AWS S3 Data Exfiltration: Detection Beyond CloudTrail Logs

An attacker with compromised AWS credentials downloads 50GB of customer data from your S3 bucket. You check CloudTrail—but there’s nothing there. CloudTrail doesn’t log GetObject operations by default. Most organizations only enable CloudTrail management events (bucket creation, policy changes), which don’t capture object-level access. Even if you enable S3 data events in CloudTrail, you still won’t see how much data was transferred or download durations.

This is the blind spot security teams discover too late during incident response. To detect S3 data exfiltration, you need S3 Server Access Logging—the native S3 feature that captures every object operation with full transfer details.

The CloudTrail Gap

CloudTrail management events log bucket-level operations:

• CreateBucket, DeleteBucket, PutBucketPolicy
• Does NOT log GetObject, PutObject, DeleteObject

S3 data events - S3 Server Access Logs can log object operations, but here’s what a CloudTrail data event looks like:

{
  "eventVersion": "1.08",
  "eventTime": "2026-02-06T14:23:11Z",
  "eventName": "GetObject",
  "awsRegion": "ap-southeast-2",
  "sourceIPAddress": "203.45.67.89",
  "requestParameters": {
    "bucketName": "customer-data-prod",
    "key": "exports/customers-2026-02.csv"
  },
  "responseElements": null
}

What’s missing from CloudTrail events:

• Bytes transferred: How much data was downloaded?
• HTTP status code: Did the download succeed (200) or fail (403)?
• Transfer duration: Was this a sustained exfiltration or quick reconnaissance?
• Referrer/User-Agent: What tool was used?

Enable S3 Server Access Logging

S3 Server Access Logging records detailed information about every request to your bucket, including bytes transferred, HTTP status codes, and download times. This is your primary data exfiltration detection mechanism.

Enable Server Access Logging

1. Create a dedicated logging bucket first (never log to the same bucket you’re monitoring):
2. From your S3 Bucket in AWS console enable logging

What S3 Server Access Logs Capture

Each log entry includes critical exfiltration indicators:

[06/Feb/2026:14:23:11 +0000] 203.45.67[.]89 arn:aws:iam::123456789012:user/sample-account 3E57427F3EXAMPLE REST.GET.OBJECT exports/customers-2026-02.csv "GET /customer-data-prod/exports/customers-2026-02.csv HTTP/1.1" 200 - 524288000 524288000 142 139 "-" "aws-cli/2.13.5 Python/3.11.2" - ECDHE-RSA-AES128-GCM-SHA256 AuthHeader customer-data-prod.s3.ap-southeast-2.amazonaws.com TLSv1.2 -

Key fields for detection:

• Bytes sent: 524288000 (500MB file downloaded)
• HTTP status: 200 (successful download)
• Total time: 142ms (download duration)
• User-Agent: aws-cli/2.13.5
• Source IP: 203.45.67[.]89

Detection Rule: Large Download Volume

Query S3 access logs to detect exfiltration (Athena SQL example):

SELECT
  remote_ip,
  requester,
  SUM(bytes_sent) / 1024 / 1024 / 1024 AS gb_transferred,
  COUNT(*) AS request_count
FROM s3_access_logs
WHERE
  operation = 'REST.GET.OBJECT'
  AND http_status = 200
  AND request_datetime >= current_timestamp - interval '1' hour
GROUP BY remote_ip, requester
HAVING SUM(bytes_sent) > 10737418240  -- Alert if >10GB in 1 hour
ORDER BY gb_transferred DESC;

More information here on how to query these logs within AWS (outside of your SIEM): https://repost.aws/knowledge-center/analyze-logs-athena

Alternative Logs: VPC Flow Logs & Route 53 DNS Analysis

If your S3 access goes through a VPC endpoint, VPC Flow Logs capture network-level logs. You can montitor VPC Flow logs and determine how much data was sent to S3. You should note that S3 is a large public service with external IP ranges and S3 uses fqdn DNS names to map events in their backend. You can therefore also cross-check with DNS logs (Route53 if you have them enabled for your VPC) to determine which buckets were resolved for a resource.

Alternative Logs: AWS GuardDuty Integration

Amazon GuardDuty automatically analyzes CloudTrail, VPC Flow Logs, and DNS logs to detect S3 exfiltration patterns. Monitor these logs for any events related to S3 buckets.

Example GuardDuty detections:

1. Exfiltration:S3/ObjectRead.Unusual

   • Detects anomalous S3 downloads (e.g., first time an IAM user downloads from this bucket)
   • Based on historical access patterns

2. PenTest:S3/KaliLinux

   • S3 API calls from known penetration testing tools (Kali, Parrot OS)

3. UnauthorizedAccess:S3/TorIPCaller

   • S3 access from Tor exit nodes

Forward GuardDuty findings to your SIEM:

Alternative Logs: Cost-Based Anomaly Detection

Data exfiltration generates S3 data transfer costs. A 500GB download to an external IP costs approximately $45 USD (S3 to internet pricing in ap-southeast-2). In the absense of S3, Network, Cloudtrail, Guarduty and DNS logs you can fallback to Anomaliy detection in your AWS bill to infer if there was exfiltration.

You can also create a cost anomaly monitor for S3:

aws ce create-anomaly-monitor \
  --anomaly-monitor file://s3-cost-monitor.json

s3-cost-monitor.json:

{
  "MonitorName": "S3-Data-Transfer-Anomaly",
  "MonitorType": "DIMENSIONAL",
  "MonitorDimension": "SERVICE",
  "MonitorSpecification": {
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["Amazon Simple Storage Service"]
    }
  }
}

Alert threshold: S3 data transfer costs exceeding 3x historical average trigger investigation.

Key Takeaways

• CloudTrail logs API calls, not data volume. Enable S3 Server Access Logging to see bytes transferred.
• Server Access Logs are your primary detection source for S3 exfiltration—capture HTTP status, download size, source IP, and user-agent.
• VPC Flow Logs provide a backup if attackers disable S3 logging (they capture network-level transfers).
• GuardDuty automates anomaly detection for unusual S3 access patterns.
• Cost anomaly detection catches exfiltration even when all logging is disabled (attackers can’t hide the AWS bill).
• Alert on volume thresholds: >10GB transferred in 1 hour from a single source should trigger investigation.

Need help implementing Cloud detections in your AWS environment? Contact Eviant for cloud security assessments and detection engineering support.