The best way to understand how threat intelligence impacts your incident response/management process is to actually run through an incident scenario with commentary to illustrate the concepts. For simplicity’s sake we assume you are familiar with our recommended model for an incident response organization and the responsibilities of the tier 1, 2, and 3 response levels. You can get a refresher back in our Incident Response Fundamentals series.
For brevity we will use an extremely simple high-level example of how the three response tiers typically evaluate, escalate, and manage incidents. If you are dealing with an advanced adversary things will be neither simple nor high-level. But this provides an overview of how things come together.
Intellectual property theft is a common mission for advanced attacker, so that will be our scenario. As we described in our Threat Intelligence in Security Monitoring paper, you can configure your monitoring system to look for suspicious IP ranges from your adversary analysis. But let’s not put the cart before the horse. Knowing you have valuable IP (intellectual property), you can infer that a well-funded adversary (perhaps a nation-state or a competitor) has a great interest in that information.
So you configure your monitoring process to look for connections to networks where those adversaries commonly hang out. You get this information from a threat intelligence service and integrate it automatically into your monitoring environment, so you are consistently looking for network traffic that indicates a bad scene.
Let’s say your network monitoring tool fires an alert for an outbound request on a high port to an IP range identified as suspicious via threat intelligence. The analyst needs to validate the origin of the packet so he looks and sees the source IP is in Engineering.
The tier 1 analyst passes this information along to a tier 2 responder. Important intellectual property may be involved and he suspects malicious activity, so he also phones the on-call handler to confirm the potential seriousness of the incident and provides a heads-up. Tier 2 takes over and the tier 1 analyst returns to other duties.
The outbound connection is the first indication that something may be funky. An outbound request very well might indicate an exfiltration attempt. Of course it might not but you need to assume the worst until proven otherwise. Tracing it back to a network that has access to sensitive data means it is definitely something to investigate more closely. The key skill at tier 1 is knowing when to get help. Confirming the alert and pinpointing the device provide the basis for the hand-off to tier 2.
Now the tier 2 analyst is running point on the investigation. Here is the sequence of steps this individual will take:
- The tier 2 analyst opens an investigation using the formal case process because intellectual property is involved and the agreed-upon response management process requires proper chain of custody when IP is involved.
- Next the analyst begins a full analysis of network communications from the system in question. The system is no longer actively leaking data, but she blocks all traffic to the suspicious external IP address on the perimeter firewall by submitting a high-priority firewall management request. After that change is made she verifies that traffic is in fact blocked. The analyst does run the risk of alerting the adversary, but stopping a potential IP leak is more important than possibly tipping off an adversary.
- She starts to capture traffic to/from the targeted device, just so a record of activity is maintained. The good news is all the devices within engineering already run endpoint forensics on their devices, so there will be a detailed record of device activity. The analyst then sets an alert for any other network traffic to the address range in question to identify other potentially compromised devices within the organization.
- At this point it is time to call or visit the user to see whether this was legitimate (though possibly misguided) activity. The user denies knowing anything about the attack or the networks in question. Through that discussion she also learns that specific user doesn’t have legitimate access to sensitive intellectual property, even though they work in engineering. Normally this would be good news but it might indicate privilege escalation or that the device is a staging area before exfiltration – both bad signs.
- The Endpoint Protection Platform (EPP) logs for that system don’t indicate any known malware on the device and this analyst doesn’t have access to endpoint forensics, so she cannot dig deeper into the device. She has tapped out her ability to investigate so she notifies her tier 3 manager of the incident.
- While processing the hand-off she figures she might as well check out the network traffic she started capturing at the first attack indication. The analyst notices outbound requests to a similar destination from one other system on the same subnet, so she informs incident response leadership that they may be investigating a serious compromise.
- By mining some logs in the SIEM she finds that the system in question logged into to a sensitive file server it doesn’t normally access, and transferred/copied entire directories. It will be a long night.
As we have mentioned, tier 2 tends to focus on network forensics and fairly straightforward log analysis because they are usually the quickest ways to pinpoint attack proliferation and gauge severity. The first step is to contain the issue, which entails blocking traffic to the external IP to temporarily eliminate any data leakage. Remember you might not actually know the extent of the compromise but that shouldn’t stop you from taking decisive action to contain the damage as quickly as possible – per the guidance laid down when you built designed the incident management process.
Tier 3 is notified at this point – not necessarily to take action, but so they are aware there might be a more serious issue. Proactive communication streamlines escalation.
Next the tier 2 analyst needs to assess the extent of the damage, understanding they cannot have the full picture without the expertise and sophisticated investigation tools used at tier 3. So she searches through the logs and finds a similar set of indicators on another device, which is not good. More than one compromised device might means a major breach. Worse yet she sees that at least one involved system connected to a sensitive file store and grabbed a large chunk of content. Time to hit the big red button, escalate, and fully engage tier 3.
- Tier 3 steps in and begins in-depth analysis of involved endpoints and network activity, leveraging work done by the tier 2 analyst. Given the potential set of adversaries, based on the destination of outbound connections and adversary analysis, the first step for tier 3 is to focus on the most recent and frequent attack tactics used by those adversaries. Their threat intelligence service identifies 5 common tactics and provides indicators and C&C patterns to look for.
- The search of endpoint forensics data identifies the malware that initially infected a user system, showing a few of the indicators identified by threat intelligence. The malware was delivered via drive-by download after clicking a phishing link. Now that they know the primary files and behavioral indicators (at least for the initial attack), a quick search shows that the malware file was delivered to eight devices on the network. But only four devices actually executed it, became compromised, and showed the indicators. Out of those four only one additional device has communicated externally (identified by the tier 2 analyst), which is why network forensics didn’t catch the others.
- At this point it is clear that law enforcement will be involved. So forensic images of all impacted devices are taken and stored securely (within the case management system). This probably could have been done earlier, but the original focus was on finding the extent of the infiltration.
- A deeper dive into the compromised device shows what appears to be a rather large encrypted
.rarfile. This could be the exfiltration package. So the analyst searches network forensics for that particular file or other movement of a file that size, but analysis shows no evidence the file was transferred out through the perimeter. It appears the organization dodged a bullet and detected the command and control traffic before exfiltration took place.
- The tier 3 analyst now has enough information to fill out the attack timeline. They know where the attack started, the malware used, the lateral movement to compromise other devices, the path to sensitive data, and even the packaging of the exfiltration package. Now they can talk to senior management about how to move forward.
- There is no proof of data loss, so senior management decides to learn what they can about the adversary. Encrypted command and control traffic over a non-standard port is allowed to continue, but all unusual outbound file transfers from the compromised device are blocked. Yes, they run the risk of blocking something legitimate, but senior management has decided this is a worthwhile risk. To make sure nothing is missed additional network forensic gear is deployed to capture all traffic from the affected segments.
- A key driver of the decision to allow C&C traffic is to not tip off attackers that they have been discovered. Prior experience warns that prematurely cutting off communications only prompts adversaries to burrow in deeper, making them harder to eradicate.
- Sensitive data is slowly removed from devices on that subnet. Forensics investigators turn the infected system image over to their threat intelligence provider for a much deeper malware analysis. The goal is to prepare a coordinated plan to clean up and expel the attacker, but to do this they need to fully understand the depth of compromise and identify all involved systems and malware variants.
At the same time outbound transfers are stopped, the response team acts decisively to remove sensitive data from the reach of attackers. This again serves to contain the damage until the threat can be neutralized. Threat intelligence providers are usually happy to assist in investigation. They learn about new tactics and can perform more sophisticated analysis than just detonating a malware file. You can leverage providers who focus on phishing packages (the initial attack vector), C&C traffic patterns, and custom malware to get a full view of exactly what the attack did and how it worked.
And you will need that information, because now you have to mitigate and clean up.
Actual sophisticated attacks are rarely this cut and dried, but response team tactics need to be consistent. The objective is always to contain damage while figuring out the extent of the compromise. Then you have options for how to remediate.
Mitigation and Cleanup
- The investigation didn’t show any exfiltration of sensitive data and you have moved that data out of harm’s way, so now it’s time to clean up the mess. The team decides to do a big bang clean up, given there are only a handful of affected devices and you want to expel the adversary quickly and completely.
- First thing on Saturday morning the compromised devices are taken offline, and the employee’s data transferred to a new machine. The old devices are totally reimaged and the base configuration and software reinstalled. Those devices will remain monitored in the lab for a week, just to make sure there aren’t any further issues.
- You also know the C&C targets and traffic dynamics of this adversary, so you implement a set of egress filtering rules on your firewalls and new attack rules on your IPS to block that activity. You also set up rules in your network forensics tool to detect any signs of adversary activity in case more active controls miss it.
- You cannot afford to assume you found all the compromised devices, so you run a credentialed remote scan on every device in your environment, working with Operations and their configuration management product. The endpoint forensics tool showed you where the file went within your environment, but you want to be sure and confirm that finding.
- At this point the incident management team believes the attack has been mitigated. So cleanup begins to restore operations. The network forensic gear is redeployed but the egress filtering rules will remain. The SIEM is now monitoring for the traces of the attack and outbound file transfers are loosened. But you keep watching for indications the attacker has returned. Ongoing diligence is key.
The mitigation is pretty straightforward. Based on the attack timeline you know which devices were impacted and clean those up. You know the network traffic dynamics so you can watch for suspicious traffic. And it was a manageable number of devices so you could get it all done quickly, before the attacker had time to burrow deeper. That’s the goal, anyway.
You keep a close eye on the network to make sure the attackers don’t return. Yes, this is a reactive step, and sophisticated adversaries may use a different kind of attack to reestablish presence in your environment. But you can only make sure you don’t get hit by the same attack so that’s your focus.
Finally, once you are pretty confident the attacker is gone, you can start loosening up some of the controls implemented as part of your response. You want to keep some mitigations but at some point business returns to normal, whatever that means for your organization. Until next time…
- The CISO needs to present to the board in a week about the impact of and lessons from the breach. So a postmortem meeting is arranged, involving the response team, operations, the external forensics team (brought in to confirm the cleanup), and the threat intelligence provider.
- There were small issues to facilitate the handoff and exchange of information between responders. The threat intelligence provider has started building a team to focus on assisting customers in the midst of response. And the incident management process was updated to take a forensic snapshot of the device before the responder starts investigating.
- There was apparently no exfiltration, so the board will be pretty happy with the response. But these changes will improve things for next time.
The key points in this scenario are rapid identification of a serious issue (outbound IP exfiltration), quick escalation to tier 2 for scoping and initial investigation, leveraged threat intelligence to narrow the scope of searches, and rapidly coordinated investigation and response with high-level resources (both internal and external) once it became clear this was a sophisticated and advanced attack. The initial handler did a good job of recognizing the problem and understanding he couldn’t handle it himself. The second level responder didn’t fall into the trap of focusing too much on the first device and missing the bigger picture. The containment plan provided breathing space for a full cleansing without tipping off the attackers to rush a deeper penetration, or allowing additional loss of important assets.
This scenario shows a well-coordinated response to a pretty simple attack. The real world doesn’t exactly work like this but the fundamentals are the same. Coordinate response, communicate effectively, and learn what you can before you take action to mitigate/remediate. Then monitor the environment to make sure you got everything.
Then move on to the next one – there is always a next one.
With that we wrap up our Leveraging Threat Intelligence in Incident Response series. Benefiting from the misfortune of others by utilizing intelligence about attacks and adversaries can streamline response management. We will assemble these posts into a paper over the next couple weeks, so keep an eye out.
We would once again like to thank Cisco, Malcovery Security, and FireEye for potentially licensing this resulting paper. Without their support we wouldn’t be able to maintain this business model or provide our research without cost.