CVE-2024-30051 — Windows DWM Heap Overflow EoP · Master's Thesis Research

Heap-based Buffer Overflow in Windows Desktop Window Manager (dwmcore.dll)
Local Privilege Escalation → Integrity Level SYSTEM via DWM process
Build target: Windows 11 22H2 (10.0.22621.3447) · Patch: KB5037771

Description

This repository contains my Master's Thesis research on CVE-2024-30051, a High-severity (CVSS 7.8) Elevation of Privilege vulnerability in the Windows Desktop Window Manager Core Library (dwmcore.dll).

The vulnerability originates from an integer division size miscalculation in CCommandBuffer::Initialize. The size used for new() and the size used for memcpy() diverge due to this miscalculation, producing a heap overflow of 0x8F bytes. A successful exploit causes dwm.exe to load an attacker-controlled DLL, executing arbitrary code under the window manager\dwm-1 account with Integrity Level SYSTEM.

My Contribution

Repository Structure

CVE-2024-30051-Masters-Thesis/
├── README.md
├── LICENSE
├── setup.bat                        # Copies s11.dll to required location
│
├── exploit/
│   ├── C21.sln                      # Visual Studio 2022 solution
│   ├── exploit_src/
│   │   ├── c26f.vcxproj
│   │   ├── c26f.filters
│   │   └── main.cpp                 # Exploit — heap spray + hooking + overflow
│   └── payload/
│       ├── payload.vcxproj
│       ├── payload.vcxproj.filters
│       ├── dllmain.cpp              # Payload DLL — spawns SYSTEM shell + cleanup
│       ├── framework.h
│       ├── pch.h
│       └── pch.cpp
│
└── docs/
    ├── screenshots/                 # Patch diffing, WinDbg, and forensic captures
    └── analysis/
        ├── 01-root-cause.md         # Integer division bug in CCommandBuffer::Initialize
        ├── 02-heap-spray.md         # 50-session empirical data and statistical findings
        └── 03-timeline.md           # Discovery, disclosure, and patch chronology

Quick Start

Prerequisites

• Windows 11 22H2 (build 22621.3447, unpatched — no KB5037771)
• Visual Studio 2022 with C++ Desktop workload
• VM with snapshot recommended (required for reproducible heap state)

Step 1 — Build the payload DLL

Open C21.sln in Visual Studio 2022. Build the payload project in Release x64.

Step 2 — Place the DLL

Run setup.bat from the repository root. It copies s11.dll to C:\Users\Public\Documents\s11.dll (the path defined by PAYLOAD_DLL_PATH).

⚠️ The DLL must be at this exact path before running C26f.exe. Placing it next to the executable will not work.

Step 3 — Build the exploit

Build the C26f project in Release x64.

Step 4 — Run

x64\Release\C26f.exe

Run from a standard (non-elevated) CMD. The exploit auto-retries up to 10 times. On success, dwm.exe loads s11.dll and spawns a CMD with SYSTEM Integrity Level. A session log is written to %TEMP%\cve_30051_log.txt.

Exploit Configuration

#define MAX_ATTEMPTS        10      // Max auto-retry attempts per session
#define SPRAY_STEP          0x10    // Hole spacing index (1024 holes)
#define SPRAY_RANGE_START   0x3000  // Spray range start index
#define SPRAY_RANGE_END     0x7000  // Spray range end index
#define SLEEP_POST_SPRAY    0xC8    // ms wait after spray (200ms)
#define SLEEP_POST_HOLES    0xC8    // ms wait after freeing holes (200ms)
#define PAYLOAD_DLL_PATH    "C:\\Users\\Public\\Documents\\s11.dll"

Technical Overview

Vulnerability Root Cause

In CCommandBuffer::Initialize (dwmcore.dll 10.0.22621.3447), CD2DSharedBuffer::GetBufferSize is called twice. The size passed to new() undergoes integer division by 0x90 before multiplication, while memcpy() uses the raw value:

buffer_size = GetBufferSize()   → e.g. 0x23F

size_new    = (0x23F / 0x90) * 0x90  = 0x1B0   ← allocated
size_memcpy = 0x23F                             ← copied

overflow    = 0x23F - 0x1B0 = 0x8F bytes

Patch Diffing Results

BinDiff comparison between build 10.0.22621.3447 (vulnerable) and 10.0.22621.3593 (patched):

The anomalous score of 0.32 against a global similarity of 0.98 is the direct signature of the vulnerability locus.

Exploitation Chain

1. Hook RtlCreateHeap               → capture dwmcore heap handle
2. Hook RtlAllocateHeap             → capture base chunk address
3. Hook NtDCompositionCreateChannel → capture MappedAddress (shared memory region)
4. Hook NtDCompositionCommitChannel → overwrite size field (0x120 → 0x23F)
                                      inject additional batch commands
5. Heap spray 0x10000 CHolographicInteropTexture objects (size=0x1B0)
6. Free holes every 0x10 indices    → create gaps for overflow landing
7. Write payload into overflow buffer → KCBTable+0x388 + LoadLibraryA + DLL path
8. Release all spray objects         → trigger overflow → LoadLibraryA("s11.dll")
9. dwm.exe loads payload DLL         → spawns CMD as SYSTEM integrity

Empirical Heap Spray Analysis (50 Sessions)

Research Question

Does available RAM influence the number of attempts required for successful heap spray?

Experimental Design

Two blocks of 25 sessions each. Protocol per session: restore clean post-boot snapshot → wait 100 seconds stabilization → launch exploit → record success attempt.

Results

Statistical Tests

Key Conclusions

• C1: DWM heap post-boot is 12.9–19× more deterministic than theoretical prediction.
• C2: RAM availability has statistically significant effect on spray reliability (p = 0.031).
• C3: Halving RAM doubles standard deviation (1.135 → 2.645).
• C4: Failure rate is homogeneous at 4% across both configurations.
• C5: Constant base = heap_base + 0x720 confirms reproducible post-boot heap layout as the primary driver of determinism — not hole density.
• C6: With ≥ 8 GB RAM, an adversary can expect success within the first 5 attempts.

Full raw data, session log format, and deterministic heap observations documented in docs/analysis/02-heap-spray.md.

Post-Exploitation Output

On success, a CMD window opens under window manager\dwm-1:

=====================================================
  CVE-2024-30051 - Windows DWM Heap Overflow EoP
  CWE-122  |  CVSS 7.8  |  Elevation of Privilege
=====================================================

  Researched and reproduced by : devianntsec
  Original PoC by              : Ricardo Narvaja (Fortra)
  Target                       : Windows 11 22H2 (22621.3447)

=====================================================

  [*] Current user:
  window manager\dwm-1

  [*] Mandatory Integrity Level:
  Mandatory Label\System Mandatory Level   S-1-16-16384

  [*] Enabled privileges:
  SeImpersonatePrivilege    Enabled

=====================================================
  Shell running under DWM process - SYSTEM level
=====================================================

Artifacts (s11.dll and the .bat script) are automatically deleted after 5 seconds via a deferred cleanup process.

Forensic Artifacts

Technical Documentation

Academic Context

This research is part of my Master's Thesis in Cybersecurity (UCAM — Campus Internacional de Ciberseguridad), analyzing N-Day vulnerabilities across multiple environments.

This CVE represents the Windows desktop application vector within the thesis, demonstrating:

• Heap-based buffer overflow exploitation via DirectComposition ALPC channel
• Binary diffing (BinDiff) as a systematic method for N-Day vulnerability location
• In-process API hooking without external tools
• Empirical quantification of heap spray determinism across RAM configurations

Keywords: EoP · Heap Overflow · DirectComposition · DWM · Patch Diffing · BinDiff · WinDbg · Heap Spray · Empirical Analysis · CVE-2024-30051

Author

Annais Molina (devianntsec) — Master's Student in Cybersecurity

Acknowledgments

• Ricardo Narvaja (Fortra/CoreSecurity) — Original PoC and reverse engineering writeup
• Kaspersky GReAT — Original vulnerability discovery and responsible disclosure
• Microsoft MSRC — Patch KB5037771 (May 2024)

License

MIT License — see LICENSE

Legal Disclaimer

This repository is provided for educational and security research purposes only, as part of an academic Master's Thesis. All testing was performed on isolated virtual machines with no network exposure. Use only on systems you own or have explicit written authorization to test. Unauthorized use against systems is illegal and may result in criminal prosecution.