Isolating a Resource for Forensics

When an EC2 instance is compromised, your instinct may be to shut it down. Resist that. Powering off destroys volatile memory and may tip off the attacker.

Isolation cuts the resource off from the network and other systems while keeping it running and intact for analysis. Stop the spread without erasing the evidence.

The fastest way to isolate an instance is to attach an empty, deny-all security group. Because security groups are stateful and apply to the instance directly, swapping in one with no rules halts essentially all new traffic.

Some teams keep a pre-made forensic isolation security group ready so containment is a single API call.

Before changing anything else, capture state. Take an EBS (Elastic Block Store) snapshot of every attached volume to freeze the disk.

If your tooling supports it, dump the instance memory too, since malware often lives only in RAM. These artifacts become the immutable evidence your investigation works from.

Tag the isolated instance and its snapshots clearly — for example Status=Quarantine — so no one accidentally reuses or terminates them.

Record the timeline: when you detected it, when you isolated it, and what you changed. A clean chain of custody matters if findings ever feed a legal or compliance process.

A compromised instance often carries an IAM role through its instance profile, and the attacker may be using those credentials.

Remove or restrict the role, and use the IAM revoke active sessions action to invalidate temporary credentials already issued. This stops the attacker from pivoting to other services with the instance identity.

For deeper containment you can adjust route tables or a network ACL to cut the subnet off, or move the instance into a dedicated quarantine subnet with no outbound path.

This is heavier-handed than a security group swap but useful when you suspect the attacker controls the instance configuration itself.

Pull the relevant logs before they roll over. CloudTrail shows API calls made with the instance role, VPC Flow Logs show its network connections, and any application logs show on-host behavior.

Centralized logging means this evidence survives even if the instance is later wiped or rebuilt.

Never analyze a suspect disk on a production system. Attach the EBS snapshot copy to a hardened forensic instance in an isolated environment.

Mount the volume read-only so the act of investigating cannot alter the evidence. Work from copies, never the originals.

Manual isolation is slow at 3 a.m. Wire GuardDuty findings to EventBridge and a Lambda function that automatically applies the forensic security group, snapshots volumes, and tags the instance.

Automation shrinks the window an attacker has between detection and containment from minutes to seconds.

Once evidence is captured, prefer to rebuild from a trusted AMI rather than clean the compromised host. You can rarely be fully certain a backdoor is gone.

The isolated instance and its snapshots remain in quarantine for investigation while a fresh, patched instance takes over production duties.

Throughout isolation, keep a precise record: when each action was taken, by whom, and why. CloudTrail captures the API calls, but add human context on top.

This timeline is essential for the post-incident review and for any legal or compliance follow-up, turning a frantic response into defensible, auditable evidence.

Choose the safest containment action.

To isolate a compromised resource, keep it running but cut off the network with a deny-all security group, then snapshot EBS volumes and capture memory before anything changes. Revoke the instance role and its active sessions, tag everything as quarantine, and pull CloudTrail and Flow Logs early. Analyze copies on a read-only forensic instance, automate the steps with EventBridge and Lambda, and rebuild from a trusted AMI rather than repairing.