Anubis ransomware actors deployed a newly identified backdoor and an unusually large collection of security-disabling tools during an attack on a US organisation. The October 2026 intrusion reached the ransomware stage, but defenders blocked the encryption payload before it could execute.
Symantec disclosed the incident on 5 November 2026. Its investigation found the custom Lindnor backdoor on two Windows hosts, both of which were Microsoft SQL Server machines, followed by at least 13 executables designed to interfere with endpoint security.
Anubis ransomware attack timeline
The intrusion took place in October 2026, although investigators could not establish how the attackers first entered the environment. The earliest identified activity was the presence of Backdoor.Lindnor on two affected systems.
These systems were significant because they were the only two Microsoft SQL Server hosts in the organisation’s affected environment. However, no specific SQL Server or Windows versions were reported, and the available evidence does not establish whether a SQL vulnerability provided initial access.
Within roughly one hour of Lindnor being discovered, the attackers deployed at least 13 separate security-disabling executables. They also introduced five known vulnerable signed drivers, installed the legitimate AnyDesk remote access application and prepared remote access to continue in Windows Safe Mode.
The intrusion subsequently progressed to an Anubis ransomware payload reportedly named iservice.exe. Security controls blocked that file before execution, preventing encryption. No destructive wiper activity was reported in this incident.
Symantec published its findings on 5 November 2026. Further coverage appeared between 6 and 9 November, but no additional exploitation details or changes to the incident outcome were reported.
How the Lindnor backdoor operated
Lindnor is a previously undocumented Windows backdoor developed to provide persistent access and basic information about a compromised host. Custom backdoors are relatively uncommon in ransomware intrusions, where affiliates often rely on publicly available tools or legitimate operating system functions.
Masquerading as legitimate components
On one SQL Server, the Anubis ransomware actors named the backdoor healthcontroller64.exe and placed it in a directory made to resemble a Google Chrome component unpacker. On the second server, it appeared as svchelper.exe inside a VMware-like directory.
Both copies were installed as Windows services. This allowed the malware to run in the background while its filenames, locations and service-based execution helped it resemble legitimate software activity.
After execution, Lindnor collected and transmitted host information including:
- The backdoor process ID and file path.
- The installed Windows version.
- The computer name and current user name.
- The Windows domain and logon server.
The backdoor communicated with primary and backup command-and-control infrastructure over port 443. Because this port normally carries encrypted web traffic, connections may blend into routine network activity unless organisations inspect server destinations and identify unusual communication patterns.
Symantec also detected Lindnor on two unrelated networks where ransomware activity did not follow. Those sightings confirm that the backdoor is being used in the wild beyond this single attack, although its precise relationship with Hawkmoth affiliates remains unclear.
Anubis ransomware used at least 13 security killers
The volume of defensive evasion tooling was one of the incident’s most notable features. At least 13 executables were deployed in about an hour, apparently giving the attackers several opportunities to disable antivirus and endpoint detection and response products.
Two utilities, gbbsym.exe and symgooq.exe, masqueraded as Symantec components. Their capabilities included listing kernel callbacks through a vulnerable driver and removing those callbacks, behaviour consistent with attempts to stop security software from monitoring malicious processes.
Other reported filenames included huntreagent.exe and s1.exe, which were likely separate builds of the same utility. Most of the 13 security-disabling executables had not previously been described publicly, limiting opportunities for defenders to identify the toolset through established threat intelligence.
Vulnerable drivers provided kernel access
The Anubis ransomware operators brought five signed but vulnerable drivers into the environment. This technique is known as Bring Your Own Vulnerable Driver, or BYOVD.
Windows normally trusts a legitimately signed driver to perform privileged operations. Attackers can abuse a known flaw in such a driver to obtain kernel-level capabilities, then use that access to terminate security processes or remove the callbacks used by EDR products. The drivers were known to be vulnerable, but the reviewed public reporting did not identify their individual names.
This approach does not mean the targeted security software itself contained the exploited vulnerability. Instead, the attackers introduced third-party drivers that could be abused to undermine defensive controls from inside the operating system.
AnyDesk configured for Safe Mode
The attackers also installed AnyDesk, created a local account and used a helper utility called safemode.exe. That helper configured AnyDesk to start in Safe Mode with Networking.
Many endpoint security components provide reduced functionality in Safe Mode because Windows loads a restricted set of services and drivers. Maintaining remote access under those conditions could allow an attacker to continue operating while attempting to load vulnerable drivers, disable security controls or prepare the ransomware payload.
Who is behind the Anubis ransomware operation?
Symantec tracks the developer of Anubis as Hawkmoth. It assesses Anubis to be a ransomware-as-a-service operation that emerged in December 2024 as a rebrand of Sphinx ransomware, with the underlying payload remaining largely unchanged.
Under the service model, affiliates conduct intrusions using the ransomware operator’s payload and infrastructure. Tactics can therefore vary between incidents. In a July 2026 case, attackers associated with the operation used Megasync, WinSCP, FileZilla and S3browser for data theft, demonstrating a willingness to try several tools serving the same purpose.
The operation claimed roughly 96 victims during the 12 months preceding the report, with about 52 percent located in the United States. The October incident confirms active exploitation, even though encryption was stopped.
What organisations should check now
Organisations running Windows and on-premises Microsoft SQL Server systems should use the disclosed artefacts to guide focused threat hunting. Their presence is not proof of ransomware by itself, but unexplained matches require investigation.
- Search for healthcontroller64.exe, svchelper.exe, gbbsym.exe, symgooq.exe, huntreagent.exe, s1.exe, safemode.exe and iservice.exe.
- Review newly created Windows services and binaries stored in unexpected Chrome-like or VMware-like directories.
- Investigate outbound port 443 traffic from database servers to unfamiliar destinations.
- Check for unauthorised AnyDesk installations, local accounts and Safe Mode persistence.
- Apply Microsoft’s vulnerable driver blocklist, restrict driver installation and verify that EDR tamper protection is enabled.
The blocked encryption stage shows that layered controls can interrupt Anubis ransomware even after attackers establish persistence. Detection should nevertheless focus on the earlier Lindnor, driver-loading and Safe Mode activity, before affiliates can disable protection and launch their final payload.
Originally reported by cybersecuritynews.com.
