Certified: The GIAC GSOM Audio Course

In this episode, we move into the phase of incident work where you stop merely containing damage and start removing the underlying problem while bringing systems back to a stable, trustworthy state. Eradication is the work of eliminating the attacker’s foothold and the conditions that allowed it, and recovery is the work of restoring normal operations without accidentally reopening the door. New learners sometimes assume this phase is just cleaning up, like deleting a bad file and restarting a service, but in real incident response the hardest failures often happen here. If you restore too quickly, you can reintroduce compromised systems into production and trigger a repeat incident that looks like the attacker never left. If you eradicate too narrowly, you might remove one visible symptom while leaving persistence behind, which means the attacker returns the moment you relax. The key idea is that eradication and recovery must be driven by verification, not by hope, and reentry must be controlled, not rushed.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Eradication begins with a clear understanding of what exactly you are trying to remove, because you cannot remove what you have not identified. That does not mean you must know every detail of the incident, but you do need a defensible theory of access, such as whether the attacker used stolen credentials, exploited a weakness, or abused a trusted relationship. From that theory, you identify the footholds, like compromised accounts, altered configurations, unauthorized scheduled actions, or backdoor access paths. You also identify the enabling conditions, such as overly broad privileges, missing protections, or weak segmentation that allowed movement. Eradication is successful when both the footholds and the enabling conditions are addressed, because removing only one side often leads to recurrence. A beginner mistake is to treat eradication as a single action, when it is actually a series of actions that must be coordinated so the environment changes in a controlled way. When you think in terms of footholds and conditions, your eradication plan becomes more complete and less fragile.

Verification is the thread that should run through every eradication decision, because it is the only reliable way to know whether you actually removed the attacker’s capability. Verification means you define what evidence would show the attacker is gone, what evidence would suggest they are still present, and what evidence would show your changes had the intended effect. For example, if you reset credentials, you verify that old credentials no longer work and that authentication patterns return to expected behavior. If you remove persistence, you verify that the suspicious processes or tasks no longer appear after normal system cycles. If you patch or change configurations, you verify that the vulnerable condition is no longer present and that related indicators stop appearing. This is not about performing a perfect scientific proof, but about creating a set of checks that make reentry a reasoned decision. Without verification, recovery becomes a gamble, and gambling is how incidents turn into repeating disasters.

A critical part of verification is understanding that some checks are stronger than others, and you should favor checks that directly measure what you are trying to confirm. A weak check might be that an alert stopped, because alerts can stop for many reasons, including logging failures or attacker behavior changes. A stronger check might be that the suspicious behavior can no longer be produced under the same conditions, such as repeated failed authentication where success used to occur. Another strong check is corroboration across independent sources, such as confirming both host-level and identity-level signals align with the idea that the foothold is gone. Verification should also include checking for negative evidence, meaning evidence that should not exist if your theory is correct, like a privileged login from an unapproved location after access restrictions were applied. When negative evidence appears, you treat it as a signal to pause and reassess rather than to explain it away. This mindset keeps eradication connected to reality and reduces the chance of returning compromised systems to normal operations.

Controlled reentry is the practice of bringing systems and access back online in steps, with monitoring and checkpoints that allow you to stop if something looks wrong. New learners often imagine recovery as a big switch that flips everything back to normal, but that approach hides problems until they become large. Controlled reentry instead treats recovery like a phased return, where you start with the most essential functions, validate stability, and then expand. For example, you might restore core services first, then less critical integrations, then broader user access, each time verifying that security signals remain clean and that business operations behave as expected. You also keep containment controls in place longer than you think you need, because the first hours after reentry are when hidden persistence often reveals itself. The goal is not to slow the business down, but to ensure that when services return, they return into an environment that can detect and stop a relapse quickly. When recovery is phased and monitored, you can be both fast and safe.

Another important concept is that eradication and recovery are not just technical actions, because identity and process changes can matter as much as system changes. If an incident involved credential misuse, eradication may require reviewing which accounts were affected, resetting or reissuing credentials, tightening permissions, and ensuring that access paths are aligned with least privilege. If an incident involved operational missteps, recovery may require clarifying who can make certain changes and how those changes are reviewed. If an incident exposed gaps in detection, part of recovery is improving monitoring so you can confirm cleanliness and detect recurrence. Beginners sometimes treat these as separate improvements for later, but they are often necessary for safe reentry right now. For example, restoring a system without fixing an access weakness can recreate the same conditions the attacker used. By treating identity, permissions, and process as part of eradication, you make recovery more durable rather than temporary.

It is also helpful to understand why attackers often survive early eradication attempts, because that teaches you what to verify and where to look. Attackers can establish multiple footholds, such as more than one compromised account, more than one altered system, or more than one access path, so removing a single foothold does not necessarily remove access. Attackers can also hide within legitimate tools and normal-looking behavior, which means you might remove obvious malicious artifacts while leaving subtle privilege changes or configuration alterations behind. They may also have created persistence that survives reboots, software updates, or user logouts. This is why eradication should be systematic rather than opportunistic, guided by your best understanding of attacker goals and methods. You want to look for breadth, meaning how many paths exist, and depth, meaning how durable each path is. Verification checks should reflect both, so you can be confident you removed access rather than merely quieted symptoms.

Recovery planning becomes safer when you explicitly identify what must be true before you allow a system or capability to return. These are sometimes called reentry criteria, and even if you do not use that phrase, the idea matters for beginners. Reentry criteria might include that compromised accounts have been secured, that the affected systems have been restored from known-good sources or validated as clean, and that monitoring is in place to watch for recurrence. Criteria might also include that critical dependencies are understood, so you do not restore a service in a way that breaks downstream systems unexpectedly. The reason criteria are valuable is that they turn a stressful decision into a checklist of evidence-based conditions, which reduces emotional pressure and debate. They also help the organization accept short delays when delays are justified by safety. If someone asks why a system cannot return yet, the answer becomes a set of conditions tied to risk rather than a vague concern. That clarity builds trust in the response team and improves coordination during high-pressure restoration.

A subtle but important part of controlled reentry is keeping a close watch on changes, because recovery often involves many modifications happening quickly. Systems may be rebuilt, access may be reset, configurations may be tightened, and services may be restarted, and in that flurry it is easy to lose track of what changed and why. Losing track creates two problems, because it makes troubleshooting harder if something breaks, and it makes security verification weaker because you cannot link observed behavior to specific changes. A disciplined approach records key recovery actions, their timing, and their expected effect, so that if a suspicious signal appears after reentry you can quickly determine whether it is an expected side effect or a sign of recurrence. This record also helps prevent accidental rollback of a security improvement in the rush to restore functionality. When you can trace changes, you can also validate them more effectively, because each change has a purpose and a corresponding verification step. That is how recovery stays controlled instead of chaotic.

Testing is another part of recovery that beginners sometimes misunderstand, because they think testing is only for software releases. In incident recovery, testing means validating that the restored system behaves correctly and securely in its normal role. That includes basic functional behavior, like whether users can access what they should, but it also includes security-relevant behavior, like whether access is appropriately restricted and whether logs and monitoring still capture meaningful activity. Testing also helps confirm you did not restore a system in a brittle state, where it works briefly but fails under real load or normal user behavior. If you skip testing, you may declare recovery complete and then face a secondary outage that undermines confidence and creates a new emergency. Controlled testing does not have to be elaborate, but it should be intentional and connected to the incident story. For example, if the incident involved unauthorized access, part of testing is confirming that the same access path is now blocked. That kind of testing directly supports verification and reduces the risk of repeat compromise.

Another truth-driven technique is to maintain heightened monitoring during and after reentry, because that period is when the environment is most sensitive. If an attacker still has a foothold, they may try to reestablish control once they notice containment controls changing or once systems return. If your eradication created gaps or side effects, monitoring can reveal them early while impact is still limited. Heightened monitoring also helps you distinguish between normal recovery noise and suspicious recurrence, because recovery itself can create unusual patterns such as mass logins, service restarts, and configuration updates. The key is to treat monitoring as a feedback loop, not as a passive dashboard. When monitoring reveals something unexpected, you pause, interpret it in the context of your timeline and changes, and decide whether to continue, adjust, or roll back. This is how you keep reentry controlled rather than hopeful, and it is how you detect relapse early instead of after harm returns.

The relationship between eradication and business continuity is also crucial, because recovery decisions affect people’s ability to work and the organization’s ability to serve customers. A common mistake is to treat recovery as purely technical, where the goal is to restore everything as fast as possible. The safer approach is to prioritize what must return first to support critical operations while keeping risk controlled. That may mean restoring a smaller set of functions first, or temporarily operating in a restricted mode, or delaying nonessential features until confidence is higher. These choices are not signs of weakness, because they are deliberate risk reductions that protect the business from a repeat incident. When you communicate recovery in terms of priorities and controlled reentry, stakeholders can understand why some functions return sooner than others. That transparency makes it easier to accept temporary limitations and reduces the pressure to shortcut verification. Ultimately, a stable partial recovery is better than a rushed full recovery that collapses into another incident.

In closing, eradication and recovery succeed when they are treated as a verified, controlled progression rather than a fast cleanup followed by a return to normal. Eradication removes both footholds and the conditions that enabled them, and it uses verification to confirm that the attacker’s capabilities are truly gone. Recovery restores operations through phased reentry, testing, and heightened monitoring so the environment can catch relapse before it becomes damage. The discipline here is not about being slow, because it is about being intentional, so each change has a purpose and a corresponding check. When you build reentry criteria, track changes, and validate outcomes, you turn uncertainty into confidence step by step. This approach protects the business from self-inflicted outages and protects the response team from false closure, because you can demonstrate that systems returned in a state that is both functional and trustworthy.