Check your dev and test environments for hidden attack paths to production
Audits often miss critical flaws. Three firms found that excluded environments and limited testing left them exposed to real attacks.
Key points
- A US insurer found its development environment was not isolated from production, allowing an attacker pivot via cracked credentials.
- A global payments provider discovered that required annual pentests missed default passwords and misconfigurations across global offices.
- Both organizations adopted continuous exposure management to validate assumptions and verify that remediation efforts actually closed attack paths.
Security audits and penetration tests often fail to reveal the full scope of an organization’s exposure to attackers. Research published by Horizon3.ai illustrates how three financial and insurance organisations discovered significant gaps between their audit compliance and their actual defence capabilities. These cases show that passing a regulatory check does not guarantee that an environment is secure against a determined adversary who can exploit overlooked access paths or weak credentials.
Why do standard audits miss critical security flaws?
Audits typically verify that an organisation meets specific control requirements, but they do not always test whether those controls hold up against active exploitation. For instance, a development environment might be assumed to be isolated from production systems, or a single penetration test might satisfy banking regulations without covering the entire infrastructure. These assumptions create blind spots. Security teams may believe an environment is low risk or that a remediation ticket has closed a vulnerability, but without evidence of actual attack simulation, those beliefs remain untested and potentially false.
How did the US insurer’s development environment get compromised?
The insurer had excluded its development environment from monthly penetration tests because developers considered it isolated and low risk. When Horizon3.ai’s NodeZero tool finally tested the environment, it found 266 cracked passwords, including 146 accounts sharing the same password. It also identified overprivileged service accounts and an unpatched ActiveMQ service. The tool exploited the ActiveMQ service to deploy a remote access tool, which compromised a service account with Domain Admin privileges in the production domain, creating a direct path from development to production.
What blind spots did the payments provider discover?
The global payments provider complied with banking partner requirements for two annual penetration tests, but these engagements only examined limited portions of its distributed environment. Previous tests had not reported issues such as default passwords on infrastructure devices, exposed ESXi management ports, or misconfigured systems across global offices. One weak credential allowed access to nearly 300,000 files in approximately two hours. The organisation lacked a consistent view of what remained untested, leaving significant exposure despite meeting regulatory testing mandates.
How did these organisations improve their security posture?
Both organisations shifted towards continuous exposure management to challenge their security assumptions. The insurer overhauled password policies, restricted privileged accounts, and expanded collaboration between security and development teams to validate weaknesses and test fixes. The payments provider adopted quarterly testing across more than 50 networks, ensuring every IP within its scope was tested. It also used automated verification to confirm that critical weaknesses were remediated. This consistent methodology provided auditors with proof of remediation and broader coverage than previous manual tests.
What affected people can do
Employees and users should verify that their organisation tests all environments, including development and staging, not just production. Check if your company has a process for validating that security fixes actually close attack paths rather than just closing tickets. Be aware that weak or shared credentials in non-production systems can still lead to production compromises. Report any unusual access requests or shared passwords immediately. Understand that compliance certificates do not equal security; ask your IT team how they verify that isolated environments remain truly isolated from core business systems.
What to do and how to stay safe: Horizon3.ai
- Ensure all network segments, including development and testing environments, are included in regular security testing and exposure assessments.
- Implement continuous monitoring to verify that remediation efforts effectively close identified vulnerabilities and attack paths.
- Enforce strict password policies and eliminate shared credentials, particularly for service accounts with elevated privileges.
- Validate that security controls and isolation assumptions hold up against simulated attacks, not just theoretical audits.
Step-by-step guide: Is It Safe to Use Password Managers? The Real Risks and Rewards
General security guidance from the DarkWeb Dispatch newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does passing a security audit mean an organisation is attack-ready?
No, passing an audit establishes that an organisation meets defined requirements, but it does not guarantee that every assumption about access and segmentation has been tested against actual attacker capabilities.
What specific risks were found in the insurer’s development environment?
The development environment contained cracked passwords, overprivileged service accounts, and an unpatched ActiveMQ service that allowed a pivot into the production domain.
How did the payments provider improve its testing coverage?
The provider adopted quarterly testing across more than 50 networks and used automated verification to confirm fixes, providing consistent coverage and proof of remediation to auditors.
