Security News

Cybersecurity news aggregator

📦
HIGH Attacks Dark Reading

'Damn Vulnerable' Training Apps Leave Vendors' Clouds Exposed

Over-permissioned training applications are being exploited by hackers to gain access to the IT systems of major security vendors. This supply chain attack poses a significant risk, potentially compromising the security vendors' own products and services.
Read Full Article →

Nate Nelson, Contributing Writer January 21, 2026 5 Min Read Source: C. Fish Images via Alamy Stock Photo Security vendors have been leaving deliberately insecure training applications on the public Internet, and attackers have been taking advantage of them to breach their cloud environments. What's the worst kind of asset an organization can leave open on the Web? A database? A management interface? An edge device with a known vulnerability? Organizations are constantly breached through means like these. In a newly published report , Pentera researcher Noam Yaffe highlights another lesser known but potentially more dangerous backdoor into organizations; a backdoor that, ironically, is more common among cybersecurity vendors than among anyone else: cybersecurity training applications. Insecure by design, hackers are already leveraging these all too often over-permissioned and exposed programs to access IT systems at major security vendors like F5 , Cloudflare , and Palo Alto Networks . Training Apps: A Doormat into the Enterprise Cloud "It was a Tuesday morning," Yaffe recalls, when he and a colleague were assessing a client's cloud security posture. "We found this app that looked broken. It didn't even look like their own product. We didn't really understand what it was." "We checked it out," he says, then "I realized I saw this somewhere before. I looked it up. It was called 'Hackazon.' And I was like: Oh, it's what they call a 'damn vulnerable app.'" Developed by Deloitte, Hackazon is a mock e-commerce site with software vulnerabilities built in. It's a training ground for users to learn about and practice their cyber skills. So while the content of the app was fake, those vulnerabilities were very real, not to mention publicly prescribed. What's worse: Yaffe's client ran the app directly in production, on the company's very real Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instance. So he picked at an insecure file upload vulnerability, obtained the power of remote code execution (RCE), jumped from the fake site to the real cloud instance's metadata service, and nabbed credentials. It turned out that not only did Hackazon have an identity and access management (IAM) role attached, but the role read "AdministratorAccess." "So we got the credentials, we connected to the full cloud environment, and then we gained lateral movement, being administrators of the client's whole cloud environment," Yaffe recalls. The Full Scope of Training App Risk His next question, naturally, was whether this might not be the only company whose training program doubled as a doormat for cyberattackers. Using open source (OSS) scanning tools, he probed the Web for more instances of Hackazon, and other damn vulnerable apps like it, including OWASP Juice Shop, Damn Vulnerable Web Application (DVWA), and Buggy Web Application (bWAPP). He found more than 10,000, then verified that 1,926 of them were active and accessible from the internet. They were deployed across 1,626 unique servers, though he chose to focus only on the 974 that ran on either AWS, Google Cloud (GCP), or Microsoft Azure . Of those 974, 165 had identity and access management (IAM) roles attached; 109 were overpermissioned, granting Yaffe ample ability to reach deeper and move laterally within the victim organization's cloud environment. In fact, the problem is far worse than this. For one thing, companies regularly spin up and take down training apps, but Yaffe studied the problem for only a few months. So even since he stopped looking, there are likely many more new damn vulnerable apps on the Web today. Plus, as mentioned earlier, Yaffe was only focused on apps running on major cloud platforms. He didn't even bother to test the 652 vulnerable servers that were self-hosted or deployed to less popular cloud platforms, which carry the same risks. Major Security Vendors Exposed With temporary cloud credentials in hand, it took Yaffe no time at all to realize the kinds of organizations he was now penetrating: large, global ones, Fortune 500 companies, and the like. For instance, in the case of the third or fourth company he exploited used DVWA, and when he penetrated its underlying cloud infrastructure, he recalls, "I was going into the organization's settings, and I saw the account was connected to Palo Alto Networks. And I was like, 'All right, I'm an admin inside of infrastructure at Palo Alto.'" In response to an inquiry from Dark Reading, a Palo Alto Networks spokesperson clarified that "this was an isolated training account containing no sensitive data. We immediately resolved the issue and verified that this environment was strictly segregated from all production systems and customer data. At no time were any Palo Alto Networks products or customer environments impacted." Ironically, the companies that are so vulnerable — those that most often use damn vulnerable apps — are typically in the cybersecurity industry. Yaffe's first client that exposed Hackazon was a security company. Besides Palo Alto, there was also F5, Cloudflare, and plenty of other big brands Pentera chose not to publicly disclose because those companies weren't as willing to cop to their mistakes. Dark Reading also contacted F5 and Cloudflare for comment on this story; neither of those vendors have yet responded. And it turned out that Yaffe wasn't the first one to recognize the potential in hacking companies through their training apps. Out of 616 Web servers running DVWA, 20% contained artifacts from cyberattacks. In particular, a number of compromised systems were being exploited to run the XMRig cryptominer. Interestingly, though, that was the worst of it. Why, with the opportunity for complete organizational compromise, did attackers stop at cryptomining ? "That's a question I asked myself," Yaffe recalls, though he hasn't yet figured out the answer. "I did let companies know, 'Hey, I found a cryptominer in your environment, meaning an attacker was sitting here. You should check if someone else accessed your temporary credentials. If so, what did they do?'" About the Author Nate Nelson, Contributing Writer Nate Nelson is a journalist and scriptwriter. He writes for "Darknet Diaries" — the most popular podcast in cybersecurity — and co-created the former Top 20 tech podcast "Malicious Life." Before joining Dark Reading, he was a reporter at Threatpost. See more from Nate Nelson, Contributing Writer

Share this article