The Lindnor backdoor is a new custom implant that Symantec found in an October 2026 ransomware attack on a US organization. Symantec says the attackers used the Anubis ransomware and dropped at least 13 security-killing programs within roughly an hour. This post is a hunt plan: what to look for, in the order to look, and what to do on a match.
Symantec says the encryption payload was blocked and it has no evidence that files were encrypted. We name no victim and list no hashes or domains. Symantec’s post carries its indicators for your blocklists.
What Is the Lindnor Backdoor and Who Uses It?
Symantec calls it Backdoor.Lindnor. It appears to have run as a service, installed once in a folder made to look like a Chrome component unpacker directory and once in a VMware folder. It was found on two Microsoft SQL Server machines, the only two SQL Servers among those affected. Symantec did not identify how the attackers got in.
The backdoor sent the process ID, operating system version, its own file path, computer name, user name, domain and logon server to a command-and-control server. It was set up with a primary server and a fallback, both reached over port 443. Symantec also saw the backdoor on the networks of two other unrelated organizations, where no ransomware activity was identified.
The ransomware is Anubis, which Symantec says is developed by a group it tracks as Hawkmoth. The operation is ransomware-as-a-service and emerged in December 2024 as a rebrand of Sphinx, so different affiliates may run Anubis attacks. Symantec says the group has claimed about 96 victims in 12 months, 52% of them in the US.
- Time frame.
- October 2026.
- Backdoor.
- Backdoor.Lindnor, a custom implant that ran as a service on two SQL Server machines.
- Security killers.
- At least 13 executables dropped within roughly an hour, plus five signed but vulnerable drivers.
- Remote access.
- AnyDesk, a new local account, and a setting that lets AnyDesk run in Safe Mode with Networking.
- Outcome.
- The encryption payload was blocked; Symantec has no evidence of encrypted files.
How Do the Attackers Switch Off Security Software?
The attackers favoured bring your own vulnerable driver (BYOVD), dropping five signed but publicly known vulnerable drivers to gain kernel-level access. Symantec says 11 of the 13 executables appear to have been unpublished before. Two posed as Symantec software and could list and remove kernel callbacks through a loaded vulnerable driver. The observed command lines show removal was used.
All but two of the dropped programs were blocked. Symantec could not analyse those two, so their exact purpose is unknown, though they may have run one of the drivers. Symantec says the pattern fits attackers trying one tool after another until one works. It adds that ready-made BYOVD tooling is routinely bundled into ransomware-as-a-service offerings.
The second route is Safe Mode. The attackers installed the legitimate tool AnyDesk, created a local account and added it to a local group. They then ran a registry change that registered AnyDesk as a service allowed to run in Safe Mode with Networking. Symantec notes that security software generally does not fully operate in Safe Mode, which gives attackers a window to use the drivers.
How Do You Hunt for This Intrusion, Step by Step?
The order below starts with the hosts Symantec saw and moves outward. All seven steps are our hunt plan built on Symantec’s findings. Run each query over at least October 2026.
The ATT&CK ids are our mapping, not Symantec’s. They are exploitation for privilege escalation for the driver abuse, T1543.003 for the service, T1562.001 for disabling tools and T1219 for AnyDesk.
- Start with servers, database servers firstSymantec found the backdoor on its two SQL Servers. List every Windows server, put database servers at the top, and treat a server with no security agent heartbeat as a lead on its own.
- Find odd servicesIn the System log, review new service installs (event 7045) and in the Security log, service installs (event 4697). Flag a service whose file sits in a folder named for Chrome or VMware on a host that does not run that software.
- Check outbound port 443 from serversIn firewall, proxy or flow logs, look for servers that make long-lived HTTPS connections to rare hosts, especially a pair of destinations where one appears only when the other fails. A database server rarely browses the web.
- Look for the burst of new executablesIn endpoint or file-creation telemetry, look for a dozen or more new executables on one host within an hour. Also flag programs named like a security vendor’s tools that run from a user or temp folder.
- Review driver loadsSysmon event 6 or your EDR’s driver-load telemetry shows signed drivers loading. Compare each new driver with a public vulnerable-driver list and with your own baseline. A driver nobody installed is a lead.
- Look for the Safe Mode setupCheck for remote tools you did not deploy, such as AnyDesk, and for new local accounts in local groups. Also check registry entries under the SafeBoot Network key that register a service for Safe Mode with Networking.
- Check security agent healthLook for stopped security services, tamper alerts and gaps in telemetry on the same hosts, since the attackers set out to end those services.
Why this order: the backdoor is the quietest sign and the burst of tools is the loudest. Start with the servers Symantec names, then follow the signs that run from a service install to a driver load, and last check whether the agent went silent. An unexplained gap in agent telemetry is worth treating as a hit even if no tool is found.
What Should You Do If Something Matches?
These are our recommendations, not Symantec’s. Isolate the host from the network but leave it powered, so memory and logs survive. Do not reboot into Safe Mode to look around, because that is the mode the attackers prepared. Collect the service file, the driver files and the registry entries before anything is cleaned.
Treat a match as a ransomware intrusion in progress, even though no encryption has started. Symantec says the Anubis note tells victims that data was downloaded from the network. It documented a separate July 2026 Anubis attack in which the attackers used four different tools to copy data out, so also check for bulk data transfers. Rotate credentials that touched the host, rebuild it from known-good media, and follow our ransomware response checklist.
Which Controls Make the Next Attempt Harder?
Our advice is to block known vulnerable drivers where the operating system allows it, and to keep tamper protection on for the security agent. Alert when a security service stops, not only when malware is found. Restrict remote access tools to an allowlist, and review who can add local accounts to local groups.
Symantec’s June 2026 whitepaper on BYOVD, which it links in this post, covers the technique in depth. Our entries on EDR, backdoors and threat hunting explain the terms. For an earlier BYOVD case, read our Reynolds ransomware BYOVD analysis.