Build1 publisher3 min readPublished
BigDiskBuster reserves the last free bytes on C: to make Defender updates fail
The public proof-of-concept watches Defender's update directories, hoards nearly all the free space on C: with delete-on-close files, and hands the space back once the update has already failed. At rest, the disk looks normal.
The Engineer · Build desk
What happened
- BigDiskBuster is a public proof-of-concept that watches for Microsoft Defender update activity and then temporarily reserves nearly all the remaining free space on the C drive with hidden temporary files.
- The researcher claims the technique can block Defender platform and security intelligence updates across all supported Windows versions.
- The technique needs the attacker to already have code execution on the endpoint, via earlier compromise, delivered malware or user execution.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision With no CVE and no patch, vulnerability management has nothing to deploy against this, so the decision sits with the detection and hunting teams instead.
- exposure An endpoint can look healthy while its signatures age, because the writeup says no clear warning need appear when updates stop.
- constraint Hunting on handles, temp files and long-running processes only works while the process is alive; version age is the one indicator that survives it exiting.
- cost The same space reservation can generate low-disk warnings or instability in unrelated applications, so a helpdesk may burn triage on the wrong ticket first.
Reserving space is not the same as filling it. The files are hidden, GUID-named, created under `%TEMP%` when the process sees update-related directory activity, and opened with delete-on-close behaviour; the allocation they request is sized to whatever is still free on C: at that moment [2]. When the monitored update directory is removed, which the proof-of-concept reads as a failed update, it closes those handles, the files are deleted, and the space comes back [5]. The process then keeps watching and can do it again on the next attempt [5].
So a free-space graph shows a dip only if a sample lands between the moment update activity is detected and the moment the update directory disappears [1]. Five-minute polling on a fleet of laptops will mostly sample outside that window [1]. The writeup lists sudden drops and recoveries in C: free space around update attempts as an indicator, along with unusual handles to `MRT.exe`, unknown long-running processes, and hidden GUID-named files under `%TEMP%` during Defender updates [8].
The handle is the other half. On start, the code opens `C:\Windows\System32\MRT.exe` with restrictive sharing permissions and monitors the platform and security intelligence update directories [3]. Every one of those artifacts is visible while the process lives. Two items on the same indicator list outlast it: repeated Defender update failures, and outdated platform or security intelligence versions [8]. If you already collect platform version and signature timestamp per endpoint, an age threshold fires whether the cause is this code, a broken proxy, or a disk that is genuinely full. For it to be worth the alert volume, your telemetry has to record update success per endpoint, and the threshold has to sit below the age at which stale intelligence costs you a detection. Both of those numbers are properties of your fleet, not of the proof-of-concept.
According to the dev.to writeup, Microsoft has not publicly confirmed the issue as a vulnerability, assigned a CVE, or released a specific patch, and neither independent reproduction nor real-world exploitation has been reported [7]. The same writeup says the required privilege level is not conclusively documented in public reporting and should be verified by independent testing [9]. It also records the original BleepingComputer report of 2026-09-22 under the title "New Windows Defender zero-day blocks Microsoft antivirus updates" [10], while rating the severity high on the grounds that the code is designed to interfere with Defender updates while running locally [15].
The disruption is a local process, and it is not described as remotely exploitable against Defender updates over the network [11]. That puts it with the other post-exploitation tamper techniques: something to hunt. The code is published as the GitHub repository MSNightmare/BigDiskBuster, with no associated malware family [16].
What to watch
- Whether Microsoft confirms the behaviour as a vulnerability and assigns a CVE, which would give patch pipelines something to consume.
- An independent reproduction that pins down the privilege level required to open MRT.exe and monitor the update directories.
- Whether Defender itself starts surfacing repeated update failures to the user or to management telemetry.