As reported by Dark Reading, a proof-of-concept technique dubbed BigDiskBuster demonstrates how an attacker can leave Microsoft Defender's core service running while quietly blocking its signature and definition updates. The result is a Defender installation that appears healthy to monitoring tools but is effectively blind to anything discovered after the update block began.
Why This Matters More Than an EDR-Killer
Security teams have spent years building alerting around service-status indicators. If Defender or any EDR agent stops, starts crashing, or gets disabled, SOC dashboards light up immediately. BigDiskBuster sidesteps all of that. The service process runs normally. It responds to health checks. It even reports a running state to Microsoft's own telemetry channels. But behind that facade, the definition files stagnate, and any threat variant added to signatures after the blockage goes undetected.
This is a degradation attack rather than a disabling attack, and that distinction is critical. Degradation attacks fall into the blind spot of most operational monitoring because the failure mode is gradual and silent. An EDR that is running but 90 days out of date is worse than no EDR at all in some respects — it provides false assurance.
The Broader Evasion Playbook
BigDiskBuster fits into a growing category of techniques that impair security tooling without triggering tamper protection or alerting:
Each of these leaves the security agent's process intact while hollowing out its effectiveness. The CISA-led EDR evasion advisory from 2024 highlighted similar patterns in the wild, tied to Volt Typhoon and other actors.
Who Is Most at Risk
Organizations most exposed to this type of technique are those that:
- Rely on Microsoft Defender as their primary or sole endpoint protection without a secondary detection layer
- Have limited visibility into Defender update telemetry beyond the service health dashboard
- Operate hybrid environments where update paths traverse internet-facing firewalls that could be tampered with via network-level controls
- Lack configuration drift monitoring for endpoint security agents
SMBs and mid-market organizations using Defender for Business or standalone Defender configurations are particularly vulnerable because they often lack the multi-layered defense posture of enterprises that pair Defender with a secondary EDR or MDR provider.
What Defenders Should Watch
The key detection shift here is moving from service health monitoring to effectiveness monitoring. You should be tracking:
- Definition age — alert if the last successful signature update exceeds 24–48 hours
- Update success/failure ratios — a sudden spike in failed update attempts is a strong indicator of tampering
- Network egress to Microsoft update endpoints — confirm traffic to
*.windowsupdate.comand*.delivery.mp.microsoft.comis unobstructed - Registry and file integrity for Defender configuration — monitor changes to
HKLM\SOFTWARE\Microsoft\Windows Defenderkeys - Windows Event Log IDs 1150 and 2000–2003 — these capture signature update events and can be correlated for gap detection
If you're using Microsoft Sentinel or Defender for Endpoint, build a scheduled query that flags any endpoint where TimeGenerated for the last successful signature update is older than a defined threshold. This is a low-effort, high-value detection rule.
Shield53 Recommendations
Don't trust the process. Trust the output. A running agent that hasn't updated in days is a liability, not a control.
- Deploy definition-age alerting immediately. Create a threshold alert at 48 hours for any endpoint with stale signatures. This should be treated as a P2 incident at minimum.
- Layer your detection. If Defender is your only endpoint tool, consider adding a lightweight secondary agent or a network-level detection layer (IDS/IPS) that doesn't share Defender's update dependency.
- Harden update paths. Ensure your firewall and proxy rules explicitly allow and log traffic to Microsoft's signature update endpoints, and alert on any rule modifications affecting those destinations.
- Enable tamper protection and verify it's active. Microsoft Defender's tamper protection helps prevent some configuration changes, but it does not address network-level update blocking — verify both layers.
- Conduct purple-team validation. Have your internal or external red team attempt a BigDiskBuster-style update starvation against a test group of endpoints to validate your detection coverage.
- Review CISA's guidance on EDR evasion and map your current detection rules against the known techniques catalog.
This technique is a reminder that security tooling is not a binary state — it's a spectrum of effectiveness. An agent that's running but not updating is a silent failure, and silent failures are exactly what adversaries count on. The defenders who win are the ones monitoring for quality of protection, not just presence of it.