Microsoft Defender Hidden Exclusions: How Attackers Evade Audits and What Windows Admins Should Check

The research comes from Huntress, whose endpoint team looked at how attackers abuse Microsoft Defender Antivirus (MDAV) exclusions. The short version: an empty Get-MpPreference result on a compromised host may not mean much.

What the researchers found​

Huntress tested the policy value HideExclusionsFromLocalAdmins, which sits at HKLM\SOFTWARE\Policies\Microsoft\Windows Defender. Once it was set, PowerShell queries run as a local administrator stopped returning the configured exclusions. Huntress also found that the setting hides them from SYSTEM, despite what the name suggests. eSecurity Planet's summary of the research: PowerShell stopped listing the exclusions after researchers turned on the setting. Checks running with SYSTEM-level access also failed to show them.

This is not a vulnerability, and nothing gets deleted. The policy definition published in Windows' administrative templates says that if you enable this setting, Local Admins will no longer be able to see the exclusion list in Windows Security App or via PowerShell. Applying this setting will not remove exclusions, it will only prevent them from being visible to Local Admins. The template lists support for at least Windows Server 2016, Windows 10 Version 1607, with Enabled: 1 Disabled: 0 as the policy state values.

The technique stacks two moves. First the attacker excludes their staging folder from scanning. Then they hide the exclusion. GBHackers described Huntress' finding as attackers combining broad Defender exclusions with the HideExclusionsFromLocalAdmins setting, creating a stealthy defense-evasion path that leaves malicious activity unscanned while obscuring evidence of the change.

The important caveat: this is a post-compromise technique. Writing to Defender's policy keys requires administrative rights. As eSecurity Planet put it, an attacker with enough privileges can enable it after adding malicious exclusions. If someone can do this, they already own the machine. The hiding just makes them harder to find afterwards.

Section summary: HideExclusionsFromLocalAdmins = 1 keeps exclusions active while hiding them from PowerShell, the Windows Security app, and SYSTEM-level queries made through the standard Defender interfaces. It needs admin rights, so it's a tool for staying hidden after a break-in, not for getting in.

How Defender exclusions work​

Exclusions exist for good reasons, such as performance problems or compatibility issues with trusted software. Microsoft's own guidance says you usually don't need them at all. The main types are:

Huntress considers path and extension exclusions the most useful to attackers, because matching content is skipped by scheduled scans, on-demand scans, and real-time protection. Microsoft's documentation adds one nuance: process exclusions apply only to real-time protection, not to scheduled or on-demand scans.

GBHackers explained why broad paths matter: a path exclusion targeting a temporary directory, user profile location, or an entire drive can allow an adversary to download, unpack, and execute payloads without Defender inspection.

Where exclusions are stored​

Huntress traced how the different methods write exclusions:

• PowerShell and WMI (Add-MpPreference, Set-MpPreference, or the MSFT_MpPreference class): the request goes to Defender's engine, MsMpEng.exe, which writes to HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions.
• Group Policy: written to a separate key, HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions.
• Standard queries combine both locations, so neither key on its own is the full picture.

Defender blocks direct writes to its own exclusions key, but the policy key is easier to reach. eSecurity Planet noted that direct changes to Defender's standard exclusions registry key are blocked, but the Group Policy-backed exclusions key can be edited directly. Changes made through that route take effect after a reboot.

One PowerShell detail can bite during cleanup. Microsoft says Set-MpPreference replaces all existing exclusions of the type you specify, while Add-MpPreference and Remove-MpPreference add or remove only the entries you name. Use the wrong one and you can wipe a whole category of exclusions by accident.

The malware examples​

Huntress lists three campaigns that abused exclusions:

• GootKit (2019): created a path exclusion through the MSFT_MpPreference WMI class.
• WhisperGate (2022): used Set-MpPreference to exclude the entire C:\ drive.
• Muddled Libra (2024): listed by Huntress as an exclusion-abuse campaign, with no procedural detail in the published write-up.

These are past cases of exclusion abuse. The research doesn't say that these groups used the hiding policy. The hiding policy is Huntress' finding about what attackers can add on top of an exclusion.

Can you still find hidden exclusions in the registry? It depends​

The sources disagree here, and it matters for anyone writing an audit script.

Huntress says administrators and SYSTEM can still see hidden exclusions by reading the registry directly. eSecurity Planet repeated the claim: administrators can still find the underlying registry values, so the setting hides exclusions from normal Defender tools instead of removing them.

Microsoft's current exclusions documentation says something else. It states that with HideExclusionsFromLocalAdmins enabled, exclusions aren't visible in Get-MpPreference or Registry Editor. An NVISO write-up from 2022 agreed, reporting that when enabled, all exclusions in PowerShell, Windows Security and registry editor are not visible to administrators.

A second complication comes from Microsoft's troubleshooting guidance. Starting in February 2026, organizations that use Microsoft Defender for Endpoint configuration management, on antimalware platform version 4.18.25110.6 or later, can no longer read exclusion values directly from the local registry. Microsoft tells those organizations to use the supported Defender PowerShell cmdlets such as Get-MpPreference instead.

Put those together:

• "Just check the registry" may work in some lab setups. It is not a reliable verification method across a fleet.
• On devices managed by Defender for Endpoint configuration management, direct registry reads of exclusions are no longer supported at all.
• Microsoft's documentation and Huntress' testing differ on whether hidden exclusions show up in Registry Editor. Test it in your own environment before you rely on either.

A practical audit plan for Windows admins​

None of these steps can promise to catch a determined attacker, but together they cover the gaps a PowerShell-only check leaves.

1. Run the standard query, and treat an empty result as unconfirmed. Microsoft's documented one-liner lists all three main categories:
   $p = Get-MpPreference; 'ExclusionExtension','ExclusionPath','ExclusionProcess' | ForEach-Object { $t = $_; $p.$t | ForEach-Object {[pscustomobject]@{Type=$t; Value=$_}} } | Format-Table -AutoSize
   As one Windows how-to site put it, an empty or incomplete list is not always proof that no managed exclusions exist.
2. Check whether the hide policy is enabled. Look for HideExclusionsFromLocalAdmins set to 1 under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender. If your organization never set this policy, finding it is a serious warning sign.
3. Find out where the setting came from. Microsoft's troubleshooting guide recommends running GpResult.exe /h C:\temp\GpResult_output.html from an elevated prompt to review Group Policy. On Intune-managed devices, run mdmdiagnosticstool.exe -out "c:\temp\MDMDiagReport.zip". In the Defender portal, the Effective settings tab on a device's page shows each security setting's actual value and which source configured it.
4. Test suspicious locations one at a time. On Defender Antivirus 4.18.2111-5.0 (December 2021) or later, run MpCmdRun.exe -CheckExclusion -Path <PathAndFile or Path> from an elevated command prompt. "Is excluded" returns exit code 0 and "is not excluded" returns exit code 1. Microsoft notes that a folder exclusion covers everything below it, and the tool doesn't tell you which exclusion entry matched. It won't give you a full list either; it just checks the path you give it. Start with C:\, temp folders, C:\Users, and Downloads. (The available evidence doesn't say whether -CheckExclusion still reports correctly while the hide policy is active, so verify this before depending on it.)
5. Confirm with the EICAR test file. Microsoft documents creating the harmless EICAR test string inside a suspect path or with a suspect extension. If Defender doesn't detect it, an exclusion is in effect. This doesn't work for process exclusions.
6. Watch the registry writes. Huntress built telemetry for exclusion-related registry activity because every method eventually writes to the registry. eSecurity Planet noted that this monitoring also watches for changes to the hiding setting, giving endpoint detection and response tools another chance to catch suspicious activity. Any EDR or SIEM that sees registry events can alert on writes to both exclusion keys and to the HideExclusionsFromLocalAdmins value.

Section summary: Use PowerShell, the hide-policy check, policy-source tools, and per-path testing together. On Defender for Endpoint-managed fleets, trust the management plane over local registry reads.

Hardening: make exclusions harder to plant and easier to spot​

• Pick one way to manage Defender. Microsoft recommends a single management method where possible. Its precedence order puts Defender for Endpoint security settings management and Group Policy above Configuration Manager and Intune, with local PowerShell, MpCmdRun, and WMI at the bottom. Keep an approved list of exclusions in that system so you can spot anything new.
• Turn on tamper protection. Microsoft lists it as one way to protect configured exclusions on devices.
• Use least privilege. Every route in this research needs admin rights. Fewer standing admin accounts means fewer ways for an attacker to add exclusions.
• Use the hide policy yourself, but document it. Microsoft offers the setting so attackers who land on a box can't easily read your exclusion list. If you deploy it, record that, so your analysts don't mistake a "nothing to see here" result for a clean machine.

The bigger picture​

Abusing built-in admin features is nothing new. Attackers have long preferred turning off one quiet setting to switching off antivirus completely, which sets off alarms. Huntress makes the same point: an exclusion is more subtle than disabling MDAV, and hiding the exclusion adds another layer of cover.

The fair counterpoint is that Microsoft documents this policy openly, and an attacker who can set it already has administrative control. That's game over in most threat models. The real gap is in tooling. Scripts, RMM checks, and some security products that ask Defender for its exclusion list through the standard interfaces will get an incomplete answer and report it as complete.

For Windows admins: if your exclusion audit is a single Get-MpPreference call, you can no longer treat a clean result as proof. Check the hide policy, confirm where each setting came from in your management console, and alert on writes to the registry keys involved.