Containing without destroying what you need

Why this matters

Containment is the phase with the most irreversible actions in it. You can re-run an analysis; you cannot un-alert an attacker, un-destroy a memory image, or un-lock out a business at month end.

It is also the phase where incomplete work is invisible. A partial eradication looks exactly like a complete one — the alerts stop, the host comes back, the incident closes — and reveals itself weeks later as a second compromise through a door nobody shut. The whole of this lesson is about making that difference visible before you close.

The lesson

Network isolation versus host isolation

Containment options sit on a scale from surgical to blunt, and the right choice depends on scope, the attacker's awareness, and what the business can bear.

Host-level isolation removes one system's ability to communicate while leaving it running and reachable by you:

• EDR network containment is the usual mechanism: the agent blocks all traffic except to the management console. Fast, revocable, precise — and it keeps the host alive for memory capture, which pulling the cable does not.
• Disabling the switch port or the virtual NIC achieves isolation without the agent, and also cuts your own access.
• Powering off is the last resort. It stops everything, destroys memory, and may trigger destructive logic. Reserve it for cases where the damage in progress outweighs the evidence, which chiefly means encryption underway.

Network-level containment works above the host:

• Firewall or ACL rules blocking the command-and-control destination. Useful, and easily bypassed by an attacker with a second channel.
• Segment isolation — cutting a VLAN or a site off from the rest. Appropriate when scope is broad or uncertain.
• DNS sinkholing the malicious domain, which contains and, valuably, tells you which other hosts try to reach it. Containment as a discovery tool.
• Blocking at the egress proxy, which catches hosts you have not identified.

Identity-level containment is the one people under-use and is often the most effective, because modern intrusions are credential-driven rather than host-driven. Disabling an account, revoking sessions and tokens, or blocking a conditional-access path can cut an attacker off across every system at once — and no amount of host isolation helps if they simply log in somewhere else.

How to choose:

• Scope known and narrow → host isolation, all at once.
• Scope uncertain and spreading → network segment containment while you scope, accepting the disruption.
• Credential-based access → identity containment first, hosts second.
• Evidence still needed → capture memory first where you can; EDR isolation preserves it, cables and power do not.

And the rule from lesson 30, restated because it is the one most often broken: contain the full known scope simultaneously. Host-by-host containment as you discover systems gives a capable attacker time to move, and it teaches them exactly what you can see.

Credential reset and session revocation

The half of eradication that gets forgotten, and the reason many "eradicated" intrusions come back.

The principle: any credential exposed to a compromised system is compromised — not "may have been", for practical purposes. Credentials sit in memory, in configuration files, in browser stores, in scripts, in scheduled tasks, and in the tooling that manages the host.

What that means in scope:

• Every account that logged into the host, interactively or as a service.
• Local accounts on the host, and any shared local password, which usually means every machine built from the same image.
• Service accounts, which are the difficult ones: often highly privileged, often with passwords embedded in applications, often rotated by nobody.
• API keys, tokens and certificates present on the host or accessible from it.
• Cached domain credentials and Kerberos material, which is why a compromised domain controller escalates into rebuilding trust in the whole directory.
• Credentials in source, in the CI/CD pipeline and in configuration management, which may be reachable without touching the host at all.

Resetting the password is not sufficient on its own, and this is the piece most often missed: existing sessions and tokens frequently remain valid. You must also revoke sessions, refresh tokens, OAuth grants, application passwords, and API keys, or the attacker keeps access with an authentication that no longer needs the password you changed.

Sequencing matters:

• Reset at once, across the scope, for the same reason containment happens at once. Rolling resets tell the attacker to consolidate.
• Coordinate with containment, so you are not resetting credentials on a system the attacker still controls and can recapture them from.
• Check for attacker-created accounts and added authenticators before you declare this done — a registered MFA device or an added SSH key survives every password reset you perform.
• Expect breakage. Service account resets break applications, and doing it during an incident without a list of dependencies causes an outage. Which is, again, a preparation item.

Removing persistence completely

Eradication fails when persistence is missed, so enumerate it rather than relying on the tool's verdict.

Where persistence lives, by platform:

• Windows: run and run-once registry keys, scheduled tasks, services, WMI event subscriptions, startup folders, DLL search-order and COM hijacks, accessibility-tool replacements, LSA and authentication package entries, Office add-ins, and BITS jobs.
• Linux and Unix: cron and at jobs, systemd units and timers, shell profile and rc files, init scripts, LD_PRELOAD entries, SSH authorized_keys, kernel modules, and modified binaries or libraries.
• Cloud and identity: added IAM users, roles and access keys, trust policies permitting an external account, OAuth application grants, federation and identity-provider trust changes, mail forwarding and inbox rules, and serverless functions on a schedule. Persistence here survives rebuilding every host you own, which is precisely why it is favoured.
• Application-level: web shells, modified templates, plugins, database triggers and stored procedures, and altered CI/CD pipeline definitions.
• Firmware and hypervisor, rare and effectively unrecoverable without specialist help.

How to do the enumeration properly:

• Compare against a known-good baseline where one exists, rather than inspecting in isolation. The value of a baseline is that it answers "is this normal here", which no amount of expertise answers reliably for an unfamiliar estate.
• Check every host in scope, not only the one that alerted.
• Look at the timeline. Everything created or modified around the intrusion window deserves a look, and this is where lesson 30's timeline pays for itself.
• Do not trust an EDR "remediated" verdict as completion. It removed what it recognised. That is a subset.

Rebuild versus clean, and how to decide

The default answer is rebuild, and the reasoning is straightforward: you can prove a rebuilt system is clean because you know what it was built from. You cannot prove a cleaned system is clean, only that you did not find anything further.

Cleaning in place is defensible when:

• The compromise is well understood commodity malware with a known, complete removal.
• It was caught early, before credential theft or lateral movement.
• Rebuilding is genuinely infeasible — an appliance, an unsupported system, a bespoke build nobody can recreate.
• The system is not privileged and holds nothing sensitive.

Rebuild when:

• Any hands-on-keyboard access occurred. A human attacker with an interactive session may have done anything, and the absence of evidence for it is unpersuasive.
• Root or SYSTEM privilege was obtained.
• The malware is unknown, or capable of loading arbitrary further payloads.
• Persistence was found, since finding one mechanism raises the odds of a second.
• The system is critical or privileged — a domain controller, a jump host, a build server.
• You cannot establish what happened, which is the most common real reason and a perfectly good one.

Rebuilding properly means:

• From a known-good image or definition, not from a backup taken after the compromise began. Check the backup's date against the timeline — restoring the intrusion is a well-populated category of mistake.
• Patched before it returns to the network, or it is re-exploited within minutes if the entry vector was a vulnerability.
• Restoring data, not system state, where the two can be separated.
• With credentials rotated, per above.
• And note that rebuilding does not fix the entry vector. A rebuilt host with the same unpatched service and the same exposed management port is a future incident on a timer.

Watching for the attacker's response to containment

The part that distinguishes a response from a clean-up, and a recurring exam theme: containment is an event the attacker observes, and a capable one reacts.

What they do:

• Activate a backup access channel — a second implant, a different protocol, a dormant account. Prepared in advance precisely for this.
• Accelerate. If they believe they are about to lose access, exfiltration or encryption may start immediately. This is a real cost of containing a ransomware actor half-way.
• Go quiet, and return in weeks when attention has moved on. The most dangerous response, because it reads as success.
• Destroy evidence — clear logs, wipe systems, delete their tooling.
• Escalate to extortion, contacting the organisation directly.

So the hours and days after containment are an active monitoring period, not a wind-down:

• Watch for the indicators you have, everywhere, especially on hosts you did not contain.
• Watch the accounts you reset for authentication attempts, which is a strong signal the attacker still holds credentials you have not found.
• Watch for new persistence appearing on rebuilt and cleaned systems.
• Watch for novel outbound patterns, since their known channels are blocked and a new one has to look different.
• Keep the hunt going for an agreed period before you stand down, with the duration decided in advance rather than by fatigue.

And record the decision to close against evidence: scope searched, persistence enumerated, credentials rotated and verified, monitoring clean for a stated period. "Nothing has happened for a few days" is not that evidence — it is the absence of detection, which this course has distinguished from the absence of an attacker since its first lesson.

Topics this lesson owns

• [x] Network isolation versus host isolation
• [x] Credential reset and session revocation
• [x] Removing persistence completely
• [x] Rebuild versus clean, and how to decide
• [x] Watching for the attacker's response to containment