Share
## https://sploitus.com/exploit?id=968D0B8B-0F78-5650-B65D-6AD17E5C2D34
# CVE-2024-30051 β€” Windows DWM Heap Overflow EoP Β· Master's Thesis Research

[![Platform](https://img.shields.io/badge/Platform-Windows%2011%2022H2-blue)](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-30051)
[![Language](https://img.shields.io/badge/Language-C%2B%2B-informational)](https://github.com/devianntsec)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
[![Research](https://img.shields.io/badge/Research-Master's%20Thesis-purple)](https://github.com/devianntsec)
[![CVSS](https://img.shields.io/badge/CVSS-7.8%20(High)-orange)](https://nvd.nist.gov/vuln/detail/CVE-2024-30051)

> **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

| Aspect | Description |
|--------|-------------|
| **Automated retry loop** | Auto-retries up to 10 attempts, exits on first success |
| **Session logging** | Full timestamped log per session to `%TEMP%\cve_30051_log.txt` |
| **Empirical heap spray analysis** | 20 sessions across two configurations (step=0x20 vs step=0x10) |
| **Post-exploitation payload** | Custom DLL with privilege banner, `whoami` output, and auto-cleanup |
| **Academic documentation** | Root cause, exploitation chain, and statistical findings |

---

## Repository Structure
```
CVE-2024-30051-Masters-Thesis/
β”œβ”€β”€ README.md                        # This file
β”œβ”€β”€ LICENSE                          # MIT License
β”œβ”€β”€ setup.bat                        # Helper script β€” copies s11.dll to required location
β”‚
β”œβ”€β”€ exploit/                         # Visual Studio 2022 solution
β”‚   β”œβ”€β”€ C21.sln                      # Solution file (contains C26f + payload projects)
β”‚   β”‚
β”‚   β”œβ”€β”€ exploit_src/                 # Main exploit source (C26f.exe)
β”‚   β”‚   β”œβ”€β”€ c26f.vcxproj             # Visual Studio project file
β”‚   β”‚   β”œβ”€β”€ c26f.filters             # Project file filters (organizes source files in IDE)
β”‚   β”‚   └── main.cpp                 # Exploit entry point β€” heap spray + hooking + overflow
β”‚   β”‚
β”‚   └── payload/                     # Payload DLL source (s11.dll)
β”‚       β”œβ”€β”€ payload.vcxproj          # Visual Studio project file
β”‚       β”œβ”€β”€ payload.vcxproj.filters  # Project file filters
β”‚       β”œβ”€β”€ dllmain.cpp              # DLL entry point β€” spawns SYSTEM shell + cleanup
β”‚       β”œβ”€β”€ framework.h              # Windows header includes
β”‚       β”œβ”€β”€ pch.h                    # Precompiled header definitions
β”‚       └── pch.cpp                  # Precompiled header source
β”‚
└── docs/
    β”œβ”€β”€ analysis/
    β”‚    β”œβ”€β”€ 01-root-cause.md         # Integer division β”‚bug in CCommandBuffer::Initialize
    β”‚    β”œβ”€β”€ 02-heap-spray.md         # Empirical data from β”‚20 sessions, statistical findings
    β”‚    └── 03-timeline.md           # Discovery, β”‚disclosure, and patch chronology
    β”‚ 
    └── screenshots/
         └──  ...                     # Media
```

---

## Quick Start

### Prerequisites

- Windows 11 22H2 (build 22621.3447, **unpatched** β€” no KB5037771)
- Visual Studio 2022 with C++ Desktop workload
- Machine should be a VM (VirtualBox/VMware) with snapshot before testing

### Step 1 β€” Build the payload DLL

1. Open `C21.sln` in Visual Studio
2. Build the `payload` project in **Release x64**

### Step 2 β€” Place the DLL

Run `setup.bat` from the repository root. It will copy `s11.dll` to the required location and optionally launch the exploit.

> ⚠️ The path `C:\Users\Public\Documents\s11.dll` is hardcoded in the exploit.
> The DLL **must** be at this exact location before running `C26f.exe`.
> Placing it next to the executable will not work.

### Step 3 β€” Build the exploit

1. Build the `C26f` project in **Release x64**

### Step 4 β€” Run
```cmd
x64\Release\C26f.exe
```

Or use `setup.bat`, which offers to launch it directly after placing the DLL.

Run from a standard (non-elevated) CMD. The exploit will:
1. Auto-retry up to 10 times
2. On success, `dwm.exe` loads `s11.dll` and spawns a CMD with **SYSTEM Integrity Level**
3. A session log is written to `%TEMP%\cve_30051_log.txt`
4. A summary MessageBox appears on completion

---

## Exploit Configuration

At the top of `main.cpp`, the following `#define` values control the heap spray:
```cpp
#define MAX_ATTEMPTS        10      // Max auto-retry attempts
#define SPRAY_STEP          0x10    // Hole spacing (0x20 = 512 holes, 0x10 = 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)
```

---

## Technical Overview

### Vulnerability Root Cause

In `CCommandBuffer::Initialize` (dwmcore.dll 10.0.22621.3447), `CD2DSharedBuffer::GetBufferSize` is called twice. The size for `new()` undergoes integer division by `0x90` before multiplication, while `memcpy()` uses the raw size:
```
buffer_size = GetBufferSize()   β†’ e.g. 0x23F

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

overflow    = 0x23F - 0x1B0 = 0x8F bytes
```

### Exploitation Chain
```
1. Hook RtlCreateHeap        β†’ capture dwmcore heap handle
2. Hook RtlAllocateHeap      β†’ capture base chunk address
3. Hook NtDCompositionCreateChannel  β†’ capture MappedAddress
4. Hook NtDCompositionCommitChannel  β†’ modify 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
```

### Key Offsets (Build 22621.3447)

| Field | Value | Notes |
|-------|-------|-------|
| `value4` | `0x1B0` | Allocation size |
| `value5` | `0x50` | Object type (CHolographicInteropTexture) |
| `posicion` | `0x1B0` | Offset from base+0x48+44 to write target |
| `offset_to_0x120` | `0x48` | Always deterministic post-boot |
| `KCBTable+0x388` | Runtime | vftable pointer to overwrite |

---

## Empirical Heap Spray Analysis

As part of the Master's Thesis research, 20 controlled sessions were run across two spray configurations. Each session used a clean VM snapshot.

### Results

| Config | Holes | Theoretical probability/attempt | Observed average | Worst case |
|--------|-------|----------------------------------|-----------------|------------|
| `SPRAY_STEP=0x20` | 512 | 0.78% | **2.4 attempts** | 9 |
| `SPRAY_STEP=0x10` | 1024 | 1.56% | **2.44 attempts** | 8 |

### Key Finding

Doubling the number of holes (0x20 β†’ 0x10) produced **no statistically significant improvement** in observed success rate. The theoretical probability (0.78% vs 1.56%) diverges dramatically from the empirical rate (~41% first-attempt success on clean post-boot heap).

**Conclusion:** The DWM heap after system boot exhibits a **deterministic initial structure** that independently favors exploit success. The bottleneck is not hole density but the predictable LFH state, which places `CHolographicInteropTexture` objects in positions favorable to the overflow regardless of spray granularity.

This finding is documented in detail in [`docs/analysis/02-heap-spray.md`](docs/analysis/02-heap-spray.md).

---

## Post-Exploitation Output

On success, a CMD window opens displaying:
```
=====================================================
  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   Label         S-1-16-16384

  [*] Enabled privileges:
  SeImpersonatePrivilege    Impersonate a client after auth   Enabled

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

The banner section is displayed in **green** (via embedded PowerShell). The `whoami` section uses default terminal colors. An interactive CMD session remains open with a custom prompt. Artifacts (`s11.dll` and the `.bat` script) are automatically deleted after 5 seconds via a deferred cleanup process.

---

## Technical Documentation

| Document | Description |
|----------|-------------|
| [Root Cause Analysis](docs/analysis/01-root-cause.md) | Integer division bug in CCommandBuffer::Initialize |
| [Heap Spray Analysis](docs/analysis/02-heap-spray.md) | Empirical data from 20 sessions, statistical findings |
| [CVE Timeline](docs/analysis/03-timeline.md) | Discovery, disclosure, and patch chronology |

---

## 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
- DirectComposition API abuse for kernel interaction
- In-process API hooking without external tools
- Empirical analysis of heap spray reliability

**Keywords:** `EoP` Β· `Heap Overflow` Β· `DirectComposition` Β· `DWM` Β· `Windows Kernel` Β· `CVE-2024-30051`

---

## Author

**Annais Molina (devianntsec)** β€” Master's Student in Cybersecurity

[![GitHub](https://img.shields.io/badge/GitHub-@devianntsec-181717?style=flat-square&logo=github)](https://github.com/devianntsec)
[![LinkedIn](https://img.shields.io/badge/LinkedIn-Annais%20Molina-0077B5?style=flat-square&logo=linkedin)](https://linkedin.com/in/annais-molina-fuentes)
[![Email](https://img.shields.io/badge/Email-me%40deviannt.com-D14836?style=flat-square&logo=gmail)](mailto:me@deviannt.com)

---

## Acknowledgments

- [**Ricardo Narvaja (Fortra/CoreSecurity)**](https://github.com/fortra/CVE-2024-30051) β€” Original PoC and reverse engineering writeup
- [**Kaspersky GReAT**](https://securelist.com/cve-2024-30051/112954/) β€” Original vulnerability discovery and responsible disclosure
- [**Microsoft MSRC**](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-30051) β€” Patch KB5037771 (May 2024)

---

## License

MIT License β€” see [LICENSE](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.


  Β© 2026 Annais Molina Β· Master's Thesis in Cybersecurity
  UCAM Universidad CatΓ³lica San Antonio de Murcia Β· Campus Internacional de Ciberseguridad