Ransomware

Symantec's Threat Hunter team pulled apart a ransomware intrusion at a United States organization in October 2026 and found something it had not documented before: a custom backdoor it now tracks as Backdoor.Lindnor. The investigation started on the two machines that were the environment's only Microsoft SQL Server hosts, because that is where the implant turned up. The attackers were staging Anubis ransomware, and defenders cut the intrusion off before the encryption payload ran.

Blocking the encryption kept the files intact, but it does not undo what the attackers already had. They held code execution on two internet-adjacent database servers, disabled the endpoint protection on them, and had a remote access path ready before anyone noticed. Database servers draw this kind of attention because they tend to run as a high-privilege service, hold the data worth stealing, and sit on the same segment as the application tier, so a foothold there reaches both the crown jewels and the rest of the network.

How it works

Lindnor is a backdoor: once it runs, it calls out to the attacker and waits for commands. Symantec found it on each SQL host under a file name chosen to look like something you would expect to see. On one server it ran as healthcontroller64.exe from a directory dressed up as a Google Chrome component. On the other it ran as svchelper.exe inside a folder made to look like VMware. On a process list or in Explorer, either one reads as ordinary software.

For its command and control (C2), the channel an implant uses to receive instructions and send data back, Lindnor connects to a primary server and a fallback address over TCP port 443. That is the same port web browsers use for encrypted HTTPS traffic, so a connection from a server to an unfamiliar host on 443 does not stand out in a firewall log the way an odd high port would. The traffic hides in the noise of ordinary Transport Layer Security (TLS), the encryption that secures HTTPS.

The part that should worry defenders is how the attackers cleared the way. They used a technique called bring your own vulnerable driver (BYOVD). A driver is kernel-level code that Windows trusts because it carries a valid signature; some legitimately signed drivers contain bugs that let whoever loads them run their own code in the kernel. The attackers loaded such a driver and used it to reach into the kernel and switch off endpoint protection from below, where a normal user-mode security product cannot defend itself. Symantec's reporting describes a large toolset for this: around 13 security-disabling programs, most of them not previously seen in public, alongside five signed-but-vulnerable drivers.

Two of those tools stand out. They were named gbbsym.exe and symgooq.exe to pose as Symantec components, and they could enumerate the kernel callbacks that security software registers and then strip them out of memory. Callbacks are the hooks a protection product plants so the kernel notifies it when a process starts or a driver loads. Remove the callbacks and the product goes blind without being uninstalled or obviously stopped. On the SQL hosts, Symantec saw the attackers go from active to blinding the endpoint sensors within roughly an hour.

What was seen

The intrusion hit a single United States organization in October 2026, and the credit for the finding is Symantec's; this is reporting on their research. The two SQL Servers were the only SQL hosts in the environment, which is why the backdoor showing up on both of them was the thread the investigation pulled. How the attackers first got in is not known.

Anubis is the ransomware that was staged. Symantec attributes it to a ransomware-as-a-service operation it tracks as Hawkmoth, meaning the group rents the encryptor to affiliates who carry out the break-ins. In this case the affiliate got as far as deploying the toolset and the backdoor, but the encryption stage was stopped before any files were locked.

The attackers also set up to survive a reboot into Safe Mode. They added a registry entry that registered AnyDesk, a legitimate remote access tool, to start under Safe Mode with Networking. Safe Mode loads a minimal set of drivers and services, and most endpoint protection does not fully run there, so booting a suspected machine into Safe Mode to clean it can instead hand the attacker a working remote session with the defenses switched off. A remote access trojan (RAT), or any remote tool, configured to run in Safe Mode is a sign of an operator who expects to be investigated.

What to do

If you see these indicators, isolate and investigate the SQL hosts first, but pull them off the network rather than rebooting into Safe Mode, because Safe Mode is exactly what the attackers prepared.

1. Hunt for the file names and the callout. Search both SQL Servers and the wider estate for healthcontroller64.exe and svchelper.exe, and for executables running out of folders that imitate Chrome or VMware. Review outbound TLS connections from database servers to unfamiliar hosts on port 443; a SQL Server reaching out to an address that is not a known update or monitoring endpoint is worth chasing.
2. Audit service-install events. On the SQL hosts and nearby servers, check Windows event ID 7045 in the System log and event ID 4697 in the Security log, both of which record a new service being installed, and flag any service you cannot tie to a known install. Lindnor ran as a service, so a rogue service pointing at a Chrome or VMware lookalike path is a strong lead.
3. Verify your protection is actually running. Because the attackers blinded the endpoint sensors through a vulnerable driver, confirm on each host that the protection service is live and reporting, not just installed. Turn on Microsoft's vulnerable driver blocklist and add detections for the loading of known-vulnerable drivers, so the BYOVD step is caught rather than the payload after it.
4. Harden SQL Server itself. Run the SQL Server service under a dedicated low-privilege account, not Local System or a domain admin. Disable xp_cmdshell unless a specific application needs it, since it turns a database login into operating-system command execution. Set strong, unique credentials for the sa account and every service account, and keep SQL Server off the public internet so the database tier is reachable only from the application hosts that need it.

Where this leaves you

One unexpected executable on one server is a reason to investigate the rest. The same crew blinded two hosts in about an hour and left a Safe Mode foothold behind, so a host with these indicators needs a full investigation of what the account could reach before it goes back into service.

If you want someone to run these hunts and check whether your endpoint protection has been silently switched off, our security operations work does exactly that, and our safeguarding and hardening team can lock down SQL Server and drivers so the BYOVD step fails. A network penetration test will show you whether a foothold on a database server can reach the rest of your estate the way this one could. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: SecurityOnline on Lindnor and Anubis, SOC Prime on Backdoor.Lindnor detection, Symantec Threat Hunter Team on BYOVD defense evasion, SecurityLab report (13 programs, five drivers).