Listen to this Post
Introduction:
Modern endpoint security relies heavily on blocking malicious code execution. Virtualization-Based Security (VBS), Hypervisor-Protected Code Integrity (HVCI), and Kernel CET (kCET) are designed to create an impenetrable fortress around the kernel, preventing attackers from running unauthorized code. However, a newly developed post-exploitation technique called DOG (Data-Only Gadgets) shatters this paradigm by proving that execution is not a requirement for a successful compromise. This technique leverages existing kernel structures and code, chaining them into functional attack paths using only read/write primitives, effectively rendering memory integrity protections irrelevant.
Learning Objectives:
- Understand the core mechanics of data-only gadget chains and how they subvert kernel execution protections.
- Learn how to identify, classify, and chain existing kernel structures for post-exploitation using DOG.
- Explore defensive strategies against data-only attacks and how to modify EDR/hypervisor monitoring to detect such anomalies.
You Should Know:
- Understanding Data-Only Gadgets (DOG) and the Post-Exploitation Paradigm
The core concept behind DOG is a fundamental shift in offensive security: instead of injecting or executing shellcode, the attacker manipulates what is already present. When an attacker achieves arbitrary read/write primitives in the kernel, they don’t need to “run” code in the traditional sense. DOG automates the process of scanning the kernel’s memory space to locate existing function pointers, data structures, and code gadgets that can be chained together to perform malicious actions.
For example, consider a scenario where an attacker wants to elevate privileges. Instead of injecting a new `token` stealing routine, DOG locates the existing `SeTokenAssignPrimaryToken` function and manipulates the pointers in the current process’s `EPROCESS` structure to point to a privileged token already present in memory. This is not code execution; it’s data manipulation.
Step‑by‑step guide explaining what this does and how to use it:
- Step 1: Establish Read/Write Primitive. The first requirement is a kernel read/write primitive, typically achieved through a vulnerable driver or a bypassed IOCTL. On Windows, this might be a `Write-What-Where` condition.
- Step 2: Scan Kernel Memory. DOG performs a heuristic scan of the kernel address space. It maps the kernel (e.g., `ntoskrnl.exe` and loaded drivers) and identifies structures.
- Step 3: Classify Structures. The tool classifies objects like
EPROCESS,ETHREAD,TOKEN, and `KAPC` to locate relevant pointers and security descriptors. - Step 4: Chain Gadgets. Based on the attacker’s goal (e.g., privilege escalation, hiding a process), DOG identifies a sequence of structures that can be linked. For instance, changing the `Token` pointer in the current `EPROCESS` to point to the System process’s
Token. - Step 5: Resolve and Apply. DOG resolves the runtime addresses of these gadgets and applies the write primitives to chain them.
Commands/Tools: On Windows, analyzing this often involves using `WinDbg` for debugging and `ida` for static analysis to identify viable gadgets. A command to inspect token privileges in a live kernel debug session might be:
dt nt!_EPROCESS <Process_Address> Token
2. Reconnaissance: Identifying Viable Kernel Gadgets
Before chaining, the attacker must know what is available. This phase involves deep kernel reconnaissance. DOG automates this by parsing kernel debugging symbols (PDB files) or performing signature-based scans on the kernel image. It looks for “gadgets”—not the typical ROP gadgets, but functional data pointers. Examples include pointers to the `ObReferenceObjectByHandle` function, or structures containing system call tables.
Step‑by‑step guide explaining what this does and how to use it:
- Step 1: Dump Kernel Modules. Using tools like `lm` in WinDbg or `system.map` in Linux, list all loaded kernel modules.
- Step 2: Locate Symbol Tables. If available, use `x nt!` to list symbols. DOG specifically looks for functions that handle security (e.g.,
Se), process management (Ps), and object management (Ob). - Step 3: Build Dependency Graphs. The tool maps which structures hold pointers to these functions. For instance, the `EPROCESS` structure contains a `PspCidTable` handle table; manipulating this can hide processes without hooking functions.
Commands/Tools:
On a Linux system, you might view the `kallsyms` to see kernel symbols:
sudo cat /proc/kallsyms | grep -E "commit_creds|prepare_kernel_cred|sys_call_table"
On Windows, using a tool like `WinDbg` to list function pointers:
x nt!Se
3. Chaining Data-Only Attacks for Privilege Escalation
The most common application of DOG is privilege escalation. Since kernel execution protections prevent the addition of new code, DOG modifies existing data structures. A classic chain involves swapping the `Token` of a target process with the `System` process. This is a purely data-oriented attack: it writes a new value to the `Token` field in the `EPROCESS` structure.
Step‑by‑step guide explaining what this does and how to use it:
- Step 1: Locate the Target EPROCESS. Identify the address of the current process’s `EPROCESS` structure and the `System` process’s
EPROCESS. - Step 2: Locate the Token Field. Determine the offset of the `Token` field within the `EPROCESS` structure. This offset is version-specific (e.g., Windows 10 vs 11).
- Step 3: Write the New Token Pointer. Use the write primitive to replace the current process’s token pointer with the System process’s token pointer.
- Step 4: Verify. Spawn a new shell. If the operation was successful, the new process will have SYSTEM privileges without a single byte of shellcode being executed.
Code/Script (Conceptual in C):
// Assuming we have read/write primitives ReadKernelMemory and WriteKernelMemory
void escalate_privilege_data_only() {
uintptr_t current_eprocess = get_current_eprocess();
uintptr_t system_eprocess = get_system_eprocess();
uintptr_t token_field_offset = 0x348; // Offset varies by OS version
uintptr_t system_token = ReadKernelMemory(system_eprocess + token_field_offset);
WriteKernelMemory(current_eprocess + token_field_offset, system_token);
}
4. Integration with Kernel Pack and EDR Evasion
DOG is not just a theory; it has been integrated into the “Kernel Pack” framework. The key to its success against EDRs is that it does not trigger “Code Integrity” violations. Traditional EDRs hook kernel functions to detect callbacks. Since DOG doesn’t call those functions via new code—it simply manipulates data—many EDR hooks are bypassed.
Step‑by‑step guide explaining what this does and how to use it:
- Step 1: Load Kernel Pack. The operator loads the Kernel Pack into a compromised environment with admin privileges (or via a kernel exploit).
- Step 2: Invoke DOG Module. The operator selects the DOG module and specifies the target objective (e.g., “Hide Process” or “Elevate Token”).
- Step 3: Runtime Resolution. DOG dynamically resolves offsets for the specific Windows version of the target machine, ensuring compatibility without reboots or crashes.
- Step 4: Execute Chain. The tool applies the data-only changes. From the perspective of the EDR, the system state changed, but no unauthorized code executed, making detection extremely difficult.
5. Mitigation Strategies: Hardening Against Data-Only Exploitation
Defending against DOG requires shifting focus from execution prevention to integrity monitoring. Since these attacks don’t rely on executing malicious code, traditional antivirus and EDR solutions focused on hashing and execution control are ineffective. The defense must center on kernel integrity.
Step‑by‑step guide explaining what this does and how to use it:
- Step 1: Implement Kernel Integrity Monitoring. Use Kernel Patch Protection (PatchGuard) on Windows, but note that DOG modifies structures, not code. Advanced EDRs must monitor critical structures (like `EPROCESS` tokens) for unauthorized modifications.
- Step 2: Restrict Read/Write Primitives. The root cause of DOG is the existence of a read/write primitive. Hardening against driver vulnerabilities (like blocking vulnerable driver load lists) is critical. Use Windows Defender Application Control (WDAC) to only allow signed, trusted drivers.
- Step 3: Virtualization-Based Security (VBS) with Secure Kernel. While DOG bypasses HVCI, enabling VBS with the secure kernel adds another layer of isolation that can monitor access to hypervisor pages. Monitor for anomalies in the “Trustlet” communications.
- Step 4: Use Event Tracing for Windows (ETW). Monitor for kernel events such as `Microsoft-Windows-Kernel-Process` for `EPROCESS` modifications that don’t align with normal API calls.
Commands/Tools:
To monitor for potential kernel data manipulation on Windows, use PowerShell to query for suspicious driver loads:
Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} | Where-Object { $<em>.Message -match "Unsigned" -or $</em>.Message -match "Test" }
To enforce WDAC policies:
Get-CIPolicy
- Demonstrating the Impact: Simulating DOG in a Lab Environment
To fully understand the lethality of this technique, it is best simulated in a lab. Setting up a Windows 11 VM with VBS, HVCI, and kCET fully enabled, then using a publicly available vulnerable driver (e.g., for exploitation exercises) to establish a read/write primitive allows for testing DOG-style attacks.
Step‑by‑step guide explaining what this does and how to use it:
- Step 1: Environment Setup. Install Windows 11 on a VM. Enable VBS, HVCI, and kCET via Windows Security > Device Security > Core Isolation.
- Step 2: Deploy Vulnerable Driver. Load a known vulnerable driver (like a test driver with arbitrary read/write) to simulate the primitive acquisition phase.
- Step 3: Run DOG (or DOG-like script). Execute the data-only chain to elevate privileges.
- Step 4: Observe EDR. Install a demo EDR to see if it alerts. Typically, it will not alert on code execution, but may alert on token manipulation if it monitors that specific structure.
What Undercode Say:
- The Landscape Has Changed: The introduction of DOG confirms that kernel security must evolve beyond “block execution.” Defenders must now treat the kernel’s data plane as the new attack surface.
- Read/Write is the New Execute: The industry’s focus on preventing code execution (via HVCI) is no longer a silver bullet. If an attacker can write to kernel memory, they can effectively “execute” logic using the kernel’s own instructions.
- EDR Blind Spot: Many modern EDR solutions rely heavily on function hooking. Data-only attacks present a significant blind spot, requiring a shift toward memory integrity monitoring and behavioral analysis of kernel structures.
- Offensive Evolution: For red teams, DOG represents a leap in sophistication. It allows for stealthy persistence and privilege escalation without touching the disk or executing shellcode, evading even the most hardened configurations.
- Defensive Necessity: For defenders, the mitigation lies in aggressive driver lockdown, kernel structure integrity validation, and moving security controls into the hypervisor layer where data modifications can be observed across virtual machine boundaries.
Prediction:
As techniques like DOG become more mainstream, we will likely see a surge in “Data-Only” exploitation frameworks. This will force a market-wide recalibration of EDR and XDR platforms toward “Kernel Integrity Monitoring” (KIM) as a mandatory feature. In the next 12-24 months, anticipate Microsoft and leading security vendors to release updates focused on protecting `EPROCESS` and `TOKEN` structures from unauthorized direct manipulation, potentially leveraging new hypervisor capabilities to enforce “Data Execution Prevention” for kernel structures, effectively treating sensitive data like code.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
