Edit

Share via

Overview of indicators in Microsoft Defender for Endpoint

  • Article

Applies to:

Tip

Want to experience Microsoft Defender for Endpoint? Sign up for a free trial.

Indicator of compromise (IoC) overview

An Indicator of compromise (IoC) is a forensic artifact, observed on the network or host. An IoC indicates - with high confidence - a computer or network intrusion has occurred. IoCs are observable, which links them directly to measurable events. Some IoC examples include:

  • hashes of known malware
  • signatures of malicious network traffic
  • URLs or domains that are known malware distributors

To halt other compromise or prevent breaches of known IoCs, successful IoC tools should be able to detect all malicious data that is enumerated by the tool's rule set. IoC matching is an essential feature in every endpoint protection solution. This capability gives SecOps the ability to set a list of indicators for detection and for blocking (prevention and response).

Organizations can create indicators that define the detection, prevention, and exclusion of IoC entities. You can define the action to be taken as well as the duration for when to apply the action, and the scope of the device group to apply it to.

This video shows a walkthrough of creating and adding indicators:

About Microsoft indicators

As a general rule, you should only create indicators for known bad IoCs, or for any files / websites that should be explicitly allowed in your organization. For more information on the types of sites that Defender for Endpoint can block by default, see Microsoft Defender SmartScreen overview.

False Positive (FP) refers to a SmartScreen false positive, such that it's considered to be malware or phish, but actually isn't a threat, so you want to create an allow policy for it.

You can also help drive improvements to Microsoft's security intelligence by submitting false positives, and suspicious or known-bad IoCs for analysis. If a warning or block is incorrectly shown for a file or application, or if you suspect an undetected file is malware, you can submit a file to Microsoft for review. For more information, see Submit files for analysis.

IP/URL indicators

You can use IP/URL indicators to unblock users from a SmartScreen false positive (FP) or to override a Web Content Filtering (WFC) block.

You can use URL and IP indicators to manage site access. You can create interim IP and URL indicators to temporarily unblock users from a SmartScreen block. You might also have indicators that you keep for a long period of time to selectively bypass web content filtering blocks.

Consider the case where you have a web content filtering categorization for a particular site that is correct. In this example, you have web content filtering set to block all social media, which is correct for your overall organizational goals. However, the marketing team has a real need to use a specific social media site for advertising and announcements. In that case, you can unblock the specific social media site using IP or URL indicators for the specific group (or groups) to use.

See Web protection and Web content filtering

IP/URL Indicators: Network protection and the TCP three-way handshake

With network protection, the determination of whether to allow or block access to a site is made after the completion of the three-way handshake via TCP/IP. Thus, when a site is blocked by network protection, you might see an action type of ConnectionSuccess under NetworkConnectionEvents in the Microsoft Defender portal, even though the site was blocked. NetworkConnectionEvents are reported from the TCP layer, and not from network protection. After the three-way handshake has completed, access to the site is allowed or blocked by network protection.

Here's an example of how that works:

  1. Suppose that a user attempts to access a website on their device. The site happens to be hosted on a dangerous domain, and it should be blocked by network protection.

  2. The three-way handshake via TCP/IP commences. Before it completes, a NetworkConnectionEvents action is logged, and its ActionType is listed as ConnectionSuccess. However, as soon as the three-way handshake process completes, network protection blocks access to the site. All of this happens quickly. A similar process occurs with Microsoft Defender SmartScreen; it's when the three-way handshake completes that a determination is made, and access to a site is either blocked or allowed.

  3. In the Microsoft Defender portal, an alert is listed in the alerts queue. Details of that alert include both NetworkConnectionEvents and AlertEvents. You can see that the site was blocked, even though you also have a NetworkConnectionEvents item with the ActionType of ConnectionSuccess.

File hash indicators

In some cases, creating a new indicator for a newly identified file IoC - as an immediate stop-gap measure - might be appropriate to block files or even applications. However, using indicators to attempt to block an application might not provide the expected results as applications are typically composed of many different files. The preferred methods of blocking applications are to use Windows Defender Application Control (WDAC) or AppLocker.

Because each version of an application has a different file hash, using indicators to block hashes isn't recommended.

Windows Defender Application Control (WDAC)

Certificate indicators

In some cases, a specific certificate that's used to sign a file or application that your organization is set to allow or block. Certificate indicators are supported in Defender for Endpoint, if they use the .CER or .PEM file format. See Create indicators based on certificates for more details.

IoC detection engines

Currently, the supported Microsoft sources for IoCs are:

Cloud detection engine

The cloud detection engine of Defender for Endpoint regularly scans collected data and tries to match the indicators you set. When there's a match, action is taken according to the settings you specified for the IoC.

Endpoint prevention engine

The same list of indicators is honored by the prevention agent. Meaning, if Microsoft Defender Antivirus is the primary antivirus configured, the matched indicators are treated according to the settings. For example, if the action is "Alert and Block", Microsoft Defender Antivirus prevents file executions (block and remediate) and a corresponding alert appears. On the other hand, if the Action is set to "Allow", Microsoft Defender Antivirus doesn't detect or block the file.

Automated investigation and remediation engine

The automated investigation and remediation behave similarly to the endpoint prevention engine. If an indicator is set to "Allow", automated investigation and remediation ignores a "bad" verdict for it. If set to "Block", automated investigation and remediation treats it as "bad".

The EnableFileHashComputation setting computes the file hash for the cert and file IoC during file scans. It supports IoC enforcement of hashes and certs belong to trusted applications. It's concurrently enabled with the allow or block file setting. EnableFileHashComputation is enabled manually through Group Policy, and is disabled by default.

Enforcement types for Indicators

When your security team creates a new indicator (IoC), the following actions are available:

  • Allow: the IoC is allowed to run on your devices.
  • Audit: an alert is triggered when the IoC runs.
  • Warn: the IoC prompts a warning that the user can bypass
  • Block execution: the IoC won't be allowed to run.
  • Block and remediate: the IoC won't be allowed to run and a remediation action will be applied to the IoC.

Note

Using Warn mode will prompt your users with a warning if they open a risky app or website. The prompt won't block them from allowing the application or website to run, but you can provide a custom message and links to a company page that describes appropriate usage of the app. Users can still bypass the warning and continue to use the app if they need. For more information, see Govern apps discovered by Microsoft Defender for Endpoint.

You can create an indicator for:

The table below shows exactly which actions are available per indicator (IoC) type:

IoC type Available actions
Files Allow
Audit
Warn
Block execution
Block and remediate
IP addresses Allow
Audit
Warn
Block execution
URLs and domains Allow
Audit
Warn
Block execution
Certificates Allow
Block and remediate

The functionality of pre-existing IoCs won't change. However, the indicators were renamed to match the current supported response actions:

  • The "alert only" response action was renamed to "audit" with the generated alert setting enabled.
  • The "alert and block" response was renamed to "block and remediate" with the optional generate alert setting.

The IoC API schema and the threat IDs in advance hunting are updated to align with the renaming of the IoC response actions. The API scheme changes apply to all IoC Types.

Note

There is a limit of 15,000 indicators per tenant. Increases to this limit are not supported.

File and certificate indicators do not block exclusions defined for Microsoft Defender Antivirus. Indicators are not supported in Microsoft Defender Antivirus when it is in passive mode.

The format for importing new indicators (IoCs) has changed according to the new updated actions and alerts settings. We recommend downloading the new CSV format that can be found at the bottom of the import panel.

If indicators are synced to the Microsoft Defender portal from Microsoft Defender for Cloud Apps for sanctioned or unsanctioned applications, the Generate Alert option is enabled by default in the Microsoft Defender portal. If you try to clear the Generate Alert option for Defender for Endpoint, it is re-enabled after some time because the Defender for Cloud Apps policy overrides it.

Known issues and limitations

Customers might experience issues with alerts for Indicators of Compromise. The following scenarios are situations where alerts aren't created or are created with inaccurate information. Each issue is investigated by our engineering team.

  • Block indicators: Generic alerts with informational severity only will be fired. Custom alerts (that is, custom title and severity) aren't fired in these cases.
  • Warn indicators: Generic alerts and custom alerts are possible in this scenario, however, the results aren't deterministic due to an issue with the alert detection logic. In some cases, customers might see a generic alert, whereas a custom alert might show in other cases.
  • Allow: No alerts are generated (by design).
  • Audit: Alerts are generated based on the severity provided by the customer.
  • In some cases, alerts coming from EDR detections might take precedence over alerts stemming from antivirus blocks, in which case an information alert is generated.

Microsoft Store apps cannot be blocked by Defender because they're signed by Microsoft.

Tip

Do you want to learn more? Engage with the Microsoft Security community in our Tech Community: Microsoft Defender for Endpoint Tech Community.