# 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. 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.

- **Published:** 2026-11-12T08:06:06Z
- **Last reviewed:** 2026-11-12T08:06:06Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5838
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5838.png
- **ID:** TL-2026-5838
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 (1 shown free below) · **IOCs:** 9
- **CVEs:** CVE-2025-29824

## Description

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

- T1222.001 Windows Permissions
- T1211 Exploitation for Stealth
- T1685 Disable or Modify Tools
- T1106 Native API
- T1559 Inter-Process Communication

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**SignDrop CLFS LPE — Defender Engine Creates .cnpf Authentication File (Exploitation)** (`TL-2026-5838-SPL-001`)

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

````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_seen
````

### Microsoft KQL

```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, InitiatingProcessParentFileName
```

### Sigma

```yaml
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.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- SignDrop LPE — CLFS [indicator] Authentication File Created in User-Writable Path (Exploitation) (locked: unlock with TL Creds)
- SignDrop LPE — SYSTEM Process Launched from User-Writable Non-SYSTEM Parent (Post-Exploitation) (locked: unlock with TL Creds)
- SignDrop Context — Microsoft Defender Tampering or Protection Disabled (Defense Impairment) (locked: unlock with TL Creds)
- SignDrop LPE — CLFS .blf Log Created in User-Writable Path by Non-System Binary (Exploitation) (locked: unlock with TL Creds)
- SignDrop PoC Staging — SigDrop Source/Build Artifacts and Out-of-Place [indicator] (Post-Exploitation Tooling) (locked: unlock with TL Creds)
- SignDrop Context — CLFS ERROR_LOG_METADATA_CORRUPT Error in Windows Event Logs (Hunting) (locked: unlock with TL Creds)
- SignDrop LPE — SYSTEM Shell Spawned by Non-SYSTEM Parent (Post-Exploitation) (locked: unlock with TL Creds)
- SignDrop Context — CLFS Authentication Mode Set to Disabled (Defense Impairment) (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [New Windows SignDrop Zero-Day Exploit Allows Attackers to Gain SYSTEM Privileges (GBHackers)](https://gbhackers.com/new-windows-signdrop-zero-day/)
- [MSNightmare/SignDrop - researcher PoC repository](https://github.com/MSNightmare/SignDrop)
- [Windows SignDrop 0-Day Exploit Lets Attackers Gain SYSTEM Privileges Through CLFS Protection (Cyber Security News)](https://cybersecuritynews.com/windows-signdrop-zero-day-exploit/)
- [SignDrop: Ungepatchter Windows-Zero-Day nutzt Microsofts CLFS-Schutzmassnahme aus (All About Security)](https://all-about-security.de/signdrop-ungepatchter-windows-zero-day-nutzt-microsofts-clfs-schutzmassnahme-aus)
- [SignDrop Windows CLFS Zero-Day Details and Proof-of-Concept Exploit Published (Daily CyberSecurity)](https://securityonline.info/signdrop-windows-clfs-zero-day-poc/)
- [Exploitation of CLFS zero-day leads to ransomware activity (Microsoft Threat Intelligence, CVE-2025-29824)](https://www.microsoft.com/en-us/security/blog/2025/04/08/exploitation-of-clfs-zero-day-leads-to-ransomware-activity/)
- [AddLogContainer function (clfsw32.h) - Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/api/clfsw32/nf-clfsw32-addlogcontainer)
- [ShieldBreak Windows zero-day (Cyderes Howler Cell) - related research by the same researcher](https://www.cyderes.com/howler-cell/shieldbreak-windows-zero-day)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5838