Key findingsAttackers using the Anubis ransomware targeted a U.S. organization in October 2026 using a new custom backdoor that Symantec has called Backdoor.Lindnor.The backdoor masqueraded as a Chrome component and as a VMware file, and was found on two Microsoft SQL Server machines.Within roughly an hour, the attackers dropped at least 13 executables to help terminate security services, along with five publicly known vulnerable drivers.The attackers also installed the legitimate remote access tool AnyDesk and a separate tool to run it in Safe Mode, likely to maintain access when security software was not fully running.The file encryption payload was blocked from execution, and there’s no evidence that any files were encrypted.Anubis has claimed approximately 96 victims in the past 12 months, and 52% of those victims are in the U.S.OverviewAttackers using the Anubis ransomware, which is developed by a group Symantec tracks as Hawkmoth, deployed a previously undocumented custom backdoor and an unusually large number of security software-disabling tools in an October 2026 attack on an organization in the U.S. Hawkmoth runs a ransomware-as-a-service (RaaS) operation that emerged in December 2024 as a rebrand of the Sphinx ransomware. Its payload appears to be largely unchanged from the Sphinx version, with only the branding updated. As Hawkmoth operates an affiliate program, Anubis attacks may be carried out by different groups of affiliates. Attackers using it seem to be particularly tenacious. In a July 2026 Anubis attack documented by Symantec, we noted that the threat actor used four different exfiltration tools (Megasync, WinSCP, Filezilla, S3browser) to steal data from the affected network and that it was unusual to see that many of the same type of tool deployed in a single attack. The group has claimed approximately 96 victims in the past 12 months, and the majority of them (52%) are located in the U.S., which aligns with previous targeting patterns by the group.We did not identify how the attackers gained initial access. The first indicator of the intrusion was the detection of the new Lindnor backdoor, which was found on two machines that were also the only two Microsoft SQL Servers among those affected. Tooling and tradecraftCustom backdoorThe backdoor, called Backdoor.Lindnor, was installed with the filename healthcontroller64.exe in a folder made to resemble a Chrome component unpacker directory on one machine, and as svchelper.exe in a VMware folder on the other. In both cases, the backdoor appears to have run as a service.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 (C&C) server. It was configured with a primary C&C server and a fallback, which are both accessed via port 443. The presence of this backdoor is notable as custom backdoors remain relatively uncommon in ransomware attacks. Ransomware attackers generally rely on publicly available, dual-use and living-off-the-land tools to carry out the majority of pre-ransomware activity in their attacks. This backdoor was also spotted on the networks of two other unrelated organizations, though in those cases no ransomware activity was identified on the networks. Security evasion toolsA notable aspect of this attack was that the threat actors dropped at least 13 executables in quick succession, for the purpose of terminating security products. They clearly favored the Bring Your Own Vulnerable Driver (BYOVD) approach, as demonstrated by their dropping of five signed but vulnerable drivers for the purpose of abusing them to gain kernel-level access. Two of the executables, gbbsym.exe and symgooq.exe, masqueraded as Symantec software. Both accepted the switch (-l) to list kernel callbacks through a loaded vulnerable driver and a second switch (-d) to list and remove them. The observed command lines show the second switch (-d) was used. Eleven of the 13 executables appear to have been previously unpublished. The vulnerable drivers were all publicly known.All the dropped executables were blocked except huntreagent.exe and s1.exe. These files were not available for analysis so their exact purpose is unknown, but it is possible they may have been used to run one or more of the vulnerable drivers. Both tools are the same file size but with different file hashes, which suggests they may be two builds of the same tool. The pattern of using so many different tools is consistent with attackers trying one tool after another until they find something that works.The attackers’ heavy reliance on BYOVD serves to highlight how the technique has become a standard part of the ransomware playbook, a trend we discussed in-depth in our June 2026 whitepaper: Lights Out: Defense Evasion in the Age of BYOVD.BYOVD is commonly used to gain kernel-level access because it is effective and relies on using legitimate, signed files, the presence of which are unlikely to raise red flags. Once operating in the kernel, attackers can use them to help stop security software and prevent their activities from being detected. There are hundreds of known vulnerable drivers already in circulation and newly discovered ones are shared openly on a regular basis. Ready-made BYOVD tooling is now routinely bundled into RaaS offerings alongside the payloads themselves, making it a standard way to disable security software during ransomware attacks. Remote access and Safe ModeThe attackers also installed the legitimate remote access tool AnyDesk, created a new local user account and added it to a local group. AnyDesk is frequently used by ransomware attackers for remote access. However, in this attack, the threat actors also ran a tool, safemode.exe, that configures AnyDesk to keep working when Windows boots into Safe Mode. They ran a registry command that registered AnyDesk as a service permitted to run in Safe Mode with Networking."CSIDL_SYSTEM\reg.exe" add HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\AnyDesk /ve /t REG_SZ /d Service /fSecurity software generally does not fully operate in Safe Mode, which gives attackers a window to use the vulnerable drivers and switch off protections. This isn’t a new technique but it is not commonly seen. Ransomware payloadThe Anubis encryption payload was named iservice.exe. If successful, it appends the extension .anubis to encrypted files and drops ransom notes named restore files.txt and restore files.html. The note tells the victim that data was downloaded from the network and that it will be published if negotiations fail. The ransomware also has an optional wiper mode that wipes file contents, leaving files completely empty. In this attack, the payload was blocked, preventing the attackers from executing the encryption phase across the victim network.SignificanceAttackers using the Anubis ransomware appear to focus their attacks on the U.S., and this intrusion fits with established patterns of behavior by the group. This targeting isn’t surprising given that ransomware attackers generally “follow the money” and a majority of large enterprises have a presence in the U.S.While the overall modus operandi of the attackers is familiar, the presence of a custom backdoor and usage of large numbers of security-disabling tools makes this attack stand out from typical ransomware intrusions. Few ransomware operators build their own backdoors, and the volume of security-disabling tools used within a single hour of activity is unusual. This suggests that the attackers were prepared for the prospect of security software getting in their way, so they arrived with a large toolbox and a second remote access route configured for Safe Mode operation to help them gain an advantage. Despite all this preparation, the attack appears to have largely failed at the last hurdle because the encryption modules were successfully blocked from execution.ProtectionIf an IOC is malicious and the file is available to us, Symantec Endpoint products will detect and block that file.Indicators of CompromiseFile indicatorsfc200686175559f4544a5de826905f09a68476d889690a3be40ac32356790cb8 – healthcontroller64.exe, svchelper.exe (Backdoor.Lindnor)5d2dd9caf2ae4a5083dbec16e688040456cdbc31eaeecbab78188e322ed0415b – powerhost.exe, eventwatcher.exe (Backdoor.Lindnor)ad9575a9ef2dcc9d2fd2a24376c418549d4b3db5564c22b20081d33cf7629e43 – volumeproxy.exe (Backdoor.Lindnor)e69b882218fa2a19fd351741874bfcd10a6ae91076e6a8483795e0e357f8d026 – iservice.exe (Anubis ransomware)467d1395b61d4b886329571b564fb21db01639acd2799439646c85b9aeaec175 – anydesk.exe47a864736764112d7897c76e56d51111ce75b3e46fdbac6933df8a5b29507d17 – safemode.exe6543ee9f89d80b2bcf08e98fb8e9e73a4b144a93c7b2a3f28e35de8f7e7a8a80 – bdr.exe83eff3e51b69968a4ddd503b0b1dccfa8829d638f2dc00cc69640a29aea814f1 – hwaudioch.exef8d4142a94269b4258f370ef2292d22a49cd6dee8266a7122f4531e9cc5d9a2f – gibformin.execd1e68583b8b984a9bb5b9f7067077c0e0d8f79da4455c326319e5e5fc6e9c5f – test.exe5a2082162852984ffe7e7c501faa6cf473129fcba29406ffb98d55198de4b3a5 – xs.scr5fcd2c954764ac0888c8ba72fc1cf54db64e8f23f83aeb0786ae5b80438ba926 – gibfor.exeaa779d811e00a30dfb56b994bdd63424cbf97617af737a218b6aff9f7c3a50f5 – gbbsym.exe854c3e76beb200243ccf6af260e9a2089c2fc545f8f1b34d34c6fe86f2d056c3 – symgooq.exe67dee1d52189460b88f8ce5ffa76a5c22f86ffd67f8e689118019fce0863c321 – g.execde8dbeaf15250337a03e07a7e257b12b03e5e951885cc69a578545f44425bdd – backup.exe28357d9666a9be36b2ea9ac6007bb8bfbe7e2438e095c1ec40720c4001f47c62 – rustr.exe588887e709459f1d1a8109b089cb3462c6f796d30b6297a1a0fdb3419a3ccbce – huntreagent.exe962be6983f3ed4f1dc4ce117e135cc0a5ab8fc6b5f5aa0284eff8a9def66e338 – s1.exe5abe477517f51d81061d2e69a9adebdcda80d36667d0afabe103fda4802d33db – havoc.sys72d0b5615b996cbb01b1ca139e627079094f734da48a0435ffd8480a25d0a258 – monprocessex.syse727d0753d2cd0b2f6eeba4cea53aa10b3ff3ed2afeb78f545fcf6d840f85c3e – xhunter1.sys9058388d05d984ca691a23ee70fcdbd3266c5cdc68ebc5aed95c67f1c502bc75 – bdapiutil64.sys2fdfdd13a0c548bb68c9d5aa8599a9265d4659da3e237fe7a42ac6ac06b9a06a – fly.sys Network IOCsmsrcontrib[.]comcfgsync-relay.eastus.cloudapp.azure[.]com
Click Here For The Original Source.
——————————————————–
