Kernel
The Windows kernel contains multiple specific sections responsible for some part of the kernel. Not all sections are as interesting to a security researcher. The interesting ones among others are the Security Reference Monitor, Object Manager, Configuration Manager, Memory manager, I/O manager, Process and thread manager and Configuration manager.
Most cmdlets used within these notes are from the NtObjectManager PowerShell module
Shared objects leading to privileged code execution
When you query the list of handles using the Get-NtHandle command, you also get the address of the object in kernel memory. When you open the same kernel object, you'll get different handles, but they will still point to the same kernel object address. You can use the object address to find processes that share handles.
This can be interesting for security in cases when an object is shared between two processes at different privileges. The low-privileged process might be able to modify the properties of the object to bypass security checks in the higher privileged process, enabling it to gain additional privileges. The low-privileged process could map the shared Section to be writable and modify contents that the privileged process assumed couldn’t be modified. This could result in the low privileged process being able to modify arbitrary memory in the privileged process, resulting in privileged code execution.
On a default Windows install, you likely won't get any results, but third party software running could contain interesting mapped memory sections.
Modify mapped memory
If you find an interesting Section object to modify, you can map it into memory using Add-NtSection. But how do modify the mapped memory? The simplest approach from the command line is to use the Write-NtVirtualMemory command, which supports passing a mapped section and an array.
Memory execution
There are different ways to allocate a memory space and execute it.
Within normal space
Within section objects
One way is to use sections. The following example gets our current process, creates a new section object with Execute Read Write privileges, maps it to our current process, writes the memory and executes the thread.
We can also select a remote process instead using mapping:
Object manager
In Linux, everything is a file. In Windows everything is a object, meaning that every file, process, and thread is represented in kernel memory as an object structure. The Object manager is responsible for managing these objects.
Object Manager Name Space (OMNS)
As a user of Windows, you typically see just your filesystem drives in Explorer. But underneath the user interface is a whole additional filesystem just for kernel objects. Access to this filesystem, referred to as the object manager namespace (OMNS), isn’t very well documented or exposed to most developers, which makes it even more interesting. Each directory is configured with a security descriptor that determines which users can list its contents and which users can create new sub-directories and objects.
Windows pre-configures several important object directories like NtObject:\RPC Control\ which is the directory for Remote Procedure Call endpoints.
Or the NtObject:\Device directory, containing devices such as mounted filesystems.
The configuration manager (registry)
The configuration manager, known more commonly as the registry, is an important component for configuring the operating system. It stores a variety of configuration information, ranging from the system-critical list of available I/O manager device drivers to the (less critical) last position on screen of your text editor's window.
You can access it through the OMNS, although you must use registry-specific system calls. The root of the registry is the OMNS path \REGISTRY.
Note that PowerShell already comes with a drive provider that you can use to access the registry. However, this drive provider exposes only the Win32 view of the registry, which hides the internal details about the registry from view.
the PowerShell module's drive provider allows you to view the entire registry. It also uses the native APIs, which use counted strings, and supports the use of NUL characters in the names of the registry keys and values, while the APIs uses NUL-terminated C-style strings, which cannot handle embedded NUL characters. Therefore, if a NUL is embedded into a name, it’s impossible for the built-in provider to access that key or value.
This behavior of the Win32 APIs can lead to security issues. For example, it’s possible for malicious code to hide registry keys and values from any software that uses the Win32 APIs. This can prevent the malicious code from being detected.
Last updated