0x00 Abstract Allowing direct access to named or un-named executive objects to user mode and kernel mode applications would be extremely dangerous as it would interfere with, and render the duty of the executive subsystems obsolete. As a result, this would put the whole system at risk and make the management of executive objects almost impossible. Additionally, executive objects resides in kernel memory, which means that if user mode applications could directly modify data structure in kernel memory this would also be extremely dangerous and chances of a BSOD would be high. Driver and kernel applications can obviously directly access these data structures, however, most of the objects are undocumented and therefore it is highly recommended not to do so. Instead drivers and kernel applications should (must) use kernel APIs exposed by the different executive subsystems. Finally, they should also increase (i.e. ObfReferenceObject ) or decrease (i.e. ObfDereferenceObject ) the executiv...

0x00 Abstract Almost all the actions carried out by user mode applications and Windows executive subsystems (e.g. I/O Manager, Memory Manager) have to deal with Windows resources (aka objects). These actions can be related to physical objects like devices or logical objects such as processes, threads, tokens and files. For this specific reason, the Object Manager, which is a executive subsystem, is responsible for providing a standardised, uniform and singular way to manage, create, release and access objects. Among other things, this ensures that other user mode applications and executive subsystems do not re-invent the wheel when they are interacting with objects, which might cause duplication of code and logic, resulting in security issues and logical errors. Even if everything related to objects has to go through the Object Manager, defining Windows as an object oriented operating system would be an overstatement as many kernel structures are not objects. Additionally, the Objec...

0x00 Abstract The 12th Jun 2019 I wrote a paper about the Anti-Malware Scan Interface technology. At this time, the objective was to dig into the AMSI internals in order to, firstly, understand how the technology works and, secondly, how it is possible to bypass AMSI by carrying out an in memory module function patching. This paper will not provide more information about AMSI and the patch will be the same. The reason being that a good amount of people already talked about it over the last years. Instead I will use this module in-memory patching as a case study for writing a tool in C that enumerate a remote process. Link to the paper: https://www.contextis.com/en/blog/amsi-bypass Source code of the tool can be found on Github: https://github.com/am0nsec/wspe/tree/master/AMSI Demonstration: AMSI Module Remote In-Memory Patching 0x01 Remote Process Environment Block The Process Environment Block (PEB) is a very interesting structure that contains a lot of information such a...