Defender can report protected while its updates stall: how to prove signatures are current across an estate

About 20 missed updates can still read as up to date

Microsoft's own Defender for Endpoint device health report counts a device's security intelligence as up to date if that version was published in the past seven days. Microsoft says it typically publishes new malware definitions three times a day. Put those two documented figures together and a device can sit on a version that is about 20 releases behind (seven days at three a day is 21 releases, one of which is the version it holds) and still land in the green bucket. A device that stops reporting altogether for more than seven days is not shown as out of date at all. It moves to Unknown.

That arithmetic matters this week because a researcher has published a second tool whose stated purpose is to stop Microsoft Defender Antivirus taking signature and platform updates, leaving a device on whatever protection it already had. The tool is called BigDiskBuster. It was released over the weekend of 19 and 20 September 2026, BleepingComputer reported on Tuesday 22 September, and Microsoft had not commented when the report was published.

What the arithmetic does not establish is equally important. It does not show that BigDiskBuster evades any of Microsoft's reports, and no source says it does. It does not show that anyone is using the tool against real organisations: no exploitation in the wild is reported. It is a statement about how wide the reporting window is, and so about how long a stalled device can look fine to a team that only watches the summary tiles.

What was disclosed, and what is not on the record

The effect, in the researcher's own description as quoted by BleepingComputer, is that while the tool runs in the background Defender cannot complete platform or signature updates, so the device stays on its current versions. The researcher said it appears to work on all supported Windows versions and described the proof of concept as buggy and in need of rewriting.

The researcher, Abdelhamid Naceri, who also publishes as Nightmare Eclipse, compared it to UnDefend, an earlier tool released in April that BleepingComputer says allowed standard users to block definition updates. BleepingComputer counts almost a dozen Windows and Defender zero-days released by the same researcher since April 2026, some of which Microsoft has since fixed and some of which remain unpatched.

What the record says about BigDiskBuster on 22 September 2026, from BleepingComputer's report and Microsoft's Security Update Guide

Question	Stated	Not stated
What does it affect?	Microsoft Defender Antivirus platform and signature updates, on all supported Windows versions, per the researcher	Any independent test of that claim
Has Microsoft acknowledged it?	A Microsoft spokesperson was not immediately available to comment	Any Microsoft statement, blog or advisory
Is there a CVE or fix?	No new Defender denial of service entry in the Security Update Guide when checked on 22 September	Whether Microsoft treats it as a vulnerability, or when a fix might ship
Is it exploited in the wild?	No exploitation reported	Any telemetry either way
What access does an attacker need?	The tool must be running in the background on the device	The privilege level it needs; the standard user claim was made for UnDefend, not for this tool
Does tamper protection stop it?	Nothing	Whether tamper protection, or any Defender detection, blocks or flags it

The last two rows carry the practical point. Whatever privilege the tool needs, it has to be running on the device. An attacker who can do that already has code execution on the endpoint, so a device whose updates stop without explanation should be treated as a possible intrusion, not only as a maintenance ticket. That is an inference from the report, not a finding in it.

The precedent: an update block Microsoft rated Low and CISA listed as exploited

There is a direct precedent for how this class of problem ends up on the record. On 19 May 2026 Microsoft published CVE-2026-45498, a Microsoft Defender denial of service vulnerability, in its Security Update Guide. BleepingComputer reported at the time that this CVE is UnDefend; Microsoft's own entry does not use that name, so treat the link as secondary reporting.

CVE-2026-45498 on the record, from the MSRC Security Update Guide, the NVD record and CISA's KEV catalogue, fetched 22 September 2026

Field	On the record	What it does not tell you
Microsoft severity	Low, CVSS 3.1 base score 4.0, local attack vector, no privileges required	Why a low score still made the exploited list
NVD score	7.5, network attack vector, high availability impact	Why NVD and Microsoft disagree on the vector
Exploited	Microsoft: Exploitation Detected. CISA added it to KEV on 20 May 2026	Who exploited it, or how widely
Affected	Defender Antimalware Platform up to 4.18.26030.3011	Whether older platforms still in your estate are affected
Fixed	Platform 4.18.26040.7, delivered automatically, no customer install action	Whether your devices actually received it
KEV deadline	3 June 2026, 14 days after listing, for US federal agencies	Anything binding on UK organisations

Two points carry over to BigDiskBuster. First, Microsoft fixed the earlier flaw in the Defender platform, which updates itself, so the fix only helps devices whose updates work. A tool that blocks updates therefore also blocks the fix for the tool, which is why the verification steps below matter more than any single patch. Second, the MSRC entry itself tells customers to check. In its FAQ Microsoft says best practice is to "regularly verify whether software distribution" of platform and definition updates "is working as expected in their environment."

A simple assurance check follows directly: any Windows device reporting a Defender platform version below 4.18.26040.7 is still exposed to CVE-2026-45498, four months after the fix. On 22 September 2026 Microsoft's security intelligence page listed the current releases as security intelligence 1.459.333.0, engine 1.1.26080.3 and platform 4.18.26080.4.

A green status is a switch, not a version

The friendly name here is "protected". Most of the fields that feed a green tick in a console answer the question "is Defender switched on?" They do not answer "is Defender current?" A tool whose stated effect is to freeze updates, while leaving the antivirus running, is aimed precisely at the gap between those two questions.

Common Defender health signals, what each one establishes and what it does not, from Microsoft Learn

Signal	What it establishes	What it does not establish
AntivirusEnabled, RealTimeProtectionEnabled = True	Scanning and real-time protection are on	That the signatures doing the scanning are recent
AMRunningMode = Normal	Defender is the active antivirus, not passive	Anything about update state
IsTamperProtected = True	Protected settings cannot be changed	That updates are arriving; tamper protection guards settings
Event 1150, hourly	The client is running and reporting	Currency, although the event carries the versions you can compare
Device health card: Up to date	Signature published within 7 days, device reported within 7 days	That the device has the latest of roughly 21 releases in that window
Device health card: Unknown	The device has not reported for more than 7 days	That it is out of date, although it may well be
Intune Unhealthy endpoints list is empty	No device reported a detected issue	That every device is current; clean devices are not listed at all

None of these signals is wrong. Each answers a narrower question than a dashboard label suggests. The control is the version and age data underneath them, compared against what Microsoft has actually released.

On the device: the fields that prove currency

Get-MpComputerStatus returns the local truth. Microsoft's class reference defines the fields that matter for this purpose:

• AntivirusSignatureAge: signature age in whole days. If signatures have never updated, the value is 65535.
• AntivirusSignatureLastUpdated: local time of the last signature update, null if it has never updated.
• AntivirusSignatureVersion: the signature version, to compare with Microsoft's published current version.
• AMEngineVersion: the antimalware engine version.
• AMProductVersion: the product version. Microsoft's platform releases take the 4.18 form, so this is the field to compare with the platform versions above (our reading of the field, which the class reference labels simply as product version).
• IsTamperProtected and RealTimeProtectionEnabled: the pair Microsoft's tamper protection guide says to read together.

One detail changes how you set thresholds. Microsoft's description of the 1151 health report event says antivirus signature age is calculated from the release date of the security intelligence update, not from when the device installed it. Age therefore measures how far behind Microsoft the device is, which is what you want.

# One device: currency fields, not only status fields
Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled, RealTimeProtectionEnabled, IsTamperProtected, AntivirusSignatureVersion, AntivirusSignatureLastUpdated, AntivirusSignatureAge, AMEngineVersion, AMProductVersion

# Many servers over CIM: list only those at or beyond your age threshold
$s = New-CimSession -ComputerName (Get-Content .\servers.txt)
Get-MpComputerStatus -CimSession $s | Where-Object AntivirusSignatureAge -ge 2 | Select-Object PSComputerName, AntivirusSignatureAge, AntivirusSignatureLastUpdated, AMEngineVersion, AMProductVersion

For estates without Defender for Endpoint or Intune reporting, this is the cheapest assurance available: it needs only Windows remote management, which many server teams already have. For laptops that are rarely on the corporate network, the portal reports below are more practical.

In the event log: alert on silence, not only on failure

Defender writes its update history to the Windows Defender Operational log (Applications and Services Logs, Microsoft, Windows, Windows Defender, Operational). Microsoft's documented event list includes a clear set of update events:

Update and health related events in the Microsoft-Windows-Windows Defender/Operational channel, from Microsoft Learn's event reference

Event ID	Microsoft's meaning	Use in monitoring
2000	Antimalware definitions updated successfully	The heartbeat: alert when it stops
2001	Security intelligence update failed, with update stage and source	Alert, and group by source to spot a broken WSUS or share
2002 / 2003	Engine updated / engine update failed	Alert on 2003
2004	Problem loading definitions, reverting to last known good	Alert: the device may be running older signatures
2005	Engine could not load because the platform is out of date	Alert: platform is stuck
2006	Platform update failed	Alert
2007	Platform will soon be out of date	Warn
1150	Client running and healthy, hourly, with platform, signature and engine versions	Proof of life: compare versions
1151	Client health report, including signature age in days	Feed the age straight into your threshold
5001 / 5007 / 5013	Real-time protection disabled / configuration changed / tamper protection blocked a change	Alert: possible interference

The failure events are useful, but no source says whether BigDiskBuster causes Defender to log 2001 or 2006, or causes nothing to be logged. A rule that only fires on failure events assumes the failure is noisy. A rule that fires when a device keeps sending 1150 proof of life but has logged no 2000 success for longer than your threshold does not depend on that assumption. That design choice is ours, built from Microsoft's documented events, not a Microsoft recommendation.

# Recent update and interference events on one device (read only)
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 500 |
  Where-Object Id -In 2000,2001,2003,2004,2005,2006,2007,5001,5007,5013 |
  Select-Object TimeCreated, Id, Message

In the portal: what Defender for Endpoint and Intune actually measure

Defender for Endpoint device health report. In the Microsoft Defender portal, Reports, then Device health and compliance, the Microsoft Defender Antivirus health tab has eight cards, including engine, security intelligence and platform version cards and three up-to-date cards. Microsoft documents the logic precisely:

• Engine and platform are up to date if the device reported within seven days and its build is at least the most recent monthly release, with a three day grace period after release through Windows Update.
• Security intelligence is up to date if the version on the device was written in the past seven days and the device reported in the past seven days.
• If the device has not reported for more than seven days, all three show as Unknown, whatever its real state.
• Unknown can also mean the device is off the network, powered down, has Defender disabled, lacks cloud protection or does not meet the version prerequisites.

The report needs Defender for Endpoint Plan 2 or Defender for Business, and the View Data, Threat and vulnerability management permission. Microsoft sells those licences, and the richer estate reporting sits behind them; the Get-MpComputerStatus and event log routes above cost nothing extra.

Export it and keep it. The device antivirus health export API returns fields including avSignatureVersion, avEngineVersion, avPlatformVersion and avIsSignatureUpToDate, avIsEngineUpToDate and avIsPlatformUpToDate, all filterable. Microsoft states the data is a current snapshot with no history, so to see a device stop moving you have to store the snapshots yourself. The JSON method is rate limited to 30 calls a minute and 1,000 an hour.

Advanced hunting. Microsoft's reference for the DeviceTvmSecureConfigurationAssessment table gives an example query for devices with non-compliant antivirus configurations, and the tamper protection guide gives a query for tampering attempts:

// Microsoft's example: devices with antivirus configuration issues
DeviceTvmSecureConfigurationAssessment
| where ConfigurationSubcategory == 'Antivirus' and IsApplicable == 1 and IsCompliant == 0
| join kind=leftouter (
    DeviceTvmSecureConfigurationAssessmentKB
    | project ConfigurationId, ConfigurationName, ConfigurationDescription, RiskDescription, Tags, ConfigurationImpact
) on ConfigurationId
| project DeviceName, OSPlatform, ConfigurationId, ConfigurationName, ConfigurationDescription, ConfigurationImpact

// Microsoft's example: tampering attempts in the last 10 days
DeviceEvents
| where Timestamp > ago(10d)
| where ActionType == "TamperingAttempt"

Intune. Reports, Microsoft Defender Antivirus, gives the Antivirus agent status report (real-time and network protection state, Defender status, tamper protection, now labelled controlled configuration) and the Detected malware report. Endpoint security, Antivirus, Unhealthy endpoints lists only devices with detected issues, so an empty list is not a clean bill of health. Windows compliance policy can require Microsoft Defender Antimalware security intelligence up-to-date, which reads the Defender/Health/SignatureOutOfDate CSP, and can set a minimum antimalware version. Setting the minimum version to the platform build that fixed CVE-2026-45498 turns that fix into a compliance gate, which can in turn feed Conditional Access.

Where each reporting route draws its line, from Microsoft Learn

Route	Threshold it applies	Blind spot
Get-MpComputerStatus	Whatever you set	Needs remote reach to each device
Event log and SIEM	Whatever you set	Only as good as forwarding; failure events may not fire
MDE device health	7 days for signatures; latest monthly build plus 3 days for engine and platform	Silent over 7 days becomes Unknown
MDE export API	Same as the report	No history unless you store it
Intune compliance	The device's own out of date flag	Depends on the device-side threshold

Tamper protection guards settings, not the supply line

Tamper protection is the second friendly name. Microsoft's overview lists what it locks when enabled on Windows, and one item on that list is that "security intelligence updates occur". It is easy to read that as a guarantee that updates arrive. The documented mechanism is narrower: tamper protection prevents protected settings from being disabled or changed, and Event 5013 records a blocked change. Nothing in Microsoft's documentation or in the BleepingComputer report says whether tamper protection stops a tool like BigDiskBuster.

Keep tamper protection on regardless; it closes the older, simpler route of switching Defender's settings off, and Defender Vulnerability Management raises a security recommendation for devices where it is off. Then measure updates separately, because a settings lock cannot tell you whether the update source is reachable or the update completed.

The monitoring loop

The loop has one weak joint that no product fixes by default: the gap between the update source and the report. Microsoft's fallback logic moves a device to the next configured update source only when the current update is considered out of date, which by default is seven consecutive days of failing to apply updates from WSUS or Microsoft Update. The device-side threshold is configurable through the Group Policy setting "Define the number of days before virus security intelligence is considered out of date", and a catch-up update can be forced after a set number of days with SignatureUpdateCatchupInterval. Tightening those settings shortens the time before a device flags itself, but a device-side setting will not help if something on the device is stopping updates, which is why the alert belongs off the device.

Pick a threshold tighter than seven days

Seven days is Microsoft's reporting window, not a recommendation to wait seven days. For always-connected servers and desktops, an AntivirusSignatureAge of 2 days or more is already abnormal if updates arrive several times a day, and it is where we would set a first alert. That figure is editorial judgement, not Microsoft guidance; pick your own, write it down, and alert on it.

For laptops, the right comparison is between Signature refresh time (when the device last reported update status) and Security intelligence publish time (the release date of the version it holds). A device that reports every day but whose publish time stops moving is the pattern a frozen update produces. A device that stops reporting is a different problem, and belongs in a separate Unknown queue that someone actually works, rather than a slice of a pie chart.

What to do this week, in order

The question that exposes the gap

BigDiskBuster may turn out to be buggy, fixed quickly or never used in anger. The earlier update block was exploited and fixed in a self-updating component, which means its fix reached only the devices whose updates worked. The assurance problem is the same whichever tool comes next.

So the question for any IT manager is this: if one of your devices stopped taking Defender updates at nine o'clock this morning, which person, looking at which report, would know by tomorrow, and would their report say "out of date", "Unknown" or still "up to date"?