SignDrop: How Windows CLFS Protection Was Turned into Full SYSTEM Rights

On Tuesday, November 10, 2026 — the same day Microsoft shipped its planned November security updates — researcher Abdelhamid Naceri (known under the pseudonyms MSNightmare, Nightmare Eclipse, and Chaotic Eclipse) published an exploit on GitHub called SignDrop. It's a local privilege-escalation vulnerability in the Common Log File System (CLFS) driver — a kernel-mode Windows component.

SignDrop's key feature is that it doesn't target CLFS itself but the log-file authentication mechanism Microsoft added precisely to stop CLFS exploitation. "Everything Microsoft did was done right, but the logic itself allows abuse," the researcher wrote in the technical breakdown.

At publication, Microsoft had not confirmed the vulnerability, assigned no CVE, and shipped no fix. The exploit was tested on Windows 11 26H2, an experimental Windows 11 26H2 build, and Windows Server 2025. Per the researcher's own estimate, about 80% of Windows installations worldwide may be vulnerable.

What CLFS is and why it's constantly attacked

The Common Log File System is a built-in Windows logging subsystem that stores records in structured "containers" and "log files." It runs in kernel mode (clfs.sys) and parses complex binary structures — which is why it historically became a favorite target for privilege-escalation attacks.

The problem's scale is telling: CISA's Known Exploited Vulnerabilities (KEV) catalog lists ten CLFS vulnerabilities confirmed exploited in real attacks. One — CVE-2025-29824 — was used in ransomware campaigns in April 2025: attackers escalated via CLFS, dumped the SAM/SYSTEM/SECURITY registry hives, and created their own admin user.

CLFS exploitation history is rich with concrete episodes. The CVE-2025-29824 attack was recorded by the Microsoft Threat Intelligence Center — a rare case of ransomware operators using a privilege-escalation 0-day (Symantec linked the activity to the Play group). A year earlier, in 2024, the CLFS flaw CVE-2024-26169 was tied to Black Basta, and in 2025 another actively exploited flaw CVE-2025-32701 (use-after-free) enabled escalation to SYSTEM. The common thread: these attacks turn a modest standard-user account into full host control, then disable defenses and deploy the main payload.

Why is CLFS so "rewarding" to exploit? The driver must parse data partly controlled by an ordinary user — log files can be created without any special rights. The slightest structure-parsing error becomes kernel memory corruption, and from there, code execution with SYSTEM privileges.

How Microsoft tried to close CLFS

To curb this attack surface, from October 28, 2025 Microsoft began rolling out CLFS log-file authentication in the release channel — for Windows 11 25H2, 26H1, and Windows Server 2025.

The protection's essence: a hash-based message authentication code (HMAC) is added to every log file, built from the log data and a machine-unique key. The driver then parses only the log files it wrote itself — rejecting foreign or forged ones. Beside each log, a companion file with the .cnpf extension stores recovery data, created with the same security attributes as the original.

Rollout happened in two stages. The first 90 days the system runs in learning mode, gathering info about legitimate log files. After that period, the driver automatically switches to enforcement mode, where every log file must carry a valid authentication code.

It's precisely this protection — meant to nullify CLFS exploitation — that became SignDrop's target. After the mitigation's introduction, the number of publicly exploited CLFS vulnerabilities dropped sharply — but the mitigation itself, it turns out, brought a new vulnerability.

Technical breakdown: how SignDrop works

The vulnerability lies in how clfs.sys handles creation of the .cnpf authentication file. Naceri describes the key behavior: if a new associated container file is empty, CLFS will try to sign it regardless of whether the signature file exists.

The exploitation chain:

1. Preparation. An ordinary user (no admin rights) creates a CLFS log and container with paths they control.
2. Forcing the open. Opening the log file requires no special flags in the NtCreateFile call — the right path suffices. So the attacker "forces" a privileged process to open the prepared log.
3. Context shift. Since the log is now opened by a privileged process, not the original user, the companion file is created on that process's behalf — i.e., with SYSTEM rights.
4. Redirection. Using Object Manager symbolic links, the attacker redirects .cnpf file creation to a location they choose.
5. Write. The .cnpf file inherits the original log's DACL, so the ordinary user gains write access to it. Result: a file created as SYSTEM that an ordinary user can write to.
6. Escalation. This chains into launching a shell with SYSTEM privileges.

A technical detail making the attack possible: CLFS checks access rights correctly only when a process creates its own log files — then the OBJ_FORCE_ACCESS_CHECK flag is set and new objects stay in the creating process's context. But when a log file has an associated container, opening the original automatically opens the linked one — and at that moment the security context "slips" onto the privileged process. So the signed file is created not on behalf of the user who prepared the log, but of whoever opened it.

Windows Defender — an unwitting accomplice

An especially ironic element of SignDrop is the choice of "privileged process." In the published code, that role is played by Windows Defender (MsMpEng).

The attacker calls the signature-update RPC interface ServerMpUpdateEngineSignature. Defender, in its antivirus engine's context, opens the prepared CLFS container, follows the path recorded in the container, opens the associated file — and, if the signature file is absent, creates it with SYSTEM rights.

This means the security system's own mechanism is used against it. As the researcher notes, the same trick can apply against any antivirus engine or EDR: arbitrary file creation happens "in the context" of the protective process itself, so from its kernel drivers' perspective the request looks legitimate and passes self-defense / tamper protection. This makes the vulnerability unique — it can, among other things, disable antivirus and EDR.

Who's vulnerable and how to check

An important caveat: SignDrop is local privilege escalation. The attacker first needs access to the machine as a standard user — via phishing, stolen credentials, a remote-code-execution flaw, or another vector. SignDrop turns that "limited" access into full system control.

You can check whether your system falls in the claimed blast radius via the registry. Open the key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication

and look at the Mode value:

• 0 (enforcement mode) or 1 (learning mode) — per the researcher, the system is vulnerable;
• 2 or 3 — mitigation disabled, and the system falls outside the claimed attack.

Because ~90 days after installation the system auto-switches from learning to enforcement mode, the typical configuration of "settled" installations is exactly what the exploit targets. Naceri puts it bluntly: "you're generally vulnerable if your Windows installation is over 90 days old," adding wryly that "it's safe to assume everyone reading this is vulnerable." The practical consequence for admins: if Mode is 0 or 1, assume the system is in the blast radius and prepare for an out-of-band update.

Why disabling the protection is a bad idea

Formally, disabling the mitigation (Mode 2 or 3) removes SignDrop's attack path. But both the researcher and Microsoft's documentation warn against it: disabling forces CLFS to parse unverified log files again, reopening the very memory-corruption vulnerabilities the protection was meant to stop.

In other words, it's a choice between two bad options, and "disable the protection" is no solution. Naceri summarizes: "for now, unfortunately, disabling the mitigation exposes your machine to memory-corruption vulnerabilities, because CLFS still handles log files poorly — that's why this mitigation exists at all. So for now the only way out is to wait for a Microsoft patch."

How to protect yourself

Since no official fix exists yet, practical steps reduce to process-level risk reduction and monitoring.

1. Watch MSRC. The official place Microsoft's response will appear is the Security Update Guide (msrc.microsoft.com/update-guide). The moment a patch ships, install it out-of-band.
2. Shrink local-access surface. Since the exploit needs a standard-user account, it's critical to limit an attacker's ability to get such access: least privilege, MFA, staff anti-phishing training. More on basic hygiene in our "Cybersecurity: learning" material.
3. Don't disable the CLFS mitigation. As explained, disabling log-file authentication (Mode 2/3) reopens old memory-corruption flaws. Leave it at 0 or 1.
4. Monitor anomalies. Watch for unexpected signature-update RPC calls, .cnpf file creation in atypical locations, and Object Manager symlink manipulations. Experienced teams can cover this with EDR/SIEM rules.
5. Segment and update. Keep systems current (latest cumulative updates, including November's from the 10th) and segment the network so compromising one workstation doesn't open a path to critical servers.

Conclusion

SignDrop is a telling example of how even a well-thought-out protection mechanism can become an attack vector. Microsoft made CLFS noticeably safer, but a gap remained in the very logic of authentication-file creation — allowing a privileged process to create a file as SYSTEM in an attacker-controlled location.

For now the vulnerability has neither CVE nor patch, but the exploit is already public — meaning the window between PoC publication and in-the-wild attacks could be short. For Ukrainian organizations, where Windows dominates both workstations and servers, the key now is not to panic but also not to delay: watch MSRC, keep systems updated, and tighten local-access control. The moment Microsoft ships a fix, it becomes an out-of-band priority for every security team.