Skip to content

Antivirus exclusions for the Nanitor agent

If your antivirus or endpoint security software is blocking the Nanitor agent, adding an exclusion for the agent process or installation directory will allow it to run normally.

What to exclude

The Nanitor agent binary is nanitor-agent-bin.exe. It can run from two locations depending on whether an upgrade has been applied:

  • C:\Program Files\Nanitor\Nanitor Agent\nanitor-agent-bin.exe (base installation)
  • C:\Program Files\Nanitor\Nanitor Agent\versions\<version>\nanitor-agent-bin.exe (after upgrade)

The most reliable approach is to exclude by process name (nanitor-agent-bin.exe) rather than by path. This works across both locations and does not break when the agent upgrades to a new version directory.

If your AV product requires a path-based exclusion, exclude the full installation directory:

C:\Program Files\Nanitor\Nanitor Agent\

Note: The LSASS credential-theft ASR rule does not honor standard AV path exclusions (the Exclusions section in Windows Security or -ExclusionPath). If the block is from Defender ASR, use the methods in the Defender section below instead.

Microsoft Defender - ASR rule blocking the agent

A common case is Microsoft Defender's Attack Surface Reduction (ASR) rule "Block credential stealing from the Windows local security authority subsystem" flagging nanitor-agent-bin.exe.

The Nanitor agent reads LSA policy, audit policies, user rights assignments, and registry keys such as WDigest and SAM settings to run CIS benchmark compliance checks. This overlaps with the access pattern the ASR rule monitors, causing Defender to flag the agent even though no credential theft is taking place. If the agent is blocked, benchmark checks that depend on these registry reads will not complete, and checks may appear stuck in a failing or incomplete state even after the underlying policy is correctly configured.

There are three ways to resolve this, in order from most targeted to broadest:

Option 1 - Per-rule exclusion (Intune or GPO)

Applies only to the LSASS ASR rule and leaves all other Defender protections unchanged. This is the most targeted option.

  • Intune: In the Microsoft Intune admin center, go to Endpoint security > Attack surface reduction and add a per-rule exclusion for rule 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 (Block credential stealing from the Windows local security authority subsystem). Add nanitor-agent-bin.exe as the excluded file. Note: the per-rule exclusion field only appears after the rule mode is set to Audit, Block, or Warn - if you have not yet configured this rule in Intune, set the mode first.
  • Group Policy: Use the per-rule exclusion setting in the Attack Surface Reduction policy node. See Configure ASR rules and exclusions on Microsoft Learn for the exact steps.

Option 2 - Process exclusion (PowerShell)

Matches by process name regardless of which version directory the agent runs from. This is the simplest option and works across all Defender ASR rules, but note that a process exclusion also causes Defender to skip real-time scanning of files opened by that process - not just ASR enforcement. Scheduled and on-demand scans are not affected.

Run the following in an elevated PowerShell prompt:

Add-MpPreference -ExclusionProcess "nanitor-agent-bin.exe"

To verify:

Get-MpPreference | Select-Object -ExpandProperty ExclusionProcess

Option 3 - Global ASR path exclusion (PowerShell)

Applies to all ASR rules, including the LSASS rule. This option uses -AttackSurfaceReductionOnlyExclusions, which is distinct from standard MDAV path exclusions (-ExclusionPath) - the LSASS rule honors this parameter even though it does not honor -ExclusionPath. Must cover both the base installation path and the versioned subdirectory used after upgrades.

Add-MpPreference -AttackSurfaceReductionOnlyExclusions `
    "$env:ProgramFiles\Nanitor\Nanitor Agent\nanitor-agent-bin.exe", `
    "$env:ProgramFiles\Nanitor\Nanitor Agent\versions\*\nanitor-agent-bin.exe"

To verify:

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionOnlyExclusions

Why benchmark changes may not show as compliant immediately

The Nanitor agent reads actual registry values and runtime system state, not GPO configuration files. A policy change is only reported as compliant once it has been applied to the registry and taken effect on the system. This is expected - it confirms the policy is active, not just defined.

There is no difference in how the agent reads results based on how the policy was deployed. Whether you use Intune, GPO, or a combination, the agent reads the same effective registry state. If a setting is not reflected as compliant after applying the exclusion and restarting the agent, the policy has usually not yet fully applied to the system.