Synology NAS ransomware and what service hiding changes

A NAS carries file sharing, backup, collaboration and remote administration all at once, and so it ends up holding a large share of a company’s important data. Once an attacker takes control of the device, the damage can reach production documents, application data, and the backups stored on that same device.

HKEPC recently reported that some Synology NAS devices were hit by ransomware, with files renamed to carry a “.L0CK3D” extension. On 29 October 2026 Synology issued a statement saying it had found attackers exploiting a vulnerability patched in December 2024 to go after devices still running outdated DSM. Because the media and the vendor describe the point of entry differently, not every reported case can be attributed to the same exploit chain.

From an architecture point of view, the question this incident raises is this: before authentication has happened, can an outside source already reach the NAS’s services?

Exposed services mean an attack surface exists before login

To provide remote access, companies often use NAT and port forwarding to publish the NAS’s admin interface or application services to the internet.

In that setup, an outside source needs no valid account to open a network connection to the service and send requests to the web server, the API or other protocol handlers. The username-and-password check is just one control further down the line.

If the flaw sits in the request handling that runs before authentication, an attacker may trigger it directly without going through the normal login. So even with MFA switched on, a company cannot treat it as protection against every unauthenticated remote vulnerability.

Two layers need to be told apart here: the application’s login decides whether a user can operate its functions; network- and service-layer access control decides whether the other side gets the chance to reach the application at all.

Merak moves access control ahead of the service connection

Merak’s service-hiding architecture denies unauthorised connections by default, placing authentication and authorisation before a connection to the protected service is set up.

Taking a NAS as the example, a deployment can bring the DSM admin interface, file services and related apps under protection and remove the old direct public entrance. Users must first pass Merak’s authentication and authorisation before they can set up an encrypted connection to the designated service.

The point of the design is that the NAS no longer has to take application requests directly from arbitrary internet sources. Attacks that rely on public reachability for scanning and exploitation can have their connection path restricted before the request reaches the NAS.

In this architecture, each control does a different job:

• Default-deny for unauthorised connections: keeps outside sources from reaching protected services directly.
• mTLS mutual authentication: verifies certificates and identity between both ends of the connection.
• MFA: strengthens user authentication and reduces the risk of a single stolen password.
• RBAC service-level authorisation: opens only the services a role needs and limits what can be connected to.

For example, regular employees can be authorised to use NAS file services without being allowed to connect to the DSM admin interface, while operators are given access to the management services according to their role. Passing authentication does not mean being able to reach every internal service.

This kind of service-level authorisation still has to be paired with the NAS’s own accounts, shared folders and file permissions to fully limit what a user can do.

Reducing exposure depends on leaving no bypass path

Whether service hiding works depends on whether every access path has been brought under control.

If the NAS is under Merak’s protection but the router still keeps a port forward straight to it, outside sources may be able to bypass authentication. Other remote access entrances, reverse proxies and internal network paths also need to be inventoried alongside it.

A deployment should confirm that the protected services accept connections only from authorised paths, and check network segmentation and firewall rules. Changing the port, hiding the URL or not publishing the DNS name is not, on its own, enough to establish this kind of access restriction.

Service hiding reduces reachability; patching and backups handle the rest

Merak reduces the chance that an unauthorised source exploits a NAS service flaw directly, and it is especially suited to protecting services meant only for employees, operators or specific partners.

But service hiding does not remove the device’s own vulnerabilities. If the attack comes from an authorised endpoint that has been compromised, or the ransomware is already running on the NAS, the job still falls to endpoint protection, least privilege, system patching and incident response. And for a legitimate connection with write access, service-level authorisation cannot judge by itself whether each file change is malicious.

NAS protection therefore has to handle three things at once: limit who can reach the services, keep patching exploitable vulnerabilities, and keep backups an attacker cannot easily rewrite or delete.

Merak’s part in this is to shrink the range from which the services can be reached first. Opening the NAS’s management and file services only to authenticated and authorised identities reduces the risk of staying exposed to attacks from the public internet after a vulnerability is announced and before the patch is in.

Terms and further reading