Key Takeaways
- CloudTrail records every AWS API call, making it the foundation of cloud detection. If you monitor one AWS source, monitor this.
- CloudTrail writes to S3, and Wazuh collects it with the aws-s3 module, decoding each event into fields like eventName, userIdentity, sourceIP and region.
- Top detections: root account usage, IAM policy and key changes, disabling of CloudTrail or GuardDuty, and unauthorised or denied API calls.
- Credential compromise shows up here: API calls from new regions or IPs, reconnaissance bursts, and privilege escalation sequences.
- Map to MITRE ATT&CK for a coverage view of cloud techniques across persistence, privilege escalation and defence evasion.
Why CloudTrail Is the Foundation
AWS CloudTrail records the control-plane activity of your account: who did what, when, from where, and whether it succeeded. Every console action and API call, from launching an instance to changing an IAM policy to deleting a bucket, produces a CloudTrail event. This makes CloudTrail the authoritative record of what happens in AWS and the single most important source for detecting cloud attacks.
Because almost every cloud attack technique involves AWS API calls, CloudTrail is where you see them: an attacker using stolen credentials, escalating privileges, disabling security controls or exfiltrating data all leave CloudTrail events. Monitoring CloudTrail with Wazuh turns that record into real-time detection instead of a log you only read after an incident.
Sending CloudTrail to Wazuh
CloudTrail delivers its logs to an S3 bucket. The integration is therefore straightforward: configure a trail (ideally an organisation trail covering all accounts and regions) to write to an S3 bucket, then configure the Wazuh AWS module to read that bucket with the cloudtrail log type. Wazuh polls the bucket, pulls new log objects, decompresses and parses them, and applies rules.
Wazuh decodes CloudTrail events into structured fields, including the eventName (the API action), userIdentity (who made the call, including whether it was the root user, an IAM user or an assumed role), sourceIPAddress, awsRegion, and the error code if the call was denied. These fields are what detection rules match on. Use least-privilege read-only credentials scoped to the trail bucket, and for multi-account setups read from the central logging account.
Need Your AWS Connected to Wazuh?
Codesecure specialises in Wazuh cloud monitoring: CloudTrail, CloudWatch, Config, VPC Flow Logs, S3, EC2, RDS and MongoDB Atlas, wired into one SOC with least-privilege IAM and tuned detections. ISO/IEC 27001:2022 certified delivery, named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
See Cloud SOC Services →The Core CloudTrail Detections
A handful of detections cover the highest-risk cloud activity. Root account usage is near the top: the root user should almost never be used day to day, so any root API activity or console login deserves an alert. IAM changes are next, creating users, attaching policies, creating access keys, or modifying roles can all indicate privilege escalation or persistence, so alert on sensitive IAM write actions.
Disabling security controls is a classic defence-evasion move: StopLogging on CloudTrail, deleting a trail, disabling GuardDuty or Config, or changing a bucket policy on the log bucket should all alert loudly, because an attacker often tries to blind monitoring first. Unauthorised and denied calls (AccessDenied errors) in volume can indicate reconnaissance or an attacker probing what a stolen credential can do.
Detecting Compromised Credentials
Stolen AWS access keys are one of the most common cloud incidents, and CloudTrail is where they are caught. When a credential is used by an attacker, the pattern often differs from normal use: API calls from a new source IP or region, activity at unusual hours, or a sudden burst of reconnaissance calls (ListBuckets, DescribeInstances, ListUsers, GetAccountAuthorizationDetails) as the attacker maps what the credential can access.
Wazuh can detect these patterns with rules that flag API activity from unexpected regions, correlate reconnaissance bursts, and watch for the escalation sequence that follows, such as creating new keys or roles. Enriching CloudTrail events with threat intelligence (matching source IPs against known-bad lists) adds another signal. The combination catches credential misuse early, often before the attacker has established persistence or reached data.
Tuning Out the Noise
CloudTrail is high volume, and much of it is routine automation: CI/CD pipelines, auto-scaling, infrastructure-as-code runs and AWS services calling each other. Without tuning, these generate constant events that resemble the actions you want to detect. The key is to baseline normal automation and build allowlists for known service roles, pipeline identities and expected regions.
Focus alerting on sensitive actions by human or unexpected identities rather than all occurrences of an action. For example, IAM changes by your Terraform role during a deploy window are expected, while the same change by an unknown assumed role at 3am is not. Separate what you store (keep all CloudTrail for forensics and compliance) from what you alert on (the sensitive, anomalous subset). This keeps CloudTrail monitoring precise instead of a wall of noise.
Cloud Logs Flowing But No Detections?
Collecting CloudTrail or VPC Flow Logs is only step one. Our SOC lead will review your AWS log coverage and detection gaps on a 30-minute free scoping call. No obligation, no slideware.
Book a Free Scoping Call →Measuring Coverage with ATT&CK
Map your CloudTrail detections to MITRE ATT&CK for cloud so you can measure what you cover. Root usage and new credentials relate to persistence and privilege escalation; disabling CloudTrail or GuardDuty is defence evasion (impair defences); reconnaissance calls map to discovery techniques; and unusual data access maps to collection and exfiltration. Tagging rules with technique IDs builds a coverage view.
This makes CloudTrail monitoring a measurable programme rather than a set of ad-hoc rules. You can show which cloud attack techniques you detect, prioritise the gaps, and validate detections during cloud purple-team exercises. Combined with the other AWS sources in this series, CloudTrail anchors a coverage map across the whole account.
Frequently Asked Questions
How do I send AWS CloudTrail logs to Wazuh?
Configure a CloudTrail trail (ideally an organisation trail across all accounts and regions) to deliver logs to an S3 bucket, then configure the Wazuh AWS module to read that bucket with the cloudtrail log type. Wazuh polls the bucket, parses each event into structured fields and applies detection rules. Use least-privilege read-only credentials scoped to the trail bucket.
What are the most important CloudTrail detections?
Root account usage, sensitive IAM changes (new users, access keys, policy attachments, role changes), disabling of security controls (StopLogging, deleting a trail, disabling GuardDuty or Config), and unauthorised or denied API calls in volume. These cover privilege escalation, persistence, defence evasion and reconnaissance, which are the core cloud attack techniques.
Can Wazuh detect compromised AWS access keys?
Yes. Compromised keys often show up in CloudTrail as API calls from a new source IP or region, activity at unusual hours, or a burst of reconnaissance calls like ListBuckets and ListUsers. Wazuh rules can flag activity from unexpected regions, correlate reconnaissance bursts and watch for the privilege-escalation sequence that follows, catching misuse early.
Why should I alert when CloudTrail logging is disabled?
Because disabling logging is a classic defence-evasion move. Attackers often try to blind monitoring before acting, using StopLogging, deleting the trail, or disabling GuardDuty and Config. An event that stops or deletes logging is therefore both high-signal and urgent, and should trigger a loud alert and immediate investigation.
How do I reduce CloudTrail alert noise?
CloudTrail is high volume and much of it is routine automation (CI/CD, auto-scaling, infrastructure-as-code). Baseline normal automation, build allowlists for known service roles, pipeline identities and expected regions, and alert on sensitive actions by human or unexpected identities rather than every occurrence. Store all CloudTrail for forensics but alert only on the anomalous subset.
Can Codesecure set up CloudTrail monitoring in our Wazuh?
Yes. Codesecure configures CloudTrail collection into Wazuh and builds tuned detections for root usage, IAM abuse, disabled logging, credential compromise and reconnaissance, mapped to MITRE ATT&CK. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
Catch AWS Credential Abuse In The Audit Trail
Codesecure builds CloudTrail detections in Wazuh for root usage, IAM privilege escalation, disabled logging and compromised keys, tuned against your automation and mapped to MITRE ATT&CK. Delivered by named OSCP, CEH and CISSP consultants.
