Audit and minimise Microsoft Defender exclusions

Every Microsoft Defender exclusion is a place where the antivirus deliberately looks away. Most were added for a good reason at the time (a slow build server, a vendor support call, a false positive), then forgotten. Ransomware operators know this: listing and adding exclusions is one of the first things they do with admin rights, and a folder that is already excluded is the ideal place to stage tools.

The Defender hardening pillar lists the warning signs. This guide is the full audit: find every exclusion from every source, decide which ones survive, make the survivors narrow, then stop the list growing back.

The kinds of exclusion to look for

"Exclusions" is not one list. An audit that only checks ExclusionPath misses most of them.

Also check the server role automatic exclusions are not disabled (DisableAutoExclusions should be false), because turning them off usually leads someone to add a much broader manual list.

Step 1: collect from every source

Exclusions come from Group Policy, Intune, Configuration Manager and local configuration, and Defender merges them unless you have disabled local merge. Start with the effective list on a sample of devices, run as an administrator or SYSTEM:

$p = Get-MpPreference
[pscustomobject]@{
  Computer   = $env:COMPUTERNAME
  Paths      = $p.ExclusionPath -join '; '
  Extensions = $p.ExclusionExtension -join '; '
  Processes  = $p.ExclusionProcess -join '; '
  AsrOnly    = $p.AttackSurfaceReductionOnlyExclusions -join '; '
  CfaApps    = $p.ControlledFolderAccessAllowedApplications -join '; '
  AllowIds   = $p.ThreatIDDefaultAction_Ids -join '; '
}

Run it through your management tool, collect a CSV per device, and group by value to see which exclusions are fleet-wide and which are one-offs.

Then read the sources, so you know who added each one:

# Group Policy-delivered exclusions
Get-ChildItem "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions" -Recurse |
  ForEach-Object { $_.Name; $_.GetValueNames() }

# Locally added exclusions (only readable as SYSTEM on recent platforms)
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows Defender\Exclusions" -Recurse

In Intune, check every Endpoint security > Antivirus profile and any Antivirus exclusions profile, plus settings catalog profiles using the Defender CSP (ExcludedPaths, ExcludedExtensions, ExcludedProcesses). In Group Policy, the setting is Computer Configuration > Policies > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Exclusions. Get-GPOReport -All -ReportType Xml and a search for Exclusions finds every GPO that sets them.

To test a single path on a device, recent platforms support:

& "$env:ProgramFiles\Windows Defender\MpCmdRun.exe" -CheckExclusion -path "D:\Build\out"

Attackers use the same technique to find excluded folders, so it also belongs on your list of command lines to watch.

Step 2: judge each exclusion

For every entry, answer four questions and write the answers down:

1. Who owns it? A named person or team, not "the vendor".
2. Why does it exist? Performance, a false positive, a vendor requirement. Keep the ticket or document.
3. Is it still needed? Is the software still installed? Has the vendor fixed the false positive? Is the performance problem real on current Defender?
4. Is it as narrow as possible? A specific file rather than a folder, a folder rather than a drive, a path rather than a process.

Anything without an owner after a reasonable chase gets removed in the next ring, with monitoring for the fallout.

Step 3: replace broad exclusions with narrow ones

Two technical details catch people out:

• Environment variables are resolved in the SYSTEM context. %APPDATA% in an exclusion points at the system profile, not the user's. Use explicit paths or supported wildcards, and check the result with -CheckExclusion.
• Process exclusions apply to what the process opens, not to the process image, and only to real-time protection (not scheduled or on-demand scans). Excluding an interpreter by name exempts every script it reads.

For build servers and developer machines, consider performance mode on a Dev Drive (Windows 11) instead of folder exclusions: Defender scans files asynchronously on the Dev Drive rather than not at all. For a false positive, submit the file to Microsoft and use a Defender for Endpoint Allow indicator on the file hash, which covers exactly one file, rather than a path.

Step 4: stop the list growing back

• Disable local merge. Microsoft Defender Antivirus > Configure local administrator merge behavior for lists = Disabled (Intune: DisableLocalAdminMerge). Locally added exclusions, including an attacker's, are then ignored.
• Hide exclusions from local admins. Microsoft Defender Antivirus > Exclusions > Control whether or not exclusions are visible to Local Admins = Enabled (Intune: HideExclusionsFromLocalAdmins). Enabling it implicitly enables the Local Users variant from the pillar; exclusions still apply but no longer show in the Windows Security app, Get-MpPreference or Registry Editor, so an attacker with admin rights has no ready-made map. The Defender CSP lists it for Windows 10 1809 and later.
• Tamper-protect exclusions. With Tamper Protection on, Defender also protects exclusions from local modification when all of these hold: platform 4.18.2211.5 or later, DisableLocalAdminMerge enabled, the device managed only by Intune or only by Configuration Manager (co-management isn't supported) with the Defender for Endpoint sensor running, and exclusions delivered by that tool. HKLM\SOFTWARE\Microsoft\Windows Defender\Features\TPExclusions = 1 indicates this is active.
• Require a change process. New exclusions go through a ticket with owner, justification and review date, and live in one central policy per scope, not scattered across GPOs.

Step 5: monitor changes

Defender logs every configuration change as event 5007 in Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational, with the old and new value. An exclusion appears as a registry path under Windows Defender\Exclusions:

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Windows Defender/Operational'; Id = 5007 } |
  Where-Object Message -match 'Exclusions' |
  Select-Object TimeCreated, Message

With Defender for Endpoint, advanced hunting catches changes across the fleet:

DeviceRegistryEvents
| where RegistryKey has @"Windows Defender\Exclusions"
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, InitiatingProcessCommandLine

Alert on any exclusion change outside your change window, and on Add-MpPreference or Set-MpPreference with -Exclusion in PowerShell script block logs. Remember that AV exclusions do not blind the EDR sensor: Defender for Endpoint still records activity in excluded paths, which is what makes the detection above possible.

Servers and special cases

Servers carry the longest and oldest exclusion lists, usually copied from vendor documents written for Windows Server 2008. Work through them role by role:

• Domain controllers. Automatic exclusions already cover the AD DS database, logs and SYSVOL. Remove manual duplicates, and treat any broad exclusion on a DC (a whole drive, C:\Windows\Temp) as a high-severity finding, because a DC is where an attacker most wants to stage tools unseen.
• SQL Server, Exchange and backup servers. Vendors publish precise lists. Compare yours with the current version, not the one from the original installation; many lists have become shorter.
• Hyper-V and VDI hosts. Exclude the virtual disk and configuration file locations the documentation names, not the whole volume. For non-persistent VDI, follow Microsoft's VDI guidance for shared security intelligence and scan scheduling rather than excluding the golden image.
• Developer workstations. Exclusions here tend to be the broadest in the estate. Prefer Dev Drive performance mode and narrow build-output paths, and keep these devices under controlled folder access audit so you can see what the build tools actually touch.

What breaks

Removing exclusions can bring back the problem they were added for:

• Performance: databases, backup agents and build tools slow down. Measure with the Defender performance analyzer (New-MpPerformanceRecording and Get-MpPerformanceReport) before re-adding anything, and exclude the specific hot path it identifies.
• False positives on in-house tools. Sign them and submit them to Microsoft.
• Vendor support: some vendors refuse support without their list. Negotiate the narrowest version and record the exception.

Remove in rings, as with any other change, and keep a rollback policy ready.

Checklist

• Effective exclusions collected from a representative sample, grouped by value
• Every GPO, Intune profile and ConfigMgr policy with exclusions identified
• ASR, CFA, threat-action and Defender for Endpoint allow lists included in the audit
• Each exclusion has an owner, reason and review date, or is removed
• No user-writable folders, interpreters or executable extensions excluded
• Local admin merge disabled; exclusions hidden from local admins
• Exclusions tamper-protected where supported
• Event 5007 and exclusion registry changes alerted