Listen to this Post
Introduction:
When attackers manually map malicious payloads into a Windows process, the Virtual Address Descriptor (VAD) tree leaves an exposed RWX (Read-Write-Execute) node – a blinking red light for kernel‑mode EDRs and memory scanners. Direct Kernel Object Manipulation (DKOM) offers a surgical solution: unlink the VAD node so that the memory region becomes invisible to forensic tools, all while navigating undocumented structures, spinlocks, and a razor‑thin 24KB kernel stack.
Learning Objectives:
- Understand the Windows VAD tree structure and why RWX nodes are Indicators of Compromise (IoCs).
- Learn to manually walk
ActiveProcessLinks, attach to a target process, and safely manipulate the VAD AVL tree using DKOM techniques. - Implement an iterative (non‑recursive) in‑order traversal to avoid kernel stack overflows, and remove a VAD node via the undocumented `RtlAvlRemoveNode` function.
You Should Know:
1. Walking the `ActiveProcessLinks` to Bypass API Hooks
What it does:
EDRs often hook `NtQuerySystemInformation` or `PsLookupProcessByProcessId` to monitor process enumeration. By manually traversing the doubly‑linked list of `_EPROCESS` structures (via ActiveProcessLinks), you can resolve a target process’s `_EPROCESS` address without calling any monitored APIs.
Step‑by‑step guide (kernel driver, C++):
- Obtain the address of the initial system process (PID 4) – often stored in `PsInitialSystemProcess` (exported).
- Cast it to `PEPROCESS` and access the `ActiveProcessLinks` field (offset varies by Windows build; use `dt nt!_EPROCESS ActiveProcessLinks` in WinDBG).
- Iterate through the list comparing `UniqueProcessId` with your target PID.
- Once found, call `KeAttachProcess()` to attach to the target process’s address space.
PEPROCOUND TargetEprocess = NULL;
PLIST_ENTRY head = &PsInitialSystemProcess->ActiveProcessLinks;
PLIST_ENTRY entry = head->Flink;
while (entry != head) {
PEPROCESS eproc = CONTAINING_RECORD(entry, EPROCESS, ActiveProcessLinks);
if ((HANDLE)((PUCHAR)eproc + UniqueProcessIdOffset) == targetPid) {
TargetEprocess = eproc;
break;
}
entry = entry->Flink;
}
KeAttachProcess(TargetEprocess);
Windows command (live debugging with WinDBG):
`!process 0 0` – lists all processes with `_EPROCESS` addresses.
`dt nt!_EPROCESS ActiveProcessLinks` – inspect links.
- Reverse Engineering `MiLockVadTree` – Obtaining the Exclusive Spinlock
What it does:
The VAD tree is protected by an undocumented spinlock that must be acquired before any modification to prevent race conditions and memory corruption. `MiLockVadTree` internally calls KeAcquireSpinLockRaiseToDpc. You can either locate this function by pattern scanning or directly call it if you know its prototype.
Step‑by‑step guide:
- Use WinDBG to disassemble `MiLockVadTree` (exported in some builds, otherwise find via
x nt!MiVad). - Observe its single parameter: a pointer to the `_MMVAD` structure’s locking field (often `VadLock` embedded in the VAD root).
- Call `MiLockVadTree` at `DISPATCH_LEVEL` – ensure you are at the correct IRQL before proceeding.
- After manipulation, call the corresponding unlock routine (e.g., `MiUnlockVadTree` or manually call
KeReleaseSpinLock).
// Reverse-engineered pattern (Windows 11 22H2) typedef VOID (NTAPI pMiLockVadTree)(PVOID VadLock); pMiLockVadTree MiLockVadTree = (pMiLockVadTree)GetKernelProcAddress(L"MiLockVadTree"); if (MiLockVadTree) MiLockVadTree(&VadRoot->VadLock);
Mitigation for defenders:
Monitor for drivers that attempt to locate and call undocumented `MiLock` functions via pattern scanning – a strong indicator of DKOM malware.
- Iterative In‑Order VAD Traversal (Bypassing the 24KB Stack Limit)
What it does:
A recursive tree walk on the VAD AVL tree can quickly exceed the kernel thread stack limit (24KB), causing `KERNEL_STACK_INPAGE_ERROR` (BSOD). The solution is an iterative algorithm that uses a manually managed pointer stack (allocated from non‑paged pool) to traverse the tree without recursion.
Step‑by‑step guide:
- Locate the root of the VAD tree inside the target process’s `_EPROCESS` – usually at offset `VadRoot` (e.g., `+0x7a0` for Windows 11).
- Define a structure for your manual stack (e.g., `PVOID stack
` and an index). </li> </ol> <h2 style="color: yellow;">3. Implement an in‑order traversal loop:</h2> <ul> <li>Push current node, then go left until <code>LeftChild == NULL</code>.</li> <li>Pop node, process it (check if it matches the target VA range of your payload), then go right.</li> </ul> <ol> <li>Use `RtlAvlFindNode` or manually compare `StartingVpn` and `EndingVpn` fields.</li> </ol> [bash] // Iterative in-order traversal define MAX_STACK 256 PMMVAD stack[bash]; int top = -1; PMMVAD current = VadRoot; while (current != NULL || top != -1) { while (current != NULL) { stack[++top] = current; current = current->LeftChild; } current = stack[top--]; // Check if current VAD covers the payload's virtual address if (targetVa >= (current->StartingVpn << PAGE_SHIFT) && targetVa <= (current->EndingVpn << PAGE_SHIFT) + PAGE_MASK) { TargetVad = current; break; } current = current->RightChild; }Linux parallel:
In Linux, similar VMA (Virtual Memory Area) tree traversal can be done using `rb_next()` iteratively to avoid stack exhaustion in kernel context.
4. Unlinking the VAD Node Using `RtlAvlRemoveNode`
What it does:
Once you have identified the target VAD node (the one backing your manually mapped payload), you must unlink it from the AVL tree completely. The undocumented `RtlAvlRemoveNode` (exported from
ntoskrnl.exe) performs a balanced removal and updates all parent/child pointers.Step‑by‑step guide:
- Acquire the VAD tree spinlock using `MiLockVadTree` as shown earlier.
2. Call `RtlAvlRemoveNode`:
- First parameter: pointer to the VAD tree root (from
_EPROCESS.VadRoot). - Second parameter: pointer to the target VAD node (
PMMVAD).
- After removal, zero out the node’s
LeftChild,RightChild, and `Parent` pointers to avoid dangling references. - Release the spinlock and detach from the process (
KeDetachProcess).
// Prototype - reverse engineered typedef BOOLEAN (NTAPI pRtlAvlRemoveNode)(PRTL_AVL_TABLE Table, PVOID Node); pRtlAvlRemoveNode RtlAvlRemoveNode = (pRtlAvlRemoveNode)GetKernelProcAddress(L"RtlAvlRemoveNode"); if (RtlAvlRemoveNode) { RtlAvlRemoveNode((PRTL_AVL_TABLE)VadRoot, TargetVad); }Detection note:
After unlinking, the memory region is still present but no longer appears in tools like `!vad` in WinDBG,
Vmmap, or Microsoft Defender’s memory scanner. However, the physical pages may remain – advanced EDRs can cross‑reference working set lists with PFN databases to spot anomalies.5. Cleaning Up the _EPROCESS Flags and Countermeasures
What it does:
To fully disappear, you should also clear the `_EPROCESS.VadRoot` reference (if dereferenced), adjust the `VirtualMemoryCount` and `WorkingSetSize` fields, and remove any audit trail left by the memory mapping operation (e.g., mapped file objects).
Step‑by‑step guide (post‑unlink):
- Decrement the `_EPROCESS.VirtualMemoryCount` by one (offset varies by build).
- Reduce `_EPROCESS.WorkingSetSize` and `PeakWorkingSetSize` by the number of pages you unmapped.
- If your payload was backed by a section object, ensure you also unlink and close the section handle.
- Optionally, call `MmUnmapViewOfSystem` for completeness (careful – this may re‑touch the VAD and cause inconsistency).
Windows PowerShell (forensic view – what a defender would run):
List all RWX VAD regions using WinDBG in script mode & "C:\Program Files\Debugging Tools for Windows (x64)\cdb.exe" -c "!process 0 0; !vad target_process_address -v; q" -z memory.dmp
Mitigation script for Blue Teams (Live response):
Use `!vad` in WinDBG over a live kernel debugger, then validate that every `_MMVAD` node has consistent parent/child pointers – missing nodes or a corrupted AVL tree signature (e.g., child with no parent) indicates DKOM tampering.
6. Defensive Evasion: Hiding the DKOM Manipulation Itself
What it does:
Even if you successfully unlink the VAD, the driver that performed the DKOM may still be loaded in memory and its image can be scanned. You must hide the driver’s own kernel objects, such as its `_DRIVER_OBJECT` and
_LDR_DATA_TABLE_ENTRY.Step‑by‑step guide (simplified):
1. Unlink your driver’s module from the `PsLoadedModuleList`.
- Remove its entry from `MmLoadedModuleList` to avoid detection by `NtQuerySystemInformation` (SystemModuleInformation).
3. Clear the `DriverSection` field in your `_DRIVER_OBJECT`.
- Use `ExQueueWorkItem` to run cleanup at a later IRQL, making the removal less synchronous and harder to trace.
// Unlink from PsLoadedModuleList PLIST_ENTRY head = &PsLoadedModuleList; PLIST_ENTRY entry = head->Flink; while (entry != head) { PLDR_DATA_TABLE_ENTRY ldr = CONTAINING_RECORD(entry, LDR_DATA_TABLE_ENTRY, InLoadOrderLinks); if (ldr->DllBase == myDriverBase) { RemoveEntryList(&ldr->InLoadOrderLinks); RemoveEntryList(&ldr->InMemoryOrderLinks); RemoveEntryList(&ldr->InInitializationOrderLinks); break; } entry = entry->Flink; }What Undercode Say:
- Key Takeaway 1: DKOM techniques like VAD unlinking are not just theoretical – they are actively used in rootkits to evade EDRs that rely solely on VAD scanning. Understanding this is essential for both offensive developers and defenders.
- Key Takeaway 2: The 24KB kernel stack limit turns a simple recursive function into a BSOD trigger. The iterative traversal pattern is a non‑negotiable safe coding practice for any kernel‑mode tree walk.
Analysis: The Windows kernel remains a battlefield of undocumented structures and cat‑and‑mouse games. While Microsoft has hardened PatchGuard and added mitigations, the VAD tree is still vulnerable to direct manipulation because kernel callbacks (e.g.,
ObRegisterCallbacks) do not monitor internal AVL modifications. Defenders must adopt memory forensics that verify tree integrity – e.g., walking the VAD AVL tree from the root and cross‑referencing with the per‑process working set list. Additionally, the rise of eBPF for Windows (now production‑ready) may offer a non‑invasive way to monitor spinlock acquisitions and detect `RtlAvlRemoveNode` calls from unsigned drivers. For red teams, this technique remains potent but requires careful attention to IRQL, pool allocations, and Windows version offsets – a single mistake still leads to a crash. Ultimately, hiding memory is only half the battle; hiding the fact that you are hiding requires orchestrating multiple DKOM primitives simultaneously.Prediction:
As EDRs move towards hardware‑assisted virtualization (VT‑x) and hypervisor‑based memory introspection, traditional VAD unlinking will become less effective because the hypervisor can maintain a shadow VAD tree outside the guest’s reach. However, this shift also introduces new attack surfaces – hypercall injection and nested page table manipulation. Within the next two years, we will see rootkits that unhook VTL0 (Ring 0) and move into VTL1 (Secure Kernel) or use Intel CET to bypass control‑flow integrity checks during VAD manipulation. Defenders will respond with AI‑driven anomaly detection that flags IRQL changes and spinlock acquisition patterns, not just static VAD node values. The DKOM arms race is far from over – it is merely moving deeper into the hardware stack.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Arth Maurya – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeTesting & Stay Tuned:
