Windows SignDrop CLFS Zero-Day: Mitigation and Hunting

On November 10, 2026, a researcher publishing as MSNightmare released SignDrop, a local privilege escalation zero-day in the Windows Common Log File System (CLFS) driver, clfs.sys, with working proof-of-concept code. A standard user who can run a program on the PC ends up with a SYSTEM shell.

The flaw sits inside a security feature. Since October 28, 2025, Windows signs CLFS log files with authentication codes so the driver can refuse files that something else has modified. Microsoft added it because attackers kept using CLFS parsing bugs to gain privileges. SignDrop abuses the way the driver creates the .cnpf file that supports that signing. In the researcher’s words, the mitigation “can be used against itself”.

There is no patch, no CVE and no Microsoft advisory. The researcher’s write-up does not say the flaw was reported to Microsoft before release. Microsoft and CISA have not reported attacks. The code is public, so expect it in attacker toolkits quickly. Local privilege escalation is the step ransomware operators need after a phish or a stolen password.

Who is affected

A device is exposed when CLFS logfile authentication is active, in learning mode or enforcement mode. Microsoft’s documentation lists the feature for:

• Windows 11, versions 25H2 and 26H1
• Windows Server 2025

with updates released on or after October 28, 2025. The researcher reports testing it on Windows 11 26H2 builds and on a Windows Server 2025 preview build.

Windows 10, Windows 11 24H2 and earlier, and Windows Server 2022 and earlier are not in Microsoft’s list for the feature. Use the registry check below to be sure about a given device.

The attacker needs to run code on the device as any user. That makes these the systems to worry about first:

1. Multi-user servers: Remote Desktop session hosts, virtual desktop pools, jump hosts and shared engineering servers, where one user’s session can become SYSTEM over everyone else’s.
2. Servers that run code for others: web and application servers, build agents and database servers on Windows Server 2025, where a flaw in an application gives an attacker a low-privileged foothold.
3. Workstations, where the flaw turns a phishing payload running as the user into full control of the PC and its security tools.

What the flaw is

CLFS is the kernel logging service that Windows, the registry and many applications use for transaction logs. A log is a base file ending in .blf plus one or more container files.

With logfile authentication on, the driver writes authentication codes into each log and keeps a patch file ending in .cnpf beside it. Microsoft documents that the patch file gets the same security attributes as the file it belongs to.

The researcher’s write-up describes the problem this way:

• A log can point at a second container file at a path the log’s creator chooses. Whenever the log is opened, the driver opens that container as well, and creates its .cnpf file if the container is empty.
• The driver checks access as whichever process opens the log. When the user who made the log opens it, the check is correct and nothing is gained.
• Opening a log needs no special flag. A privileged process that can be made to open a path the user controls will open the prepared log, and the driver then creates the .cnpf file with that process’s rights, at the location stored in the log, with the permissions of the original file.

The published code makes Microsoft Defender the privileged process. It calls Defender’s signature update interface and redirects the path with object manager symbolic links, so Defender’s engine, running as SYSTEM, opens the log. The result is a file created as SYSTEM in a place a standard user could never write to, with permissions the user controls. The proof of concept turns that into a SYSTEM shell.

The claim about antivirus and EDR

The researcher says the same trick works against any antimalware product, because the file is created by the product’s own process and its self-protection sees a request from itself. On that basis the researcher says it can turn off any antivirus or EDR product. Microsoft and other vendors have not confirmed this. Until they do, treat a sensor that stops reporting on an affected Windows version as a possible intrusion, not a fault.

What to do now

There is no update to install. These steps reduce the chance of the flaw being used and make its use visible.

1. Leave CLFS authentication on. Setting the mode to disabled removes the exposure to SignDrop, but it also removes the protection against the CLFS memory corruption exploits the feature was built to stop. Microsoft does not recommend disabling it, and the researcher says the same.
2. Stop untrusted programs from running. SignDrop needs the attacker to run their own code. Enforce App Control for Business or AppLocker on servers and shared hosts, and turn on the Defender attack surface reduction rule that blocks executable files unless they meet a prevalence, age or trusted list criterion.
3. Tighten multi-user servers first. Limit who can log on to session hosts and jump hosts, and remove the ability to run programs from user-writable folders there.
4. Alert when a security tool goes quiet. A device on an affected Windows version whose antivirus or EDR sensor stops, loses real-time protection or reports tampering needs a look the same day.
5. Record the CLFS mode across the fleet with the check below, so you know which devices are exposed and can see if anyone changes it.
6. Install Microsoft’s fix as soon as it exists. Microsoft’s next scheduled security updates are due on December 8, 2026. A fix may arrive sooner, out of band.

How to check your environment

The mode is a registry value. Read it with PowerShell:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" |
    Select-Object Mode, EnforcementTransitionPeriod, LearningModeStartTime

Microsoft documents the Mode values:

If the key does not exist, the Windows build does not have the feature.

A device starts in learning mode when it first receives the feature and moves to enforcement after the adoption period, which Microsoft sets at 90 days. Both modes are exposed, so nearly every Windows 11 25H2 or Windows Server 2025 device with current updates reads 0 or 1.

To collect the value across a fleet, run the command through Intune remediation scripts, Configuration Manager or your remote management tool. Group Policy shows the setting under Computer Configuration > Administrative Templates > System > Filesystem > Enable / disable CLFS logfile authentication.

Do not run the proof of concept on production devices to test them. The registry value gives the same answer.

Threat hunting

No indicators of compromise have been published, and the exploit leaves little that is unique. These hunts look for the file it creates, the privilege jump it produces and the tampering that would follow.

Example KQL for Microsoft Sentinel and Defender

The KQL below is example code for Microsoft Sentinel and Microsoft Defender for Endpoint. Adapt table and field names to your environment and test each query before relying on it.

Hunt 1: devices on affected Windows versions

// Example: Defender XDR, Windows 11 and Windows Server 2025 devices by version
DeviceInfo
| where Timestamp > ago(7d)
| where OSPlatform in ("Windows11", "WindowsServer2025")
| summarize arg_max(Timestamp, OSVersionInfo, OSBuild) by DeviceId, DeviceName, OSPlatform
| summarize Devices = count() by OSPlatform, OSVersionInfo
| order by Devices desc

To see whether anyone has changed the CLFS mode:

// Example: Defender XDR, changes to the CLFS authentication settings
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"Services\CLFS\Authentication"
| where RegistryValueName in~ ("Mode", "EnforcementTransitionPeriod")
| project Timestamp, DeviceName, ActionType, RegistryValueName, PreviousRegistryValueData, RegistryValueData,
          InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Hunt 2: .cnpf files in the wrong place or from the wrong process

Normal patch files are named after their log, such as example.blf.cnpf, and sit beside it. This looks for .cnpf files with other names, any written by security software, and any created in system or program folders.

// Example: Defender XDR, unusual CLFS patch files
let SecurityTools = dynamic(["MsMpEng.exe", "MpCmdRun.exe", "MpDefenderCoreService.exe", "NisSrv.exe", "MsSense.exe", "SenseNdr.exe"]);   // add your own AV and EDR processes
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType in ("FileCreated", "FileRenamed")
| where FileName endswith ".cnpf"
| extend Reason = case(
    InitiatingProcessFileName in~ (SecurityTools), "Written by security software",
    FileName !endswith ".blf.cnpf", "Not named after a .blf log",
    FolderPath has_any (@"\Windows\System32\", @"\Program Files", @"\ProgramData\Microsoft\Windows Defender"), "System or program folder",
    "")
| where isnotempty(Reason)
| where not(FolderPath has_any (@"\System32\config\", @"\System32\LogFiles\", @"\ServiceProfiles\"))   // registry and service logs, tune for your estate
| project Timestamp, DeviceName, Reason, FolderPath, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Defender for Endpoint does not record every file its own engine writes, so an empty result does not clear a device.

Hunt 3: a SYSTEM shell started from a standard user’s process

The proof of concept ends by starting a shell as SYSTEM. A SYSTEM process whose parent runs at medium integrity as a normal user is the privilege jump, whichever exploit caused it.

// Example: Defender XDR, SYSTEM-integrity shells with a medium or low integrity parent
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessIntegrityLevel == "System"
| where InitiatingProcessIntegrityLevel in ("Medium", "Low")
| where InitiatingProcessAccountSid != "S-1-5-18"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "conhost.exe", "wt.exe", "rundll32.exe", "regsvr32.exe", "mshta.exe")
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName
| order by Timestamp desc

Hunt 4: Defender signature update errors and protection changes

The published code calls Defender’s signature update interface with a path it controls. That can show as a failed definition update at a time when no update was due, followed by protection being turned off.

// Example: Defender XDR, definition update failures and tampering attempts per device
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType in ("AntivirusDefinitionsUpdateFailed", "TamperingAttempt", "AntivirusTroubleshootModeEvent")
| summarize Events = count(), First = min(Timestamp), Last = max(Timestamp) by DeviceName, ActionType
| order by Last desc

If you collect the Defender operational log in Sentinel:

// Example: Sentinel, Defender update failures (2001), real-time protection disabled (5001) and blocked tampering (5013)
Event
| where TimeGenerated > ago(30d)
| where EventLog == "Microsoft-Windows-Windows Defender/Operational"
| where EventID in (2001, 5001, 5013)
| project TimeGenerated, Computer, EventID, RenderedDescription
| order by TimeGenerated desc

Hunt 5: sensors that stopped reporting

// Example: Defender XDR, affected Windows devices that were reporting last week and are silent now
DeviceInfo
| where Timestamp > ago(14d)
| where OSPlatform in ("Windows11", "WindowsServer2025")
| summarize LastSeen = max(Timestamp) by DeviceId, DeviceName
| where LastSeen between (ago(14d) .. ago(2d))
| order by LastSeen desc

Laptops that are simply switched off will appear. Check the ones that are still active in your directory, VPN or network logs.

Hunt 6: the published project by name

Copies of the public code are the easy case, since an attacker can rename them. The project is named SigDrop, and the repository ships a file named hid.dll whose role the write-up does not explain.

// Example: Defender XDR, the public project's file names, and hid.dll outside the Windows folders
union
(DeviceProcessEvents
    | where Timestamp > ago(30d)
    | where FileName has_any ("SigDrop", "SignDrop") or ProcessCommandLine has_any ("SigDrop", "SignDrop")
    | project Timestamp, DeviceName, Evidence = strcat("Process: ", FolderPath, " ", ProcessCommandLine), Account = AccountName),
(DeviceFileEvents
    | where Timestamp > ago(30d)
    | where FileName has_any ("SigDrop", "SignDrop")
    | project Timestamp, DeviceName, Evidence = strcat("File: ", FolderPath), Account = InitiatingProcessAccountName),
(DeviceImageLoadEvents
    | where Timestamp > ago(30d)
    | where FileName =~ "hid.dll" and not(FolderPath has_any (@"\Windows\System32", @"\Windows\SysWOW64", @"\Windows\WinSxS"))
    | project Timestamp, DeviceName, Evidence = strcat("Image load: ", FolderPath, " by ", InitiatingProcessFileName), Account = InitiatingProcessAccountName)
| order by Timestamp desc

How to tell if a device was compromised

SignDrop is a step in an attack, so look at what happened either side of it:

• Before: how the attacker got to run code. A phishing attachment, a user-writable folder on a session host, or a web application flaw on a server.
• The jump: a SYSTEM shell under a user’s process (Hunt 3), a .cnpf file where none belongs (Hunt 2), or a Defender update error that lines up with either (Hunt 4).
• After: what SYSTEM was used for. Security tools stopped or uninstalled, credential dumping from LSASS, new local administrators, new services or scheduled tasks, and lateral movement with the credentials found on the device.

If a device shows the jump, isolate it, collect the evidence, and reset the credentials of every account that was signed in to it, including service accounts.

Timeline

• October 28, 2025: Microsoft ships CLFS logfile authentication in Windows 11 25H2 and Windows Server 2025 updates (KB5056852). Devices start a 90-day learning period, then enforce.
• November 10, 2026, 19:20 UTC: The SignDrop repository is published with proof-of-concept source code.
• November 10, 2026, 23:37 UTC: The researcher adds the technical write-up.
• December 8, 2026: Microsoft’s next scheduled security updates. Microsoft has not said whether a fix will be in them.

Frequently Asked Questions

Is there a patch or a CVE for SignDrop? No. Microsoft has not published an advisory, a CVE or an update for it. The only public description is the researcher’s own repository.

Which Windows versions are affected? Devices where CLFS logfile authentication is in learning or enforcement mode. Microsoft lists the feature for Windows 11 25H2 and later and Windows Server 2025, with updates from October 28, 2025 onward.

How do I check whether a PC is exposed? Read the Mode value under HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication. A value of 0 or 1 means the feature is active and the device is exposed. A value of 2 or 3 means it is disabled.

Should I disable CLFS authentication to protect against it? We do not recommend it. Disabling the feature brings back exposure to CLFS memory corruption exploits, which is what it was built to stop. Microsoft advises against disabling it, and so does the researcher.

Can SignDrop be exploited remotely? No. The attacker must already be able to run a program on the device as some user. It is the second step after phishing, a stolen password or a flaw in an application.

Is SignDrop being used in attacks? Microsoft and CISA have reported none. Working exploit code has been public since November 10, 2026, so plan as if it will be.

Can it really disable antivirus and EDR? That is the researcher’s claim, and the published code uses Microsoft Defender’s own process to create the file. No vendor has confirmed it. Treat a sensor that goes silent on an affected device as a lead.

Are .cnpf files a sign of compromise? No. Every CLFS log on an affected Windows version has one, next to its .blf file. What matters is a .cnpf file with an unusual name, in a system or program folder, or written by a security product.

How ThreatDefence is responding

ThreatDefence is tracking SignDrop and has added the behavior described above to our detection content. Across all monitored environments, our SOC is:

• alerting on SYSTEM shells started from standard user processes, and on CLFS patch files created outside their normal locations
• watching for antivirus and EDR sensors that stop reporting, lose real-time protection or report tampering
• following Microsoft’s channels for an advisory, a CVE and a fix

If you want help checking your Windows estate or investigating a suspected privilege escalation, contact us. Read more about our managed detection and response.

Sources

• MSNightmare, SignDrop repository and write-up (November 10, 2026)
• Microsoft Support, Common Log File System (CLFS) Authentication Mitigation, KB5056852 (October 28, 2025)
• Microsoft Learn, CLFS Logfile Authentication
• Microsoft Learn, Introduction to the Common Log File System
• Microsoft Learn, fsutil clfs
• Microsoft Learn, Attack surface reduction rules reference
• Microsoft Learn, App Control for Business
• Microsoft Learn, DeviceFileEvents table (Defender XDR advanced hunting)