Crypto-mining in account 47 at 02:14
Corvus Payment Services is a PCI DSS Level 1 acquirer running 90 AWS accounts under Organizations, with an organization trail delivered to a dedicated log-archive account, GuardDuty enabled everywhere, and Security Hub aggregated into the security account. CloudTrail object retention in S3 is one year; CloudWatch Logs retention is 90 days. The SIRT is four engineers with no 24/7 rota. At 02:14 on a Saturday, GuardDuty raises CryptoCurrency:EC2/BitcoinTool.B!DNS in account 47. Three EC2 instances are mining, launched using an IAM role belonging to a CI runner whose access key sits in a build script. That principal has also called GetSecretValue in the same account. Corvus's acquirer agreement requires notification within 24 hours of a confirmed incident affecting cardholder data; state law allows 30 days; some cardholder data belongs to EU residents, so GDPR may apply.
1. What is the order of operations in the first six hours, and what must be captured before any instance is terminated?
Read the worked answer
Order: identity first, then network, then host. The CI role is the actor; the instances are effects. Disabling the access key and revoking sessions stops new instances and new API calls immediately, and is reversible, unlike deletion. Then isolate the instances - replace their security groups with a quarantine group allowing no ingress or egress, or move them to a quarantine subnet. Do not stop or terminate: stopping destroys memory and termination destroys the disk.
Capture before containment closes the door.
- EBS snapshots of all three instances and any attached volumes, tagged to the case number.
- Memory capture if the tooling is already deployed and fast enough - it must be attempted before isolation, so decide the sequence deliberately rather than discovering the conflict at 03:00.
- CloudTrail events for the CI principal across all regions, since credential misuse often starts in an unused region.
- VPC flow logs, Route 53 Resolver query logs, GuardDuty findings, and the IAM credential report.
- CI build logs and repository history for the build script containing the key.
- Evidence of which secrets
GetSecretValuereturned and when - that determines the notification analysis later, and it must be recorded before those secrets are rotated.
Rotate the exposed secrets after recording them, not before. Copy all artifacts into the log-archive account; an attacker with a foothold in account 47 may reach anything 47 can write to.
2. Walk the notification decision tree - 24 hours, 72 hours, 30 days - and explain where security's role stops and legal's begins.
Read the worked answer
First question: was cardholder data actually accessed? Scope from evidence, not assumption: did the CI principal retrieve database or storage credentials from Secrets Manager, did network egress show data leaving, did any call touch the CDE? The answer determines which clocks matter.
Acquirer contract - 24 hours from confirmation. Contract clocks usually run from confirmation, not from the GuardDuty alert, but do not gamble on a favourable reading. Send an initial notification with known unknowns and commit to updates; a late notice is a contractual breach independent of whether data left.
GDPR - 72 hours from awareness. Awareness means a reasonable degree of certainty that a personal-data breach occurred, not completed forensics. If EU cardholder data was plausibly exposed, notify the supervisory authority within 72 hours with what is known, and supplement. Article 33 does not require certainty, and waiting for certainty is the classic failure.
State law - 30 days. Tighter in several jurisdictions, and encryption safe harbour may apply if data was encrypted and the key was not compromised - verify against the KMS grant actually used rather than assuming.
Division of labour. Security establishes facts: what was accessed, what was encrypted, which subjects are implicated, whether exfiltration occurred. Legal and privacy decide whether the facts cross a statutory or contractual threshold, and who signs. Security should never make that determination alone, and should never sit on findings while waiting for a legal opinion - run both in parallel and document who decided what, when, and on what evidence.
3. Post-incident, what changes to detection, containment and CI identity would you make, and how do you prove they work?
Read the worked answer
Detection. GuardDuty worked; the response did not. Automated containment for high-confidence finding families: an EventBridge rule invoking Lambda or SSM Automation to attach a quarantine security group, disable the implicated key, tag the resource and open a ticket. Require human approval only where automation could disrupt a production service, and let everything else run unattended overnight.
Retention and integrity. Ninety days of CloudWatch is acceptable only if the one-year S3 trail is immutable - S3 Object Lock in compliance mode on the log-archive bucket, plus an SCP denying s3:DeleteObject and cloudtrail:StopLogging even to account administrators. An attacker's first move is often log deletion, and an organization trail nobody can delete is worth more than a longer retention period.
CI identity. OIDC federation with a per-repository, per-environment role; no static keys in build scripts; an SCP denying secretsmanager:GetSecretValue to CI roles except named secrets. Back it with secrets-scanning push protection and automated revocation.
Prove it works. Quarterly purple-team exercises that execute the actual playbook against a sandbox account at an odd hour, not a tabletop discussion. Measure MTTD and MTTC per exercise, verify the canary evidence appears in the archive account, and confirm that log deletion genuinely fails. If the playbook has never run at 02:00 with four people, it is a hypothesis, not a capability.