Amazon SCS-C02: Incident Response & Forensics — Study Guide

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Isolation of Compromised EC2 Instances

The first operational objective when an EC2 instance is suspected of compromise is containment without destruction of evidence. Containment on AWS is a layered activity that touches the instance’s network exposure, its lifecycle bindings, and its accessibility to responders.

The canonical isolation sequence starts by tightening the instance’s security group. Because each instance ideally has its own dedicated security group, you can replace the ingress and egress rules with a minimal set that permits only the forensics team (or a dedicated diagnostics security group) to reach it. If the instance sits behind an Application Load Balancer or in a target group, deregister it first; if it is a member of an Auto Scaling group, detach it with the --should-decrement-desired-capacity flag so the ASG does not immediately launch a replacement or, worse, terminate the “unhealthy” instance mid-investigation.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Enabling termination protection is essential because a well-meaning operator, an automation script, or an ASG scale-in event can otherwise destroy the very volumes you are trying to preserve. Termination protection is not a substitute for detaching from the ASG — an ASG can still terminate protected instances during scale-in unless you also remove the instance from the group’s scope.

For subnet-level containment when you need immediate egress cutoff (for example, an instance beaconing to known-malicious IPs), you can add an explicit deny-all outbound rule to the subnet’s network ACL as the first-numbered rule. This is stateless and takes effect instantly on all flows, unlike security group changes that only affect new flows. Once your forensic access path is in place via a diagnostics SG, the NACL deny can be removed so the responder subnet can reach the target through the SG allow-list.

Preserving Volatile and Non-Volatile Evidence

Volatile evidence — process listings, open network sockets, loaded kernel modules, memory contents, tmpfs contents — is destroyed the moment the instance stops. Non-volatile evidence lives on EBS and survives stop/start but can still be lost if volumes are detached or the instance is terminated without snapshots. The rule of order: collect volatile artifacts first while the instance is still running, then snapshot EBS.

Volatile collection should be scripted and executed via SSM Run Command rather than by a human typing at an interactive shell. Run Command records the invocation, the parameters, the executing principal, and the output in CloudWatch Logs or S3, which itself becomes part of the chain-of-custody record.

### Practical Problem: Use-Case Scenario

**Scenario:** Meridian Financial runs its customer-facing web applications in a single AWS account across multiple VPCs, using Auto Scaling groups behind Application Load Balancers, EBS-backed EC2 instances, centralized CloudTrail and CloudWatch logging, GuardDuty, and an S3-based log archive encrypted with KMS. The security operations team uses AWS Systems Manager for remote management and stores backups and snapshots in a designated recovery account.

**Challenge:** One production EC2 instance shows signs of compromise with suspicious outbound traffic and unexpected process activity; the team must isolate the instance and preserve both volatile memory and non-volatile disk evidence for forensic analysis without destroying audit trails.

**Recommended Approach:**
1. Use the Auto Scaling and ELB APIs to detach the instance from target groups and suspend Auto Scaling processes, then apply a restrictive Security Group (deny all inbound/outbound) and update the instance’s Network ACL rules to isolate network access while retaining management via AWS Systems Manager Session Manager.
2. Use AWS Systems Manager Run Command to execute an in-guest memory capture (e.g., LiME) that writes the RAM dump to an attached, encrypted EBS volume or directly to an S3 bucket encrypted with SSE-KMS and S3 Object Lock enabled for retention.
3. Use EC2 CreateSnapshot (or CreateImage) to capture point-in-time EBS snapshots of all attached volumes, then copy those snapshots to a separate AWS account or another region to preserve chain-of-custody and prevent tampering.
4. Enable or retrieve VPC Traffic Mirroring for the instance ENI to collect packet captures to a dedicated monitoring EC2, and concurrently export VPC Flow Logs, ELB access logs, CloudTrail, CloudWatch Logs, and GuardDuty findings to the secure S3 archive.
5. Tag and inventory all collected artifacts in AWS Security Hub or a ticketing system, ensure S3 objects are encrypted and Object Lock is set, and restrict IAM access to a small forensics team while logging all access through CloudTrail.

**Rationale:** Isolating network access before taking images prevents further contamination while using SSM avoids opening new network vectors; capturing volatile memory first and creating immutable EBS snapshots and secure S3 archives preserves evidence integrity and chain-of-custody in line with AWS incident response best practices.

## ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Immediately after volatile capture, snapshot every attached EBS volume. Tag the snapshots with the incident identifier so they are unambiguously tied to the case.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Tag the instance itself with the same incident ticket, the investigator’s name, and a status label such as Quarantine. Consistent metadata tagging is the AWS-native mechanism for chain-of-custody — it is queryable, immutable via IAM condition keys, and appears in every CloudTrail event about the resource.

Live Response with Session Manager and Run Command

A subtle but exam-critical point: existing SSH sessions survive security group rule removal. Security groups are stateful and evaluate rules on connection establishment; an already-established TCP session continues to flow even after the ingress rule that permitted it is deleted. If a responder isolates an instance by stripping SG rules while depending on their own SSH session for access, that session works — until it drops, at which point they are locked out and any bastion or key-based re-entry is now impossible.

The correct pattern is to grant the forensics team access through SSM Session Manager, which does not require any inbound port to be open. Session Manager works over the SSM Agent’s outbound connection to the SSM, EC2 Messages, and SSM Messages endpoints (ideally via VPC interface endpoints so the isolated instance needs no internet route). Attach an instance profile permitting ssm:UpdateInstanceInformation and the messages APIs, and grant responders ssm:StartSession scoped by tag to the quarantined instance.

Because Session Manager sessions are brokered by the SSM control plane, tightening or completely emptying the security group’s ingress does not disturb them, and every keystroke can be logged to S3 or CloudWatch Logs — an auditable interactive session, not a black box.

Cross-Account Recovery of Encrypted Snapshots

Mature environments route forensic snapshots into a dedicated forensics account isolated from the compromised workload account. Sharing snapshots across accounts requires two things: the snapshot must be shared with the target account (modify-snapshot-attribute --create-volume-permission), and if the snapshot is encrypted with a customer-managed KMS key, the KMS key policy must grant the forensics account principals kms:Decrypt, kms:CreateGrant, and kms:DescribeKey. Snapshots encrypted with the AWS-managed aws/ebs key cannot be shared cross-account — you must re-encrypt with a CMK first via a copy operation. In the forensics account, copy the shared snapshot and re-encrypt it under a local forensics CMK so subsequent volume creation does not depend on the source account.

Playbook Design and Minimizing Overhead

Codify the containment steps as an SSM Automation document or Step Functions workflow triggered by GuardDuty or Security Hub findings via EventBridge. A single automation should: (1) capture volatile data via Run Command, (2) snapshot volumes with incident tags, (3) enable termination protection, (4) detach from ASG and deregister from ELB targets, (5) replace the SG with the quarantine SG, and (6) tag the instance with the ticket ID. Keeping the instance running preserves live evidence and enables interactive investigation via Session Manager — powering off should be a deliberate later step, not part of automatic containment, because shutdown zeroes volatile evidence and can trigger cleanup logic embedded in malware.

The traps to internalize: removing SG rules while trusting an existing SSH session leaves the responder blind and gives false confidence in isolation; performing in-place remediation before snapshotting destroys the artifacts that answer how the intrusion happened; and leaving the instance in its ASG or target group invites automated termination or, worse, silent replacement that hides the incident’s scope.

Immediate Containment

When a workload is suspected of compromise, the first decision is whether to isolate it in place or remove it from service. Removing it — stopping or terminating — destroys volatile evidence such as RAM contents, running processes, open sockets, and any malware that lives only in memory. Containment in place is almost always the correct starting move, and it must happen fast enough that an attacker cannot exfiltrate additional data or pivot laterally before controls take effect.

Two AWS-native controls operate at different layers, and the distinction matters. Security groups are stateful and attached to elastic network interfaces (ENIs); network ACLs (NACLs) are stateless and attached to subnets. Replacing an instance’s security groups with a locked-down “quarantine” SG is the surgical approach — it isolates one ENI without disturbing other workloads in the same subnet and preserves the instance’s runtime state. However, security group changes only affect new flows that hit the ENI, and if the compromised instance already holds long-lived outbound connections, existing state can persist. NACL deny rules take effect at the subnet boundary immediately and can shut down traffic even faster when speed matters more than surgical precision — for example, when several instances in the same subnet are implicated, or when an attacker’s active session must be severed instantly. NACLs are also useful when policy prevents modifying an instance directly.

The canonical quarantine SG allows no inbound traffic and outbound traffic only to VPC interface endpoints for com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages, and com.amazonaws.<region>.ec2messages. That preserves Systems Manager Session Manager access while blocking C2 channels, data exfiltration, and lateral movement.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Evidence Preservation Order

Forensic value degrades from most to least volatile, so the order of operations is fixed and non-negotiable:

• Enable termination protection first. Setting DisableApiTermination=true prevents an Auto Scaling event, an operator mistake, or a scheduled action from destroying the instance mid-investigation. Also detach the instance from its Auto Scaling group so ASG health checks cannot replace it.

• Detach or protect from Auto Scaling. Use EnterStandby or detach the instance so the ASG will not terminate it as unhealthy.

• Snapshot every attached EBS volume. CreateSnapshot (or CreateSnapshots for multi-volume atomic capture) produces an immutable, encrypted forensic artifact. Tag snapshots with the incident ID, source instance ID, timestamp, and analyst. Copy snapshots to a dedicated forensics account owned by the security team so they survive account compromise.

• Capture memory. Use an SSM RunCommand document to invoke a memory acquisition tool (LiME, AVML on Linux; WinPMEM on Windows) and stream the image to an S3 forensics bucket with Object Lock in compliance mode. Memory must be captured while the instance is still running — a stopped instance has no RAM to acquire.

• Collect metadata. Record instance ID, AMI, IAM instance profile, VPC/subnet, ENI IDs, tags, running process list, netstat output, and IMDS contents. Tag the instance Status=Quarantined and IncidentId=<id> so downstream automation and human operators recognize its state.

• Only then stop the instance if the investigation requires offline disk analysis. Stopping wipes memory, so this is always the last step.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Automated IR Workflows

GuardDuty findings should trigger containment within seconds, not hours. The canonical pipeline is EventBridge → Lambda → SSM Automation, with SNS for notifications.

An EventBridge rule matches on source: aws.guardduty with a detail-type of GuardDuty Finding and a pattern filtering to EC2-relevant finding types such as UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/*, and CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

The Lambda target extracts the instance ID from detail.resource.instanceDetails.instanceId, then invokes an SSM Automation document (or directly calls the SDK) to: enable termination protection, replace ENI security groups with the quarantine SG via ModifyNetworkInterfaceAttribute, snapshot all attached volumes, tag the instance, and publish an SNS message to the SOC channel. Using SSM Automation rather than raw SDK calls gives step-by-step audit trails in Automation execution history.

Logging for Exfiltration and C2 Analysis

Containment without telemetry is guesswork. VPC Flow Logs must be enabled at the VPC or subnet level with the traffic type set to ALL (both ACCEPT and REJECT). REJECT records reveal scanning, blocked exfil attempts, and C2 beacons trying to reach known-bad IPs; ACCEPT records show which flows succeeded. Route flow logs to CloudWatch Logs for real-time queries and to S3 for long-term retention with Object Lock. CloudTrail with data events on the forensics S3 bucket and KMS provides the audit chain for evidence handling. Combine with DNS query logging (Route 53 Resolver) to catch DGA and DNS tunneling that flow logs alone would miss.

Controlled Forensic Access via Session Manager

Session Manager eliminates the need for SSH keys, bastion hosts, or open port 22/3389, which is precisely why the quarantine SG can block all traditional access. Enable session logging to an S3 bucket with SSE-KMS and to CloudWatch Logs; enforce EnforceEncryption=true in the session preferences so no session runs without TLS and log encryption. IAM policies on ssm:StartSession should be scoped to instances with tag:Status=Quarantined and only granted to the incident response role.

Common Traps and Why They Fail

• Stopping or terminating first. Stopping releases memory, kills active connections, and eliminates the ability to capture volatile artifacts. Terminating additionally releases the root volume unless DeleteOnTermination=false, and even then you lose runtime state. Always contain in place before any power-state change.

• Relying solely on security groups when NACLs are faster. SG changes are surgical but only affect the ENI they are attached to and only govern new flows. When multiple instances in a subnet are implicated, or when an attacker’s existing outbound session must be cut immediately, a subnet-level NACL deny rule closes the door faster because NACLs are stateless and block every packet regardless of prior state.

• Remediating before snapshotting. Reimaging, patching, or replacing the instance before creating EBS snapshots destroys the disk-resident evidence — malware binaries, persistence mechanisms, logs, timestamps. Snapshots are cheap and immutable; take them before any remediation action, and copy them to a dedicated forensics account so a compromised production account cannot delete them.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a multi-account AWS environment with production workloads in a dedicated account: EC2 and EKS services hosting customer data, S3 buckets for archives, centralized logging in a security account with CloudTrail, GuardDuty, Security Hub and Config enabled, and a CI/CD pipeline for deployments. Their operations team uses Systems Manager for patching and maintenance and Route 53/ALBs for public endpoints.

Challenge: A GuardDuty finding and unexpected outbound traffic spikes indicate a likely compromised EC2 instance engaging in data exfiltration and suspicious IAM API calls, requiring immediate containment while preserving forensic evidence and maintaining auditable investigator access.

Recommended Approach:

1. Trigger immediate containment via EventBridge on the GuardDuty finding to invoke a Step Functions workflow that uses a Lambda/SSM Automation to attach a quarantine security group, remove public IPs or detach the ENI, and revoke/rotate implicated IAM credentials via IAM.
2. Preserve volatile and persistent evidence by executing an SSM Automation document to create an EBS snapshot and AMI of the instance, copy snapshots to a dedicated forensics AWS account, and store exported artifacts in an S3 bucket with S3 Object Lock (compliance mode) and KMS encryption.
3. Capture logging for exfiltration and C2 analysis by ensuring CloudTrail management and data events (S3, Lambda) are enabled, forwarding VPC Flow Logs, ALB/NGINX access logs and Route 53 query logs to the central security account, and elevate the finding to Amazon Detective for timeline correlation.
4. Automate orchestration and notifications using EventBridge -> Step Functions -> Lambda to coordinate containment, evidence copy, SNS notifications to incident owners and ticket creation in the existing ITSM system.
5. Provide controlled forensic access by requiring AWS Systems Manager Session Manager for live investigation sessions with session logging to CloudWatch Logs and the forensics S3 bucket, permitted only to a designated forensics IAM role with MFA and temporary credentials.

Rationale: This approach isolates the threat quickly, preserves immutable artifacts and centralized logs for analysis, automates repeatable response steps to reduce time-to-contain, and enforces auditable, least-privilege forensic access via Session Manager per AWS best practices.

← Container · All domains

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →