Why Containment Is Easy to Get Wrong
When something looks like an attack, the urge to act immediately is strong. Wipe the machine, reset everything, switch the server off. These instincts come from a good place, but they can destroy the very information needed to understand how the attacker got in, what they touched and whether they are still present.
Containment has two goals that pull against each other: stop the situation from getting worse, and keep enough evidence to investigate. Good containment is mostly about choosing which goal gets priority at each moment, and making that choice on purpose.
Start by Understanding What You Are Dealing With
Before changing anything, take a few minutes to establish the basics. Which systems, accounts or data appear to be involved? Is the activity ongoing or finished? What is the business impact if the affected system goes offline?
Write the answers down with times, even roughly. A short timeline kept from the start is far more useful than recollections gathered afterward. If you have an incident response plan, this is where it earns its keep, because the decision about who may authorize disruptive action should already be settled.
Short-Term Containment
Short-term containment is about quickly cutting off the attacker’s ability to do more harm. Common general options include:
- Isolating a device from the network while leaving it powered on, so memory and running processes remain available for examination.
- Disabling or locking an account suspected of misuse, rather than deleting it.
- Blocking a specific connection or address at a firewall, using existing firewall rules or adding a narrow one.
- Revoking active sessions or access tokens, since changing a password alone sometimes leaves existing sessions open.
Notice that most of these are reversible. A reversible action is generally preferable early on, because your understanding of the situation is still incomplete and you may need to undo a decision.
Preserve Evidence as You Go
Evidence is often fragile. Powering a machine off can erase what is held only in memory, and logging back into an affected machine changes files and timestamps. Rebuilding it immediately removes everything.
Some general habits help:
- Keep logs from affected systems, and copy them somewhere the attacker cannot reach, since intruders sometimes alter or delete logs.
- Take a snapshot of a virtual machine before changing it, if your environment supports that.
- If you must image a disk or capture data, note who did it, when, and how.
- Limit how many people touch the affected system, and record what each person did.
If there is any chance of legal action, an insurance claim, or involvement of authorities, consider getting advice before altering evidence. How formal this needs to be varies widely by situation and location.
Long-Term Containment
Sometimes a system cannot simply be removed from service. A server that runs core operations may need to stay up while a clean replacement is prepared. Long-term containment keeps the business running with extra restrictions: tighter network rules, additional monitoring, temporary credentials, or moving a service onto a clean machine.
This stage is a holding pattern, not a solution. It buys time to plan eradication properly, rather than rushing a rebuild that leaves a weakness in place.
Common Ways Containment Makes Things Worse
- Tipping off the attacker. Abruptly blocking one foothold while others remain can prompt an intruder to destroy data or deploy more damaging tools. Where you can, map the scope first and then act on all known footholds together.
- Resetting only some credentials. If an attacker has access to several accounts, resetting one leaves the others as a way back in. Shared logins and forgotten service accounts are frequent blind spots.
- Using a compromised channel to coordinate. If email accounts may be controlled by the attacker, discussing the response over that email is risky. Have an alternate way to reach each other.
- Cleaning up too early. Deleting suspicious files before they are copied and documented removes clues.
- Spreading the problem. Plugging an infected USB drive into a “clean” machine for analysis, or reconnecting an affected device before it is verified, can carry the problem elsewhere.
Think About Backups Early
If ransomware or destructive malware is involved, check the state of your backups before doing anything else. Make sure connected backup systems are not reachable from the affected network, because some attacks target them first. Good ransomware protection, such as backups that cannot be altered from ordinary accounts, is far easier to set up beforehand than during an incident.
Communicate While You Contain
Containment often disrupts people. A user whose laptop is suddenly disconnected will be confused or annoyed. A short, honest message such as “We are investigating a problem and have temporarily disconnected some systems” avoids rumors without revealing sensitive detail. Decide in advance who speaks for the team so that technical staff can keep working.
Knowing When Containment Is Done
Containment is complete when the team has reasonable confidence that the known activity has stopped and the attacker no longer has access through the routes identified. That confidence is never absolute. It is usually supported by monitoring that continues for some time afterward, and by willingness to revisit the conclusion if new signs appear.
Each incident is different, and these are general principles rather than a script. A slower, documented approach is usually better than a fast one that leaves you unable to explain what happened.