Five exploited-in-wild local privilege escalation vulnerabilities from a single kernel driver in three years. That’s not a run of bad luck. That’s a structural condition Microsoft keeps patching at the wrong scope.

The driver is clfs.sys. The vulnerability class is use-after-free. The patch cycle has addressed each instance and left the class intact.

What CLFS Is

The Windows Common Log File System driver manages structured binary log files — .BLF files — from kernel mode. It’s not optional infrastructure. Windows Event Tracing, the kernel transaction manager, and NTFS transactional logging all depend on it. It’s wired into the kernel’s own housekeeping.

The BLF format is a complex binary structure: containers, records, log blocks, internal offset tables, linked-list pointers, reference counts, version fields. All of it is deserialized in kernel context. The driver manages the full object lifecycle — creating log clients, appending records, marshaling and unmarshaling the binary structures, handling container pinning and record reference counting.

Here’s the problem: any local user can create a BLF file. Any local user can cause the kernel to parse it. The attack surface is always open, on every Windows machine, by design.

The Exploit Timeline

April 2022 — CVE-2022-24521. Use-after-free in CLFS. Lazarus Group had it weaponized and running operations before the patch shipped. Microsoft fixed the specific instance.

September 2022 — CVE-2022-37969. Another use-after-free in CLFS. Multiple threat actors were exploiting it in parallel by the time it hit Patch Tuesday. Microsoft fixed the specific instance.

February 2023 — CVE-2023-23376. Out-of-bounds write this time, same driver. Exploited in wild. Microsoft fixed the specific instance.

April 2023 — CVE-2023-28252. Use-after-free again. Nokoyawa ransomware, Lazarus-affiliated, used this one for deployment. The pattern is now established: a criminal group has an operational CLFS exploit, they run their ransomware campaign, the patch ships, and the timer resets. Microsoft fixed the specific instance.

April 2025 — CVE-2025-29824. Use-after-free. Storm-2460 is the attributed actor. RansomEXX. The fifth time a CLFS LPE has been found operating in the wild. Microsoft fixed the specific instance.

CVE-2025-29824: The Mechanics

The vulnerability is a use-after-free in log file parsing and manipulation. A kernel structure involved in log record management gets freed while the driver still holds a live reference. The attacker-controlled path to reach this condition requires only local logon — no additional privileges, no service accounts, nothing special.

Exploitation is standard use-after-free technique adapted for kernel mode: spray kernel objects to reclaim the freed memory with attacker-controlled data, use the resulting type confusion to corrupt a token or security descriptor, escalate to SYSTEM. Local user to SYSTEM in one shot.

Affected surface: Windows 10, Windows 11, Server 2019, Server 2022. Default configurations, no mitigations required, no additional setup. The full supported Windows fleet.

Storm-2460 and the Deployment Chain

Storm-2460 is financially motivated. Their operational chain for this campaign:

Initial access through whatever vector is available — phishing, exploitation of internet-facing services. Once they’re in at user privilege, CVE-2025-29824 gets them to SYSTEM. From there they drop certsteal.exe, a custom credential harvester targeting DPAPI-protected credential stores, Kerberos tickets, and certificate private keys. Harvested credentials enable lateral movement. RansomEXX and INC ransomware deploy as SYSTEM for maximum filesystem access.

The choice of CLFS for the elevation step is not accidental. Ransomware operators need a reliable, weaponizable LPE that works on default configurations. CLFS has been delivering that repeatedly.

CLFS was also a component in PipeMagic campaigns running concurrently with Storm-2460. PipeMagic is a plugin-based malware framework — plugins loaded as encrypted blobs, communication over Windows named pipes. The same CVE-2025-29824 capability was apparently available across multiple actor groups simultaneously. When a single LPE works reliably enough that independent operators converge on it, the driver has become commodity infrastructure for the criminal ecosystem.

Why CLFS Keeps Producing These

The architecture of the problem is straightforward.

CLFS manages kernel objects with complex lifetime rules. Log containers can be pinned. Records carry reference counts. Log clients maintain session state. The driver must handle creation, access, and teardown across all these object types while managing memory in kernel context.

The BLF format it parses is not a simple flat structure. It has internal pointers. It has version fields the parser must handle. It has linked structures with cross-references. The parser must handle all of this correctly, including edge cases — and the input to that parser is attacker-influenced, because any local user can construct a BLF file.

Use-after-free bugs in this context arise from edge cases in object lifetime management. A log record freed while a reference still exists. A container unmapped while the driver holds a pointer. A session structure torn down while an in-flight operation still touches it. There are many ways to produce the condition in a complex object model with kernel-mode memory management.

Microsoft has patched five specific instances of this condition. In each case, they identified the specific code path producing the UAF and closed it. The architectural relationship — user-influenced binary input driving complex kernel-mode object lifecycle with direct SYSTEM-level consequences — has not changed.

Two approaches would address the class rather than the instance: sandbox the CLFS parser so a UAF has limited consequence rather than a straight path to SYSTEM, or redesign the BLF lifecycle model to eliminate the conditions that produce UAF in the first place. Neither of these has happened.

The result is a predictable pattern. The driver gets exploited. The patch addresses the instance. The class remains. The timer resets. Three to twelve months later, a threat actor shows up with a new instance.

The Patch Problem

The argument that this is difficult to fix is not wrong. Sandboxing a kernel parser is non-trivial work. Redesigning an object lifecycle model that other kernel subsystems depend on is a significant engineering commitment. These are real constraints.

The argument that the current approach is sufficient is contradicted by five consecutive exploit-in-wild CVEs from the same driver in 36 months. Nokoyawa ran ransomware operations on a CLFS LPE. RansomEXX ran operations on the next one. These are not nation-state actors burning zero-days for intelligence collection — these are financially motivated criminal operators running commodity ransomware campaigns. They are using CLFS because it is reliable and it works.

The driver will produce another exploited instance. The timeline on the previous five is roughly six to twelve months between events. The patch for CVE-2025-29824 shipped April 2025. The architectural conditions are unchanged.

The fix keeps being the wrong scope.

PGP signature: clfs-ransomwares-favorite-kernel-driver.md.asc — Key fingerprint: 5FD2 1B4F E7E4 A3CA 7971 CB09 DE66 3978 8E09 1026