Wednesday, September 28, 2016

IR Do's and Don'ts

There is a lot of documentation around the different phases of the IR cycle. We talk a lot about preparation, identification, containment, eradication, recovery and lessons learned. Lets face it, dealing with intrusions can be very fast paced with a lot of activity all usually happening at the same time. You can often be in more than one of the above phases and likely will need to repeat a few as well. If you don’t respond to intrusions all that often or maybe you never have, it’s easy to to get lost in all the activity and miss some very important steps. Here are some of the things that may be good to think about as well as some of the pitfalls to avoid.
Find the entry point
I put this at the top because I think this should be one of your top priorities. You may not always be alerted to an intrusion as a result of a beaconing endpoint or the intruder may not even be using a backdoor for gaining access to your network. The intruder may very well be entering your network by taking advantage of legitimate means. Following the trail that is left behind until you eventually locate that entry point, or as is often the case entry points, is critical. You should never consider the incident contained until the intruder’s access is cut off.
Find the exit point
This ranks up there with locating the entry point and killing access. If the intruder was able to locate and access the data they were after they are probably funneling it out of your network. Some things to ask your self may be:
1. Are there large data transfers identified from any of the identified compromised machines.
2. Do you have pcap to identify what those transfers consisted of?
3. Do you see archiving activity or sequential rapid file access during the time the intruder was on the machine?
The above are some of the things that you may want to look for. If you have an indication that data was collected for exfil you may want to look at:
1. What did the login activity look like around that time?
2. Are there any tools found on the device that could be used to push data?
3. What ip’s may be suspect based on access time or volume of data transfer?
Identify lateral movement and how it’s being performed
Regardless of where in the killchain an intrusion is identified always assume that lateral movement is happening until you can prove otherwise. If we take a step back and simply look at it from a non tool perspective there are certain things that need to occur for them to do this successfully.
1. They need to know where to go.
2. They need a way to get there.
3. Once there they need a way to get in.
If we think about the above tasks we know they need to perform, can you identify:
1. Any scanning activity or network enumeration.
2. Any network connections that are either the source or destination of your known compromised machines from the point you know they were compromised. If so, do the identified connections match any indicators of the current intrusion or do they seem out of the norm for what these machines usually do? Are there large amounts of data being transferred either to other internal machines or outside of your network? If you collect pcap, what does the pcap indicate?
3. Once an adversary has a foothold into your environment you generally won’t see exploitation of internal machines as a method to gain access to it. How are they gaining access? Are legitimate credentials being used and if so what level of access do they have within your domain? Are you seeing these credentials being used elsewhere in your environment? How were they able to get these credentials?
Follow the indicators
I’ve watched new analysts (and remember when I was there myself) struggle with not only knowing where to begin, but what to do next. When you identify a new indicator what does it tell you? A few examples would be:
1. Password dumper – What hashes were dumped and do we see any of those credentials currently being used?
2. net.exe – Was this a result of enumeration or lateral movement?
3. ping.exe – What hosts were being pinged? Were they successful and do those hosts show signs of compromise?
Once new indicators are identified can you identify any other hosts on your network with those same indicators?
Delegate tasks
If you are running the incident know that you can’t do it alone. Whether it’s analyzing host artifacts, looking at network traffic, building new detection, or simply working on a communication to send to leadership. Distributing the workload across your team is important, but it does take some confidence in knowing that each team member can effectively handle the task they were given.
Know when, what and how to contain
Containment is largely a business decision, but some things to keep in mind regarding containment are.
1. What is the scale of the incident? If you contain something will you lose sight of the activity before it is scoped to the point that you can contain the intruder access.
2. What needs to be contained? This can be things such as machines, user accounts, external access…
3. From a business decision, who has the authority to grant containment?
4. What is the impact of containment based on the severity of the incident?
5. Does my containment method allow for additional artifacts to be collected from the device if needed?
6. Does my containment method destroy any evidence that may be crucial to the investigation?
Have a method for host collection
I’ve said before that during an incident is probably not the best time to be pulling disk images for analysis. The amount of time it takes to collect and transfer these does not enable the speed that we should be moving at. It’s a good idea to have a standard set of artifacts that are collected during response so analysts know what they are getting as well as the people that are collecting the data know what to collect. Once you have a standard it can also be scripted and quickly pushed out to suspect hosts.
Build detection throughout the incident
Continuously building detection as new indicators are found is extremely important during an incident. As the intruder moves from machine to machine they may utilize different methods of movement, tools, user accounts and so on. As these indicators are identified try to implement them in some type of alerting mechanism as well as performing a historical search.
I’ve talked about this many times. Hopefully when you’re responding to an incident you are not the only person involved. Your documentation should be a team effort as well as being collaborative. It’s important to have a place that the entire team can document their analysis, update documentation with additional findings as well as a place where anyone with access can get a current status and a full picture of what has been determined at that point in time.
Leadership: Keeping leadership informed on what is currently happening is important. They likely have to communicate your findings to others who are not directly involved in the incident, but may be key stakeholders in decisions that are made. Not keeping them informed so that they can make those business decisions can be a mistake.
Response team: Communicate what you are doing as well as what you are finding to the rest of the team. If it’s what you are finding it’s probably best to communicate that in your documentation so that others can easily find it and incorporate it into their analysis. Not every compromised host will look the same and having a place for everyone on the team to get updated information is very important.
Wrapping things up
Knowing what needs to be remediated is critical and it’s a good idea to keep a running list so that you don’t lose sight of something that can allow the intruder access back into your network or easy access internally the next time they are in. Some things to keep in mind when you are keeping that running list:
1. Compromised machines
2. User accounts
2. Policies (firewall, proxy, WAF…)
4. Applications that may have been exploited
Don’t forget to watch for new or unrelated activity
Just because your are currently responding to an incident doesn’t mean that you can’t experience another compromise at the same time. If you don’t have analysts that are dedicated to analyzing alerts during response you may be missing the next intrusion.
Dont panic
This is probably one of the worst things that you can do. Remember that you will get through this much quicker if sound decisions are made and this likely won’t happen if your response is based on knee jerk reactions. Keep focus on the most critical tasks at hand and ask yourself if the decisions you are making are sound. Even though the decisions may fall on you, allow input from others because the may have ideas or viewpoints that you have not thought about.
Don’t communicate assumptions
I think some assumptions are ok and may help guide your analysis, but communicating these out before they are proven to be fact can be a mistake. Remember that other decisions are made based on the analysis that you are performing and communicating.
In closing, I think that it’s a good idea to have some type of playbook that is specific to your company. What are the types of things that you know need to be done everytime can be put here. This may help others if you or the senior person on your team is tasked and they have questions or are looking for the next thing to do.

No comments:

Post a Comment