The Hitchhiker's Guide to Microsoft Defender for Endpoint exclusions

Since Microsoft Defender for Endpoint is a suite of products, rather than just one single piece of software, there are various places where you can create exclusions for different features. Also, there are integrations in other products, that result in possible side effects when enabling certain settings.

Most of these products have separate documentations, there is no single documentation page that contains all the information about exclusions available in Microsoft Defender for Endpoint. Until now!

This guide will give you a (hopefully) complete overview on the different types of exclusions that are available, how those exclusions interact with each other and what potential gotchas you have to anticipate.

If you already know about all the exclusions that are available, feel free to skip those parts and read more about “How exclusions and IoCs are evaluated?” or what the threat type “EUS:Win32/CustomEnterpriseBlock” is all about.

When to use exclusions?

When talking about Antivirus exclusions, most of the time we are talking about exclusions from the scan engine.

Those exclusions are a very controversial topic and vendors often recommend far reaching exclusions to minimize any impact on their own product, or even recommend disabling AV scanning for the installation altogether.

Every exclusion from the AV engine is a gap in your protection. Therefore, you should try to avoid them whenever possible. Microsoft itself states the following:

My friend Christopher Brumm has a published a blog post titled My learnings on Microsoft Defender for Endpoint and Exclusions about this question, and you should definitely give it a read.

As a rule of thumb:

• Exclusions should always be your last resort.
• You should protect files and folders that are excluded from Microsoft Defender Antivirus using ACLs from user access to avoid creating an easy path for attackers.
• Document your exclusions, including the reason why it was implemented and review them periodically.

But not all configurations shown in this article refer to such exclusions. There are also exclusions from default behavior which can also increase your security. There are so called block indicators in Microsoft Defender for Endpoint and those can be used e.g. to prevent certain software from being executed at all.

So when talking about exclusions in this article I refer to every deviation from the default behavior.

Having said this, let’s dive into the different exclusion types right away.

Exclusions based on product

This initial section lists the exclusion types that are available in the different products. In the next segment I will go into more depth what those different exclusions are used for.

Defender for Endpoint

• Allow / Block indicators
  • File Hashes
  • Certificates
  • IP addresses, URL/Domains
• Automation folder exclusions

Defender Antivirus

• Automatic exclusions
• Custom exclusions
  • Process based exclusions
  • Folder location based exclusions
  • File extension exclusions
  • Contextual file and folder exclusions
  • Custom remediation action based on threat severity
  • Custom remediation action for a specific threat
• Attack surface reduction exclusions
• Controlled folder access

Integrations

Defender for Cloud Apps

Microsoft Defender for Cloud Apps (Microsoft Cloud App Security) allows you to block unsanctioned apps using the MDE integration setting “Enforce app access”. You must also enable this integration in the “Advanced features” section of the Defender portal.

This feature creates custom URL indicators for all URLs related to the service. More details about this type of indicator are documented here.

Defender Vulnerability Management

Microsoft Defender Vulnerability Management is a quite new offering from Microsoft and as of writing in public preview. It is completely integrated in the Defender portal but requires either a standalone license (Defender Vulnerability Management Standalone) or, if you already have licensed the Defender for Endpoint Plan 2 plan, you need the “Defender Vulnerability Management add-on”.

This feature allows you to warn then user or block the execution of vulnerable applications.

You cannot use this feature to block Microsoft applications, any apps for MacOS and Linux or apps where Microsoft does not have sufficient information to block the execution. If MDE can block the execution of an app is only known after the creation of a remediation.

This feature creates custom file indicators for all executables related to the vulnerable application. More details about this type of indicator are documented here.

Custom indicators

Custom indicators are a very powerful tool to change the behavior of Microsoft Defender. You can allow, audit and block execution of processes based on file hashes or signing certificates and even restrict access to certain websites or ip addresses.

Management of custom indicators is available via

• Microsoft Defender portal
• API
• Import/Export of CSV file

Especially the API access allows for advanced use cases, such as blocking connections to known C2 servers keeping the list automatically up to date.

Each created indicator can be scoped to specific device groups or tenant wide. And since some indicators are short-lived you can also define a expiration date and time after which it is deleted.

Currently there is a maximum of 15.000 indicators that can be created within one organization.

File hashes

File hash based indicators detect files, using one of the following hash algorithms

• MD5 (not recommended)
• SHA-1
• SHA-256

Through the use of file hashes, you don’t have to rely on the folder path to exclude a file from MDE or MDAV behavior. But you have to keep in mind that you will need to exclude each new version of an executable since the hash will change with every small change.

You can allow, audit, warn or block and remediate access to files.

While the computation of file hashes is enabled by default, the detection rate can be greatly enhanced using the setting EnableFileHashComputation. This on the other hand, can have a big performance hit for the system. You might want to enable this setting on high secure workstations.

The advanced feature “Allow or block file” must be enabled that those indicators work.

Normally it only takes a couple of minutes to get changes for file indicators deployed, but it can take upwards of 30 minutes in some cases.

Allow action

Portable executable (PE) files, either exe or dll are allowed to execute even if Microsoft Defender for Endpoint or Microsoft Defender Antivirus would prevent execution.

Also those files are excluded from blocking through Attack Surface reduction rules and excluded from automated investigation.

This makes this type of indicator ideal for to mitigate false positives or handling exclusions when rolling out ASR rules.

This indicator should not be used to exclude ever changing files like docx or xslx since the hash values of those files change every time they are edited.

Audit action

Each access to a file target by a audit IoC will be monitored and alerted in the Defender portal.

This allows you to track the usage of a specific file or process in your environment.

Warn action

The warn action will trigger a warning when executing or accessing the file, but the user can decide to unblock the file herself.

Block and remediate

If a file with the defined file hash is found on a device the execution or even the read access to this file will be completely blocked and it will be quarantined.

This behavior will also occur during a automated investigation.

Certificates

The use of certificates as a custom indicator helps you to modify the behavior of Microsoft Defender, based on the code signing certificate of an executable.

Therefor those exceptions are broader than a file hash indicator and it makes it easier to handle exception for signed software that is regularly updated.

Only executables signed with the exact code signing certificate uploaded as indicator are affected. Do not expect to upload a root certificate and all sub certificates will be handled the same.

The full chain of trust for the certificate must be valid and either be trusted through a root certificate in the Microsoft Trusted Root Program or the root certificate must be present in the Trusted Root Certification Authorities store.

Supported certificate file formats for upload are

• PEM
• CER

It can take up to 3 hours for a change to propagate to all clients.

Allow

This action will whitelist all executables that are signed by the defined certificate.

This results in an exclusion for those applications from

• Blocking Attack surface reduction rules
• Automated investigation and remediation engine
• Controlled folder access
  Scripting engines, including PowerShell, are exempt from this exclusion per se.

Block and remediate

All executables signed using this certificate, are prevented to execute and will be removed.

IP addresses, URLs and Domains

This indicator blocks network connections to IP addresses or websites.

You can only block public IP addresses, RFC 1918 IP addresses cannot be blocked. It is also not possible to block network connections using CIDR blocks or IP ranges.

Supported protocols are

• TCP
• HTTP
• HTTPS (TLS)

Microsoft Edge and Internet Explorer use SmartScreen to inform the user about the block, all other applications use toast warnings.

Since this indicator has many prerequisites, you will find those in the next section.

It can take up to 2 hours for a change to propagate to all clients.

When using Internet Explorer or Edge full path HTTPS URLs (e.g. www.bad[.]site/trojan.html ) are supported. In all other apps only FQDN (e.g. www.bad[.]site) can be blocked.

The feature “Enforce app access” in Microsoft Defender for Cloud Apps (Microsoft Cloud App Security) uses custom URL indicators to block access. Those indicators are, by default, scoped to all devices. You can change this manually.

Prerequisites

Custom network indicators must be enabled in the advanced features

Network protection must be enabled on your devices as well.

The enable network protection on servers you also have to enable the setting AllowNetworkProtectionOnWinServer and optimally AllowDatagramProcessingOnWinServer.

For Windows Server 2012 R2 and 2016 in addition to the already mentioned settings you must enable AllowNetworkProtectionDownLevel.

You can use this script to enable all the settings on your servers.

Set-MpPreference -EnableNetworkProtection Enabled
Set-MpPreference -AllowNetworkProtectionOnWinServer 1
Set-MpPreference -AllowDatagramProcessingOnWinServer 1
Set-MpPreference -AllowNetworkProtectionDownLevel 1

Allow

Allow access to this IP address or website, even if Microsoft would block the connection using SmartScreen. This can be used to handle false positives in the web content filter feature or allow a specific group of people/device group access to a specific website you otherwise wont’t allow.

Audit

This will create an alert in MDE every time the specified IP address, URL or domain is contacted.

You can modify the alert severity based on your needs and also assign a category, description and recommended action.

Warn

Warn the user when she or a software she is using accesses this target. The user can choose to bypass the warning.

Block execution

The computer cannot connect to the specified indicator using TCP.

Automation folder exclusions

As an administrator you can exclude certain files or folder from the “Automated investigation” feature. Those exclusions are scoped tenant-wide and cannot be scoped only to a specific device group.

You can exclude one or multiple folders completely.

If this exclusion is to broad for you taste you can also limit the exclusion to certain file extensions within the defined folder path.

Still to broad? You can also exclude specific file names that should be ignored by an automated investigation within the folder.

Since those exclusions are applied to every device in your company, you shouldn’t use this exclusion type lightly.

The defined folders, filetype and files are still being analyzed by Microsoft Defender Antivirus.

Automatic exclusions

Automatic exclusions are built-in exclusions. Files defined as part of the automatic exclusions won’t be scanned by the Real-Time Protection engine of Microsoft Defender Antivirus.

Those exclusions do not apply to quick, full or on-demand scans.

You can choose to disable to those exclusions, but this is not recommended.

Operating system files

Starting with Windows 2012 R2 (using the new down-level agent) built-in exclusions for operating system files are supported.

Such files include files like %windir%\SoftwareDistribution\Datastore\*\Datastore.edb or %allusersprofile%\NTUser.pol. Microsoft offers a complete list of those exclusions.

Server roles

Starting with Windows 2016 this feature also covers exclusions based on installed Server roles. The enumeration of installed roles and features is based on the Deployment Image Servicing and Management (DISM) engine.

Supported roles and features are currently limited to

• File Replication Service (FRS)
• Hyper-V
• SYSVOL
• Active Directory
• DNS Server
• Print Server
• Web Server
• Windows Server Update Services

The automatic exclusions for those features only cover the default installation paths. If you chose to install e.g. your NTDS or SYSVOL on another disk or another path than the default the exclusions won’t apply. You will have to create custom exclusions.

Custom exclusions

Custom exclusions are any exclusions to the MDAV engine that you yourself define. As discussed at the beginning of the blog they should only be created if really necessary.

Those exclusions only apply for MDAV and will be ignored for detections based on Microsoft Defender for Endpoint, by attack surface reduction rules or the controlled folder access feature.

Tamper Protection

Starting late 2022 exclusions for Microsoft Defender Antivirus can be protected by tamper protection. For this some conditions must be met:

• Exclusions must be managed using Intune
• Tamper protection is enabled using Intune, not Microsoft Defender Antivirus
• Local admin merge must be disabled
• Defender platform version 4.18.2111.0 or greater
• The feature TPExclusions must have a value of 1

Process based exclusions

This type of exclusions does not exclude the defined process itself but excludes all files accessed by this process from real-time protection and monitoring.

If you add an exclusion like %ProgramFiles%\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\SQLServr.exe all files accessed by the SQLServr.exe in the specified folder will be excluded.

This exclusion does not apply to scheduled or on-demand scans. In my example this would result in mdf and ldf database file being scanned when such a scan is triggered.

Supported wildcards for this exclusion type are

• An asterisk (*) at the end of an path.
  This will exclude files that are accessed by any processes in the defined folder from real-time protection.
• Environment variables
  All available windows environment variables, that are in scope for the SYSTEM account can be used. e.g. %ProgramFiles% or %ALLUSERSPROFILE%

You should always define the exact path of the process and try to avoid wildcards.

Folder location based exclusions

This exclusion is far more wide reaching than a process exclusion. Files and folders covered by the exclusion definition will be excluded from

• Real-time protection and monitoring
• Scheduled scans
• On-demand scans

This effectively makes MDAV blind.

Supported wildcards for this exclusion type are

• An asterisk (*) as a wildcard for filenames
  C:\SomeFolder\*.txt will exclude all txt files in the folder C:\SomeFolder\
• An asterisk (\*\) as a wildcard for a single folder
  C:\SomeFolder\*\Data\ will exclude all files in folder that match the wildcard. C:\SomeFolder\App1\Data\ would be excluded, while C:\SomeFolder\App\Bin\Data\ wouldn’t be.
• A question mark (?) as a wildcard for a single character in a file or foldername
  C:\SomeFolder\log?.txt will exclude C:\SomeFolder\log0.txt C:\SomeFolder\log1.txt but not C:\SomeFolder\log.txt
• Environment variables
  All available windows environment variables, that are in scope for the SYSTEM account can be used. e.g. %ProgramFiles% or %ALLUSERSPROFILE%

Contextual file and folder exclusions

Contextual file and folder exclusions is an addition to folder location based exclusions. It allows you to control the circumstances when and how a file or folder is excluded.

You can limit the scope by defining either one or multiple of the following conditions in conjunction with the exclusion path.

• Path type
• Scan type
• Scan trigger
• Process

Path type

The path type restricts the defined exclusion to either a file or a folder path. This makes it much harder to abuse a defined exclusion by creating a similar named folder or file.

D:\Windows\NTDS\ntds.dit\:{PathType:file}

This would completely exclude the file ntds.dit, defined by a full path from any protection.

C:\Program Files\Microsoft SQL Server\MSSQL$*\FTDATA\:{PathType:folder}

This example would exclude the folder and all objects beneath this folder from MDAV protection.

Scan type

You can also define if the specified object will be excluded either from Resource, Quick or Full scans using this method.

• Resource A targeted scan of a single item
• Quick A scheduled or manual started quick scan of the system
• Full A scheduled or manual started full scan of the system

C:\DBDATA\master.mdf\:{ScanType:Full}

This will exclude the file master.mdf in the defined path from Full scans, but not from Resource or Quick scans.

Scan trigger

Valid scan triggers are

• OnDemand Manual triggered scan either using the UI or script
• OnAccess Real-time protection like read or write of a file or folder
• BM A scan triggered by behavioral monitoring

C:\DBDATA\master.mdf\:{ScanTrigger:OnAccess}

This example excludes the file master.mdf in the defined path from OnAccess scans, but not from OnDemand or BM initiated scans.

Process

Process restrictions are especially interesting, because you can define exactly for which process image a specific path is excluded. This makes it obsolete to exclude all activity of a process.

D:\DBDATA\*.mdf\:{Process:"%ProgramFiles%\Microsoft SQL Server\*\MSSQL\Binn\SQLServr.exe"}

This will exclude all objects named *.mdf from being scanned when the process SQLServr.exe in a defined path is interacting with them.

You can define more than one process per exclusion

D:\DBDATA\*.mdf\:{Process:"%ProgramFiles%\Microsoft SQL Server\*\MSSQL\Binn\SQLServr.exe",Process:"SQLDumper.exe"}

This adds all process with the image name SQLDumper.exe to this exclusion.

As you can see, wildcards are allowed for the process as well. See here for valid wildcards.

Combinations

You can combine any variation of mentioned restrictions to fit you needs. If you do not define a specific restriction the default behavior of file and folder exclusions is used.

D:\DBDATA\*.mdf\:{PathType:folder,Process:"%ProgramFiles%\Microsoft SQL Server\*\MSSQL\Binn\SQLServr.exe"}

In this example the folder D:\DBDATA\ will not be scanned if the process %ProgramFiles%\Microsoft SQL Server\*\MSSQL\Binn\SQLServr.exe is accessing any files in this folder. Because ScanType and ScanTrigger is not defined the folder is also excluded from any scheduled scanning as it would have been before restrictions were introduced.

File extension exclusions

This exclusion type has a big impact since it excludes files solely on their file extension.

Those files will be excluded from

• Real-time protection and monitoring
• Scheduled scans
• On-demand scans

This exclusion type does not support any kind of wildcards.

Custom remediation action based on threat severity

The configuration setting “Specify threat alert levels at which default action should not be taken when detected” let’s you configure which action Microsoft Defender Antivirus should take when a certain threat is found on the device.

Depending on the severity you can change the behavior of MDAV .

Threat severity is divided in four categories:

• 1 = Low
• 2 = Medium
• 4 = High
• 5 = Severe

One of the three actions must be configured

• 2 = Quarantine
• 3 = Remove
• 6 = Ignore

As you can see there is one action that is called Ignore. An attacker could change the the default behavior for all threat severities to 6 and no remediation action would be started.

Custom remediation action for a specific threat

You can also change the default behavior for specific threat id e.g. Tool:Win32/EICAR_Test_File has threat id 17463.

You can use Get-MpThreatCatalog to list all available threat ids.

The three possible actions are the same as before.

• 2 = Quarantine
• 3 = Remove
• 6 = Ignore

Attack surface reduction exclusions

Attack surface reduction rules are used by MDAV to prevent certain software behavior.

Exclusions to Attack surface reduction rules always apply to all ASR rules. It is currently not possible to target certain ASR rules.

You can create exclusions based on the file- or folder path.

Those exclusions support environment variables and asterisk (*) as wildcards.

• C:\MyData\*.exe
• C:\MyData\App.exe
• %SystemDrive%\MyData\App.exe

The custom indicator types File Hashes and Certificates are also evaluated and Allow actions result in an exclusion from ASR rules.

Controlled folder access

Controlled folder access prevents unknown or untrusted apps from changing any files in protected folders. Those folders include Documents, Pictures, Videos, Music and Favorites by default.

This feature that does not allow any exclusions from the default list of folders. If you want to protect additional folders you can add them.

While you can’t exclude a specific folder, you can exclude certain allowed applications from the restrictions.

Those exclusions include environment variables as well as asterisk (*) as wildcards.

The custom indicator types File Hashes and Certificates are also evaluated and Allow actions result in an exclusion from the controlled folder access feature.

Microsoft adds apps that it considers friendly to this whitelist as well. Those automatically whitelisted apps are not displayed in the configuration and to my knowledge there is no way to know which apps fall into this category.

How exclusions and IoCs are evaluated?

All those different types of exclusions are evaluated by the different features in Microsoft Defender Antivirus and Microsoft Defender for Endpoint to decide if an artifact should be either Allowed or Blocked. Depending on the configuration this evaluation can get confusing quick. I created a flow chart based on the Microsoft documentation.

Microsoft itself describes some parts of the evaluation in the section “policy conflict handling”:

• If the file is not allowed by Windows Defender Application Control and AppLocker enforce mode policy, then Block
• Else if the file is allowed by the Microsoft Defender Antivirus exclusion, then Allow
• Else if the file is blocked or warned by a block or warn file IoC, then Block/Warn
• Else if the file is allowed by an allow file IoC policy, then Allow
• Else if the file is blocked by ASR rules, CFA, AV, SmartScreen, then Block
• Else Allow (passes Windows Defender Application Control & AppLocker policy, no IoC rules apply to it)

This description does no cover all the exclusion types I discussed in this article. For an complete overview I added those in the flow chart as well.

For some features additional conflict handling or even completely different exclusion handling is used.

File IoC conflict handling

If there are conflicting file indicators the policy of the one with the more secure hash will be applied.

URL conflict handling

The indicator with the longer URL path wins over the indicator with the shorter URL paths.

IoC scoping conflict handling

If there are IoC policies for the same type but different actions, the one closer to device wins. This means that the IoC scoped to a device group take precedence over the IoC that is scoped to all devices.

Automated investigation

When running an automated investigation and remediation task on a device custom indicators are taken into account.

So if the verdict of the investigation is “bad” but there is an “allow” IoC for this file no action is taken to remediate it.

The other way around is also applicable. A good verdict will be overwritten by a “block” IoC.

EUS:Win32/CustomEnterpriseBlock

Now that you think you know all about exclusions let me introduce the threat EUS:Win32/CustomEnterpriseBlock and her friends:

Those threat types are used to mitigate threats that are not detected by the Microsoft Defender Antivirus engine, but by Microsoft Defender for Endpoint.

There is not much official documentation about those threat types. There is a mention in this article on how to restore files an admin has removed through the “Stop and Quarantine” file option in the Defender portal.

A second mention of this threat name is found in the section “Public Preview: Advanced hunting capabilities” from the article “Create indicators for files”

In this article you will also find the following line:

Information in this section (Public Preview for Automated investigation and remediation engine) relates to prerelease product which may be substantially modified before it’s commercially released.

This hints us to another feature that might be related to this threat type: The “Automated investigation and remediation engine”.

The automated investigation and remediation engine

Let’s do an experiment.

I created a a custom folder exclusion (MDAV) on a device on-boarded to Microsoft Defender for Endpoint. This device is part of an device group that is configured for the automation level: “Full - remediate threats automatically”

This exclusion was for the folder C:\Research. Based on our knowledge in the previous section on exclusion evaluation only Windows Defender Application Control and AppLocker policies could now prevent me from executing any malware from within this folder.

So let’s download something bad and noisy. (Mimikatz) is the perfect test subject, so lets execute it. As expected the mimikatz.exe process is started without intervention of Microsoft Defender Antivirus, because the complete folder was excluded from the real-time monitoring protection.

But what happened next is very interesting. Microsoft Defender for Endpoint detects the execution of mimikatz based on the signals send to Microsoft and creates an alert.

As part of this alert an automated investigation, configured for full remediation, is started.

As part of the automated investigation and remediation process Microsoft Defender for Endpoint scans files, processes, services, drivers, IP addresses and possible persistence methods on the affected endpoint.

On the affected device you will see toast messages pop up while this investigation is running, stating “Enterprise Unwanted Application found”. This happens for every malicious file and can be observed in the “Windows Virus & threat protection” UI under current threats or in the evidence section of the Automated investigation.

As a result Mimikatz is completely removed as part of the automated investigation and remediation process.

So it seems that engine only respects the exclusions defined in the Microsoft Defender for Endpoint portal as part of the Automation folder exclusions and has no regard for any exclusion configured as part of the MDAV settings. And it uses the EUS:Win32/CustomEnterpriseBlock threat type to archive this on the device.

Verifying the behavior

To verify that no local configuration gets in the way of the automated remediation process I created an additional test setup.

Since the automated remediation will remove threats found on the device, even when there is a exception in Microsoft Defender Antivirus, I modified the behavior in MDAV to ignore all threats match Custom.*Enterprise using Add-MpPreference -ThreatIDDefaultAction_Actions 6 -ThreatIDDefaultAction_Ids <THREATID>.

This way I can verify if the automated remediation engine will honour any local configuration.

Get-MPComputerStats | Select *Version*
Get-MpThreatCatalog | ? ThreatName -match "Custom.*Enterprise" | % {
	Add-MpPreference -ThreatIDDefaultAction_Actions 6 -ThreatIDDefaultAction_Ids $_.ThreatId
}
Get-MpPreference | fl ThreatIDDefaultAction*

After I excluded all those threats I downloaded and ran mimikatz again. The folder exclusion for MDAV was still in place at this point in time.

$ProgressPreference = "SilentlyContinue"
[Net.ServicePointManager]::SecurityProtocol = ([Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12)
Invoke-WebRequest -Uri "https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0-20210810-2/mimikatz_trunk.zip"  -OutFile "mimikatz.zip"
Unblock-File "mimikatz.zip"
Expand-Archive -Path "mimikatz.zip" -DestinationPath . -Force
.\x64\mimikatz.exe "lsadump::lsa" "exit"

The execution of mimikatz was, as expected, not immediately blocked. Microsoft Defender for Endpoint created a new alert and started an automated investigation.

Soon after, toast messages from Defender AV started to pop up on the device, stating that an “Enterprise Unwanted Application” was found and removed.

In the Windows Security center under “Protection history” the files were listed twice. Initially as allowed, and a few seconds later as quarantined.

Checking the filesystem I could confirm that all mimikatz related exe and dll were removed from the device. The configuration itself was still intact, so nothing was changed here automatically.

Even changing the default behavior for those MDE related threats in MDAV is not honored by the automated remediation.

Conclusion

Based on this testing I would say it’s safe to conclude that the automated remediation engine ignores any locally configured settings. Also this makes it even more obvious why you should not change the automated remediation to some semi automated mode in day to day operations.

This makes it the most powerful remediation engine in the Microsoft Defender for Endpoint suite.

Also all those EUS:Win32/CustomEnterprise* are always detections based on some kind of Microsoft Defender for Endpoint feature. This makes them easy to distinguish from threat detected by the Microsoft Defender Antivirus engine.

Nice to know
If you add a custom file indicator and such a file is detected the threat name assigned to this is EUS:Win32/CustomEnterpriseBlock!cl.

That’s all for today - 🍺 Cheers

Additional information

• SQL Server AV exclusions
• Exchange Server AV exclusions
• SharePoint AV exclusions
• Virus scanning recommendations for Enterprise computers that are running Windows or Windows Server
• Recommendations for defining exclusions
• Common mistakes to avoid