Seeking out the Attacker’s Methodology
Potentially, the most powerful way of creating an Indicator is to describe the attacker’s methodology.
Indicators attempting to detect methodology do not focus on a specific piece or pieces of forensic evidence directly tied to malware or compromise. Instead, they focus on the commonality of the methods that an attacker (or set of attackers) may use. Methodology indicators don’t necessarily show a specific instance of a compromise, but they will show the result of recurring tactics repeated by a certain group of adversaries. As such, they are the hardest to write, but when done properly, they capture evidence of a behavior that is only done by attackers or intruders as opposed to legitimate users or system use.
Looking for methodology allows you to:
- Look for specific locations in the file system, registry, or other parts of the operating system that hostile actors regularly use in the course of their intrusion, even if it has nothing to do with the initial exploit or compromise.
- Look for sets of artifacts left by tools or toolkits used by adversaries that would be expensive for them to change or modify.
- Look for signs of adversary activity on systems that were used for lateral movement, that were not directly compromised but show signs of activity that does not fit normal system user usage.
In real world cases, IOCs can combine any and all of the above types of functionality, or you can just use a single type of functionality by itself. The investigator tailors IOCs to the needs of their investigation, and the flexibility of OpenIOC allows them to change that as the case evolves, without having to write a new Indicator.
John Snow Labs Unique Indicators Creation
Unlike some other data standards used to describe threat information, there is no one-to-one mapping of an instantiation of a threat (such as a piece of malware) and the entry in the data standard used to describe it.
This flexibility of OpenIOC is a great strength, but also makes it possible for some IOCs to not be as useful as others. An IOC of “OR filename = *.exe” is definitely going to identify a lot of files – but this is a rather poor indicator, generating many false positives as it hits every executable file on a system. Better IOCs achieve the best true positive rate while having the lowest false positive rate (hitting on things which are normally found on a system or not related to an intrusion). Ultimately, the best IOCs have these properties:
- The IOC identifies only attacker activity.
- The IOC is inexpensive to evaluate – it is typically simple and evaluates information that is less expensive to collect or calculate.
- The IOC is expensive for the attacker to evade. In other words, to evade the IOC the attacker has to drastically change tactics, tools, or approach.
Using IOCs in the Investigative Lifecycle
IOCs are a part of an effective and proven workflow that is at the core of John Snow Lab’s own incident response process. The flexibility and machine-readable nature of the OpenIOC format are what makes this possible. The following outline shows some of the steps involved in the lifecycle of an investigation, and how OpenIOC and IOCs make that possible.
Initial Evidence – Evidence of a compromise is detected, either on a host or on the network. This may be in response to law enforcement (LE) notification or an anomaly noticed from a variety of sources. Regardless of what led to it, responders investigate and identify something which is a concrete forensic indicator of an intrusion.
Create IOCs for Host & Network – Following the initial discovery of forensic evidence, the investigators create an IOC from the existing data. The specific type of IOC created will vary based on the evidence, the environment, and the skill and comfort level of the investigator. The flexibility of OpenIOC allows a limitless number of permutations on how an Indicator can be crafted, so the investigator using OpenIOC has a lot of options as to how they want to proceed.
Deploy IOCs in the Enterprise – Once an IOC or set of IOCs have been created, the investigator will deploy these to technology that can look for the existence of the IOC(s) on other systems or other parts of the network. IOCs could be easily transformed and fed into IDS, IPS, HIDS/HIPS, SIEMS, or other investigative tools to look into the enterprise.
Identify Additional Suspect Systems – After deploying the IOCs into suitable technologies, additional systems will be identified, unless the first host was the only endpoint compromised.
Collect Evidence – Additional evidence is acquired from the additional systems that have been identified.
Analyze Evidence – The additional data collected is analyzed. This can identify further intrusion, false positives, or additional intelligence for the investigators. This feedback then allows for the investigator to refine their searches and to return to the start of the workflow.
Refine & Create New IOCs – The investigative team can create new IOCs based of their findings in the enterprise and additional intelligence, and continue to refine their cycle until they feel they either have exhausted the need to find new information, or other factors force them to stop investigating and move to remediation.
The threat landscape that confronts both the government and commercial sector is more challenging than it has ever been. While defenders must succeed 100% of the time, the attackers only need to get through once to be successful. In almost all environments, some type of compromise is inevitable. Rapid dissemination of pertinent information among defenders is one of the few effective ways to combat target attacks by sophisticated threat actors, and a necessary component of a successful incident response & containment workflow. Indicators of Compromise, written in OpenIOC, allow organizations to define pieces of threat intelligence in a standardized, logically organized manner, encode the experience and knowledge of human subject matter experts in a machine-readable format, and use the speed of responding in machine time to communicate that intelligence across their enterprise or to other entities they wish to share intelligence with. With OpenIOC, your organization can harness the power of the many years of incident response experience that went into creating and refining OpenIOC, and empower your personnel to respond to incursions with the speed and intelligence they need to change the current imbalance of power that so greatly favors the attackers.