# Windows Registry Hive Exploitation

> Windows registry hive exploitation for local privilege escalation. Use this skill whenever the user mentions registry exploitation, Windows LPE, hive corruption, CVE-2023-23420, CVE-2023-23423, registry memory corruption, or any Windows privilege escalation involving registry hives. Also trigger for questions about deterministic heap grooming, paged pool overflows, or inter-hive attacks on Windows systems.

- Skill: `abelrguezr/windows-registry-hive-exploitation` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/windows-registry-hive-exploitation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/windows-registry-hive-exploitation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/windows-registry-hive-exploitation

---


# Windows Registry Hive Exploitation

A skill for understanding and applying Windows registry hive corruption techniques for local privilege escalation (LPE) in authorized security testing contexts.

## ⚠️ Legal and Ethical Notice

This skill is for **authorized security research and penetration testing only**. Only use these techniques on systems you own or have explicit written authorization to test. Unauthorized exploitation of these vulnerabilities is illegal and unethical.

## Why Hive Corruption is Special

Windows registry hives are **memory-mapped `.regf` files** managed by a custom allocator (`HvAllocateCell`, `HvReallocateCell`, `HvFreeCell`). The allocator has three critical properties:

1. **No randomization** – Cell placement depends only on the order/size of prior registry API calls, making layouts reproducible across hosts.
2. **No integrity checks** – Manually altered header/data fields are trusted by kernel consumers (`Cmp*` routines) and the Registry process.
3. **Shared address space** – Attacker-controlled hives are often mapped into the same user-mode address range as HKLM/HKU hives, enabling inter-hive overflows.

This makes hive-based memory corruption bugs (e.g., CVE-2023-23420 / CVE-2023-23423) uniquely reliable for LPE.

## Deterministic Layout Grooming

Because hive allocation is deterministic, you can groom cell placement purely via Win32 APIs:

### Grooming Workflow

1. **Reset the target key** – Delete and recreate the key so the hive bin contains only known cells.
2. **Allocate predictable runs of cells** by creating values with carefully selected sizes:
   - Key/value metadata cells are multiples of 8 bytes.
   - Writing `0x3FD8`-byte values forces a fresh `0x4000`-byte bin (`0x3FD8` data + `_HBIN` header/padding), ideal for interleaving bins.
3. **Use resize-friendly types** (e.g., `REG_BINARY`) so you can free/extend individual cells by calling `RegSetValueEx` with different lengths.
4. **Record the sequence** of operations (create/delete/resize). Replaying it reproduces the same layout on other systems.

### Example Grooming Pattern

```c
void MakeBin(HKEY base, const wchar_t *name, size_t bytes) {
    std::vector<uint8_t> buf(bytes, 0x41);
    RegSetKeyValueW(base, NULL, name, REG_BINARY, buf.data(), (DWORD)buf.size());
}

void Groom(HKEY hive) {
    for (int i = 0; i < 0x20; ++i) {
        wchar_t value[32];
        swprintf(value, L"bin_%02d", i);
        MakeBin(hive, value, 0x3FD8);
        RegDeleteKeyValueW(hive, NULL, value); // leaves holes for victim cells
    }
}
```

Once a corruption primitive is available, the groom guarantees that the **target cell resides next to the sprayed holes**, enabling precise overwrites without heap spraying.

## Finding Writable Privileged Hives

Windows only evaluates the **ACL on the final component** of a registry path. If any descendant under HKLM/HKU grants `KEY_SET_VALUE`, `KEY_CREATE_SUB_KEY`, or `WRITE_DAC` to low-privileged users, you can reach it even when every parent key is locked down.

### Enumeration Strategy

1. From an elevated context, walk `\Registry\Machine` and `\Registry\User`, dumping each key's security descriptor. Store items whose DACL allows unprivileged SIDs.
2. As a normal user, attempt `RegOpenKeyEx` with `KEY_SET_VALUE|KEY_CREATE_SUB_KEY` against the recorded paths. Successful opens are viable targets.
3. Maintain a cache of open handles to **stable writable locations** so PoCs can directly deploy corrupted metadata.

### PowerShell Enumeration Script

```powershell
# Enumerate writable HKLM keys accessible to Users group
$targets = Get-ChildItem Registry::HKEY_LOCAL_MACHINE -Recurse -ErrorAction SilentlyContinue | Where-Object {
    try {
        $acl = Get-Acl $_.PsPath
        $acl.Access | Where-Object { $_.IdentityReference -match 'S-1-5-32-545' }
    } catch { $false }
} | Select-Object -ExpandProperty PsPath

foreach ($path in $targets) {
    try {
        Get-Item -Path $path -ErrorAction Stop | Out-Null
        Write-Host "[+] Accessible: $path"
    } catch {}
}
```

Project Zero found **>1000 such writable keys in HKLM on Windows 11**, including long-lived entries like `HKLM\SOFTWARE\Microsoft\DRM` and several `HKLM\SYSTEM` branches.

## Cross-User Hive Abuse

Every user hive contains `HKCU\Software\Microsoft\Input\TypingInsights`, whose ACL grants `KEY_ALL_ACCESS` to **Everyone (S-1-1-0)**. This enables:

- **Filling another user's hive** up to the 2 GiB limit, causing logon failures or forcing hive truncation.
- **Dropping corrupted cells** into other users' `NTUSER.DAT`, setting up lateral exploits.
- **Modifying differencing hives** for sandboxed apps that rely on per-user overlay hives.

This makes hive corruption vulnerabilities applicable to **lateral movement**, not just elevation within the same account.

## Metadata Corruption to Paged Pool Overflow

Large registry values are stored in `_CM_BIG_DATA` records:

- `_CM_KEY_VALUE.DataLength` holds the logical size. Its high bit indicates whether the payload lives inside the cell or in big-data storage.
- `_CM_BIG_DATA.Count` counts **16 KiB chunks** (16384 bytes minus metadata) referenced via a chunk table.

When any component calls `CmpGetValueData`:

1. The kernel allocates a **paged pool buffer** sized strictly from `DataLength`.
2. It copies `Count * 0x4000` bytes from hive storage into that buffer.

If you corrupt the cell so `DataLength < 16344 * (Count - 1)`, the copy **overruns the destination linearly** into adjacent paged-pool objects.

### Exploit Chain

1. Use the deterministic groom to place the vulnerable `_CM_KEY_VALUE` near controllable metadata.
2. Flip `DataLength` to a small number (e.g., 0x100) while leaving `_CM_BIG_DATA.Count` intact.
3. Pool-groom from user mode (pipes, ALPC ports, section objects) so a chosen object (like `EPROCESS->Token` owner or `SRVNET_BUFFER`) occupies the next chunk after the allocation.
4. Trigger a read (e.g., `RegQueryValueEx`, `NtQueryValueKey`) so `CmpGetValueData` copies all chunks and **overwrites the neighbor's fields** with attacker-controlled data from the hive.
5. Use the corrupted kernel object to pivot to arbitrary read/write or direct SYSTEM token theft.

Because the overflow length equals `(Count * 0x4000) - DataLength`, you get a **precise byte budget** and full control over the bytes written.

## Inter-Hive Linear Overflows

Hives mounted by the Registry process are mapped in **2 MiB-aligned views** with **no guard gaps**. You can force two different hives to grow in lockstep until their `_HBIN` ranges touch:

1. Choose an attacker-writable hive (app hive or user hive) and a privileged target (e.g., `HKLM\SOFTWARE`).
2. Continuously create/delete `0x3FD8`-byte values in both hives. Each allocation adds a `0x4000`-byte bin, so running both writers in parallel interleaves their bins in virtual memory.
3. Once the final bin of the attacker hive sits immediately before an HBIN belonging to HKLM, use the hive corruption bug to **overflow out of the attacker hive**, smashing HBIN headers or cells inside HKLM.
4. With HKLM metadata under control you can:
   - Stage a big-data inconsistency primitive directly in the privileged hive.
   - Corrupt configuration data consumed by SYSTEM services before it ever leaves the kernel.

The absence of guard pages means a linear overwrite from an unprivileged hive can **directly corrupt SYSTEM-owned hive structures**.

## Operational Tips

- **Monitor hive placement** with `!vad` (user-mode) and `!reg view` / `!pool` (kernel) to confirm adjacency before triggering the overflow.
- **Cache writable HKLM paths** discovered during enumeration so corruption primitives can be deployed quickly even after reboots.
- **Combine hive grooming** with standard pool feng shui (pipe pair freelists, `NtAllocateVirtualMemory` on `Registry` process) to stabilize post-overflow primitives.

## Debugging and Analysis

### WinDbg Commands

```windbg
!process Registry 0          # Find Registry process
!vad <pid>                   # View VAD tree for hive mappings
!reg view                    # View registry hive structures
!pool <address>              # Analyze paged pool allocations
```

### Key Structures

- `_HBIN` – Hive bin header (0x4000 bytes)
- `_CM_KEY_VALUE` – Key value metadata cell
- `_CM_BIG_DATA` – Large value storage record
- `HvAllocateCell` / `HvReallocateCell` / `HvFreeCell` – Allocator functions

## References

- [Project Zero – The Windows Registry Adventure #8: Practical exploitation of hive memory corruption](https://projectzero.google/2025/05/the-windows-registry-adventure-8-exploitation.html)
- CVE-2023-23420, CVE-2023-23423 – Windows Registry memory corruption vulnerabilities