TL;DR
E.V.A.Information Security research uncovered a widespread security issue involving numerous leading security vendors inadvertently exposing intentionally vulnerable training applications – such as OWASP Juice Shop, DVWA, and Hackazon – to the public internet. Primarily deployed for internal testing, product demonstrations, and security training, these applications were frequently left accessible in their default or misconfigured states.
These critical flaws not only allowed attackers full control over the compromised virtual machines but also provided pathways for lateral movement into sensitive internal systems. Violations of the principle of least privilege and inadequate sandboxing measures further facilitated privilege escalation, endangering critical infrastructure and sensitive organizational data.
These findings represent a significant, and often overlooked, blind spot in cloud security.
In this post, we will walk through the journey of revealing real-world breaches involving companies like Palo Alto Networks, Cloudflare, F5 Networks, UpWind Security and discovering live crypto-miners in the wild deployed and actively exploited by attackers..
How It All Started
They say every great idea starts in the shower - this one started on a sunny Tuesday. During a routine cloud security assessment for a client, we came across an exposed instance of Hackazon, a known intentionally vulnerable training app, running directly in production.
Exploiting its insecure file upload vulnerability gave us immediate RCE. From there, we queried the EC2 instance metadata service and extracted temporary AWS credentials – only to discover the attached IAM role had AdministratorAccess.
That moment raised a simple, but critical question:
How many other vulnerable training applications are publicly exposed, and what could an attacker do with them?
A 4-Step Hunt for Exposed Apps
To answer that question at scale, I designed a four-step methodology inspired by our red team reconnaissance, however in the research I didn’t focus on companies, but on the vulnerable training applications themselves.
Step 1: Target Selection & Fingerprinting
I began by selecting 10 widely-used vulnerable applications. Each app had known RCE-capable vulnerabilities. For each application, I created a fingerprint profile including:
- Favicon Hashes
- Page Titles and HTML Markers
- Unique Endpoint Paths
- Distinct Response Strings
To ensure accuracy across deployment variations, I spun up each app locally to extract and validate fingerprints.
Step 2: Discovery & Validation
With fingerprints in hand, it was time to scan the internet. I leveraged public search engines such as Shodan and Censys, to identify internet-facing instances matching the defined signatures. For example, to discover OWASP Juice-Shop applications via Shodan, we could use the Juice-Shop favicon hash in the following query:
<span class="cool-inline-text" style="margin-bottom: 10px;display: inline-block;border-radius: .375rem;background-color: #F0F8FB;font-family: monospace;font-size: smaller;padding: 0.25rem 0.5rem;">http.favicon.hash:-1669740430</span>
Over the course of the research, more than 10,000 raw results were collected across multiple platforms. A custom python script was used to automatically discover and then clean, validate, filter out false positives, and remove duplicate entries.
This filtering process resulted in 1,926 verified, live, and vulnerable applications. The rest either weren’t accessible or didn’t meet validation criteria.
Step 3: Enrichment & Attribution
To understand who was at risk and what kind of environments were exposed, I enriched the data for each verified instance.
The enrichment process included:
- Cloud Provider Identification
- Geolocation and hosting provider using ipinfo.io
- Reverse DNS & SSL certificate analysis to extract potential org names or internal domains
This enrichment helped correlate some instances to known organizations. However, it wasn’t a silver bullet - many results pointed to generic cloud infrastructure or had no obvious identifiers. To truly identify the companies involved, some manual digging was needed, especially for the most interesting cases.
Step 4: Exploitation & Impact
Out of the 1,926 verified applications, 1,626 unique servers were identified and Nearly 60% (974) ran on AWS, GCP, or Azure. The rest (652) ran on self-hosted infrastructure and were not tested as part of the research.
To assess the risk beyond surface exposure, I built a Python tool to automate exploitation using known vectors to achieve RCE. Upon successful access, the script:
- Queried the cloud metadata service (<span style="font-family: monospace;font-size: smaller;">http://169.254.169.254</span>)
- Extracted the cloud identity name and temporary credentials
- Extracted the machine environment variables
The results were alarming: 94 exposed credential sets were found, many tied to over-privileged IAM roles. These often granted far more access than a “training” app should. These violations were validated manually and allowed for high-impact operations, including:
- Full access to S3 buckets, GCS, and Azure Blob Storage
- Ability to read from and write to Secrets Managers
- Permissions to interact with container registries (ECR, Artifact Registry, etc.)
- Deployment and destruction of compute resources
- Administrator level access to the cloud account
In multiple cases, we found active secrets (GitHub tokens, Slack keys, Docker Hub creds), proprietary source code, and real user data. What began as a harmless lab could lead directly to an organization’s crown jewels.
Bottom line: One misconfigured training app with an over-privileged IAM role can be a single step away from full cloud compromise.
Case Studies: Real-World Exposures
During this research, we encountered multiple cases where exposed training applications belonged to major security vendors and technology companies. While each case had its own nuances, the pattern was strikingly consistent: low-priority “lab” tied to an overly permissive IAM role.
Below are a few verified cases where a single exposed application could have been leveraged for a full cloud compromise. All incidents were responsibly disclosed to the affected organizations and were confirmed, acknowledged (some with bounty $$$$ =] ), and mitigated prior to publication
.
Palo Alto Networks - DVWA
A misconfigured DVWA application was discovered running on an AWS instance linked to one of Palo Alto Networks’ cloud accounts. By leveraging the attached IAM role and its temporary credentials, we gained full administrative access to the AWS account.
Cloudflare - bWAPP
A misconfigured bWAPP application was found running on a GCP instance linked to one of Cloudflare’s cloud accounts. By querying the GCP metadata service, we were able to impersonate the default service account <span style="font-family: monospace;font-size: smaller;">XXX-compute@developer.gserviceaccount.com</span>, ultimately gaining read access to more than 300 storage buckets.
Upwind Security - DVWA
Multiple misconfigured DVWA applications were discovered running on AWS instances associated with several Upwind Security cloud accounts. By leveraging each instance’s attached IAM role and corresponding temporary credentials, we gained permissions such as reading from AWS Secrets Manager (retrieving stored secrets) and enumerating and accessing Amazon ECR repositories.
F5 Networks - DVWA
A misconfigured DVWA application was discovered running on a GCP instance linked to one of F5 Networks’ cloud accounts. By querying the GCP metadata service, we were able to impersonate the default service account <span style="font-family: monospace;font-size: smaller;">XXX-compute@developer.gserviceaccount.com</span>, ultimately gaining read access to multiple storage buckets - some containing logs, metrics, and other sensitive data.
<div class="swiper swiper-slider" data-speed="1200" aria-label="Image slideshow"> <div class="swiper-wrapper"> <div class="swiper-slide"> <figure class="slide-media"> <img src="https://cdn.prod.website-files.com/6637ec84acdca762bbea2e39/68a240c417cccfe17d5d87ba_Cloudflare%20-%20bucket%20globalse-198312_cloudbuild%20content.png" alt="Trunk server app controller – claims routes" class="medium-zoom-image" loading="lazy" sizes="(max-width: 800px) 100vw, 1482px" /> <figcaption class="caption"> <div class="caption-wrap"> <div class="caption-title">Trunk Server – App Controller</div> <div class="caption-subtitle">Temporary <strong>/claims</strong> routes</div> </div> </figcaption> </figure> </div> <div class="swiper-slide"> <figure class="slide-media"> <img src="https://cdn.prod.website-files.com/6637ec84acdca762bbea2e39/68a240c4a7681f6518aab0d7_Cloudflare%20-%20gcloud%20list%20buckets.png" alt="Supply chain concept" class="medium-zoom-image" loading="lazy" /> <figcaption class="caption"> <div class="caption-wrap"> <div class="caption-title">Supply Chain Exposure</div> <div class="caption-subtitle">Opaque dependencies widen blast radius</div> </div> </figcaption> </figure> </div> <div class="swiper-slide"> <figure class="slide-media"> <img src="https://cdn.prod.website-files.com/6637ec84acdca762bbea2e39/68a240c4c3c1b8befe0e00ef_Palo%20Alto%20-%20AWS%20Org%20(Notice%20paloalto%20email)%20VVV.png" alt="Developer dashboard" class="medium-zoom-image" loading="lazy" /> <figcaption class="caption"> <div class="caption-wrap"> <div class="caption-title">Developer View</div> <div class="caption-subtitle">Package trust & provenance matter</div> </div> </figcaption> </figure> </div> <div class="swiper-slide"> <figure class="slide-media"> <img src="https://cdn.prod.website-files.com/6637ec84acdca762bbea2e39/68a240c41b6574571b302974_UpWind%20-%20I%20have%20permissions.png" alt="Developer dashboard" class="medium-zoom-image" loading="lazy" /> <figcaption class="caption"> <div class="caption-wrap"> <div class="caption-title">Developer View</div> <div class="caption-subtitle">Package trust & provenance matter</div> </div> </figcaption> </figure> </div> <div class="swiper-slide"> <figure class="slide-media"> <img src="https://cdn.prod.website-files.com/6637ec84acdca762bbea2e39/68a240c43bda1905055ac245_F5%20-%20list%20bucket.png" alt="Developer dashboard" class="medium-zoom-image" loading="lazy" /> <figcaption class="caption"> <div class="caption-wrap"> <div class="caption-title">Developer View</div> <div class="caption-subtitle">Package trust & provenance matter</div> </div> </figcaption> </figure> </div> <div class="swiper-slide"> <figure class="slide-media"> <img src="https://cdn.prod.website-files.com/6637ec84acdca762bbea2e39/68a240c4ccfcae2e34c92e01_Palo%20Alto%20-%20ecsInstanceRole%20is%20admin%20on%20the%20env%20VVV.png" alt="Developer dashboard" class="medium-zoom-image" loading="lazy" /> <figcaption class="caption"> <div class="caption-wrap"> <div class="caption-title">Developer View</div> <div class="caption-subtitle">Package trust & provenance matter</div> </div> </figcaption> </figure> </div> </div> <div class="swiper-button-prev" aria-label="Previous slide"></div> <div class="swiper-button-next" aria-label="Next slide"></div> <div class="swiper-pagination"></div> </div>
Evidence of Active Exploitation in the Wild
An interesting discovery emerged during the assessment of several misconfigured vulnerable applications, hosted both on-premises and in the cloud. While establishing shells on these machines and enumerating internal data to determine their owners, we found clear evidence that this attack vector was already being exploited in the wild. In multiple cases, we identified obfuscated files and scripts that had been deployed by a previous malicious actor. These artifacts included webshells, crypto-mining binaries, and persistence mechanisms - indicating that the compromised environments had been leveraged for both resource abuse and potential lateral movement.
Anatomy of a Real-World Attack
To illustrate the anatomy of such an attack, here’s a real-world step-by-step <u>example using DVWA</u> – a widely deployed intentionally vulnerable application:
#1: Accessing The “Lab”
Attackers first gain access to the application — most often via default credentials or well-known exploits such as SQL injection. In DVWA, 54% of instances (334 out of 616 discovered) still used the default credentials <span style="font-family: monospace;font-size: smaller;">admin:password</span>
This not only grants admin access, but also allows attackers to downgrade DVWA’s internal security settings from “impossible” to “low” with a single click, making every built-in vulnerability trivially exploitable.
#2: Remote Code Execution (RCE) via File Upload or Command Injection
Once inside, the next step is executing arbitrary code on the server.In DVWA, this is possible by exploiting the insecure file upload module to deploy a <span style="font-family: monospace;font-size: smaller;">.php</span> payload.
For example, uploading a crafted script named "gcp_extract_metadata" and browsing to<span style="font-family: monospace;font-size: smaller;">https://TARGET_APP/hackable/uploads/gcp_extract_metadata.php</span> triggers execution in the server’s context.
#3: Persistent Foothold & Cloud Credential Harvesting
With RCE confirmed, attackers can quickly transition from testing to persistence and privilege escalation - spawning an interactive shell, installing a backdoor, deploying a crypto miner, or beginning reconnaissance on the compromised host.
Since this research focused on cloud-hosted environments (AWS, GCP, Azure), the payload was built to immediately perform automated reconnaissance and credential theft. It was capable of:
- Scan for SSH keys, API tokens, and config files
- Search for hardcoded secrets in environment variables and files
- Search for hardcoded secrets in environment variables and files
- Extracting cloud identity name and credentials via the cloud metadata service
- Query cloud metadata services (http://169.254.169.254/) to extract IAM role/cloud identity credentials
#4: Escalation to Cloud Environment Compromise
At this stage, the game changes. With valid IAM role credentials in hand, attackers are no longer bound to the vulnerable application’s server - they now have the keys to the organization’s cloud account.
In real-world cases from this research, this meant moving directly into the provider’s management plane and running high-impact operations, such as:
- Listing and downloading every object from S3, GCS, or Azure Blob Storage
- Pulling and pushing images in ECR or Artifact Registry, including inserting backdoored containers
- Accessing secrets managers to harvest API keys, database passwords, and CI/CD tokens
- Spinning up compute instances for persistence or crypto mining - often under the company’s billing account
- Modifying IAM policies to ensure ongoing administrative access
In multiple verified incidents, this pivot went as far as granting administrator privileges across the entire cloud account. That level of access allows an attacker to exfiltrate sensitive data, destroy resources, or embed long-term persistence mechanisms - all without touching the original lab again.
From here, the vulnerable application becomes irrelevant. The attacker now operates entirely within the organization’s cloud environment.
Root Causes: How Did These Labs Become Serious Threats?
After analyzing hundreds of exposed training applications, I identified several recurring issues. These root causes explain how seemingly harmless training apps can lead to serious cloud security breaches:
# Shadow IT and Forgotten Deployments:
Many vulnerable training apps are deployed informally—by developers or security engineers for demos, tests, or experiments—without notifying IT or security teams. Often, these deployments are forgotten, left online indefinitely, and excluded from asset management and monitoring systems, becoming invisible attack surfaces.
# Default Credentials & Misconfigurations:
Intentionally vulnerable apps are designed with insecure default configurations to demonstrate security flaws. However, when organizations fail to alter these settings—leaving default passwords, open registrations, or insecure debugging modes enabled—attackers gain easy entry points.
# IAM Permissions Mismanagement:
One of the most critical findings involved overly permissive IAM roles/cloud identities attached to test environments. Rather than using tightly scoped roles, teams frequently granted broad access, even Administrator privileges, to supposedly temporary or low-risk systems. This oversight dramatically escalates the potential impact of a breach.
# Underestimating the Risks of "Test" Environments:
A common misconception is that "test" or "dev" environments pose minimal risk. But attackers don't discriminate based on labels—many training apps were hosted alongside real data, credentials, or production infrastructure. Misplaced trust in these labels leads to inadequate protections, monitoring, and oversight.
All of these factors are security oversights. They highlight the need for better governance around even lowly test resources. In an era of cloud and Infrastructure-as-Code, it’s easy for anyone to spin up a service, and just as easy to forget about it. But as we saw, the risks are very real.
Conclusion: Vigilance Is Crucial for Training and Testing Environments
In cybersecurity, most breaches don’t start from complex zero-day vulnerabilities—they begin with simple mistakes, forgotten deployments, and insecure defaults. Training apps, though valuable tools for education and demonstration, quickly turn dangerous if left unmonitored and unprotected.
Organizations must understand that labeling something as "test," "dev," or"training" doesn't remove the need for careful security management.Any publicly accessible resource is a potential attack vector, especially when cloud credentials or sensitive data might be within reach.
The lesson here is straight forward but critical: Training environments should never be treated as disposable or low-risk. With proper visibility, continuous monitoring, and disciplined security practices, companies can ensure their valuable security exercises remain just that - valuable and secure.
After all, good security isn't just about knowing the latest attack methods - it's about consistently applying basic hygiene and maintaining vigilance everywhere, including the lab.
