BigDiskBuster PoC Blocks Microsoft Defender Updates via Disk Exhaustion — Detection and Mitigation Guide

On September 19, 2026, security researcher Abdelhamid Naceri published a proof-of-concept tool called BigDiskBuster on GitHub that demonstrates an unpatched weakness in the Microsoft Defender update pipeline: by filling all available disk space on a Windows endpoint, an attacker can reliably prevent Defender from installing both platform (engine) updates and signature (definition) updates. There is no CVE assigned, no Microsoft advisory, and no patch available as of this writing.

This matters to defenders for one simple reason: an EDR/AV agent that cannot update is a degrading asset with a ticking clock. Signature staleness means missed detections for newly released malware families. Platform update failure means the engine itself never receives bug fixes, performance improvements, and — critically — patches for Defender's own vulnerabilities. Naceri is a former Microsoft security researcher whose previous Defender findings were leveraged in real attack chains, so this PoC should be treated as a preview of tradecraft, not an academic curiosity. Disk exhaustion as a defense-evasion primitive maps directly to MITRE ATT&CK T1562 (Impair Defenses) with elements of T1499 (Endpoint Denial of Service), and it requires nothing exotic — any code running with write access to the system volume can do it.

SOC teams should assume this technique will be folded into ransomware pre-staging and loader toolkits within weeks. The defensive playbook below gives you the detection, hunting, and hardening controls to get ahead of it.

Technical Analysis

Affected Products and Platforms

• Microsoft Defender Antivirus on all supported Windows client and server versions that rely on disk-resident update staging (Windows 10/11, Windows Server 2016 through 2025)
• Both the platform update channel (MpAsDesc / engine updates delivered via Microsoft Update, WSUS, or Intune) and the security intelligence update channel (MpSigStub-driven .vdm signature packages) are impacted
• No version is excluded; the weakness is architectural — the update process requires writable free space on the system volume to stage and apply packages, and it fails rather than alerting when that space is unavailable

How the Technique Works

The attack chain is deceptively simple, which is exactly why it's dangerous:

1. Execution context. Attacker code runs on the endpoint — post-exploitation, via a loader, a malicious macro, or even a low-privilege user context. No kernel exploit, no elevation to SYSTEM is strictly required if the user can write to a location that consumes the system volume.
2. Disk exhaustion. The tool rapidly creates or expands files (the classic primitive is fsutil file createnew <path> <size> or equivalent raw NTFS writes) until the system drive has insufficient free space for Defender's update staging.
3. Silent update failure. Defender's update mechanisms — MpSigStub.exe for security intelligence and the Microsoft Update pipeline for platform components — fail to stage packages. Critically, these failures are logged but not surfaced to the user or to most default EDR alerting. The Defender UI continues to show a green checkmark in many cases while signature versions quietly age.
4. Protection degradation. As days pass, the gap between the endpoint's signature version and current intelligence widens. New malware families, updated YARA-equivalent detections, and behavioral engine fixes never arrive. The endpoint becomes progressively blind.
5. Optional cleanup. A sophisticated actor can delete the filler files before the final payload stage, restoring disk space and removing the obvious artifact — leaving only the log trail of update failures.

Exploitation Status

• Public PoC: Yes — source published on GitHub (September 19, 2026)
• CVE: None assigned
• Microsoft advisory / patch: None at time of writing
• CISA KEV: Not listed (no CVE exists to list)
• Active exploitation: Not yet confirmed in the wild, but the barrier to weaponization is near zero — the PoC is functional and the technique is trivially portable into any post-exploitation framework

This is the definition of a pre-weaponization window. Detection engineering now costs hours; incident response after a ransomware crew blinds your AV with it costs weeks.

Detection & Response

The observable indicators here are strong and specific: (1) processes creating abnormally large files or consuming the system volume, (2) fsutil-based file creation with large size arguments, (3) Defender signature/platform update failure events, and (4) signature staleness across the fleet. Layer all four.

Sigma Rules

---
title: Large File Creation via Fsutil - Potential Disk Exhaustion
id: 3b9a1f47-2c6e-4d81-9f35-7e2a8c0d5b11
status: experimental
description: Detects fsutil createnew used to allocate very large files, a known primitive for disk exhaustion attacks that impair Microsoft Defender updates (BigDiskBuster technique).
references:
  - https://thehackernews.com/2026/09/researcher-drops-bigdiskbuster-zero-day.html
  - https://attack.mitre.org/techniques/T1562/
  - https://attack.mitre.org/techniques/T1499/
author: Security Arsenal
date: 2026/09/25
tags:
  - attack.defense_evasion
  - attack.t1562
  - attack.impact
  - attack.t1499
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\fsutil.exe'
  selection_cli:
    CommandLine|contains:
      - 'createnew'
  selection_size:
    CommandLine|re: 'createnew\s+\S+\s+[0-9]{9,}'
  condition: selection_img and selection_cli and selection_size
falsepositives:
  - Storage benchmarking and capacity testing by administrators
  - Database administrators pre-allocating data files
level: high
---
title: Microsoft Defender Signature Update Failure
id: 8c2d6e90-1a4b-4f77-b3e9-5d0c7a2f4e66
status: experimental
description: Detects Microsoft Defender security intelligence or platform update failures, which may indicate disk exhaustion (BigDiskBuster), update tampering, or servicing stack issues. Correlates with MpSigStub and Windows Defender operational events.
references:
  - https://thehackernews.com/2026/09/researcher-drops-bigdiskbuster-zero-day.html
  - https://attack.mitre.org/techniques/T1562/001/
author: Security Arsenal
date: 2026/09/25
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  product: windows
  service: Microsoft-Windows-Windows Defender/Operational
detection:
  selection:
    EventID:
      - 2001  # Signature update failed
      - 2002  # Engine update failed
  condition: selection
falsepositives:
  - Transient network issues reaching update sources
  - WSUS/Intune misconfiguration
level: high
---
title: Rapid Disk Space Consumption on System Volume
id: f14a7c28-6b3d-4e59-a082-9c1e5d7b3f90
status: experimental
description: Detects creation of new large files on the system drive by non-system processes, consistent with disk-filling behavior designed to block Microsoft Defender updates.
references:
  - https://thehackernews.com/2026/09/researcher-drops-bigdiskbuster-zero-day.html
  - https://attack.mitre.org/techniques/T1499/004/
author: Security Arsenal
date: 2026/09/25
tags:
  - attack.impact
  - attack.t1499.004
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|re: '^C:\\[^\\]+\.(tmp|dat|bin|pad|fill|000)$'
  filter_legit:
    Image|endswith:
      - '\sqlservr.exe'
      - '\MsMpEng.exe'
      - '\TiWorker.exe'
      - '\svchost.exe'
  condition: selection and not filter_legit
falsepositives:
  - Application installers staging payloads in C:\ root (unusual but possible)
  - Forensic imaging tools writing to the system volume
level: medium

KQL — Microsoft Sentinel / Defender

Two hunts: one for the disk-fill primitive itself, one for the effect — signature staleness across the fleet. The second query is your safety net even if the first never fires.

// Hunt 1: Processes creating large files on the system volume (disk exhaustion primitive)
DeviceFileEvents
| where TimeGenerated > ago(24h)
| where FolderPath startswith "C:\\"
| where ActionType == "FileCreated"
| join kind=inner (
    DeviceFileEvents
    | where TimeGenerated > ago(24h)
    | where ActionType == "FileModified"
    | summarize MaxFileSize = max(FileSize), WriteEvents = count() by DeviceId, FileName, FolderPath, InitiatingProcessFileName
) on DeviceId, FolderPath, FileName
| where MaxFileSize > 1GB or WriteEvents > 500
| where InitiatingProcessFileName !in~ ("MsMpEng.exe", "TiWorker.exe", "svchost.exe", "sqlservr.exe", "System")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName, MaxFileSize, WriteEvents
| order by MaxFileSize desc
;

// Hunt 2: Fsutil createnew abuse with large allocations
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "fsutil.exe"
| where ProcessCommandLine has "createnew"
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc
;

// Hunt 3: Fleet-wide Defender signature staleness — endpoints falling behind current intelligence
DeviceInfo
| where TimeGenerated > ago(1d)
| summarize arg_max(TimeGenerated, *) by DeviceId
| join kind=inner (
    DeviceEvents
    | where ActionType == "AntivirusSignatureVersionUpdated"
    | summarize LastSigUpdate = max(TimeGenerated), LastSigVersion = arg_max(TimeGenerated, AdditionalFields) by DeviceId
) on DeviceId
| extend SigAgeDays = datetime_diff("day", now(), LastSigUpdate)
| where SigAgeDays >= 2
| project DeviceName, OSPlatform, LastSigUpdate, SigAgeDays, LastSigVersion
| order by SigAgeDays desc

Velociraptor VQL

Use this artifact for fleet-wide sweeps to find the disk-fill artifact and the responsible process before an attacker cleans up.

-- Hunt for suspicious large files on the system volume and live processes
-- consistent with BigDiskBuster-style disk exhaustion

LET large_files = SELECT FullPath, Size, Mtime
FROM glob(globs='C:/Windows/Temp/**', accessor='ntfs')
WHERE Size > 1000000000
ORDER BY Size DESC

LET suspicious_procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)createnew|bigdiskbuster'
   OR Name =~ '(?i)bigdiskbuster'

SELECT * FROM large_files
UNION ALL
SELECT NULL AS FullPath, NULL AS Size, NULL AS Mtime FROM suspicious_procs

Verification and Hardening Script

Run this as a scheduled task or via your RMM across the fleet. It checks system volume free space, Defender signature age, platform version age, and recent update failure events — and writes structured output your SIEM can ingest.

# BigDiskBuster posture check: disk headroom + Defender update health
# Run as SYSTEM/admin on each endpoint; alert on any 'FAIL' output

$results = [ordered]@{}

# 1. System volume free space (GB)
$sysDrive = Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='$env:SystemDrive'"
$freeGB = [math]::Round($sysDrive.FreeSpace / 1GB, 2)
$results['SystemDriveFreeGB'] = $freeGB
$results['DiskCheck'] = if ($freeGB -lt 5) { 'FAIL - critically low free space' } elseif ($freeGB -lt 15) { 'WARN - low headroom' } else { 'PASS' }

# 2. Recently created large files on C:\ root and common temp paths (last 24h)
$largeFiles = Get-ChildItem -Path 'C:\', "$env:TEMP" -File -ErrorAction SilentlyContinue |
  Where-Object { $_.Length -gt 1GB -and $_.CreationTime -gt (Get-Date).AddDays(-1) } |
  Select-Object FullName, @{N='SizeGB';E={[math]::Round($_.Length/1GB,2)}}, CreationTime
$results['RecentLargeFiles'] = if ($largeFiles) { ($largeFiles | ConvertTo-Json -Compress) } else { 'None' }

# 3. Defender signature and engine age
$mp = Get-MpComputerStatus
$sigAge = (New-TimeSpan -Start $mp.AntivirusSignatureLastUpdated -End (Get-Date)).Days
$results['SignatureAgeDays'] = $sigAge
$results['SignatureVersion'] = $mp.AntivirusSignatureVersion
$results['EngineVersion'] = $mp.AMEngineVersion
$results['SignatureCheck'] = if ($sigAge -ge 3) { 'FAIL - signatures stale' } elseif ($sigAge -ge 2) { 'WARN' } else { 'PASS' }
$results['RealTimeProtection'] = if ($mp.RealTimeProtectionEnabled) { 'PASS' } else { 'FAIL - RTP disabled' }
$results['TamperProtection'] = if ($mp.IsTamperProtected) { 'PASS' } else { 'WARN - tamper protection off' }

# 4. Defender update failure events (last 7 days)
$failEvents = Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; Id=2001,2002; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue
$results['UpdateFailures7d'] = if ($failEvents) { $failEvents.Count } else { 0 }

# Output as single-line JSON for SIEM ingestion
$results['Host'] = $env:COMPUTERNAME
$results['CheckTime'] = (Get-Date).ToString('o')
[pscustomobject]$results | ConvertTo-Json -Compress

# Attempt a forced signature update if stale
if ($sigAge -ge 2) {
  try { Update-MpSignature -ErrorAction Stop; Write-Output 'SIGNATURE_UPDATE_TRIGGERED' }
  catch { Write-Output "SIGNATURE_UPDATE_FAILED: $($_.Exception.Message)" }
}

Remediation

There is no patch for this issue — no CVE, no Microsoft advisory, no fixed build. Until Microsoft redesigns the update pipeline to reserve staging space or alert loudly on update failure, mitigation is entirely on the defensive side:

1. Enforce free-space floors on the system volume. Alert at 15 GB free, page at 5 GB. Implement the PowerShell check above fleet-wide via scheduled task, RMM, or as a custom detection in your EDR. Disk-space monitoring is usually an infrastructure-metric concern; reclassify it as a security control.
2. Alert on Defender signature staleness, not just update errors. Deploy Hunt 3 (KQL) as a scheduled Sentinel analytics rule at a 2-day threshold. A silent endpoint that simply stops updating is the real risk — failure events (2001/2002) may not fire in every staging-failure path.
3. Restrict write access to the system volume root and staging directories. Standard users should not be able to create files in C:\ root or C:\ProgramData\Microsoft\Windows Defender paths. Audit NTFS ACLs; remove broad Everyone/Users write grants.
4. Enable and verify Tamper Protection (Intune: Defender > Tamper Protection; verify with Get-MpComputerStatus | Select IsTamperProtected). It won't stop disk exhaustion directly, but it raises the bar for follow-on tampering once updates are blocked.
5. Configure fallback update channels. Ensure endpoints can pull security intelligence from MMPC (https://www.microsoft.com/en-us/wdsi) directly if WSUS/Intune distribution fails, and verify MpSigStub.exe isn't blocked by application control policies in a way that masks failures.
6. Add disk-fill primitives to your threat hunting rotation. fsutil createnew with large sizes, unexpected multi-GB files in temp paths, and non-system processes with sustained high-volume writes should be weekly hunts, not annual ones.
7. Track Microsoft's response. Watch the Microsoft Security Update Guide and the Microsoft Defender for Endpoint blog for any servicing change addressing update-staging resilience. Validate any future fix against the public PoC in a lab before considering the issue closed.
8. Exercise the scenario. Add "AV update pipeline impaired via resource exhaustion" to your next purple team or tabletop. Your IR runbook should answer: how do we re-establish Defender health on a fleet whose signatures are two weeks stale after an intrusion?

The uncomfortable takeaway: this technique demonstrates that availability of the security stack is itself an attack surface. Defenders who only monitor for tampering, disabling, and uninstalling of the AV agent will miss an attack that leaves the agent running and smiling while it slowly goes blind. Monitor the health and currency of your controls, not just their presence.

Related Resources

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