Wikipedia defines an Indicator of Compromise (IOC) as "an artifact observed on a network or in an operating system that with high confidence indicates a computer intrusion." Associated contextual information is also usually included along with the artifact and helps an organization to properly leverage the IOC. Context most often includes, among other things, information regarding to which attack stage an indicator is relevant. Attack stages can be broken up into three main families, each of which contains one or more attack stages:
- Pre-infection: reconnaissance, exploit, re-direct
- Infection: payload delivery
- Post-infection: command and control, update, drop, staging, exfiltration
At some point, when an organization wants to watch for and alert on a given attack, intrusion, or activity of concern, that organization will need to select one or more IOCs for this purpose. Going for the "money shot" involves selecting the highest fidelity, most reliable, least false-positive prone IOC or IOCs for a given attack, intrusion, or activity of concern. For example, if we look at a typical web-based re-direct attack, it may involve the following stages:
Some people may argue that detecting an attack after it has already happened is too late. To those people, I would argue that, in my experience, attempting to detect attacks as they happen most often leads to a deluge of false positives. This deluge almost always buries the team and prevents real attacks from being detected. If there are reliable ways to detect attacks as they happen, they should be used to block those attacks. However, it's important to remind ourselves that attacks will ultimately still get through those defenses. In those instances, the money shot has proven to be the best approach.
For each attack, there may be thousands or millions of noisy pre-infection IOCs. Conversely, there are usually a very small number of low noise post-infection IOCs. Whenever possible, go for the "money shot" to help reduce false positives and improve the signal-to-noise ratio.
- Compromise of a legitimate third party site to re-direct to a malicious exploit site
- Exploitation of the system from the malicious exploit site
- Delivery of the malicious code
- Command and control, along with other post-infection activity
- Compromised legitimate third party sites likely number in the millions, meaning we would need millions of IOCs to identify just this one attack at this stage. Further, there is no guarantee that the attempted re-direct would succeed (e.g., if it were blocked by the proxy). An unsuccessful re-direct means that there was no attempt to exploit. In other words, for our purposes, a false positive.
- Exploits don't always succeed, and as such, alerting on attempted exploits can often generate thousands upon thousands of false positives.
- If we see a malicious payload being delivered, that is certainly of concern. But what if the malicious payload does not successfully transfer, install, execute, and/or persist? We have little insight into whether a system is infected, unless of course, we see command and control or other post-infection activity.
Some people may argue that detecting an attack after it has already happened is too late. To those people, I would argue that, in my experience, attempting to detect attacks as they happen most often leads to a deluge of false positives. This deluge almost always buries the team and prevents real attacks from being detected. If there are reliable ways to detect attacks as they happen, they should be used to block those attacks. However, it's important to remind ourselves that attacks will ultimately still get through those defenses. In those instances, the money shot has proven to be the best approach.
For each attack, there may be thousands or millions of noisy pre-infection IOCs. Conversely, there are usually a very small number of low noise post-infection IOCs. Whenever possible, go for the "money shot" to help reduce false positives and improve the signal-to-noise ratio.
No comments:
Post a Comment