ransomware
7 articles with this tag
Tsurugi Handa Hospital ransomware (2021) — an unpatched VPN CVE and the backup trap
The way in, per the expert committee's report, was an internet-facing VPN device left unpatched against a known vulnerability (CVE-2018-13379), reachable with leaked credentials. Short passwords, no account lockout, and users holding admin rights made lateral movement easy. Decisively, the primary system and its backup were on the same network and both were encrypted — a backup that isn't isolated and offline is no backup when it counts. EMR recovery took about two months. Defend by patching internet-facing VPNs fast, revoking leaked/reused credentials, and keeping isolated, offline, 3-2-1 backups.
Osaka General Medical Center ransomware (2022) — a contractor's VPN as the way in, and hospital BCP
The way in was not the hospital itself but a meal-service contractor's remote-maintenance VPN device — unpatched, and reachable using leaked credentials — the investigation committee found. Because the hospital and contractor were constantly connected, and because servers/PCs shared passwords, users held broad admin rights, EMR servers lacked antivirus, and the network wasn't segmented, the encryption spread across the EMR system. Outpatient care, surgery, and emergency intake were restricted; full recovery took over two months. Defend by treating contractor links as your own attack surface: patch internet-facing VPNs, end credential reuse, least privilege, segment, and build a medical BCP (paper fallback, tested restore).
Capcom Ransomware (2020) — Why an Old VPN Device Was the Way In, and the Double-Extortion Defense
The way in was an old backup VPN device that had been left running at a North American subsidiary after newer units replaced it. From there the network was breached, data was stolen, and then ransomware encrypted systems (double extortion). Up to ~390,000 people's personal data was potentially exposed (no payment-card data). Capcom refused to pay, restored from backup, and disclosed transparently. Defend by decommissioning unused gear, patching edge devices, and covering both theft and encryption (segmentation, detection, backups).
KADOKAWA / Niconico Ransomware (2024) — Why It Spread Company-Wide, and Network Segmentation & BCP
The way in was described as phishing that stole an employee's credentials; from there the internal network was breached and ransomware ran, taking down many of the group's services (including Niconico) for months and leaking ~250,000 people's data. Reporting and analysis attribute the company-wide spread to systems of very different criticality sharing the same network — reportedly with too little segmentation. Defend by segmenting the network by criticality, using phishing-resistant authentication, and preparing business continuity (BCP) and recovery.
Backup essentials: the 3-2-1 rule and a recovery plan that survives ransomware
'I have a backup' isn't enough — only a backup you've verified you can restore is real. The basics: the 3-2-1 rule (three copies, two media types, one offsite). For ransomware you also need at least one 'offline or immutable' copy — an always-connected backup gets encrypted along with the original. Cloud sync is not a backup (it replicates deletions and encryption too). Versioning and a periodic restore test complete the practice.
What is ransomware? How it works, how it gets in, and how to avoid paying
Ransomware is malware that encrypts your files and demands payment to get them back. Modern attacks add double extortion — they steal data first and threaten to leak it, so decryption alone doesn't stop the breach. Main entry routes: phishing, weak/no-MFA VPN/RDP, and unpatched internet-facing flaws. The single most important defense is offline/immutable backups plus restore tests — being able to recover without paying. Also close the entry (MFA, patching) and limit blast radius (least privilege, segmentation).
MOVEit mass breach (2023) — how a SQL injection zero-day reached 2,700+ orgs, and how to defend
The entry was a SQL injection zero-day (CVE-2023-34362) in the internet-facing MOVEit Transfer. A web shell (LEMURLOOT) was planted and data was bulk-stolen from the backing database, hitting 2,700+ orgs and ~93.3M people. Most victims were pulled in indirectly because a vendor used MOVEit. In your environment: KEV fast-patching, minimize exposure, web↔DB least privilege and segmentation, vendor inventory and data minimization.