Lindnor Backdoor SQL Server Attack: New Malware Disguised as Chrome and VMware Files in Anubis Ransomware Intrusion, What Is Confirmed and How to Check Yours

Symantec reports that attackers using Anubis ransomware installed a previously undocumented backdoor called Lindnor on two Microsoft SQL Server machines at a U.S. organization in October 2026, disguising it as Chrome and VMware files. If your business runs SQL Server, this matters because a familiar name in a process list proves nothing, and the servers holding your records deserve a check this week.

The ransomware itself failed: Symantec says the encryption payload was blocked and found no evidence that files were encrypted. There is no patch to install, because Symantec did not identify how the attackers got in and its report does not tie the intrusion to a SQL Server bug.

What is the Lindnor backdoor?

A backdoor is a program that gives an attacker continuing remote access to a machine. Symantec's Threat Hunter Team, part of Broadcom, documented Lindnor on November 5, 2026. On the two servers it was installed as:

• healthcontroller64.exe, in a folder made to resemble a Chrome component unpacker directory
• svchelper.exe, in a VMware folder

It appears to have run as a Windows service. It sends its command server the process ID, operating system version, its own file path, computer name, user name, domain and logon server, using a primary and a fallback server over port 443, the port ordinary encrypted web traffic uses. Symantec's indicator list also ties powerhost.exe, eventwatcher.exe and volumeproxy.exe to Lindnor.

How the Anubis ransomware attack on SQL Server unfolded

These are the main stages Symantec describes:

1. Lindnor was detected first. It was the first sign of the intrusion, found on the only two SQL Servers among the affected machines.
2. Security tools came under attack. Within roughly an hour, the attackers dropped at least 13 programs meant to shut down security services, along with five publicly known vulnerable drivers. Symantec says 11 of the 13 appear to be previously unpublished, and two posed as Symantec software. Using a signed but flawed driver to switch off protection is called "bring your own vulnerable driver," or BYOVD.
3. Remote access was added. The attackers installed the legitimate tool AnyDesk, created a local user account, added it to a local group, and registered AnyDesk to run in Safe Mode with Networking. Symantec notes that security software generally does not fully operate in Safe Mode.
4. The ransomware was blocked. The payload, iservice.exe, appends .anubis to files and leaves notes named restore files.txt and restore files.html. Anubis also has an optional wiper mode that leaves files completely empty.

Lindnor: what is confirmed, what is claimed and what is not known

Confirmed by Symantec's investigation: the backdoor, its file names and indicators, the security-killing tools, the AnyDesk Safe Mode change and the blocked payload. Symantec also saw Lindnor on the networks of two other unrelated organizations, with no ransomware activity identified there. At the time of writing, the technical detail comes from Symantec alone.

Claimed: Symantec reports that Anubis has claimed about 96 victims in the past 12 months, with 52% in the U.S. Those are the ransomware operators' own claims. Symantec says Anubis is developed by a group it tracks as Hawkmoth, a ransomware-as-a-service operation that emerged in December 2024 as a rebrand of Sphinx.

Not known:

• How the attackers got in
• The victim's name or industry
• What commands Lindnor accepts, which the report does not describe
• Whether data was stolen in this attack. Symantec lists no theft tools for it, though a July 2026 Anubis attack used four: Megasync, WinSCP, FileZilla and S3 Browser
• Whether SQL Server was the deliberate target or simply where the backdoor landed
• What huntreagent.exe and s1.exe do, because they were not available to Symantec for analysis

How to check SQL Server for Lindnor this week

Run these on every SQL Server, including any that a vendor set up for you. A match is a lead to investigate. A clean result is not an all-clear, because attackers can rename files.

1. Look for the known file names in Windows services. In an administrator PowerShell window:

Get-CimInstance Win32_Service | Where-Object PathName -match 'healthcontroller64|svchelper|powerhost|eventwatcher|volumeproxy' | Select-Object Name, PathName

2. Check for the Safe Mode change. Run the line below. If the key exists and AnyDesk is not your approved tool, treat it as an incident.

reg query HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\AnyDesk

3. Account for every remote access tool. AnyDesk on a database server should have an owner and a reason. CISA's ransomware guide advises blocking common remote management ports at the network edge and using authorized tools only over approved remote access.
4. Review new accounts. If auditing is on, search the Security log for event 4720 (user account created) and event 4732 (member added to a local group).
5. Search for Symantec's indicators. Check DNS and firewall logs for msrcontrib[.]com and cfgsync-relay.eastus.cloudapp.azure[.]com, removing the brackets first. Load the file hashes from Symantec's report into your endpoint security tool.
6. Tighten driver blocking. On Windows, go to Windows Security, then Device security, then Core isolation details. Microsoft says its vulnerable driver blocklist has been on by default since the Windows 11 2022 update and is also enforced when memory integrity is active, except on Windows Server 2016, so check servers rather than assuming. The list is not guaranteed to catch every driver, and we have not confirmed whether it covers these five. If you use Microsoft Defender, Microsoft also recommends the attack surface reduction rule that blocks abuse of vulnerable signed drivers. Test in audit mode first, since blocking drivers can break software.
7. Close the likely doors. These are general hardening steps that Symantec did not tie to this attack. Confirm that TCP 1433, the default SQL Server port, is not open to the internet, and keep remote desktop off the web. Require multifactor authentication for machine-level access. Confirm that xp_cmdshell, which is off by default, is still off:

SELECT name, value_in_use FROM sys.configurations WHERE name = 'xp_cmdshell';

8. Test your backups. CISA advises offline, encrypted backups that you test regularly. Microsoft advises securing backups separately from common administrator accounts, so that an attacker with those accounts cannot delete them.

If anything matches, take the server off the network, keep its logs and disk intact, and bring in incident response before deleting anything.

Why the Lindnor attack matters for a company network

Database servers often hold the records a business cannot run without, and they tend to be left alone once they work. This case shows how quickly a ransomware crew can move against one: Symantec counted at least 13 tools aimed at security software within roughly an hour.

It also shows the limit of a good outcome. A blocked payload does not remove a backdoor, a new account or a remote access tool already in place, so "the ransomware was stopped" is the start of the cleanup, not the end. If you run your own database servers, someone should own this work by name. Our notes on self-hosting infrastructure cover what that involves.

Lindnor backdoor questions people are asking

Is there a patch for the Lindnor backdoor?

No. Lindnor is malware, not a software flaw, and Symantec did not identify how the attackers got in. Keep Windows and SQL Server updated anyway, and use the checks above.

Was SQL Server hacked through a vulnerability?

Not as far as anyone has shown. Symantec found Lindnor on two SQL Servers but says it did not identify the initial access route.

How do I know if my SQL Server has Lindnor?

Check services for the five known file names, search your logs for Symantec's domains, and compare files against its published hashes. Renamed files can slip past a name search, so use endpoint security tooling as well.

Does Anubis ransomware delete files?

It can. Symantec describes an optional wiper mode that leaves files completely empty, on top of normal encryption.

The bigger lesson

Malware does not have to look strange to be dangerous. Here it borrowed the names of Chrome, VMware and even the security vendor's own products, and only behavior and layered defenses gave it away. Know what should be running on your most important servers, and treat anything you cannot explain as a question that needs an answer.

For help locking down your servers, see our security hardening work or request a quote.

Get security alerts by email, with the free checklist, at our security alerts page.

Sources: Symantec Threat Hunter Team: Lindnor report; Microsoft: recommended driver block rules; Microsoft: device protection in Windows Security; Microsoft: SQL Server security best practices; Microsoft: xp_cmdshell; Microsoft: SQL Server firewall ports; Microsoft: event 4720; Microsoft: event 4732; CISA: StopRansomware Guide.