Cybersecurity · October 23, 2026 · ComputerKing Team

Ransomware Response for Hong Kong SMEs: 2025–2026 Guide

Ransomware leak claims rose nearly 50% in 2025; virtual machines are now targets. First-hour isolation, Hong Kong reporting and backup recovery for SMEs.

Note: This article is general information only and does not constitute legal advice. Decisions about paying a ransom, reporting obligations and personal data breaches should be made with legal advice and the relevant authorities. All service fees are subject to individual quotation; no prices are given in this article.

Summary

In 2025, claims on ransomware leak sites surged by nearly 50%, and virtualisation hosts are now prime targets. If you are hit, isolate first, protect your backups and evidence, then report under Hong Kong guidance — do not rush to pay the ransom.

Opening: A Hypothetical Scenario, Not a Real Case

The following is a hypothetical scenario, not a real client case. On a Monday morning, a trading company with a dozen or so staff returns to the office to find that files in the shared folder will not open, their extensions have turned into strings of random characters, and a ransom note has appeared on the desktop demanding payment in cryptocurrency within a deadline — or stolen data will be published. Quotations, customer contact details and unshipped orders are all inside. The boss's first instinct is: "Just switch the machines off and reinstall everything, and it will be fine." That reaction is natural, but it is very likely the worst possible first step.

Why does this topic deserve a dedicated article? Because ransomware after 2025 is no longer simply "files locked, pay to unlock". The mainstream model today is double extortion: attackers first steal your data, then encrypt your systems. Even if you restore everything from backup, the stolen copy in their hands can still be used to threaten you. So "we have backups, so we are fine" is already out of date in 2025–2026.

The Latest Trends in 2025–2026: Claims Surge, Concentrated Leaders, Virtual Machines Targeted

Hong Kong Overall Incident Figures — Stated With the Right Denominator

HKCERT's *Hong Kong Cybersecurity Outlook 2026* states that HKCERT received 15,877 cybersecurity incident reports in 2025, a record high and about 27% more than the previous year. This must be stated precisely: it is the number of reports HKCERT *received*, not the total number of incidents that actually occurred in Hong Kong, and it is not a ransomware-specific figure. Within it, phishing accounted for nearly 60% (57%), system-vulnerability-related incidents reached 2,328 cases (15%), more than 3.5 times the previous year, and botnet-related incidents accounted for 18%. In other words, attackers are increasingly exploiting unpatched vulnerabilities and misconfigurations, not relying on a single phishing email alone.

In the first half of 2026, HKCERT received 8,358 incident reports, broadly in line with 8,142 in the same period of 2025. Phishing remained the largest category at 5,305 cases, or 63%. Among phishing brand impersonation, social media and instant messaging apps accounted for 46%, followed by banking/financial and electronic payment services (17%) and cryptocurrency platforms (15%). For an SME, the practical meaning is direct: a fake message an employee receives on WhatsApp is just as dangerous as a fake link in an email. Do not only defend email.

HKCERT's Outlook lists five cybersecurity risks for 2026, but the publicly available summary only fully lists the first four: (1) AI-driven attacks and Agentic AI risks; (2) data leakage risks from weak enterprise AI governance; (3) supply chain vulnerabilities and third-party security gaps; and (4) single points of failure from over-reliance on cloud infrastructure. The fifth item was not fully listed in the summary, and this article will not invent it. It is also worth noting that threat-report summaries point out that AI currently mainly amplifies older techniques — phishing, impersonation, reconnaissance and content generation — rather than inventing an entirely new class of intrusion. There is no need to be frightened by the phrase "AI ransomware", but there is absolutely no room to underestimate how much more convincing AI makes phishing messages.

Globally: Leak-Site Claims Rose by Nearly 50% in One Year

Analyst1's *2025 Review*, based on ransomware data leak site (DLS) statistics, recorded 7,819 claims in 2025, up about 49.7% from 5,223 in 2024. The United States accounted for nearly half of 2025 claims (3,936 of 7,819); the rest of the top ten countries/regions included Canada, Germany, the United Kingdom, Italy, France, Spain, Brazil, Australia and India. The top 20 groups accounted for nearly 70% of claims in 2025, led by Qilin (15%), Akira (10%) and Clop (6%).

The statistical basis must be stated: DLS claim numbers do not equal the total number of actual victims, because some victims are never published, some groups run no leak site at all, and the figures are driven by attackers' own claims. But the direction of travel is clear: the ransomware business has not shrunk — it has grown larger.

Ransomware-as-a-Service: Strike One Brand, and Its Affiliates Move Elsewhere

Under the ransomware-as-a-service (RaaS) model, core developers provide the brand, tools and negotiation/leak infrastructure, while affiliates buy or rent the tools to carry out attacks. After law enforcement action against LockBit (February 2024) and ALPHV/BlackCat (December 2023 and March 2024), affiliates migrated in large numbers to other brands, and the market did not disappear. A secondary compilation by DeepStrike of GuidePoint figures states that 124 ransomware groups were active in 2025, up 46% on the previous year, mostly smaller or renamed affiliates. This article cites that figure only as a secondary compilation, not as a primary survey.

The clearest illustration of "weakened but not eliminated" is LockBit 5.0. According to Acronis Threat Research Unit analysis (as relayed in a secondary summary), LockBit 5.0 was released in September 2025 under a RaaS model, targeting Windows, Linux and VMware ESXi systems, combining cross-platform encryption with double extortion. The ESXi variant shuts down virtual machines before encrypting virtual disk files — meaning a single compromised virtualisation host can affect dozens of virtual machines. According to the same secondary summary, LockBit's leak site listed 60 victims from December 2025, spanning manufacturing, healthcare, education, finance and government. These technical details and victim figures are secondary summaries, and this article does not present them as directly verified primary material. But the direction is unmistakable: if your company runs all its servers on virtualisation, the virtualisation host itself is one of the attacker's most desirable targets, and backups and virtualisation infrastructure must be protected separately.

Double Extortion Is Now Mainstream — and Extortion-Only Attacks Are Rising Too

Double extortion means stealing data first, then encrypting systems, and threatening to publish the stolen data. According to Travelers Insurance figures (as relayed in a secondary summary), 87.6% of ransomware claims involved both encryption and data theft or the threat of publication. The implication is harsh: even a successful backup restore does not remove the threat from data already stolen. Triple extortion goes further, adding pressure on customers or partners, or launching distributed denial-of-service (DDoS) attacks; TechTarget's summary notes that groups such as Vice Society have used this technique. It should be stated that triple extortion is an escalation technique used by *some* groups, not the standard process of every attack.

At the same time, extortion-only attacks (stealing data without encrypting) are rising. A secondary summary of Sophos's retail-sector report notes that extortion-only attacks rose from 2% in 2023 to 6% in 2025, a threefold increase, while the retail encryption rate fell to a five-year low of 48%. This is a retail-sector subsample and must not be generalised to all industries. But it carries a warning: some attackers do not even bother encrypting — they steal data and extort directly, and you may never see the warning sign of "files that will not open".

A Hong Kong Local Case: What the InvestHK Incident of February 2025 Teaches Us

On 22 February 2025 (Saturday), parts of Invest Hong Kong's (InvestHK) computer systems suffered a malicious ransomware attack, announced on 23 February. Affected areas included its internal customer relationship management (CRM) system, intranet and some website functions, including the website contact form and event updates. According to secondary reporting of the official press release, immediate measures included updating relevant access rights, isolating affected systems and activating backup procedures; reporting to the Police, the Digital Policy Office (DPO), the Office of the Privacy Commissioner for Personal Data (PCPD) and the Security Bureau on the same day; engaging specialists to assist investigation and recovery; and keeping public services — telephone, email and face-to-face meetings — running normally.

The preliminary assessment indicated that data possibly involved included customers' basic information (company contact details) and InvestHK staff records. The number of people affected was not disclosed in reporting at the time, and this article will not invent a figure. A secondary summary also states that, as of 3 March 2025, InvestHK said no personal data had been leaked in the attack; that update is not an InvestHK original announcement directly verified by this article, and readers should rely on official announcements.

For comparison, a Legislative Council written reply (26 March 2025) states that the Digital Policy Office received 5, 3 and 2 reports of ransomware incidents involving government IT systems in 2022, 2023 and 2024 respectively, with no data leakage in any of them. The most useful lesson from the InvestHK case for SMEs is not that it involved a government body, but its reporting tempo: multiple parties notified on the same day, rather than waiting until the investigation was complete. That tempo matches the PCPD guidance requirement of acting "as soon as practicable", discussed in the reporting section below.

The First Hour After an Attack: Getting the Order Right Matters More Than Doing More

The core sequence of CISA's #StopRansomware guidance should be the backbone for SMEs: first identify which systems are affected and isolate them immediately; if multiple systems are affected, take the relevant network segment offline at the switch level; if that is not possible, unplug the affected devices' Ethernet cables or disconnect Wi-Fi first. Then prioritise affected systems for restoration by criticality, have the team build and record a preliminary understanding of the incident, and contact internal and external teams and stakeholders.

The details that can be executed on site are worth spelling out one by one:

First, unplug cables — do not just turn off Wi-Fi. An infected machine must have Ethernet, Wi-Fi, Bluetooth and any shared disks disconnected at the same time. Other computers on the same network that are not yet fully encrypted should also be disconnected and separated, gathered together and clearly labelled to show which ones are encrypted; they must stay disconnected while gathered, and must not be reconnected for the convenience of testing. Many companies only turn off Wi-Fi while the machine is still plugged into the LAN cable, so the ransomware keeps spreading laterally across the internal network, and the rescue effort creates more victims.

Second, isolate servers and backup repositories first. Sources with incident-response experience specifically warn to isolate domain controllers (DCs) and backup repositories first, because backups themselves are attack targets. Important communications should use out-of-band channels such as telephone, because everyday email or instant-messaging channels may already be affected — do not assume they are unmonitored.

Third, pause synchronisation — do not let encrypted files overwrite good ones. Pause OneDrive, Google Drive, Dropbox and similar sync tools, because sync tools will upload encrypted files and overwrite the previously good versions. This is why HKCERT repeatedly reminds users: when using cloud backup, confirm that the provider offers a "version history" feature, so earlier versions can be retrieved before they were overwritten by sync. Sync is not backup — that sentence is worth pinning on the IT room door.

Fourth, immediately disconnect backup devices from the infected network; after disconnecting, confirm the backups themselves are offline and safe and, where possible, scan to verify; do not reconnect before they are confirmed clean. CISA's relayed guidance requires ensuring backup data is offline and secure and, where possible, scanning backup data with antivirus software for malware. Antivirus scanning cannot detect all malware, and the contents of encrypted backup files cannot themselves be scanned; the real proof is an actual restore test in an isolated environment. Never reconnect a backup to the infected network before confirming this, or you will hand your last lifeline to the attacker yourself.

Fifth, do not wipe machines immediately. Multiple sources agree: before evidence is collected, do not erase, reinstall or restore onto the original machine, because doing so destroys evidence needed for police investigation and insurance claims. HKCERT's earlier crypto-ransomware steps are also: isolate and disconnect immediately, then scan and clean, and restore from backup if one exists; if there was no backup before, it advises against restoring the system, so as not to lose information needed for decryption.

On the question of "to shut down or not", the industry genuinely disagrees, and this article must present both sides rather than only one. CISA's position is to prioritise disconnection, with shutdown only as a fallback when disconnection is impossible, because shutdown loses volatile memory (RAM) forensic evidence. Another school of practical opinion argues that while encryption is in progress, every extra minute means more files encrypted, and advocates disconnecting and shutting down immediately. That approach conflicts with evidence preservation. For an SME without a dedicated IT team, the safest formulation is: the first step on site is always disconnection; whether to shut down should be decided immediately by the IT supplier or incident responders, and must not be decided by non-technical staff wiping or reinstalling machines on their own.

Preserving Evidence: What You Delete Today May Be the Key to the Case Tomorrow

HKCERT's self-help guidance reminds victims that, when deciding to report to the Police or relevant authorities, they should preserve evidence: any email messages in the account — not just their content, but also their headers; and any logs from servers, routers or computers, such as firewall logs and antivirus logs; and provide examples of incident-related email messages when reporting. Legislative Council material also warns of a common mistake: some victims, after being defrauded or having a computer compromised, immediately delete computer data or even reinstall all software, destroying the relevant evidence.

So the first-hour preservation list includes: a copy of the ransom note, changes in file extensions, lock-screen messages, the time of discovery, the steps already taken, and firewall and endpoint logs. Photograph the ransom note, note down the extension, and only then use a clean computer to identify the variant. That is the correct order.

To Pay or Not to Pay: What the Authorities Say, and How to Read the Numbers

The FBI and CISA strongly discourage paying ransoms: payment does not guarantee file recovery, may encourage attackers to target more organisations, and may fund illegal activity. Whether or not payment is decided, they urge reporting to CISA, the local FBI office or IC3 (https://ic3.gov). This position has been covered in earlier articles, so this article only summarises it and does not expand it into a chapter on US law.

Secondary summaries of Sophos's *State of Ransomware 2025* (June 2025, a survey of 3,400 IT and cybersecurity leaders across 17 countries) disagree with each other, so this article will only say "nearly half", citing the survey organisation and year. A secondary summary of the same report also notes that the median ransom demand fell by about one-third compared with 2024, and the median actual payment was US$1 million; another secondary compilation cites Verizon DBIR as putting the 2025 median payment at US$115,000. The two figures use different samples and definitions, and must never be mixed or directly compared.

Before paying, three questions must be clarified. First, has the stolen data already been leaked? If it has, paying a "decryption ransom" cannot recover data already leaked. Second, is there an offline, uncontaminated, verifiable backup? If there is, the need to pay falls sharply. Third, is the recipient on a sanctions list? US OFAC guidance warns that paying sanctioned persons may breach sanctions rules; Hong Kong businesses should consult legal advisers, and this article does not present US guidance as Hong Kong law. Most importantly, no payment decision should be made hastily by one person at the moment of attack; the decision-maker, legal and insurance consultation process, and reporting order should be written into the response plan in advance. That is a restatement of industry advice, not a mandatory requirement of any official body.

One further point must be stated: in the research for this article, no official source promised that the Police or HKCERT would pay a ransom or negotiate with hackers on a victim's behalf. This article makes no such claim. The correct formulation is to "seek help and report to the Police and HKCERT, and seek investigation and decryption-tool information".

Hong Kong Reporting Procedures: Where to Report, When, and How

Hong Kong Police: Reporting Channels and the Free Decryption Platform

The Hong Kong Police Force has formally joined "No More Ransom" (https://www.nomoreransom.org), an international anti-ransomware project initiated by Europol, the Dutch National Police and two cybersecurity companies. Its free services include: ransomware identification — victims can upload encrypted files, email addresses, URLs or Bitcoin addresses from the ransom message, and the platform attempts to identify the ransomware type and provide related decryption tools (if any); an online database describing ransomware types, attack and infection methods; prevention advice; decryption tools; and information and hyperlinks for reporting to law enforcement.

But the Police page states plainly: decryption tools do not apply to all ransomware; because ransomware evolves rapidly, developing corresponding decryption tools takes time, and the newest variants may have no solution. So "just download a decryptor from No More Ransom and it will be fixed" is only half right — the other half, the assumption that a tool will always exist, is wrong. HKCERT also warns that fake decryptors are themselves traps: they must be downloaded from legitimate sources using a clean computer, and never tried recklessly on the original machine. When identifying a variant, tools such as ID Ransomware can be used to upload an encrypted file or ransom note to identify the variant, and then No More Ransom can be checked for a free tool; even when a tool exists, it should first be tested on a copy, never directly on the original machine.

For reporting, victims can report to the nearest police station or via the online form. One number must also be kept straight: 18222 is the Police's 24-hour anti-scam helpline, for enquiries and help — it is not a ransomware hotline, and must not be described as one. As for the Police online reporting portal link, this article refers to it only generally; readers should use the portal published on the Police's official website on the day.

HKCERT: Prevention and Post-Incident Steps

HKCERT's prevention guidance, drawn from several of its articles, can be summarised as follows. First, back up important files regularly and promptly, and keep one backup copy offline in a safe place so it is not affected by malware at the same time; when using cloud backup, confirm the provider offers a "version history" feature. Second, install security software and keep its signatures updated; install the latest security patches for systems and software. Third, for remote access tools and NAS devices: disable unused accounts and minimise account privileges as far as possible; disable unused protocols and applications such as SSH, Telnet, web servers, SQL servers and phpMyAdmin; avoid default ports such as 22, 443, 80, 8080 and 8081; changing ports is only obfuscation and cannot replace patching, MFA and a default-deny policy, and changing 443 may also affect normal services, so seek professional advice before changing it; adopt a firewall policy that by default denies all traffic; maintain offline data backups and test restoration regularly; enable system logging and trigger alerts on anomalies; and replace end-of-support software and hardware with still-supported versions.

After an incident, HKCERT's guidance points are: first take the infected computer offline to prevent malware from further affecting intranet files; copy encrypted files to a blank storage device; use a clean computer to download legitimate decryption tools, and never download suspicious decryptors of unknown origin; if a system or data backup existed before infection, restore from backup; refer to HKCERT's *Ransomware Decryption Guide*; and contact HKCERT for enquiries or assistance. HKCERT states plainly that it does not guarantee decryption tools will successfully recover files. HKCERT's 24-hour telephone hotline is 8105 6060; this article does not add an HKCERT email address that has not been verified.

PCPD: Current Guidance Versus the Reform Discussion — They Must Not Be Confused

This section is the easiest part of the article to get wrong, so it must be stated with particular clarity. The PCPD's *Guidance on Data Breach Handling and Notification* asks organisations to adopt a two-layer approach of "Prepare + Respond". On preparation, organisations should draw up a comprehensive written data breach response plan, covering what counts as a data breach and its trigger criteria, internal escalation procedures, response team members and contact lists, risk assessment processes, investigation procedures and containment strategies, communication plans for notifying stakeholders, post-incident review mechanisms, and training and exercise plans. On response, there are five steps: (1) immediately gather basic information about the data breach; (2) contain the data breach; (3) assess the risk of harm to data subjects; (4) consider issuing a data breach notification; and (5) record the data breach incident.

On notification criteria, the current guidance position is: data users should notify the Commissioner and affected data subjects as soon as practicable after becoming aware of a data breach, particularly when the breach is reasonably likely to pose a real risk of significant harm to data subjects; and notification should not be delayed merely because an internal investigation is incomplete. Harm-risk assessment factors include the type and sensitivity of the leaked data, the volume of leaked data, whether the data was encrypted, the likelihood of identity theft or fraud, and whether effective mitigation or remedial measures have been taken. Possible harms include threats to personal safety, identity theft, financial loss, humiliation or loss of dignity, reputational or relationship damage, and loss of business or employment opportunities.

The two most important sentences must always appear together, and neither may be omitted: under current arrangements, PCPD notification is guidance advice, not a mandatory statutory provision; and the mandatory deadlines discussed in the reform debate (for example, the five-working-day period mentioned in a secondary summary) are still under discussion and have not formally taken effect, and must never be written as current law. On the statutory basis, data users must, under Data Protection Principle 4 of the *Personal Data (Privacy) Ordinance*, take all practicable steps to safeguard personal data against unauthorised or accidental access, processing, erasure, loss or use; the same applies when engaging data processors. But "advised notification" and "a statutory requirement to notify within a deadline" are two different things, and must not be conflated.

The background to the reform discussion is: reform proposals in 2024 raised mandatory data breach notification and administrative fines, but according to secondary legal summaries, the Government announced in November 2024 that the reform was paused, citing concerns including the compliance burden on small and micro enterprises and a preference for phased implementation. Another secondary summary states that the PCPD restarted the reform agenda in February 2026 and is consulting Legislative Council members, and that the notification framework under discussion would require notifying the Commissioner and affected persons as soon as possible where there is a real risk of significant harm, and in any event within five working days; and that the administrative fine framework is proposed at the higher of 10% of annual turnover or HK$10 million. That secondary summary itself states that, as of mid-2026, no formal submission timetable had been confirmed, and it is less reliable than an official announcement. So this article will only say that "reform is still under discussion, current notification remains guidance advice, and readers should rely on formal announcements by the PCPD and the Government" — it will not present the five-day deadline or fine figures as current law.

The content of a notification to affected persons may include: a general description of the breach, the date and time of the breach, whether the breach was caused by the data user or a third-party processor, the types of personal data involved, the harm-risk assessment, measures already taken or to be taken to prevent further leakage, contact details of the person handling the breach, self-protection advice for data subjects, and whether law enforcement, the Commissioner or other relevant parties have been notified. Notification may be by telephone, in writing, by email or in person; where affected persons cannot be identified immediately or the public interest is involved, public notification via a website or the media may be more effective. The PCPD has launched an electronic data breach notification form, replacing the previous practice of downloading a form and submitting it by email, fax or post, to facilitate more timely notification.

A local example worth mentioning is the Canvas online learning system breach reported by HKCERT: seven local institutions proactively reported suspected personal data breaches to the PCPD, while the scope of impact was still under investigation. This example shows that "a suspected breach may also be proactively reported" — it is not a case of "only report once a breach is proven". It must be stated, however, that this is not a ransomware case, and it must not be presented as a ransomware notification example.

As for government departments' internal procedures, when an IT security incident occurs in a government department or public body, it must be reported to the Government Information Security Incident Response Office under the Digital Policy Office in accordance with the *Government IT Security Policy and Guidelines*, and the PCPD and/or Police notified according to the nature of the incident. This is a government internal procedure, and private businesses are not subject to the same chain. But the InvestHK case shows same-day simultaneous notification to the Police, the DPO, the PCPD and the Security Bureau, which can serve as a public example of "multi-party simultaneous notification".

Backup Recovery: Why Having Backups Still Fails to Save You

The Correct Recovery Order

First, restore from clean backups only after affected systems have been cleaned or rebuilt, to avoid immediate reinfection. Second, find a clean restore point — do not automatically use the latest one: attackers may have been lurking for some time, and the latest backup may already be contaminated; one backup guide recommends retaining 30 to 180 days of historical versions, and this article cites that as "that guide's recommendation", not as a universal standard. Third, verify in an isolated environment first: guidance recommends using an isolated recovery environment plus an immutable backup vault, so backups can be restored and analysed without bringing malware back into the production environment. Fourth, before freezing the original machine's state, making a bit-by-bit safety copy, and verifying the backup is clean in an isolated environment, do not restore directly over the original disk; once cleaning/rebuilding is complete and the backup is verified clean, restoring to the cleaned system is normal practice. Data-recovery sources warn that restoring a backup directly onto an affected server overwrites the original disk; if the backup itself is faulty, incomplete or itself encrypted, that destroys the last data that might still have been recoverable. The correct approach is to first freeze the original machine's state, make a bit-by-bit safety copy, and then work read-only on the copy. Fifth, prioritise by criticality: restore email, accounting and business systems first; before restoring, decide how long each service can be down, rather than estimating only when the incident happens. Sixth, monitor after restoration: restoration is not completion — confirm the intrusion route is closed, accounts have been reset and systems patched before fully resuming normal operations.

From 3-2-1 to 3-2-1-1-0: How the Backup Principle Has Evolved

"Immutable" means that, within a set period, not even administrators, attackers or accidental operations can overwrite or delete the data; it may take the form of cloud object locking, WORM storage or physical offline media. Offline media only has a similar effect to immutability while it is disconnected; once reconnected it can be written to again, and it is not equivalent to object-lock immutability. A workable SME combination is local backup (external hard drive or NAS) plus cloud backup with version history and immutable settings; local restoration is fast, and cloud backup is safe offsite. A local NAS must not stay permanently online, on the same domain, or under the same administrator account, otherwise it is the failure mode described in the first of the ten reasons below. HKCERT's earlier advice is also: back up important documents immediately and regularly, and keep an offline copy; when using cloud backup, confirm the provider offers a version history feature.

Note that HKCERT's guidance text only expressly states "regular backups + offline copies + version history". 3-2-1 is an industry-standard formulation, and this article notes it as industry advice rather than HKCERT's original text.

Ten Common Reasons Why "We Had Backups" Still Fails

First, backups share the same network, domain and administrator accounts as production: once attackers gain administrator rights, they can delete or encrypt the backups too. Analysis of the CISA/FBI SafePay joint advisory of October 2026 (AA26-293A) also notes that attackers disable the Volume Shadow Copy service, reset NAS devices holding backup data to factory settings, and in individual cases delete all network backups. Second, backups stay plugged in: a USB external drive left permanently connected will be encrypted along with everything else; it should be disconnected after backup completes. Third, a backup job showing "success" does not mean restoration works: the job log only proves the job ran, not that the data is clean, complete or that a whole system can be restored; the only reliable verification is actually performing a restore test. Fourth, full restoration has never been tested, and nobody knows how long it takes: a common SME situation is nightly backups "running", but no file or whole machine has ever been restored, and nobody knows how long a full restore would actually take. Fifth, restoring into the same uncleaned environment: the largest cause of reinfection is restoring systems into the same infected environment before eliminating the original intrusion route; attackers using residual access can re-encrypt faster than you can. Sixth, backup administrator accounts are not separated: do not manage backups with the same accounts used for everyday email or workstations; use dedicated accounts, multi-factor authentication and least privilege, and send alerts to more than one responsible person. Seventh, assuming Microsoft 365 itself equals backup: guidance notes that Microsoft maintains service operations, but retention periods for deleted emails and OneDrive files are limited; Exchange Online mailboxes, OneDrive and SharePoint restore options and retention periods must be checked separately, and dedicated cloud-to-cloud backup used where necessary. Eighth, laptops and new folders are overlooked: sales staff or managers keep important files on the desktop, never synced to the server; someone opened a new folder last year, but the backup settings do not cover it. Ninth, alerts go to an inbox nobody reads: failure notices are sent to a departed employee's mailbox, and nobody follows up. Tenth, the backup system itself is unmonitored: backup tools and security monitoring operate independently, and attacks on backup infrastructure go unnoticed.

Vendor research figures may only be cited with reservations, and never as Hong Kong facts. Veeam's 2025 research (as relayed in reporting) states that 89% of attacked organisations had their backup repositories targeted; only 10% of organisations restored more than 90% of their data, and 57% restored less than half. Veeam's 2026 research (as relayed) states that nearly 90% of security leaders believed they could restore quickly, but only 28% actually achieved full restoration. The samples and methods behind these two sets of figures have not been independently verified by this article, and they must not be applied directly to Hong Kong SMEs. As for publicly available official figures on Hong Kong SME backup restoration success rates, there are currently none, and this article will not invent any.

The 30-Day Post-Recovery Prevention Checklist: Six Areas, None Optional

Patching comes first, and it is also the cheapest item. The CISA/FBI SafePay joint advisory of October 2026 (AA26-293A) stresses that timely patching is one of the most effective and cost-effective steps, prioritising known exploited vulnerabilities, especially on externally facing systems, and keeping operating systems, software and firmware up to date. HKCERT also repeatedly reminds users to apply the latest security updates to Windows and other applications, disable unused protocols and applications, and replace end-of-support software and hardware with supported versions. One prevention guide recommends applying critical patches within 24–48 hours and automating as far as possible; this article cites that as "that guide's recommendation", not as a legal requirement for all businesses.

Endpoint detection and response (EDR) is not a luxury. HKCERT's latest ransomware feature expressly recommends installing EDR on all endpoints to monitor and automatically respond to abnormal behaviour in real time, including ransomware, and to set detection policies based on threat intelligence, in order to improve detection rates, shorten response times and reduce losses. Other prevention guides agree that traditional antivirus is not enough: EDR is designed to detect unknown variants by behaviour and may intercept before encryption begins, but does not guarantee it will always intercept. Guides also warn that someone or some mechanism must monitor alerts around the clock, or the tool alone will not save the company. This article gives no EDR brand prices and no "guaranteed blocking" claims; all such matters are subject to individual quotation. EDR cannot be installed on NAS devices, IoT devices or ESXi hosts themselves; those need network monitoring and host hardening to cover them — do not assume EDR covers everything.

Network segmentation and least privilege. HKCERT recommends segmenting critical systems and data, using firewalls and access controls to enforce segmentation and limit ransomware spread. The CISA/FBI SafePay advisory and multiple prevention guides agree that segmentation can contain an infection within one zone and prevent lateral movement to high-value assets; at the same time, user accounts and system administrators should be limited to least privilege, and everyday work should not use administrator accounts. For SMEs, the practical implementation is to separate file servers, accounting systems and backup systems from the general office network; restrict who can log in to servers and the backup console; and reduce the number of domain administrators.

Multi-factor authentication (MFA) and remote access. The CISA/FBI SafePay advisory lists MFA as a primary mitigation: all services that support MFA should require MFA, especially remote access (VPN), privileged accounts and email. HKCERT also recommends MFA for all accounts, especially administrator-privilege accounts, and strengthening remote access security, including VPN and identity authentication; unused remote tools should be disabled, default ports avoided, and firewalls set to a default-deny policy. Do not expose remote desktop (RDP) services directly to the internet; where they must be used, they should go through VPN plus MFA plus access restrictions plus monitoring.

Staff training and phishing exercises. HKCERT's Outlook 2026 recommends regular targeted security training for different departments, especially positions handling sensitive data, and strengthening incident-response capability through simulation exercises and case-based learning to reduce human error. HKCERT's ransomware feature also recommends using advanced email filtering and anti-phishing solutions to block malicious emails, followed by regular phishing simulation exercises to train staff. Multiple prevention guides agree: staff are the first line of defence, and can also be the greatest weakness; regular, low-pressure phishing simulations are more effective than a once-a-year compliance lecture; staff should be taught to recognise social engineering, malicious links and attachments, and to know how to report quickly.

An incident response plan and exercises are the first documents to complete after recovery. A one-page plan is enough to start: who makes the calls, how to disconnect affected computers, where the backups are, and who communicates externally with customers. The plan should record contact details for the IT supplier, insurer, lawyer, Police and HKCERT, and be kept offline — not only on a shared drive that could itself be encrypted. A plan that has never been exercised is very likely to fail in a real incident; desktop exercises should be run regularly to test roles, contact trees and out-of-band communication channels. Post-recovery review should cover: what the intrusion route was, which control failed, how long backup restoration actually took, and what must change next time. Without a review, the same failure will simply repeat.

A One-Page Response Card: Pin It in the IT Room, Don't Just Store It on a Computer

"Deal with it when it happens, find someone then" is the most expensive trap. At the moment of an incident, the contact details for the IT supplier, insurer and legal adviser may be inside the very systems that have been encrypted. A one-page plan prepared in advance, with an offline contact list, costs the least and returns the most. Every SME is advised to write a response card containing: HKCERT's 24-hour hotline 8105 6060; Police reporting channels and the No More Ransom platform; insurer and legal adviser contact details; IT support contact details; and the "five things in the first hour": disconnect, pause sync, protect backups, preserve the ransom note and logs, and make the notification calls. Print this card and pin it in the IT room and in managers' hands — do not keep it only on a computer that could itself be encrypted.

Common Misconceptions, Dismantled One by One

"We have backups, so we are fine" — Wrong. Under double extortion, backups only solve the encryption problem, not the problem of stolen data being published or sold; attackers also target backup systems and domain controllers. HKCERT's guidance requiring offline backup storage and regular restore testing exists precisely because connected backups can themselves be encrypted or deleted.

"Reinstall or switch off immediately — that is cleanest" — Wrong, and it may destroy evidence. Switching off destroys forensic evidence in RAM; wiping and reinstalling destroys logs and system images, affecting police investigation and insurance claims; and some decryption tools only run on the originally encrypted machine (according to individual data-recovery sources). The correct approach is to isolate first, prioritising disconnection without powering off, and to preserve the ransom note, logs and encrypted file samples.

"Paying the ransom guarantees recovery and guarantees nothing will be published" — Wrong. The FBI and CISA state plainly that payment does not guarantee file recovery; paying also cannot guarantee that attackers will delete stolen data; and there is a risk of becoming a target again. This article gives no "ransom payment success rate" figure, because there is no verifiable primary source for one.

"Cloud backup with automatic sync equals offline backup" — Wrong. HKCERT states plainly that cloud backup must have a version history feature, or encrypted files synced to the cloud will overwrite older versions; a true offline backup is a copy isolated from the infected network.

"Ransomware only targets large companies or government" — Wrong. HKCERT's 2025 incident figures show phishing and vulnerability exploitation occurring at scale; HKCERT also notes that SMEs often lack the resources to build broad network defences, making them easy targets, and has produced an *Incident Response Guideline for SMEs* for this reason. The difference for SMEs is not whether they will be hit, but that they have fewer recovery resources.

"We can report to the Police or the PCPD after we are hit; there is no need to prepare beforehand" — Wrong. PCPD guidance requires a written response plan to be drawn up in advance; HKCERT's self-help guidance requires email headers and logs to be retained in normal times, and trying to make up for this after an incident is often too late. The InvestHK case's public approach was same-day multi-party notification, not notification weeks after the event.

"After reinstalling, using the same passwords and VPN settings will be fine" — Wrong. If the intrusion source — stolen credentials, an unpatched vulnerability, a VPN without MFA — has not been eliminated, going back online is equivalent to reopening the door. Intrusion-source investigation and credential resets must be completed before recovery.

Conclusion: Being Hit Is Not the End of the World — But Having No Preparation Is

The ransomware trends tell us three things. First, the scale of attacks is expanding: leak-site claims rose by nearly 50% in 2025. Second, attack targets have expanded from personal computers to virtualisation hosts and backup systems. Third, double extortion puts a gap — the gap of data leakage — between "restored" and "all clear". For Hong Kong SMEs, the response is not to buy the most expensive tool, but to get the order right: in normal times, maintain offline backups and restore testing, MFA, patching and segmentation; at the moment of an incident, disconnect and isolate, preserve evidence and backups, and report under the guidance; after recovery, review and harden, and write a one-page response card. None of this work requires invented prices, and none of it requires mythology — all of it can start today. Service fees are subject to individual quotation throughout.

Further reading: for the general ransomware response guide (first steps, ransom payment risks, backup recovery basics), see Ransomware Response Guide for Hong Kong SMEs: First Steps & Recovery. This article is the 2025–2026 deep dive on latest trends, virtual machine targets and Hong Kong reporting procedures.

Frequently Asked Questions

Q1: What is the first thing to do after a ransomware attack?

First, disconnect and isolate affected devices: unplug Ethernet cables, disconnect Wi-Fi, Bluetooth and shared disks, and pause cloud sync, keeping backups away from the infected network. Then preserve the ransom note, logs and encrypted file samples, and contact IT support, the Police and HKCERT. Do not wipe machines or reinstall on your own without immediate IT / incident-responder judgement, so as not to destroy evidence.

Q2: Must I report to the Police? What is HKCERT's hotline number?

Reporting to the Police assists investigation and is an important step for insurance claims and evidence preservation; victims can report to the nearest police station or via the online form. HKCERT's 24-hour hotline is 8105 6060, for enquiries or assistance. 18222 is the Police's 24-hour anti-scam helpline, for enquiries and help — it is not a ransomware hotline.

Q3: If personal data may have been leaked, when should the PCPD be notified?

Under the PCPD's current guidance, data users should notify the Commissioner and affected data subjects as soon as practicable after becoming aware of a data breach, particularly when the breach is reasonably likely to pose a real risk of significant harm to data subjects; notification should not be delayed merely because an internal investigation is incomplete. Current notification is guidance advice, not a mandatory statutory provision; mandatory deadlines discussed in the reform debate have not formally taken effect, and readers should rely on formal announcements by the PCPD and the Government. When in doubt, consult a legal adviser first.

Q4: Does having backups mean I have nothing to fear?

No. Backups only solve the problem of files being encrypted; they do not solve the problem of data already having been stolen. Under double extortion, attackers can threaten to publish stolen data, so even if all files are restored, the leakage threat and notification obligations remain. Moreover, backups themselves may be encrypted, deleted or never tested for restoration. Only backups with offline copies, version history and regular restore testing count as reliable.

Q5: Will No More Ransom definitely decrypt my files?

Not necessarily. The Police page states plainly that decryption tools do not apply to all ransomware, and the newest variants may have no solution. The correct approach is to use a clean computer to identify the ransomware variant, then check No More Ransom for a free tool; even when a tool exists, test it on a copy first. Never download so-called decryptors of unknown origin — fake decryptors are themselves malware traps.

Q6: Is paying the ransom the fastest solution?

The FBI and CISA strongly discourage paying ransoms: payment does not guarantee file recovery, does not guarantee attackers will delete stolen data, and may encourage attackers to target more organisations. Before paying, it must be clarified whether data has already been leaked, whether a clean backup exists, and whether the recipient is on a sanctions list. No payment decision should be made hastily by one person at the moment of attack; legal advisers and law enforcement should be consulted first.

Q7: Are small companies not targets?

No. HKCERT notes that SMEs often lack the resources to build broad network defences, making them easy targets, and has produced an SME incident response guideline for this reason. Automation has lowered the cost of launching attacks. The difference for small companies is not whether they will be hit, but that they have fewer recovery resources — which makes advance preparation even more important for them.

Q8: Does cloud sync (such as OneDrive or Google Drive) count as backup?

Not entirely. Sync only copies the current state to the cloud, so encrypted files synced upwards will overwrite good versions; genuine backup requires version history and immutable settings. HKCERT has long reminded users to confirm that a cloud backup provider offers a version history feature. As for Microsoft 365, mailbox, OneDrive and SharePoint restore options and retention periods must be checked separately — do not assume the platform itself equals a complete backup.

Sources

• HKCERT mid-year review: 2026 first-half incident statistics and trends
• HKCERT: ransomware evolved — double extortion and fake decryptors
• HKCERT: remote access tools and NAS devices ransomware warning
• HKCERT: ransomware keeps evolving — multiple extortion
• HKCERT: crypto-ransomware warning
• HKCERT: data protection guideline
• HKCERT: self-help guide for security incidents
• HKCERT: ransomware's new front
• Hong Kong Police: No More Ransom project
• InvestHK ransomware incident, government news
• Legislative Council written reply on government IT ransomware incidents
• PCPD breach guidance, secondary summary (Linklaters)
• PCPD breach guidance, secondary summary (Sidley)
• Analyst1 2025 ransomware extortion review
• LockBit 5.0, secondary summary
• Ransomware trends, secondary summary
• Sophos 2025 report, secondary summary
• CISA guidance, as relayed
• SafePay joint advisory analysis
• Backup strategy (3-2-1-1-0) guide
• Immutable backups explained
• Why backups still fail
• HKCERT Outlook 2026, as republished

Related Articles

• Ransomware Response Guide for Hong Kong SMEs: First Steps & Recovery
• Backup Is Not Recovery: Restore Tests and Immutable Backups
• Hong Kong Backup Strategy Guide: The 3-2-1 Rule Done Properly — Time Machine, Windows, Cloud and Offline Drives