Abuse Cognito User and Identity Pools

What this lab covers

You examine a serverless application's client-side code, identify how it authenticates, and work out where its identity configuration grants more than intended. That leads to AWS credentials and onward to the application's backend components.

The lab rewards reading source rather than running tools. Client-side JavaScript in a serverless application contains the identifiers needed to interact with its identity infrastructure directly, which is by design, and the security depends entirely on how the backing configuration is scoped.

It is rated intermediate because it requires holding several AWS services in mind at once. It suits anyone assessing serverless applications or building them.

How Cognito misconfiguration becomes cloud access

A user pool is a directory. It handles sign-up, sign-in and tokens for application users. An identity pool is a credential broker. It takes a token, or in some configurations no token at all, and returns temporary AWS credentials for an IAM role.

Identity pools can be configured to support unauthenticated identities. This exists for legitimate reasons, such as letting a visitor use a feature before signing up, and it attaches a specific role for that case. The risk is entirely in what that unauthenticated role is permitted to do, and those roles are frequently given far broader access than the guest experience requires.

Two configuration choices compound the problem. Self sign-up on the user pool means an attacker can simply create an account and become an authenticated user. Where attributes are writable by the user, values that the application trusts for authorisation decisions may be modifiable by the person they describe.

How to detect this in your own environment

Watch the identity pool's roles as identities in their own right. Credentials issued through Cognito appear in CloudTrail with a distinctive assumed role session, so you can baseline what the guest and authenticated roles normally do and alert on anything outside it.

A sudden rise in unauthenticated identity requests, or in user pool sign-ups, is worth alerting on. Both are ordinary application events, so the signal is in the rate and in the source distribution rather than in any single event.

Monitor for the application's roles touching services the application does not use. A guest role reading from a table it has no feature for is the clearest evidence that permissions exceed intent.

How to prevent it

Disable unauthenticated identities unless a specific feature requires them, and if one does, scope that role to exactly that feature. This is the single highest-impact control here, because it decides what an anonymous internet user receives.

Never make authorisation decisions on user-supplied attributes. If the application trusts an attribute to decide access, that attribute must be writable only by the backend, not by the user it belongs to.

Scope the authenticated role too. Self sign-up means the authenticated role is reachable by anyone willing to register, so it should be treated as a semi-public identity rather than a trusted one.

Real-world context

Cognito misconfiguration has been the subject of published security research showing that permissive identity pool and attribute settings can allow escalation from an anonymous or newly registered user to meaningful access in the backing AWS account.

The wider lesson is about serverless architecture generally. Moving authentication into a managed service does not move the authorisation decision, and the roles attached to identity infrastructure are where the real access boundary sits. They receive far less review than application code.

The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts and T1548 Abuse Elevation Control Mechanism.

Applying this at work

• Check every identity pool in your accounts for unauthenticated access, and review the policy on the role it hands out.
• Review the authenticated role on the assumption that anyone can register, if self sign-up is enabled.
• Confirm no authorisation logic depends on user-writable attributes.
• Baseline what your application roles do in CloudTrail and alert on services outside that set.
• Include client-side application code in your review scope, since it discloses the identifiers needed to interact with your identity infrastructure.

Frequently asked questions

What is the difference between a Cognito user pool and an identity pool?

A user pool is a user directory that authenticates people and issues tokens. An identity pool exchanges an identity for temporary AWS credentials tied to an IAM role. The identity pool is where cloud access is actually granted.

Can someone get AWS credentials without signing in?

Yes, if the identity pool permits unauthenticated identities. That is a supported configuration for guest features, and anyone can obtain credentials for the role attached to it, so that role's permissions define your anonymous attack surface.

Why does self sign-up matter for security?

Because it makes the authenticated role reachable by anyone willing to register an account. The authenticated role should be scoped as though it were semi-public rather than trusted.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS identity abuse and privilege escalation in full, and is assessed hands-on in a live AWS account.