Can You Trust Your IoCs?


Monday 9:35am. One of our customers receives an alert that their CounterCraft Cyber Deception Platform has detected an interesting threat actor: Carbanak/Anunak.

Taking a closer look at the notification, we can see that it seems that CounterCraft detected an IoC belonging to a threat actor.

But when we take a look at the event that triggered the notification, we notice that the IP address was used by a process path associated with a very well-known crypto-miner:

Data from CounterCraft providing process context about the alert

Hmm, this is so strange… Has Carbanak/Anunak changed their business to crypto mining? The key as to why we think that this alert is from crypto miners and not Carbanak/Anunak is the /tmp/.X25-unix/.rsync path. This is a well known path that a cryptominer uses. (You can read our blog about it here.)

Let’s double check that.

Checking IBM X-Force to see if ip address was still part of the Carbanak group

Yes, it is the same IP address. So, what happened?

Basically, that IP address has been reused by another organization or individual - which, by the way, appears to have been compromised and is now mining 24x7.

So, can we trust the IoCs we use in our daily operations? The answer is — sort of.

Information vs Intelligence

The threat intelligence community has been using Indicators of Compromise (IoCs) since its origin. We all agree that there is a lot of misunderstanding around information (data) and intelligence, despite the fact that both terms are often used interchangeably.

Our colleagues at FireEye published a nice blog post describing the differences between information and intelligence, and why context is really important. Information is usually a feed of raw, unfiltered data, aggregated from virtually every source, and always contextless. Intelligence, on the other hand, is processed, evaluated and interpreted, and should be relevant, timely and complete (with context).

For the last 15 years, organizations have been stockpiling millions of small pieces of data, called Indicators of Compromise (IoCs), like there’s no tomorrow (our own cyber Diogenes Syndrome). Almost every security team receives different feeds, coming from open source intelligence sources or private companies. Those IoC’s typically consist of domain names, IP addresses, binary hashes, etc.

David J Bianco did a great job back in 2013 with his Pyramid of Pain describing how organizations were struggling to use those indicators in an effective way; that article is still valid in 2021, as very few organizations are making them actionable.

Diagram: David Bianco - Pyramid of Pain

Threat actors are going to burn their indicators as soon as they think they have been detected. Some not-so-advanced threat actors will keep reusing them, but that is a very bad OPSEC, which in turn is very good evidence that allows threat intelligence practitioners to link incidents by the same actor.

In our case, it is very likely that Carbanak/Anunak burned the entire infrastructure once they were discovered.

We also like how John Lambert visually described the journey inside those organizations that try to make them actionable:

Diagram: John Lambert - Threat Intel Journey

It is true that any newcomer to the Threat Intelligence community will be overwhelmed by the number of IoCs (i.e., “Drown in the IOC Rapids”). Let’s have a quick look at some of the most popular platforms:


We can see 25M malware hashes, 50M domain names, 48M IP addresses.

AlienVault OTX

We can see 4M malware hashes, 25M domain names, and 4M IP addresses.

The importance of context and time when using IoCs

Now that we can get millions of IoCs in a few minutes, we need to discuss the limitations of using them. The truth is that the vast majority of those IoCs are totally useless because they are dated and lack context.

Context is key in order to make an IoC actionable; an IoC should include relevant information that can help to answer some questions (when, where, attack stage, target, vertical …).

And time is also key because as we have seen in our alert, the IP address was being reused by another owner—Carbanak/Anunak was no longer using it.

So, are IoCs still valid?

Yes, they are, but only with context. Instead of stockpiling tons of IoCs, we should be collecting (as Mr Bianco stated in his Pain Pyramid) TTPs that can help to detect any activities from known threat actors.

IoCs are very relevant when they are fresh, or when the actor does not know we have them.

This post shows that threat intelligence is broken without context. This is the threat analyst’s journey: a notification that has a simple conclusion, but the context that is provided leads to a discovery, and deeper intelligence. In this case, the CounterCraft platform was able to go beyond simple tagging and add some context by analyzing what happened. This would not be possible with an IoC delivered from a third party service.

So, please, keep using your IoCs—but be discerning and use good judgement.

Like Jim Morrison said, this is the end. But you can...