Back to Intelligence

ShieldCrash PoC: Unpatched Microsoft Defender Arbitrary File Read as SYSTEM — Detection and Hardening Guide

SA
Security Arsenal Team
September 10, 2026
10 min read

Security researcher Chaotic Eclipse (also tracked under the aliases INFINITE NIGHTMARE, MSNightmare, and Nightmare-Eclipse) has publicly released ShieldCrash, a proof-of-concept exploit targeting an unpatched vulnerability in Microsoft Defender that yields an arbitrary file read as NT AUTHORITY\SYSTEM. According to the researcher, Microsoft has not fully addressed the underlying issue — meaning every Windows endpoint running Defender as its primary AV is potentially exposed to local privilege-adjacent information disclosure until a vendor fix ships.

Let me be clear about why this matters operationally. An arbitrary file read running in the SYSTEM context is not a theoretical nuisance. It enables a low-privileged local attacker — or malware that has achieved initial code execution as a standard user — to read files they have no business touching: SAM hive backups, DPAPI master keys, sensitive configuration files, cached credentials, and documents belonging to other users. Combined with the fact that the PoC is public, the barrier to weaponization drops to near zero. Every red teamer and every commodity malware author now has working reference code.

Because there is no patch at the time of writing, this post focuses on what defenders can actually do today: understand the mechanics, hunt for exploitation artifacts, and reduce blast radius.

Technical Analysis

Affected Products and Platforms

  • Microsoft Defender Antivirus (MsMpEng.exe and associated platform components)
  • Applies broadly across supported Windows client and server editions where Defender is the active AV — Windows 10/11 and Windows Server 2016/2019/2022/2025 deployments should all be treated as in-scope until Microsoft publishes an authoritative affected-versions list
  • No CVE identifier has been assigned in the public reporting at time of writing, and no CVSS score is available

How the Vulnerability Works

Based on the public reporting, ShieldCrash abuses Defender's own privileged file-handling logic. Defender's engine runs as SYSTEM and routinely opens, moves, scans, and quarantines files on behalf of lower-privileged triggers. This class of vulnerability — and we've seen this pattern repeatedly across multiple AV vendors over the years — typically hinges on the privileged engine following attacker-controlled filesystem constructs (reparse points, junctions, or symlinks planted in locations Defender operates on, such as quarantine, scan staging, or signature-processing paths) and then performing a file operation on the redirected target with its own SYSTEM token.

From a defender's perspective, the exploitation chain looks like this:

  1. Attacker has local code execution as a standard (non-admin) user — via phishing payload, malicious macro, or an initial-access implant.
  2. The attacker stages filesystem artifacts — typically junctions or symlinks — in a location the Defender engine will interact with (scan targets, quarantine workflow, or attacker-writable paths the engine trusts).
  3. A Defender action is triggered or raced (a scan, a quarantine operation, or an engine file operation), causing MsMpEng to follow the attacker-controlled redirection.
  4. Defender opens the redirected target file as SYSTEM and the contents are exposed back to the attacker-controlled context — yielding arbitrary read of files the attacker could never access directly.

Key exploitation requirements: local access is mandatory. This is not remotely exploitable on its own, but it chains perfectly with any initial-access primitive, which is exactly how it will be used in the wild — as a post-exploitation escalation and credential-theft stage.

Exploitation Status

  • Public PoC: Yes. Working proof-of-concept code has been released by the researcher.
  • Patch status: Unpatched / disputed fix completeness. The researcher asserts Microsoft has not fully remediated the issue.
  • Confirmed in-the-wild exploitation: Not yet confirmed in public reporting — but with public PoC code, assume weaponization is a matter of when, not if.
  • CISA KEV: Not listed as of publication.

Detection & Response

This is a local privilege-adjacent technique, so our detection surface is endpoint telemetry: filesystem artifacts in and around Defender's operating directories, link-creation tooling aimed at those paths, and anomalous behavior from the Defender engine itself. The rules below are tuned to be high-signal — they target the specific staging behaviors this exploit class requires, not generic noise.

YAML
---
title: Suspicious Link or Junction Creation Targeting Microsoft Defender Directories
id: 3f8a2c14-7b61-4e5d-9c02-8a1d4f6b7e90
status: experimental
description: Detects use of link-creation utilities (mklink, fsutil, New-Item) to plant junctions, symlinks, or hardlinks pointing into or out of Microsoft Defender operating paths — a known staging pattern for AV privileged file-operation exploits such as ShieldCrash.
references:
  - https://securityaffairs.com/198726/security/chaotic-eclipse-released-shieldcrash-a-poc-for-microsoft-defender-zero-day.html
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\cmd.exe'
      - '\fsutil.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_linkverb:
    CommandLine|contains:
      - 'mklink'
      - '/j '
      - '/d '
      - 'hardlink create'
      - 'New-Item'
      - 'SymbolicLink'
      - 'Junction'
  selection_path:
    CommandLine|contains:
      - 'ProgramData\Microsoft\Windows Defender'
      - 'Windows Defender\Platform'
      - 'Windows Defender\Quarantine'
      - 'MsMpEng'
  condition: selection_tool and selection_linkverb and selection_path
falsepositives:
  - Rare; legitimate administration of Defender directories via link tooling is highly unusual
level: high
---
title: Non-Microsoft Process Writing to Windows Defender Platform or Quarantine Paths
id: 6c1d9e27-4a53-4b8f-a710-2e9c5d8b3f41
status: experimental
description: Detects file creation or modification inside Microsoft Defender platform, quarantine, or scan staging directories by processes other than known Microsoft Defender/Update binaries — consistent with an attacker staging artifacts for a privileged file-read exploit.
references:
  - https://securityaffairs.com/198726/security/chaotic-eclipse-released-shieldcrash-a-poc-for-microsoft-defender-zero-day.html
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.defense_evasion
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\ProgramData\Microsoft\Windows Defender\Quarantine'
      - '\ProgramData\Microsoft\Windows Defender\Scans'
      - '\ProgramData\Microsoft\Windows Defender\Platform'
  filter_legit:
    Image|endswith:
      - '\MsMpEng.exe'
      - '\MpCmdRun.exe'
      - '\MpSigStub.exe'
      - '\MsSense.exe'
      - '\SenseIR.exe'
      - '\MsMpEngCP.exe'
      - '\TrustedInstaller.exe'
      - '\TiWorker.exe'
      - '\svchost.exe'
  condition: selection_path and not filter_legit
falsepositives:
  - Third-party EDR management tools deploying alongside Defender
  - Software deployment systems servicing Defender platform updates (validate signer)
level: high
---
title: Unexpected Child Process Spawned by Microsoft Defender Engine
id: 9b4e7f38-1d62-4c3a-b845-5f0a2c9d6e17
status: experimental
description: Detects MsMpEng.exe spawning unexpected child processes. A compromised or exploited Defender engine executing attacker-controlled commands is a strong post-exploitation signal for AV-engine vulnerabilities.
references:
  - https://securityaffairs.com/198726/security/chaotic-eclipse-released-shieldcrash-a-poc-for-microsoft-defender-zero-day.html
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\MsMpEng.exe'
  filter_known:
    Image|endswith:
      - '\MpCmdRun.exe'
      - '\NisSrv.exe'
      - '\MsMpEngCP.exe'
      - '\conhost.exe'
  condition: selection_parent and not filter_known
falsepositives:
  - Extremely rare; MsMpEng child processes outside its known set warrant investigation
level: critical
KQL — Microsoft Sentinel / Defender
// Hunt: staging and exploitation artifacts for Defender privileged file-read abuse (ShieldCrash class)
// Looks for link-creation tooling aimed at Defender paths AND anomalous writes into Defender directories
let DefenderPaths = dynamic(["ProgramData\\Microsoft\\Windows Defender", "Windows Defender\\Quarantine", "Windows Defender\\Platform"]);
let LegitWriters = dynamic(["MsMpEng.exe", "MpCmdRun.exe", "MpSigStub.exe", "MsSense.exe", "SenseIR.exe", "TrustedInstaller.exe", "TiWorker.exe", "svchost.exe"]);
let LinkOps = DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("mklink", "hardlink create", "New-Item", "SymbolicLink", "Junction")
| where ProcessCommandLine has_any (DefenderPaths)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId;
let DirWrites = DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath has_any (DefenderPaths)
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where not(InitiatingProcessFileName has_any (LegitWriters))
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName, ActionType, ReportId;
union LinkOps, DirWrites
| sort by Timestamp desc
VQL — Velociraptor
-- Hunt for staged artifacts in Microsoft Defender directories and link-creation activity
-- Deploy as a multi-client hunt across Windows endpoints
SELECT * FROM foreach(
  row={
    SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
    FROM pslist()
    WHERE CommandLine =~ '(?i)(mklink|hardlink create|New-Item|SymbolicLink|Junction)'
       AND CommandLine =~ '(?i)Windows Defender'
  },
  query={
    SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
    FROM scope()
  })

// Separately: enumerate recent files planted in Defender quarantine/scans paths
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs='C:/ProgramData/Microsoft/Windows Defender/{Quarantine,Scans}/**')
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC
PowerShell
# ShieldCrash exposure verification and hardening audit
# Run as Administrator on each endpoint (or deploy via Intune/SCCM/GPO startup script)

# 1. Verify Defender engine/platform and signature currency — patch readiness baseline
$status = Get-MpComputerStatus
[PSCustomObject]@{
    AMEngineVersion         = $status.AMEngineVersion
    AMProductVersion        = $status.AMProductVersion
    AntivirusSignatureVer   = $status.AntivirusSignatureVersion
    SignatureLastUpdated    = $status.AntivirusSignatureLastUpdated
    RealTimeProtection      = $status.RealTimeProtectionEnabled
    TamperProtection        = $status.IsTamperProtected
} | Format-List

# 2. Confirm Tamper Protection is ON (prevents attacker tampering with Defender settings)
if (-not $status.IsTamperProtected) {
    Write-Warning "Tamper Protection is DISABLED on $env:COMPUTERNAME — enable via MDE/Intune/Defender portal"
}

# 3. Force immediate signature/platform update so the fix lands the moment Microsoft ships it
Update-MpSignature -ErrorAction SilentlyContinue

# 4. Audit for suspicious reparse points (junctions/symlinks) planted in Defender paths
$defenderPaths = @(
    "$env:ProgramData\Microsoft\Windows Defender"
)
foreach ($p in $defenderPaths) {
    Get-ChildItem -Path $p -Recurse -Force -ErrorAction SilentlyContinue |
        Where-Object { $_.Attributes -band [IO.FileAttributes]::ReparsePoint } |
        Select-Object FullName, LinkType, Target, LastWriteTime
}

# 5. Verify directory ACLs on Defender operating paths have not been loosened
$acl = Get-Acl "$env:ProgramData\Microsoft\Windows Defender"
$acl.Access | Where-Object {
    $_.FileSystemRights -match 'Write|Modify|FullControl' -and
    $_.IdentityReference -notmatch 'SYSTEM|Administrators|TrustedInstaller'
} | Select-Object IdentityReference, FileSystemRights, AccessControlType

# 6. Audit recent non-Microsoft handles: review process events touching Defender dirs
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match 'Windows Defender' } |
    Select-Object -First 50 TimeCreated, Message

Remediation

There is no vendor patch at the time of writing, so remediation is about exposure reduction, monitoring, and patch readiness.

  1. Enforce Tamper Protection everywhere. Confirm via the Microsoft Defender portal, Intune, or Group Policy that Tamper Protection is enabled on all endpoints. This prevents local attackers from disabling or reconfiguring Defender to weaken your detection posture while they attempt exploitation.
  2. Lock down Defender directory ACLs. Verify that C:\ProgramData\Microsoft\Windows Defender and its subdirectories grant write/modify rights only to SYSTEM, Administrators, and TrustedInstaller. Any broadened ACL (e.g., from a misconfigured deployment tool) widens the staging surface for this exploit class.
  3. Reduce local execution opportunity. This bug requires local code execution first. Enforce application control (WDAC or AppLocker), attack surface reduction rules, and hardened macro/script policies so initial-access payloads never get the foothold this exploit needs to chain from.
  4. Deploy the detections above now. The Sigma rules, KQL hunt, and VQL artifact target the staging behaviors (link creation into Defender paths, anomalous writes by non-Microsoft processes) that any weaponized version of this technique will need. Tune the legitimate-writer filter lists to your environment's management tooling before production rollout.
  5. Automate signature and platform updates. Ensure Defender platform and security intelligence updates flow without manual intervention so Microsoft's fix applies the day it ships. Monitor the Microsoft Security Update Guide and the Microsoft Security Response Center for the advisory and CVE assignment.
  6. Protect high-value file targets. Assume a successful read targets credential material: ensure DPAPI secrets, SAM/SYSTEM backups, and sensitive shares are not readable via any path a SYSTEM-context read on an endpoint could expose, rotate exposed credentials on any host showing hunt hits, and audit LAPS/BitLocker recovery key exposure paths.
  7. Watch for the patch and validate it. When Microsoft ships a fix, validate deployment via Get-MpComputerStatus platform/engine version reporting across your fleet — and note the researcher's claim that prior remediation was incomplete. Test post-patch behavior in a lab against the public PoC where your policies permit.

No CISA KEV deadline exists yet, but with public exploit code in circulation, treat your detection deployment as a this-week priority, not a this-quarter one.

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.