Containment

Containment is a critical phase of incident response, focused on stopping the spread of a security incident. The goal is to limit damage while preserving evidence for investigation. Containment sits between detection and eradication: you have confirmed something bad is happening, and before you can clean it up you need to make sure it cannot get worse while you work.

AWS Containment Actions

• Deactivate compromised IAM access keys
• Attach a deny-all IAM policy to compromised users/roles
• Replace security groups with quarantine groups (no inbound, no outbound)
• Revoke active role sessions by attaching a deny-all inline policy with an aws:TokenIssueTime condition (note: IAM eventual consistency may create a brief propagation delay)
• Snapshot EBS volumes before terminating for forensics
• Block malicious IPs in WAF or NACLs

Why the Order of Actions Matters

In AWS, identity is usually the real blast radius, not the machine. A compromised EC2 instance is dangerous mostly because of the IAM role attached to it. So the practical ordering is: credentials first, network second, compute last. Deactivate or deny the identity the attacker is using, then isolate the network path, then deal with the instance or container itself. If you do it in the reverse order, you isolate a box while the attacker continues operating with stolen credentials from their own infrastructure, completely outside your VPC.

Temporary credentials deserve special attention. STS credentials cannot be invalidated before their expiry time. The documented workaround is to attach a deny policy to the role with a condition on aws:TokenIssueTime, which blocks every session issued before a timestamp you choose. Any legitimate workload simply re-assumes the role and gets fresh, working credentials; the attacker's stolen session stops working.

How It Goes Wrong in Practice

The classic failure mode is terminating a compromised instance as the first move. It feels decisive, and it is almost always wrong. Termination destroys volatile evidence: memory contents, running processes, active network connections, and anything on instance store volumes. Worse, it does nothing about the instance role credentials the attacker already pulled from the metadata service. Those credentials keep working from anywhere on the internet until they expire, so the attacker continues listing buckets and creating resources while the team believes the incident is closed because "the server is gone".

The disciplined sequence looks like this: swap the instance's security groups for a pre-created quarantine group, snapshot its EBS volumes, revoke the role's active sessions with a aws:TokenIssueTime deny, review CloudTrail for what the credentials actually did, and only then decide whether the instance is terminated or kept for deeper forensics.

A Practical Check: Quarantining an Instance from the CLI

Replacing all security groups on a compromised instance with a quarantine group is a single call:

aws ec2 modify-instance-attribute --instance-id i-0abc123def456789 --groups sg-0quarantine1234567

The --groups parameter replaces the entire set of groups on the instance, and the command produces no output on success. One caveat from the AWS documentation: if the instance has more than one network interface, change groups per interface with ModifyNetworkInterfaceAttribute instead. Deactivating a compromised access key is just as short:

aws iam update-access-key --user-name deploy-bot --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

Deactivation is reversible, which is exactly what you want during an investigation: the key stops working immediately but its ID remains searchable in CloudTrail history.

Prepare Containment Before You Need It

Containment is a terrible thing to improvise at 3am. Pre-create an empty quarantine security group in every VPC, keep a tested deny-all policy document in your incident response repository, make sure responders have break-glass access that does not depend on the possibly-compromised identity provider, and rehearse the sequence in a game day. The teams that contain incidents in minutes are the ones that only have to execute, not design, under pressure.

Frequently Asked Questions

How is containment different from eradication?

Containment stops the incident from spreading; eradication removes the attacker's foothold. Quarantining an instance is containment. Deleting the backdoor IAM user the attacker created, patching the vulnerability they exploited, and rebuilding the host are eradication. Containment buys you the time to do eradication properly.

Should I terminate a compromised EC2 instance immediately?

No. Isolate it with a quarantine security group, snapshot its volumes, and revoke its role sessions first. Termination destroys evidence and does not stop credentials that were already exfiltrated.

Can I revoke temporary STS credentials directly?

No. There is no API call that invalidates an issued STS session before it expires. The effective control is a deny policy on the role conditioned on aws:TokenIssueTime, which blocks all sessions issued before the time you specify.