The release of the APT1 report from Mandiant has been one of the major recent event in the security world. I’m not going to review the report or to comment on it, even though the work that Mandiant did is really impressive and clearly demonstrate that governemental attacks are real. As I said in a previous post, cyber-espionage is on an increase trend and what Mandiant release is just the tip of the iceberg.
But what is really interesting in this report is the…appendix! Mandiant did include an awful lot of details such as FQDN, SSL Certificates and…Indicators of Compromise (e.g. IOC)! Let’s have a closer look at those IOCs.
Indicator of Compromise
Indicators of Compromise are forensic artifacts of an intrusion that can be identified on a host or network.
The current threat landscape is made of highly complex viruses and/or stealth intrusions, very difficult to prevent, identify, detect, etc. Also the IT environment is vast, heterogeneous, not always managed, making it even more difficult to ensure that a breach is contained quickly and in effective manner. So what do we need? An easy and standard way to describe a breach or the describe a malware and its behaviors. Also we need the ability to share this description You guess it, Indicators of Compromise are the solution!
OpenIOC is an open source standard developed by Mandiant to codify intelligence in order to rapidly search for a potential security breaches. What Mandiant did is to define a language (OpenIOC) used to provide descriptive terms (named “Indicator Term”) about a specific threat. Put everything together and you get an Indicator of Compromise!
Speaking of standard, OpenIOC fully rely on XML. The benefits are numerous: well known language, easily extensible, parsing or conversion of XML can be easily done, etc.
So how does that work?
An IOC consist of the following:
- Find unique artifacts related to your threat, such as signature (e.g. MD5), filename, path, etc.
- Find more complex artifact related to your threat, such as memory artifact, process name, import, etc.
- Put all this together, in a logical group.
Sounds easy? Well could be but let’s be honest, if you are planning to build IOC just based on a MD5 hash and a filename this might not be the most efficient IOC in the world! IOC can be designed to exclude known good file from an investigation or combined together to increase the probability to identify a malware.
For the record, or for those of you who doubt that you can go to a certain level of complexity, the OpenIOC has defined more than 500 “Indicator Terms”…that can be combined with boolean operators (AND, OR, etc.).
A few good tips…from Mandiant
As with everything you can use this standard is a good way or in…less effective way. Keep in mind the following to build good IOC:
- Make your IOC identify only attacker activities.
- Make your IOC simple! The goal is to a “low cost” evaluation, if the evaluation criteria you are using required high calculation power or are difficult to collect…you won’t get the value out of an IOC.
- Understand your threat! Really understand your threat! and if you think you have already done that…check again. A good IOC will be difficult to evade and as such the bad guy might need to re-think completly his/her virus to avoid detection.
…provided by Mandiant 😉 of course as Mandiant is the “parent” of the OpenIOC they had to come up with some tools. As Mandiant is know for providing some very good free tools (go checkout Redline if you have not done so before) there you go:
Both are free and running on Windows, all requirements are describe on the webpage [Note: anybody to create an IOC editor for Mac OS X?]. Mandiant is still making money, their paying products include support for IOC and can be use to scan your environment to detect infected workstations/servers.
All this sounds good…very good…but lack of empirical experience…stay stuned for more and in the next parts we will go through building IOC for a specifc threats and use the tools to detect a threat.