How to find the AWS account ID of any S3 bucket

https://tracebit.com/blog/2024/02/finding-aws-account-id-of-any-s3-bucket/

by tracebit • 2 years ago

583 215 2 years ago

ianhawes• 2 years ago

TIL: AWS Account IDs are considered secrets. IMO, if a given value cannot be cycled, it is sensitive but not secret.

tracebit4• 2 years ago

AWS do not define account IDs as a secret (https://docs.aws.amazon.com/accounts/latest/reference/manage...) but until now it's not been possible to do this look up.

abadpoli10• 2 years ago

AWS Account IDs are not secret and don’t need to be. AWS doesn’t design anything that assumes your account ID is secret, and you shouldn’t either.

dekhn2• 2 years ago

I've gotten in long arguments with senior IT people who refuse to believe this even when they talk to AWS directly about it.

electroly3• 2 years ago

While I agree, the way you wrote this might mislead people into thinking that you meant you can treat your account ID as non-secret because AWS does. That doesn't directly follow; the difference between AWS's point of view and your company's point of view means there are things you might care about that AWS does not. Rather, you need to follow AWS's lead and design your cloud deployment such that the account ID doesn't leak anything interesting about your business that you'd prefer to keep private. Correlated ownership of buckets (e.g. different clients of the same design firm) in particular is something AWS doesn't care about, but you might. If you don't want people to know that the buckets have the same owner, better split it up into separate accounts to preserve the non-secretness of the account ID.

TheIronMark• 2 years ago

AWS doesn't consider them sensitive, but some organizations do. My feeling is that I would rather avoid leaking any info about my AWS environments. Just because AWS doesn't think they can be dangerous doesn't mean someone else won't find a way.

1letterunixname• 2 years ago

Yes. *

* Security through obscurity provides secondary security only, so it doesn't add to defense-in-depth significantly. If it can be added, then it is slightly safer to prefer to do so. Elimination of unprivileged enumeration and internal primary key predictability are relatively more important to reduce the attack surface.

jameshart5• 2 years ago

AWS account IDs aren’t secret, but the identity of who owns particular S3 bucket names is meant to be.

If you get an email apparently from AWS that correctly names an S3 bucket and the associated account ID, are you more likely to take it seriously than an email that just names a bucket?

afavour• 2 years ago

Not to mention it also means you can establish relationships between buckets by finding common ownership.

No, the account ID isn’t secret but I don’t think we should be dismissive of this new information either. It’s still important metadata to factor into decision making.

btown• 2 years ago

More generally, this opens up all sorts of threat models for espionage and alternative data. A private bucket called project-foobar-logs-staging might have its existence known in an index but never have been known to be associated with Baz Corp's publicly-known image buckets - but with this disclosure, a database will become available making that association possible. And it will be possible to monitor if and when project-foobar-logs-prod gets provisioned. Not to mention that state-level actors would love to see an enumerable list of projects their rivals are working on, and if any of them happen to have been secured only by obscurity in the past.

Edge cases, to be sure, but certainly nontrivial.

INTPenis2• 2 years ago

It's valuable info to any pentester. Security by obscurity is still one layer of security.

Uehreka• 2 years ago

But there’s a reason people advise against security by obscurity: the obscurity can go away at any time and once it does it’s unrecoverable.

So sure, maybe pat yourself on the back today that on top of your other measures, no one outside your org and AWS knows your Account ID. But if it gets out at some point, those other measures should be foiling your pentesters on their own. In fact, to better test that this is the case, you should probably give the pentesters your account ID so you can be informed regarding your security in this scenario.

fnordpiglet2• 2 years ago

They’re not a secret, in fact it’s what you use to share the identity of one account with another, possibly third party’s account. It’s a secret in the way your personal email address is. You may not advertise it on 4chan, but you definitely share it to limited audiences. Once you’ve shared it it’s no longer an actual secret. Indeed, as has been noted, aws itself doesn’t treat your account id as a secret and freely shares it within aws, logs it in plain text, uses it for operations with human operators, internal reporting, etc. It’s an identifier, it’s discoverable, shareable, and leaks all over the place.

This is not the stuff secrets are made of.

Trying to eek some sort of security story out of hiding account ids plays right into security through obscurity. As it’s not treated as a secret the most you’re doing is obscuring the attack surface of your infrastructure. IAM doesn’t allow anyone to use the knowledge of your account ID to grant any privilege not specifically granted within the account itself via two way grants. Holes in your IAM policies aren’t protected by hiding the account ID, they’re protected by closing the holes.

sroussey5• 2 years ago

Yes, but I do use random email addresses (that look like passwords) to stop correlation, concerted credential stuffing (that might lock me out for a time), etc. And if it pops up in a compromised server no one will know that email address is mine.

corytheboyd5• 2 years ago

Everyone here throwing down the “technically not a secret” card but I don’t think that was your point. I guess “sensitive, but not secret” is the right way to say it. They’re obviously not secret like credentials, but it’s a damn good piece of info for an attacker to hold against you, because, like you said, it’s impossible to rotate, but is tangentially related to every single part of your AWS infrastructure (per-account of course).

evandale5• 2 years ago

It's not even sensitive or confidential though, Amazon says that themselves in their docs.

paulddraper5• 2 years ago

Not at all.

In fact, when delegating IAM access (where security is top of mind), account IDs are shared liberally.

Account IDs are as secret as phone numbers. That bit of info could be tangentially useful to an attack, but really shouldn't be assumed to be secret in any meaningful way.

samstave• 2 years ago

So are S3 Crawler bots inbound that will be used to exploit and blackmail S3 bucket owners... via doxxing?

EDIT: isnt one of the S's "secure"....

Isnt it like THE FIRST S?!?!?!?

EDIT

I get it! - I forgot the three Ss'!

Shove it.

JohnMakin• 2 years ago

Exploiting incorrect/weak IAM permissions I would assume.

upheaval7276• 2 years ago

No. Simple Storage Service

PodgieTar• 2 years ago

Of S3?

No, it's Simple. Simple Storage Service

akerl_• 2 years ago

No. None of the Ss in S3 stand for Secure.

And this still doesn’t let you tie an account ID to an email or human.

beepboopboop• 2 years ago

Shove it

… in Simple Storage Service?

busymom02• 2 years ago

Slightly related - CloudFlare account_id and zone_id are safe to be public

https://github.com/cloudflare/cloudflare-docs/issues/474

https://community.cloudflare.com/t/api-zone-id/355566

The Zone ID and Account ID are not sensitive. Sensitive data like account API Key, Secrets etc. can all be revoked, rotated or changed. See the comment 36 below on the Wrangler repo: as per our security team, it’s completely Fine to have your zone_id and account_id public, the Global API key and associated email address should be kept secret.

abadpoli10• 2 years ago

AWS account ID is also safe to be public.

That said, one thing I could think of that this could be used for is correlation. If you’re running multiple S3 sites from the same AWS account, people would be able to see that they’re hosted by the same account. Whether or not this matters depends on your threat model.

tracebit4• 2 years ago

Exactly - this isn't going to open the door for someone but could add a ton of value to enumeration.

As we are very canary focused, we also think it's interesting to consider the implications of the recent research from Truffle Security w.r.t canary tokens (https://trufflesecurity.com/blog/canaries).

mschuster914• 2 years ago

AWS account ID is also safe to be public.

Not necessarily. An AWS account ID + the knowledge of a role name that by mistake has the "allow role assumption" allowlist too wide (say "*") is now enough to take over the account.

One might of course say "well then don't do that", but of course the more complex a system like IAM is the easier it is for unexperienced people to open the floodgates.

sroussey5• 2 years ago

Oh, there are other things... like a compromised chrome extension that only looks for your accountID being used and sends back credentials.

Knowing an accountId tells you where to focus your efforts. You got through one hoop (of many).

latchkey• 2 years ago

For CF accounts, I use the gmail `+ feature` to make a totally unique email address that cannot be easily guessed. Not perfect, but adds another layer of abstraction.

busymom02• 2 years ago

If I remember right, the pre-signed url generated for R2 uploads include the account ID in it.

nerdjon2• 2 years ago

For sure an interesting find, but was kinda hoping based on the title that there was a more straightforward way to do this.

I really wish that AWS had a simple way from an admin account to ask "where is X resource" within an organization to quickly tell me which account has a specific S3 bucket (and other things, but s3 buckets is the big one).

Admittedly this is mostly an issue with legacy buckets that existed before better practices and buckets all being defined in code. But with a ton of AWS accounts it can be tedious to hunt down a resource in an unknown account and possibly region.

emilburzo• 2 years ago

If you use AWS config setup for the organization (aggregator), you'll get a athena-sql-queryable inventory of all your resources from all organization accounts.

So finding out which account owns a resource can be as simple as, roughly: select accountId where arn = "x"

nerdjon2• 2 years ago

... how did I not know this existed.

That is exactly how we are setup, the amount of time I just spent going account by account looking for a specific resource.

Thank you! I have long wondered why it didn't exist, and apparently it did...

baby_souffle2• 2 years ago

You can also do this with steam pipe.

It might not scale well beyond tens of accounts though, depending in your query…

tracebit4• 2 years ago

For those interested, we put the code online here: https://github.com/tracebit-com/find-s3-account

belter3• 2 years ago

I am not sure this would be in agreement with these policies, or at least the spirit of them: https://aws.amazon.com/security/penetration-testing/

jkaplowitz• 2 years ago

OP's article said they consulted with Amazon's security team before publishing, so I imagine they know what's allowed in this case.

phendrenad2• 2 years ago

Can we go further, and find the email associated with an account ID?

tuananh4• 2 years ago

i dont think we can.

id is static while email can be changed.

eax-eip• 2 years ago

How about the other way: email -> account ID?

jameshart5• 2 years ago

The ability to apply a wildcard match on the s3:ResourceAccount condition key

That’s the crazy part. No good can ever come from this - there is no legitimate reason why you would grant or deny permission based on a partial account id match.

efitz2• 2 years ago

That's the part that surprised me as well; it doesn't seem like a field that should be eligible for anything other than an exact match. I am unable to conceive of a use case for pattern matching account IDs.

sroussey5• 2 years ago

Well, that assumes that the ID is cryptographically random. Perhaps that is a bad assumption.

twoodfin• 2 years ago

If for some reason you’re dealing with thousands of accounts that are architecturally indistinguishable, bucketing them by ID prefix isn’t a particularly wild thing to want to do.

supriyo-biswas• 2 years ago

This is because, I assume, the AWS policy execution has a number of “operators” and “operands”, and in this case, you’re using the StringLike operand on the account ID string.

Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] now, although other types of side channels such as speculative execution side channels on CPUs (Meltdown, Spectre) already made waves at the time of discovery, and before that we had power analysis[2] and Magnetostriction detection, and constant time cryptography (this one is a field of its own, so I omit references.)

[1] https://en.m.wikipedia.org/wiki/Side-channel_attack [2] https://en.m.wikipedia.org/wiki/Power_analysis

paulddraper5• 2 years ago

the AWS policy execution has a number of “operators” and “operands”

That is correct.

The IAM condition language is flexible and does not prevent you from doing strange things.

darkwater2• 2 years ago

Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1]

We, the DevOps people, already knew about side channel attacks, Spectre and the likes, evaluated the performances hit for the fixes (or alleged fixes), patched our kernel boot params etc etc. We are curious people, just like many here.

PaulHoule2• 2 years ago

Probably comes out of a tendency to generalize. Last week for one of my side projects I built something that lets you write queries in a format inspired by OWL and it has a library of relational operators that can, say, extract the host from a URL or do a prefix query, like query, regex query, etc.

As it is my side project’s side project I do what is easy so these operators are always available even in cases where they don’t make sense (I dunno what happens if you try a regex query on a number, I don’t care) I can imagine there is something a bit like this inside AWS but for a security-sensitive system with a lot of users you have a different standard.

johnklos• 2 years ago

This is like matching a bitfield on the group ID on a Unix system. I could see someone coming up with this idea, and I could see them thinking this is somehow smart, but implementing it on systems that aren't 100% in your control would just be silly.

creatonez• 2 years ago

there is no legitimate reason why you would grant or deny permission based on a partial account id match.

You're not a fan of my AWS lottery idea where accounts ending in 666 get access to a free bitcoin miner??

lobsterthief• 2 years ago

I love the idea, but maybe we can pair it with my ICO idea of flipping a virtual stack of Pogs to unlock new units of currency that can be mined.

RajT88• 2 years ago

Will it make it easier to identify the operators of malvertising campaigns hosted on AWS?

victorbjorklund2• 2 years ago

Doubt they use their real information on their AWS accounts.

dotancohen2• 2 years ago

Just need enough information to send to either Amazon or the FBI.

sylens2• 2 years ago

While I wouldn't publicly hand out my account IDs as a general practice, I think you have to expect that some of them will be disclosed at some point. As more third party vendors and SaaS platforms move away from IAM users and access keys to using role assumption as the preferred method of integration (as they should!), the account ID of at least the account you use as their integration point is now known by another party, who have their own dependencies, vulnerabilities, etc.

SamuelAdams• 2 years ago

This is what I’m curious to learn. What can an attacker do with an AWS account ID? How is that any different from knowing someone’s email address?

sylens2• 2 years ago

If the account and its resources are properly configured - not much.

But that can be easier said than done for many organizations, especially when you have lots of different teams configuring their own environments.

quickthrower2• 2 years ago

Useful social engineering datapoint

coredog64• 2 years ago

Once I have an AWS account ID, my next trick is to grant cross-account bucket policies to discover role names in the account.

jokoon• 2 years ago

Maybe their logic is to let authorities track people who misuses it?

tuananh4• 2 years ago

aws s3 bucket needs to match the domain for website hosting.

let's say if apple uses s3, they need to create bucket name "apple.com", and then we can find what aws account which apple is using.

ejb999• 2 years ago

Not exactly - they Can do that, but they don't need to match - using cloudfront in front of your s3 website and then the site can be served from any bucket or folder within a bucket.

I have dozens of s3 static websites served from a single s3 bucket, all with unique top-level domains, each in its own folder within that single bucket - much easier this way.

Given anyone can create a bucket with any name (if its not already in use), you can't count on getting the bucket name that matches your domain name.

tuananh4• 2 years ago

ah thanks. iirc it used to be like that ( when use without cloudfront).

mayank• 2 years ago

aws s3 bucket needs to match the domain for website hosting.

This is outdated information, and not required anymore when using CloudFront.

And even in the past, you could use the S3 API to implement a reverse proxy without matching bucket and domain names.

hacker_newz• 2 years ago

That is not how s3 buckets work.

tuananh4• 2 years ago

it used to be like that (without cloudfront)

https://docs.aws.amazon.com/AmazonS3/latest/userguide/websit...

ed• 2 years ago

How might this matter? A obvious one: Given a production bucket, it’s now possible to find development buckets for that same org, which is not expected behavior IMO.

drjasonharrison• 2 years ago

Only true if they use the same accounts for both production and development. This would be another reason not to use the same accounts.

catlifeonmars2• 2 years ago

Unlikely, unless dev buckets are somehow in the same account.

booi• 2 years ago

it's bad practice but it's more common than you think especially with older accounts (pre-organization)

corytheboyd5• 2 years ago

You only need the bucket name to do that. You should include a randomly generated prefix/suffix in bucket names to prevent against such enumeration attempts. Another good idea (as well as, not instead of) is to expose objects in buckets publicly with a non-default host name, such that the bucket name isn’t leaked at all.

gusmd• 2 years ago

Or, for read scenarios, putting a CloudFront distribution in front of the bucket!

paulddraper5• 2 years ago

How so?

You'd have the know the name of the (development) bucket first, right?

insomniacity• 2 years ago

And this is why you pad the bucket name with random chars.

dheera• 2 years ago

Perhaps this can make s3fs and similar mounting tools easier to use; just plug in the bucket, enter password, and it mounts.

cj• 2 years ago

While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.

https://docs.aws.amazon.com/accounts/latest/reference/manage...

panarky2• 2 years ago

What does this mean?

If they're not secret, sensitive, or confidential, then why must they be shared carefully?

pyre• 2 years ago

There is plenty of information that you wouldn't necessarily want to publish, but wouldn't be the end of the world if it were leaked either.

rmbyrro• 2 years ago

Usually, the more information an attacker has about you, the higher the chances of coming up with a successful attack vector.

dexwiz• 2 years ago

There are levels of data classification, and different regulations and policies apply to each level and geo. They are probably disavowing themselves of any liability.

https://docs.aws.amazon.com/whitepapers/latest/data-classifi...

raid2000• 2 years ago

This is a good question for any provider like AWS--what kinds of information do I leak with seemlingly mundane choices like bucket names.

The other attack vector is from insiders. Many organizations "shield" identifiable information behind UUIDs or some other scheme. In the event of a breach, the UUID might mean nothing to most (it's not foolproof, though), but opens more doors for an insider.

0xbadcafebee• 2 years ago

A hacker can enumerate the resources of and access to an account by using its account ID. Many AWS customers incorrectly configure resources such that any other AWS customer can access things in their AWS account; for example, some 3rd party providers tell customers to configure access for the 3rd party, that can lead to wide-open access for anyone who knows the customer's account ID. If the cloud admins don't know what they're doing it can be very easy to screw up and not realize it.

It's sort of like giving someone your IP address. By itself it's not enough to hack someone. But if your host is insecure, it sure makes it easier knowing exactly where to attack.

thekevan• 2 years ago

My personal phone number is not exactly secret or confidential, but I only share it carefully.

dimitrios1• 2 years ago

Seems like at least in the digital world, there is either public or private information, and that's it. We don't really have a good concept of privilege or protected information.

For example, my home address is technically public, but I most certainly wouldn't want it lambasted across the interstate with a picture of my family next to it advertising where I live. It's handed out on a need-to-know basis, and I mostly trust / expect that it's kept mostly confidential, or use-limited.

greiskul• 2 years ago

One huge mistake that Google did when they were integrating youtube with Google+, was the idea of sharing people's youtube comments with their G+ friends. Youtube comments have always been public, but there was huge customer pushback, forcing them to revert them for this idea, since there is in people's mind a huge difference between public and publicized comments.

chrisjj• 2 years ago

they are not considered secret, sensitive, or confidential information

... by us (it should say).

Users may consider it differently.

bjw4• 2 years ago

Any tips on how to do the same for EC2 instances? Am aware of one that’s allegedly joined to our domain but can’t find it in any owned accounts

vegardx• 2 years ago

If you're lucky and it has a instance profile attached with appropriate role/policy attached you can use get caller identity to see what account it's running in: https://docs.aws.amazon.com/cli/latest/reference/sts/get-cal...

bagels• 2 years ago

What value is there in allowing wildcard account id matching? I can't think of a legitimate use case.

denysvitali2• 2 years ago

This is probably the rule engine of the policies being used for something less useful

syncsynchalt• 2 years ago

It's likely only allowed because someone didn't think to explicitly disallow it.

thenickdude• 2 years ago

Related: AWS key IDs (not the secret key part) include your account ID within them, bitshifted by one position:

https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f...

These key IDs are included in the URL for pre-signed links to S3, so there's a good chance you've already been publishing your account ID.

firebaze• 2 years ago

Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth".

This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not)

Anything non-"security by obscurity" does not depend on you understanding something or not - it will apply, no matter what, as long as the attacker hasn't a genius on payroll which cracks e.g. AES-256 just so (https://www.youtube.com/watch?v=KEkrWRHCDQU)

ralusek• 2 years ago

To me security by obscurity is limited to things like this:

There is a way to view bananas at

/bananas/:bananaUUID

unsecured endpoint.

I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.

orf• 2 years ago

Interesting post. I wonder if you can further combine it by using a PrincipalTag in some way? You can assume a number of roles with different tag values, and these can be interpolated into the condition. This lets you do things without a huge statement?

NovemberWhiskey4• 2 years ago

There seems to be a large discussion of whether account IDs are "secret" or "private" or "confidential" or whatever.

From my point of view, that entirely misses the point. The problem here is that what's revealed here is the relationship between buckets and account IDs, which allows discovery of shared ownership of buckets (unless you use a micro-account approach).

I probably don't care if you can discover that 2343242365 is the account number associated with "coolbuttplugs.com" but I probably do care if the same account hosts a bucket for "michaeljfoobar.name" and my buttplug thing is a sideshow from my white shoe law practice.

denysvitali2• 2 years ago

Accounts on AWS are pretty cheap (free?) - why would you host everything on the same account?

gaudystead• 2 years ago

You may be underestimating human laziness...

whs• 2 years ago

In my company we use reseller billing as AWS do not have a local billing entity. The reseller owns the organization's root account and we do not have access to it. Every subaccount creation require a support email to the reseller.

Garlef• 2 years ago

free as in: AWS does not charge you

not free as in: you have to manage it (for example give a CI role access via OIDC, create a role for you to assume to do stuff via the console, etc)

huslage• 2 years ago

I have always likened AWS Account IDs to be similar to public keys. But even less useful. There is nothing useful that you can do with them without other information.

master_crab• 2 years ago

AWS account ID == Your IP address. It may be sensitive, but someone needs to know it to get s*$t done.

Illustrative example: I had to deal with a third party that we needed to integrate with because of anti-money laundering procedures a year or two ago. I wanted my team to setup a privatelink with the organization because that's generally more secure than an open sftp port. The company refused citing security reasons to hide their Account Id (it's needed for the role ARN used for reciprocal permissions to PV endpoints). So what did we do?

We ended up whitelisting a range of public IPs they use for inbound port 22...

Moral of the story: you may think you are a genius for obfuscating your IDs, but you can't really run a business unless people have an address back to you

stingraycharles2• 2 years ago

AWS PrivateLink has another property that generally makes it undesirable for these types of integrations: communication is bidirectional, and IP subnets should not overlap.

We (as a vendor ourselves) typically integrate as a VPC Endpoint Service, where communication is unidirectional and our service is exposed as a load balancer’s endpoint within the customer’s VPC.

EE84M3i• 2 years ago

I thought PrivateLink was branding for vpc interface endpoints? There's no ip subject restriction for that because it's basically a proxy. Are you thinking of vpc peering?

VPC endpoints seem preferable in this situation.

executesorder66• 2 years ago

get s*$t done

What were you hoping to achieve with this utterly pointless self-censorship?

sam0x17• 2 years ago

Any scenario where the actual hack results in the time-honored trope/misunderstanding of "hacking" the password one character at a time is awesome

lijok• 2 years ago

ITT lots of debate on whether AWS Account IDs are sensitive or not. To chime in my 2c; we've had this debate in multiple orgs with different security teams and the outcome has always been the same; they're not and it's counterproductive to your security posture to treat it as privileged information. Humans have a nasty habit of placing trust in people who have access to privileged information.

"Hi, this is Tom from AWS, I need to speak with you about your account 5923965523" - as a social engineering primer garners significantly different levels of trust from the target depending on whether the target perceives the account ID to be privileged information.

datadeft• 2 years ago

Sometimes I am having trouble finding my own AWS account id...

myroon5• 2 years ago

Other public AWS resources with global namespaces also reveal AWS account IDs:

https://blog.plerion.com/conditional-love-for-aws-metadata-e...

mise_en_place• 2 years ago

This is kind of a big deal, but also not really? UUIDs are not IDs. And IDs are not always indices. This is a common design flaw in many distributed systems.

d0gsg0w00f• 2 years ago

I think the more worrying attack vector is when you now use the account number to try and Allowlist a principal from that account in some policy in your account. If the principal doesn't exist in the other account you'll get a role/user not found error!

Presumably you could use this to find real principals in the other account.

jimmalongading• 2 years ago

I apologize in advance for what Im going to say here.

AWS account ID is not sensitive data in any way. Just because you can screw up a config doesnt make a user name or account id “sensitive”.

Its not more sensitive than an email address. What is wrong with you people? Where did you come from, and why are you so dumb?

daveevad• 2 years ago

the ability to use StringLike conditions

so much depends

upon

a regular

expression

static_void_• 2 years ago

Account IDs are 12 digit random numbers. They are used to identify an AWS account, that's all. Knowledge of the full 12 digits doesn't grant access to anything, prove you own the account, or enable you to authenticate to any systems (or individuals like in customer service for example) in AWS.

They are visible when ever you share something with another AWS account, they're in the ARN. For example, the 12 digit account IDs of all a vendors that vend AMIs, assume roles on AWS accounts (think datadog, for logging / metrics) or otherwise provide services have AWS Account IDs that are well known and easily discoverable. This s3 example is just sort of interesting since its one of the handful of AWS services that don't use account IDs in ARNs.

AWS account ids are not secrets and treating them as secrets or giving the impression that they are anything other than public data is a distraction from real security concerns.

How to find the AWS account ID of any S3 bucket

Related Stories