Security Incident Eradication Checklist

As we continue our series laying out some helpful initial checklists for small-medium sized businesses to better prepare for potential security incidents, we’re now moving into the latter half of the six phases of incident response with eradication. After you have contained a security incident and limited its ability to spread, you now have to worry about removing the actual infection so you can move on to recovery. But this is a very misunderstood step, from our experience. A lot of organizations don’t understand the risks associated with improper eradication and have misconceptions about how to actual fix a malware infection or breached system. Let’s look at a security incident eradication checklist that covers some of the important steps and things you need to think about during this process.

1. Do you know the point of entry?

When you are trying to fix a security incident, one of the most important considerations is preventing re-infection or the exact same incident happening again. As part of the eradication and either simultaneously or before fixing the actual infection, you should have a plan to prevent it from happening again. If you’re not sure how it happened, make sure to conduct additional internal log analysis or engage a third-party to help with this process so you can develop a remediation plan to prevent this from happening again.

2. How do fix the problem and verify the threat has been eradicated?

This is one of the most misunderstood portions of incident response efforts. Actually fixing a threat can seem straight forward, but to achieve any kind of assurance that the problem is really taken care of is tricky. Running an antivirus scan that comes back clean and calling it a day is very likely not a sufficient course of action, as it fails to address elements of an attack such as lateral movement, dropped payloads, running processes, and established persistence, just to name a few. Many times, these extra elements of an attack will be obfuscated, as well, making them invisible to traditional signature-based antivirus solutions. While you may not be able to afford a full forensic analysis of an incident and threat hunters to monitor your network for signs of persistence following an incident, there are a few important considerations.

First, if at all possible, perform a complete wipe/re-image of the affected system(s). This would of course require you to have good back-ups in place and the ability to establish the initial date/time of infection, rolling back to just before that. Besides that, reset the passwords of any compromised or potentially compromised accounts. If you’re not using LAPS, this should include the local administrator password of the workstation, along with any user accounts that logged into that system during the infected time. If you don’t have good back-ups or the ability to completely re-image an infected system, it’s even more imperative to identify the initial point of infection, any indicators of compromise to understand affected processes/applications, and to increase monitoring on infected systems following the removal/recovery process.

3. What additional hardening, patching, and/or configuration steps need to be taken?

While eradicating and preparing to recover systems/business processes, you should be thinking about and documenting any additional security hardening that needs to be done to affected systems or the network as a whole following the incident. Similarly, is there any patching that needs to be done to ensure other systems on the network aren’t affected or do configuration changes need to be made to applications/software to prevent infection/spread. These issues should be considered/documented now and then formalized, approved, and implemented during the lessons learned phase of the incident response process.

4. Are you able to monitor the system for evidence of a future compromise?

Regardless of how you choose to eradicate an infection, you need to have a plan for increased monitoring of any affected systems for some period of time after the eradication process (e.g. 30 days). This is important to make sure the steps you took to fix the issue were effective and there were no lingering effects, such as rootkits, backdoors, additional compromised accounts, etc. This may be a daily task where you review event logs from the affected host or Active Directory logs for account usage. Or maybe you simply pay a little more attention to alerts from your SIEM that is already in place and being used for log aggregation and analytics. Whatever the case may be, you need to be on heightened alert.

These are just a few items as part of a security incident eradication checklist that you should consider for your particular organization. Each organization and each situation may require different processes for this phase, based on available technology/expertise and the affected assets. But the differences in approach are another great reason why you should think through these processes as part of your overall Incident Response Plan ahead of time, and practice your plan with the stakeholders in your company as part of Incident Response table-tops. Reach out if you have questions on how to customize this process or if you need help running through table-top exercises in your organization.