Skip to content
>_ITDITDWeb Security Platform

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.

Published 2026-07-18 Updated 2026-10-04 12 min read

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.

Contractor VPN
Entry = the caterer's maintenance device, left unpatched
Shared PW + all-admin
Internal setup that let it spread across the hospital, per the report
2+ months
Time to full EMR recovery
Closed-network belief
'A closed network is safe': flagged by the report
Case file
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 and 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
Main 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 was breached first was not the hospital itself but a contractor's connection. 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. Once attackers got in at one point, 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 false belief; a contractor's link is part of your attack surface

A core finding was the belief that a network cut off from the outside is inherently safe. In reality there are always connections from the closed network to the outside: maintenance VPNs, constant contractor links, remote support. With even one such connection and no internal segmentation, an attacker who gets in once can reach 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.

Each stage of the attack and how to stop it

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 → 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)

Every step could have been stopped. Defense-in-depth means having several points where an attack can be stopped, not relying on one control.

Published timeline

  1. 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.
  2. 2022-11

    Outpatient care largely stopped, planned surgeries cancelled, emergency intake restricted to severe cases. Care continued on paper.
  3. 2022-12

    Core systems restarted in stages; outpatient care resumed progressively.
  4. 2023-01-11

    Systems including the EMR were largely fully restored — over two months to full recovery.
  5. 2023-03-28

    The information-security incident investigation committee published its report, citing the entry path, the factors behind the spread, and the belief that "a closed network is safe."

Root cause: not just the entry point, but contractor oversight and how the damage spread

Writing this off as "the hospital's VPN got hit" misses the point. The attackers came in through 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 must continue

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 normal times, 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 that the data won't be leaked. 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:

1

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.

2

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.

3

Segment the network by importance

Put contractor links, the EMR, and back-office systems in separate segments and minimize cross-segment traffic. A closed network is not automatically safe, so segment inside the closed network too. Fold this into your organizational security baseline.

4

Defend critical servers, and build medical BCP and recovery

Put EDR/antivirus on critical servers like the EMR. Decide, in normal times, 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 overlaps with this site's design principles

The takeaway is that your defense does not end at your own organization: a contractor's or maintenance connection becomes part of your attack surface. That is the opposite of this site's own principles: limit how far damage can spread if one part is breached, 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. These are 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 is safe" belief, and the recovery, 2022–2023) — based on the official committee report

FAQ

QWhere did attackers get in during the Osaka General Medical Center incident?
A

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?
A

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. Once attackers got in at one point, little inside stopped the spread, so the encryption propagated quickly.

QWhat are the top lessons for a hospital or a small organization?
A

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.