Written by Will Gibb & Devon Kerr

One challenge investigators face during incident response is finding a way to organize information about an attackers' activity, utilities, malware and other indicators of compromise, called IOCs. The OpenIOC format addresses this challenge head-on. OpenIOC provides a standard format and terms for describing the artifacts encountered during the course of an investigation. In this post we're going to provide a high-level overview of IOCs, including IOC use cases, the structure of an IOC and IOC logic.

Before we continue, it's important to mention that IOCs are not signatures, and they aren't meant to function as a signature would. It is often understated, but an IOC is meant to be used in combination with human intelligence. IOCs are designed to aid in your investigation, or the investigations of others with whom you share threat intelligence.

IOC Use Cases:

There are several use cases for codifying your IOCs, and these typically revolve around your objectives as an investigator. The number of potential use cases is quite large, and we've listed some of the most common use cases below:

• Find malware/utility: This is the most common use case. Essentially, this is an IOC written to find some type of known malware or utility, either by looking for attributes of the binary, itself, or for some artifact created upon execution, such as a prefetch file or registry key.
• Methodology: Unlike an IOC written to identify malware or utilities, these IOCs find things you don't necessarily know about, in order to generate investigative leads. For example, if you wanted to identify any service DLL that wasn't signed and which was loaded from any directory that did not include the path "windowssystem32", you could write an IOC to describe that condition. Another good example of a methodology IOC is an IOC that looks for the Registry text value of all "Run" keys for a string ending ".jpg". This represents an abnormal condition which upon investigation may lead to evidence of a compromise.
• Bulk: You may already be using this kind of IOC. Many organizations subscribe to threat intelligence feeds that deliver a list of MD5s or IP addresses; a bulk IOC can represent a collection of those indicators. These kinds of IOCs are very black and white and are typically only good for an exact match.
• Investigative: As you investigate systems in an environment and identify evidence of malicious activity such as metadata related to the installation of backdoors, execution of tools, or files being staged for theft, you can track that information in an IOC. These IOCs are similar to bulk IOCs; however, an investigative IOC only contains indicators from a single investigation. Using this type of IOC can help you to prioritize which systems you want to analyze.

IOC components:

An IOC is made up of three main parts: IOC metadata, references and the definition. Let's examine each one of these more closely, noting that we're using the Mandiant IOC Editor (IOCe) downloadable from the Mandiant website:

Metadata: IOC metadata describes information like the author of the IOC (jsmith@domain.tld), the name of the IOC (Evil.exe (BACKDOOR) and a brief description such as "This variant of the open source Poison Ivy backdoor has been configured to beacon to 10.127.10.128 and registers itself as "Microsoft 1atent time services".

References: Within the IOC, references can find information like the name of an investigation or case number, comments and information on the maturity of the IOC such as Alpha, Beta, Release, etc. This data can help you to understand where the IOC fits in your library of threat intelligence. One common use for references is to associate an IOC with a particular threat group. It is not uncommon for certain references to be removed from IOCs when sharing IOCs with third parties.

Definition: This is the content of the IOC, containing the artifacts that an investigator decided to codify in the IOC. For example, these may include the MD5 of a file, a registry path or something found in process memory. Inside the definition, indicators are listed out or combined into expressions that consist of two terms and some form of Boolean logic.

One thing about the OpenIOC format that makes it particularly useful is the ability to combine similar terms using Boolean AND & OR logic. The previous example shows how this type of logic can be used. This type of IOC describes three possible scenarios:

1. The name of a service is "MS 1atent time services" - OR -
2. The ServiceDLL name for any service contains "evil.exe" - OR -
3. The filename is "bad.exe" AND the filesize attribute of that file is within the range 4096 to 10240 bytes.

When you use Boolean logic, remember the following:

• An AND requires that both sides of the expression are true
• An OR requires that one side of the expression is true

Understanding that the Boolean statements, such as 'The name of a service is "MS 1atent time services", OR "filename is "bad.exe" AND the filesize attribute of that file is within the range 4096 to 10240 bytes"', are evaluated separately is an important aspect understanding how the logic within an IOC works. These statements are not if-else statements, nor do they both have to exist in order for the IOC to have a match. When investigating a host, if the "MS 1atent time services" service is present, this IOC would have a match; regardless of whether or not the malicious file the IOC described was present on the host as well.

In our next post we're going to have a crash course in writing IOC definitions using the Mandiant IOC editor, IOCe.