Custom indicators of compromise (IoC) are an essential feature for every endpoint solution. Custom IoCs provide SecOps with greater capacity to fine-tune detections based on their organization’s particular and contextualized threat intelligence. Microsoft Defender for Endpoint supports a robust and comprehensive custom IoC platform.
In this blog, we will discuss recommendations for using custom IoCs to maximize their capabilities. In addition, we will provide recommendations for customers who ingest large threat intelligence (TI) feeds (beyond our limit of 15,000 indicators per tenant) or have more complex rules. However, note that the more indicators are added, the more management is needed.
Use ‘allow IoC’ sparingly
Each time an IoC is allowed, it opens new attack vectors as well as increases the IoC count. We recommend that you limit the number of allow IoC policies that bypass Microsoft Defender Antivirus, SmartScreen, attack surface reduction (ASR), or web content filtering blocks.
Allow IoC is used for exclusion management. If there is an entity that is blocked by Microsoft Defender Antivirus or SmartScreen that you do not want blocked on your devices, you can add a policy to allow for the entity you want to unblock. Additionally, you can keep your ASR or web content filtering rules but exclude certain entities that would have been blocked by those rules. According to the conflict handling guidance, the custom IoC will win over ASR and web content filtering rules and Microsoft Defender Antivirus and SmartScreen ratings.
Set an expiration date when importing new indicators
Third party threat intelligence (TI) can give insight into recently released malware or malicious websites. Ingesting these feeds can enrich your cybersecurity telemetry and give your devices an extra level of security. Custom IoCs provide the ability to import these feeds and block or monitor these entities.
We recommend setting an expiration date when ingesting recently added or relevant indicators to your organization to minimize the common overlap between third party TI and Microsoft TI that feeds solutions like Microsoft Defender for Endpoint. Setting an expiration date can also remove aged indicators that are more likely to have already been blocked by Defender Antivirus, and can make room for newer intelligence.
To import third party TI, either use the indicator API or upload a csv file through the portal. Set the expiration date to a few days in advance and once the expiration date passes, import a fresh set of indicators from the previous few days.
Many of our customers use custom IoCs to ingest third party TI feeds. For example, many of them integrate MISP with Microsoft Defender for Endpoint. MISP is a free, open-source platform to share indicators and it consolidates many TI feeds. They import the previous few days' worth of indicators, set the action to block these indicators, generates alerts, and set an expiration date of 3 days. Then, after the expiration date has passed, they push a new set of indicators from the previous few days.
Other enterprise customers have opted to directly import indicators from third party intelligence feed APIs such as PhishTank and Phishunt.
Identify and remove duplicate indicators
Duplicate indicators count towards the 15,000 indicator limit per tenant but result in the duplicate indicator’s policy not being enforced. Let’s go over a few examples of duplicate indicators and ways to identify and remove them.
- Indicators with the same device group, enforcement target, and action
Defender for Endpoint already detects this type of duplicate indicator and does not import it. If importing through the portal, Defender will automatically update the existing policy with the new expiration date and alert severity/details if they differ from those of the previous policy.
Policies with the same device group and enforcement target but conflicting actions follow a policy conflict handling order. Refer to the IoC support documentation on conflict handling file/cert and domain/URL/IP. Note that the conflict handling orders differ for file/cert vs. domain/URL/IP.
To detect existing conflicting IoCs, execute this PowerShell script which detects and reports them.
- Indicators already blocked by Defender Antivirus or SmartScreen
Many indicators are already blocked by Defender Antivirus or SmartScreen, and therefore don’t need an IoC block policy. You can use the Virus Total API to verify whether Defender already blocks the entity and if so, not import the indicator.
For example, when looking at the ThreatFox feed from abuse.ch, 94% of the SHA 256 indicators are already blocked by Defender AV and therefore don’t need to be imported.
Note: The Virus Total Public API has a limit of 4 requests/minute while the Premium API allows for an unlimited number of requests.
- File indicators with hash collisions
Defender for Endpoint allows for importing of SHA256, SHA1, and MD5 hashes. There can be hash collisions, however, where there are different types of hashes for the same file, resulting in only the longer hash’s policy being applied.
To detect duplicate indicators upon import, you can execute this Powershell script which detects and reports conflicting indicators, file indicators already blocked by Defender, and file indicators with hash collisions.
- File and Cert Indicators already blocked by application control solutions
Application control capabilities, such as those that are included in Windows 10, or its predecessor Applocker, can also restrict execution based on allow or block lists. If file and cert indicators are also blocked by an application control solution, then the file/cert IoC is a duplication and should be removed.
Application control and Applocker can block on cert and Authenticode file hashes. Additionally, the policy limited for both Applocker and application control has greater capacity than Defender for Endpoint’s IoC solution. To learn about application control and Applocker enforcement capabilities, visit the documentation resources below:
You can also learn more about viewing application control and Applocker events with advanced hunting in the documentation about querying application control events.
Periodically clean up old indicators
Our final recommendation is to periodically go through your indicators and clean up ones that may no longer be relevant, such as indicators with no expiration date. To help with these periodic reviews and revisions, a best practice is to add a description with a reason whenever an indicator is added.
We hope that you’ve found this guidance useful in offering recommendations and best practices to optimize the usage of custom IoCs to ingest an organization’s particular and contextualized threat intelligence. Let us know your feedback and questions and check out the additional resources below!
Resources for using IoCs:
