When a Cognito app client becomes the front door for takeover

Account takeover does not always start with a stolen password. Sometimes the application’s own sign-in client is configured to hand attackers everything they need.

How the attack works

The app client is public, meaning it has no secret, and self-signup is left open, so an attacker simply registers and gets a foothold identity. Because the client also grants overly broad OAuth scopes, the tokens it issues carry access the application fully trusts. With those tokens, and with exposed admin user APIs such as AdminInitiateAuth and AdminUpdateUserAttributes, the attacker stops acting as themselves and starts acting on other users, pivoting toward higher-value identities and reaching application data as legitimate users. CloudTrail records the Cognito calls: SignUp, InitiateAuth, and the admin user actions. In ATT&CK terms this combines T1078, Valid Accounts, with T1528, Steal Application Access Token, and T1098, Account Manipulation.

Why it works

The client was meant for a controlled set of users behind a confidential backend, but insecure defaults turned it into an open door. A public, secretless client with broad scopes mints tokens the app trusts, and exposed admin APIs let one foothold act on every other account.

How to fix it

Resetting the one user you noticed first does nothing while the client keeps minting trusted tokens. Fix the source: require a client secret, disable self-signup, tighten OAuth scopes to least privilege, and restrict the admin user APIs. Then invalidate the tokens already handed out by forcing global sign-out and rotating the client secret and keys. Finally, audit every app client across your pools for the same public, secretless, broad-scope pattern, because this is rarely the only client built that way.

Practice it

We built this as a GraphLattice Range scenario so security teams can rehearse the detection, the global sign-out containment, and the fleet-wide app-client audit.