IOC: Indicators and Artifacts

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

:IOC: Indicators and Artifacts:

When building an IOC, or indicator of compromise, there are a few questions you should ask yourself.

  • What exactly am I looking for?
  • How specific do I have to be?
  • How will this help me for the future?

Now if you have been a frequent visitor of MalWerewolf, you may have already read the great post by InterDimSham about what exactly are IOCs. If you haven’t, please check it out as it’s a good read http://malwerewolf.com/2014/12/iocs-create-manage-understand-manifesto/. The following information may still be useful without it; however, you should at least have some foundational knowledge on how IOCs are used.

The one concept to rule them all; an IOC is as useful as the creator wants it to be. All of the questions we asked ourselves earlier should be fairly present in our minds when going through the development process. Building a proper IOC requires a decent foundation across all of the security disciplines so don’t be afraid to reach out to friends or colleagues. But what do we put in an IOC? Hashes, paths and domains, oh my! Should that be it? This is where we need to get into exactly WHAT IS an indicator. The security field loves to use terms like artifacts and indicators so I thought it would be great to just go over some examples of both and then give an overall idea as to what we believe is the best route of tackling the IOC development cycle.


So your honeypot got some badness on it and you want to build an IOC that you can use to scan across your infrastructure. Well let’s take a look at the artifacts. An artifact will be something present. This should be something that you can interact with. A lnk file, a folder or even the files themselves, these are all potential artifacts that you may encounter when in an investigation or incident. Let’s begin staging an IOC with the information we currently have.

IOC Prep


We have four files identified in this incident and we have some basic information such as compile times, file names, file sizes and hashes. But wait! What is the path in our IOC? Is an existence of a path an artifact or an indicator? I believe it’s both. The best way I can work through the indicator vs artifact conundrum is by comparing it to firing a gun. What would the gun residue be that is left on someone’s hand? Well, it’s an artifact as it is tangible and exists, but the fact that it exists is an indicator that a gun was used. You could use the residue to match the gun (one) or you could use the residue to make the assumption that A gun was used (many). So when we are building an IOC, the folder may be the artifact but I would use the path’s existence instead as an indicator.


An indicator is something that suggests an event happened. This is going to be a broader, catch-all type of object in the IOC. Instead of looking at the folder and file drop location of C:\Temp\Malwerewolf\ how about we look for the indicator in which a folder path is named \Malwerewolf\ somewhere on the file system. What if we noticed that the svchost.exe that was part of this malware executed in a temp directory? Below is a filled out IOC including all the indicators and artifacts.

Staged IOC


IOC Analysis

The original IOC was bare and, although it contained a decent amount of indicators, it was extremely weak and could hit on just about anything. Any files based on specific sizes, files named svchost.exe and fairly generic compile times can cause a spike in false positives. What’s the use of an indicator if it is causing so much noise that your colleagues become buried in analysis. This should be in the back of the minds of all content-developers who are responsible for creating the IOCs, snort signatures or alerts in their security environments.

Our second IOC instead has marriage of indicators and artifacts. We have used the hashes as artifacts and kept them by themselves. These are great but provide a very specific function to the IOC. These will tell you whether or not you have the badness on your host. We have then used the artifact’s names and combined them with indicators to create a broader range of possibilities. If variants are used of the same badness, hashes will be different. However, although hashes may be different, we may still observe the same behaviors. Dropping a file in the \Temp\ directory with the filename of svchost.exe suggests that an alert may need to be triggered. This moves into the next piece of logic which checks against the file size or compile time. This may not be required as an exe being dropped with  a file path of \Temp\ could be enough for the alert. Maybe there’s a file that was dropped which had a compile time at the same time as the other variant. We added the artifact’s name of maliciousness.exe and looked for whether it matched a compile time or the size of the file. Last but not least would be the registry. I have left out the indicators of the registry to allow you to explore what you might add to this. Value? Text? Would you add more logic to this object in the IOC?

To quote The Phantom Tollbooth, “What’s the most important – Words or Numbers?”. In security, we might ask, “Artifacts or Indicators?”. Though the question has been altered, the answer is still the same. Artifacts and Indicators are of equal value. They each provide strengths and weaknesses in their own right. It is up to us to determine what we want out of the IOC in front of us and remember with great power… I refuse to finish that.

Leave a Reply

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

Today is Monday