SignDrop PoC turns Windows CLFS auth feature into SYSTEM access

A newly published proof-of-concept called SignDrop turns a Windows security feature into a local privilege-escalation primitive, taking a standard user to SYSTEM and — because the PoC drives it through Microsoft Defender's own service — bypassing endpoint tamper protection on the way. The code and write-up are on GitHub from researcher Abdelhamid Naceri (also known as Nightmare Eclipse). It was released on November 10, the same day as Microsoft's November Patch Tuesday. Microsoft has not assigned a CVE, and there is no fix. This is an unpatched zero-day, though no in-the-wild abuse has been reported and it is not in CISA's KEV catalog.

What the bug does

The target is the Common Log File System driver, clfs.sys. In October 2025, Microsoft added a log-authentication mitigation to Windows 11 25H2/26H1 and Windows Server 2025: when CLFS creates a log, it writes a companion .cnpf authentication file alongside it, inheriting the log's security attributes. SignDrop abuses the ordering. A standard user prepares a CLFS log and container, then uses Object Manager symbolic links to redirect where the .cnpf file lands. When a privileged process later opens the prepared log, clfs.sys creates the companion file in that process's SYSTEM context — but at the attacker-chosen path, leaving a SYSTEM-owned file the standard user can write. Naceri's PoC triggers the privileged open through Defender's antimalware update interface, which is also why he says the technique "can be used to turn off any antivirus/EDR."

Affected configurations

Per BleepingComputer and The Hacker News, Naceri tested Windows 11 26H2, a Windows 11 26H2 Experimental build, and Windows Server 2025 Experimental. Independent testing was reported by Heewon Song of 78researchlab's PurpleHound team. A machine is in scope when the CLFS authentication mode is set to 0 or 1; modes 2 and 3 disable the mitigation and fall outside the claimed attack surface. Naceri estimates roughly 80% of Windows installs are exposed.

Check your exposure

Read the CLFS authentication mode from the registry — a value of 0 or 1 means the machine is in scope:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode

Action checklist

1. Confirm exposure with the registry key above across your fleet.
2. Don't disable the CLFS mitigation as a workaround. Turning it off re-opens the memory-corruption attacks it was built to stop. Wait for a Microsoft patch.
3. Watch EDR self-defense. The PoC disables tamper protection via the Defender update path; alert on unexpected manipulation of the antimalware service and on .cnpf files created outside expected log directories.
4. Prioritize the LPE context. This needs local code execution first — it is a post-foothold escalation, so treat it as a chaining risk behind phishing and initial-access bugs, not an internet-facing exposure.

Context

CLFS is one of the most reliably exploited corners of the Windows kernel — a steady stream of CLFS elevation-of-privilege bugs has shipped in Patch Tuesdays and shown up in ransomware playbooks. SignDrop is notable because it doesn't attack the old clfs.sys parsing surface; it attacks the mitigation Microsoft added to harden it, dropping on Patch Tuesday with no CVE and no fix. Until Microsoft responds, the registry check and EDR tamper-protection monitoring are the only levers defenders have.