Key Findings
- SignDrop is a local privilege escalation from a standard user to NT AUTHORITY\SYSTEM targeting Microsoft's own CLFS authentication mitigation. The exploit was published on November 10, 2026, under the MSNightmare handle on GitHub. No coordinated disclosure, no CVE, no patch.
- The vulnerability turns a defense into an attack surface. Microsoft added HMAC-based authentication codes to CLFS log files specifically to block the class of logic bugs caused by improper validation of CLFS data structures, which accounted for 19 of 24 CLFS CVEs over five years. SignDrop abuses the signing mechanism itself: it forces clfs.sys to create a .cnpf signature file as SYSTEM in an attacker-controlled location, producing a privileged file-creation primitive at an attacker-selected path. Because the resulting file retains attacker-accessible security attributes, the exploit reopens it and replaces the CLFS-generated content with an embedded payload DLL.
- Microsoft Defender performs the privileged action on the attacker's behalf. The exploit calls Defender's signature update RPC interface to trigger a CLFS log open under SYSTEM context. Defender is both the bait handler and the unwitting accomplice, consistent with most prior Nightmare-Eclipse chains.
- SignDrop is a logic chain with no memory corruption. The exploit chains CLFS container creation through Object Manager symbolic links, an oplock synchronization barrier, privileged .cnpf file creation, ordinary file mapping to replace the resulting content, and DLL placement in the ink directory, ending in a payload that spawns conhost.exe as SYSTEM on the user's desktop while killing the UAC consent dialog. Every link is a legitimate Windows subsystem, a native Object Manager operation, or an internal Defender RPC interface.
- The researcher claims approximately 80% of Windows installations are vulnerable, covering systems with CLFS authentication in either enforcement mode (Mode 0) or learning mode (Mode 1, the adoption period for systems transitioning to the new format). That figure is unsubstantiated, but the exposure conditions are broad: any system where the registry key HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication exists with Mode set to 0 or 1 is in scope.
- Disabling the mitigation is not a viable remediation. The researcher notes that turning off CLFS authentication re-exposes machines to the older memory corruption primitives the mitigation was built to stop.
- No confirmed in-the-wild exploitation has been identified as of November 10, 2026. The PoC source code and a Visual Studio project are publicly available on GitHub.
- This is Howler Cell's ninth report on the Nightmare-Eclipse cluster, which now spans sixteen public zero-day releases across seven months.
- MITRE ATT&CK mapping: T1068 Exploitation for Privilege Escalation, T1574.001 Hijack Execution Flow: DLL, T1070.004 Indicator Removal: File Deletion, T1106 Native API.
The Researcher Behind SignDrop
Nightmare-Eclipse is a single researcher operating under a rotating set of handles. Current reporting attributes Nightmare-Eclipse, Chaotic Eclipse, Infinite Nightmare, and MSNightmare to the same person, with prior Howler Cell coverage recording Dead Eclipse as well. The GitHub account is MSNightmare, with parallel mirrors on self-hosted Git servers at git.projectnightcrawler[.]dev and git.churchofmalware[.]org.
The first release dropped on April 3, 2026. Named releases to date include UnDefend, RedSun, BlueHammer, YellowKey, GreenPlasma, MiniPlasma, RoguePlanet, LegacyHive, GreatXML, ShieldBreak, the four-vendor batch covering CrowdStrike, NVIDIA, Avast, and Kaspersky, ShieldCrash, and now SignDrop. Sixteen tools in roughly thirty-one weeks, with the scope widening in each phase. The first wave targeted Defender and adjacent Windows components. The second broke through Defender patches as fast as Microsoft shipped them. The third shifted to third-party security vendors entirely. ShieldCrash, the prior release, was the first whose claimed primitive Howler Cell could not reproduce.
SignDrop marks a fourth phase. SignDrop targets a security mitigation inside the Windows kernel itself, one Microsoft built specifically to harden CLFS against the class of attacks that had produced nearly two dozen CVEs. The motivation still reads as grievance against vendor disclosure handling rather than financial gain, and the pattern is the same: design-level abuse of trusted functionality, chained out of legitimate operating system features, published without coordination. But the escalation from Defender features to kernel-level mitigations narrows the available vendor response. Microsoft cannot disable its own hardening. It must fix the logic.
This is the ninth report in Howler Cell's ongoing coverage of the Nightmare-Eclipse cluster. Prior installments: BlueHammer, RedSun, RoguePlanet, GreatXML, LegacyHive, ShieldBreak, the four-vendor batch (Nightmare Season), and ShieldCrash.
The significance for defenders is a public actor turning security mechanisms into attack surface faster than the vendor can close them. CLFS authentication exists because CLFS was a reliable source of privilege escalation bugs. When the hardening becomes the primitive, detection has to come from host telemetry that does not assume the hardened component, or the endpoint agent it calls into, is behaving as designed.
What SignDrop Claims
SignDrop targets the CLFS authentication mechanism Microsoft added to detect unauthorized modification of CLFS log file data structures. The design signs log files with HMAC-based authentication codes so that a tampered log fails validation, closing the class of logic bugs behind 19 of 24 CLFS CVEs over five years.
The researcher claims a standard user can reach NT AUTHORITY\SYSTEM on any system where CLFS authentication is active, in either enforcement mode (Mode 0) or learning mode (Mode 1), and estimates that approximately 80% of Windows installations are vulnerable. The researcher also states that disabling the mitigation is not a way out, because it re-exposes the older memory corruption primitives the mitigation was built to stop.
The released code leaves signed logs intact and forces clfs.sys to create the .cnpf signature file as SYSTEM at a path the attacker selects, then replaces the content of that file with a payload DLL. The primitive is a privileged file creation at an attacker-chosen path, converted into code execution through DLL sideloading.
|
Release |
SignDrop |
|---|---|
|
Researcher |
MSNightmare (Nightmare-Eclipse cluster) |
|
Published |
November 10, 2026, the same day as November Patch Tuesday |
|
Target |
CLFS authentication in clfs.sys, triggered through the Microsoft Defender signature update RPC interface |
|
Claimed primitive |
Local privilege escalation, standard user to NT AUTHORITY\SYSTEM |
|
Howler Cell reproduction |
SYSTEM shell obtained (Figure 1) |
|
CVE |
Not assigned as of publication |
|
Vendor status |
No patch, advisory, or public comment as of November 11, 2026 |
Intended Execution Chain
Figure 2 shows the chain as designed. Howler Cell's reproduction completed all five stages and produced a SYSTEM shell on the interactive desktop. Howler Cell assesses that consent.exe, started as SYSTEM by the exploit's "runas" request, is the privileged process that loads the planted hid.dll.
Technical Analysis
The Howler Cell Threat Research Team analyzed the publicly released proof of concept for SignDrop, published November 10, 2026. SignDrop is a local privilege escalation from standard user to NT AUTHORITY\SYSTEM that abuses the CLFS authentication mechanism Microsoft added to detect unauthorized modifications to CLFS log file data structures.
The chain follows the same five-stage shape established across the Nightmare-Eclipse cluster. The attacker stages content, gets a privileged component to engage with it, redirects the path the privileged component resolves, lets that component perform the privileged action, and collects the result. No memory corruption is involved. The chain combines legitimate Windows subsystems, native Object Manager operations, and an internal Defender RPC interface.
Stage 1. Setup
The exploit terminates any running instance of osk.exe (On-Screen Keyboard) and relaunches it hidden. It creates a temporary working directory at %TEMP%\SigDrop_<GUID> that auto-deletes when the exploit finishes.
A CLFS log file is created through the \CLFS device prefix, routing through the kernel's Common Log File System driver. Two Object Manager symbolic links are constructed in \BaseNamedObjects\Restricted\, each keyed to a freshly minted GUID. One redirects the CLFS container path to a file in the working directory. The second redirects the corresponding .cnpf signature file path the same way. A third symbolic link, created in Stage 2 after the bait file and oplock are in place, will redirect the Defender signature update directory path.
MITRE ATT&CK: T1106 Native API
Stage 2. Product Engaged
The exploit issues a DeviceIoControl (IOCTL 0x8007A808) to create CLFS containers through the symbolic links. The container path passed to CLFS resolves through the symbolic links in \BaseNamedObjects\Restricted\, which redirect into the attacker's working directory. CLFS follows the links and creates the container and the associated .cnpf signature file under the calling standard-user context.
If the .cnpf file does not appear, the system does not have CLFS authentication active and the exploit exits, reporting the machine is not vulnerable.
A bait file named MpEngine.dll is then staged in the working directory with an opportunistic lock. The oplock serves as a synchronization barrier: when Defender accesses the file, the oplock breaks, signaling that the product has engaged.
A worker thread calls Defender's signature update RPC interface (Proc42_ServerMpUpdateEngineSignature), pointing it at the working directory through a GlobalRoot path that traverses the third symbolic link. Defender opens the directory and accesses MpEngine.dll as SYSTEM.
MITRE ATT&CK: T1106 Native API, T1068 Exploitation for Privilege Escalation
Stage 3. Path Redirect
When the oplock breaks, the exploit deletes the bait file and redirects the third symbolic link. It originally pointed at the working directory. Now it is repointed to \BaseNamedObjects\Restricted, the parent directory in the Object Manager namespace. This means any further path component Defender resolves through the update directory link now lands in \BaseNamedObjects\Restricted\, exactly where the exploit is about to place its next two redirects.
A new symbolic link is created at \BaseNamedObjects\Restricted\mpasbase.vdm, pointing to the CLFS log file path. This is the load-bearing redirect. Defender's update process expects to find mpasbase.vdm, the signature database, at the path it was given. The symbolic link routes that access into the CLFS log instead.
The original .cnpf symbolic link is then destroyed and recreated with a new target: \??\C:\Program Files\Common Files\microsoft shared\ink\hid.dll. When the CLFS driver next creates or updates the signature file for this log, it will follow the link and write to the ink directory as SYSTEM.
MITRE ATT&CK: T1068 Exploitation for Privilege Escalation
Stage 4. Privileged Action
The exploit monitors C:\Program Files\Common Files\microsoft shared\ink\ for new files, watching specifically for hid.dll. When Defender's SYSTEM-context operation triggers the CLFS authentication mechanism, clfs.sys creates the .cnpf signature file. The symbolic link redirects that creation to hid.dll in the ink directory. The file is created by CLFS running in kernel context under SYSTEM privileges.
MITRE ATT&CK: T1068 Exploitation for Privilege Escalation
Stage 5. Outcome
The real hid.dll (Human Interface Device library) lives in C:\Windows\System32\ and is loaded by processes that interact with HID hardware: keyboards, touchscreens, and pen input. The exploit uses it as a sideloading target because the ink directory (C:\Program Files\Common Files\microsoft shared\ink) is referenced by accessibility and input components, and consent.exe loads from it when the On-Screen Keyboard is active.
The exploit opens the planted hid.dll with CREATE_ALWAYS in a retry loop, truncating the CLFS signature content. It extracts an embedded payload DLL from its own PE resources (IDR_DLL1), maps it into memory, and overwrites it with the payload. After replacing the CLFS-generated file with the embedded payload, the exploit invokes ShellExecute with the "runas" verb for conhost.exe. That request is the load trigger. The AppInfo service starts consent.exe as SYSTEM on the secure desktop, and with osk.exe running, consent.exe loads the planted hid.dll from the ink directory.
Howler Cell reversed the pre-compiled hid.dll payload shipped in the repository. The payload opens the interactive user desktop (WinSta0\Default) with full access, switches its thread to that desktop, and spawns C:\Windows\System32\conhost.exe as a new console process on it. The payload runs inside consent.exe on the secure desktop, so the desktop switch places the console where the user sees it, and conhost.exe inherits SYSTEM privileges.
The payload then enumerates running processes, searching for consent.exe (the Windows UAC consent dialog), and terminates every matching instance. This terminates the payload's own host along with any other consent.exe instance, so no elevation prompt remains on screen. The payload then calls ExitProcess.
The result is a SYSTEM-privileged conhost.exe console window on the user's interactive desktop with no visible UAC prompt. The SYSTEM shell does not come from the "runas" ShellExecute in the main exploit. It comes from the payload's own CreateProcessW. The main exploit's "runas" call and the payload's consent.exe kill work as a pair: one loads the payload into a SYSTEM process, the other removes the visible prompt.
After a two-second delay, the exploit terminates osk.exe and atomically removes the planted hid.dll from the ink directory using a transacted delete, cleaning the artifact from disk while the SYSTEM shell persists.
MITRE ATT&CK: T1574.001 Hijack Execution Flow: DLL, T1070.004 Indicator Removal: File Deletion
Howler Cell Reproduction
Howler Cell compiled and executed the proof of concept in a controlled environment.
The exploit was run from a standard user session. Every stage executed as described. The CLFS container and .cnpf signature file were created through the symbolic links, Defender engaged through the signature update RPC interface and broke the oplock, the redirects resolved, and clfs.sys created hid.dll in the ink directory under SYSTEM.
The chain completes. The payload replaced the CLFS-generated content, the consent.exe prompt was terminated, and a conhost.exe console running as NT AUTHORITY\SYSTEM appeared on the interactive desktop, as shown in Figure 1. The planted hid.dll was then removed by the exploit's transacted delete, leaving the SYSTEM shell running with the file-system artifact already gone.
That cleanup step is the detail that matters for response. By the time an analyst looks at the ink directory, the file is no longer on disk. Evidence of the write has to come from file creation, image load, and process creation telemetry captured at the time, not from a post-incident file sweep.
Affected Versions
The exploit targets the CLFS authentication mechanism controlled by the registry key HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication. Systems where Mode is set to 1 (learning) or 0 (enforcement) are in scope. Microsoft's documentation states that CLFS enters a 90-day learning period when the feature is first enabled, during which it signs log files as they open, and then transitions to enforcement mode. Systems older than 90 days with the feature active are typically in enforcement mode.
The researcher reports testing against Windows 11 26H2 and experimental builds of Windows 11 and Windows Server 2025. The researcher estimates 80% of Windows installations are vulnerable, though no data supports that figure. Even discounting the estimate, the exposure conditions are broad: the CLFS authentication feature ships enabled on current Windows versions and affects both client and server. Mode 0 or 1 indicates that CLFS authentication is active and satisfies one prerequisite identified by the author. The registry value alone does not establish that exploitation will succeed.
No CVE has been assigned. No patch exists. Microsoft has not commented publicly as of November 11, 2026.
Why SignDrop Matters
SignDrop is a meaningful escalation in a campaign that has not slowed. Prior releases in the Nightmare-Eclipse cluster centered on security products and the Windows components around them. SignDrop targets a security mitigation inside the Windows kernel, one Microsoft built specifically to close the class of logic bugs that accounted for 19 of 24 CLFS CVEs over the past five years. The method is the same: find a trusted component that performs a privileged action on a user-influenced path, and make it perform that action somewhere it should not. The target is harder to fix.
The irony is precise. CLFS authentication was Microsoft's answer to a well-documented attack surface. The mitigation signs log files to prevent tampering. SignDrop leaves the log files intact and abuses the signing operation itself, turning the creation of the integrity check into the privilege escalation primitive. The defense is the vulnerability.
The researcher's claim that disabling the mitigation re-exposes machines to the older attacks is the second half of that irony. Defenders cannot turn the feature off without reopening the surface it closed. A patch would likely need to change how CLFS resolves paths during signature file creation, which sits in kernel-mode code. Neither option appears straightforward.
The release timing follows the established pattern. November Patch Tuesday landed on November 10, 2026. SignDrop was published the same day, ensuring that the patch cycle could not include a fix and that defenders were processing both simultaneously. The same timing has appeared in June, July, August, and September releases.
Sixteen public zero-day releases from April 3 through November 10, 2026, is roughly one every fourteen days, and the scope continues to widen rather than consolidate. Organizations should expect further releases targeting Windows kernel mitigations, privileged driver operations, or other trust boundaries that run with elevated privileges, and should treat the presence of a privileged security mechanism as an attack surface to be monitored rather than a guarantee to be trusted.
Howler Cell assesses with high confidence that the public SignDrop code achieves local privilege escalation to SYSTEM on systems with CLFS authentication active, based on our own reproduction. We assess with moderate confidence that exposure is broad across current Windows client and server builds, and with low confidence in the researcher's 80% figure, which no published data supports. This assessment will be revised as Microsoft responds.
Detection and Hunting Opportunities
Coverage for this cluster starts before any host telemetry. Nightmare-Eclipse publishes without coordination and mirrors releases across GitHub and self-hosted Git servers. Monitoring those channels has consistently given lead time over vendor advisories in this lineage, and that time goes into hunt hypotheses rather than patch waiting.
On the host, the detection opportunities below are keyed to the five stages in Figure 2. None of them depend on Defender detecting the exploit, because Defender is the component the exploit uses to perform the privileged action.
|
Ref |
Chain stage |
Observable |
Detection or hunt opportunity |
|---|---|---|---|
|
A |
Stage 1. Setup |
osk.exe terminated and relaunched hidden by a user process. CLFS log created through the \CLFS device prefix inside %TEMP%\SigDrop_<GUID>. |
Hunt for osk.exe launched hidden by an unexpected parent. Flag CLFS log and container creation in user-writable temporary paths. The directory name is PoC-specific and useful only as a tripwire for the unmodified sample. |
|
B |
Stage 2. Product Engaged |
DeviceIoControl IOCTL 0x8007A808 to CLFS from a user process. Bait MpEngine.dll staged with an oplock in a user-writable directory. Defender signature update RPC (Proc42_ServerMpUpdateEngineSignature) called by a process outside the Defender service tree. |
Alert on the signature update RPC from any caller outside the Defender service tree. Flag MpEngine.dll created outside Defender installation paths. |
|
C |
Stage 3. Path Redirect |
Object Manager symbolic link creation and repointing under \BaseNamedObjects\Restricted\, including a link named mpasbase.vdm. |
Hunt for symbolic link churn under \BaseNamedObjects\Restricted\ correlated with Defender RPC activity. This also covers ShieldBreak, ShieldCrash, and future variants that route through the same namespace. |
|
D |
Stage 4. Privileged Action |
hid.dll created in C:\Program Files\Common Files\microsoft shared\ink by a SYSTEM-context write. |
Alert on any creation of hid.dll in the ink directory. The file does not ship there with Windows, so any appearance indicates a successful write regardless of variant. |
|
E |
Stage 5. Outcome |
SYSTEM-context conhost.exe on the interactive desktop. consent.exe loading hid.dll from the ink directory, then terminated shortly after a "runas" request. Transacted delete of hid.dll from the ink directory. |
Alert on consent.exe loading any DLL from the ink directory. Correlate SYSTEM conhost.exe creation with a recent hid.dll write or image load from the ink directory, and investigate the parent process and image-load chain. Hunt for consent.exe terminations not initiated by the user. |
Two of these carry the most signal today. A hid.dll creation in the ink directory and a Defender signature update RPC call from outside the Defender service tree are both rare enough in a typical estate to alert on rather than hunt. The RPC call fires early in the chain, before the privileged write. Symbolic link monitoring under \BaseNamedObjects\Restricted\ also applies to ShieldBreak and ShieldCrash, so environments that built coverage for those releases already have part of this.
What Defenders Should Do
Inventory CLFS authentication state across the estate. Query HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication on every host and record the Mode value. Mode 0 or 1 means CLFS authentication is active and the host meets the prerequisite the researcher identifies. The registry value alone does not establish that exploitation will succeed, but it defines the population to prioritize for detection coverage.
Do not disable the mitigation as a workaround. Turning off CLFS authentication re-exposes machines to the older memory corruption attacks it was built to stop. That trades a public logic bug for a well-documented bug class.
Restrict untrusted local code execution. Every release in the Nightmare-Eclipse cluster is a local privilege escalation, which requires an attacker to already hold a foothold on the host. Application control and script control reduce the population of attackers who can reach the vulnerable path at all.
Deploy the Table 2 detections now. Rows B through E key on behavior and system paths rather than the PoC's working directory or GUIDs, and will survive a renamed or recompiled variant. Row A is a tripwire for the unmodified sample only. Because the exploit deletes hid.dll after use, make sure file creation and image load telemetry from the ink directory is retained rather than relying on on-disk evidence.
Do not read the absence of a Microsoft advisory as resolution. As of publication, no CVE has been assigned, no patch exists, and Microsoft has not commented publicly. A fix will likely need to change how CLFS resolves paths during signature file creation in kernel-mode code.
Assume a follow-up. Sixteen public zero-day releases in roughly thirty-one weeks, with the scope widening from security products to kernel mitigations, is a cadence that does not support treating any single release as the end of the matter.
Conclusion
There is no patch, and disabling the mitigation is not a safe workaround. Behavioral detection against Defender signature update RPC calls from outside the Defender service tree, symbolic link activity under \BaseNamedObjects\Restricted\, hid.dll creation in the ink directory, and consent.exe image loads from that directory are the primary defensive controls until Microsoft ships a fix.
Cyderes Howler Cell is tracking MSNightmare's activity across this cluster. Findings will be updated as the situation develops.
Appendix
Zero-Day Proof of Concept
- hxxps[://]github[.]com/MSNightmare/SignDrop
- Claimed primitive: local privilege escalation from standard user to NT AUTHORITY\SYSTEM. Confirmed by Howler Cell reproduction.
- Working directory: %TEMP%\SigDrop_<GUID>, auto-deleted when the exploit finishes
- Object Manager links: GUID-named symbolic links and mpasbase.vdm under \BaseNamedObjects\Restricted\
- Bait file: MpEngine.dll in the working directory, held with an oplock
- CLFS IOCTL: 0x8007A808
- Defender RPC method: Proc42_ServerMpUpdateEngineSignature
- Planted DLL: C:\Program Files\Common Files\microsoft shared\ink\hid.dll, removed by transacted delete after execution
- Embedded payload resource: IDR_DLL1
Reproduction Artifacts
These are artifacts of the proof of concept running in a controlled environment, not adversary indicators.
References
- MSNightmare, SignDrop repository on GitHub
- SecurityOnline, "SignDrop Windows CLFS Zero-Day Details and Proof-of-Concept Exploit Published," November 11, 2026
- Microsoft Security Blog, Brandon Jackson, "Security mitigation for the Common Log Filesystem (CLFS)," August 27, 2024. Source of the 19-of-24 CLFS CVE figure and HMAC mitigation design.
- MSNightmare mirrors at git.projectnightcrawler[.]dev and git.churchofmalware[.]org
Related Nightmare-Eclipse Mirrors and Channels
These are researcher publication and distribution points, not adversary infrastructure.
Related Cyderes Howler Cell Coverage
- ShieldCrash: Testing the Claimed Microsoft Defender Zero-Day
- Nightmare Season: Nightmare-Eclipse Turns Its Zero-Days on CrowdStrike, NVIDIA, Avast, and Kaspersky
- ShieldBreak: The Windows Zero-Day That Breaks Microsoft's Own RoguePlanet Fix
- LegacyHive: The Windows User Profile Service Arbitrary Hive Loading Vulnerability
- GreatXML: Inside the Windows Zero-Day That Turns Defender's Offline Scanner Into a BitLocker Backdoor
- RoguePlanet: Windows Zero-Day That Weaponizes Defender's Own Quarantine Pipeline
- RedSun Zero-Day: When Defender Becomes the Delivery Mechanism
- BlueHammer: Inside the Windows Zero-Day That Turns Defender Against Itself
Stay informed with Howler Cell
Receive the latest Howler Cell news and research directly to your inbox.
