One Developer Password Unlocked Everything: Inside a Healthcare Software Provider's Wake-Up Call
A company that thought its segmented cloud setup was secure ran a simulated attack and watched a single stolen developer credential unravel four years of layered defences in minutes.
Key points
- A healthcare software provider ran a simulated insider attack and found 16 separate weaknesses that, chained together, gave attackers a path from a developer's laptop to sensitive data stored in Amazon Web Services (AWS), the company's cloud platform.
- The breach path bypassed network segmentation, meaning the digital walls the company built between departments did not stop the simulated attacker from jumping between them.
- After fixing those weaknesses, the company reduced its critical cloud exposure to two low-severity issues that could not be combined into a damaging attack.
- A developer account carried far more access than an HR or support account, making it the single highest-risk entry point in the environment.
- The company now runs attack simulations every month rather than once a year.
A healthcare software provider thought its defences were solid. It had split its network into separate zones, managed who could access what, and made staff use multi-factor authentication (MFA), the practice of proving your identity with a password plus a second check such as a text message or app approval. Routine scans hunted for known vulnerabilities. Outside security experts tested the systems once a year. Then one simulation changed the entire picture.
The company ran what is called an insider threat penetration test, meaning security professionals used a tool called NodeZero to act as if they were a criminal who had already stolen an employee's login details. The goal was to find out how far a real attacker could get from that starting point.
How did the attack spread so fast?
The simulated attacker got into the developer account and tore through the company's network in minutes. NodeZero cracked password hashes (scrambled versions of passwords stored on company servers), climbed to higher levels of access, and jumped across the segmented zones the company believed would contain any breach.
"We're completely segmented," the company's IT operations leader told CSO Online. "We thought we were fine by being siloed. But NodeZero jumped the segments."
The platform then reached AWS, the cloud service the company uses to deliver its software to healthcare customers. A single developer account had become the pivot point for the whole attack chain.
To make the test realistic, three employees, a developer, an HR staff member, and a support worker, voluntarily entered their credentials into a fake login page. The HR and support accounts went nowhere useful. The developer account opened almost everything.
| Finding | Before fixes | After fixes |
|---|---|---|
| Weaknesses identified | 16 | 2 |
| Hosts fully taken over | 4 | 0 |
| AWS critical exposure | Yes | No |
| Severity of remaining issues | Critical | Low, not chainable |
| Testing cadence | Annual | Monthly |
Why does this matter to healthcare customers?
This company did not just hold its own data. Its software ran inside other healthcare organisations, meaning a real attack could have rippled outward to hospitals, clinics, or patient record systems that relied on it. That kind of supply-chain risk, where criminals break into a software provider to reach its customers downstream, has driven some of the most damaging incidents of recent years.
The company's IT leader put it plainly: "Ultimately, our goal is to make sure our staff has jobs to come to each day."
What changed after the test?
The company fixed all 16 weaknesses. It removed the excessive admin rights that let the developer account roam so freely, introduced approval workflows for privileged access (tasks that carry the highest level of system control), and expanded MFA to cover more accounts. Monthly testing replaced the annual snapshot.
"When you think about what an annual penetration test is, it's a snapshot at a moment in time," the operations leader said. "Technology does not stand still. It only changes."
If your organisation uses software built by a third-party provider, it is worth asking that vendor how often it tests its own internal security, not just whether it holds a compliance certificate.
