Notifications
Clear all
Topic starter
02/08/2026 12:05 pm
TL;DR: 1,926 verified vulnerable training and demo applications were found online, with 109 exposed credential sets and active evidence of miners, webshells, and persistence in the wild, showing how “test” environments can become cloud compromise entry points, according to Pentera. The control gap is not discovery alone, but the combination of default exposure, over-privileged IAM, and weak environment lifecycle governance.
NHIMG editorial — based on content published by Pentera: From misconfigured cloud environments to wormable crypto-miners and exposed training apps
By the numbers:
- Out of the 1,926 verified applications, 1,626 unique servers were identified.
- 60% of those servers, servers, 974 in total, ran on enterprise-owned infrastructure across AWS, Azure, and GCP.
- Pentera found 109 exposed credential sets tied to unique identity or role names.
Questions worth separating out
Q: What breaks when a training environment is left internet-facing with a cloud role attached?
A: The boundary between a low-risk lab and a privileged cloud account disappears.
Q: Why do non-production workloads complicate least-privilege governance?
A: Because teams often grant them broad access to make demos and testing easier, then forget to tighten it later.
Q: What do security teams get wrong about demo and test systems?
A: They treat the application label as a risk signal and ignore the identity and network posture underneath it.
Practitioner guidance
- Inventory every non-production workload with cloud identities Create a complete register of demo, training, and test systems, including the cloud role or service account attached to each one.
- Remove public reachability from lab environments Place training and demo applications behind internal access paths, private endpoints, or segmented networks.
- Constrain attached roles to the minimum viable scope Replace broad policies such as administrator-level access with purpose-specific permissions for each environment.
What's in the full report
Pentera's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step fingerprinting and verification workflow for discovering exposed vulnerable applications at scale
- The exploitation path from public exposure to metadata-service credential theft and management-plane access
- Per-vendor case studies showing how specific cloud roles and misconfigurations produced different blast radii
- Details of the SigInt reconnaissance workflow used to automate discovery and attribution
👉 Read Pentera's analysis of exposed training apps and cloud compromise paths →
Exposed training environments: are your cloud controls keeping up?
Explore further
02/08/2026 1:10 pm
Non-production environments are identity-bearing assets, not disposable labs. The article shows that a "test" or "demo" label does not reduce risk when the workload is internet-facing and linked to powerful cloud permissions. In practice, the privilege carried by the attached identity matters more than the purpose of the app. For identity governance, the control question is whether the environment has a bounded, reviewable identity lifecycle.
A question worth separating out:
Q: Who is accountable when unauthorized access persists in a cloud environment?
A: Accountability sits with the team that owns identity lifecycle, access governance, and the systems that issue or retain privileges. In practice that usually means IAM, cloud security, and the business owner of the access path must share responsibility for revocation, review, and monitoring.
👉 Read our full editorial: Exposed training apps turn cloud labs into full account compromise
