Not All IOC Scanning Is the Same

In the recent months I had several talks with friends and coworkers about IOC scanning and how to integrate IOCs from threat intel feeds into our scanners or other products that our customers already use. People often tell me that EDR or client management product X already does IOC scanning and that we don’t need to check for these indicators a second time. 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.

IOC scanning automation

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 entry)
  • 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. We use the locations that I mentioned above and others to detect them using their tools although all the files have 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)

I am sure that digital forensics experts would come up with other fruitful locations. It is just sad to see those great indicators feed into tools that do „IOC scanning“ only to get another check mark in a product comparison table – aka the „compulsory“ way.

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?“.

Tags: , , , , , , , , , , ,

About Florian Roth

Senior IT Security Engineer: THOR APT Scanner, Security Monitoring and SIEM, Web Application Audits, Advanced Persistent Threats (APT), Malware Analysis, Incident Response, Intrusion Detection, Perl / Python / .NET Programming, Data Visualization

No comments yet.

Schreibe einen Kommentar