Security teams often spin up vulnerable applications for demos, training, or internal testing. A recent Pentera research report documents how those environments are being left exposed on the public internet and actively exploited.
The research focuses on intentionally vulnerable apps such as OWASP Juice Shop, Damn Vulnerable Web Application, Hackazon, and similar projects. These tools are commonly deployed to teach secure coding, support product demonstrations, or give red and blue teams hands-on practice. According to the report, many of these apps were found running in default or misconfigured states with direct internet access.
Once exposed, the applications provided attackers with straightforward paths to remote code execution. From there, attackers were able to move deeper into cloud environments by harvesting credentials and abusing attached identity and access management roles.
Scanning for exposed lab environments
Noam Yaffe, Senior Security Researcher at Pentera, began by selecting ten well-known vulnerable applications that include known remote code execution paths. Each application was fingerprinted using elements such as favicon hashes, page titles, response strings, and unique URL paths. These fingerprints were then used to search public internet scanning platforms like Shodan and Censys.
Over 10,000 raw results were collected during this discovery phase. An enrichment process followed, adding context such as cloud provider, hosting information, reverse DNS data, and certificate details. After verification and filtering, the final dataset included 1,926 live and vulnerable applications that were accessible from the internet:
Most of the confirmed instances were hosted in major cloud platforms. About 60 percent were running in AWS, Google Cloud, or Azure environments. The remaining systems were hosted on other infrastructure and were excluded from deeper testing.
From vulnerable app to cloud access
The report shows how exploitation often moved beyond the training application itself. Automated tooling was used to exploit known flaws and establish code execution on the underlying host. Once access was gained, the tooling queried cloud metadata services to extract identity information and temporary credentials.
In 109 cases, exposed credential sets were linked to unique cloud identities or roles. Many of those roles had broad permissions that allowed access to storage services, secrets managers, container registries, and compute resources. Some roles provided administrative access to entire cloud accounts.
The research also uncovered active secrets on compromised systems, including API tokens, messaging platform keys, and container registry credentials. In several cases, sensitive source code and real user data were present in environments labeled as training or development.
Evidence of active exploitation
The study includes multiple examples showing that these exposures are being used by attackers in real campaigns. Around 20 percent of discovered DVWA instances contained artifacts linked to malicious activity. The most common payload was the XMRig cryptocurrency miner configured to mine Monero.
Beyond crypto mining, the researcher identified persistence mechanisms designed to survive cleanup attempts. These included watchdog scripts that restored deleted files, downloaded additional tooling, and removed competing malware. Web shells with hardcoded credentials were also found, providing ongoing access to compromised systems.
The tooling and infrastructure observed in these cases showed signs of coordination and repeat use across multiple targets. The report documents encrypted payload delivery, automated recovery, and structured process control within the malware.
Real-world vendor exposures
Several case studies in the report describe exposed training applications tied to large technology and security vendors. In each case, the vulnerable app was connected to a cloud account with permissions that enabled access to internal resources.
Examples include a bWAPP deployment linked to a Google Cloud account that allowed storage bucket access, and DVWA instances associated with AWS and Google Cloud projects that enabled broader account visibility. Each issue was responsibly disclosed and remediated before publication, according to the report.
Patterns across environments
Across all findings, the research points to recurring operational patterns. Training and testing environments often lack the same asset tracking, monitoring, and review processes applied to production systems. Default credentials and permissive access settings were common across many deployments.
The study also highlights how long-lived cloud resources can remain exposed long after their original purpose has passed. Virtual machines created for short-term demos or labs were still reachable months later with active permissions.
Recommendations
The report outlines practical steps for reducing this type of exposure. These include maintaining an accurate inventory of all cloud assets, applying strict least-privilege permissions to non-production environments, and enforcing lifecycle management so temporary systems expire automatically.
Additional recommendations include changing all default credentials before deployment, applying monitoring to training environments, and routinely scanning for exposed services using the same discovery techniques attackers rely on.
