People often tell us that EDR product X already does IOC scanning and that they don’t have to check for these indicators a second time using our scanners. Especially when it comes to network wide sweeps for traces of activity due to an ongoing incident I recommend scanning a second time with one of our scanners or a tool of similar quality.
This blog post explains why.
People usually spend a fair amount of time on selecting threat intel feeds and interesting indicators for their scans. However when it comes to the actual application of these indicators they seem to be satisfied with the simplest form of checks.
Especially when we look at C2 or Filename IOCs I can easily explain the difference between the „compulsory“ and „freestyle“ methods of IOC scanning.
A plain „compulsory“ filename IOC check would walk the disk or query a database looking for a certain filename, right?
However if you think about it for a second and ask yourself „where else could we check for that filename?“ you’ll realize that the following elements could also contain the malicious filename:
- Eventlog entries (e.g. process starts, service installs with image path, access failures …)
- Log files (local Antivirus log file, access to file in web root > web server access log, backup errors, PowerShell history …)
- Registry (recently opened files, shell bags, service image path, other caches …)
- MFT (deleted entries)
- Archive content (packed in ZIP file)
- WMI (scripts – e.g. see this PoC by Matt Graeber)
- Crash dumps
- Windows Error Report (WER – file names and content)
- Free disk space (filename as content of batch files or other scripts, scheduled tasks …)
Actually we often see that during lateral movement attackers access systems, run their tools remotely, copy the output, delete the output files and leave no file system traces behind. Our scanners use the locations mentioned above and others to detect them although all the files have already been removed from disk. That’s the „freestyle“ method.
The same counts for the C2 IOCs. The „compulsory“ plain method would check the system’s network connections.
The „freestyle“ method also includes checking for these C2 IOCs in the following locations:
- Process memory (C2 strings loaded and decrypted in process memory)
- Log files (web server access logs, Windows firewall log file, AV module log file …)
- Hosts file
- Files (in backdoor config files on disk)
- Registry (hard coded C2 server in registry key)
It is sad to see great indicators from expensive feeds used into tools that do „IOC scanning“ the „compulsory“ way missing so many interesting spots.
If all you have is a hammer, everything looks like a nail.
So – the next time when someone tells you that their tool checks for IOCs on the endpoint, your question should be „How and where do you check for these IOCs?“.
