Back to Intelligence

Windows SignDrop Zero-Day Grants SYSTEM Privileges: Detection, Hardening, and Mitigation Guide for Defenders

SA
Security Arsenal Team
November 12, 2026
12 min read

Security researcher Abdelhamid Naceri — known in the community as Nightmare Eclipse — has publicly released details and proof-of-concept code for a new unpatched Windows local privilege escalation (LPE) vulnerability dubbed SignDrop. The flaw allows a low-privileged local user — or malware running under standard user context — to elevate to NT AUTHORITY\SYSTEM, the highest privilege level on a Windows host.

Naceri has a track record here. He previously released working exploit code for Windows Installer privilege escalation flaws after becoming frustrated with vendor patch timelines, and those exploits were rapidly weaponized by ransomware operators and commodity malware within days of disclosure. Defenders should assume the same trajectory for SignDrop: public PoC code means weaponization is a matter of when, not if.

As of publication, Microsoft has not released a patch, and no CVE has been formally assigned. That means your exposure window is open right now, and the only controls available are detection, hardening, and attack-surface reduction. This post gives your SOC the telemetry signatures and your engineering teams the compensating controls to hold the line until a fix ships.

Technical Analysis

What is SignDrop?

SignDrop is a local privilege escalation vulnerability. Based on the researcher's disclosure pattern and the class of bugs Naceri has historically targeted, SignDrop abuses weaknesses in how Windows privileged components handle file operations — specifically, how a trusted, signature-validated process can be coerced into dropping or writing files to protected locations (such as C:\Windows\System32 or other privileged directories) on behalf of an unprivileged caller. Once an attacker can plant an arbitrary file in a SYSTEM-writable location, privilege escalation follows through well-worn paths: DLL planting into a service binary path, overwriting a scheduled task target, or abusing a privileged service that loads attacker-controlled content.

This file-write-as-SYSTEM primitive is the same family of technique that powered prior Windows LPE disclosures weaponized in the wild. The exploitation chain typically looks like this:

  1. Initial access — attacker gains code execution as a standard user (phishing, drive-by, malicious macro, compromised third-party software).
  2. Trigger the flaw — the exploit invokes a trusted, signed Windows component and manipulates it into performing a file-write or file-move operation into a privileged directory, bypassing ACL checks because the privileged process performs the write.
  3. Payload placement — an attacker-controlled DLL or executable lands in a location loaded by a SYSTEM service, scheduled task, or privileged installer flow.
  4. Elevation — the planted payload executes as NT AUTHORITY\SYSTEM, completing the escalation.

Affected Platforms

Per the researcher's disclosure, the vulnerability affects currently supported Windows client and server versions — treat Windows 10, Windows 11, Windows Server 2019, and Windows Server 2022 (and later) as in-scope until Microsoft publishes an authoritative affected-products list. Because the vulnerable behavior lives in core OS components rather than a specific application, assume broad applicability across your fleet.

Exploitation Requirements and Status

  • Access required: Local code execution as a standard (non-admin) user. This is a post-compromise elevation primitive, not an initial-access vector — but it collapses the entire "standard user" containment model.
  • User interaction: None beyond executing the exploit binary.
  • Reliability: Naceri's prior PoCs have been highly reliable, working across builds without target-specific offsets.
  • Status: Public proof-of-concept available. No patch. Not yet in CISA KEV — but monitor the KEV catalog daily; prior Naceri-disclosed bugs were added within weeks of public exploitation.

Why This Matters Operationally

Every ransomware playbook, every red team engagement, and every nation-state intrusion I've worked follows the same arc: initial access as a user, then privilege escalation, then lateral movement. Endpoint controls like EDR tamper protection, credential guard, and application allowlisting all assume the attacker is constrained by user-context permissions. A reliable, public SYSTEM-level LPE in every unpatched Windows box removes that assumption. If your defense-in-depth strategy leans on "the attacker is only a standard user," SignDrop breaks it.

Detection & Response

Because exploitation ultimately manifests as anomalous file writes to protected directories and unexpected child processes or payload execution under SYSTEM context, our detections focus on those observable behaviors rather than the exploit binary itself (which will be recompiled and renamed within hours of publication).

The following Sigma rules target the post-exploitation artifacts: file creation in privileged directories by non-system processes, and SYSTEM-context execution of binaries from non-standard locations.

YAML
---
title: Suspicious File Creation in Protected Windows Directory by Non-Privileged Process
id: 8b2c4d6e-1a3f-4b5c-9d7e-2f4a6c8e0b1d
status: experimental
description: Detects file creation events in privileged Windows directories (System32, SysWOW64, WinSxS-adjacent paths) by processes that do not normally write there. SignDrop-style LPE exploits coerce privileged components into dropping attacker payloads in these locations.
references:
  - https://www.bleepingcomputer.com/news/security/new-windows-signdrop-zero-day-gives-hackers-system-privileges/
  - https://attack.mitre.org/techniques/T1068/
  - https://attack.mitre.org/techniques/T1574/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.t1574.001
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\Windows\System32\'
      - '\Windows\SysWOW64\'
  filter_software_installers:
    Image|contains:
      - '\msiexec.exe'
      - '\TiWorker.exe'
      - '\TrustedInstaller.exe'
      - '\svchost.exe'
      - '\WindowsUpdate'
      - '\dism.exe'
      - '\sfc.exe'
  filter_legit_updaters:
    Image|contains:
      - '\Program Files\'
      - '\Program Files (x86)\'
  condition: selection_path and not filter_software_installers and not filter_legit_updaters
falsepositives:
  - Legitimate software installers running from temp directories
  - Enterprise software distribution tools (SCCM, Intune) writing drivers or system components
level: high
---
title: SYSTEM-Context Execution of Binary from User-Writable or Temp Location
id: 3f7a9c1e-5d2b-4e8f-a6c0-7b9d1e3f5a2c
status: experimental
description: Detects processes running as SYSTEM with executable paths in user-writable or temporary directories. SignDrop and similar LPE chains frequently result in attacker payloads planted in writable locations being executed by privileged services or scheduled tasks.
references:
  - https://www.bleepingcomputer.com/news/security/new-windows-signdrop-zero-day-gives-hackers-system-privileges/
  - https://attack.mitre.org/techniques/T1068/
  - https://attack.mitre.org/techniques/T1053/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.persistence
logsource:
  category: process_creation
  product: windows
detection:
  selection_user:
    User|contains:
      - 'SYSTEM'
      - 'LOCAL SERVICE'
      - 'NETWORK SERVICE'
  selection_path:
    Image|contains:
      - '\Users\Public\'
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Windows\Temp\'
      - '\ProgramData\'
      - '\$Recycle.Bin\'
      - '\PerfLogs\'
  filter_programdata_known:
    Image|contains:
      - '\ProgramData\Microsoft\'
      - '\ProgramData\Package Cache\'
  condition: selection_user and selection_path and not filter_programdata_known
falsepositives:
  - Enterprise deployment agents running from ProgramData
  - Legitimate scheduled tasks installed by line-of-business software
level: high
---
title: Scheduled Task Registration Pointing to User-Writable Payload
id: 6e1b3d5f-8a2c-4f7b-b9e0-1c4d6e8a0b3f
status: experimental
description: Detects creation of scheduled tasks whose action executable resides in a user-writable path. A common SignDrop post-exploitation persistence and elevation mechanism is registering a task running as SYSTEM that launches the planted payload.
references:
  - https://www.bleepingcomputer.com/news/security/new-windows-signdrop-zero-day-gives-hackers-system-privileges/
  - https://attack.mitre.org/techniques/T1053.005/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1053.005
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\schtasks.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_args:
    CommandLine|contains:
      - '/create'
      - 'Register-ScheduledTask'
  selection_path:
    CommandLine|contains:
      - 'Users\Public'
      - 'AppData\Local\Temp'
      - 'Windows\Temp'
      - '$env:TEMP'
      - 'ProgramData'
  filter_admin_activity:
    CommandLine|contains:
      - 'ProgramData\Microsoft'
  condition: selection_tool and selection_args and selection_path and not filter_admin_activity
falsepositives:
  - Software installers creating update tasks
  - IT automation scripts deploying scheduled tasks
level: medium

KQL — Microsoft Sentinel / Defender for Endpoint

This hunt query looks for the core SignDrop post-exploitation pattern: SYSTEM-context processes executing from unusual locations, correlated with recent file writes to protected directories by non-standard processes. Run it across your fleet, and tune the exclusion list against your known software distribution tooling.

KQL — Microsoft Sentinel / Defender
// Hunt for SYSTEM-context execution from user-writable/temp paths (SignDrop post-exploitation pattern)
let Lookback = 7d;
let SuspiciousPaths = dynamic([@"\Users\Public\", @"\AppData\Local\Temp\", @"\Windows\Temp\", @"\ProgramData\", @"\PerfLogs\", @"\$Recycle.Bin\"]);
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where AccountName in~ ("system", "local service", "network service")
| where FolderPath has_any (SuspiciousPaths)
| where FolderPath !has @"\ProgramData\Microsoft\"
| project TimeGenerated, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
| join kind=leftouter (
    DeviceFileEvents
    | where TimeGenerated > ago(Lookback)
    | where FolderPath has_any (@"\Windows\System32\", @"\Windows\SysWOW64\")
    | where ActionType == "FileCreated"
    | where InitiatingProcessFolderPath !has_any (@"\Windows\System32\", @"\Windows\ servicing\")
    | project FileCreatedTime=TimeGenerated, DeviceName, DroppedFile=FileName, DroppedTo=FolderPath, DroppingProcess=InitiatingProcessFileName
) on DeviceName
| project-reorder TimeGenerated, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, DroppingProcess, DroppedFile, DroppedTo
| sort by TimeGenerated desc

A companion query for file-write anomalies into System32 by non-OS processes:

KQL — Microsoft Sentinel / Defender
// File creations in protected directories by processes outside trusted OS paths
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where ActionType == "FileCreated"
| where FolderPath has_any (@"C:\Windows\System32\", @"C:\Windows\SysWOW64\")
| where InitiatingProcessFolderPath !startswith @"C:\Windows\"
| where InitiatingProcessFolderPath !startswith @"C:\Program Files"
| summarize FileCount=count(), Files=make_set(FileName, 10), DroppedPaths=make_set(FolderPath, 10)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessSHA256
| sort by FileCount desc

Velociraptor VQL — Endpoint Sweep

Use this hunt artifact to sweep endpoints for recently created files in protected directories, cross-referenced against running SYSTEM processes from non-standard paths — the two strongest host-based artifacts of a SignDrop-style escalation.

VQL — Velociraptor
-- SignDrop LPE hunt: recent file drops in protected dirs + SYSTEM processes from odd paths
LET protected_drops = SELECT FullPath, Mtime, Size,
       upload(accessor="ntfs", path=FullPath) as FileAvailable
FROM glob(globs=[
  "C:/Windows/System32/*.dll",
  "C:/Windows/System32/*.exe",
  "C:/Windows/SysWOW64/*.dll"
])
WHERE Mtime > now() - 604800

LET system_procs = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Username =~ 'SYSTEM|LOCAL SERVICE|NETWORK SERVICE'
  AND Exe =~ '(?i)(Users.Public|AppData.Local.Temp|Windows.Temp|ProgramData|PerfLogs)'
  AND Exe !~ '(?i)ProgramData.Microsoft'

SELECT * FROM protected_drops
UNION ALL
SELECT FullPath=NULL, Mtime=CreateTime, Size=NULL, FileAvailable=NULL,
       Pid=Pid, Name=Name, Exe=Exe, CommandLine=CommandLine, Username=Username
FROM system_procs

For tighter output, run the two SELECT statements as separate artifacts — one file-drop timeline artifact and one live-process artifact — so your analysts can pivot each independently.

Verification and Hardening Script

Until Microsoft ships a patch, use this PowerShell script to audit endpoint exposure indicators: look for recently dropped unsigned binaries in protected directories, audit scheduled tasks pointing to writable paths, and confirm that key mitigations (attack surface reduction rules, WDAC/AppLocker, restricted standard-user rights) are in place.

PowerShell
# SignDrop exposure audit - run elevated via RMM/Intune/SCCM across the fleet
$report = [ordered]@{}

# 1. Recently created unsigned binaries in protected directories (last 7 days)
$cutoff = (Get-Date).AddDays(-7)
$suspiciousDrops = Get-ChildItem -Path "$env:SystemRoot\System32","$env:SystemRoot\SysWOW64" -Include *.dll,*.exe -ErrorAction SilentlyContinue |
    Where-Object { $_.CreationTime -gt $cutoff } |
    ForEach-Object {
        $sig = Get-AuthenticodeSignature $_.FullName
        [PSCustomObject]@{
            Path      = $_.FullName
            Created   = $_.CreationTime
            Signed    = $sig.Status
            Signer    = $sig.SignerCertificate.Subject
        }
    } | Where-Object { $_.Signed -ne 'Valid' -or $_.Signer -notmatch 'Microsoft' }
$report['UnsignedDropsInProtectedDirs'] = $suspiciousDrops

# 2. Scheduled tasks running as SYSTEM with actions in writable paths
$writablePaths = 'Users\Public|AppData\Local\Temp|Windows\Temp|ProgramData|PerfLogs'
$riskyTasks = Get-ScheduledTask | Where-Object {
    $_.Principal.UserId -match 'SYSTEM|LOCAL SERVICE|NETWORK SERVICE' -and
    ($_.Actions | Where-Object { $_.Execute -match $writablePaths })
} | Select-Object TaskName, TaskPath, @{N='Action';E={($_.Actions | ForEach-Object { "$($_.Execute) $($_.Arguments)" }) -join '; '}}
$report['RiskySystemTasks'] = $riskyTasks

# 3. Verify Microsoft Defender Attack Surface Reduction rule state (block untrusted/unsigned processes from USB and Office child processes as baseline)
$asrRules = Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
$asrActions = Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
$report['ASRConfigured'] = ($asrRules.Count -gt 0)

# 4. Verify WDAC / AppLocker enforcement presence
$wdac = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard -ErrorAction SilentlyContinue
$report['WDAC_Enforced'] = ($wdac.CodeIntegrityPolicyEnforcementStatus -eq 2)
$applocker = Get-AppLockerPolicy -Effective -ErrorAction SilentlyContinue
$report['AppLockerPresent'] = ($null -ne $applocker)

# 5. Recent local privilege escalation indicators: non-admin users added to local Administrators
$admins = Get-LocalGroupMember -Group 'Administrators' -ErrorAction SilentlyContinue | Select-Object Name, ObjectClass, PrincipalSource
$report['LocalAdmins'] = $admins

$report | ConvertTo-Json -Depth 5 | Out-File "$env:ProgramData\SignDrop_Audit_$(Get-Date -Format yyyyMMdd_HHmmss).json"
Write-Output "Audit complete. Review output JSON in $env:ProgramData."

Remediation

Immediate Actions (No Patch Available)

  1. Deploy the detections above today. Public PoC means your exposure starts now. Push the Sigma rules through your detection pipeline, onboard the KQL queries as scheduled Sentinel analytics, and run the PowerShell audit fleet-wide. Prioritize internet-facing users, developer workstations, and any host where standard users execute untrusted code.

  2. Enforce application control. This is the single most effective compensating control for an unpatched LPE. If the exploit binary or its planted payload cannot execute, the chain dies:

    • Deploy Windows Defender Application Control (WDAC) or AppLocker in enforce mode on high-value assets (at minimum: block executables and DLLs from user-writable paths for all users, allow only signed/trusted publishers).
    • Enable Microsoft Defender ASR rules, particularly Block executable files from running unless they meet a prevalence, age, or trusted list criterion and Block abuse of exploited vulnerable signed drivers.
    • Enable SmartScreen and reputation-based protection for downloaded executables.
  3. Harden the escalation targets. Since the payload ultimately executes via SYSTEM-context services or scheduled tasks:

    • Audit all scheduled tasks for actions pointing to user-writable paths (script above) and remediate.
    • Review service binary permissions; ensure no service binary or its directory is writable by standard users (icacls review on non-default service paths).
    • Enable LSA protection / Credential Guard — post-escalation credential theft is the next step in the kill chain.
  4. Reduce the local admin and execution surface. Confirm users run as standard users (no local admin), remove unnecessary software, and restrict PowerShell to Constrained Language Mode for standard users where feasible.

  5. Monitor for the patch. Track the Microsoft Security Response Center advisory feed, the monthly Patch Tuesday release, and the CISA Known Exploited Vulnerabilities catalog. Given the researcher's history, expect either an out-of-band fix or inclusion in an upcoming cumulative update — and expect a CISA KEV entry with a federal remediation deadline if active exploitation is confirmed. Build the patch into your emergency change window the day it ships.

  6. Brief your threat model. Update your IR runbooks: any host showing the file-drop or SYSTEM-execution patterns above should be treated as a confirmed compromise requiring credential resets for all users who authenticated to that host, not just the exploited account. SYSTEM-level access means every secret that touched the box is exposed.

If Exploitation Is Suspected

Isolate the host, capture memory (WinPmem/Velociraptor offline collector), preserve C:\Windows\System32\config, $MFT, USN Journal, and ShimCache/AmCache hives before remediation, and hunt laterally using the KQL queries above with the compromised host's timeline as ground truth. SYSTEM escalation plus public exploit availability means assume-breach posture on adjacent credentials.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.