How We Gained Full Access to a $100M Zero-Trust Startup

Hello Everyone, 👋
Today I’d like to walk you through a recent engagement we carried out with one of our clients, a growing startup in the zero-trust security space.

Intro

As part of this engagement, we performed a comprehensive penetration test. The company, which has secured over $100 million in funding, entrusted us with assessing its application security.

While many issues were identified, this case study focuses on one of the most critical findings that has led to full system access. We are unable to disclose the company’s name, but we agreed to share this case study anonymized to highlight the importance of penetration testing.

The target environment was a SaaS-based Zero Trust Access platform designed to provide secure, seamless connectivity to internal resources across both cloud and on-premises infrastructures.

We are ready! Let’s Hack.

Generating SSH Keys for Other Users

While exploring the application, we discovered a feature that enables users to generate SSH keys for secure access to their environments. We decided to test how this feature works and quickly found that it was vulnerable to a CSRF attack.

CSRF (Cross-Site Request Forgery) is a type of web attack where a user is tricked into performing actions on a website without meaning to. It happens when a malicious website makes requests using the user’s browser to another site where the user is already logged in (like transferring money or changing settings). Because the browser sends cookies automatically, the other site thinks it’s a real request from the user.

GET /portal/generate_ssh_key

Once we confirmed the presence of the CSRF vulnerability, it became evident that an attacker could exploit it to generate SSH keys on behalf of any logged-in user. This raised an important question: could this also work against an admin account? We decided to investigate further.

At this point, another question came up, how could the attacker actually obtain the generated SSH key? It’s one thing to generate it via CSRF, but can it be read or retrieved in some way? If so, how? That’s where CORS (Cross-Origin Resource Sharing) comes into play.

CORS Misconfiguration

While digging deeper, we found an even more serious issue, the same endpoint was vulnerable to a
CORS (Cross-Origin Resource Sharing) misconfiguration. Let me explain.

For context, CORS is a browser security mechanism that restricts web pages from making requests to a different domain than the one that served the web page. It should prevent malicious sites from accessing sensitive information from other sites.

When CORS is misconfigured, such as allowing access from any origin using a wildcard or by reflecting arbitrary origins in the Access-Control-Allow-Origin header, the browser’s same-origin policy can be bypassed. This can allow attackers to perform actions or access data in the context of an authenticated user. However, it is important to understand that not all CORS misconfigurations lead to impactful exploits.

A wildcard alone does not allow reading sensitive authenticated responses. In many cases, it only permits access to public or static resources, and most browsers will block credentialed requests unless explicitly allowed by the server.

The situation becomes more dangerous when the server is configured with Access-Control-Allow-Credentials set to true. This header instructs the browser to include credentials such as cookies or HTTP authentication headers in cross-origin requests. When this is combined with a permissive or reflective Access-Control-Allow-Origin, the browser treats the cross-origin request as if it originated from the same domain.

This chain becomes critical when combined with a CSRF vulnerability. In such cases, an attacker can create a malicious cross-origin request from their domain. If a victim visits that page while authenticated, their browser will send the request with their session credentials, and the server will process it as legitimate.

As you might have figured out now, I was able to exploit the misconfiguration to send authenticated cross-origin requests from an attacker-controlled domain. The server accepted and processed the requests, effectively allowing us to perform actions on behalf of the user while bypassing the browser’s same-origin policy.

 

Stealing the Admin’s SSH Key

To demonstrate the vulnerability to our client, we crafted an exploit that combined both vulnerabilities (CSRF and CORS) to extract the SSH key of an administrator user.
We logged in as an administrator.

We visited a page hosting the malicious exploit as an administrator.
The page used JavaScript to trigger the CSRF request via a CORS-enabled cross-origin fetch. It resulted in the server generating a new SSH key pair and returning it to the malicious site.

BOOM! We successfully extracted the admin’s SSH private key.

An attacker could generate and exfiltrate SSH keys for privileged users, including administrators, and gain full access to internal infrastructure and systems, with the victim having no interaction beyond simply being logged in by chaining the CSRF and CORS vulnerabilities.

Let’s proceed to the next vulnerability. While exploring the platform, we noticed that the application integrates with AWS infrastructure, and we decided to take a closer look at how the AWS-related features were implemented.

SSRF Leads to AWS Account Takeover

As you might have guessed from the title of this section, what we found turned out to be far more critical than expected.

During the assessment, we discovered a critical Server-Side Request Forgery (SSRF) vulnerability in the application’s “Create App” feature. This feature enables administrators to tunnel traffic to remote applications by configuring custom endpoints.

However, it lacked input validation and security controls, making it possible for a malicious user to exploit it for SSRF attacks.

Server-Side Request Forgery (SSRF) is a vulnerability that enables an attacker to cause the server to send HTTP requests on their behalf. An attacker can trick the server into accessing internal systems, cloud metadata services, or other restricted resources not directly accessible from the outside by manipulating parameters that define URLs or endpoints.

AWS EC2 instance metadata refers to data about your EC2 instance that the instance itself can retrieve. In AWS environments, a common target for SSRF attacks is the Instance Metadata Service (IMDS), especially when using version 1 (IMDSv1). IMDSv1 lacks protections, such as session-based tokens, making it vulnerable to simple HTTP requests from within the instance. If an attacker can trigger an SSRF to access http://169.254.169.254, they can extract sensitive information such as IAM role names, instance identity documents, and temporary security credentials. These credentials can then be used to interact with AWS services, potentially leading to full account compromise.

Abusing Internal AWS Metadata

The feature allowed configuration of parameters such as host2 and scheme, which were expected to be encoded in Base64.
By intercepting and modifying the request, an attacker could replace the values with a Base64-encoded AWS metadata endpoint, for example:

http://169.254.169.254

This endpoint is part of the AWS instance metadata service, which exposes sensitive data, including instance identity, IAM role information, and temporary security credentials.

Access the Instance Identity Document

A crafted request to the following endpoint returned an instance identity document:

/latest/dynamic/instance-identity/document?host2=aHR0cDovLzE2OS4yNTQuMTY5LjI1NA==&scheme=aHR0cA==

This confirmed that the exploit is functional and we could reach the internal metadata service.
Retrieve IAM Role Information, and the attacker then queried the metadata service for IAM role configuration:

/latest/meta-data/iam/info?host2=aHR0cDovLzE2OS4yNTQuMTY5LjI1NA==&scheme=aHR0cA==

This revealed that the instance was assigned an IAM role named deploy.

Extract Temporary AWS Credentials

With access to the IAM role, the attacker fetched temporary AWS security credentials:

/latest/meta-data/iam/security-credentials/deploy

The following screenshot shows that the response returned the credentials of that AWS User, Access Key ID, Secret Access Key, and Session Token. These credentials enabled the attacker to authenticate with AWS CLI and interact with cloud resources.

Lateral Movement via AWS CLI

Using the extracted credentials, we executed the following command to enumerate EC2 instances:

aws ec2 describe-instances

The output revealed a list of active EC2 instances along with their associated metadata and user-defined descriptions. While reviewing the data, I noticed something interesting.

A few of the instance descriptions contained hardcoded credentials in plaintext. We were amazed that the exposed sensitive credentials were directly within the cloud infrastructure, significantly increasing the impact of the attack:

aws ec2 describe-instances | grep 'pass' --color

The fact that plaintext passwords were used indicated insufficient credential storage and increased the overall impact of the exploit.

By chaining the SSRF vulnerability with weak IAM role controls, the attacker was able to compromise the target’s AWS environment fully.

Full Access to AWS Environment

Using the compromised credentials of the developer in the descriptions, we successfully authenticated as an AWS Administrator, confirming the severity of the issue.

Upon discovery, we notified the client immediately. After an internal review, the client approved controlled exploitation for demonstration purposes.

Conclusion

This case study highlights the critical importance of penetration testing and security assessments, especially for companies handling sensitive data and infrastructure. If you’re building or managing cloud-native applications, these risks are real and often overlooked.

We’re always open to collaborating with teams who care about security and want to stay ahead of potential threats. If your organization is seeking comprehensive, real-world penetration testing, don’t hesitate to reach out.

Thanks for reading and following along with this case study.