AWS Security Specialty (SCS-C03): Stolen Instance Credentials at 02:14 - Contain, Preserve, Prevent Recurrence

Stolen Instance Credentials at 02:14 - Contain, Preserve, Prevent Recurrence

At 02:14 UTC, GuardDuty raises UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS for role web-app-role, used by instance i-0a1b2c3d in account 111122223333 (us-east-1). The instance sits behind an ALB in an Auto Scaling group (min 4, max 12) launched from a launch template. It has no SSM agent and no EDR; egress to 0.0.0.0/0 is permitted so user-data can install packages. VPC flow logs are off; CloudTrail records management events only. The role's maximum session duration is 12 hours and the credentials were issued 40 minutes ago. The CISO requires three things: credential abuse stopped within 15 minutes, forensic evidence preserved, and no disruption to the other eleven instances. Nobody on the team has performed an EC2 forensic capture before, and there is no separate forensics account or budget to build one today.

1. What is the fastest effective action to stop the attacker's use of the stolen credentials, and why is quarantining the instance's security group not that action?

Read the worked answer

Quarantining the instance does not touch the attacker at all. The finding says the credentials are being used from outside AWS, so the attacker never traverses the instance's security group or subnet. Isolation protects the instance and preserves its network state; it does not revoke anything.

What actually works, in this order:

Attach an explicit-deny inline policy to web-app-role that denies * on *, with a condition on aws:TokenIssueTime earlier than now (or earlier than a recorded timestamp you take first). Role policy is evaluated for every existing session, including sessions the attacker already holds, so this takes effect in seconds and cannot be bypassed by continuing to use issued keys. This is the AWS-documented way to revoke temporary credentials.
Detach the role from the instance profile so the instance stops vending new credentials. This alone is insufficient: already-issued credentials stay valid until they expire (up to the 12-hour maximum session duration here).
Keep the deny policy narrow in effect by exempting only what you truly need (e.g. ssm:* if SSM were present). Here it is not, so deny-all is acceptable because the instance is about to be quarantined anyway.

Sequencing matters: capture the credential issue time first if you want to scope the deny condition, but do not spend more than a minute on it - deny-all is acceptable and reversible once containment is confirmed.

2. Describe how you preserve evidence from this instance given that there is no EDR and no SSM, and state explicitly what evidence you will lose.

Read the worked answer

You are doing disk and metadata forensics, not memory forensics, and you should say so in the incident record rather than pretend otherwise.

Sequence:

Freeze the ASG relationship first - suspend Launch, Terminate, ReplaceUnhealthy, and HealthCheck processes, or put the instance into Standby. Otherwise a failed health check during your capture causes the ASG to terminate the instance and delete the volumes mid-snapshot.
Enable termination protection on the instance.
Snapshot every EBS volume attached to the instance and tag the snapshots with case ID, instance ID, and timestamp. Snapshots are crash-consistent, not application-consistent - acceptable for a triage case.
Do not mount the snapshot in place of the source. Create volumes from the snapshots and attach them read-only to a dedicated analysis instance in a controlled security group; if you must work from the original volume, use dd with a hash (SHA-256) before and after to demonstrate integrity.
Export and preserve instance metadata - describe-instances output, user-data (a common persistence location), tags, and the instance profile contents, saved to the log-archive account's S3 bucket with Object Lock.

What you lose: volatile memory - running processes, injected code, in-memory keys. Without an agent you cannot capture RAM, so respond quickly and note the gap. Also turn on VPC flow logs now for the subnet - they will not show the exfiltration that already happened, but they will capture any lateral movement from this point forward.

3. The ASG is the reason one compromised instance becomes twelve. What specifically must change before the AMI or launch template is reused, and in what order?

Read the worked answer

The launch template carries two hazards: the same web-app-role and the same unpatched AMI. If you scale, the ASG immediately creates a fresh instance with the same over-privileged identity and the same exploitable software.

Order of operations:

Block the blast radius before anything else: suspend the ASG's launch process (done in the previous step) so no replacement can appear while you work.
Triage for lateral movement: check CloudTrail for every API call made by web-app-role since 40 minutes before the finding - sts:GetCallerIdentity from odd user agents, iam:CreateUser, s3:PutBucketPolicy, ec2:RunInstances, and cross-account calls. Assume anything that role could do, was done, until proven otherwise. The role's real blast radius - not the instance - is the scope of the incident.
Rebuild the identity: new role with only the permissions the app demonstrably needs (S3 prefix-scoped, no iam:*, no ec2:*), instance metadata service set to IMDSv2 required with hop limit 1 so an SSRF in the app can no longer reach credentials.
Fix the network: replace the 0.0.0.0/0 egress with the minimum (package repositories via a VPC interface endpoint, or a proxy), which removes the exfiltration path entirely.
Only then patch the AMI, publish a new launch template version, and resume scaling with a canary of one instance.

The exam-relevant point is ordering: identity and egress flaws are what made this an incident; the instance is just where it surfaced.