IOC's turning into IOOI's
Last Updated: 2020-10-01 10:40:47 UTC
by Daniel Wesemann (Version: 1)
Remember, back in the days, when the anti-virus vendors looked with derision at some of their competition, exclaiming "But they are using just SIGNATURES. Our tool detects BEHAVIOURS". That was like 15 years ago. Fast forward to today, with many of the same vendors now selling "threat intelligence feeds" for good money, and the most frequent attributes pushed over these feeds are MD5/SHA1 hashes and IP addresses. The main thing that changed is that we now call these items "IOCs" (Indicators of Compromise) instead of "signatures", but they still mostly are what they always were: Binary fingerprints that are very easy for an attacker to change.
There certainly is some value in detecting IPs and SHA1 hashes, but for most of these IOCs, their value rapidly diminishes within hours or days after the artefact was first sighted in the wild. With the bad guys making increased use of Cloud based infrastructure, and correspondingly rapid change and re-use of IP addresses, even the most useful IP address "IOC" can rapidly turn from an indicator of compromise into an "IOOI", an Indicator of outdated Intelligence.
IOOI - that's what I call it when we get a match on an IP that freshly came over a threat intel feed, but after analysis, we end up with the determination that our match is just for some innocent party who "inherited" a cloud based IP address that, hours or days or weeks earlier, had been used by someone else, for malicious purposes.
In 2013, David Bianco published his paper on what he called "The Pyramid of Pain" where he details the different types of "indicators", and the corresponding "pain" inflicted on attackers when these indicators are getting detected or blocked. The little snag about that pyramid though is that it is also a "Pyramid of Effort" for us in the defense to effectively detect the corresponding artefacts.
Matching against IPs and hash IOCs is trivial, once you collect the necessary logs. Reliably detecting TTPs (Tactics Techniques and Procedures) in comparison still requires some skilled and continuous effort for this detection to remain up to date, functional and relevant. But like most things in life, it is the more difficult and harder endeavours that are the ones worth pursuing. So if you haven't done so yet, take a look at MITRE's excellent "ATT&CK" framework, and the detailled real-life attack techniques described therein. Then, for each of the techniques mentioned, assess how good your current tooling and procedures are in catching these individual techniques. Be honest with yourself, and don't be discouraged by the gaps that you'll inevitably discover ... but then prioritize, and start plugging away at shoring them up.
Since you already have the capability to match IPs and hashes from your "threat intel feeds" against your logs, chances are you also already have the logs and capabilities in place that are necessary to go looking for TTPs. But unlike matching on IP and Hash IOCs, spending time on TTP detection will, over time, give you detection capability that is uniquely tuned to YOUR environment. And that's where the value is, much more so than in chasing matches for IOCs that turn out to be IOOIs.
If you have your own experiences with IOOIs, or with TTP detection capabilities that have a longer half-life than simple IOCs, please let us know or share in the comments below.