From sandbox to front door, the real danger of cloud training laboratories

The intentionally insecure environments - those applications designed to teach hacking and penetration tests - have for years been a valuable tool for learning, doing demos and testing security controls. Projects known as OWASP Juice Shop, DVWA, bWAPP or commercial laboratory environments offer scenarios where errors and bad practices can be studied without risk... as long as they remain confined.

The problem arises when those laboratories are no longer confined. Recent research into Pentera Labs He identified a worrying pattern: instances created for training or demonstration that end up exposed to the Internet, running within active cloud accounts and, more seriously, linked to identities and roles with excessive permissions. This combination makes what should be an educational environment a real gateway to the productive environment.

The findings are strong: Pentera identified almost two thousand public instances of training applications and found that a significant part of them ran on infrastructure managed by the customers themselves in the large cloud suppliers - AWS, Azure and Google Cloud. In addition, in a significant fraction of cases the teams found evidence of previous malicious activity, from cryptomoneda mining to webshells and persistence mechanisms.

The logic of the attack does not need extreme sophistication. With default credentials, open settings or known vulnerabilities, an attacker can take control of the training application and, if that application is linked to roles or identities with privileges, pivote and access other resources in the same cloud account. That transforms a sandbox into a step towards more far-reaching commitments.

This problem is not anecdotal or limited to small organizations. Pentera observed the pattern in environments linked to large companies and security providers, which shows that the risk affects both mature organizations and those in the process of improving it. Labelling a resource as "practice" or "temporary" does not make it invisible to attackers or exempt it from operational risks if exposed.

Why is it? In many IT and security teams, educational environments are considered of low value and are outside regular reviews, inventories and monitoring systems. They are quickly created for a course or demo, used, and sometimes remain active for months without any question of their configuration, associated credentials or the extent of their access. Over time, oblivion can become exploitation.

Mitigating this type of risk requires simple but firm measures. First, keep these environments isolated: private networks, separate VPCs or independent sandbox accounts / projects. Secondly, apply the principle of less privilege in identities and roles linked to laboratories and demos. Third, automate inventory and monitoring to detect publicly exposed resources or images with default settings. And fourth, adopt "lifecycle" practices: maintain automatic creation and destruction routines so that environments only exist for the time needed.

The big clouds offer guides and tools for these practices: Amazon publishes architectural and security recommendations for cloud environments at its center of good practices ( AWS Security), Microsoft maintains extensive safety documentation in Azure ( Azure Security) and Google Cloud publishes its controls and recommendations ( Google Cloud Security). It is also useful to rely on community standards and resources such as OWASP Top Ten to understand common attack vectors in web applications.

In addition to the configurations and permissions, the public area should be monitored with tools and services for the detection of exposed assets. Connected devices and services search platforms, such as Shodan, and native cloud inventory services help quickly identify open instances that should remain closed. Telemetry, centralized loops and alerts are vital to detect suspicious activity, from indicative cryptomoneda mining patterns to unusual connections to cloud metadata.

For training equipment, there are safe alternatives: using temporary environments that are automatically arranged and destroyed, managed laboratory platforms that offer default network isolation or deploy exercise and scenarios in fully segregated accounts without shared credentials with productive environments. Implementing strong authentication and not reusing known credentials by default is a basic practice that avoids many incidents.

The lesson is clear: the "training" label does not reduce technical risk. When a vulnerable application is accessible from the Internet and is connected to identities with the ability to interact with the rest of the infrastructure, it becomes part of the exposed perimeter of the organization. Protecting this perimeter requires integrating laboratory environments into the same policies and controls as other assets.

If you want to deepen the methodology and concrete findings, the complete research of Pentera is available on your blog and also offer a web seminar explaining the process of discovery and evidence observed: report by Pentera Labs and related webinar. For those who manage clouds, consult the suppliers' official guides and align with recognized safety practices is a good starting point for a laboratory to remain a learning tool rather than a path of attack.