Anubis ransomware operators placed a custom backdoor on database servers, brought a collection of tools to disable security software, and prepared remote access for Safe Mode.
Published on November 5, the technical disclosure describes several distinct operations before that failure. Lindnor supplied an initial visible foothold, vulnerable drivers offered a route into the Windows kernel, and a legitimate remote service provided another access option. Together, those steps explain extensive preparation for ransomware without establishing how the attackers originally entered the network.
Lindnor Appears On Two Database Servers
The first identified sign of compromise was Lindnor on two Microsoft SQL Server machines. They were also the only SQL Server systems among the affected hosts. Nevertheless, that placement does not identify a database vulnerability or prove that SQL authentication supplied initial access.
On one machine, the implant occupied a directory resembling a browser component folder. The other copy sat in a virtualization software directory. Both appear to have run as Windows services, giving the malicious programs an execution context separate from an ordinary desktop application.
Windows manages services through the Service Control Manager, which maintains installed-service records and handles start, stop and status requests. A service can start at boot or on demand, depending on its configuration. Consequently, finding a service establishes a managed execution route, while its particular startup settings determine whether it automatically returns after a restart.
Host Details Connect The Implant To Its Controller
Lindnor sent its process identifier, operating-system version, executable location, computer name, user name, domain and logon server to its command infrastructure. These fields describe both the running implant and the Windows environment around it.
For example, the computer and domain values distinguish a host from similarly named systems elsewhere. Meanwhile, the process identifier and file location tie that host information to a particular running copy. The collected details therefore give the operator a structured identification of the compromised system.
For command traffic, the backdoor contained primary and fallback server addresses, both using port 443. A second destination offers an alternative if the preferred server becomes unavailable. However, a port number alone does not establish encryption, a particular application protocol or successful communication with both destinations.
Vulnerable Drivers Target The Kernel Boundary
Within roughly one hour, the attackers dropped at least 13 executables intended to terminate security products, alongside five signed but vulnerable drivers. This is Bring Your Own Vulnerable Driver, or BYOVD. The attacker supplies the exploitable component instead of depending on a driver already present on the host.
Ordinary applications execute in user mode, where Windows separates their address spaces from protected operating-system memory. In contrast, kernel-mode drivers share an address space with core system components. A flaw in a loaded driver can therefore expose operations unavailable to an ordinary application.
Nevertheless, signed drivers can still contain exploitable flaws. Windows driver policy evaluates whether a driver may load; a vulnerability concerns what that driver allows once running. Microsoft’s vulnerable-driver blocklist addresses this separate risk by identifying drivers with known weaknesses or dangerous behavior. The incident report does not establish the affected machines’ blocklist settings.
Windows also checks service-management permissions. Creating a service through the normal management interface requires administrative privileges, while starting or changing an existing service requires its relevant access rights. Thus, placing a driver file on disk and successfully loading it are separate steps.
Callback Removal Attacks A Source Of Visibility
Two of the tools offered operations to enumerate and remove kernel callbacks through a vulnerable driver. Observed command lines selected the removal operation. That records an attempted interference with monitoring, rather than proving that every targeted callback disappeared.
Callbacks let operating-system components notify registered code about events. For example, PsSetCreateProcessNotifyRoutineEx registers a routine that receives process-creation and exit notifications. A monitoring driver can use such notifications to track process activity across the system. Removing a relevant callback can therefore cut off that particular notification path.
Existing protection blocked most of the dropped executables. Two exceptions were unavailable for analysis, leaving their exact purpose unresolved. Their equal sizes and different hashes suggest possible variants, but do not establish identical behavior. Meanwhile, the rapid sequence of alternatives is consistent with repeated attempts to find a working route through the existing protections.
Remote Access Is Prepared For Safe Mode
The attackers separately installed a legitimate remote-access application, created a local account and added it to a local group. They also changed the registry to permit the remote service under Safe Mode with Networking.
Safe Mode starts Windows with a limited set of drivers and services. The networking variant adds components needed to reach other computers and the internet. As a result, a prepared remote service can preserve connectivity while Windows starts fewer components.
Here, the registry change identified the remote application’s service beneath SafeBoot\Network and set its default string data to Service. This changed its eligibility to run in that startup mode. It did not, by itself, demonstrate a reboot or a completed remote session after one.
The arrangement gave the operators a second access route alongside their custom implant. Because security software may operate differently or incompletely in Safe Mode, the configuration also supported their broader attempt to reduce interference before deploying ransomware.
The Encryption Payload Stops At Execution
Execution controls stopped the final Anubis payload before encryption began. Anubis also supports an optional mode that empties file contents, but the disclosed case does not establish execution of that wiping function. Similarly, a ransom note’s claim of downloaded data is not independent evidence of theft from this organization.
We demonstrated Xcitium stopping Anubis samples from encrypting files in our Anubis ransomware case study. In that test, the platform restricted unknown ransomware processes before they could alter real data. This shows why control at execution matters before a payload reaches its destructive phase. Here, the operators tried to weaken monitoring and preserve access before launching that final payload.
Conclusion: The Attack Targeted Protection Before Encryption
The Anubis operators tried to change the conditions under which their ransomware would run. A custom backdoor established a visible foothold, while vulnerable-driver tools targeted monitoring callbacks. Separately, a remote service received permission to run in Safe Mode with Networking. These steps sought to preserve attacker access while reducing interference from security software.
Blocking the encryption payload prevented that stage of the attack. However, the earlier backdoor and unauthorized configuration changes still require investigation. The operational question extends beyond whether files remain readable. It includes which programs hold execution authority, which services can return, and whether monitoring still reports the activity it should.
Why This Threat Matters
- Preparation preceded impact. The attackers attempted to weaken protection before the final payload could encrypt files.
- Signed drivers carried risk. Legitimate signatures accompanied vulnerable components intended to provide access to protected kernel operations.
- Alternative tools extended the attempt. A rapid sequence of security-disabling executables showed repeated efforts to find a working route.
- Recovery settings affected access. Safe Mode service registration prepared remote connectivity in an environment with fewer running components.
- A blocked payload left earlier compromise to resolve. The backdoor, new account and service changes remain relevant even without completed encryption.
Where Defensive Control Must Operate
Control must begin when an unfamiliar executable seeks authority on the host, before it can interfere with protection. Restrict service creation and driver loading to approved administrative workflows. Meanwhile, review remote-support deployments against their authorized purpose and access scope, including changes to startup behavior.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, provides behavioral visibility, forensic evidence and response on supported, managed Windows endpoints. Execution Governance restricts unknown executable activity under endpoint policy before it gains access to real resources. Process telemetry supports investigation of the relationship between backdoor execution, suspicious system changes and subsequent payload activity. That evidence helps establish the sequence across programs whose names or signatures may appear familiar.
Remove The Access Paths Before Restoring Service
Isolate affected systems and preserve volatile evidence before rebooting or rebuilding them. Then examine service records, driver activity, local account creation, remote-access settings and SafeBoot changes as one intrusion timeline. Remove unauthorized access and restore approved configurations through a controlled recovery process. Where credential exposure is possible, assess the relevant accounts and replace affected secrets from a trusted system.
Before reconnecting a recovered server, verify its approved service configuration, active protection settings and the arrival of expected telemetry. Document the authorization for any retained remote-support service. Recovery should establish that the system’s access and monitoring controls work again, alongside confirming the state of its files.
