IOCs; How to Create, Manage, and Understand -The Manifesto-

by InterDimensional_Shambler
Categories: Analysis, Host Forensics, Network Forensics
Tags: No Tags
Comments: Leave a Comment

How to Create, Manage, and Understand IOCs -The Manifesto-

[OpenIOC Background]

What are they and how does it pertain to IOCs?

OpenIOC is a framework developed by mandiant to take CUSTOM Indicators of Compromise and put them into an extensible XML schema for the intention of scanning host(s) with. This type of approach is a little like having an in-house malware scanning engine based off IOCs you have gathered / collected / decided to alert upon. These IOCs can also be shared between intelligence agencies / companies to help collaborate and combine intelligence in an EFFECTIVE and organized manner.

NOTE: You should probably invest some time researching intel vetting tools, because some of these intelligence feeds will contain ONLY IPs and domains (in the upwards of 10,000+ each).
This can be a daunting task to vet and verify this information. (You you will need to do this step because you will OFTEN find internal IPs, root DNS servers, google IPs, etc in this intel.)

More info on OpenIOC GO HERE

[IOC Logic]


Before we actually put data into an IOC we have to understand there are some caveats with the logic (and certain IOC scanning tools). At first (when you first start making IOCs) the Logic seems a bit counter-intuitive; but after a while it makes sense. The “Parameters” of an IOC contain the logic (AND/OR). the condition (is, isnot, contains, containsnot), and the item itself (fileitem-MD5). There is no error-checking so you CAN erroneously enter data (beware typos and UNVETTED outside intelligence)

The list of items you can match on in an IOC are defined in the OpenIOC schema. Mandiant’s (being used by IOCe) is here:


  • All of your IOCs will be logically grouped under ORs and ANDs.
  • Every item should be under a primary OR.
  • This first “tier” logic will match on simpler things (like hashes)
  • Then the nested logic is where you can put your AND logic (Like Filename AND the Filepath).
  • Every “tier” of nested logic should alternate (wasted cycles on duplicative logic).
  • Some of the IOC scanner tools will only scan properly when the NESTED logic is of the same type (Like all items with file data must be in the same nested AND/OR).

NOTE: This is a problem sometimes because you have to get really creative with grouping your logics and generally match on PARTIAL IOC data instead of more than one part.
Like if I need a registry item AND a filepath it would have to match on either or both instead of just both.
The plus side to this is that you will get more hits on partial data (like if the malware changed only a portion of itself it would still be caught).

[IOC Creation]

There are many ways to create an IOC; but the main method is with Mandiant’s IOC Editor


  • There are a few things I do not like about Mandiant’s IOC Editor:
  • No Bulk Modification options (No ability to select multiple things and add / delete / modify).
  • No “Sort” options.

Mandiant has a couple write-ups on how to build an effective IOC, but I will write one up (based off my own collective knowledge):

[IOC Metadata]

All of these items are metadata used by Mandiant IOCe. It is quite useful to understand how you’re utilizing the metadata because if you have a repository for these IOCs they COULD be organized, and referenced by an automation system if this metadata is used in a uniform manner. This would be very important if you get ADDITIONAL intel on an existing IOC and you had a system to query, update, and store ALL that info for the IOC without having to create a new IOC for each addition. There is quite a bit of Metadata that can be put into an IOC (you can even put your own).

IOCe will allow you to put in the following:

  • Name, Author, GUID, Created timestamp, Modified timestamp
    • There are additional metadata types in the upper-right; when you right-click you can add some of the following (These can be used to script with organization or grouping for scanning with certain indicators, etc):
  • Group, Report, Comment, Category, Grade, Threat Group, Other
  • Description (This is where you put all the information about the IOC and what it is looking for & why. If the IOC is vague {only has MD5s} it is a good idea to put other things to look for in here.)

NOW For filling the IOC with content.


Example of FAKE MalwereWolf Trojan in IOC Editor

Let’s take a made-up example malware that has simple characteristics like this:

  • [File Items]
    • MD5 x 2
    • Filepath x 2
    • Filename x 2
  • [Registry]
    • Value x 2
    • Path x 2
  • [Network]
    • Domain
    • IP

The Example of this is on the right.

Note: This IOC is made to a personal preference of “industry standards”.


You can see a lot of information in IOC Editor, and not all of this required for an IOC. I can explain some justification to a lot of this information.

  • So the left pane displays all of the IOCs loaded from the folder you specify when you open IOCe
  • You can see the Name, GUID, creator, and some timestamps of the IOC.
  • You will note that the GUID is the same as the filename (VERY important to not change the filename for some of the IOC scanning tools)
  • The upper-right pane displays all of the IOC’s metadata
  • The Bottom-Middle pane displays the IOC logic and actual “data” in the IOC
  • The Bottom-Right pane is expanded when you click that little finger-pane icon and it will allow you to add comments to each of the IOC items
  • I have not used this as this level of detail in an IOC might only be used by a serious reverse engineering IOC ingestion system.


  • Name: In the example it’s the Malware family Trojan.Malwerewolf.B (Good practice is to name this after the threat group / malware family)
  • Author: In the example the author is the analyst “InterDimSham” (If you are sharing intel you could put a company ID, or your InfoSec group name, or an analysts’ name)
  • GUID: This SHOULD be auto-generated by your IOC creator (you do not want a GUID collision)
  • Group: In the example the intel feed the info was derived from “Intel.Feed.A” (This will let you get attribution on what group intel is successful / not successful)
  • ThreatGroup: In the example our APT actor was named “APT-MWW” (This is a great way to get attribution to what APT actor is most prevalent, you could also put the malware family name in here)
  • Report: In the example the report is indicative of the ticket number 1. (This is where you want to attribute a specific ID for the IOC data so can you can tie back to your knowledge base for additional intel)
  • Category: In the example the category is a backdoor because this variant had those indications. (IOCe has some pre-defined categories for malware, but I think you can add your own here)
  • Grade: In the example this is being used as a threat level for triage/response.
  • Our Example Description contains a LONG PARAGRAPH style explaining the background of the IOC.Description:

In the example you cannot see the entire description, but it gives a great description of the purpose of the IOC (The purpose is to assist in associating the IOC with actual analysis).

A report from A Intel Feed described APT group APT-MWW using a trojan backdoor that is being identified as Trojan.Malwerewolf.B.
Since this is an APT actor using custom malware we have put a risk factor of 8.
The ticket tying all our internal details is in ticket #1.

The Malware is delivered from watering hole campaigns, and spear-phishing.
It installs itself an easily identifiable name of FILE[0-9].exe
It’s behavior consists of opening a backdoor and communicating back to its C2 with ASCII string of “MWW-C2”.
Appears to have a persistent C2 to remote domain with URI “/mww/c2?”
Persistence is generally kept by registry run keys.
No replication has been identified yet

[IOC Items & Logic]

The Bottom-Middle pane contains the nuts & bolts of the IOC (what is going to be used to scan your hosts). Here we see a relatively small MADE UP (Fake MD5s, fake domains, etc) malware scenario for TWO different files. Everything in the IOC is under a single OR because it this IOC is going to read like this:

  • MD5-1
  • OR
  • MD5-2
  • OR
    • Filename-1
    • OR
    • Filename-2
      • AND
    • Filepath contains “\Appdata\Local\Temp”
    • OR
    • Filepath contains “\Local Settings\Temp”
  • OR
    • RegistryPath contains “Software\Microsoft\Windows\CurrentVersion\Run”
    • AND
    • RegistryValue contains “FILE1.exe”
  • OR
    • RegistryPath contains “Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run”
    • AND
    • RegistryValue contains “FILE2.exe”
  • OR
    • Port Remote IP contains “”
  • OR
    • UrlHistory URL contains “remote.localhost.8080/mww/c2?”
  • OR
    • Network DNS contains remote.localhost

Since IOC scanner tools are relatively new there are a LOT of annoying scenarios that have been run across (which is why this layed out the way it is)

  1. Everything is under the parent OR (If you want something specific to an AND you’ll have to add it under that parent OR).
  2. You might have noticed that it is “organized” by type for each and
  3. This is due to the IOC scanning tool has to have it this way because of the way it collects data.
  4. It collects data for each IOC type (registry, filenames,MD5s, Network DNS, etc) from different areas so it uses the specific IOC types to scan those specific data collections.
    1. This means your logic cannot be as EXACT as you’d like it (like if this registry AND this IP, etc)
  5. You might also notice lack of wildcards or environment variables
    1. This was also due to the IOC scanning tool not having the capability of scanning with wildcards.
    2. There was a sort of workaround to use regex
  6. Nesting logic can be hard, but you should never have the same logic directly nested (no OR-OR, no AND-AND). This is especially true when having to group by IOC type.

[IOC Verification]

  • Be aware that your IOC scanner may be CASE-SENSITIVE
  • Be aware of typos, and whitespace in your IOC
  • You could probably write a script to go through and fix common mistakes in an IOC (or it could even go through an entire IOC store)

As previously mentioned, there are more tools than Mandiant’s IOCe:

  • A way of stream-lining (the IOCe tedious task) BULK imports of certain data types into an IOC. This will basically strip certain things (registry items, file paths, Hashes, network IOCs) and put them into the XML for you (with a mandiant-ready IOC name).
    TK_Lane also mentions a script that seems to do the cleaning of IOCs, but I was unable to find it on the web.
  • You could write one out yourself in a text editor (if you’re a bit crazy).


It’s generally best to use an IOC Generator so that the filename gets that GUID-looking unique filename.

Depending on the tool you’re using to scan your enterprise there might be a LOT of caveats as to what you put into your IOCs.

How you “organize” them, and other things.


Some of the IOC scanning tools can only scan with a couple hundred IOCs (because it will become very cumbersome by having too many IOCs).

This also might be true if your IOC has too many objects in it (which is why it is so important to have ORGANIZED, non-duplicative data).

Leave a Reply

Your email address will not be published. Required fields are marked *

Today is Monday