A healthcare software provider believed its segmented environment was reasonably secure.
The company had invested heavily in layered controls across a distributed workforce, separating developer environments, segmenting cloud infrastructure, and tightly managing administrative access. MFA was enforced broadly, vulnerability scanning was routine, and annual penetration tests were part of the organization’s broader security and compliance efforts.
At least, that was the assumption.
Then an insider threat pentest with NodeZero® showed how quickly a single compromised developer credential could enable lateral movement through the environment and toward cloud infrastructure supporting software delivery.
“It owned our network in a matter of minutes,” said the company’s IT Operations Leader.
That result changed the conversation immediately. This was not simply a healthcare organization protecting endpoints and servers. It was a healthcare software provider operating in a position of downstream trust, where a compromise would potentially impact customers, healthcare operations, and the systems relying on their software.
The organization realized that annual pentests and scanner output were not enough to answer the question that actually mattered: what can an attacker really do once inside the environment?
That realization pushed the company toward continuous validation, repeated testing, and a far more operational approach to exposure management.
Image 1: Initial internal testing identified 16 weaknesses compromising 4 hosts which led to AWS compromise and sensitive data exposure.
The security team believed their network was secure. That was until they were able to understand what an attacker could do if he arrived in their network.The real question was whether they truly understood what an attacker could do once those weaknesses were chained together inside a real environment.
Like many software providers, the organization operated with a widely distributed workforce, extensive developer access requirements, hybrid infrastructure, and growing cloud dependencies.
Before adopting NodeZero, the company relied heavily on traditional vulnerability scanning and annual penetration testing. The team understood the limitations immediately after running NodeZero for the first time
The insider threat pentest exposed how quickly those assumptions did break down.
“When you think about what an annual penetration test is, it’s a snapshot at a moment in time,” said the Security Leader. “Technology does not stand still. It only changes.”
The team initially attempted a phishing impact pentest paired with their Microsoft 365 environment, but no employees entered credentials during the exercise. Rather than stopping there, and trusting their employees would never fall for a phish, the organization decided to model a more realistic compromise scenario by asking three employees — a developer, someone in HR, and someone in support — to intentionally submit credentials into the phishing pentest so the team could observe what an attacker could actually do with different levels of access.
That decision quickly exposed where the real risk existed.
The HR and support accounts were effectively contained, but once NodeZero impersonated the developer account, the attack path expanded rapidly. The platform cracked password hashes, escalated privileges, moved laterally across segmented environments, and attempted to traverse toward AWS-connected resources.
“We’re completely segmented,” said the Security Leader. “We thought we were fine by being siloed. But NodeZero jumped the segments.”
The speed of the compromise surprised the team, but the path itself was even more important. A single developer system with elevated access had effectively become the pivot point that would allow attackers to move through the environment.
That moment reframed the problem entirely. The organization was no longer looking at isolated vulnerabilities. It was looking at exposure, attack chaining, and the reality that one compromised developer credential could potentially become something much larger.
Image 2: NodeZero demonstrated how a compromised developer path could move laterally across segmented environments to obtain host compromise.
The organization’s response to those findings was shaped largely by its leadership culture. The security team did not have to convince executives that healthcare organizations and technology providers were increasingly in the crosshairs of ransomware operators and financially motivated attackers.
“We’re not oblivious to it,” said the Security Leader. “We’re a healthcare technology provider. We fall closer to the bullseye than the outer rings.”
That awareness changed how the organization approached security investments. Instead of treating security spending as a compliance obligation, leadership evaluated decisions through the lens of operational and business risk.
“When we need something, it’s not necessarily ‘what’s it going to cost us,’” said the IT Operations Leader. “It’s ‘what’s it going to cost us if we don’t do this?’”
The organization also recognized that scanner output alone was not enough to prioritize risk effectively. Vulnerability data identified weaknesses, but it did not explain which weaknesses could actually be exploited or how attackers might move through the environment once initial access was obtained.
“Why don’t we put a tool against the full scope of the environment and find out what we don’t know?” the Security Leader explained.
That shift — from identifying vulnerabilities to validating exploitability — changed how the organization approached security operations moving forward.
The insider threat pentest exposed a critical weakness in the organization’s operational model: developer access.
A developer system with elevated permissions became the pivot point that allowed NodeZero to escalate privileges and move laterally through the environment. The organization responded quickly by eliminating overly permissive access across the environment and implementing privileged access workflows that required approval before administrative commands could execute.
“We need to take away convenience and focus more on security first,” said the Security Leader.
The organization also expanded MFA enforcement deeper into administrative and development workflows while increasing its focus on validating cloud attack paths. During internal testing, NodeZero attempted to traverse toward AWS-connected resources and cloud infrastructure supporting development operations. Existing cloud separation controls prevented compromise of source code repositories and build environments, but the attempted movement reinforced the need to continuously validate cloud attack paths instead of assuming IAM and segmentation controls were sufficient.
Initial AWS testing identified:
Post remediation AWS testing identified:
That progression mattered because it demonstrated measurable reduction in exploitable cloud attack paths rather than theoretical improvement.
Image 3: Initial AWS testing identified critical (score of 10) exploitable weaknesses that resulted in AWS full account compromise and sensitive data exposure
Image 4: Initial AWS testing where NodeZero obtained AWS full account compromise.
Image 5: Post remediation AWS findings were reduced to two low-severity weaknesses with no business impact.
The organization also expanded phishing pentests and credential-based testing to better model how real attackers operate inside their environments.
“We wanted to try to be as close to real life as possible,” said the IT Operations Leader.
The biggest shift was not technical. It was operational.
Instead of treating penetration testing as a yearly compliance requirement, the organization built a repeatable monthly cadence around testing, remediation, and validation.
“We scan the first week, we plan the second, we remediate the third, and we monitor the fourth,” said the IT Operations Leader.
That cadence produced measurable improvement over time.
The team also used repeated testing to validate whether remediation efforts actually removed attack paths instead of simply closing tickets. That distinction changed internal conversations because the organization no longer relied on assumptions about whether controls were functioning correctly. Teams could continuously test, validate, and measure improvement over time, and leadership supported those operational changes immediately.
“The executives didn’t put their heads in the sand,” said the Security Leader. “They accepted that change had to happen.”
That support allowed the organization to reduce excessive privilege, tighten developer access, harden segmentation boundaries, and continuously validate whether attackers could still move through the environment.
Many organizations believe segmentation, MFA, vulnerability scanners, and annual pentests provide enough visibility into risk. This healthcare software provider learned something different.
A single compromised developer path exposed hidden attack chains that traditional approaches had not surfaced. Segmentation alone did not stop lateral movement, vulnerability data alone did not explain real exposure, and annual assessments did not reflect how quickly environments changed.
Continuous validation changed that.
Over time, the organization reduced exploitable attack paths across internal systems, phishing scenarios, and AWS infrastructure by operationalizing repeated testing, remediation, and verification. More importantly, the organization stopped relying on assumptions.
“Ultimately, our goal is to make sure our staff has jobs to come to each day,” said the IT Operations Leader.
That perspective reframed the problem entirely. Not as compliance or vulnerability management, but as the ongoing responsibility to continuously validate that it is not possible for a real adversary to traverse their environment.