examhub .cc The most efficient path to the most valuable certifications.
Vol. I
In this note ≈ 24 min

Compromised Resources Forensics Detective

4,720 words · ≈ 24 min read

Overview of Compromised Resources Forensics

Compromised resources forensics is the discipline of containing, capturing, and analyzing AWS workloads that may already be under attacker control, while preserving evidence with chain-of-custody integrity. In the SCS-C02 exam, compromised resources forensics maps directly to Domain 1 task 1.3 — "Respond to compromised resources and workloads" — and pulls in services across Detective, EBS, S3, Athena, Systems Manager, EventBridge, Lambda, and Step Functions. Mastering compromised resources forensics is therefore the single highest-leverage topic in the entire 14% Domain 1 weighting, because nearly every scenario question about compromised resources expects you to choose an answer that both contains the threat and preserves forensic evidence.

The official AWS Security Incident Response Guide frames compromised resources forensics as a five-stage cycle: isolate, collect, analyze, eradicate, recover. SCS-C02 tests every stage. Expect questions that ask which sequence of actions on a compromised EC2 instance both stops attacker lateral movement and keeps memory state intact for forensic analysis. Expect questions that ask how to share an EBS snapshot with a separate forensic account when the source volume is encrypted with a customer managed KMS key. Expect questions about how to query CloudTrail logs in S3 with Athena to determine the blast radius of a stolen IAM credential.

This topic on compromised resources forensics walks through the full lifecycle, with concrete service choices, runbook patterns, and the trap answers that catch most candidates. By the end you should be able to read any compromised resources scenario and immediately recognize whether the question is asking about isolation, collection, analysis, preservation, or automation — and you should know exactly which AWS services solve each phase of compromised resources forensics.

Compromised resources forensics is the disciplined process of containing a suspected-malicious AWS workload, capturing volatile and non-volatile evidence under chain of custody, identifying the root cause via behavior graph analysis and log queries, and preserving artifacts in tamper-proof storage. In AWS, compromised resources forensics combines runbook automation (Lambda, Step Functions, Systems Manager) with evidence services (EBS snapshots, S3 Object Lock) and analysis services (Detective, Athena). Reference: AWS Security Incident Response Guide — Develop Forensic Capabilities.

Why Compromised Resources Forensics Matters for SCS-C02

The SCS-C02 exam guide explicitly enumerates compromised resources forensics skills: isolating EC2 instances, capturing EBS snapshots and memory dumps, conducting root cause analysis with Detective, querying logs in S3 with Athena, and preserving forensic artifacts with S3 Object Lock, isolated forensic accounts, S3 Lifecycle, and replication. Every one of these bullets is a question waiting to be asked. Compromised resources forensics is the only topic in Domain 1 that combines hands-on response runbooks with evidence preservation governance — which is exactly the kind of multi-service synthesis that distinguishes specialty-level exams.

Beyond the exam, compromised resources forensics matters because real attackers do real damage in real time. The longer a compromised EC2 instance keeps its security group, IAM instance profile, and network connectivity, the more credentials it leaks, the more lateral movement it performs, and the more logs the attacker has time to tamper with. Compromised resources forensics is therefore both a technical practice and an operational reflex.

Three patterns dominate SCS-C02 questions on compromised resources forensics:

  1. Isolation before termination — never terminate a compromised EC2 instance before snapshotting EBS and capturing memory; you destroy evidence.
  2. Cross-account snapshot sharing requires KMS grant — encrypted snapshots must have the KMS key shared via key policy or grant before the forensic account can copy them.
  3. S3 Object Lock in compliance mode — for legal-hold forensic artifacts, governance mode is the trap; only compliance mode is truly immutable, even against the root user.

Reference: AWS Security Incident Response Guide — Forensic Investigation.

Phase 1 — Isolation: Containing a Compromised EC2 Instance

The first phase of compromised resources forensics is isolation. The goal of isolation is to stop attacker activity without destroying evidence. The official Amazon EC2 Incident Response runbook pattern lists four isolation actions in order:

  1. Detach the instance from any Auto Scaling group by calling DetachInstances with ShouldDecrementDesiredCapacity=false so ASG doesn't replace it. This prevents ASG health checks from terminating the instance before you can collect evidence.
  2. Replace all attached security groups with a deny-all forensic SG that has no inbound rules and only allows outbound to the forensic collection bucket VPC endpoint and the Systems Manager endpoints. Modifying SG (rather than NACLs) is preferred because SG changes are stateful and immediate, while NACL changes don't drop existing connections.
  3. Remove the IAM instance profile by calling DisassociateIamInstanceProfile. This stops the instance from being able to use stolen role credentials to call AWS APIs from EC2 metadata service. If the attacker already cached the temporary credentials, you must additionally revoke active sessions via an IAM policy with aws:TokenIssueTime condition.
  4. Disable termination protection off (so you can later quarantine) but enable DisableApiTermination=true until you're ready, to prevent accidental destruction.

A common compromised resources forensics trap question gives you four options where one is "Stop the EC2 instance immediately" and another is "Terminate and let ASG replace". Both destroy evidence. Stopping an EBS-backed instance flushes RAM (you lose memory forensics — running processes, decrypted secrets, in-memory malware). Terminating with the default DeleteOnTermination=true for the root volume destroys disk evidence too. Always isolate via SG and IAM detach first, snapshot second, then optionally quarantine. Reference: EC2 Instance Lifecycle.

For instances inside a managed service such as EKS or ECS, the isolation pattern adjusts slightly: cordon the node via kubectl cordon to prevent new pods, drain non-system pods to other nodes, then apply the deny-all SG to the underlying EC2 host. For Lambda compromised resources forensics is different — you can't snapshot a Lambda runtime, so the equivalent is to set the function's reserved concurrency to 0 (effectively disabling invocation) while preserving CloudWatch Logs and X-Ray traces.

Phase 2 — Collection: EBS Snapshots and Memory Dumps

Once the compromised EC2 instance is isolated, collection captures evidence for downstream compromised resources forensics analysis. Two evidence types matter: non-volatile (disk) and volatile (memory).

EBS Snapshot Forensics

EBS snapshot forensics is the foundation of compromised resources forensics. The procedure:

  1. Call CreateSnapshot on every EBS volume attached to the compromised instance, including the root volume. Tag the snapshot with Forensics=true, IncidentID=<id>, SourceInstanceID=<i-xxx>, CapturedAt=<timestamp>.
  2. If the volume is encrypted with a customer managed KMS key, the snapshot inherits that encryption. To copy or share the snapshot to the forensic account, you must either share the KMS key via kms:CreateGrant for the forensic account principal, or re-encrypt the snapshot copy with a forensic account KMS key during the cross-account copy.
  3. Compute a SHA-256 hash of the snapshot block list (using EBS direct APIs ListSnapshotBlocks + GetSnapshotBlock) to establish chain-of-custody integrity. Store the hash in a separate S3 Object Lock bucket alongside the case file.
  4. Mount the snapshot as a new EBS volume in a forensic-only EC2 instance running an analysis toolkit (Volatility, Sleuth Kit, plaso). Always mount read-only to prevent timestamp pollution.

When sharing an EBS snapshot encrypted with a customer managed KMS key to an isolated forensic account, three things must align:

  1. The snapshot's CreateVolumePermission includes the forensic account ID.
  2. The KMS key policy allows the forensic account principal to call kms:Decrypt, kms:CreateGrant, and kms:DescribeKey.
  3. The forensic account's IAM role has matching IAM permissions to use that KMS key.

If any one of these is missing, the forensic account sees KMSKeyNotAccessibleFault. Reference: Share an Amazon EBS Snapshot.

Memory Acquisition via Systems Manager

Memory dump capture is the time-sensitive half of compromised resources forensics — once the instance is stopped or terminated, RAM is gone forever. Use AWS Systems Manager Run Command to invoke the right tool on a live instance:

  • Linux instances: invoke AWS-RunShellScript to install and run LiME (Linux Memory Extractor), output the .lime file directly to an S3 forensic bucket via aws s3 cp. Some teams use AVML (Microsoft's userland Linux memory tool) which is statically linked and doesn't require kernel module compilation.
  • Windows instances: invoke AWS-RunPowerShellScript to run a memory acquisition tool such as DumpIt, Magnet RAM Capture, or Belkasoft Live RAM Capturer, again redirecting the .dmp output to S3.
  • After acquisition, the memory image is analyzed offline with Volatility 3 in the forensic account: vol.py -f memory.lime windows.pslist, linux.bash, linux.malfind, etc.

Compromised resources forensics teams reach for SSM Run Command instead of SSH because:

  1. SSM doesn't require an inbound port (your deny-all SG can stay deny-all; SSM uses outbound HTTPS through VPC endpoints).
  2. Every command and its output is logged in CloudTrail and SSM command history — which is itself forensic evidence.
  3. You don't need to distribute SSH keys, which means no chain-of-custody question about whether the responder modified ~/.ssh/authorized_keys.

Reference: Systems Manager Run Command.

Quarantine vs Terminate

After EBS snapshot and memory dump are safely in S3 with Object Lock, you have a choice: terminate the compromised instance, or migrate it to an isolated forensic VPC for live behavioral analysis. Most organizations terminate because every running compromised instance is a risk surface. Some mature teams quarantine — moving the ENI to a forensic VPC where outbound is null-routed but tcpdump is mirrored via VPC Traffic Mirroring to a Suricata sensor — so they can study live attacker behavior. The exam tends to favor terminate-after-snapshot answers unless the scenario explicitly requires behavioral analysis.

Phase 3 — Analysis: Amazon Detective Behavior Graph

Once evidence is collected, compromised resources forensics moves into root cause analysis. Amazon Detective is the headline AWS service for this phase. Detective automatically ingests three data sources without configuration: VPC Flow Logs, CloudTrail management events, and GuardDuty findings. From these it builds a continuously updated behavior graph that links IAM principals, EC2 instances, IP addresses, and AWS API calls into a navigable timeline.

A behavior graph is a graph database (under the hood, Amazon Neptune) that nodes-and-edges links AWS entities — IAM users, IAM roles, EC2 instances, AWS accounts, IP addresses, finding IDs — based on observed activity in CloudTrail and VPC Flow Logs. Detective updates the graph continuously and lets investigators pivot from a GuardDuty finding to "what else did this IP touch?" or "what else did this IAM role do in the past 30 days?" without writing a single SQL query. Reference: Amazon Detective Behavior Graph.

The Detective investigation workflow during compromised resources forensics:

  1. Open the GuardDuty finding (e.g. UnauthorizedAccess:EC2/SSHBruteForce or CryptoCurrency:EC2/BitcoinTool.B) — Detective adds an "Investigate in Detective" link inline.
  2. Detective opens the finding profile with three timeline panels: API call volume, network volume, and successful login locations. Anomalies are flagged in red.
  3. Pivot to the resource profile for the compromised instance — see every IAM principal that called APIs on this instance, every IP that connected to it, every other instance it talked to.
  4. Pivot to the IP address profile for any suspicious IP — see which other AWS resources in your environment that IP touched. This is how you find the blast radius.
  5. Pivot to the IAM role profile if the attacker stole role credentials — see every API call made with that role, including unusual regions or unusual API actions.

Detective is the single fastest way to answer "what is the blast radius of this compromise?" — a question SCS-C02 loves to ask. Without Detective, you'd write a half-dozen Athena queries by hand and spend hours.

Phase 3b — Athena Queries Over S3 Logs

When compromised resources forensics requires queries Detective can't express — typically time-bounded JOINs across CloudTrail, VPC Flow Logs, S3 access logs, and ALB access logs — Athena is the right tool. The setup pattern:

  1. Centralize all logs in a dedicated security account log archive bucket (the AWS Security Reference Architecture calls this the Log Archive account).
  2. Define AWS Glue Data Catalog tables for each log source. CloudTrail and VPC Flow Logs have official partition projection patterns documented in the Athena CloudTrail integration guide.
  3. Run forensic SQL queries directly in Athena.

Common compromised resources forensics Athena queries:

  • UserIdentity timeline: SELECT eventTime, eventSource, eventName, sourceIPAddress, userAgent FROM cloudtrail WHERE useridentity.arn LIKE '%role/CompromisedRole%' AND eventTime BETWEEN '...' AND '...' ORDER BY eventTime. This reconstructs the attacker's API session.
  • Source IP blast radius: SELECT DISTINCT eventSource, eventName, resources FROM cloudtrail WHERE sourceIPAddress = '1.2.3.4' AND eventTime > '...'. Lists every API call from the attacker IP.
  • VPC Flow Logs lateral movement: SELECT srcaddr, dstaddr, dstport, action FROM vpc_flow_logs WHERE srcaddr = '10.0.1.50' AND action = 'ACCEPT' AND dstport NOT IN (80, 443) — finds unusual east-west traffic from the compromised instance.
  • S3 exfiltration check: SELECT key, requester, bytes_sent FROM s3_access_logs WHERE bucket = 'sensitive-data' AND operation = 'REST.GET.OBJECT' AND bytes_sent > 1000000 AND requester LIKE '%CompromisedRole%'.

For SCS-C02 compromised resources forensics scenarios, internalize this mapping:

  • "Who called what API when" → CloudTrail in S3 + Athena
  • "What network connections did the instance make" → VPC Flow Logs in S3 + Athena
  • "Visualize relationships and pivot interactively" → Amazon Detective
  • "Find findings across multiple security services" → AWS Security Hub
  • "Who accessed which S3 object" → S3 server access logs or CloudTrail data events on S3
  • "What did the attacker run inside the instance" → memory dump (Volatility) + EBS snapshot file system analysis

Reference: Querying CloudTrail Logs with Athena.

Phase 4 — Forensic Artifact Preservation

Preserving forensic artifacts is the part of compromised resources forensics most candidates underestimate, and it's worth roughly two questions on the SCS-C02 exam. The threat model is: an insider with admin privileges, or an attacker who has escalated to admin, must not be able to delete evidence — even with root user credentials. AWS provides four building blocks.

S3 Object Lock — Compliance vs Governance Mode

S3 Object Lock is write-once-read-many (WORM) storage. It comes in two modes:

  • Governance mode: objects can't be deleted by normal users, but principals with s3:BypassGovernanceRetention can override. Useful for operational hold-don't-delete policies, not for legal-grade evidence.
  • Compliance mode: objects cannot be deleted by any user, including the AWS account root user, until the retention period expires. The retention period itself can only be extended, never shortened. This is the only mode that satisfies SEC 17a-4(f), CFTC, FINRA, and most HIPAA/GxP retention requirements.

For compromised resources forensics, always use compliance mode with a retention period at least as long as your incident response policy requires (typically 1, 3, or 7 years).

Multiple SCS-C02 practice questions present a forensics bucket configured with Object Lock governance mode and ask why an internal investigation team complains evidence was tampered with. The answer is "governance mode allows users with s3:BypassGovernanceRetention to delete objects". Compliance mode is the correct choice for legal-grade compromised resources forensics evidence — even AWS Support cannot delete a compliance-locked object before retention expiry. Reference: S3 Object Lock Modes.

Isolated Forensic Account

The forensic account is a separate AWS account in the same Organization but in a dedicated forensic OU. It has these characteristics:

  • Its own forensic KMS keys (so production account compromise doesn't grant access to forensic encryption keys).
  • An SCP applied at the forensic OU that explicitly denies s3:DeleteObject, s3:DeleteBucket, s3:PutBucketLifecycleConfiguration, kms:ScheduleKeyDeletion on forensic resources, even by root.
  • Cross-account IAM roles for read-only access by case-assigned investigators only, gated by MFA and CloudTrail Lake breakglass logging.
  • VPCs with no internet egress, only VPC endpoints to S3 and KMS.

The forensic account is where snapshots get copied to, where memory dumps are landed, where Athena queries run, and where Detective can be enabled as a standalone graph. By the time an attacker reaches your production root, they still don't have any path into the forensic account.

S3 Lifecycle to Glacier Deep Archive

Forensic artifacts are large (multi-TB memory dumps, full EBS snapshot exports) and accessed rarely after the active investigation. S3 Lifecycle policies move objects from S3 Standard to S3 Glacier Deep Archive after 90 or 180 days. Cost drops by ~95%. Object Lock retention continues to apply through storage class transitions — Glacier Deep Archive honors the Object Lock retention timer.

S3 Cross-Region Replication for HA

S3 Cross-Region Replication (CRR) duplicates forensic objects to a second region. With same-account, same-Object-Lock-mode replication, you protect against region-level disasters and against an attacker who somehow corrupts the primary bucket (e.g. by ransoming the KMS key). Configure replication with DeleteMarkerReplication=Disabled so an attempted delete in the source doesn't propagate as a delete marker in the destination.

For specialty-grade compromised resources forensics evidence preservation, layer all four:

  • S3 Object Lock compliance mode — immutability against all principals including root.
  • Isolated forensic account with SCP — prevents cross-account reach.
  • S3 Lifecycle to Glacier Deep Archive — cost-effective long-term retention.
  • S3 Cross-Region Replication — resilience against region failure or targeted ransomware.

Missing any one of these layers is a common SCS-C02 wrong-answer pattern. Reference: Logging Strategies — Building a Multi-Account Logging Architecture.

Phase 5 — Eradication and Recovery

After analysis identifies root cause, eradication removes the attacker foothold:

  • Rotate any credentials the attacker may have touched: IAM access keys, IAM Identity Center session policies, AWS Secrets Manager secrets, SSH host keys, application JWTs.
  • Revoke active IAM role sessions globally with an inline policy condition aws:TokenIssueTime set to the current timestamp on the role's trust policy or attached deny.
  • Patch the vulnerability that allowed initial access — typically via AWS Systems Manager Patch Manager for unpatched OS CVEs, or via deployment pipeline fixes for application-layer flaws.
  • Update detective controls so the same attack pattern is alerted faster next time: new GuardDuty filter, new Security Hub custom insight, new EventBridge rule.

Recovery rebuilds workload from a known-good state:

  • Launch new EC2 instances from a hardened AMI built fresh by EC2 Image Builder — never reuse the compromised AMI even if it "looks clean".
  • Restore application data from a pre-compromise AWS Backup recovery point that's been integrity-validated against the timeline established by Detective.
  • Conduct a post-incident review and update the runbook.

Automation: EventBridge → Step Functions → Lambda

Manual compromised resources forensics is too slow. The mature pattern is fully automated runbook execution. The reference architecture:

  1. GuardDuty generates a finding (e.g. Trojan:EC2/BlackholeTraffic).
  2. The finding flows to EventBridge via the GuardDuty default event bus integration.
  3. An EventBridge rule matches source = aws.guardduty AND detail.severity >= 7 and targets a Step Functions state machine.
  4. The Step Functions state machine orchestrates the runbook stages as discrete states:
    • IsolateInstance (Lambda — calls ModifyInstanceAttribute to swap SG and DisassociateIamInstanceProfile)
    • SnapshotVolumes (Lambda — iterates volumes and calls CreateSnapshot)
    • CaptureMemory (Lambda — invokes SSM SendCommand with the memory dump document, with a Step Functions wait state until the SSM command completes)
    • CopyEvidenceToForensicAccount (Lambda — copies snapshots and S3 objects to the forensic account)
    • NotifySOC (Lambda — posts to SNS, PagerDuty, Slack)
    • OptionallyTerminate (Choice state — only if severity >= 8)

A single Lambda function topping out at 15 minutes can't orchestrate the full compromised resources runbook (memory dump alone can take longer). Step Functions gives you:

  • Per-state retries with exponential backoff and jitter
  • Long-running waits for SSM commands without paying for Lambda idle time
  • Visual state machine view in the console — invaluable during a 3am incident
  • Integrated CloudWatch metrics on success/failure rate per state
  • Express workflows for high-volume low-latency events; Standard workflows for the long-running forensic runbook

Reference: Step Functions for Incident Response.

The runbook itself is stored in version control as a Systems Manager Automation document or a CloudFormation/CDK definition. SCS-C02 expects you to recognize this pattern: GuardDuty → EventBridge → orchestration → Lambda actions, with each Lambda doing one bounded step.

Common Mistakes in Compromised Resources Forensics

Avoid these — each one is a wrong answer pattern on SCS-C02:

  1. Terminating before snapshotting. Destroys evidence. Always isolate, then collect, then terminate.
  2. Modifying NACLs instead of SGs for isolation. NACLs are stateless and don't drop existing connections. SGs do (effectively, by removing all rules).
  3. Sharing encrypted snapshots without sharing the KMS key. Forensic account gets KMSKeyNotAccessibleFault.
  4. Using S3 Object Lock governance mode for legal evidence. Insiders with s3:BypassGovernanceRetention can delete.
  5. Storing forensic artifacts in the same account as the compromise. Attacker root = evidence destruction.
  6. Running memory acquisition over SSH instead of SSM Run Command. Inbound port required, no automatic CloudTrail audit, key distribution overhead.

Reference: AWS Security Incident Response Guide — Common Anti-Patterns.

Service-by-Service Reference for Compromised Resources Forensics

A cheat sheet of every service the SCS-C02 exam will reference under compromised resources forensics:

  • Amazon EC2 — the primary compromised resource. Use ModifyInstanceAttribute for SG, DisassociateIamInstanceProfile, CreateSnapshot, StopInstances/TerminateInstances. EC2 docs.
  • Amazon EBS — disk evidence. CreateSnapshot, cross-account share via ModifySnapshotAttribute. EBS Snapshots docs.
  • AWS KMS — encryption keys for snapshots and forensic S3 buckets. Cross-account access via key policies and grants. KMS Cross-Account Access.
  • AWS Systems Manager — Run Command for memory acquisition, Patch Manager for eradication, Automation for runbooks. SSM docs.
  • Amazon Detective — behavior graph for root cause analysis and blast radius. Detective docs.
  • Amazon Athena — SQL over S3-stored CloudTrail/VPC Flow Logs for custom queries. Athena docs.
  • Amazon S3 Object Lock — WORM storage in compliance mode for forensic evidence. Object Lock docs.
  • AWS Lambda — atomic runbook actions (one task per function). Lambda docs.
  • AWS Step Functions — orchestrates multi-stage compromised resources forensics runbook. Step Functions docs.
  • Amazon EventBridge — routes GuardDuty findings to Step Functions. EventBridge docs.
  • Amazon GuardDuty — generates findings that trigger compromised resources forensics. GuardDuty docs.
  • AWS CloudTrail — primary log source for "who did what" timelines. CloudTrail docs.

Putting It All Together: A Worked Example

Imagine GuardDuty raises a CryptoCurrency:EC2/BitcoinTool.B!DNS finding at severity 8 against i-0abcd1234. The Step Functions runbook fires at 03:14:22 UTC.

03:14:23 — IsolateInstance Lambda detaches i-0abcd1234 from ASG, replaces all SGs with sg-forensic-deny-all, disassociates the IAM instance profile.

03:14:30 — SnapshotVolumes Lambda creates snapshots snap-root and snap-data, tags them with IncidentID=INC-2026-0042.

03:14:45 — CaptureMemory Lambda calls SSM Run Command with AWS-RunShellScript to load LiME and dump RAM to s3://forensic-acct-evidence/INC-2026-0042/memory.lime. The Step Function waits up to 30 minutes.

03:18:11 — Memory dump completes (3.2 GB). The S3 bucket has Object Lock compliance mode set with 7-year retention. SHA-256 hash is computed and stored next to the dump.

03:18:30 — CopyEvidenceToForensicAccount Lambda calls CopySnapshot with the forensic account's KMS key and ModifySnapshotAttribute to grant CreateVolumePermission to the forensic account.

03:18:45 — NotifySOC Lambda posts to PagerDuty. The SOC analyst opens Amazon Detective, pivots from the GuardDuty finding to the resource profile of i-0abcd1234, sees that the IAM role attached to the instance also called iam:CreateAccessKey 18 minutes ago — confirming credential exfiltration.

03:19:02 — Analyst runs Athena query against CloudTrail to enumerate every API call from the new access key — finds three S3 objects downloaded from a sensitive bucket. Now the blast radius is known.

03:25:00 — OptionallyTerminate runs because severity >= 8 and analyst approval was received via Slack-based ChatOps. The instance is terminated. Forensic copies remain in the isolated account, untouchable for 7 years.

The entire compromised resources forensics flow took ~10 minutes, with a complete chain of custody, no human typing during the time-critical phase, and full evidence preservation. This is the gold standard SCS-C02 wants you to recognize.

FAQ

Q1: When responding to a compromised EC2 instance, should I stop or terminate it first to contain the threat?

A: Neither — at least not until evidence is captured. The correct first action in compromised resources forensics is to isolate without changing instance state: replace security groups with deny-all, disassociate the IAM instance profile, and detach from any Auto Scaling group. Stopping flushes RAM and you lose memory forensics. Terminating with default settings deletes the root EBS volume. Snapshot the EBS volumes and capture memory via Systems Manager Run Command first, then optionally terminate or quarantine. Reference: AWS Security Incident Response Guide.

Q2: Why does Amazon Detective need GuardDuty? Can I run Detective standalone?

A: Detective doesn't need GuardDuty findings — it ingests CloudTrail and VPC Flow Logs autonomously and builds the behavior graph regardless. But Detective is most useful when it correlates against GuardDuty findings, because GuardDuty provides the initial signal (the "what triggered the investigation") while Detective provides the context graph (the "what else is connected"). Most production deployments enable GuardDuty, Security Hub, and Detective together. Reference: Detective Behavior Graph.

Q3: What's the difference between S3 Object Lock governance mode and compliance mode for compromised resources forensics?

A: Governance mode lets users with the s3:BypassGovernanceRetention permission delete locked objects — useful for internal hold-and-release workflows, not for legal evidence. Compliance mode is true WORM: no user, including the AWS account root user, can delete or shorten retention until the timer expires. For compromised resources forensics evidence intended to survive insider threat or audit demands, always use compliance mode with a retention period that matches your incident response policy (typically 1, 3, or 7 years). Reference: S3 Object Lock Modes.

Q4: How do I share an encrypted EBS snapshot with my isolated forensic account?

A: Three things must align: (1) call ModifySnapshotAttribute to add the forensic account ID to CreateVolumePermission; (2) update the customer managed KMS key policy to allow the forensic account principal to perform kms:Decrypt, kms:CreateGrant, and kms:DescribeKey; (3) grant matching IAM permissions to the IAM role in the forensic account that will copy the snapshot. If any layer is missing, the forensic account sees KMSKeyNotAccessibleFault. AWS-managed keys (aws/ebs) cannot be shared cross-account — you must use a customer managed key. Reference: Sharing an Encrypted EBS Snapshot.

Q5: When should I use Amazon Athena versus Amazon Detective for compromised resources forensics analysis?

A: Use Detective when you need interactive pivoting across IAM principals, IPs, instances, and findings — its behavior graph is purpose-built for "show me everything connected to this entity in the last 30 days". Use Athena when you need precise SQL over historical logs — for example, time-bounded JOINs across CloudTrail and VPC Flow Logs, or filtering S3 access logs by bytes_sent > 1GB. Detective is faster for relationship discovery; Athena is more flexible for custom queries. Mature compromised resources forensics teams use both: Detective for the first 80% of the investigation, Athena for the last 20% that requires custom SQL. Reference: Querying CloudTrail Logs with Athena.

Q6: How do I automate the compromised resources forensics runbook end to end?

A: The reference architecture is GuardDuty → EventBridge → Step Functions → Lambda. GuardDuty findings flow to EventBridge by default; an EventBridge rule with a severity filter targets a Step Functions Standard workflow; the workflow orchestrates discrete Lambda functions for each runbook stage (isolate, snapshot, memory dump via SSM, cross-account copy, notify SOC, optionally terminate). Step Functions is preferred over a single Lambda because the full runbook (especially memory acquisition via SSM Run Command) takes longer than Lambda's 15-minute limit and benefits from per-state retries, waits, and visual debugging. Reference: Automating Incident Response with Step Functions.

Q7: Why a separate forensic account at all? Can't I just use a separate S3 bucket in the production account?

A: A separate bucket in the same account is not enough because if an attacker reaches the production account root, they can delete the bucket regardless of Object Lock mode by deleting the AWS account itself (after a waiting period). More practically, attackers with admin privileges can disable CloudTrail, modify KMS key policies, and tamper with logs in the production account. An isolated forensic account in a forensic OU with a deny-all SCP for delete operations on forensic resources, plus separate KMS keys, breaks the attacker's ability to destroy evidence even with full production-account compromise. This is the architecture endorsed by the AWS Security Reference Architecture.

Summary

Compromised resources forensics on AWS is a five-phase loop: isolate with security group + IAM detach, collect EBS snapshots and memory dumps via Systems Manager, analyze with Amazon Detective for relationship pivots and Athena for custom SQL, preserve evidence in an isolated forensic account with S3 Object Lock compliance mode, S3 Lifecycle to Glacier Deep Archive, and S3 Cross-Region Replication, and eradicate plus recover by rotating credentials and rebuilding from clean AMIs. Automate the time-critical phases with EventBridge → Step Functions → Lambda so that response begins within seconds of a GuardDuty finding. For SCS-C02, master the trap patterns (no terminate-before-snapshot, no governance mode for legal evidence, no shared encrypted snapshots without KMS grants) and the service mappings, and compromised resources forensics questions become some of the most predictable on the entire exam.

Official sources