Deep dive into CVE‑2025‑29824 in Windows
clfs.sys driver vulnerability that allows attackers to escalate privileges within the operating systemOn April 8, 2025, Microsoft patched 121 vulnerabilities across its products, including CVE-2025-29824—the only one known to be exploited in the wild. This particular flaw enabled adversaries to escalate Windows privileges by leveraging a bug in the clfs.sys driver. Microsoft Threat Intelligence discovered the issue during the Storm-2460 attacks targeting organizations in Saudi Arabia, Spain, Venezuela, and the United States. By exploiting CVE‑2025‑29824, the threat actor was able to escalate its privileges to NT AUTHORITY\SYSTEM to perform lateral movement and encrypt victims’ files.
The CVE-2025-29824 exploit was executed from the dllhost.exe address space and employed conventional post-exploitation methods. To retrieve kernel-space addresses, the adversaries used NtQuerySystemInformation. For privilege escalation, they invoked RtlSetAllBits within the kernel, enabling all process privileges by traversing EPROCESS structures.
Since the exploit relied on the clfs.sys driver, the attackers created the file C:\ProgramData\SkyPdf\PDUDrv.blf.
After gaining escalated privileges, they proceeded to inject their payload first into the winlogon.exe address space, then into procdump.exe, and finally into the dllhost.exe address space. The latter was launched via the following command:
C:\Windows\system32\dllhost.exe -accepteula -r -ma lsass.exe c:\programdata\[random character combination]
These steps enabled the extraction of LSASS memory data, ultimately leading to the theft of Windows user credentials. With SYSTEM-level access, the attackers used RansomEXX to encrypt files within the compromised system. This ransomware was also launched through dllhost.exe:
C:\Windows\system32\dllhost.exe --do [path to RansomEXX]
According to the official Microsoft website, the vulnerability stems from manipulating allocated heap memory after it has been freed. If exploited, this could allow an attacker to escalate its privileges in Windows OS.
clfs.sys overview
clfs.sys is a Windows kernel-mode driver responsible for logging information into BLF (Base Log File) files. It was introduced in 2005 with the release of Windows Server 2003 R2. As a kernel‑space component, clfs.sys is required for the proper functioning of certain other drivers. For example, the Transaction Manager (tm.sys) relies on it for transaction logging with rollback support.
The diagram below shows the tm.sys functions imported from clfs.sys.
The clfs.sys driver has its own API (clfsw32.dll) that provides user-mode access. For instance, CreateLogFile can be used to create a primary log file, while AddLogContainer allows adding a container with data. The driver can also be accessed via IOCTL, which is implemented in Windows through the NtDeviceIoControlFile function. A file descriptor can be created using NtCreateFile.
Recently, clfs.sys—along with afd.sys and win32k.sys—has become a popular target for adversaries. Vulnerabilities in these drivers are frequently exploited in the wild during various attack campaigns.
As mentioned in one of our previous articles, users can employ Winbindex to download different Windows file versions. In this case, we retrieved those incorporating the April (April 8) and March (March 11) security updates.
Using BinDiff to compare the two files, we discovered that only a few functions had been modified. The primary changes affected CClfsRequest::Close and CClfsLogCcb::Cleanup, both of which are called when closing the log file descriptor.
In its security updates, Microsoft introduced a new function Feature_[number]__private_IsEnabledDeviceUsage. We believe this was added to ensure that devices can be rolled back to their original state in the event of issues during patch installation.
The decompiled code of CClfsRequest::Close is as follows:
The updated code of CClfsLogCcb::Cleanup, which is invoked from within CClfsRequest::Cleanup, is as follows:
When the file descriptor is closed, the kernel sends two I/O requests to the driver: IRP_MJ_CLEANUP for cleanup and IRP_MJ_CLOSE for closing the file. These requests are processed as follows:
This sequence is also illustrated in the diagram below:
It should be noted that IRP_MJ_CLEANUP and IRP_MJ_CLOSE cannot be invoked directly from user space. During IRP_MJ_CLEANUP, descriptor‑related operations can still be initiated from user space.
When analyzing the modified code, we discovered that the applied fix involved relocating the call to the CClfsLogCcb::Release function from CClfsLogCcb::Cleanup to CClfsRequest::Close.
CClfsLogCcb::Release decrements the reference count of CClfsLogCcb by one. If this count reaches zero, the destructor is invoked, and the allocated memory is freed:
However, since the memory allocated for CClfsLogCcb has already been freed during the IRP_MJ_CLEANUP I/O request, it becomes possible to invoke an IOCTL call that uses the previously freed CClfsLogCcb. This can lead to memory corruption within the kernel.
One of the functions that uses CClfsLogCcb is CClfsRequest::StartArchival:
For the vulnerability to be successfully triggered, the execution chain must follow the sequence shown below:
Notably, the memory is freed via LookasideList:
So, if the number of freed objects does not exceed the depth of LookasideList, which is 24, an object is not immediately released. Instead, it is marked respectively within the list. Therefore, to exploit the vulnerability, an adversary must first create at least 25 descriptors for the same log file, then close 24 of them to fill LookasideList, and finally trigger the exploit using the remaining descriptors.
If this sequence is successfully executed, the freed memory remains available in the kernel address space and may be reallocated for another object of the same size. The clfs.sys driver will treat such object as a valid CClfsLogCcb instance. Further exploitation involves manipulating this new object through clfs.sys.
In recent years, clfs.sys has become an increasingly popular target for cybercriminals. They are leveraging zero-day vulnerabilities in this and other drivers to escalate privileges and conceal post‑exploitation activities. In the second part of the joint research article, experts from Kaspersky detailed the malware’s implementation. Defending against such attacks is particularly challenging, as even the latest software versions may remain vulnerable.
To mitigate these threats, we recommend using advanced security solutions that not only prevent attacks but also log malicious activity. EDR tools, for instance, enable both early and post-exploitation detection of suspicious behavior, significantly increasing the chances of preventing financial damage. Additionally, to stand up to attacker threats, organizations should ensure timely software updates and conduct regular penetration testing.