Industry solution
Government and Public Sector Ransomware Response
Public sector ransomware incidents run on three lines at once: service interruption, data security and mandatory reporting. When document circulation, archives and integrated service platforms stop, both public services and internal operations are affected. This page covers the handling sequence, reporting duties and hardening priorities.
Critical business systems
- OA collaboration and electronic document exchange systems
- Integrated public service platforms and public-facing portals
- Records management systems and electronic archives
- Data sharing and exchange platforms and dedicated business network systems
- HR, finance and asset management systems
- Video conferencing, surveillance and access control systems
- Internal endpoints, file servers and virtualization platforms
- Backup systems and disaster recovery environments
Threat landscape
Government and public sector bodies have long been priority targets. Public reporting — including joint advisories from overseas law enforcement and cybersecurity agencies on families such as Medusa and Rhysida — explicitly notes government and public sector impact, while published landscape reports in China note that larger public-sector organisations are far from exempt.
Risk characteristics of public sector environments:
- Large public-facing exposure. Portals, integrated service platforms and online transaction systems must serve the internet, making web application flaws and weak credentials frequent entry points.
- OA as a common pivot. To support mobile working, OA is often published directly to the internet, and public sources document unauthenticated SQL injection, command execution and file upload flaws in the major OA products — scanned for continuously.
- Many systems built across many eras. Applications from different periods are maintained by different vendors, with old versions, blurred responsibility boundaries, and difficult patch and decommissioning management.
- Heavy reliance on third-party operations. Integrators, on-site operators and development vendors hold extensive access, and the channels and accounts serving them are a weak point.
- Explicit compliance obligations. The Cybersecurity Law, Data Security Law and the Multi-Level Protection Scheme set requirements for incident handling and reporting, and the Administrative Measures for National Cybersecurity Incident Reporting, effective 1 November 2025, set reporting deadlines for critical information infrastructure operators after an incident.
Business impact
- Public services stop. Online applications, appointments, enquiries and filings cease, drawing public attention and compressing the handling window.
- Internal operations stall. Document circulation, approvals, seal usage, meetings and expense processes break, forcing cross-departmental work offline.
- Risk to archives and operational data. If electronic archives, operational registers and approval records are destroyed without usable backups, recovery is extremely difficult and some content may be unreconstructable.
- Data security and confidentiality risk. Internal documents, personnel information and operational data may already have been exfiltrated under the double-extortion model, engaging data security and confidentiality requirements.
- Compliance and accountability pressure. Incidents must be reported to the competent authorities within set deadlines, with cooperation in investigation and remediation, and the handling itself later falls within the scope of inspection.
- Recovery must be documented. Handling steps, evidence preservation, recovery actions and remediation measures all need traceable written records to support later inspection and sign-off.
Our response plan
Isolate, preserve evidence, and escalate internally
Isolate affected systems and segments without reinstalling or overwriting, and image key servers read-only. Start the internal escalation at the same time, notifying the cybersecurity and confidentiality functions and preparing reporting material according to your classification and regulator's requirements. Document the entire process in writing — time, action, owner, basis — since those records serve both as technical material and as evidence for later inspection and sign-off.
Trace the entry point and assess exfiltration
Focus on three entry classes: exploitation of public-facing web systems (portals, service platforms, OA); third-party operations channels (integrator remote access, on-site accounts, vendor jump hosts); and weakly authenticated remote access (RDP, VPN). Assess exfiltration in parallel — anomalous egress traffic, staged archives, upload records and transfer tool artefacts. The exfiltration conclusion directly shapes what and how much must be reported, so it needs to be established early.
Prioritise public services and document workflow
A workable order: first tier — identity and network infrastructure, public service platforms and portals (restoring availability first, with notices and degraded service if needed), and OA document circulation and approvals; second tier — records management, dedicated business network systems, finance and HR; third tier — historical archives, statistical analysis and non-critical internal systems. Even where public services cannot be fully restored immediately, service guidance and alternative channels should be published quickly.
Recover clean and organise formal acceptance
Rebuild every system in a clean environment, restore the data, and validate on an isolated segment before go-live. Acceptance must produce a written conclusion: whether each system functions correctly, whether data is complete, the scope of any gaps and the plan to fill them, residual risk and the monitoring arrangements that follow. Before public-facing systems go live, run a security check — vulnerability scan, web shell hunt, configuration review — so they are not re-exposed to the internet carrying the original flaw.
Complete reporting and implement remediation
Complete incident reporting as required and support any follow-up. The Administrative Measures for National Cybersecurity Incident Reporting took effect on 1 November 2025 with explicit deadlines for critical information infrastructure operators, to be applied in light of your classification and your regulator's and locality's requirements. Technical remediation focuses on reducing public-facing exposure and patching, funnelling and auditing third-party access, network segmentation and least privilege, taking the backup estate out of the production domain with offline or immutable copies, and building centralised log retention and monitoring.
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.
- Some versions decryptable
GlobeImposter
GlobeImposter has been active since 2017 and is highly prevalent in China through its Chinese-zodiac variants (such as .Dragon4444) and Olympian-gods variants (such as .Ares666). It spreads by brute-forcing RDP/SMB and moving laterally, and caused widespread hospital infections in China in 2018. Mainstream variants have no 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
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.
Hardening recommendations
- Manage public-facing exposure from an inventory. Periodically enumerate every internet-facing system and port and maintain a register; decommission unmaintained and retired systems decisively — orphaned systems are the most common entry point in the public sector.
- Harden OA and portals as a priority. Move to VPN or zero-trust access where possible; where public publication is required, front it with a WAF, restrict admin console paths, disable test interfaces, and track vendor patches and CNVD / CNNVD advisories.
- Funnel third-party operations through one control point. Route integrator and on-site operator access through a jump host, authorised on demand, fully audited and revoked on departure, with no shared accounts or permanently valid remote tools.
- Segment the network and apply least privilege. Establish boundaries between public-facing, internal office, core business and administration zones, and never run service accounts with domain administrator rights.
- Keep the backup estate outside the production domain. Give backup servers independent credentials and network, enable immutable or offline copies, and give archives and operational data their own long-term retention strategy.
- Strengthen identity. Enable MFA on key systems, promptly remove departed and transferred users, and audit privileged accounts and their scope regularly.
- Retain and monitor logs centrally. Keep at least six months of logs per protection requirements, with alerting on anomalous logons, mass file changes and shadow-copy deletion.
- Institutionalise drills and reporting plans. Run an incident exercise at least annually, and define the internal escalation path, external reporting owners and deadlines, so reports can be filed correctly during a real event.
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
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.
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.
Domain Controller Compromise and Estate-Wide Encryption
A compromised domain controller hands the attacker a legitimate administrator identity, allowing an encryptor to be pushed to every host at once through Group Policy or remote execution. This page covers how such incidents present, the correct order for Active Directory recovery, and how to decide between cleanup and full rebuild.
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.
Attack Forensics & Attribution
Establish the intrusion path, timeline and impact — in a report usable for police reporting and compliance.
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
How quickly must we report a ransomware incident?
The deadline depends on the incident's classification and your organisation's status, and your regulator's and locality's requirements govern. China's Administrative Measures for National Cybersecurity Incident Reporting took effect on 1 November 2025 with explicit deadlines for critical information infrastructure operators after a cybersecurity incident. The recommended practice: trigger internal escalation immediately, assemble the factual material in parallel (time of discovery, systems affected, preliminary impact, measures taken), file the initial report within the required window, and supplement it as the investigation progresses. Our technical findings and reports support those filings.
After OA encryption, can documents and archives be recovered?
Assess the two parts separately. Database content — workflow records, approval comments, metadata — has a relatively good chance, especially where a usable backup exists or the data file was only header-encrypted. Attachments (document bodies, scans, archived images) depend more on backups, snapshots and carving deleted files, since attachment stores are dominated by small files that are usually fully encrypted. The good news is that official documents typically have distributed copies — with the sending and receiving bodies, in the handling officer's mailbox and local folders, and in paper archives — which frequently restore the critical items.
A vendor's operations account was abused — how is responsibility apportioned?
Apportioning responsibility is a management and legal question; what we provide are the technical facts — the entry path, the account used and its source addresses, the timeline, and the attacker's activity across systems. Those facts answer clearly which channel and which account were used to get in. From a remediation standpoint, however responsibility falls, third-party access should be funnelled through a jump host, authorised temporarily on demand, fully audited, revoked on departure, and never shared — that is what actually reduces the risk.
When can our public service platform go back online?
Three conditions should hold before go-live: the entry point is fixed (the flaw identified by forensics is patched, weak credentials remediated, exposure reduced); the system is confirmed clean (web shells removed, persistence hunted, configuration reviewed); and monitoring is in place (log retention and alerting active, so renewed attempts are seen). Until then, public impact can be reduced with notices, alternative channels and in-person service. Rushing back online while still carrying the original flaw is the most common cause of a second incident.
We passed our protection assessment — why were we still hit?
An assessment confirms compliance at a point in time, while the attack surface changes continuously. Common gaps in real cases: orphaned systems outside the assessment scope still exposed to the internet; ports and interfaces added after go-live that never entered the management process; patching lagging newly disclosed severe vulnerabilities; over-privileged, unaudited third-party operations accounts; and backups that exist but have never been validated by a real restore. Our remediation advice starts from the links actually exploited, rather than adding documentation against a checklist.
Updated