KINWILDER

Breaches & ransomware · Briefing

HKCERT warns of ransomware targeting Synology NAS devices

Check whether storage appliances can run supported software, and assess recovery readiness alongside patch deployment.

Kinwilder research desk · · AI-assisted analysis

What is established

HKCERT’s alert, published on 2 November 2026, reports ransomware encrypting Synology NAS data. It relays Synology’s account that attacks targeted end-of-life DiskStation Manager (DSM) versions through a vulnerability patched in December 2024. Attack dates are unspecified. Source: HKCERT.

Separate PHP2Shell package fixes are also discussed; Synology has not confirmed PHP2Shell involvement in the ransomware attacks. Source: HKCERT.

Who is behind it

Attribution is not established: the alert names no operator, ransomware brand, affiliate or state association. Source: HKCERT.

Analysis: A product being targeted does not identify the people targeting it. Defenders should keep actor labels separate from evidence about access and impact. Neither a familiar ransom-note style nor a plausible motive would, by itself, justify assigning this activity to a particular group.

Our analysis

Original analysis: The immediate defensive question is whether an appliance’s software lifecycle matches its operational importance. A storage system can remain useful long after its maintenance plan becomes inadequate. Checking that gap is more actionable here than speculating about an unnamed attacker.

The technical entry path remains uncertain. A conceptual attack path would run from an exposed service, through a software flaw, to permissions capable of altering stored files. That is an assessment model, not a reconstruction of these incidents. The supplied evidence does not identify the vulnerable component, authentication requirements or execution context.

The authorization invariant is straightforward: only approved identities and processes should be able to modify stored data, administer storage or change recovery controls. An investigation should determine which of those boundaries was crossed and with what privileges. Finding encryption establishes an impact; it does not establish how access began.

Potential exposure should therefore be assessed through inventory and reachability. Which appliances accept connections from outside trusted networks? Who owns their maintenance? Can they run supported software? Treat unanswered questions as investigation priorities, not evidence of compromise. Watch for more precise vendor information that would let defenders narrow this assessment.

Defensive actions

HKCERT recommends supported DSM upgrades, applicable package updates, reduced internet exposure and offline or immutable backups. For suspected infection, it recommends isolation and evidence preservation. Source: HKCERT.

Original defensive guidance, in priority order:

  1. Establish a device-by-device decision record. Capture the model, installed software, package inventory, administrative owner and reachable services. Check each device against authoritative vendor support information before choosing an upgrade destination. Assign an owner and deadline to every unresolved compatibility question.
  2. If suspicious activity is present, investigate its scope. Identify clients, service accounts and scheduled tasks with write access to the affected shares. Decide containment boundaries using those relationships rather than assuming the appliance is the entire incident.
  3. Hunt using available authentication, administration and file-service telemetry. Examine unexpected administrative sessions, permission changes and bursts of file modifications. Correlate timestamps across sources; any one behaviour can have legitimate explanations. These are proposed investigative leads, not indicators published for this campaign.
  4. Assess recovery independently. Identify who can alter retention settings, delete recovery copies or approve restoration. Ask whether one compromised administrative identity could control both production data and recovery resources. Record the evidence supporting the answer.
  5. Make lifecycle ownership explicit. Give each appliance a replacement decision date and an escalation path when business requirements outlast software support. Require a documented reason for every externally reachable management service.

Key concepts

Limits

This is single-source reporting. The alert supplies no CVE, fixed DSM version, victim count, affected sector or victim country. Source: HKCERT.

Synology’s account is relayed through HKCERT, not independently corroborated here. Kinwilder did not reproduce the attacks or validate an entry point. The analysis and investigative suggestions above are proposals for defensive assessment, not findings from affected systems.


Kinwilder briefing: AI-written analysis of public reporting, checked in a separate AI review against the linked sources. No human expert review or independent reproduction is implied.

Sources

Editorial standard · root@kinwilder.com · RSS · Outpost