MICROSOFT SENTINEL | THREAT INTEL
How to Create and Manage Indicators in Microsoft Sentinel
Tips for creating and managing indicators of compromise
Microsoft Sentinel makes it easy to subscribe to threat intelligence indicator feeds and automatically import hundreds or thousands of indicators, which is great for staying on top of the latest threats. However, what if an indicator of compromise specific to an environment is identified during triage? This is where manually creating and managing indicators can bring value to your security operations. This post will discuss the indicator lifecycle and what goes into creating a valuable indicator of compromise in Microsoft Sentinel.
Did you know we release weekly indicators of compromise relating to the latest malware threats? Sign up for our newsletter to stay in the know:
Why create indicators?
It’s easy to overlook the ability to manually create indicators since that extra time could be used elsewhere. However, properly vetting and creating an indicator could mean additional time saved in future incidents and a better understanding of the threats targeting the organization.
For example, think of your average phishing campaign. Threat actors will usually have limited tools and infrastructure, such as domains used to host malware. A single URL may be sent to multiple targets, or the same attachment can be re-used. An analyst who performs an investigation now knows these entities are malicious and can create indicators for future investigations to save triage time or prevent the attack from occurring in the first place by configuring security tools to block the indicator.
A pattern eventually begins to unfold after establishing a collection of indicators. Analysis of this collection reveals common tactics, techniques, and procedures. This is then mapped to specific threat actors, and the SOC can update its detections to better defend against said threat actor.
Check out my previous blog post on getting value from threat intelligence indicator feeds in Microsoft Sentinel
The indicator lifecycle
It’s not enough to just create indicators. Properly managing an indicator’s lifecycle is also essential to ensure its value.
Discovery: The indicator lifecycle begins when it is first identified. This may result from analyzing a set of log data, an alert generated from a security tool, or is obtained from an external source, such as a feed or report. If malicious activity is identified, it’s worth creating an indicator.
Assessment: The indicator is then analyzed to understand its nature, which may require detonating malware in a sandbox or reviewing network traffic captures. The result of this phase is being able to classify the threat, such as a trojan horse file or phishing URL.
Deployment: After the indicator has been adequately assessed, it can be deployed to security tools. This may involve adding IP addresses to firewall blocklists or ensuring endpoint security tools block the execution of file hashes.
Detection: Once deployed, security tools will begin to alert on new activity relating to the indicator.
End of life: After some time, the indicator will reach the end of its usefulness. Ensuring that the indicator is retired correctly is critical to reducing false positives.
However, not all indicators are equal in their value and ability to be identified. File hashes are static and very accurate in identifying a threat, whereas it’s easy for an attacker to register new domain names on the fly. David Bianco wrote about the pyramid of pain, which illustrates this concept:
Creating an indicator in Microsoft Sentinel
There are two locations where a Microsoft Sentinel user can manually create an indicator: from the threat intelligence page or directly from an entity value in the incident overview. Both methods have the same procedure to add a new indicator; however, creation from an existing entity value offers the benefit of pre-filling some field values.
Creating a new indicator while on the threat intelligence page is easy. Just click the “Add new” button. To create a new indicator from the incident overview, click the menu button next to the desired entity, then click “Add to TI (Preview)”:
Indicator fields
Type: Currently, five types of indicators can be selected: domain-name, file, ipv4-addr, ipv6-addr, and url.
Value: After selecting the indicator type, the menu will update with the proper value field. All except for file indicators are simple text boxes. For file indicators, you must supply at least one file hash using the following format: <algorithm>:<hash value>. Note that Microsoft Sentinel supports the following algorithm values: MD5 | SHA-1 | SHA-256 | SHA-512 | MD6 | RIPEMD-160 | SHA-224 | SHA3–224 | SHA3–256 | SHA3–384 | SHA3–512 | SHA-384 | SSDEEPWHIRLPOOL.
Tag: Tags are where short and simple bits of information should be added to give more context into why the indicator was created. When manually creating an indicator, including a tag with the original incident ID is recommended. Other recommended tags include:
- Threat category
- Malware family
- ASN/ISP
- Protocols
Threat type: The threat types field works similarly to tags and should be used to identify the type of threat associated with the indicator. For example, file hashes associated with Trojan horse malware can have the “Trojan” threat type. SOC teams should consider developing their own threat classification methodology and can reference one of the many available threat taxonomies.
Description: The description field is a free-form text field that should contain expanded details about the indicator. The more information, the better! Some recommendations to include here are:
- How the indicator was detected
- How the indicator was identified as being malicious
Name: The name field is another free-form text field for identifying the indicator. It is recommended to keep this value short. For example, consider using “Phishing URL” for a URL indicator.
Revoke: Indicators may not always be active, and it’s a good practice to update indicators as soon as possible to reflect the state change. Ensure the “Revoked” box is checked when the indicator is inactive to prevent false positives.
Confidence: The confidence scale is a 0–100 value indicating the likelihood an indicator is malicious. The closer to the maximum value of 100, the higher confidence that the indicator is genuinely malicious. Analytical confidence levels originate from traditional intelligence analysis, such as those described in U.S. intelligence community directive 203: https://www.dni.gov/files/documents/ICD/ICD%20203%20Analytic%20Standards.pdf.
This field can be confusing to apply appropriately, and each team must agree on how they apply confidence levels and how each level impacts operations. When calculating confidence levels, one aspect to consider is the source of the indicator. Some examples that can be posed are:
- Is the data source accurate?
- Is it missing any data?
- Is it timely?
One example of a low confidence indicator could be an IP address flagged for port scanning activity. Further review of the traffic does not provide substantial proof that the IP is performing any malicious activity, but the SOC still wants to monitor this particular IP address in the future. Conversely, if an analyst has identified that a file hash belongs to malware, they can generally apply a much higher confidence level.
Kill chain: The default use case for this field is to feature the specific phase of the Lockheed Martin cyber kill chain. However, you can place any applicable text here, similar to tags. For example, in the ReversingLabs Ransomware indicator feed, we apply three kill chain phases to indicators based on the phase of a typical ransomware attack: the “Early” stage, indicating the start of a ransomware attack that includes the initial infection mechanisms, such as phishing URLs and domains; the “Middle” stage, which involves the further propagation of the malware; and the “Late” stage, which relates to indicators seen right before or just after the ransomware is activated, such as data exfiltration.
Validity timeframe: The final relevant fields are the “valid from” and “valid to” fields. As discussed previously, indicators may not always be actively in use. Attackers may rotate IP addresses and domain names, while entities like file hashes can be added permanently. For indicators that may be short-lived, a regular check for activity should be performed. An initial timeframe for indicator validity is about 30 days, and the validity may be renewed for an additional 30 days after each analysis that concludes the indicator is still malicious.
Conclusion
A healthy set of indicators of compromise, whether obtained via third-party feeds or manual creation, is a great way to improve detection and response capabilities. SOC teams should ensure the indicator lifecycle is appropriately managed, and all relevant detail is available when creating new indicators to improve the value gained from utilizing indicators.
Just getting started with threat intelligence? Check out a free trial of our Ransomware threat intelligence indicator feed for Microsoft Sentinel in the Azure Marketplace
