A Linux backdoor moved into the Windows kernel, and the detection window closes at driver load

Once a rootkit maps into the Windows kernel, the machine stops telling you the truth. Process lists, netstat output, directory listings, and registry queries all run through code the attacker now controls. That is the real lesson in the SprySOCKS disclosure ESET published on June 16, 2026, and it changes where you have to look. The detection window for this malware is the few seconds around driver load and persistence write. After that, you are asking a compromised host to incriminate itself.

SprySOCKS is not new. It surfaced in 2023 as a Linux-only backdoor tied to the China-nexus group ESET tracks as FishMonger, also known as Earth Lusca, Aquatic Panda, and TAG-22. What is new is that it crossed platforms. ESET found two Windows builds, internally versioned 1.8, used against government targets in Honduras, Taiwan, Thailand, and Pakistan during 2023 and 2024. The reporting was confirmed independently by BleepingComputer and Dark Reading.

Two variants, one of which is the problem

The split matters for triage. WIN_PLUS is the plain build with no kernel component. It still does the backdoor work, but it lives in user space where normal endpoint telemetry can see it. ESET found it through its print-processor persistence.

WIN_DRV is the one that should worry you. It carries a kernel driver chain that turns the host into an unreliable witness. A loader (tpsvcloc.dll) injects the backdoor using process doppelganging. A second-stage driver (fsdiskbit.sys, a minifilter) decrypts and manually maps a rootkit named RawWNPF directly into memory. From there the rootkit hides the malware's processes, network connections, files, and registry keys from anything that asks the operating system.

Why the kernel driver defeats your usual checks

RawWNPF does not just hide a file. It hooks the calls defenders rely on. It tampers with NtQuerySystemInformation to strip its process IDs from results. It hooks the network stack to filter its own ports and addresses out of connection tables. It uses minifilter callbacks to drop its files from directory listings and a registry callback to mask its keys. Each of those is a primitive a defender normally trusts.

The cleverest piece is the network trick. WIN_DRV registers Windows Filtering Platform filters and watches every open port for a magic value. When it sees the right marker, it silently diverts that TCP traffic to the backdoor's hidden listener. The backdoor never opens a visible port of its own. So a host port scan finds nothing, and the obvious detection (a strange listening service) never appears. This is the detail that pushes your visibility off the box: if the host cannot show you the connection, network flow analysis from a tap or your egress layer becomes the place you actually catch it.

A leaked 2012 certificate is doing the heavy lifting

The driver is signed with a certificate leaked from the PastDSE GitHub project, and that certificate expired in 2012. It works anyway, but only on systems where Driver Signature Enforcement is off or misconfigured. That reframes the threat. This is partly a malware story and partly a fleet hygiene problem. If your Windows servers run with DSE disabled or without Hypervisor-protected Code Integrity, you have left the front door open for any driver signed with a junk certificate, not just this one. Auditing the DSE and HVCI state across your estate is a control that costs little and that almost nobody checks until after an incident.

Where you can still see it

The trick is to catch the activity before RawWNPF is resident, or in the places the rootkit does not cover. Three of these are worth building detections around tonight.

• Persistence writes, at creation time. WIN_DRV creates a scheduled task named ApphostRagistreationVerifier that runs as SYSTEM at boot, with a backup that hijacks vds.exe by registering it under an IFEO (Image File Execution Options) debugger key. WIN_PLUS registers a print processor at HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\VSPMsg. The rootkit hides these keys after the fact, but the write event itself fires before the driver is masking anything. Alert on the creation, not the steady state.
• Boring admin surfaces nobody baselines. Print processors and IFEO debugger keys are legitimate Windows features, which is exactly why they are good hiding spots. Most teams have no baseline of what should live there. Building one is a cheap, high-signal win that pays off well beyond this actor.
• DLL side-loading and odd file paths. The loader rides a legitimate ThinPrint executable that loads the malicious tpsvcloc.dll. ESET listed artifacts in unusual locations such as %SystemRoot%\Fonts\ and C:\Windows\System32\spool\drivers\color\config.dat, plus the driver at C:\Windows\System32\drivers\fsdiskbit.sys. File integrity monitoring on those directories catches the drop before the rootkit can hide it.

For the network side, do not rely on the host. Pull flow data from your egress point and look for the C2 pattern ESET documented: TCP on 443, UDP on 53, and WebSocket on 80, with the C2 address 207.148.78[.]36 sitting in the same Vultr range used for delivery back in 2023. Traffic that the host swears does not exist, but your tap sees, is the tell.

What to actually do this week

Start by accepting the core constraint: a host running a kernel rootkit cannot audit itself. That is why host-based detection works best when it watches the events that precede compromise, the driver loads and the persistence writes, rather than querying state after the fact. It is also why an independent view, whether a network tap or boot-integrity attestation, earns its place in the stack. We have written before about why host telemetry is the foundation we build on and about how stealthy state-backed actors hide in plain sight in the Velvet Ant authentication-stack case.

Concretely: audit Driver Signature Enforcement and HVCI on every Windows server, treat any driver signed with an expired or out-of-band certificate as suspect, baseline your print processors and IFEO keys so a new entry is loud, and move your trust for network visibility off the endpoint. None of this is exotic. It is the difference between catching FishMonger at the doorway and finding out a year later, the way the victims here did.