SignDrop: A Public Windows CLFS Exploit to SYSTEM With No CVE and No Patch. Do Not Turn Off the Mitigation. Hunt for Defender Writing hid.dll Into the Ink Folder Instead
There is no patch for SignDrop, so do two things today: leave the CLFS authentication mitigation on, and turn on an alert for any process creating a file named hid.dll in C:\Program Files\Common Files\microsoft shared\ink, above all when the creating process is the Defender engine, MsMpEng.exe. That file write is the step in the public exploit where a standard user becomes SYSTEM, and it is the cleanest thing to hunt until Microsoft ships a fix.
What is confirmed
On Tuesday, November 10, 2026, the same day as Microsoft's November Patch Tuesday, the researcher who publishes as Nightmare Eclipse posted a repository called SignDrop under the GitHub handle MSNightmare. GitHub's API shows the repository created at 19:20 UTC that day and last changed at 23:53 UTC. We read the README and the exploit source directly.
The researcher's description, in his words: "The specific flaw exist in clfs.sys in the way how it handle the creation of the authentication file \".cnpf\"". CLFS, the Common Log File System driver, gained an authentication check for its log files in a 2025 update. Microsoft's support article describes a 90-day learning period after which "the driver will automatically transition into enforcement mode on its next start". The researcher's point is that this mitigation added a new step, writing a companion signature file ending in .cnpf, and that step can be abused.
How, per the README: a standard user builds a CLFS log and an associated container in a folder the user controls, then uses object manager symbolic links so that a privileged process opens that log. When it does, CLFS creates the missing .cnpf file in the privileged process's security context, and the README says "CLFS will always create the new authentication file with the original file DACL". The result is a file created by SYSTEM that the standard user can still write. In the published code the privileged process is Microsoft Defender, coerced over its local RPC interface through a function the researcher names ServerMpUpdateEngineSignature. The researcher's summary: "Everything is done properly by Microsoft here but the logic allows abuse."
Builds the researcher says he tested: "windows 11 26H2, Windows 11 26H2 Experimental, Windows Server 2025 Experimental". He gives no build numbers.
Who is in scope, per the README: machines where the registry value Mode under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication is 0 or 1. Values 2 or 3 are out of scope. Because learning mode turns into enforcement on its own after 90 days, most established installs are in scope.
Prerequisites, from the README, the source and The Hacker News: a local standard user account, the CLFS mitigation in learning or enforcement mode, and Microsoft Defender running, since the published chain uses Defender as the privileged process.
Microsoft's position: The Hacker News reports that Microsoft "has not confirmed the claimed flaw, assigned a CVE, or released a fix", and that nothing for it appeared in the November security updates. SignDrop is not in CISA's Known Exploited Vulnerabilities catalog as of catalog version 2026.11.10, which we checked against the CISA JSON. Neither outlet reports exploitation in the wild.
What is not known
Whether it works reliably. The Hacker News reports that Heewon Song of PurpleHound, the offensive team at 78researchlab, confirmed the exploit works but judged it not reliable enough for operational use. That is one independent test, reported second-hand. BleepingComputer does not say it reproduced the exploit.
The "80%" figure. The README says "I guess estimate 80% of the world's windows installations are vulnerable". That is the researcher's own guess, with no population or method behind it. Treat it as a guess.
The anti-EDR claim. The README says the same trick "can be used to turn off any antivirus/EDR" because the file write appears to come from the security product's own process. Nobody we read has tested that against a product other than Defender.
Whether Defender detects it. Neither The Hacker News nor BleepingComputer names a Defender signature for SignDrop, and we found none published in the sources we read as of November 12. For an earlier exploit from the same researcher, RoguePlanet, Cyderes reported that Defender detected the compiled proof of concept as Exploit:Win32/DfndrRugPlnt.BB, and that small source changes defeated that signature. Expect the same here: a file-hash signature on the public build is not protection against a recompiled one.
Why a local bug matters
SignDrop gives nothing to an attacker who is not already on the machine. It is the second stage: the step after a phishing attachment, a stolen VPN login or a remote code execution bug has put code on a Windows endpoint as an ordinary user. CLFS has been that second stage many times. CISA's catalog lists 12 vulnerabilities whose name or description mentions the Common Log File System, from CVE-2019-1214 to CVE-2023-36424, which CISA added in April 2026. The authentication mitigation was Microsoft's answer to that run of bugs, which is why switching it off to dodge SignDrop is the wrong trade: the README itself says that disabling it "will expose your machine to memory corruption vulnerabilities as CLFS still does not handle log files well". Microsoft's mitigation article warns against it too.
What to do
Do not set the CLFS authentication Mode to 2 or 3. That trades a new, unreliable exploit for an old, well-exploited attack surface.
Alert on file creation of hid.dll in C:\Program Files\Common Files\microsoft shared\ink. The exploit source points its final symbolic link at that exact path, waits for a file named hid.dll to appear there, and then writes its payload DLL into it. The Hacker News reports, and a screenshot the researcher added to the repository shows, the Defender process creating the file. A file create in that folder by MsMpEng.exe is the strongest signal. Sysmon event 11 (FileCreate) or Defender for Endpoint's DeviceFileEvents table both record it. The source also issues a transacted delete of that file at the end, so do not count on finding it on disk afterwards: hunt the creation event, not the file. Compare against a known clean machine built from your own image before you write the rule, so you know what that folder normally holds.
Alert on CLFS log files created by Defender or other SYSTEM processes outside their normal locations. CLFS logs end in .blf and the new signature files end in .cnpf. The public build makes its working folder under the user's %TEMP% with a name starting SigDrop_. That name is trivial to change, so treat it as a tripwire for the unmodified build, not as the detection.
Watch for the process tail. The exploit kills any running on-screen keyboard, starts osk.exe hidden from the user's session, and at the end asks for an elevated conhost.exe. The Hacker News reports that after a successful run every UAC prompt opens both a standard user shell and a SYSTEM shell, which is noisy for anyone at the keyboard. A SYSTEM-level command shell whose parent chain begins in a standard user's interactive session is worth an alert on its own, SignDrop or not.
Check your fleet's CLFS Mode value so you know your exposure. Machines at 0 or 1 are in scope; that is most of them.
Do not run the public exploit on a production machine to "check". BleepingComputer passes on the researcher's suggestion that a SYSTEM shell means you are vulnerable. The registry value answers the same question without running an exploit.
Watch the Microsoft Security Response Center update guide for a CVE and fix, and treat the first stage as where you can still win: phishing defenses, MFA on remote access, and patching internet-facing services.
How we know, and what we did not do
We read the SignDrop README and the C++ source in the repository; quotes above are from them. Paths and process names in the hunting steps come from that source code, not from the press. The Hacker News and BleepingComputer both trace to that repository; The Hacker News adds the 78researchlab test. CISA catalog facts come from the KEV JSON, version 2026.11.10. The weekday for November 10 was checked against the calendar.
Our edge cannot see this. SignDrop is a local Windows driver bug with no network traffic: there is no HTTP path to match, so our edge sensors and honeypots have nothing to observe. That is a blind spot, not a clean result.
Indicators: none published in the sources we read. The repository ships the researcher's proof of concept, including a compiled hid.dll, and we did not add the researcher's own files to our feed as malicious. If a vendor publishes hashes of a weaponized build seen in an attack, that is a different matter and we will look at it then.
We have written about this researcher's work before. The September post, "Nightmare Eclipse Took Off the Mask and Dropped Another Defender Zero-Day", has the back story: https://www.dugganusa.com/post/nightmare-eclipse-took-off-the-mask-and-dropped-another-defender-zero-day-we-have-eighteen-posts-on. The LegacyHive thread from July shows the same pattern of a public exploit landing right after Patch Tuesday with no CVE: https://www.dugganusa.com/post/microsoft-shipped-570-fixes-tuesday-by-wednesday-its-serial-tormentor-dropped-a-windows-zero-day-wi and the follow-through when Microsoft patched it: https://www.dugganusa.com/post/four-weeks-ago-a-third-party-patched-legacyhive-because-microsoft-wouldn-t-yesterday-microsoft-ship
Sources
SignDrop repository, README and source (primary): https://github.com/MSNightmare/SignDrop
Microsoft, CLFS authentication mitigation: https://support.microsoft.com/en-us/servicing/os/windows/2025/03/common-log-file-system-clfs-authentication-mitigation
Microsoft, CLFS log file authentication (driver documentation): https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/clfs-authentication
The Hacker News: https://thehackernews.com/2026/11/new-signdrop-zero-day-exploit-turns.html
BleepingComputer: https://www.bleepingcomputer.com/news/security/new-windows-signdrop-zero-day-gives-hackers-system-privileges/
Cyderes on RoguePlanet and the Defender signature for it: https://www.cyderes.com/howler-cell/rogueplanet-windows-zero-day
CISA Known Exploited Vulnerabilities catalog (JSON): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
Microsoft Security Response Center update guide: https://msrc.microsoft.com/update-guide
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments