I’m going to make a statement that some of y’all might have a problem with. If you’re new to cyber, or CTI, you might have learned through training or taken a course in school that talks about IOCs while discussing Threat Intelligence.

Now I should say real quick that IOCs can be useful both, and I absolutely do use them in very specific and controlled ways.

Now that that’s out of the way… Ready?

IOC’s.

Are.

Not.

Intel.

(Also, they kinda suck.)

For our purposes here, I’m going to limit this to “traditional” atomic indicators, focusing on:

• Full-path URLs (useful, but short-lived)
• File hashes (some utility, but declining rapidly)
• Domains, (increasingly ephemeral, especially when some TLDs offer literally ZERO-cost registration)
• IP addresses (essentially worthless beyond an absurdly short Time-To-Live)

What’s wrong with dumb (in the literal sense) atomic indicators?

URLs are OK – exact full paths to consumer phishing pages are basically deterministic. They’re bad. But they exist by the tens of thousands a day. You can see literally hundreds of examples on any given day from free sources so except for finding the ones attacking your brand and sending them to a take-down vendor, what good are they?

Malware links? How hard is it for me to put my bad executable on a limitless number of pwned, free or rotating web sites, blogs and Twitter accounts? (I’ll save you the trouble – it’s a three line script.)

Hashes (if they’re higher-grade than MD5s) are definitely declarative for known-bad, but with polymorphic malware that changes for every victim, or AI bots that can now spit out custom code for every attack, so yes, a known-bad hash is a known-bad file, but a bad file is decreasingly likely to have a known-bad hash. See the problem?

IP’s and domains can be rotated with such speed they’re not even worth talking about anymore, and IP-based blocking is dangerous to Operations when bad guy web sites are intentionally put on giant CGP and AWS boxes that host 100,000 domains explicitly so that it is risky to block them.

Here’s a few more problems I’d point out that are as much philosophical as they are operational.

• IoCs are reactive: IoCs are generated after an attack has already occurred, which means that they can only be used to identify and respond to known threats. If TTLs were still long and durable that would be fine. They’re not.

• Timely, actionable IoCs – to the degree they still exist – are expensive: Collecting and analyzing IoCs requires significant resources and expertise, for which the providers often expect to be paid. Are there free sources out there? Sure, but they’re worth about what you pay for them in many cases. Ask anyone who was ever ordered to ingest the US Government’s AIS feed, then spent 100x as much money on SOC labor and SIEM charges dealing with false positives as they would have spent buying a quality IOC feed.

• IoCs don’t address root causes: A source IP or piece of malware isn’t actually the problem. The vulnerabilities that attackers exploit to gain access to systems, the failure of endpoint controls to stop the malware from executing, the lousy egress controls that permitted the exfiltration… THOSE are your problem. Spend the time and money working on those underlying issues.

Which brings me to one last thought – running searches for IOCs IS. NOT. THREAT HUNTING!!!!!

(But that’s for another blog post.)