Your AWS account has been pwned

Your AWS account has been pwned. Surprise bill for stuff you didn’t spin up, or you found out some other way. Now what?

Destroy it. End.

The rest is why you should nuke it as soon as you can, and why kicking someone out of an account you keep using is a lot harder than it sounds.

Most of this is old. Daniel Grzelak wrote it down in 2016. The ugly part is that a lot of it still works, and some of it got quieter.

Temporary credentials you cannot see

STS sessions do not show up next to access keys. There is no list-session-tokens. There is no delete-session-token. Disable the original key and the session can keep running. User sessions can last up to 36 hours. Role sessions default to an hour, twelve at most. That is not a backdoor. It is enough time to plant one.

The loud stuff

A new IAM user with a name that looks like yours. An extra access key on every existing user — the limit is two, and the timestamps are sitting there in the console. A new role trusted to some other account, AdministratorAccess attached.

All of that is findable if anyone is looking. So the better version, from their side, is not creating new identities. It is editing the ones you already have: slip an extra principal into existing role trust policies. A policy change is harder to eyeball than a new key. There is no creation date on the line they added.

Then Lambda. An event on CreateUser or CreateRole, and every new thing the team makes gets the same treatment. You delete the planted key. The next user grows another one.

Unused regions

IAM is global. Compute is not. An instance in a region nobody opens — with an instance profile — keeps minting rotating credentials from the metadata service. Same idea for other regional compute. You can hunt IAM in one console. You will not notice an instance in a region you forgot you enabled unless you look there.

Security groups

If they care about the boxes, not just the API: extra ingress, including on the default group, so something they want is reachable from somewhere they control. Easy to miss in a long rule list.

Role chain juggling

This is the one that should actually scare you. SpecterOps documented it in 2020.

If two of your existing roles can assume each other — or three, in a loop — someone with one set of temp creds can hop A → B → A forever. Every AssumeRole mints a fresh session with a new expiry.

No new user. No new key. No new role. No new instance. CloudTrail looks like roles doing what they were already allowed to do. Circular trust does not have to be two roles. A → B → C → A is the same trick.

You can rotate every access key in the account and still lose, because they never needed a key of their own. They needed your roles to trust each other, which they often already do after a few years of “just add this trust, it’s a one-off.”

That is the detection problem in one sentence: nothing new exists. There is no leftover resource to find. There is just someone jumping from one of your roles to another, indefinitely.

So nuke it

Kicking someone out of an AWS account you intend to keep using means proving a negative: no leftover session, no edited trust, no Lambda waiting on the next CreateUser, no instance in a region you never open, no two roles that can keep each other alive. You will not prove that in a weekend.

New account, new org, migrate what you still trust. The old one is evidence, not a home.