However, with a bit of reconnaissance, we discovered that the platform uses AWS Cognito for authentication. We also found a publicly accessible file that anyone can download: https://platform.com/config/application.conf

Let’s try signing up directly using the userPoolWebClientId:

• –client-id <client_id_here>
• –username [email protected]
• –password <password_here>
• –region eu-west-1
• –no-sign-request

Success! This confirms that Cognito self-signup is enabled on the platform which is a promising start.

However, when we attempt to log in using the same email and password, the login fails:

That’s because we haven’t confirmed the sign-up using the verification code yet.

Since we control this email, we can access the code:

Then complete the sign-up confirmation for this account using the verification code we received:

• aws cognito-idp confirm-sign-up
• –client-id <client_id_here>
• –username [email protected]
• –confirmation-code 205842
• –no-sign-request
• –region eu-west-1

Success! Now, let’s try logging in again:

Logged in successfully and we were greeted with a warm “Welcome” message!

However, the interface didn’t load the dashboard or any useful content beyond that point.

Intercepting the request with Burp Suite confirms that the credentials were sent to Cognito, just as expected.

One of the responses returns a JWT access token:

Using this token, we can change the email attribute in Cognito to any address without verification.

For example, let’s say we want to target victim Company B. During our investigation, we identify that [email protected] likely has access to the platform.

To expand our list of potential targets, we can use an AI chatbot to quickly gather more email addresses:

“Do research online and give me 10 valid email addresses ending with @companyB.com that are likely using the platform . Only output the list of email addresses and their primary purpose, nothing else.”

We export the access token and use it to update the email attribute:

• export token=‘eyJra…’
• aws cognito-idp update-user-attributes
• –region eu-west-1
• –no-sign-request
• –user-attributes Name=email,Value=[email protected]
• –access-token $token

Success! Now, let’s try logging in as [email protected] using the same password:

Nicely done!

We’ve now successfully impersonated this email address within the customer portal.
From here, there are several paths we can take to get “Joe” added to the system. Two common scenarios:

1. If [email protected] is already in use, we can slightly modify the address to something like [email protected] and use phishing techniques to get this variation added to the platform, often with the same roles as the original user.
2. If [email protected] isn’t in use, we can either phish to be invited or simply wait to be added.
   In both cases, phishing or social engineering would be highly convincing, as the request appears legitimate, which is just a simple ask to add a valid company email. And since we can create as many of these emails as we like, the opportunities are virtually unlimited.

Let’s say [email protected] ends up being added as a Financial User:

So, can we see the dashboard after logging in as Joe?

The answer is yes. We now have full access to financial data related to this company’s assets:

Issue #2: Cross-company role assignment

As mentioned earlier, this platform is used by multiple companies, and each one manages its own user access control through Cognito.

In this example, the token was issued to a Financial Manager from one of the companies, let’s call this user Finance manager [email protected] of Company B.

Ever wonder what would happen if “Joe” were added as an Administrator in another company, eg: Company A?

Let’s try that:

At this point, if [email protected] logs out and then logs back in to get a new token, Cognito grants him Administrator access not only in Company A, but also in Company B where he was supposed to have Finance-level access only.

These two issues together create the perfect setup for an attacker to carry out further techniques, such as phishing. For a summary of how this leads to a platform-wide compromise, refer to the diagram under TL;DR section at the beginning.

For remediation, we recommend that the client conduct a thorough review of all accounts on the platform to identify any signs of compromise and prevent further exploitation. Additionally, Cognito self-signup should be disabled, as it does not align with the client’s intended user flow.

This kind of attack is made possible by connecting benign, expected functionalities with malicious intent. In other words, it probably stay under the radar of AI-based attack detection systems because all commands followed expected behaviour and no malicious payload was involved.

Moreover, in our case an AI assistant quickly gave us the exact AWS CLI commands we needed and even suggested a list of valuable email addresses to target. This suggest that for now and near future, AI tends to benefit attackers more than defenders.

This also highlights a key issue: vulnerabilities need to be assessed from an attacker’s point of view. If we had stopped at identifying that Cognito self-signup was enabled, the finding might have been marked as “informational” and never get fixed, leaving the platform wide open to exploitation.

This is precisely where thorough manual penetration testing remain essential. Human testers can trace abstract attack paths, think creatively, and spot combinations of flaws that automated scanners and today’s AI simply miss.