Industry solution
Education and Research Ransomware Response
Schools and research institutions run open networks with dispersed endpoints and systems built across many eras, often unattended at night and during holidays — a combination attackers exploit. This page covers the sector's threat profile, recovery priorities for academic and research data, and defences suited to campus networks.
Critical business systems
- Academic administration, course selection and grade management
- Student affairs, enrolment, campus card and access control systems
- Research management systems and experimental data storage
- Library management systems and digital resource platforms
- Campus website clusters and online learning / MOOC platforms
- Finance, asset and HR management systems
- File servers, NAS and laboratory shared storage
- Virtualization platforms and the campus data centre
Threat landscape
Public reporting lists education among the sectors affected in multiple official ransomware advisories — the joint advisory on the Medusa family, for instance, notes victims across medical, education, legal, insurance, technology and manufacturing critical infrastructure sectors. Education becomes a frequent target largely because of how its networks are shaped:
- Networks are open by design. Campus networks must serve personal devices, public labs, research facilities and dormitories, so addressable range is wide and admission control comparatively loose, making a foothold easier to find.
- Many systems, many vendors, many eras. Academic, student affairs, research, library and campus card systems were built by different vendors at different times, leaving old versions, mixed interfaces, blurred ownership and difficult patch and decommissioning management.
- Large website and platform exposure. Departmental sites, course platforms and laboratory pages are numerous and often unmanaged centrally, making them frequent targets for web exploitation.
- Unattended nights and holidays. Attackers favour long holidays and vacation periods, when detection and response are delayed by days or longer, allowing encryption and exfiltration to complete unhurried.
- Highly dispersed research data. Experimental data often lives on servers, NAS units and external drives bought by individual research groups, outside any central backup or security management — so when it is encrypted there is frequently no usable copy.
Business impact
- Teaching is disrupted. Course selection, timetabling, grade entry and online learning platforms stop, directly affecting the semester — and outages at critical moments such as term start or examinations hit hardest.
- Risk to enrolment and grade data. Student status, grades and degree records are irreplaceable authoritative data; if destroyed without backups, recovery is extremely difficult and requires extensive manual verification.
- Research loss is the hardest to reverse. Raw experimental data, models, code and draft papers often represent years of unique work, and group-managed storage frequently has no backup — the most characteristic and most painful loss in this sector.
- Personal data exposure. Enrolment, identity, contact details and campus card transaction records are personal information, and exfiltration under double extortion brings compliance and reputational pressure.
- Campus services stop. Campus cards, access control, library lending and dormitory management fail, disrupting daily life and attracting broad attention.
- Constrained recovery resources. IT staffing and budgets in education are usually limited, so handling and recovery often need external support to complete within an acceptable timeframe.
Our response plan
Scope the isolation and contain the campus network
Campus networks are open, so the first task is to gauge the spread quickly and contain zone by zone: cut lateral paths between the data centre and the administrative, laboratory and dormitory areas, close exposed high-risk ports, and suspend shares and sync jobs that could spread further. In parallel, image core business servers, the virtualization platform and critical research storage read-only, and preserve the logs. Do not rebuild any server before assessment.
Identify the family and locate the entry point
Establish the family and encryption mode, focusing on the sector's common entry points: web vulnerabilities in site clusters and online platforms, internet-exposed servers and weak-password RDP, legacy systems never decommissioned, and third-party vendor remote maintenance channels. Because incidents often occur during holidays, examine dwell time and activity scope carefully, and establish whether domain controllers and backup systems were reached.
Prioritise by teaching continuity and irreplaceability
A workable order: first tier — identity and network infrastructure, core academic administration (enrolment, grades, course selection and timetabling), online learning platforms, and campus services such as cards and access control; second tier — student affairs, library, finance and asset systems; third tier — historical data, analytics and archives. Treat research data as a separate track: it is the most irreplaceable and the most dispersed, so group-managed storage must be inventoried and assessed case by case.
Execute recovery and validate against teaching operations
Recover in a clean environment and validate on an isolated segment first, with academic, student affairs and finance staff operating the systems hands-on: are student counts and enrolment statuses complete, are grade records continuous, is course selection and timetabling data usable, do campus card balances and transaction records agree. Recovered research data must be validated by the research group itself — can files be opened, are formats intact, are time series continuous — with the scope of any gaps stated explicitly.
Segment the campus network and govern data
Hardening has two axes. Network: establish boundaries and access control between the data centre and each campus zone, keep core business systems off the open network, manage the public website cluster centrally, and retire unmaintained sites. Data: bring research data dispersed across groups into a central backup arrangement — or at minimum provide a central backup service and standards — and keep core business backups outside the production domain with offline or immutable copies. Establish holiday coverage and alert response, so incidents during long vacations are not left undiscovered for days.
Common ransomware families
- Free decryptor available
Phobos
Phobos is a RaaS family that relies mainly on brute-forced RDP and has spawned a long list of variants (.eking, .faust, .elbie, .devos and more). It has been a persistent presence in Chinese server-ransomware cases, and in July 2025 Japan's National Police Agency released a free decryptor covering part of the lineage.
- No public decryptor
Medusa
Medusa appeared in June 2021 and shifted to a ransomware-as-a-service model from 2023, using the .MEDUSA extension and !!!READ_ME_MEDUSA!!!.txt note. It specialises in exploiting remote-management and file-transfer components such as ScreenConnect, Fortinet EMS and GoAnywhere, and applies pressure through a countdown clock with paid extensions.
- Some versions decryptable
Rhysida
Rhysida is a RaaS operation active since 2023, marked by the .rhysida extension and a CriticalBreachDetected.pdf ransom note. It hits healthcare, education, manufacturing and government, ships an ESXi encryptor, and a subset of early Windows samples can be recovered with a free decryptor.
- Some versions decryptable
LockBit
LockBit is one of the largest ransomware-as-a-service operations in the world. Despite the 2024 law-enforcement takedown it returned as LockBit 5.0, with working Windows, Linux and VMware ESXi payloads, and it remains one of the most frequently seen families in China.
- No public decryptor
TellYouThePass
TellYouThePass is the archetypal vulnerability-driven ransomware family in China, mass-deployed against internet-facing ERP, OA, finance and middleware systems. It appends .locked and hits both Windows and Linux servers. No public decryptor exists.
Hardening recommendations
- Retire orphaned systems and unmaintained websites. Periodically enumerate exposed systems and sites with a named owner for each, and decommission unmaintained departmental sites, old course platforms and laboratory pages — the most common entry point in this sector.
- Separate core business systems from the open network. Place academic administration, student affairs, finance and campus card systems in a dedicated security zone, away from dormitory and public lab networks, with service ports closed to the internet.
- Provide central backup capability for research data. Group-purchased storage is hard to manage centrally, so the practical answer is for the institution to offer a central backup service or subsidy and bring important project data into regular backup with offline copies.
- Staff and alert coverage for nights and holidays. Attacks frequently land during long vacations. At minimum, ensure key alerts — anomalous logons, mass file changes, shadow-copy deletion, backup job failures — reach an on-call responder with a defined process.
- Reduce remote access exposure. Remove internet-facing RDP in favour of VPN with MFA, and route third-party vendor maintenance through a jump host with on-demand authorisation and full auditing.
- Govern endpoints and accounts. Deploy EDR with tamper protection across public labs and staff endpoints, promptly remove graduating students' and departing staff accounts, and forbid shared accounts for managing critical systems.
- Keep backups outside the production domain and verify them. Give core business backups independent credentials and network with offline or immutable copies, and run a real restore drill each semester.
- Write security requirements into build and maintenance contracts. New systems must specify patching responsibility, log retention, account management and a decommissioning process, so no new unowned system is created.
Emergency response
Data already encrypted? Stop and let an engineer look first
We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.
Related scenarios
File Servers and NAS Encrypted by Ransomware
When shared folders on a file server or NAS are encrypted, drawings, contracts, archives, quotations and design sources all become unusable at once — and mapped drives spread the impact to every endpoint. This page covers how to gauge spread, what shadow copies and snapshots realistically offer, and how to sequence recovery by business value.
MySQL / MariaDB Database Encrypted by Ransomware
When MySQL's ibdata1, .ibd and .frm files are encrypted, websites, online stores, OA and other web workloads all go down. Most cases start at a web application flaw or an exposed management panel. This page covers what InnoDB's file layout means for recovery, the value of binlogs, and the correct sequence.
OA Collaboration System Encrypted by Ransomware
An encrypted OA system halts document circulation, approvals, contract archives, HR and knowledge bases at once — and because OA is so often published to the internet, it is frequently the attacker's first foothold. This page covers its vulnerability profile, the twin-track recovery of attachments and database, and how to check for lateral spread.
Database Encrypted by Ransomware
When database files are encrypted, every business system that depends on them stops at once. This page explains how we triage an encrypted database, how recoverability is assessed, and when file repair, backup-plus-log restore, or rebuild is the right path.
Backups Deleted or Destroyed
Modern ransomware follows a fixed sequence: destroy the backups, then encrypt the data — deleting shadow copies, encrypting repositories, disabling jobs, and exploiting backup software flaws to steal credentials. This page covers what can still be inventoried once backups fail, why replication propagates encrypted files off-site, and what offline and immutable copies are really worth.
Related services
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Attack Forensics & Attribution
Establish the intrusion path, timeline and impact — in a report usable for police reporting and compliance.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
Our research data is encrypted and there is no backup — what now?
Stop all writes to the storage immediately, keep it as-is, and engage incident response. No backup does not mean no path: assessable options include partial-encryption repair on large files (raw experimental data, images and model files are large, and many families encrypt only the header), carving the deleted originals (encryptors commonly write new and delete old), storage-layer snapshots, and distributed copies — versions held by collaborators, submission systems and email attachments, version history in cloud sync, and raw records retained by the instruments themselves. The assessment sets expectations by data type rather than offering a blanket answer.
It happened during the holidays — can it wait until term starts?
Waiting is not advisable, for three reasons. Recoverability decays with time: storage that keeps running keeps writing, overwriting the fragments of deleted originals and shrinking what carving can retrieve. The attacker may still be inside: uncleared backdoors lead to re-encryption after recovery, or continued exfiltration. Evidence disappears: log rotation and temporary file overwrites make root-cause attribution much harder. The right move is to disconnect and isolate immediately, preserve the state, and engage response — even if full recovery is scheduled before term, containment and evidence preservation must happen now.
Enrolment and grade data is encrypted — how is it recovered and verified?
Technically this follows the database scenario: restore from backup and transaction logs first, then assess page-level repair of the data files. Verification matters especially here: after recovery, academic administration must confirm student counts and enrolment statuses, continuity of grade records across semesters, completeness of degree and graduation information, and usability of course selection and timetabling data. Gaps can often be filled from data submitted to education authorities, paper and electronic registers held by faculties, and instructors' own grade records — sources that should be listed in the recovery plan up front.
The campus network is very open — how do we harden it without disrupting users?
The idea is to protect the core rather than restrict the whole network. Concretely: place academic, student affairs, finance and campus card systems in a dedicated security zone reachable only via authenticated, necessary access, with boundaries against dormitory and public lab networks; manage the public website cluster centrally and retire unmaintained sites; and consolidate remote access onto VPN with MFA. Everyday browsing for students and staff is essentially unchanged, but the path from one ordinary endpoint laterally into core systems is cut — the highest return on investment available here.
Student and staff personal data may have leaked — what should we do?
Establish the facts before deciding actions. During forensics we examine exfiltration indicators — anomalous egress traffic, staged archives, upload records, transfer tools — and produce a technical conclusion on whether data left and which systems and data categories were involved. On that basis, the institution works with legal counsel and its supervising authority to assess handling and notification duties under personal information protection rules, and cybersecurity incident reporting requirements. We provide the technical facts and reports; we do not substitute for legal judgement and take no part in dealings with the attacker.
Updated