Quarantining a Compromised EC2 Instance

If GuardDuty or your monitoring shows an EC2 instance making malicious outbound connections, mining crypto, or scanning your network, it needs to be quarantined.

Quarantine isolates the instance from everything else so it can do no further harm, while keeping it alive for investigation rather than wiping the evidence.

The cleanest quarantine is to replace the instance's security groups with a single forensic group that has no inbound rules and, ideally, no outbound rules.

Because security groups are stateful and instance-attached, this immediately severs essentially all new connections without touching anything else in the subnet.

Stopping or terminating the instance flushes RAM, where much malware lives, and may destroy attacker artifacts.

Quarantine keeps the instance running but isolated, so you can snapshot disk, dump memory, and observe behavior. You eradicate only after the evidence is safely captured.

A compromised instance frequently carries an IAM role via its instance profile, and the attacker may be exfiltrating those temporary credentials to use elsewhere.

Replace or remove the role and revoke active sessions so the stolen credentials stop working across all AWS services, not just on the instance itself.

Immediately snapshot every attached EBS volume to freeze the disk, and capture memory if your tooling allows.

Tag these artifacts as quarantine evidence. Mounting snapshot copies read-only on a separate forensic instance lets you investigate without altering the originals or risking re-infection.

For an extra layer, you can add a deny rule in the subnet's network ACL for the instance's private IP.

NACLs are stateless and apply at the subnet boundary, so this catches any path a security group change might miss. Use it as a backstop, not the primary control.

If the instance sits behind an Elastic Load Balancer or in an Auto Scaling group, deregister it so traffic stops flowing to it.

Put the Auto Scaling instance on standby or detach it so the group does not terminate your evidence by replacing what it thinks is an unhealthy host.

At scale, manual steps are too slow. A common pattern: GuardDuty finding to EventBridge rule to Lambda, which swaps the security group, snapshots volumes, removes the role, and tags the instance.

This turns a multi-step response into a single automated action that fires within seconds of detection.

Quarantine buys time to ask how the attacker got in. Review CloudTrail, VPC Flow Logs, and on-host logs to find the entry point — an exposed port, an unpatched vulnerability, or a stolen credential.

Without the root cause, a rebuilt instance can be compromised the very same way.

After evidence is captured and the root cause is understood, replace the instance from a clean, patched AMI rather than cleaning the infected one.

You can rarely guarantee a backdoor is fully removed. Redeploying from a trusted image is faster and far more reliable than scrubbing a compromised host.

Mark the quarantined instance and its snapshots with clear tags like Status=Quarantine and the incident ID, so no automation or operator accidentally returns it to service or deletes the evidence.

Track it through to closure in your incident record, confirming both that the threat is contained and that the forensic artifacts are preserved.

Pick the right credential step.

Quarantine a compromised EC2 instance by swapping in a deny-all security group while keeping it running, then snapshot EBS volumes and capture memory before changing anything. Remove the instance-profile role and revoke active sessions so stolen credentials die, detach it from load balancers and Auto Scaling, and add a NACL backstop. Automate the whole flow from GuardDuty, investigate the root cause, and rebuild from a trusted AMI.