Analysing BigDiskBuster, the Microsoft Defender Update Blocker

Jump to section

1. What BigDiskBuster really does?
2. Can BigDiskBuster be repurposed?
3. BigDiskBuster detection:

Last week Nightmare Eclipse open sourced BigDiskBuster – although I can see that now all the repositories have been made private. This post is my analysis of this tool that many news outlets called a “0day” initially. In reality, it is a class of defense-evasion tools that never touches a security product – Windows Defender in this case. It does not involve a driver unload, or a service stop, not even a registry edit. All these are signals that a typical tamper protection is watching for. The tool just fills the hard disk space that the product needs to install its next update, and waits.

What BigDiskBuster really does?

Looking at the code – and my Qwen3.8-27B-OBLITERATED, this is what the BigDiskBuster is coded to do:

1. Resolves NtQueryVolumeInformationFile from ntdll.dll at static-initialization time. If the resolve fails, main stops immediately.
2. Opens \??\C:\ as a directory handle with FILE_READ_DATA | FILE_READ_ATTRIBUTES | SYNCHRONIZE and FILE_SYNCHRONOUS_IO_NONALERT. On a directory, FILE_READ_DATA is the same access bit as FILE_LIST_DIRECTORY, which is what ReadDirectoryChangesW requires.
3. Opens %windir%\System32\MRT.exe relative to that handle with FILE_EXECUTE | FILE_READ_DATA and ShareAccess = FILE_SHARE_READ. Since write and delete sharing are both denied, nothing else can replace or delete MRT.exe while this handle is open. The Malicious Software Removal Tool is pinned at its current version. Note the code prints the failure and keeps going, so this is opportunistic rather than required.
4. Calls ReadDirectoryChangesW on the C:\ handle with bWatchSubtree = TRUE and a filter of FILE_NAME | DIR_NAME | SIZE. This is a recursive watch on the entire system volume.
5. On FILE_ACTION_ADDED, checks whether the new directory is either ProgramData\Microsoft\Windows Defender\Platform\<something> or ProgramData\Microsoft\Windows Defender\Definition Updates\{GUID}. The GUID form is validated by feeding the name to CLSIDFromString. Either match means a Defender platform or security-intelligence update has started staging.
6. Spawns a worker thread that queries free space with FileFsFullSizeInformation, then calls NtCreateFile with AllocationSize set to the entire remaining free space, creating a hidden, GUID-named, extensionless file in %TEMP% with FILE_DELETE_ON_CLOSE. It loops while the status is STATUS_DISK_FULL, re-querying free space each pass, which converges on zero bytes free.
7. Watches for the update staging directory being removed, which it reads as “the update failed.” At that point it closes every allocation handle, the delete-on-close semantics free all the space, and it resets to a clean state waiting for the next update attempt.

There is a second thread that watches the Platform directory specifically, so a rollback there also triggers the release.

There are a few issues with the code that I did not spend time fixing, as they were outside the scope of this effort. That said, they are straightforward to address if required. But, if and when the code works, the premise is promising as none of the execution needs Administrator rights. Writing to %TEMP% is a user-level operation. Standard users hold Read and Execute on the root of C:\ by default, which covers the FILE_LIST_DIRECTORY access the watch needs. Opening MRT.exe for read and execute is also a user-level operation.

Can BigDiskBuster be repurposed?

Now that the source is available, can anyone repurpose BigDiskBuster to block other similar tools? Short answer – yes! Long answer – you remove the Windows Defender path strings and all you need are the five conditions to be true to make it fit, rather block other similar tools:

1. The product stages updates on disk before activating them. Anything – signatures, engine updates, and platform packages are downloaded, extracted, and verified on disk. Nearly every endpoint agent does this, because you cannot swap a running engine atomically without a staging area.
2. The staging volume is writable by a lower-privileged entity. Most agents stage under %ProgramData% or %ProgramFiles% on the system volume, which is the same volume holding every user’s %TEMP%. Free space is a single shared pool with no partition between the attacker and the product.
3. Update failure is non-fatal and non-escalating. The agent logs an error and keeps running on the content it already has. If it failed closed, or raised a high-severity alert on the first failure, the technique would be self-defeating.
4. No space is reserved or quota-enforced for the agent. If the product pre-reserved its staging area at install time, an attacker filling the rest of the volume would not touch it.
5. The attacker can fill the pool. Either opportunistically, watching for an update as this sample does, or simply by pre-filling and holding.

This can also potentially lead to other effects such as Windows Updates failing, Windows event logs stop recording and other application installers, browsers that write to the Temp folder also start misbehaving.

BigDiskBuster detection:

I have tried to map open source detection technologies and their functionality to detect BigDiskBuster like activity. These are:

Six signals, roughly in order of how much I trust them.

Signal	Source	False Positive Risk
Defender update failure with a disk-full error code	Windows Defender Operational 2001 / 2003 / 2006	Very low
File create with hidden + delete-on-close + deny-write share	ETW Kernel-File 30	Very low
Non-Microsoft process holding MRT.exe with deny-write share	ETW Kernel-File 12	Low
Hidden GUID-named extensionless file in Temp	Sysmon 11 + 26	Low with regex
Free space collapse then recovery	osquery logical_drives	High alone
Signature age climbing	Windows Defender 1151	Low, slow

The following Sigma rules can be found in my GitHub repository:

1. Burst of GUID-named temp file creations.yaml
2. Correlation, file activity plus Defender update failure.yaml
3. Defender update failure with disk-full status.yaml
4. Hidden GUID-named file created in a temp directory.yaml
5. Low disk space warning.yaml
6. Microsoft Defender Update Failure.yaml
7. Create Microsoft Defender Update Failure.yaml
8. Same file created and deleted in quick succession.yaml

There is also a BigDiskBuster.xml Sysmon config file that you can use and now for ETW. The Microsoft-Windows-Kernel-File provider carries the exact create flags to help you detect this activity. Enable provider GUID {edd08927-9cc4-4e65-b970-c2560fb5c289} to get:

Keyword	Mask
KERNEL_FILE_KEYWORD_FILENAME	0x10
KERNEL_FILE_KEYWORD_FILEIO	0x20
KERNEL_FILE_KEYWORD_CREATE	0x80
KERNEL_FILE_KEYWORD_DELETE_PATH	0x400
KERNEL_FILE_KEYWORD_CREATE_NEW_FILE	0x1000

Run the following command to enable this:

logman create trace BDB-FileWatch -ets -p "{edd08927-9cc4-4e65-b970-c2560fb5c289}" 0x1000 0x4 -o C:\ETW\bdb-filewatch.etl -bs 64 -nb 32 128 -max 512 -mode Circular

To also catch the MRT.exe handle lock add the CREATE keyword:

logman update trace BDB-FileWatch -ets -p "{edd08927-9cc4-4e65-b970-c2560fb5c289}" 0x1480 0x4

Know that this is noisy. Stop with logman stop BDB-FileWatch -ets.

That’s all folks!