3 common Defender for Endpoint configuration errors

Both Stefan and Mattias from the Sec-Labs team, have conducted numerous Defender for Endpoint health checks. Apart from other configuration errors, three settings are frequently misconfigured, affecting overall security.

When we discussed this, we realized we should probably write a full configuration recommendation. But let’s start with these 3 settings that are related to each other

Number one – Cloud Protection turned off or not correct cloud block protection

Cloud protection extends the threat detection capabilities in the antimalware engine and is used to enhance real-time protection with the strength of cloud. It’s a common observation in the health checks that this is turned off or not configured to block at the correct level.

The following table contains information about the components in cloud protection and comes from an older blog from Microsoft https://www.microsoft.com/en-us/security/blog/2019/06/24/inside-out-get-to-know-the-advanced-technologies-at-the-core-of-microsoft-defender-atp-next-generation-protection/

Metadata-based ML engineSpecialized ML models, which include file type-specific models, feature-specific models, and adversary-hardened monotonic models, analyze a featurized description of suspicious files sent by the client. Stacked ensemble classifiers combine results from these models to make a real-time verdict to allow or block files pre-execution.
Behavior-based ML engineSuspicious behavior sequences and advanced attack techniques are monitored on the client as triggers to analyze the process tree behavior using real-time cloud ML models. Monitored attack techniques span the attack chain, from exploits, elevation, and persistence all the way through to lateral movement and exfiltration.
AMSI-paired ML enginePairs of client-side and cloud-side models perform advanced analysis of scripting behavior pre- and post-execution to catch advanced threats like fileless and in-memory attacks. These models include a pair of models for each of the scripting engines covered, including PowerShell, JavaScript, VBScript, and Office VBA macros. Integrations include both dynamic content calls and/or behavior instrumentation on the scripting engines.
File classification ML engineMulti-class, deep neural network classifiers examine full file contents, provides an additional layer of defense against attacks that require additional analysis. Suspicious files are held from running and submitted to the cloud protection service for classification. Within seconds, full-content deep learning models produce a classification and reply to the client to allow or block the file.
Detonation-based ML engineSuspicious files are detonated in a sandbox. Deep learning classifiers analyze the observed behaviors to block attacks.
Reputation ML engineDomain-expert reputation sources and models from across Microsoft are queried to block threats that are linked to malicious or suspicious URLs, domains, emails, and files. Sources include Windows Defender SmartScreen for URL reputation models and Office 365 ATP for email attachment expert knowledge, among other Microsoft services through the Microsoft Intelligent Security Graph.
Smart rules engineExpert-written smart rules identify threats based on researcher expertise and collective knowledge of threats.
ML engineA set of light-weight machine learning models make a verdict within milliseconds. These include specialized models and features that are built for specific file types commonly abused by attackers. Examples include models built for portable executable (PE) files, PowerShell, Office macros, JavaScript, PDF files, and more.
Behavior monitoring engineThe behavior monitoring engine monitors for potential attacks post-execution. It observes process behaviors, including behavior sequence at runtime, to identify and block certain types of activities based on predetermined rules.
Memory scanning engineThis engine scans the memory space used by a running process to expose malicious behavior that may be hiding through code obfuscation.
AMSI integration engineDeep in-app integration engine enables detection of fileless and in-memory attacks through Antimalware Scan Interface (AMSI), defeating code obfuscation. This integration blocks malicious behavior of scripts client-side.
Heuristics engineHeuristic rules identify file characteristics that have similarities with known malicious characteristics to catch new threats or modified versions of known threats.
Emulation engineThe emulation engine dynamically unpacks malware and examines how they would behave at runtime. The dynamic emulation of the content and scanning both the behavior during emulation and the memory content at the end of emulation defeat malware packers and expose the behavior of polymorphic malware.
Network engineNetwork activities are inspected to identify and stop malicious activities from threats.

When it’s configured (which is normally default, but should be verified that no policy is actually disabling it) the cloud block level must be configured.

The following blocking levels are available:

Default blocking levelprovides strong detection without increasing the risk of detecting legitimate files
Moderate blocking levelprovides moderate only for high confidence detections
High blocking levelapplies a strong level of detection while optimizing client performance (but can also give you a greater chance of false positives)
High + blocking levelapplies extra protection measures (might affect client performance and increase your chance of false positives)
Zero toleranceblocking level blocks all unknown executables

It is recommended to at least be on the High blocking level

For more information about cloud block level and how to configure it, please visit https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/specify-cloud-protection-level-microsoft-defender-antivirus

As shown in below picture, the cloud protection feature is really important

More information about Cloud protection is available here: https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/cloud-protection-microsoft-defender-antivirus

Number two – Sample submission

If a suspicious is detected and depending on setting, a sample is sent to the cloud service for analysis while Microsoft Defender Antivirus blocks the file. As soon as a determination is made, the file is either released or blocked by the AV.

How does this process work? Cloud protection and sample submission at Microsoft Defender Antivirus | Microsoft Learn

  1. Client-based machine-learning models, blocking new and unknown malware.
  2. Local behavioral analysis, analyze and stopping file-based and file-less attacks.
  3. Antivirus, detecting common malware through generic and heuristic techniques.
  4. Cloud-based protection is provided for cases when Antivirus running on the endpoint needs more intelligence to verify the intent of a suspicious file
  5. file metadata is sent to the cloud protection service. Often within milliseconds, the cloud protection service can determine based on the metadata as to whether the file is malicious or not a threat.
  6. The cloud query of file metadata can be a result of behavior, mark of the web, or other characteristics where a clear verdict isn’t determined.
  7. A small metadata payload is sent, with the goal of reaching a verdict of malware or not a threat. The metadata doesn’t include personally identifiable information (PII). Information such as filenames, are hashed.
  8. Can be synchronous or asynchronous. For synchronous, the file won’t open until the cloud renders a verdict. For asynchronous, the file opens while cloud protection performs its analysis.
  9. Metadata can include PE attributes, static file attributes, dynamic and contextual attributes, and more

For the settings…

The Sample submission has 4 different settings. In the health checks, a common observation is that it is disabled (do not send) or always prompt.

For cloud protection to work properly, it must be configured to Send all Samples automatically or (at least) Send safe samples automatically.

To stress further, you will not have full protection if this is configured in the wrong way!

Se below for details.

  1. After examining the metadata, if Microsoft Defender Antivirus cloud protection can’t reach a conclusive verdict, it can request a sample of the file for further inspection. This request honors the settings configuration for sample submission:
    1. Send safe samples automatically
      • Safe samples are samples considered to not commonly contain PII data like: .bat, .scr, .dll, .exe.
      • If file is likely to contain PII, the user gets a request to allow file sample submission.
      • This option is the default on Windows, macOS, and Linux.
    2. Always Prompt
      • If configured, the user is always prompted for consent before file submission
      • This setting isn’t available in macOS and Linux cloud protection
    3. Send all samples automatically
      • If configured, all samples are sent automatically
      • If you would like sample submission to include macros embedded in Word docs, you must choose “Send all samples automatically”
      • This setting isn’t available on macOS cloud protection
    4. Do not send
      • Prevents “block at first sight” based on file sample analysis
      • “Don’t send” is the equivalent to the “Disabled” setting in macOS policy and “None” setting in Linux policy.
      • Metadata is sent for detections even when sample submission is disabled
  2. After files are submitted to cloud protection, the submitted files can be scanneddetonated, and processed through big data analysis machine-learning models to reach a verdict. Turning off cloud-delivered protection limits analysis to only what the client can provide through local machine-learning models, and similar functions.

Number 3 – Extended cloud block timeout

The last feature in this post, is the extended cloud block timeout.

If you read the whole post, you have probably noticed that all these 3 features should be configured together since they depend on each other to better protect the endpoint.

While the cloud protection is analyzing the file that was found suspicious, antivirus can block the file from running. As default, it will prevent the file from running for 10 seconds but this can be configured to up to 50 seconds (plus the 10 default seconds) to allow cloud protection to do more analysis like detonation before the file is released.

This happens on suspicious files, and should not have impact on end users!

Block at first sight and its prerequisites must be enabled before you can specify an extended timeout period.


Happy Hunting!

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.