The attacker tried to hide activity by StopLogging at 09:15, but traces persisted across multiple layers, including GuardDuty (IAMUser/CloudTrailLoggingDisabled), VPC Flow Logs, and CloudTrail log integrity checks, with S3 Object Lock used to prevent tampering.

Initial access occurred at 09:02 through a non-MFA console login from an external IP, followed by quick probing (GetCallerIdentity, ListUsers, ListRoles, ListBuckets) and self-privilege escalation via AttachUserPolicy to grant AdministratorAccess by 09:07.

The investigation checklist calls for verifying MFA usage for ConsoleLogin, inspecting for AttachUserPolicy/PutUserPolicy activity, detecting new users or access keys, checking for external sharing of snapshots/AMIs/buckets, and ensuring log integrity after StopLogging or DeleteTrail.

Data exfiltration involved GetObject of confidential payroll data and sharing snapshots with an external account (ModifySnapshotAttribute), showing several exfiltration paths beyond S3 alone.

A backdoor user and access key were created (CreateUser svc-backup and CreateAccessKey) to maintain access even after password changes, illustrating persistence in cloud environments.

Defensive lessons emphasize MFA at entry, then using SCPs to block StopLogging and DeleteTrail, and employing Access Analyzer to detect external sharing; avoid long-term access keys by using temporary credentials or roles.

The incident narrative describes a 13-minute AWS breach starting from a non-MFA console login by jdoe and rapidly progressing from reconnaissance to privilege escalation, persistence, data exfiltration, and log tampering.

The piece advocates a layered defense where multiple logging and verification mechanisms stay functional even if CloudTrail is stopped, underscoring that traces must exist across separate layers or accounts.