Threat reportVulnerabilityTL-2026-5838
SignDrop: Unpatched Windows CLFS Zero-Day Enables Local Privilege Escalation to SYSTEM (No CVE)
A public proof-of-concept for SignDrop, an unpatched logic flaw in the Windows Common Log File System driver (clfs.sys), was published on GitHub on 2026-11-10 by the researcher MSNightmare (Chaotic Eclipse / Nightmare-Eclipse). It lets a standard user obtain NT AUTHORITY\SYSTEM by abusing CLFS authentication-file (.cnpf) creation.
Key facts
| Identifiers | TL-2026-5838, CVE-2025-29824 |
|---|---|
| Also known as | SignDrop, SigDrop |
| Severity | HIGH |
| Exploitation status | Linked CVE exploited in the wild; Listed in CISA KEV: CVE-2025-29824 (added ) |
| EPSS | CVE-2025-29824: 13.9% (96.4th percentile) |
| Affected products | Microsoft Windows 11; Microsoft Windows Server |
| Weaknesses (CWE) | CWE-59, CWE-276 |
| MITRE ATT&CK techniques | T1106 Native API, T1211 Exploitation for Stealth, T1222.001 Windows Permissions, T1559 Inter-Process Communication, T1685 Disable or Modify Tools |
| Motivation | UNKNOWN |
| Target sectors | technology, government administration, finance, health, manufacturing |
| Target regions | Global |
| Detection rules | 9 (1 shown free) |
| Sources | 8 cited sources |
Detection coverage
As of 2026-11-12, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5838 across Splunk SPL, Microsoft KQL and Sigma, covering 9 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.
Free detection: SignDrop CLFS LPE — Defender Engine Creates .cnpf Authentication File (Exploitation)
TL-2026-5838 SignDrop (no CVE, unpatched clfs.sys logic flaw). Per the public PoC write-ups, the exploit coerces the Microsoft Defender engine through the RPC method ServerMpUpdateEngineSignature to open an attacker-prepared CLFS container; CLFS then signs the empty container and creates the missing .cnpf authentication file in the privileged context, with the DACL inherited from an attacker-controlled path. Defender processes (MsMpEng.exe, NisSrv.exe, MpCmdRun.exe) creating .cnpf files is the primary artifact named by sources and is not expected in normal operation. Sources are secondary and unverified; no in-the-wild use reported.
- Languages: Splunk SPL, Microsoft KQL, Sigma
- ATT&CK: T1068, T1222.001, T1211, T1559
- Data sources: sysmon, microsoft_defender_for_endpoint, windows_defender_operational
- Severity: high
- Confidence: medium
Splunk SPL
index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11 TargetFilename="*.cnpf" earliest=-24h
```SignDrop TL-2026-5838: Defender engine coerced via ServerMpUpdateEngineSignature creates a CLFS .cnpf file as SYSTEM```
| where match(Image, "(?i)(msmpeng|nissrv|mpcmdrun)[.]exe$")
| stats count AS cnpf_creates min(_time) AS first_seen max(_time) AS last_seen values(TargetFilename) AS cnpf_files values(User) AS file_user BY host, Image
| convert ctime(first_seen) ctime(last_seen)
| table host Image file_user cnpf_creates cnpf_files first_seen last_seenMicrosoft KQL
DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType == "FileCreated"
| where FileName endswith ".cnpf"
| where InitiatingProcessFileName in~ ("MsMpEng.exe", "NisSrv.exe", "MpCmdRun.exe")
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessAccountName, InitiatingProcessCommandLine, InitiatingProcessParentFileNameSigma
title: SignDrop - Microsoft Defender Engine Creates CLFS .cnpf Authentication File
id: 3f1c2a64-8b7e-4d19-a5c3-6e0b9d21f4a1
status: experimental
description: Detects Microsoft Defender engine processes creating a CLFS .cnpf authentication file, the artifact reported for the unpatched SignDrop clfs.sys local privilege escalation (TL-2026-5838)
references:
- https://github.com/MSNightmare/SignDrop
- https://cybersecuritynews.com/windows-signdrop-zero-day-exploit/
- https://www.microsoft.com/en-us/security/blog/2025/04/08/exploitation-of-clfs-zero-day-leads-to-ransomware-activity/
author: Threadlinqs Team
date: 2026-11-12
tags:
- attack.privilege-escalation
- attack.t1068
- attack.defense-evasion
- attack.t1222.001
- attack.t1211
- attack.execution
- attack.t1559
logsource:
category: file_event
product: windows
detection:
selection:
TargetFilename|endswith: '.cnpf'
Image|endswith:
- '\MsMpEng.exe'
- '\NisSrv.exe'
- '\MpCmdRun.exe'
condition: selection
falsepositives:
- Unknown - Defender is not expected to create CLFS .cnpf files; validate against a baseline of your own fleet
level: high
Known false positives:
- Undocumented Defender or CLFS-based Microsoft component behaviour on specific platform builds that legitimately writes .cnpf files
- Security-product testing or Defender platform update activity on lab hosts
Tuning notes: Confirm Sysmon EventCode 11 (FileCreate) covers *.cnpf in your Sysmon config and adjust index=windows to your Sysmon index. Baseline .cnpf creation for 7 days across the fleet, then add exclusions only for confirmed benign Image plus TargetFilename pairs. Kernel-originated creates may log Image as System; see TL-2026-5838-KQL-001 for the path-based variant.
- SignDrop LPE — CLFS [indicator] Authentication File Created in User-Writable Path (Exploitation) · unlock with TL Creds
- SignDrop LPE — SYSTEM Process Launched from User-Writable Non-SYSTEM Parent (Post-Exploitation) · unlock with TL Creds
- SignDrop Context — Microsoft Defender Tampering or Protection Disabled (Defense Impairment) · unlock with TL Creds
- SignDrop LPE — CLFS .blf Log Created in User-Writable Path by Non-System Binary (Exploitation) · unlock with TL Creds
- SignDrop PoC Staging — SigDrop Source/Build Artifacts and Out-of-Place [indicator] (Post-Exploitation Tooling) · unlock with TL Creds
- SignDrop Context — CLFS ERROR_LOG_METADATA_CORRUPT Error in Windows Event Logs (Hunting) · unlock with TL Creds
- SignDrop LPE — SYSTEM Shell Spawned by Non-SYSTEM Parent (Post-Exploitation) · unlock with TL Creds
- SignDrop Context — CLFS Authentication Mode Set to Disabled (Defense Impairment) · unlock with TL Creds
Indicators of compromise
As of 2026-11-12, Threadlinqs Intelligence tracks 9 indicators of compromise for TL-2026-5838.
Technical analysis
As of 2026-11-11 there is no CVE, advisory or patch, Microsoft has not confirmed the claims, and no in-the-wild exploitation has been reported.
SignDrop is a local privilege escalation (LPE) in the Windows Common Log File System driver, clfs.sys. According to the researcher's README and secondary coverage, it is a logic flaw rather than a memory-corruption bug, and it abuses the CLFS authentication mitigation Microsoft introduced after CVE-2025-29824 (HMAC authentication codes over CLFS log files, using a per-system secret key; available in Windows 11 25H2 and Windows Server 2025 updates released on or after 2025-10-28). An attacker already executing code as a standard user is required; the flaw does not provide remote access on its own.
Reported exploit mechanics (claims by the researcher as relayed by GBHackers, Cyber Security News, All About Security and Daily CyberSecurity; not independently verified): when a log (.blf) is created through the exposed \\CLFS device, CLFS writes a companion authentication file with the .cnpf extension. The attacker attaches additional linked containers to the log using the documented AddLogContainer API at paths the caller chooses; the access checks pass because they run in the caller's context. When a different, more privileged process later opens the log, CLFS also opens the linked containers and, if a container is empty, signs it whether or not a signature file exists. The PoC induces Microsoft Defender to open the container via a call to the Defender RPC method ServerMpUpdateEngineSignature (the repository ships windefend.idl and generated RPC stubs) and uses object-manager symbolic links to redirect the path. CLFS then creates the missing .cnpf file in the privileged context, and the new file inherits the DACL of the original file, which the attacker controls. Chaining these steps is reported to yield a SYSTEM shell. The researcher additionally claims that because the file operation appears to originate from the antimalware engine, the primitive could be used to disable AV/EDR self-defense or tamper protection; this is unverified.
Exposure: the researcher states Windows systems whose HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode value is 0 (enforced) or 1 (learning) are vulnerable, while 2 (disabled by administrator) and 3 (disabled automatically) are not. Because CLFS runs a ~90-day learning period before enforcement, nearly any system older than 90 days is said to be in scope; the researcher's ~80% of Windows installations figure is an unmeasured estimate. Tested builds per the README: Windows 11 26H2, Windows 11 26H2 Experimental and Windows Server 2025 Experimental. Disabling CLFS authentication is NOT a safe workaround because it re-exposes the memory-corruption attack surface that earlier CLFS zero-days (e.g., CVE-2025-29824, exploited by Storm-2460 with PipeMagic to deploy ransomware) abused.
Context: the same researcher previously published related Windows LPE/Defender-abuse PoCs (RoguePlanet, ShieldBreak, MiniPlasma, ShieldCrash per Cyderes and other reporting), several leveraging Defender's own privileged operations and object-manager redirection. The repository (MIT license; SigDrop.cpp, SigDrop.rc, a Visual Studio project, hid.dll binary and windefend RPC interface files) publishes no hashes. Detection guidance from sources: unexpected .cnpf creation by Defender or other privileged processes, ERROR_LOG_METADATA_CORRUPT errors, unusual SYSTEM processes spawned from low-privilege sessions, and the CLFS Authentication Mode registry value. No network IOCs or C2 infrastructure are associated with this threat, so no BeaconBeagle correlation applies. Severity HIGH is analyst-assigned; no CVSS score has been published.
MITRE ATT&CK techniques by tactic:
Execution
T1106 Native API; T1559 Inter-Process Communication
Stealth
T1211 Exploitation for Stealth
defense-impairment
Defense Impairment
Remediation
Patches
- No vendor patch or CVE as of 2026-11-11; apply Microsoft's fix as soon as it ships
Immediate actions
- Do not disable CLFS authentication (HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode values 2/3) as a workaround; it re-exposes CLFS memory-corruption bugs
- Enforce least privilege and limit who can execute code as standard users on critical Windows systems
- Monitor for unexpected .cnpf file creation by Microsoft Defender or other privileged processes
- Monitor for ERROR_LOG_METADATA_CORRUPT CLFS errors and unexpected SYSTEM-context processes spawned from standard-user sessions
- Audit the CLFS Authentication Mode registry value across the fleet to inventory exposure
Workarounds
- None safe and officially available; restricting local code execution is the only compensating control
Longer-term hardening
- Deploy EDR with behavioral detection for object-manager symbolic link abuse and privileged-process file-creation anomalies
- Review detection content built for earlier CLFS privilege-escalation flaws such as CVE-2025-29824
- Watch the Microsoft Security Update Guide for a CVE and fix for this issue
Affected and fixed versions
Timeline
- Microsoft patches CLFS zero-day CVE-2025-29824, exploited by Storm-2460 with PipeMagic to deploy ransomware; this prompts the later CLFS authentication hardening.
- Microsoft's CLFS authentication mitigation (HMAC over log files, 90-day learning then enforcement) reaches the release channel for Windows 11 25H2 and Windows Server 2025.
- Per Cyderes, the first tool in the MSNightmare / Nightmare-Eclipse cluster of Windows exploit releases is published.
- Same researcher publishes the ShieldBreak Defender/Object Manager LPE PoC without coordinated disclosure (Cyderes report 2026-08-12).
- MSNightmare publishes the SignDrop PoC (MSNightmare/SignDrop) on GitHub, the same day as Microsoft's monthly security updates; no fix addresses it.
- Security press reports no CVE, advisory or patch, no Microsoft confirmation, and no in-the-wild exploitation.
- GBHackers publishes its analysis of SignDrop; status remains unpatched and unconfirmed by Microsoft.
Sources cited
- Exploitation of CLFS zero-day leads to ransomware activity (Microsoft Threat Intelligence, CVE-2025-29824) Microsoft · Vendor report · 2025-04-08
- AddLogContainer function (clfsw32.h) - Microsoft Learn Microsoft · Vendor report · 2025-10-07
- ShieldBreak Windows zero-day (Cyderes Howler Cell) - related research by the same researcher cyderes.com · Research · 2026-08-12
- MSNightmare/SignDrop - researcher PoC repository GitHub · Proof of concept · 2026-11-10
- New Windows SignDrop Zero-Day Exploit Allows Attackers to Gain SYSTEM Privileges (GBHackers) gbhackers.com · News · 2026-11-12
- Windows SignDrop 0-Day Exploit Lets Attackers Gain SYSTEM Privileges Through CLFS Protection (Cyber Security News) cybersecuritynews.com · News · 2026-11-11
- SignDrop: Ungepatchter Windows-Zero-Day nutzt Microsofts CLFS-Schutzmassnahme aus (All About Security) all-about-security.de · News · 2026-11-11
- SignDrop Windows CLFS Zero-Day Details and Proof-of-Concept Exploit Published (Daily CyberSecurity) securityonline.info · News · 2026-11-11
Other reports on CVE-2025-29824
Drafted by the Threadlinqs research pipeline from 8 sources; published ; last updated —.
