AWS Security Hub · CloudTrail
CloudTrail.6: The CloudTrail log bucket is publicly accessible
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub CloudTrail.6 check?
CloudTrail.6 fails when the S3 bucket holding CloudTrail logs is publicly accessible (readable or writable by anonymous or any-AWS principals) through account or bucket Block Public Access settings, the bucket policy, or a legacy ACL.
Why does CloudTrail.6 matter?
The CloudTrail bucket is your account's full audit history, and its name usually follows the predictable aws-cloudtrail-logs-<account-id>-<random> pattern, so an attacker doesn't even need to discover it, just guess and try an anonymous GET. A public read leaks every API call you've made; a public write lets an intruder destroy the evidence. Either way the bucket that's supposed to catch attackers becomes a gift to them.
How do I fix CloudTrail.6?
- Enable account-level S3 Block Public Access and bucket-level Block Public Access on the trail bucket.
- Remove any bucket-policy statement or ACL that grants access to AllUsers or AuthenticatedUsers.
- Re-audit the four layers (account BPA, bucket BPA, policy, ACL) to confirm none still grants public access.
- For a centralised log bucket, scope the policy to only the specific accounts that must deliver to it.
Remediation script · bash
# Close the highest-impact public exposure first: databases.
for db in $(aws rds describe-db-instances \
--query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier' --output text); do
aws rds modify-db-instance --db-instance-identifier "$db" \
--no-publicly-accessible --apply-immediately
echo "$db: public access removed"
done
# Ratchet S3 shut at the account level so no bucket can be made public again.
aws s3control put-public-access-block --account-id 123456789012 \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true' Full walkthrough (console steps, edge cases and verification) in the lesson Block public access to AWS resources.
Is CloudTrail.6 a false positive?
A bucket policy that grants delivery to a whole organization or to many accounts can read as broadly permissive without being truly public; the control fails only on genuine anonymous/any-AWS exposure (AllUsers/AuthenticatedUsers), so a cross-account policy scoped with aws:SourceOrgID or explicit account IDs is the correct, intended state and shouldn't be loosened to chase a green tick. The more common surprise is the opposite of a false positive: where you aggregate logs into one centralised bucket, Security Hub only evaluates the control in the account and Region that owns that bucket and reports No data elsewhere, so a finding in another account usually means a stray local trail bucket, not your central one. Confirm which bucket actually triggered the finding before changing anything, and suppress only if you've verified the four access layers (account BPA, bucket BPA, policy, ACL) genuinely block public access.
More CloudTrail controls
- CloudTrail.1 No multi-Region trail captures read/write management events
- CloudTrail.2 CloudTrail logs are not KMS-encrypted
- CloudTrail.3 No CloudTrail trail is enabled at all
- CloudTrail.4 CloudTrail log file validation should be enabled
- CloudTrail.5 CloudTrail is not wired to CloudWatch for alerting
- CloudTrail.7 Enable access logging on the CloudTrail S3 bucket
- CloudTrail.10 CloudTrail Lake stores should use customer-managed KMS