Incidents & Vulnerabilities
Osaka General Medical Center ransomware (2022) — a contractor's VPN as the way in, and hospital BCP
Osaka General Medical Center's 2022 ransomware: the entry was a meal-service contractor's unpatched maintenance VPN, and shared passwords plus weak segmentation spread it across the EMR, halting care for months. How you defend contractor links, credentials, segmentation, and medical BCP.
We read a real, public incident not as a news rerun but through "how would you defend against this?" This is an explainer based on public records (the official investigation committee report and reporting). Sources are listed at the end; we do not include attack how-to or personally identifying details. Contractor and vendor names are not the point, so we describe them by role rather than naming them.
- Target
- Osaka General Medical Center (Osaka Prefectural Hospital Organization). Hospital systems including the EMR
- Detected
- Early hours of October 31, 2022 (a failure in the contractor's system, followed by the hospital's EMR failure)
- Entry (per the report)
- A remote-maintenance VPN device on the meal-service contractor's server — left unpatched, reachable with leaked credentials. Because hospital and contractor were constantly connected, attackers reached the hospital through the contractor
- Why it spread (per the report)
- Shared passwords across servers/PCs, broad admin rights, no antivirus on EMR servers, weak segmentation, and a "closed network is safe" belief
- Impact
- EMR down; outpatient care, planned surgery, and emergency intake restricted. Full recovery took over two months. The hospital reportedly did not pay the ransom
- The real fixes
- Inventory contractor links and patch internet-facing VPNs / end credential reuse and use least privilege / segment / EDR and monitoring / medical BCP (paper fallback, offline backups, rehearsed recovery)
What happened (in plain terms)
Ransomware encrypts systems to make them unusable and demands payment to restore them. Here, what broke first was not the hospital's front door but a side door. On the server of the company that supplied patient meals sat a VPN device for remote maintenance. Per the committee's report, that device was left unpatched and could be entered using previously leaked credentials.
The hospital's EMR and the contractor's system were constantly connected to exchange data such as meal counts. So if the contractor was breached, the attacker could reach inside the hospital — the contractor's weakness was the hospital's weakness. Once inside, the report explains why the damage spread across the entire EMR: login credentials were shared, many users held administrator rights, critical servers had no antivirus, and the network was not adequately segmented. With one entry point breached, little inside stopped the spread, and the encryption propagated fast. Outpatient care stopped, planned surgeries were cancelled, emergency intake was restricted, and full EMR recovery took over two months.
'A closed network is safe' is a myth — a contractor's link is your attack surface
A core finding was the "closed-network myth" — the belief that a network cut off from the outside is inherently safe. In reality there are always small holes in the closed network: maintenance VPNs, constant contractor links, remote support. With even one hole and no internal segmentation, a "closed" network becomes "one network where getting in once reaches everything." A contractor's or maintenance provider's connection may belong to another company on paper, but in security terms it is part of your attack surface and should be inventoried as such.
The attack chain is also a defense map
This too was a chain with a stop point at every stage. Read it not as attack steps but as where it could have been broken.
① Enter via the contractor's unpatched maintenance VPN + leaked credentials
An internet-facing maintenance VPN went unpatched and was reachable with previously leaked credentials.
⊘ Stop: patch internet-facing VPNs fast; inventory contractor links; MFA; revoke leaked credentials
② Hospital and contractor constantly connected → reach the internal network
A constant link for meal data meant a breach at the contractor reached inside the hospital.
⊘ Stop: isolate the contractor link in its own segment; minimize cross-segment traffic; monitor the boundary
③ Shared passwords, all-admin, weak segmentation → lateral spread to all servers
Shared credentials and broad rights let the encryption reach the EMR servers quickly.
⊘ Stop: end credential reuse; least privilege; segment the network; login monitoring and lockout
④ Weak antivirus/EDR and thin recovery prep → EMR down for a long time
Critical servers had thin defenses, and recovery took time, so care was restricted for weeks.
⊘ Stop: EDR/antivirus; offline backups and rehearsed recovery; medical BCP (paper fallback)
Published timeline
2022-10-31
A failure in the contractor's system in the early hours, followed by the hospital's EMR failure. Confirmed as ransomware; systems were shut down to stop the spread.2022-11
Outpatient care largely stopped, planned surgeries cancelled, emergency intake restricted to severe cases. Care continued on paper.2022-12
Core systems restarted in stages; outpatient care resumed progressively.2023-01-11
Systems including the EMR were largely fully restored — over two months to full recovery.2023-03-28
The information-security incident investigation committee published its report, citing the entry path, the factors behind the spread, and the "closed-network myth."
The root cause is not just "the entry" — it's the contractor plus how it spread
Writing this off as "the hospital's VPN got hit" misses the point. The entry was the contractor, but what spread the damage across the entire EMR was the internal setup — shared credentials, excessive rights, weak segmentation. The real question is whether damage could have been contained once someone got in.
Weaknesses the report identified (at the time)
- Entry via the contractor's unpatched maintenance VPN + leaked credentials
- Hospital and contractor constantly connected, so the contractor's weakness reached inside
- Shared passwords on servers/PCs and broad admin rights for users
- No antivirus on critical EMR servers; weak segmentation
- A "closed network is safe" belief that thinned out defenses
A defended setup (prevention)
- Inventory contractor links; patch internet-facing VPNs fast; MFA
- Segment the contractor connection and minimize its traffic
- End credential reuse; least privilege; login monitoring and lockout
- EDR/antivirus on critical servers; network segmentation
- Medical BCP: paper-fallback procedures, offline backups, rehearsed recovery
Medical BCP: even if systems stop, care cannot
For an ordinary company, "service down" may be the end of it; for a hospital, the question is continuity of care. So a medical BCP must assume the EMR is down for a long time and prepare, in peacetime, paper-fallback procedures to keep treating patients, alternative flows for tests, medication, and billing, plus offline/versioned backups and rehearsed recovery. Paying a ransom guarantees neither recovery nor silence — rely on segmentation, backups, and BCP prepared in advance. (Related: the Capcom incident, where an old VPN/network device was the way in; and the KADOKAWA incident, where thin segmentation spread damage company-wide.)
Preventing a repeat in your environment
This applies well beyond hospitals — to any organization with contractor or maintenance connections. In priority order:
Inventory contractor/maintenance links as your own attack surface
Map who, which device, and which path connects to you. Keep internet-facing VPN devices patched as a top priority and close connections you don't use. Require the same patch and authentication standard from contractors, in contract and in practice.
End credential reuse; move to least privilege
Retire shared passwords on servers/PCs, separate accounts, and drop blanket admin rights for least privilege. Apply multi-factor authentication where you can, add login lockout and monitoring, and revoke leaked credentials.
Segment the network by importance
Put contractor links, the EMR, and back-office systems in separate segments and minimize cross-segment traffic. "Closed network" is not "safe" — segment inside the closed network too. Fold this into your organizational security baseline.
Defend critical servers, and build medical BCP and recovery
Put EDR/antivirus on critical servers like the EMR. Decide, in peacetime, how you keep treating patients and operating if core systems are down for a long time — with paper procedures, offline backups, and rehearsed recovery. Prepare as if payment will not restore you.
Where this mirrors this site's design principles
The takeaway is that your defense does not end at your own fence — a contractor's or maintenance connection becomes your attack surface. That is the inverse of this site's own principles: minimize blast radius, isolate what matters, keep connections and privileges minimal. "A closed network is safe" carries the same danger as one shared password reaching every server, or a single point of failure. Inventory what connects to you, end reuse, segment by importance, and prepare to keep going when things stop — defenses anyone can implement, regardless of size or sector.
Sources (public records)
The facts here are based on the public information below. We do not include attack how-to, personally identifying details, or contractor/vendor names — only the defensive lessons.
- Osaka Prefectural Hospital Organization, Osaka General Medical Center — "Information Security Incident Investigation Committee Report" (published March 28, 2023) — gh.opho.jp
- Reporting (entry via the contractor's maintenance VPN, shared passwords, the closed-network myth, and the recovery, 2022–2023) — based on the official committee report
Read next
- Glossary: what ransomware is (how it works and how to avoid paying) / what EDR is (endpoint/server detection)
- Practice: backup basics (the 3-2-1 rule) / the organizational security baseline (segmentation, least privilege)
- Cases: Handa Hospital ransomware (2021) (an unpatched VPN CVE and backup isolation) / KADOKAWA ransomware (2024) (thin segmentation spread it company-wide) / Capcom ransomware (2020) (an old VPN device was the way in) / Codecov supply-chain (2021) (abuse of a trusted path)
FAQ
QWhere did attackers get in during the Osaka General Medical Center incident?
According to the investigation committee's report, the entry point was not the hospital itself but a remote-maintenance VPN device on the server of the company contracted to provide patient meals. That VPN device had been left unpatched, and information matching a 2021 leaked-credential list reportedly worked against it. Because the hospital and the contractor's systems were constantly connected, attackers reached the hospital's internal network through the contractor. In effect, the contractor's connection was the hospital's own attack surface.
QWhy did the damage spread across the whole EMR system?
The report points to shared login IDs and passwords across servers and PCs, broadly granted administrator rights, no antivirus on critical EMR servers, and insufficient network segmentation — compounded by a false belief that a 'closed network' is inherently safe (the 'closed-network myth'). Once one entry point was breached, little inside stopped the spread, so the encryption propagated quickly.
QWhat are the top lessons for a hospital or a small organization?
1) Inventory contractor and maintenance connections as your own attack surface, and keep internet-facing VPN devices patched. 2) End credential reuse and shared passwords, drop blanket admin rights, and move to least privilege. 3) Segment critical systems and minimize cross-segment traffic. 4) Put EDR/antivirus on critical servers, with login monitoring and lockout. 5) Build business continuity (BCP) so care and operations continue even if core systems are down for a long time — paper-fallback procedures, offline backups, and rehearsed recovery.