Exploiting misconfigured AWS Cognito self-registration to bypass administrative boundaries and extract production cloud credentials.
The Challenge
A friend of mine had been admitted to a hospital. While waiting, I started looking into the group behind it — a healthcare network with a valuation north of $10 billion. A simple question: If I can see their systems, who else can?
Recon: The Hidden Dashboard
Recon led me to a dashboard subdomain. No VPN, no IP restriction. Just a login panel meant for doctors and internal staff. No signup link was visible, and standard authentication checks failed.
Discovery: Following the Client
When the backend doesn’t live in the page, it lives in the JavaScript. I walked through the loaded scripts and identified AWS Cognito configuration hardcoded in the frontend.
The Flaw: Shadow Registration
If the UI doesn’t let you sign up, the real question is: Did the identity provider get the same memo? I sent a direct SignUp request to the Cognito user pool. It didn't block me; it created my account.
Cognito sent an OTP to my phone, which I confirmed. My account was now a verified identity inside their production environment without any admin approval.
Crossing the Boundary
With a verified account, I logged in and pulled a JWT. I then called GetId. AWS returned a valid identity, marking the transition from an external user to an internal object.
The Payday: AWS SAS Credentials
Every identity in AWS maps to a role with specific permissions. One final call to GetCredentialsForIdentity yielded valid temporary credentials: Access Key, Secret Key, and Session Token.
Final Thoughts
Internal systems become public when a user pool allows open registration and an IAM role assumes every identity is internal. This was reported immediately and fixed within 24 hours.
Reported. Fixed. Internal impact assessment confirmed access to S3 and DynamoDB. Rated Critical.