Rigor in Threat Intel

I’m just going to say it.

IOCs are not “threat intel”. 

Lists of IP addresses and domain names, without context, are data points and information, not “intel”. Threat intel is based on patterns developed from the accumulation/aggregation of data.

In 2016, I took a look at about half a dozen Samas ransomware engagements, all worked by different IR analysts. All of these analysts were focused on servicing the IR consulting business model; that is, work the engagement, write the report, and deliver it to the customer so that they could move on to the next engagement. However, by looking across multiple engagements, I began to see commonalities and overlaps in threat actor activity, including initial access, as well as other phases of the attack that led up to the ransomware deployment within the impacted infrastructures. By seeing, verifying, and confirming activities that were observed consistently (i.e., initial access), confidence increased in the understanding of that attack phase. This was particularly valuable when, for whatever reason, logs or other artifacts weren’t available. 

As a result of our supported observations and findings, we published a blog post describing our findings, and someone reading our blog post reached out to let us know that they’d look for some of the initial indicators, and were able to prevent their own organization from being ransomed. Later, a good bit of the content provided in that original 2016 blog post was transitioned to another blog post in 2018, and the company was then later purchased by Sophos. 

However, the point remains…we were able to develop an extremely granular understanding of the threat actor’s attack chain and timing based on accumulating data across multiple engagements, and then aggregating it into threat intelligence about the threat actor.

Threat intel is based on patterns developed from an accumulation and aggregation of data, so we can use data from multiple incidents to fill in gaps in observations, understanding and detections. We can better understand a threat actor’s capabilities and situational awareness, and develop a better understanding of how the threat actor operates not only in similar environments, but also across multiple disparate environments, and how they “respond” to various “stimulus” or obstacles. We get to see what really goes on when a threat actor gains access to an endpoint or infrastructure, what actions they take, in what sequence, and with what timing, as well as how they respond to challenges, such as when something they were observed doing or using on previous engagements is not available, or some security tooling hampers or completely inhibits their ability to continue in their attack. 

I’ve seen actors try 3 times to run the “ver” command before succeeding the 4th time. I’ve seen the same threat actor make multiple attempts to launch their malicious DLL via rundll32.exe, across multiple incidents. I’ve seen threat actors respond to security tooling deleting their malware by attempting to uninstall applications that aren’t even installed on the endpoint.

I’ve also seen threat actors access an infrastructure, orient themselves, and then step off on their attack chain, installing multiple disparate persistence mechanisms. I’ve seen threat actors determine what’s running on the endpoint before copying over their tooling, and I’ve seen threat actors simply blind the available tooling with no prior recon, as if they already knew what they were dealing with in the infrastructure.

Rigor
All that being said, we also have to understand that errors compound as we aggregate that data, as well. This is why analysts must take a rigorous approach to populating that aggregated data, one that includes review, where analysts need to be able to justify their findings, rather than simply have them thrown into the “pile” and accepted as “fact” or “truth”, albeit without question. 

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.