Key Takeaways
- Public S3 buckets cause major breaches. Monitoring S3 configuration and access is one of the highest-value cloud detections.
- Two layers to watch: bucket configuration (is it public, who can access it) and object access (who read or wrote what).
- Configuration signals come from AWS Config and CloudTrail: a bucket policy or ACL change that makes it public, or block-public-access being disabled.
- Access signals come from S3 server access logs or CloudTrail S3 data events, revealing object reads, writes and bulk downloads.
- Detect data theft by alerting on unusual volumes of object access, access from new identities or IPs, and downloads of sensitive prefixes.
Why S3 Monitoring Is Critical
Amazon S3 holds a huge share of the data organisations keep in AWS: backups, logs, application data, documents and more. That concentration of data, combined with how easy it is to misconfigure access, has made public S3 buckets one of the most common causes of large-scale data leaks. A single bucket accidentally made public can expose millions of records.
Monitoring S3 with Wazuh addresses two distinct risks. The first is exposure: a bucket becoming publicly accessible through a policy or ACL change. The second is data theft: an attacker or insider with access reading or downloading large amounts of data. Covering both configuration and access is what makes S3 monitoring effective, and both feed into Wazuh through AWS logging.
Detecting Public Exposure
The exposure risk is about configuration, and the signals come from AWS Config and CloudTrail. Config flags a bucket as non-compliant when it becomes public or violates a rule, and Wazuh can alert on that compliance change. CloudTrail records the API call that caused it, such as PutBucketPolicy, PutBucketAcl, or disabling S3 Block Public Access, so Wazuh can alert on the action itself and attribute it to an identity.
The highest-value detections here are a bucket transitioning to public, the disabling of account-level or bucket-level Block Public Access, and policy changes that grant broad or cross-account access. Because these are exactly the changes that precede data leaks, they deserve high-severity alerts and immediate review. Pairing the Config state change with the CloudTrail action gives both the what and the who in one investigation.
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 →Tracking Object Access
Configuration monitoring tells you a bucket is exposed; access monitoring tells you whether data was actually taken. There are two sources for object-level activity. S3 server access logging records requests to a bucket (requester, operation, object, response) and delivers them to another S3 bucket that Wazuh reads. CloudTrail S3 data events record object-level API calls (GetObject, PutObject, DeleteObject) with the calling identity, and can be more structured and near real-time.
Either source lets Wazuh see who accessed which objects. Data events via CloudTrail are often preferred for security because they tie access to IAM identities and integrate cleanly with your other CloudTrail monitoring, though they add cost and volume for busy buckets. Server access logs are an alternative with different cost characteristics. Enable object-level logging at least on buckets holding sensitive data, so access to that data is visible.
Detecting Data Theft
With object access flowing into Wazuh, you can detect the patterns of data theft. The clearest is bulk access: a single identity reading or downloading an unusually large number of objects or a large volume of data in a short window, which a frequency or volume rule can catch. This is the signature of someone exfiltrating a bucket, whether an external attacker with stolen credentials or a malicious insider.
Other signals include access from a new or unexpected identity or IP, access to sensitive prefixes by principals that normally never touch them, and access immediately following a suspicious CloudTrail event elsewhere. Correlating S3 access with the credential-compromise signals in CloudTrail is powerful: a stolen key that suddenly reads a sensitive bucket is a high-confidence incident. Prioritise bulk-access and sensitive-prefix detections, as they most directly indicate theft.
Balancing Coverage and Cost
Object-level logging, especially CloudTrail S3 data events on busy buckets, can generate significant volume and cost. You do not have to log every object operation on every bucket. Target the logging at the buckets that hold sensitive or regulated data, where access visibility is worth the cost, and rely on configuration monitoring (cheap and high value) everywhere.
This tiered approach keeps S3 monitoring affordable: Config and CloudTrail management-event monitoring across all buckets to catch exposure, and object-level data-event logging on the sensitive subset to catch theft. In Wazuh, separate what you store from what you alert on as always. The result is strong S3 security coverage without the cost of logging every object access across the entire estate.
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 →S3 in the Wider Cloud SOC
S3 monitoring is strongest as part of the full AWS integration. Exposure detections draw on Config and CloudTrail, access detections draw on data events and access logs, and the real value comes from correlating these with the rest: a public-bucket change tied to the identity that made it, a bulk download tied to a compromised credential, an access pattern tied to a VPC flow anomaly.
Brought into Wazuh alongside CloudTrail, Config, VPC Flow Logs and the other sources, S3 security becomes part of one coherent detection picture rather than a separate concern. Given that S3 exposure and data theft are among the most damaging and common cloud incidents, this coverage is one of the most important pieces of a Wazuh-based cloud SOC.
Frequently Asked Questions
How does Wazuh detect a public S3 bucket?
Through AWS Config and CloudTrail. Config flags a bucket as non-compliant when it becomes public, and Wazuh alerts on that compliance change. CloudTrail records the API call that caused it (PutBucketPolicy, PutBucketAcl, or disabling S3 Block Public Access), so Wazuh can alert on the action and attribute it to an identity. Pairing both gives the what and the who.
How do I monitor who accesses S3 objects with Wazuh?
Enable object-level access logging and send it to Wazuh. Two sources exist: S3 server access logs (delivered to another bucket that Wazuh reads) and CloudTrail S3 data events (object-level API calls like GetObject tied to IAM identities). Data events are often preferred for security because they attribute access to identities and integrate with your other CloudTrail monitoring.
Can Wazuh detect S3 data exfiltration?
Yes. With object access flowing in, Wazuh can detect bulk access, a single identity reading or downloading an unusually large number of objects or volume of data in a short window, which signals exfiltration. It can also alert on access from new identities or IPs and access to sensitive prefixes, and correlate these with CloudTrail credential anomalies for high-confidence incidents.
What is the difference between S3 server access logs and CloudTrail data events?
S3 server access logs record bucket requests and deliver them to another S3 bucket, with different cost characteristics. CloudTrail S3 data events record object-level API calls tied to IAM identities and are more structured and near real-time, integrating with your other CloudTrail monitoring. Data events are generally preferred for security, though they add cost on busy buckets.
How do I control the cost of S3 object logging?
Target object-level logging (especially CloudTrail data events) at buckets holding sensitive or regulated data, where access visibility justifies the cost, and rely on cheaper configuration monitoring (Config and CloudTrail management events) across all buckets to catch exposure. In Wazuh, separate storage from alerting so you keep history without alerting on routine access.
Can Codesecure set up S3 security monitoring in our Wazuh?
Yes. Codesecure configures S3 exposure detection via Config and CloudTrail, object-access monitoring via data events or access logs on sensitive buckets, and data-theft detections correlated with credential-compromise signals. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
Never Let An S3 Bucket Leak Go Unnoticed
Codesecure builds S3 security monitoring in Wazuh for public-exposure changes and object-level data theft, correlated with CloudTrail credential signals so a bulk download ties straight to the identity behind it. Delivered by named OSCP, CEH and CISSP consultants.
