The Attack: A Toolbox That Still Failed
In October 2026, attackers using Anubis ransomware hit a U.S. organization with an unusually well-prepared assault. They deployed a previously unknown custom backdoor called Lindnor, dropped 13 different security-disabling executables within an hour, installed five publicly known vulnerable drivers for BYOVD attacks, set up AnyDesk for remote access, and configured it to run in Safe Mode where security software doesn’t fully operate.
The backdoor executables — healthcontroller64.exe and svchelper.exe — masqueraded as legitimate Chrome and VMware components. The 13 security killers were designed to terminate protection software using kernel-level access gained through the vulnerable drivers. Two of them, gbbsym.exe and symgooq.exe, even pretended to be Symantec software.
Despite all this preparation and tooling, the attack largely failed. The encryption payload was blocked before it could run, and no files were encrypted.
Why the Attack Worked (Until It Didn’t)
The attackers succeeded at every step except the last one because they followed the standard playbook: land a backdoor, disable security software, maintain persistence through Safe Mode, then encrypt.
Each of those steps required writing files to disk. The Lindnor backdoor had to be written as healthcontroller64.exe and svchelper.exe. The 13 security-disabling tools had to be dropped as executables. The five vulnerable drivers had to be written to the file system. AnyDesk had to be installed. The ransomware payload iservice.exe had to land on disk before it could attempt encryption.
The organization’s security stack caught the payload at the final stage — after the backdoor was already running, after the security killers were already dropped, after AnyDesk was already configured. That’s damage mitigation, not prevention.
How FileSure Defend Stops This Attack Before It Starts
FileSure Defend operates at the Windows kernel level and intercepts every file operation before it completes. A simple policy rule blocks the entire attack chain at the first file write:
File name filter: *.exe;*.dll;*.sys;*.bat;*.ps1
Program name filter: Whitelist of authorized deployment tools only
Operations: Write, Create
Drive type: Hard drives
Result: Block
When the attackers attempt to write healthcontroller64.exe to the Chrome component directory, FileSure intercepts the write operation. The program attempting the write is not on the authorized list. The write is blocked. The backdoor never lands.
No backdoor means no command-and-control connection. No C&C means the attackers can’t drop the 13 security killers. No security killers means the vulnerable drivers are irrelevant. No AnyDesk installation. No payload delivery. The attack dies at step one.
FileSure doesn’t need to recognize Lindnor or know what gbbsym.exe does or maintain signatures for the five vulnerable drivers. It just enforces: unauthorized programs cannot write executable files to this system. The mechanism is the same whether the backdoor is brand new or five years old.
The Anubis crew brought a massive toolbox and still failed when their payload got blocked. Imagine if their entire toolbox couldn’t even unpack.
Start your free 21-day trial at bystorm.com and see FileSure block a simulated ransomware attack in real time.
Source: New Lindnor Backdoor and Glut of Security Killers Used in Ransomware Attack on U.S. Org
Category: Ransomware
Tags: anubis ransomware, lindnor backdoor, byovd, bring your own vulnerable driver, kernel filter driver, file system security, ransomware prevention, safe mode persistence
