How to find the AWS account ID of any S3 bucket

Original Article ↗ Hacker News Discussion ↗

A new technique shows how to infer the AWS account ID that owns any given S3 bucket by abusing IAM condition matching, raising questions about what previously implicit metadata can now be mapped and correlated. Commenters largely agree that AWS account IDs are not meant to be secrets—AWS says so explicitly—but argue over whether treating them as “sensitive” for operational security or correlation risks still has value. Many see this as a reminder that security must not depend on hidden identifiers or obscurity, and that misconfigured cross-account policies and metadata leakage are the real hazards to address.

Scope of the Finding

  • Technique uses S3 bucket policies and s3:ResourceAccount conditions with wildcards to infer which AWS account owns a given bucket.
  • Many see it as an interesting side channel rather than a direct break: you still need misconfigurations or additional info to get access.

Are AWS Account IDs Secret or Sensitive?

  • AWS docs explicitly say account IDs are not secret, sensitive, or confidential.
  • One camp: account IDs must be treated as public; designing systems that depend on their secrecy is bad security and a “false assumption.”
  • Other camp: not “secret,” but still “sensitive”; leaking them adds value to attackers and should be minimized where practical.

Operational Security & Metadata Leakage

  • Main concern is not raw IDs but relationships:
    • Correlating multiple buckets to the same owner (e.g., different brands, clients, internal projects).
    • Linking “hidden” or staging buckets to a known production account.
    • Business intelligence / espionage use-cases (e.g., learning about projects from bucket names).
  • Some say this is opsec, not security; others argue opsec is still legitimately important.

Security by Obscurity Debate

  • Several argue obscurity is at best a weak, non-rotatable layer and should never be relied on as a control.
  • Others counter that “not-public but not-secret” info is a valid opsec concern and doesn’t imply you’re using it as an access-control mechanism.
  • Consensus point: don’t design IAM or threat models that assume the account ID stays hidden.

IAM Wildcards and Policy Design

  • Many are surprised IAM allows wildcard (StringLike) matching on account IDs; several see no legitimate access-control use case.
  • Explanations offered:
    • Generic, loosely typed policy language that applies string operators everywhere for simplicity.
    • Possible but dubious uses (bucketing many accounts by prefix, sharding, policy size reduction).

Related Enumeration Vectors & Tools

  • AWS access key IDs embed the account ID and appear in pre-signed URLs, so many IDs were likely already leaking.
  • Other global namespaces (e.g., AMI vendors, other public resources) naturally expose account IDs.
  • AWS Config with org-wide aggregation and Athena is highlighted as the “right” way to locate which account owns which resource internally, though it’s not free.