Episode 4 - NIST SP 800-61 Computer Security Incident Handling Guide (Containment,Eradication and Recovery)

 Show Notes: Episode on Containment, Eradication, and Recovery

In this episode of Traffic Light Protocol,  Clint Marsden explores the containment, eradication, and recovery phases of the NIST SP 800-61 framework for computer security incident handling.

Key Topics Covered:

• Containment Strategies:  Choosing appropriate containment methods based on the incident type, potential damage, service availability, and evidence preservation. Examples include power disconnection and network isolation.
• Real-World Example: Clint shares an incident response case where premature action against attackers led to a total domain takeover.
• Evidence Gathering and Handling: The use of tools like write blockers to preserve evidence integrity.
• Threat Analysis: Highlights passive techniques for analysing threats without alerting attackers, such as remote log analysis and OPSEC to track attackers
• Restoration and Recovery: Covers steps to restore systems to normal operations, including vulnerability patching, backup restoration, and password resets.
• Future Considerations: Suggests engaging with external vendors for comprehensive incident response and utilizing threat intelligence platforms.

Join Clint Marsden as he guides you through the intricacies of incident response, helping you enhance your digital forensics skills. Follow Clint Marsden on LinkedIn (https://www.linkedin.com/in/clintmarsden/) and TLP on Linked In https://www.linkedin.com/company/traffic-light-protocol-the-digital-forensics-podcast-tlp for more updates and insights. 

Transcript

Hi and welcome to Traffic Light Protocol the digital forensics podcast. I am your host Clint Marsden. Today we're discussing containment eradication and recovery as part of the NIST SP 800-61 series on computer security incident handling. 

The containment eradication and recovery phase is a lot less detailed than detection and analysis and that is just by a function of what is involved. NIST talks about choosing a containment strategy depending on the type of incident that you are dealing with. We have some examples talking about the potential damage to and the theft of resources, the need for evidence preservation, service availability like network connectivity or services provided to external parties, time and resources needed to implement the strategy, the effectiveness of the strategy so partial containment or full containment, and the duration of the solution. 

So is there an emergency workaround that can be completed in a few hours or is it a few weeks or is it a permanent solution? Something that NIST talk about is the potential issue regarding containment when some attacks rely upon a certain system being online and if one system goes offline then it will potentially cause a follow-on effect. Something that I've seen is not so much like that where there is a contingency on a system being online more so that when you do decide to contain and if we talk about containment you've got a few options you can pull the plug for the power which you lose RAM and that's not ideal because there's a lot of forensic residue and evidence that is that is in RAM and RAM is volatile so essentially once you turn the machine off most of that is going to go away. Minuscule amounts do persist when you turn it back on but not enough for a proper forensic analysis. 

The other method of containment is disconnecting the network, Wi-Fi, Ethernet. In doing this you are now letting the attacker know that they have been detected and that can cause a problem in itself. I've been involved in an incident response case where the system administrators detected that there was an attacker inside the network they had uploaded a document to a public website that was receiving files for that that was how their their business operated members of the public were able to upload files and then that file was opened and converted into a pdf that caused malware to be executed in a macro and set off a chain of events where the domain was almost entirely lost. 

The attackers once they'd been discovered by the administrators and the administrators had not really gained all the facts understood all the IOCs had attempted to start kicking them out and it got to the point that this annoyed the attackers significantly and they started booting out the domain admins and resetting their passwords and it was a very very close call. So as part of this containment strategy you will need to think about are we ready do we have all the information and this is something that I don't feel that NIST have really addressed at this point in time and in this and it's a little bit surprising that it's a little short on the warnings or the the potential detail. They do talk about things much more I would say in a business continuity context so where they refer to service availability time and resources the effectiveness of the strategy and how long the solution is going to be in place and are not bringing attention to issues that can be present like what I just shared with with the attackers not being fully kicked out especially if they've had the chance to perform lateral movement and shutting down one system just means that they pop up in another area of the network and then it's like playing whack-a-mole. 

Moving on to evidence gathering and handling evidence gathering is such an important part and we've discussed this in previous episodes where I talk about taking notes and if you're taking notes you are setting yourself up in the right way to write a very thorough and detailed report that flows that prevents you from having to reanalyze evidence or reprocess evidence and it makes your life easier by documenting as you go. So what types of information do you want to track? Do you need to record when you're going through this phase of an incident? The most basic things that you will generally need are the computer system host name the MAC address and the IP address. This gives you some places to pivot from and you can move on to searching logs looking in other areas of the network you'll also be able to block those IPs those MAC addresses at various control points.

What you'd really like to get is some additional information like where it's located the serial number of the device the model number of the device whose device it is the username that's currently logged in who normally uses the device and the name title the job title and the phone number of anyone who has been involved in the investigation handled the evidence. Every time that you're taking these notes it's really important to write down the time and date including the time zone of each occurrence of where the evidence was handled and where the evidence was stored. So things can get a little bit chaotic when you're grabbing that evidence.

As part of an incident response toolkit what you really want is to have a filing cabinet that's dedicated to your IR gear and in there you've got fast usb thumb drives like usb3 usb3 external hard drives preferably ssd the quicker you can move the better buying spindle is just not worth it. They are your dedicated IR devices label them then in your notes you can document where that evidence is stored again comes back to we're writing the report we need to get some screenshots we need to get some additional evidence where is it refer to our contemporaneous notes it's on this disc it's very easy to find that also falls into chain of custody. So there's two things that we're going to be doing when we're gathering evidence the chain of custody is part two but part one is an imaging form and the imaging form is used when you're taking a full disc image of a device so you are shutting down the machine pulling the drive out using a disc duplicator using something like a tableau or a another device with a right blocker in it to prevent any evidence for being modified it's really important that you take steps to implement right blocking because it can prove that the evidence was not modified during the retrieval and once the imaging form is complete and it will have those details of the identifying information it will have where it's located the serial number the model number of the device the host name if you've got space put in the mac address put in the ip address as well this is the first things that you're going to be doing when you turn up on site it all rolls into the same process the more information that you gather at the time and when you first get there it all rolls in to as you're searching through the evidence you've got a bit of a baseline what is normal what is not normal it helps roll it into your ioc spreadsheet if you think about when you want to be collecting the evidence it's as soon as the incident occurs when an incident occurs it might set off a chain of other events so for example a user clicks on a phishing link they go to the credentials the user could then be directed to download malware they don't know it's malware they may be taken to the page that they thought they were trying to go to anyway and then they're none the wiser and then throughout the day they close the browser and completely forget about it but you don't want to be waiting some evidence is volatile as we spoke about before if the machine is rebooted everything that was in ram is lost if there are certain artifacts that have been run and that are essentially file fileless malware we want to be able to capture that from ram say we've now identified the source of the incident and we're not talking about a phishing email we are talking about a network-based attack and we've discovered the attacking host's ip address this is where the danger level kind of goes up a little it goes up a notch there's a couple of reasons for that once we start poking around on the network side of things there are a lot of artifacts that will be left and left behind if you take an ip address and you try and access it on the internet you take an ip address you google it take an ip address ping it phone scan it these leave artifacts on the other side as well so in the same way that we're doing forensics and we are combing through artifacts to see what has been done it's a two-way street we're leaving artifacts on the other end so it's really important that we're very careful about what we do when we discover what the ip address is of the host that's attacking the reason for that is we don't want to let them know that we've detected their attack and to give us the upper hand if we can just observe capture all of the iocs capture some ttps if we're lucky once we have the full picture we can map it out we might do some threat hunts we might sweep our own network go through our logs figure out what other systems have been touched by these threat actors this gives us a better chance of a proper eradication depending on your threat model you'll need to decide if you want to be looking up these ip addresses on the public internet in some instances you might have access to a threat intelligence portal or a cyber security vendor that you work with has a threat intelligence portal that you may be able to license or get them to search for you to identify these ips and to see what you're dealing with that might lead you to a particular threat group and then you might be able to understand their ttps which will help you in subsequent threat hunts or it might not yield much at all and you might find that this is an unclassified threat group and there are no ttps available be aware that you can set up search alerts in google so that when people search for your particular string you can get statistics on what is being searched if you're dealing with an apt they might have something like this in place if they are well they're obviously advanced because they're an apt but they might have specifically built infrastructure to target your organization this means that they're only using a few ips for the campaign that is attacking you which means if you start trying to access it directly if you start googling the ip they may then be alerted because well there's no one else that's going to be searching for that because no one else knows about the ip these are rarer cases this is not happening every day but it's something to be mindful of and it's something to have a bit of a strategy around whether you allow your team to do these things as part of the incident response investigations for example you might say no one is to google the threat actor ip we must use our threat intelligence platform which is a private database not public gives us that extra level of protection what i would suggest is a hands-off approach what we want to be doing is using binoculars to look from a very far distance away so that the attacker is not aware of their activities being monitored taking a step back and looking at what technologies do we have in place to monitor them from afar doing things like growing logs remotely or if you've already got logs that are being sent to a seam these are great because they're passive if we start doing things like scanning the system or trying to make changes this might tip them off so we really want to be going for passive techniques in terms of analysis now all this is being said with the view of containment so once we understand what needs to be contained what the entire spread of the infection is or what has been targeted then we can move into eradication i really want to stress that what i've spoken about in this episode is nowhere near the level of detail that i could go into and what needs to happen during a normal incident this is not the right forum or series to talk about identifying an attack and using all of the team members that you have in a security function and external to that security function to look through your network and capture everything perform that analysis and then have an eradication event if it is of a level that is that significant i encourage you to work with your existing vendors and partners to take these steps if you don't have dedicated teams in place because it can quickly spiral out of control and depending on the actor that you're dealing with can be quite significant and require quite a substantial amount of effort moving into the weeks or months for some large environments if it's a smaller type incident what we're talking about in this series is probably going to be enough to get you off the ground and to into help and if it's just more of a information gathering piece as you seek to fit other bits together then fantastic but i just wanted to include that caveat because not all incidents are the same if we take the assumption that containment has occurred that the system has been isolated we are now focusing on getting the administrators to restore systems to normal operations making sure that the systems are functioning as they should as normally if you've identified how they got in initially are there vulnerabilities that need to be patched are there iocs that need to be blocked at the firewall level or perhaps email gateway and even getting so far into restoring systems from known good and clean backups focusing on making sure that the backup is restored from prior to the incident even as far back as prior to any malware being dropped or persistence mechanisms being set up on the systems so just because the ransomware occurred on a friday the attacker may have been there on monday understanding the internals of the environment you might need to go back even further which is only going to be identified if you've got external logging because if the system has had ransomware on it the evidence will no longer be available but also might need the assistance of a an external forensic team to do so it goes without saying that as part of this process any passwords that might have been used to gain entry to your environment need to be rotated but any systems that have been touched by the attacker consider what stored passwords would be on those systems and i'm not just talking about passwords that are stored in text files i mean password hashes these things need to be considered just in case those passwords are not immediately obvious it might be suitable for you to do a entire company password reset and it's a good time to think about where is mfa not enabled and if we don't have the function to enable mfa how do we get it that is one of the biggest threat vectors these days employees are phished the accounts that are used do not have mfa and it opens up a whole can of worms it might be a good time to consider did we know about this happening in the most recent pentest report if you haven't had a pentest on the perimeter it might be time to engage a pentester to start to get some of that low-hanging fruit out of the way and then reduce that risk of it being very easy for attackers to enter the network in future something that i will mention is that pentesters love going through last year's report and using the same exploits not all of them do this but they do get a lot of pleasure out of doing it so if you do engage pentest firm i'd recommend that you do remediate the vulnerabilities and the next year that you have the pentest engagement you're not paying for the engagement where they get in using the same techniques as last year and get to write that in the report again i'm going to change it up get them to find new attack paths things that are not as bleedingly obvious as last time this wraps up the containment eradication and recovery episode of nist 800-61 of the computer security incident handling guide next up and the last episode in the series will be on post incident activity thank you for listening today i hope you enjoyed it i hope you got a lot out of it please follow me on linkedin my name is clint marsden and i've been your host for tlp the digital forensics podcast we'll see you next time