One Developer Password Unlocked Everything: Inside a Healthcare Software Provider's Wake-Up Call

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 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.

The company 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. One simulation changed the entire picture.

Security professionals used a tool called NodeZero to act as if they were a criminal who had already stolen an employee's login details. 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 hit dead ends. The developer account opened almost everything.

How did the attack spread so fast?

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. "It owned our network in a matter of minutes," the company's IT operations leader told CSO Online.

"We're completely segmented," the operations leader said. "We thought we were fine by being siloed. But NodeZero jumped the segments."

The platform then reached AWS. A single developer account, loaded with elevated privileges that HR and support accounts did not carry, had become the pivot point for the whole attack chain.

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 and patient record systems that relied on it. That supply-chain risk, where criminals break into a software provider to reach its customers downstream, has driven some of the most damaging incidents in recent memory. Our 31 July report on the CareCloud breach showed what that looks like when it goes wrong: hackers spent nearly a week inside a healthcare IT company's cloud storage before anyone noticed.

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."

The operations leader's stated goal was blunt: keep staff employed by making sure a real adversary cannot traverse the environment unchecked. That's not a compliance framing. It's an operational one, and the difference matters.

If your organisation uses software built by a third-party provider, ask that vendor how often it tests its own internal security, not just whether it holds a compliance certificate. A certificate tells you what passed a check on one day. Monthly simulation tells you what an attacker can do today.