What are IOCs?
Indicators of compromise (IOC) are a quick and easy way for your incident reponse/security team to check if similar activity occured (reactive) or preventing future attacks by means of blocking (Pro-active). These often come in the form of file hashes, IPs or domains and recently bitcoin addresses.
There are many feeds to gain IOCs, and most people have their preference. For me, It’s Twitter as the majority of activity occurs there (IMO). A recent public facing cyber attack being the Wiper that came out Russias war on Ukraine. If missed, Symantec did some good coverage here.
As with any public facing breach/cyber attack, many organisations would have rushed to block the related IOCs however, for some, such as Florian Roth, the importance of attack vectors was echoed. Often with memes:
For the inital Wiper attack, the ESET research team seemed to be the one in the know. Their thread quickly became a dicussion point, and had researches sharing information within the comments; mainly pushing for Virustotal links. The classic; VirusTotal link or didn’t happen.
Others tried to spread the message of the attack vector. This being a bigger point than the IOCs being shared at the time. The attackers had access to an AD server!
It’s this type of information that should be the main takeaway when reading such news/ insight however is often lost in the noise of IOCs. The fact is that by reviewing how they got in and what they did can often present mitigation controls that can be generic. These controls preventing this and similar attacks.
The IOCs however only block the same attack. it’s also only relevant for a single actor or breach. For example, whilst you focused on this attack, other actors were still attacking. For the Wiper, If they modify the code slightly, or host their infra elsewhere, the IOCs become less effective if not irrelevant. It’s actually one of the reason I added this inital line to RedRabbit as the hash changes the file on load. It’s also worth contiplanting that if an attack was targeting you, would they use public known IOCs ? For bots and sprays, sure, but I’m talking about a hands on keyboard attack. It’s worth a thought, and also further echos the need to review the initial stages, instead of purely on what did they execute.
So what can we do?
Review the basics. Yeah, yeah, I know… It’s a common saying, but it’s more important than you think. The basics allow generic blocks, whilst falling down the IOC rabbit hole takes time and resource. If instead of blocking certain URLs, you focused on an allow list for servers, you would be less dependant on blocking internet based URls as you would know it’s only your allowed list. Knowing this also improves your incident response, as if these servers were attacked, you know your points of entry.
A quick start would be to answer these?
- Do you know and have a list of all of your assets?
- Are they all managed?
(Endpoint protection, up-to-date, logging correctly…).
- If not able to, what other controls have you put in place?
- Do you know all your public facing systems?
- Do you have a playbook or incident reponse procedure for breach?
TrustedSec does a good post here…
CISA is also very on point when it comes to guidance. They often share insight such as the Conti Ransomware. As you can see, IOCs are listed, however look at the TTPs, patterns, entry points and mitigation steps. Remember, the majority of these patterns will be shared by other Ransomware gangs. It’s therefore best to chose the generic and reflect on your setup.
For example, for Spearphishing. Instead of just blocking the domains, ask yourself: if your CEO got a random link, or attached document, would they open it? Can they open it? Should they be able to open it? If they did open it, do you block Macros? Do they know why or would they just click enable?
It’s questions like this that get the ball rolling.
Another example. The dreaded Ransomware. If it executed, do you have backups? Is the backup system safe? Do you monitor backup failures? Is the credenetials to access the backup system secure?
If you have a backup of the system/hosts, the attack may be less impactful. Some organsiations that have been hit, have reported that they avoided paying ransom due to having successful backups.
It’s best not to do too much straight away as doing too much quickly may break or make your defenses weaker. I find it best to start with an inventory and then work outside > In.
Firstly you need a full inventory as if you don’t know what assests you have or what is exposed (internet facing) how do you know what you’re protecting. For your internet facing systems look for quick wins. Do you have management ports exposed, do you need that internet facing, can you set geo-location blocks on senstive applications?
For your assets, are they are fully managed? Do you have your agents installed. Are they feeding your expected logs into SIEM (Visibility). Do you even have a method or tool to be able to answer these?
Just to end on… “ Are IOCs pointless then?”
IOCs are great, and can allow peace of mind, and visibility. If not for those up top as if you can ensure you have controls to block. This allows the team to sleep better. It’s the common problem as in theory if you pay for security services, it should be on them to manage this. You wouldn’t be happy with your AV/ EDR provider if they don’t block or detect any of the latest IOCs being shared however we live in a world where you have no easy way to check. That is unless you either vist the site or download the malicous file. Living in the limbo state, forces teams to block IOCs as the risk of it not being blocked by default isn’t worth taking. That being said, once they are blocked, try to put some time and resource aside to address those basic controls. This will then reduce the dependancies on such IOCs and reduce panic.
Leave a Reply