How Does Our SOC Deal with Threat Reports and IOCs?

There are so many threat reports and Indicators of Compromise (IOC) published from various vendors. At Pondurance, we are fully engaged in active threat hunting which allows our team to detect and investigate the threats that are relevant to our clients’ environments and uncover unknown threats for us to publish this information. Often, we get questions about what we do with this information or how we treat IOCs. For the purpose of this post, we’ll use intelligence, IOCs, and indicators interchangeably.

We are often asked how to best operationalize threat intelligence. In this blog post, we’ll discuss our process and procedures for ingesting the wide array of threat reports, IOCs, and vulnerabilities that are consistently published. And discuss the various ways to operationalize the data to provide detection resources and capabilities.

Data Sources

Let’s start by discussing data sources.

There are various intelligence sources including internal, external, free, and paid. If your team has a dedicated intelligence person, incident response (IR) team, or security operations center (SOC) working on incidents, those could produce intelligence. 

Additionally, there are reports released from vendors such as managed security service providers (MSSPs) or threat intel companies, anti-virus, or endpoint detection and response companies, or even government agencies. Blog posts are another source of information.

Confidence in indicators and intelligence can sometimes depend on sources. For example, if we’re ingesting data from a blog post, we may be cautious about believing everything that was posted compared to an FBI flash post or intelligence shared by CISA.

Validation and Research of Indicators

We also validate and research indicators. The purpose of validating and researching indicators is to ensure that the intelligence source did not have a mistake in it. Additionally, it helps to ensure that when you alert on an indicator, you’re not receiving false positive alerts because the indicator was bad. We have also seen reports produced after an attack occurred and the indicators provided were no longer relevant as the attackers had moved away from that infrastructure.

Indicators can also be researched to find additional information or patterns regarding the threat and potentially discover more IOCs. For example, if you’re dealing with an indicator that’s a domain, there are other things related to that domain that you can research. A domain has a registrar, registration date, subdomains, and IP addresses that it points to.

Same concept that applies to the domain mentioned above applies to file hashes. For example, file hash for exe file can be researched to find properties of the exe file and potentially information related to what the file does during execution, maybe network indicators captured by a sandbox.

Once we research some of these things, we need to use what we found to protect our clients’ environments.

Operationalization To Detect and Prevent

Operationalization in this case is to utilize what we learned through the activities above and use it to make decisions, implement detection, or prevention.

If we believe that we should have observed an indicator through the data we capture, we look for the occurrence of the indicator in the data we’ve captured in the past. This is to ensure that someone wasn’t compromised previously. For example, earlier this year when IOCs related to Exchange getting compromised were released, we took the IP indicators and searched network data for them. Additionally, the reports related to the compromises included filenames and URI’s so we looked for that in IIS logs.

Depending on the type of indicator, age of indicator, and if the indicator is still relevant or not, we decide on creating alerts or adding the indicator to a threat indicator alert list. For example, if a specific exploit is used in an attack, we may set up an alert for that, however, we may not set up an alert for the IP address involved in an attack because it was old.

Besides adding alerts, we may also make dashboards. Dashboards, at least in the log management system we use, show output from various different queries as widgets. If we’re not too confident about an indicator or we’ve seen high amounts of false positives, we may view just dashboards to look for a true positive.

Below, we’ll review a report and highlight some of the important things we in the SOC may care about and why.

We’ll be looking at the latest report (at the time of writing this post) from TheDFIRReport blog, which publishes high quality content regarding breaches.

Report link: https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/ 

Timelines are very important. If we were to detect any of the activity mentioned in the report, knowing how far in the ransomware or exfiltration process the attacker could be useful and guide investigations.