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
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.
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:
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
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".
src="https://www.fireeye.com/content/dam/legacy/ammo/Image-11.png" />
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.
src="https://www.fireeye.com/content/dam/legacy/ammo/Image-21.png" />
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.
class="alignnone size-full wp-image-5217"
src="https://www.fireeye.com/content/dam/legacy/ammo/Image-31.png" />
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:
When you use Boolean logic, remember the following:
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.