It is time for part 10 of the Microsoft Defender for Endpoint (MDE) series. The final part of the series. Part 10 is focussed on tips and tricks around Defender for Endpoint and some important items scoped on common mistakes during deployments scoped around the Windows platform. Typical deployment tips based on my experience and commonly asked questions around Defender for Endpoint. The following topics are published as part of the MDE series:

Defender for Endpoint is a large topic; expect more specific deep-dived blogs later for specific components. And when interested there will be a second series with a more in-depth explanation of specific MDE features and other platforms (Linux, iOS, Android). Without joking; we can easily create around 50 parts or more for Defender for Endpoint and all related components.

NOTE: The blog series focuses on features in Microsoft Defender for Endpoint P2 all Microsoft Defender for Endpoint P1 features are available in P2.

Specific question or content idea part of Defender for Endpoint? Use the contact submission form and share the post ideas.

Common mistakes

When deploying Defender for Endpoint it all starts with preparation. Based on experience customers started with Defender for Endpoint onboarding as a small pilot, resulting in a large set of devices. What are the common mistakes?

  • No structure in Defender for Endpoint
  • Service settings not correctly enabled
  • No plans for the onboarding mechanism
  • No “design” around policies/ deployment (results in policy conflicts)
  • Exclusions migrated from other AV solutions
  • Defender AV not configured correctly
  • Deploying it in production without understanding all features
  • Audit mode is doing protection in MDE
  • Updates are not needed in passive mode
  • Not using the portal (waiting for incidents/alerts)
  • Not using Threat Analytics
  • Deploy to unpatched systems
  • Defender for Servers is fully automated including AV configuration
  • And many more

No structure in Defender for Endpoint

The portal looks simple; there is an onboarding method/ device inventory and a set of features on top of the collected data. For larger enterprises with multiple environments/ geo-locations/ companies device groups are really important for assigning more in-depth RBAC controls and for giving visibility in the reporting. When different IT teams are responsible for a smaller set of devices it is a must to configure a well-structured grouping structure.

Permissions to everyone

Did you know there is a risk when onboarding devices (Domain Controllers/ Tier-0 servers) to Azure Arc/ Defender for Endpoint (MDE) – the risk can generate a huge impact when the access model is not configured correctly and allows potential a take-over of the machine. Let me explain why and how to design a good structure without risk.

The risk with Azure Arc

After enabling Azure Arc on Domain Controllers or other Tier-0 servers there is the option to do a server takeover via the Arc agent and policies/scripts. You can easily run PowerShell scripts (Custom script extension) for generating local accounts or changing critical settings on the domain controllers via the available extensions. When enrolled in MDE there is a detection capability of the EDR for malicious performed actions; all not for all performed actions.

If you were to deploy a domain controller/other Tier-0 assets and manage the servers using Azure Arc, then the Azure Arc admins and all other sufficient roles who can become an Azure ARC admin in that tenant is effectively a Domain Admin for that AD forest.

What can we do?

When designing Azure Arc it is needed to define a good RBAC/ subscription model and define only permissions for a specific set of people. Syncing Azure Arc to one subscription/ resource group? Each member with sufficient roles can manage the servers via Azure Policies/ scripts.

– Design a good RBAC/ Azure/ IAM structure
– Give limited access to Tier-0 and Domain Controllers
– Dedicated Resource Group for Tier-0 with limited access
– Check who has control over the Azure Arc resources

The risk with Defender for Endpoint

When using Defender for Endpoint without Azure Arc there is even a risk. For all MDE onboarded devices there is a risk of a complete take-over via Live Response. With the use of Live Response, it is possible to upload custom PowerShell scripts and run scripts on any onboarded machine when there are permissions. Check always the permissions and who is able to use live response.

For MDE consider a good device structure and limited access to the Tier-0/ Domain Controller assets to a specific group of people.

What can we do?

Tag devices and assign them to a specific device group in MDE. Limit access to the device group in MDE with only access from a specific group of people. With the use of permissions, it is possible to allow only a specific group to have access.

– Tag machines
– Create separate device groups for T0/ critical assets
– Grant limited permissions to the device group
– Review live response activity
– Disable Live Response unsigned script execution when possible in the Advanced features.

Did you know you can review all performed live response sessions? Go to M365D – Actions & Submissions – Action Center and open the History tab. Filter here for the action; Live Response command. 30 days of history is visible.

Service settings not correctly enabled

Customers started onboarding Defender for Endpoint without full protection enabled. Defender for Endpoint works based on a couple of features (Advanced Features) – without all features enabled there is less protection or weakness in the product. Before starting with any onboarding of a machine, make sure the service settings are correctly enabled.

Not following new configurations/ features

Microsoft released rapidly new features around Defender for Endpoint. During most of my deployments, the configuration is configured and after a couple of years it is still the same configuration. Defender for Endpoint is a story, important to follow the new developments. Good example is the ASR rule; “Block vulnerable drivers” This ASR rule is not available via the MECM policies or old Intune policies – it is always needed to follow the new developments and improve the Defender for Endpoint instance.

No plans for the onboarding mechanism

Onboarding is a different topic – currently, many solutions are available for onboarding Defender for Endpoint. Intune, GPO, PowerShell, Configuration Manager, Azure Arc, Defender for Servers. There are many options; my tip here is don’t focus only on Defender for Endpoint – check if more is possible. For example; Defender for Servers/ Azure Arc and Microsoft Intune support way more features for a better security landscape.

When using Azure Arc/ Defender for Cloud make sure to align the specific teams with a focus on Azure and start with a well-designed Azure landing zone.

No “design” around policies/ deployment (results in policy conflicts)

GPO, Intune, Configuration Manager, Local Policy, PowerShell, and more. There are many tools available for configuring settings on Windows. Avoid conflicts and document the configured policies.

Before starting Defender for Endpoint projects, analyze the current configuration landscape. Common mistakes:

  • Defender AV disabled via GPO
  • Microsoft Security GPO baseline conflicts with Intune
  • Configuration Manager Endpoint Protection site role conflicts with Intune

When using Intune and GPO; it can be useful for the deployment of a configuration for making the MDM policy a higher order. Without any configuration, GPO is always the highest configuration when there is a conflict. With the use of a custom policy, it is possible to define the MDM policy over GPO.

MDMWinsOverGP is available via the following OMA-URI setting:

OMA-URI./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
Data typeInteger
Value1

The setting is also available via the settings catalog with the name: MDM Wins over GP

Exclusions migrated from other AV solutions

This one is quite often visible in environments. Organizations used other third-party AV solutions for many years, resulting in many legacy exclusions, including test folders and complete program folders. Never migrate the entire list from any other AV in Defender AV. Each AV works differently – add only exclusion when there is a critical need (performance issues/ compatibility issues).

When using exclusion make sure it is documented (ticket number, reason, troubleshooting details). Defining exclusions lowers the protection offered by Microsoft Defender Antivirus.

Explanation of the exclusions is not part of the MDE series with a reason. Fabian Bader published an in-depth exclusions guide with almost all related information. Must read!!!

Fabian Bader/ Cloudbrothers.info: The Hitchhiker’s Guide to Microsoft Defender for Endpoint exclusions

Defender AV not configured correctly

Biggest misunderstanding; we have the Defender for Endpoint sensor onboarded and all is good and protected. The sensor is reporting “healthy” in Defender for Endpoint and Defender AV is running.

Defender AV/ NGP is part of Defender for Endpoint and must be configured. Without Defender AV correctly configured, there is a lack of protection; Cloud Protection, ASR, Network Protection, and many more settings depend on the AV component. See the following blogs:

Tip: Use the security recommendation part of Defender for Endpoint

The first step in enrolling MDE is confirming of all configurations are compliant. Using Microsoft Defender Vulnerability Management it is possible to check the configured security controls for Antivirus, Application Guard, ASR, Bitlocker, Credential Guard, EDR, Exploit Guard, Firewall, SmartScreen, and the general onboarding state of MDE.

Use security recommendation data often and make it part of the IT process.

View via the portal: Go to recommendations and filter on the related component “Security controls” for viewing the compliance of all security controls policies.

For Attack Surface Reduction Rules – the recommendation insights are visible based on user impact information. User impact calculation is collected in the past 45 days and based on collected sensor telemetry.

Important: recommendation is based on the enablement/disabled state of the feature. Specific settings (MAPS level, timeout) are not part of the result/ check. Always confirm the baseline and correct MAPS settings with in-depth testing of the machines (simulations/ validation) See:

Microsoft Defender for Endpoint series – Defender Vulnerability Management – Part5 

Microsoft Defender for Endpoint series – Validate Defender protection and additional troubleshooting – Part6 

Deploying it in production without understanding all features

Essential for the IT teams to understand the features part of Defender for Endpoint. Based on real experiences by organizations there is often knowledge by the full IT team. Train users and make sure all features are explained (including service desk teams). Examples:

  • What is EDR in Block Mode
  • What is MAPS/ Cloud Protection
  • What is PUA protection
  • How to exclude feature xx in the portal or configuration
  • How works Tamper Protection
  • What is audit mode/ block mode

Most of the weakness starts with IT knowledge (Excluding complete folders; disabling AV features, offboard machines, not knowing the detection logic/ agent features) – make sure the team is informed and “knows” the products in-depth including all sub-features.

Recommended: View/ read all content part of the Defender for Endpoint Ninja show/ Ninja blog for in-depth knowledge.

Audit mode is doing protection in MDE

Common situation; we have some components (ASR/ Network Protection, PUA) in audit mode and are safe. Nope, audit mode is not doing any protection in MDE. It collects in some cases audit events, all there is no actual block.

Attack Surface Reduction (ASR) is always tricky and requires some fine-tuning. Don’t use audit mode for months; after configuring audit mode review the events and plan the enablement in block mode. Don’t use audit mode for years when not needed.

In cases for ASR where the rule is not compatible with the environment; enable always audit mode instead of disabling the rule. With the use of audit mode, all data is collected and available via Advanced Hunting.

Updates are not needed in passive mode

When using Defender for Endpoint/ Defender AV in passive mode/ EDR in block mode it is still required to update the agent with the correct updates. Make sure the signature updates/ platform updates and sense updates are deployed.

Not using the portal (waiting for incidents/alerts)

Defender for Endpoint is installed on all machines and up and running, there is no need for using the portal – only in cases when there is an alert. Not true; When Defender for Endpoint is correctly deployed there are many insights. After deploying it is important to use all data, start with hunting patterns and use the data in Defender Vulnerability Management for patching all systems. More information later in this blog for the usage and insights.

Not using Threat Analytics

The threat analytics part of Defender for Endpoint is important. Threat analytics is a feature with in-depth information from Microsoft security research and automated insights for possible impacted assets and available mitigations. In the Analyst report section, there is a detailed expert write-up available with in-depth information about the attack techniques and used KQL queries for hunting.

Deploy to unpatched systems

When starting with the deployment of Defender for Endpoint – make sure all systems are correctly updated to one of the latest updates. Based on experience there are many possible issues when systems are not on the correct level.

When the Servicing Stack Update (SSU) and Latest Cumulative Update (LCU) are correctly updated it will result in easier onboarding. Based on experience; Server 2016 gives a couple of issues when the SSU/ LCU is not updated to a specific version.

Defender for Servers

When using Defender for Servers there is still configuration needed for the Defender for Endpoint configuration. Defender for Servers starts only the onboarding via provisioning – it is still needed to configure additional components (AV, ASR, Firewall e.d). Ideally, use the new MDE security settings management for managing servers centralized via Intune.

Blog tip: Manage Defender for Endpoint for Windows, macOS, and Linux via Security settings management

Defender for Servers AV configuration

When using Defender for Servers there is still configuration needed for the Defender for Endpoint configuration. Defender for Servers starts only the onboarding – it is still needed to configure additional components (AV, ASR, Firewall e.d)

Not updating the unified agent

For 2012R2 and 2016 with the unified agent installed, it is needed to update the sense component. The SNSE component requires to update KB5005292 for improvements related to the EDR sensor component.

When using WSUS or Microsoft Endpoint Configuration Manager it is important to include the updates part of the “Microsoft Defender for Endpoint” category.

Misconfiguration of block at first sight (BAFS)

Block at first sight (BAFS) is a threat protection feature of the Defender AV/ NGP component and detects new malware and blocks it within seconds. BAFS relies on a couple of configurations.

  • Cloud protection
  • Sample submissions (Send all samples automatically/ send safe samples automatically)
  • Cloud extended timeout period (recommended to use 50)

The combination of the above three settings enables block at first sight (BAFS). Block at first sight detects new malware and blocks it within some seconds. To get BAFS enabled it is needed to configure the above configuration. When all items are configured Block at first sight is correctly enabled.

Emergency updates

Microsoft Defender Antivirus uses cloud-delivered protection/ MAPS) to periodically download dynamic security intelligence updates to provide more protection. These dynamic updates are pushed automatically. Microsoft is able to push emergency updates via MAPS. Make sure that cloud-delivered protection is correctly enabled.

Knowing the unknown with device discovery

Ideally, there is a CMDB where all assets are available and correctly registered. In almost all environments, there are “unknown” devices. New onboarded machines outside the process/ test machines or playgrounds are often. For Defender for Endpoint and the threat landscape, it is critical to make sure all devices are covered by Defender for Endpoint.

With the use of Defender for Endpoint Device Discovery it is possible to discover the unmanaged part of the network. Microsoft Defender for Endpoint provides a device discovery capability based on onboarded endpoints to collect, probe, and scan the network to discover unmanaged devices.

The logic detects corporate networks and excludes private networks automatically. It is possible to manually exclude networks or devices from scanning.

Currently, it supports:

  • Endpoints
  • Network devices (Routers/ switches)
  • IoT devices (printers, cameras, scanners)

Defender for Endpoint supports two configurations of discovery (Basic discovery and Standard discovery).

Standard discovery is recommended. This method is based on smart active probing to discover additional information. Standard discovers minimal information using the SenseNDR.exe.

All devices are visible in the device inventory – filter for can be onboarded/Unsupported/Insufficient info state for MDE-related devices.

Use KQL for getting all machines part of the discovery

DeviceInfo
| summarize arg_max(Timestamp, *) by DeviceId  
| where isempty(MergedToDeviceId)
| where OnboardingStatus != "Onboarded"

Authenticated scans

Microsoft Defender for Endpoint device discovery can scan the network based on endpoints. With the use of the authenticated network device discovery more in-depth scanning is possible based on dedicated MDE devices and SNMP authentication for deeper analysis. Authenticated scans will be explained in a separate blog.

Using the portal and all available data/ insights

Defender for Endpoint is not an “install, roll-out, and completed” product. The main work starts when all devices are onboarded and data is collected. I have seen many organizations rolling it out quickly and forgetting all the features part of Defender for Endpoint.

Maintaining Defender daily is critical and needed for getting most of the benefits out of the product. It starts with a couple of main parts:

  • New incidents/ Alerts
  • New Vulnerabilities
  • New threat reports
  • Responding to incidents
  • Patch vulnerabilities

Vulnerability management

With the use of the Defender for Endpoint sensor it collects vulnerabilities. There are many vulnerabilities, and managing them all is not possible. Prioritizing the work based on the impact score. MDE knows the number of CVEs and the exploit that is being actively exploited in the wild.

Tip: Create an update/vulnerability process; ideally create a team for reviewing the vulnerabilities daily/ weekly and update all software/ perform actions. Try to make the exposure score lower by patching the most critical recommendations.

Focus not only on software vulnerabilities, all software configurations are useful for making the endpoint baseline more strict. When there are device groups configured it is easy to give separate insights based on the device groups (Servers/ Linux/ Windows Endpoints e.d)

Review automated actions and portal activities

Automated investigation/ device quarantine and some other AV-related actions can be useful. In some cases, Defender for Endpoint detects and remediates automatically files. When alerts are automatically resolved it is not always visible. With the use of the action center, there are more insights available.

The action center is not only scoped on “new” actions; all historic actions are available via the History tab. Action center is available via Actions & submissions:

History contains all performed actions. This view contains for example the isolated device feature/ quarantine file action part of the automated investigation or AV quarantine items:

The quarantine file action contains all related information and allows the security team for restoring the quarantine file actions for specific actions or all instances.

For quarantine file actions there is a “devices by” field. When the field is filled in with Automation the file is automatically quarantined. Microsoft Defender AV is scoped on items quarantined by the Defender AV process.

Live response auditing?

The action center contains auditing for the live response feature. When opening the investigation page for a live response command action it shows the complete historic view and performed commands:

The investigation page contains an image snapshot of the console and command log including all performed actions and commands. All data is visible; including the session started/ session ended and total duration.

Common mistake; No tamper protection

There are still organizations not enabling tamper protection for the following reasons;

  • We need to manage devices
  • Developers are allowed to add/ change settings
  • Performance issues

There is no reason for disabling tamper protection; each machine needs to be protected with tamper protection against malicious changes in the Defender AV/ EDR solution. Without Tamper Protection it is easy to bypass core protection features.

As already mentioned in the series; there are for Windows a couple of ways of enabling tamper protection:

  • Via Defender for Endpoint portal – advanced features
  • Via Microsoft Endpoint Manager Intune

Advanced features: Enabled via advanced features part of security.microsoft.com

Intune: Using Microsoft Defender Antivirus profile in the Endpoint Security – Antivirus blade

Recently Microsoft announced the new tamper protection feature for exclusions. If you manage exclusions exclusively through Intune with both tamper protection and DisableLocalAdminMerge enabled, there is protection for exclusions where exclusions are managed by Intune. Exclusions are managed when configuring:

  • DisableLocalAdminMerge
  • Tamper Protection is deployed using Intune
Tip: Deploy tamper protection using the Intune configuration and Defender for Endpoint service settings. Deploy both so exclusions are protected and there is always a fallback when the cloud protection service is not available. Tamper protection via security.microsoft.com requires cloud protection to be fully enabled.

Based on my opinion tamper protection must be always enabled. The new troubleshooting mode can be used during troubleshooting situations for disabling the features for troubleshooting. Sometimes customers like to disable Microsoft Defender during troubleshooting and not configure tamper protection, which makes a security cap. The new troubleshooting mode is fixing this request, where teams are having more flexibility. View the in-depth troubleshooting blog here.

Local admin

When using an endpoint with local admin permissions it is recommended to restrict the following registry location: ( to avoid policy changes) 

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Policy Manager

This registry location can be restricted with a custom policy in Intune/ GPO or other systems. For Intune use a custom OMA-URI profile and configure the following value:

OMA-URI./Device/Vendor/MSFT/Defender/Configuration/HideExclusionsFromLocalAdmins
Data typeInteger
Value1

HideExclusionsFromLocalAdmins restricts the view. If the value is set to 1, it blocks all access to the policy location:

Common mistake; No updates deployed

Defender for Endpoint requires a couple of monthly/daily updates for getting new features and updates. Important to make sure the updates are working correctly and are accepted.

When using WSUS/ Configuration Manager; try to move to more modern solutions – based on real experience all issues start with WSUS/ Configuration Manager and corrupt update packages. Issues with syncing the catalog, corrupt databases, and no maintenance. Try to move to a cloud-managed distribution (MicrosoftUpdate) for at least the signature updates.

Defender for Endpoint/ Defender AV needs to be updated with recent updates. The following updates are important. Don’t forget KB5005292 which is required for the 2012R2/ 2016 EDR sensor part of the unified agent.

UpdateKBDescription
Update for Defender antimalware platform (AmProductVersion)KB4052623It is critical to make sure Defender platform is updated with the latest version, for getting the latest technology and features
Security Intelligence updatesKB2267602Defender AV requires Security Intelligence Updates/ Signature updates
Update for EDR sensor (2012R2/ 2016)KB5005292This update includes updates and fixes to the EDR sensor that is used by MDE for 2012R2/ 2016

Common mistake; Exclusions

Before starting with deploying Defender for Endpoint make sure the preventions as already explained are correctly configured:

  • DisableLocalAdminMerge
  • Tamper Protection
  • HideExclusionsFromLocalAdmins (when users are local admin)

In Intune, DisableLocalAdminmerge can be configured using the setting “Disable Local Admin Merge” configure the setting to the following: ( I know it is a bit confusing with the name convention in Intune)

When configured on “Disable Local Admin Merge” the local exclusion list added via local Group Policy, PowerShell UI is not merged with the effective policy.

Each vendor shares most of the time a large list of exclusions. A good example of Veaam advice; excluding the complete C:\Program Files\Veeam\ folder. Good job!! All it is great for running malware directly from a folder (-;

Even when the vendor shares a large list of exclusions review each exclusion, based on experience most of the applications run well without the vendor-recommended exclusions. When needed use procmon/ performance analyzer or more in-depth toolings for checking specific paths. More information:

Add only exclusion when there is a critical need (performance issues/ compatibility issues). And never, never migrate old exclusions!!

When using exclusion make sure it is documented (ticket number, reason, troubleshooting details). Defining exclusions lowers the protection offered by Microsoft Defender Antivirus.

Explanation of the exclusions is not part of the MDE series with a reason. Fabian Bader published an in-depth exclusions guide with almost all related information. Must read!!!

Fabian Bader/ Cloudbrothers.info: The Hitchhiker’s Guide to Microsoft Defender for Endpoint exclusions

Common mistake; Only network protection deployed without SmartScreen

Network protection is critical in combination with Defender for Endpoint network indicators and web content filtering. For blocking indicators the Network protection feature must be enabled in block mode. Network protection is an attack surface reduction capability, and prevents access to dangerous domains or custom-blocked indicators.

The network protection component of Defender for Endpoint identifies and blocks connections to C2 infrastructures used in ransomware attacks. Blocking C2 attacks makes Network Protection more important.

Enable SmartScreen for Edge and include the SmartScreen potentially unwanted app feature (removes the yellow warning of Defender). Don’t forget to enable SmartScreen for all components (Windows Explorer)

For Microsoft Edge browsers Defender SmartScreen must be enabled.

See blogs 4A and part 4B for more information and the configuration.

Common mistake; disabling auto-remediation

Currently, 5 different levels of remediation are available. Full automation is recommended and has been configured by default since 2021 for new tenants. I still see environments where the automated investigation is completely disabled for all machines.

When AIR is disabled (No automated response) there is no automated investigation. Full automation has proven to be reliable, efficient, and safe, and is recommended for all customers. Full automation frees up your critical security resources so they can focus more on your strategic initiatives.

When full automated response is not possible – configure at least one of the semi-levels. Avoid disabling AIR completely, since this lacks in the protection and attack disruption capabilities.

Common mistake; Not using Advanced Hunting/ Custom detections

Advanced Hunting is powerful. Out of the box Defender for Endpoint is not alerting for all activities. Advanced Hunting is powerful enough to create additional detection and close the detection caps. Since a lot of data can be found in the Advanced Hunting dataset.

With custom detections, you can proactively monitor for and respond to various events and system states, including suspected breach activity and misconfigured endpoints, and automate response actions. With the availability of data, there are many use cases to use the customs detection capabilities.

Community/ Microsoft sources

Microsoft is actively developing Microsoft Defender 365. It is important to follow the latest improvements and insights around the product.

Microsoft Defender for Endpoint in-depth book

Tip: Some Microsoft employees created a new book with the name: Microsoft Defender for Endpoint In-Depth: Achieve mastery in implementation and take any organization’s endpoint security to the next level.

Absolutely recommended for getting more Defender for Endpoint In-Depth knowledge. Buy the book here

Online Community

Some good sources/ websites/ social accounts:

Microsoft

Community websites

Twitter sources

LinkedIn sources

Probably forgot to add a lot, ping me when there are more good community resources.

Own website

View all related Defender for Endpoint content. Expect more in-depth blogs for specific features. Overview Defender for Endpoint content. Or follow me via Linkedin/ Twitter

Part 10 of the Microsoft Defender for Endpoint series is completed – focused on the explanation of the automation features using Logic App and Sentinel.

Searching for specific Defender for Endpoint information? Use the contact submission form and share the post ideas or contact using Linkedin or Twitter. I will take all suggestions into the Defender for Endpoint series and help the community as far as possible.

View previous part – Microsoft Defender for Endpoint series – Automation via Logic Apps and Sentinel – Part9