Incidents & Vulnerabilities
Tsurugi Handa Hospital ransomware (2021) — an unpatched VPN CVE and the backup trap
Tsurugi Handa Hospital's 2021 ransomware (LockBit): the way in was an internet-facing VPN left unpatched against CVE-2018-13379, reachable with leaked credentials — and primary plus backup, on the same network, were both encrypted. EMR recovery took ~2 months. How you defend internet-facing VPNs, credentials, and offline backups.
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 expert-committee report and reporting). Sources are listed at the end; we do not include attack how-to or personally identifying details. Vendor and contractor names are not the point, so we describe them by role rather than naming them.
- Target
- Tsurugi Handa Hospital (Tokushima Prefecture). Hospital systems including the EMR
- Detected
- Early hours of October 31, 2021 (ransom notes printed from printers; EMR and billing systems down)
- Entry (per the report)
- An internet-facing VPN device left unpatched against CVE-2018-13379, with leaked credentials that were never revoked
- Why it spread / recovery failed (per the report)
- Short passwords, no account lockout, users with admin rights → easy lateral movement. Primary and backup on the same network, both encrypted. A "closed network is safe" belief
- Impact
- EMR down with major disruption to care; ~85,000 patients' records inaccessible. Normal care resumed after about two months
- The real fixes
- Machine-monitor and fast-patch known CVEs on internet-facing devices / revoke leaked-and-reused credentials, MFA, least privilege, lockout / 3-2-1 + offline, immutable backups / segmentation / medical BCP
What happened (in plain terms)
Ransomware encrypts systems to make them unusable and demands payment to restore them. The way in here was not a sophisticated zero-day. On a VPN device the hospital exposed to the internet sat a vulnerability public since 2019 (CVE-2018-13379), still unpatched. Worse, that flaw had previously enabled a credential leak, and the hospital's device was on the leaked list. A long-unpatched public hole plus a leaked key that was never revoked — an open door for the attacker.
Once inside, the report explains why it spread: short passwords, no login lockout, and users holding administrator rights — one foothold could move across the hospital as an admin. And the worst part: the primary system and its backup were on the same network, and both were encrypted. The backup that was supposed to be there went down with production and could not be relied on for recovery. The EMR stayed down, and normal care resumed only after about two months.
'Having a backup' and 'being able to recover' are not the same
A backup is not insurance just by existing. Put it on the same network with the same privileges as production, and ransomware encrypts production and backup together (that is exactly how Handa Hospital lost both). What works is a backup that is isolated from production, kept offline/offsite, versioned, and ideally immutable — and that you have actually rehearsed restoring. The shorthand: 3-2-1 plus offline.
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.
① Internet-facing VPN unpatched against CVE-2018-13379 + leaked credentials → entry
A 2019 vulnerability remained, and leaked credentials were never revoked.
⊘ Stop: machine-monitor CVEs on internet-facing devices; patch fast; revoke leaked credentials; MFA
② Short passwords, no lockout, all-admin → lateral spread
From one foothold, admin rights let it reach broadly across the hospital.
⊘ Stop: strong auth; account lockout; least privilege; segmentation; login monitoring
③ Primary and backup on the same network → both encrypted
The backup was not isolated from production, so it was encrypted too.
⊘ Stop: offline/offsite, versioned, immutable backups (3-2-1)
④ EMR down for a long time → major disruption to care
Recovery took about two months, heavily affecting regional care.
⊘ Stop: rehearsed recovery; medical BCP (paper fallback); fast incident response and disclosure
Published timeline
2021-10-31
In the early hours, printers spooled ransom notes; the EMR and billing systems went down. A press conference was held the same day.2021-11
Care continued on paper. Investigation and recovery support began; data restoration was reported as feasible.2021-12
Restoration of EMR data was confirmed; recovery work proceeded in stages.2022-01-04
Systems were brought back and normal care resumed — about two months after the infection.2022-06
The expert committee published its investigation report, citing the entry path (an unpatched VPN vulnerability), the backup design, and the "closed-network myth."
The root cause is not just "the entry" — it's neglected basics
Writing this off as "the hospital's VPN got hit" misses the point. What was used was a known, public vulnerability — not a novel, sophisticated attack. Entry, spread, and failed recovery all stemmed from neglected basics: patching, credentials, and backup isolation. The report strongly criticizes selling and running an extremely vulnerable system without keeping it updated (we do not name the vendor). But the enduring point is this: even when you outsource operations, the risk remains yours.
Weaknesses the report identified (at the time)
- Internet-facing VPN left unpatched against CVE-2018-13379
- The device's credentials had leaked and were not revoked
- Short passwords, no lockout, users with admin rights
- Primary and backup on the same network, both encrypted
- A "closed network is safe" belief; thin IT capacity
A defended setup (prevention)
- Machine-monitor CVEs on internet-facing devices and patch fast; MFA
- Revoke leaked/reused credentials; least privilege; account lockout
- Backups isolated from production — offline/offsite, versioned, immutable
- Segment the network by importance (segment even a closed network)
- Rehearsed recovery and a medical BCP (paper fallback)
Outsource the work — you still own the risk
Even if a vendor builds and maintains your systems, it is your organization that suffers the outage, has care disrupted, and answers for it. So don't leave it to the vendor: confirm, in contract and in practice, "who patches internet-facing CVEs, when, and how," "is the backup isolated from production," and "when did we last rehearse recovery." (Related: the Osaka hospital incident, where a contractor's maintenance VPN was the way in; and the Capcom incident, where an old VPN device was the way in.)
Preventing a repeat in your environment
This applies well beyond hospitals — to any organization with internet-facing devices and backups. In priority order:
Machine-monitor known CVEs on internet-facing devices and patch fast
Monitor known vulnerabilities (CVEs) on internet-facing gear — VPNs, firewalls — and apply fixes promptly once published. Build a CVE remediation routine so "a known public CVE gets left unpatched" cannot happen structurally.
Cut leaked/reused credentials; move to least privilege
Revoke leaked credentials, stop reuse, and apply MFA where you can. Add account lockout and login monitoring, and don't hand out admin rights (least privilege).
Isolate backups from production and keep them offline (3-2-1)
Put backups on a separate network with separate privileges, kept offline/offsite, versioned, and immutable, and rehearse restoring them. This is the core defense against "backup got encrypted along with production."
Segment the network and build a medical BCP
Segment the network by importance (organizational security baseline), and prepare a BCP (paper-fallback procedures) to keep treating patients if core systems are down for a long time. Handa Hospital was credited for invoking its BCP quickly and disclosing openly — preparation buys speed.
Where this mirrors this site's design principles
The core here is that it was neglected basics, not a flashy attack, that decided the damage: patch known CVEs, keep credentials clean, isolate backups — none of it new or hard. That is the inverse of this site's own principles: close known holes fast, don't reuse keys, keep a recoverable setup. In particular, "we have a backup, but it's in the same place as production" carries the same danger as one API key reaching every dataset. Close the external hole, tighten the keys, and isolate and rehearse recovery — 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 vendor/contractor names — only the defensive lessons.
- Tsurugi Handa Hospital — "Expert Committee Investigation Report on the computer-virus infection incident" (published 2022) — handa-hospital.jp
- Reporting and analysis (entry via an unpatched VPN vulnerability CVE-2018-13379, backup on the same network, the closed-network myth, and the recovery, 2021–2022) — based on the official committee report
Read next
- Glossary: what ransomware is (how it works and how to avoid paying) / what a CVE is (managing known vulnerabilities)
- Practice: backup basics (the 3-2-1 rule) / CVE remediation playbook / the organizational security baseline
- Cases: Osaka hospital ransomware (2022) (a contractor's VPN and medical BCP) / Capcom ransomware (2020) (an old VPN device was the way in) / KADOKAWA ransomware (2024) (thin segmentation spread it company-wide)
FAQ
QWhere did attackers get in during the Handa Hospital incident?
According to the expert committee's report, the main intrusion path was a known vulnerability (CVE-2018-13379) on an internet-facing VPN device. That vulnerability had been public since 2019 but was left unpatched, and in 2021 credentials for many such devices were leaked — the hospital's among them, and not revoked. In short: a long-unpatched public vulnerability plus leaked credentials that were never invalidated became the open door.
QWhy did even the backup become unusable, not just the primary system?
The primary system and its backup were on the same network, so both were encrypted by the ransomware. The report also cites internal weaknesses — short passwords, no account lockout, and users with administrator rights — so one foothold could spread with admin privileges. A backup that merely 'exists' is not enough: only a backup that is isolated from production, kept offline/offsite, versioned, and ideally immutable is something you can actually recover from.
QWhat are the top lessons for a hospital or a small organization?
1) Machine-monitor known CVEs on internet-facing VPNs/devices and patch fast. 2) Revoke leaked/reused credentials, and use MFA, least privilege, and account lockout. 3) Keep backups isolated from production — offline/offsite, versioned, immutable — and rehearse recovery. 4) Drop the 'a closed network is safe' assumption and segment by importance. 5) Have a BCP so care and operations continue even if core systems are down for a long time (paper fallback).