AWS Cloud Account Compromise Detection: CloudTrail Indicators, GuardDuty Findings, and First-Response Triage
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AWS account compromise typically becomes visible within minutes in CloudTrail and GuardDuty, but only if the alerting was configured before the incident. Organizations that review CloudTrail during an investigation often find clear compromise indicators — root account login, new IAM user creation, API calls from Tor exit nodes — that occurred hours or days before discovery, while the attacker exfiltrated data and established persistence unchallenged.
The detection architecture is straightforward: CloudWatch metric filters on the highest-signal CloudTrail events, GuardDuty enabled in all regions and all accounts, and Security Hub aggregating findings from both. The response is faster and the damage is contained when the detection was built before the attacker arrived.
Pre-incident detection: alerts that must exist before compromise
The five CloudWatch metric filter alarms that cover the most common AWS account compromise scenarios can be built in under an hour and provide near-real-time alerting on the highest-signal events. Root account usage, IAM user and access key creation, CloudTrail and GuardDuty disablement, and console logins from blocked geographic locations each require a distinct filter pattern on the organization-level CloudTrail log group. This section covers the exact filter syntax, alarm thresholds, and SNS notification setup for each alarm, plus the GuardDuty Organizations configuration that extends coverage to unused regions without requiring manual per-region enablement.
Build the five CloudWatch alarms that cover the most common account compromise indicators
Create these five CloudWatch metric filters and alarms on the organization-level CloudTrail log group: (1) Root account usage — filter for userIdentity.type = Root, (2) IAM user creation — filter for eventName = CreateUser, (3) IAM access key creation outside change windows — filter for eventName = CreateAccessKey with time-of-day condition, (4) CloudTrail or GuardDuty disablement — filter for eventName = StopLogging OR DeleteTrail OR DeleteDetectors, and (5) Console login from blocked countries — filter for ConsoleLogin events with sourceIPAddress matching a geographic block list. Configure each alarm to send to an SNS topic that notifies the security team via email and optionally PagerDuty or Slack integration for immediate visibility. These five alarms cover the indicators that appear in most AWS account compromise scenarios.
Enable GuardDuty in all regions and accounts using Organizations integration before you need it
Enable GuardDuty via AWS Organizations to automatically extend coverage to all member accounts and all regions, including regions where you currently have no workloads. Attackers who compromise credentials specifically operate in low-monitoring regions such as ap-northeast-3 or eu-north-1 because organizations rarely have GuardDuty enabled there. The additional cost of enabling GuardDuty in unused regions is minimal (no actual traffic means minimal log analysis volume), and it closes a detection gap that attackers actively exploit. Configure findings from all regions to aggregate into a central Security Hub account so that a single console view shows all GuardDuty findings across all accounts and regions rather than requiring manual review per account per region.
Triage and containment: structured response to active compromise
The 60-minute triage window for active AWS account compromise has a specific sequence designed to preserve evidence while containing the damage. Revoking the compromised credential is not the first action because doing so before inventorying attacker-created resources leaves backdoors in place that survive the credential rotation. The correct sequence starts with cross-region resource enumeration, followed by credential rotation, and concludes with data exfiltration scope assessment. This section covers the AWS CLI commands for cross-region backdoor discovery and the CloudTrail log preservation steps that keep evidence intact even if the attacker attempted to delete it.
Investigate all regions for attacker-created resources before revoking the compromised credential
Before disabling or rotating the compromised credential, complete a cross-region inventory of resources created by that principal so you know the full scope of attacker activity. Revoking the credential stops ongoing access but does not remove EC2 instances, Lambda functions, or new IAM users that the attacker created as backdoors. Run AWS CLI commands against every region to list EC2 instances, Lambda functions, IAM users, and access keys created within the suspected compromise window and owned by or launched by the compromised principal. Resources created in unusual regions are the most likely persistence mechanisms — terminate them after documenting them as evidence.
Send CloudTrail logs to a separate logging account to preserve evidence during containment
CloudTrail logs sent to an S3 bucket in the same AWS account as the compromise can be deleted or modified by an attacker with sufficient permissions. Configure CloudTrail to deliver logs to an S3 bucket in a separate, dedicated logging account where the member account's credentials have no write or delete permissions. This is an AWS security best practice that applies before any incident occurs: the logging account's bucket policy should deny all delete actions from the member account while allowing PutObject for CloudTrail log delivery. During a compromise investigation, the historical CloudTrail logs in the logging account remain intact even if the attacker deleted the trail or modified logs in the member account.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
AWS account compromise is detectable in near-real-time if the alerting infrastructure was built before the incident. Root account login, new IAM user creation, API calls from threat-listed IPs, and CloudTrail disablement attempts are all visible in CloudTrail within minutes and covered by GuardDuty findings automatically. The five CloudWatch metric filter alarms for the highest-signal indicators, GuardDuty enabled in all regions and all accounts via Organizations integration, and CloudTrail logs delivered to a separate logging account that the compromised account cannot delete provide the detection and evidence preservation foundation. When an alert fires, the 60-minute triage sequence covers scope investigation, backdoor identification, credential rotation, and data exfiltration assessment before the attacker can complete their objectives.
Frequently asked questions
What are the early warning signs of AWS account compromise?
Early warning signs of AWS account compromise visible in CloudTrail include: root account console login (ConsoleLogin with userIdentity.type of Root), creation of new IAM users or access keys by accounts that do not routinely create IAM resources, API calls from geographic regions where your organization does not operate, API calls from IP addresses not associated with your corporate network or expected cloud environments, a spike in Describe and List API calls indicating reconnaissance (GetBucketAcl, ListBuckets, DescribeInstances across many services in a short time window), and EC2 instance launches or Lambda function creation in unused regions. GuardDuty automatically detects many of these patterns and generates findings that appear in the GuardDuty console and can be forwarded to Security Hub and your SIEM.
How do I set up CloudWatch alerts for AWS root account usage?
Create a CloudWatch metric filter on the CloudTrail log group that matches root account activity. The filter pattern is: { ($.userIdentity.type = Root) && ($.userIdentity.invokedBy NOT EXISTS) && ($.eventType != AwsServiceEvent) }. Create a metric from this filter, then create a CloudWatch alarm that triggers when the metric sum is greater than or equal to 1 within a 5-minute period. Configure an SNS topic as the alarm action with email and optionally SMS notifications to the security team. This alarm fires within 5 minutes of any root account activity including console login, API call, or password change, providing near-real-time notification of root credential use which is almost always either a legitimate emergency access (respond and confirm) or a compromise indicator (respond immediately).
What GuardDuty finding types indicate active account compromise?
GuardDuty finding types that indicate active account compromise rather than misconfiguration: UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B (console login from Tor exit node), UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom (API call from threat-intelligence-listed IP), UnauthorizedAccess:IAMUser/MaliciousIPCaller (API call from AWS-maintained malicious IP list), Recon:IAMUser/MaliciousIPCaller (reconnaissance API calls from suspicious IP), Policy:IAMUser/RootCredentialUsage (root credential usage), Persistence:IAMUser/UserCreated (IAM user created suggesting persistence establishment), and CryptoCurrency:EC2/BitcoinTool.B (EC2 instance making cryptocurrency mining connections indicating compromised compute). Treat all High severity GuardDuty findings as requiring same-day investigation.
How do I detect data exfiltration from S3 in AWS CloudTrail?
S3 data exfiltration indicators in CloudTrail include: a spike in GetObject API calls on buckets containing sensitive data from an IP address not associated with the application that normally accesses the bucket, GetObject calls outside of normal business hours from the expected source IP, ListBuckets calls from a principal that does not normally access S3 (indicating reconnaissance), and GetBucketAcl or GetBucketPolicy calls indicating bucket configuration reconnaissance. Enable S3 data event logging in CloudTrail (which logs individual GetObject and PutObject calls per object) for buckets containing sensitive data — data events are not logged by default because of the volume. Create CloudWatch metric filters for GetObject calls from unexpected principals on the monitored buckets.
What should I do in the first 60 minutes of suspected AWS account compromise?
The first 60 minutes of AWS account compromise response: Minutes 1-10: open CloudTrail in the AWS console, filter the last 2 hours of events by the suspected compromised principal ARN to understand what actions were taken. Check GuardDuty for active findings against the same principal. Minutes 10-20: identify any IAM users, access keys, or roles created by the compromised principal (CreateUser, CreateAccessKey, CreateRole events) — these are backdoors that must be removed as part of containment. Minutes 20-30: rotate the compromised credential by disabling the access key or resetting the IAM user password. If the root account is compromised, change the root password and verify MFA is enforced. Minutes 30-45: review EC2 instances, Lambda functions, and other resources created by the compromised principal in all regions. Terminate unauthorized compute resources that represent attacker persistence. Minutes 45-60: assess whether data exfiltration occurred by reviewing S3 access logs for the compromised principal and estimating the scope of data accessed.
How do I detect if an attacker is trying to disable CloudTrail or GuardDuty to cover their tracks?
Attackers who gain console or API access frequently attempt to disable security controls to prevent detection. CloudTrail logs StopLogging, DeleteTrail, and UpdateTrail events when CloudTrail is modified. GuardDuty logs DisassociateDetectors and DeleteDetectors events when GuardDuty is disabled. Create CloudWatch alarms specifically for these events: a metric filter matching StopLogging or DeleteTrail events should trigger an immediate critical alert because disabling CloudTrail means subsequent attacker activity will not be logged. AWS Security Hub includes security standard checks that alert when CloudTrail is disabled. Enable CloudTrail log file validation (which detects log file deletion and modification) and send CloudTrail logs to an S3 bucket in a separate, hardened logging account where the compromised account's credentials cannot delete the historical log records.
How do I enable GuardDuty across all AWS accounts and regions to prevent blind spots?
Enable GuardDuty in all AWS regions across all accounts in your organization using AWS Organizations integration. In the management account or a designated security account, configure GuardDuty with Organizations to automatically enable GuardDuty in all member accounts and all new accounts created in the future. Enable GuardDuty in all available regions, not just the regions where you run workloads — attackers who compromise credentials frequently operate in unused regions specifically because monitoring coverage there is lower. Configure GuardDuty finding aggregation to a central security account using cross-account finding sharing so all findings across all accounts appear in a single GuardDuty console. Forward findings to Security Hub and your SIEM for correlation with CloudTrail and other log sources.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.