You're correct, it's not enumeration, but it's easier than pure brute force. As the article itself suggests, if the company does use a predictable user name format (and most do), it's pretty trivial to look up their employees on LinkedIn, create a list of likely usernames, and then check if they exist.

A.k.a. .. enumeration.

No, enumeration would be if you can get the entire list of usernames somehow.

Enumeration means a specific thing, that you get a full or paginated list of things and all you need to do is hit it. This isn't enumeration at all. It's like you saying you know the bucket keys to a hashtable so you can enumerate it by hitting them one by one, except in this case you don't even know the keys.

If there are rate limits, or if the search space is vast, this is notably more limited (even if arguably still enumeration)

And then what?

Send targeted phishing mails.

Our company got hit with this. I guess there's no way to recover from this other than do our best to block these.

I can already do that by sending them for root. This seems like trying to make something out of nothing.

Are you stuck in the 70s or something? I can't recall the last time I read email addressed to root.

My friend, the main AWS account is called the root account and its username is root, so your zinger didn't zing.

How does knowing the AWS username allow you to send a more effective phishing email? Especially if the username is just the user's... name. That's public info.

Yes, you're right. Reading my statement in hindsight shows thats not correct. My intention was to convey that you can check for the existence of common IAM users and roles in the accounts (and even existence of company specific entities like users with first.last pattern, product names, etc) I've slightly updated the point a bit.

In security contexts the term “enumeration” is understood to mean “brute force”. You can Google “enumeration attack” to see a bunch of examples where this is explicitly defined.

More concrete example: Account enumeration because the "forgot password" page tells the user "Unable to find account [email protected]" instead of "If your account [email protected] exists, then we have now send you an e-mail to recover your account".

If your forgot password page takes longer to respond when an account exists when it does not, it is also a side-channel attack.

A "workaround" for this is to just try to create a new account, [email protected].

This bypasses what you've mentioned.

While a lot of security people misuse "enumeration" in this way, it's not accurate. They should use the term "oracle", eapecially since it's from the same field.