Applying Detection to the Attacker Lifecycle
Thanks everyone for the encouraging comments on my first post and for taking the time to let me know it helped you out! 😁 Now for the next edition.
Hunting is a form of detection. It's not monitoring, but it is detection. So let's take a quick look at creating a detection strategy and how it can include your hunt program.
Your detection strategy needs to create a story that your senior leadership can easily understand. The Mandiant Attacker Lifecycle always made more sense to me than the Lockheed Martin Cyber Kill Chain, so I am going to use that as the story for my strategy. Pick whichever lifecycle works for you. There is also the MITRE Attack Lifecycle.
For the sake of this post , I am going to say the lifecycle stage, Complete Mission, should be handled by DLP, backups (if mission objective is destructive), and encryption.
You want to alert early in the lifecycle so you catch attackers sooner rather than later. Luckily, this generally aligns with the capabilities of tools available to organizations. In some instances, you will want tool-driven detection and in others you will want the tool to provide you with the ability to apply intelligence-driven detection.
Let's look at some scenarios:
Exploits: You want to detect and alert on exploits as quickly as possible. For this reason, I recommend tool-driven detection. The appliance, the sensor, or agent can detect the attempt to exploit a system without needing a signature containing attacker intelligence. It relies on the maker of the tech to teach the tool ways a system shouldn't behave and alert when it sees that behavior.
Webshells: A common method for establishing a foothold, webshells are detectable using intelligence-driven detection. Ensure you have a tool with the flexibility for you to do content regex of files and create a host-based signature using the common strings found in webshells. This may start out as a Tier 3 analyst alert, but over time you will be able to tune the false positive rate so beginner analyst can validate a webshell alert. If you have access to decrypted traffic, pair this with network alerting based on webshell communications for extra coverage.
To make sure your hunt program provides the most value possible, know your organization's alerting capabilities and stay up to date with your Indicator Management team for what intelligence is being applied for detection.
In cases where you can use intelligence-driven detection, you can rely on a tool or you can hunt. I recommend hunting when alerting becomes infeasible due to the false positive rate or the need to combine numerous data sources.
Hunting will be most valuable when you are trying to detect patterns of behaviors and not attacker tools. These behaviors are most commonly demonstrated in the later stages of the lifecycle, when the attacker may just be living off the land. These stages make for good objectives of Continuous Hunts.
However, depending on the detection maturity of your organization you may need to hunt where others alert.
So let's go back to the webshell example above.
You already know you don't have access to decrypted traffic --because you have been complaining about that for months-- so its unreliable to detect webshells solely over the wire. You dig into your alerting capabilities and realize that your EDR tool doesn't support content regex of files, so your intelligence-driven detection is limited to MD5s and filenames. You may choose to hunt for webshells on hosts as part of your overall detection strategy, while you make the case for getting a tool that can offer better alerting instead.
To add that extra bit, take the time to do a more detailed mapping that aligns the attacker lifecycle with known attacker TTP's, try something like MITRE ATT&CK. This might be a bit painful, but its worth it. @Cyb3rWard0g recently made this a little less painful -https://cyberwardog.blogspot.com/2017/07/how-hot-is-your-hunt-team.html
For each technique in a tactical group, determine if your organization can alert or needs to hunt.
Example: Lateral Movement: Pass The Hash
Can you detect pass the hash in your environment? Perhaps you feel comfortable with the alerting from your Microsoft ATA in one domain, but another domain that still exists from a previous merger has no alerting. You may want to hunt for pass the hash in just the second domain due to the lack of alerting or you may not trust ATA, just yet, and want to hunt for pass the hash everywhere to be safe.
Now step back and decide your ideal state. As your programs become more mature, do you believe you should be alerting or hunting for that technique. Use intelligence about your industry's threat landscape to help you weigh risk. This step should enable you to start to develop a roadmap.
I know none of this is groundbreaking. I share it because it can be easy to want to hunt for the most advanced attacker techniques and assume the well-known techniques are covered by SOC alerting. Build a cohesive detection strategy to make sure that where and how you hunt provides the most needed detection for your organization.
O yea, don't underestimate the power of having a story for your detection strategy. It will aid you in discussing the maturity of your SOC and your Hunt Program and I've found it makes it easier for non-cybersecurity professionals to understand what you provide the org.
Happy Hunting,
~K
Hunting is a form of detection. It's not monitoring, but it is detection. So let's take a quick look at creating a detection strategy and how it can include your hunt program.
Use a Lifecycle for your Story
Your detection strategy needs to create a story that your senior leadership can easily understand. The Mandiant Attacker Lifecycle always made more sense to me than the Lockheed Martin Cyber Kill Chain, so I am going to use that as the story for my strategy. Pick whichever lifecycle works for you. There is also the MITRE Attack Lifecycle.
 |
| Mandiant Attacker Lifecycle |
For the sake of this post , I am going to say the lifecycle stage, Complete Mission, should be handled by DLP, backups (if mission objective is destructive), and encryption.
Alerting
You want to alert early in the lifecycle so you catch attackers sooner rather than later. Luckily, this generally aligns with the capabilities of tools available to organizations. In some instances, you will want tool-driven detection and in others you will want the tool to provide you with the ability to apply intelligence-driven detection.
Let's look at some scenarios:
Exploits: You want to detect and alert on exploits as quickly as possible. For this reason, I recommend tool-driven detection. The appliance, the sensor, or agent can detect the attempt to exploit a system without needing a signature containing attacker intelligence. It relies on the maker of the tech to teach the tool ways a system shouldn't behave and alert when it sees that behavior.
Webshells: A common method for establishing a foothold, webshells are detectable using intelligence-driven detection. Ensure you have a tool with the flexibility for you to do content regex of files and create a host-based signature using the common strings found in webshells. This may start out as a Tier 3 analyst alert, but over time you will be able to tune the false positive rate so beginner analyst can validate a webshell alert. If you have access to decrypted traffic, pair this with network alerting based on webshell communications for extra coverage.
To make sure your hunt program provides the most value possible, know your organization's alerting capabilities and stay up to date with your Indicator Management team for what intelligence is being applied for detection.
Hunting
In cases where you can use intelligence-driven detection, you can rely on a tool or you can hunt. I recommend hunting when alerting becomes infeasible due to the false positive rate or the need to combine numerous data sources.Hunting will be most valuable when you are trying to detect patterns of behaviors and not attacker tools. These behaviors are most commonly demonstrated in the later stages of the lifecycle, when the attacker may just be living off the land. These stages make for good objectives of Continuous Hunts.
However, depending on the detection maturity of your organization you may need to hunt where others alert.
So let's go back to the webshell example above.
You already know you don't have access to decrypted traffic --because you have been complaining about that for months-- so its unreliable to detect webshells solely over the wire. You dig into your alerting capabilities and realize that your EDR tool doesn't support content regex of files, so your intelligence-driven detection is limited to MD5s and filenames. You may choose to hunt for webshells on hosts as part of your overall detection strategy, while you make the case for getting a tool that can offer better alerting instead.
Make the Story Actionable
The story you create around the attacker lifecycle should give a good story for leadership to follow. It may even drive the budget for future tooling. Unfortunately, the story isn't immediately actionable for those who need to carry out the detection strategy.To add that extra bit, take the time to do a more detailed mapping that aligns the attacker lifecycle with known attacker TTP's, try something like MITRE ATT&CK. This might be a bit painful, but its worth it. @Cyb3rWard0g recently made this a little less painful -https://cyberwardog.blogspot.com/2017/07/how-hot-is-your-hunt-team.html
 |
| MITRE ATT&CK |
Example: Lateral Movement: Pass The Hash
Can you detect pass the hash in your environment? Perhaps you feel comfortable with the alerting from your Microsoft ATA in one domain, but another domain that still exists from a previous merger has no alerting. You may want to hunt for pass the hash in just the second domain due to the lack of alerting or you may not trust ATA, just yet, and want to hunt for pass the hash everywhere to be safe.
Now step back and decide your ideal state. As your programs become more mature, do you believe you should be alerting or hunting for that technique. Use intelligence about your industry's threat landscape to help you weigh risk. This step should enable you to start to develop a roadmap.
I know none of this is groundbreaking. I share it because it can be easy to want to hunt for the most advanced attacker techniques and assume the well-known techniques are covered by SOC alerting. Build a cohesive detection strategy to make sure that where and how you hunt provides the most needed detection for your organization.
O yea, don't underestimate the power of having a story for your detection strategy. It will aid you in discussing the maturity of your SOC and your Hunt Program and I've found it makes it easier for non-cybersecurity professionals to understand what you provide the org.
Happy Hunting,
~K
Comments
Post a Comment