A key appears in a commit, a laptop goes missing, or a billing alert fires at three in the morning. What matters is having a sequence decided in advance, because judgement under time pressure is unreliable.
The order of operations
- Contain. Deactivate the suspected credential. Deactivate rather than delete, so the audit trail stays intact.
- Assess. Check the audit log for what that credential did, and when the behaviour changed.
- Expand. Look for identities, keys or rules created during the window; attackers establish persistence quickly.
- Eradicate. Remove anything unauthorised and rotate every credential that could have been exposed.
- Recover. Restore intended configuration, confirm workloads are healthy.
- Review. Write down what happened and what would have caught it sooner.
What to look for in the logs
| Indicator | Why it matters |
|---|---|
| New identities or access keys | The usual persistence mechanism. |
| Permission or policy changes | Privilege escalation. |
| Compute started in unused regions | Frequently mining; watch the bill. |
| Security group opened widely | Preparing external access. |
| Logging disabled or retention shortened | Covering tracks. Treat as serious. |
| Large egress or snapshot sharing | Possible data exfiltration. |
Do not skip the billing check
Cost is often the clearest evidence of what was actually run, and in what region. Compare the daily spend across the suspected window; an unfamiliar service or region appearing in the breakdown narrows the search quickly.
Prepare while nothing is wrong
- Know where the audit logs are and how to query them.
- Keep an inventory of credentials and what each one can reach.
- Have a break-glass administrative path that does not depend on the compromised one.
- Know how to reach the provider’s support and abuse channels.
- Write the runbook down and rehearse it once.
Summary
Contain, assess, expand the search, eradicate, recover, review. Keep logs the account cannot edit, rotate generously, and write the runbook before you need it.
