Registry Parser
← All articles

Windows Defender forensics: exclusions and status in the registry

9 min read

Windows Defender writes its configuration into the SOFTWARE hive, and that is good news for the defender working a case. When an attacker tells Defender to ignore a folder, or flips real-time protection off, the change lands in the registry where it persists, carries a LastWrite timestamp, and sits there for anyone with the hive to read. Windows Defender forensics in the registry comes down to two questions you can answer offline: what did Defender stop looking at, and was it even running. The exclusion keys answer the first. A short set of disable values answers the second. Both are high-signal, and attacker-added Defender exclusions are about as close to a smoking gun as registry-only analysis gets.

Where the exclusions live

Exclusions sit under SOFTWARE\Microsoft\Windows Defender\Exclusions, split across three subkeys by type:

  • Exclusions\Paths — files and folders Defender will not scan.
  • Exclusions\Extensions — file extensions Defender skips.
  • Exclusions\Processes — processes whose activity Defender does not inspect.

The structure is the same in all three: the value name is the excluded item, and the data is a throwaway REG_DWORD (typically 0) that nobody reads. So an excluded path like C:\ProgramData\Updater appears as a value named C:\ProgramData\Updater under Exclusions\Paths. This is why a parser surfaces the value names, not the data — the data is meaningless, the name is the evidence. The defender_exclusions plugin enumerates all three subkeys and emits one row per value with two columns, Type and Excluded, where Type is Paths, Extensions, or Processes and Excluded is the value name. That two-column table is the whole artifact: a flat list of everything Defender was told to ignore.

There is a second location you have to check, because the one above is not where policy-pushed exclusions go. Group Policy and Intune-managed exclusions are written under the Policies path, SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions, with the same Paths/Extensions/Processes substructure. The distinction matters operationally. An exclusion under the Policies key was, in principle, pushed by an administrator through GPO or MDM — it should have a paper trail. An exclusion under the non-policy Microsoft\Windows Defender\Exclusions key was set locally, by Set-MpPreference, the Add-MpPreference cmdlet, the Defender API, or a direct registry write by something running with sufficient privilege. Locally-set exclusions are the ones to scrutinise first. Note that the plugin as written reads the non-policy path; the Policies path is a manual pivot you should make by hand, and the two can disagree, which is itself informative.

Why an attacker-added exclusion is a high-signal IOC

Most registry artifacts require interpretation. A Run key might be legitimate software. A new service might be a vendor agent. An exclusion is different, because there is almost never a benign reason for malware's own working directory to be on Defender's ignore list, and yet that is exactly what an attacker writes. The pattern is mechanical: drop the payload to C:\ProgramData\<name> or %APPDATA%\<name>, add that folder to Exclusions\Paths, and Defender stops scanning the one place the malware lives. Ransomware operators do this constantly before detonation. So do loaders that want a staging directory the AV will never touch.

So when triaging the exclusion list, the question is not "is this an exclusion" — it is "would an administrator ever have typed this." The high-signal cases:

  • A path exclusion pointing into a user-writable directory. %APPDATA%, %LOCALAPPDATA%, \Users\<name>\, \Temp\, or a freshly-created folder under \ProgramData\. Legitimate exclusions usually cover a vendor application directory under Program Files, a database data folder, or a build server's workspace — not a user's temp folder.
  • A process exclusion for something that is not a known application. Excluding MsMpEng.exe from itself makes no sense; excluding svchost.exe or powershell.exe is a way to blind Defender to living-off-the-land execution. An excluded process named like a system binary but with no legitimate reason to be exempt is a tell.
  • An extension exclusion for executable content. Excluding .exe, .dll, .ps1, or .bat is rarely a defensible administrative choice and is a blunt way to neuter scanning across the whole disk.

The reason this is such a good hunting pivot, not just a triage artifact, is that exclusions persist. They are not a runtime state that evaporates on reboot — they are a registry value that stays until something removes it. An attacker who added an exclusion months ago and then cleaned up other traces frequently leaves the exclusion behind, because it looks like configuration rather than malware. Sweep exclusion lists across a fleet, normalise the paths, and the outliers — the one host with a path exclusion no other host has, the one machine excluding a \Temp\ subfolder — surface fast. The folder named in the exclusion is then a direct lead: go look at what is, or was, in it, even if the binary is long gone. Correlate the exclusion key's LastWrite against your suspected intrusion window and you have a timestamp for when the attacker touched Defender.

Reading the status: was protection actually on

The second question — was Defender running at all — is answered by a small set of REG_DWORD toggles. The defender_status plugin reads them from two locations and emits a Field/Value table.

From the Defender root key SOFTWARE\Microsoft\Windows Defender:

  • DisableAntiSpyware — the master kill switch. Set to 1, the antimalware engine is told to stand down. Historically this was the single value that disabled Defender wholesale.
  • DisableAntiVirus — the companion antivirus disable value.

From the Real-Time Protection subkey, SOFTWARE\Microsoft\Windows Defender\Real-Time Protection:

  • DisableRealtimeMonitoring — set to 1, on-access scanning is off. Files can be written and executed without the real-time engine inspecting them. This is the value to read when you want to know whether the door was open at a given moment.
  • DisableBehaviorMonitoring — set to 1, behavioural detection is off, so even fileless and in-memory techniques that the real-time scanner might have flagged behaviourally go unseen.

The interpretation convention is the inverse you would expect: these are Disable values, so 1 means the protection is off and 0 (or absent) means it is on. The plugin surfaces the raw value as a string and lets you read it; do not let the double negative trip you up. An absent value is not the same as 0 in every code path Windows uses, but for triage, treat a missing DisableRealtimeMonitoring as "real-time was not disabled via this value" and move on. The pattern that should stop you is a 1, or a recently-written value at all.

A note on what the registry does not settle. These values describe configured intent, not a guaranteed runtime outcome — Defender's actual state at any instant also depends on tamper protection, policy precedence, and whether another AV registered and stood Defender down. Read the registry for what was configured, then corroborate with the Defender operational and Windows event logs (the Defender Operational log and the security state-change events) for what actually happened on the timeline. The hive tells you the setting; the event logs tell you when it took effect.

Tamper protection, and why these keys can lie

The reason the modern values matter so much is tamper protection. Since the feature shipped, Defender protects its own configuration: a process trying to write DisableRealtimeMonitoring directly is supposed to be blocked, and tamper protection state itself is held in protected storage rather than a freely-writable SOFTWARE value. So on a current, healthy machine an attacker often cannot just flip these DWORDs — which is exactly why an attacker who got them flipped anyway is significant. A DisableRealtimeMonitoring=1 that succeeded tells you tamper protection was off, or was bypassed, or the change predates it. Any of those is worth running down.

The corollary for the analyst: do not read these four values in isolation and conclude Defender was healthy because they are all 0 or absent. Tamper protection, policy-pushed disables under SOFTWARE\Policies\Microsoft\Windows Defender, and a third-party AV taking over the antivirus role all change the real picture. The registry values are necessary evidence, not sufficient evidence. Read them, then corroborate.

How this maps to detecting defense evasion

This whole surface is MITRE ATT&CK T1562.001, Impair Defenses: Disable or Modify Tools, and the two halves of this post map onto two halves of that technique. Disabling the engine via DisableAntiSpyware / DisableRealtimeMonitoring is the "disable" half. Adding exclusions so the engine keeps running but ignores the attacker's files is the "modify" half — arguably the sneakier one, because the AV stays green in the console while a hole is punched in its coverage. A defender who only checks "is Defender running" misses the second case entirely. Check both. For the full breakdown of the technique, the detections, and the other tooling attackers reach for, see the dedicated T1562.001 Impair Defenses post.

The detection logic for the registry side is straightforward and worth wiring into your hunt:

  • Alert on writes to the exclusion keys. Any creation of a value under Microsoft\Windows Defender\Exclusions\Paths|Extensions|Processes (or the Policies equivalent) by something other than your management tooling is suspicious. Live, this is a registry-write event you can build a rule on; offline, it is the exclusion list and its key LastWrite.
  • Alert on Disable* values being set to 1. Especially DisableAntiSpyware and DisableRealtimeMonitoring. On a tamper-protected box, a successful write here is high fidelity by itself.
  • Diff against a baseline. Exclusions and disable state are configuration; they should be stable across a fleet. The outlier host is the lead.

Tools

  • RegRipper. The defender family of plugins reads the Defender keys, including exclusions and the real-time protection settings. Read the plugin source to confirm exactly which values your version emits — coverage has shifted across releases. For the full catalogue of what RegRipper pulls from each hive, see the RegRipper plugins reference.
  • Eric Zimmerman's RECmd with a Defender batch file — same keys, CSV out, trivial to diff between hosts.
  • The parser on this site surfaces both: a flat Type / Excluded table for everything under the three exclusion subkeys, and a Field / Value table for DisableAntiSpyware, DisableAntiVirus, DisableRealtimeMonitoring, and DisableBehaviorMonitoring. Drop the SOFTWARE hive in and analyze a SOFTWARE hive in your browser — nothing is uploaded.

The bottom line

Windows Defender exclusions and status are among the cleanest defense-evasion artifacts in the registry. Exclusions are a list of value names under three subkeys; an exclusion pointing at a user-writable folder, a system process, or an executable extension is rarely benign and almost always points straight at the attacker's working directory. The disable values are four inverted DWORDs — 1 means off — that tell you whether protection was even configured to run, with the heavy caveat that tamper protection, policy, and third-party AV all shape the real outcome. Read the registry for intent, corroborate with the event logs for effect, and remember that exclusions persist long after the malware is gone, which makes them one of the better fleet-wide hunting pivots you have.