Indicators of Compromise, or IOCs, are key elements in blue team activities. IOCs are mainly small pieces of technical information that have been collected during investigations, threat hunting activities or malware analysis. About the last example, the malware analyst's goal is identify how the malware is behaving and how to indentify it.

Most common IOCs are:

• IP addresses
• Domains/FQDN
• Process names
• File names
• Mutexes
• Email addresses
• MAC addresses
• URLs
• Hashes
• Cookies
• …

Once collected, these information are re-used to search for other infected computers or to hunt. By example, if a compromised computer tried to contact a specific IP address, you could discover more victims by searching for traffic to this IP in your firewall logs. Pretty convenient… The goal is also to share these IOCs with your peers to increase the community security posture.

Yes but… (there is always a but), if you blindly use IOCs collected by third parties, you will probably face issues like a flood of false positive alerts. Just a few examples:

• Some organisations pushes IOCs extracted from sandboxes to their feeds. If the analyzed malware used 8.8.8.8 (a lot of them do), this IP address will be categorized as an IOC and will probably certainly generate a lot of noise
• Many Wordpress instances are hosted on shared servers or in the cloud. Their IP address is also a bad candidate for an IOC
• Malware use classic services to exchange data (like Discord, Pastebin, …)

Note that most tools used to managed and share IOCs have security controls in place to try to avoid these situations. By example, MISP has "warning lists"[1] for this purpose.

Instead of categorizing raw data as “IOCs”, I prefer to use another term “observable” (like the incident management platform TheHive[2] does). When you investigate an incident and find, by example, IP addresses, they are created with a status of “observable” (read: something that you saw). Then, it’s up to a security analyst or any automated processes to verify if the IP address is reliable and interesting (to enrich the observables). Only after this step, an observable can be converted into an IOC.

In the screenshot below, the observed IP address has been analyzed and it was decided to convert it to an IOC:

The idea is to further process only IOC (validated observables). They will be injected in the hunting process or shared with peers. Note also that an IOC without context is useless. Imagine that you're working for a big bank and you collect some IOCs related to a banking malware. They will be useful for other banks but less relevant for organizations active in other domains...

Keep in mind that a threat intel feed quality is not related to its size! I prefer to have 500 relevant IOCs instead of 5000 that will generate a lot of noise! In threat intelligence, size does not mather! But quality does...

[1] https://github.com/MISP/misp-warninglists
[2] https://thehive-project.org

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key