SprySOCKS reaches Windows: a backdoor that lifts the sigil with kernel drivers, DLL sid-loading and a possible firmware bootkit

Author: Published 4 min de lectura 228 reading

The images in this article were generated with artificial intelligence. How we publish

The recent detection by researchers of a Windows variant of SprySOCKS - a backdoor that until recently was considered unique to Linux - marks a significant leap in the operational capacity of cyber-espionage actors who already showed transplatform ambition. The finding of internal versions WIN _ DRV and WIN _ PLUS reveals not only portability of the code but an evolution: integration of kernel controllers and side loading techniques (DLL side-loading) to hide presence and communications.

In technical terms, Windows samples maintain the same command and control protocol, encryption and set of commands as the Linux version, but do so by taking advantage of native Windows mechanisms. WIN _ DRV loads a kernel driver (identified in the analysis as RawWNPF and deployed by an encrypted load driver) that allows you to camouflage network connections, processes and log entries, and also deploy a TCP traffic diversion technique to hide your real listening port. WIN _ PLUS, for its part, abuses the Print Spooler service to run a first charger that acts as a printing processor and finally injects the backdoor into svchost.ex.

SprySOCKS reaches Windows: a backdoor that lifts the sigil with kernel drivers, DLL sid-loading and a possible firmware bootkit
Image generated with IA.

These details are not anecdotal: the combination of kernel drivers, side-loading and abuse of legitimate services complicates traditional detection and requires safety controls at multiple levels. The use of drivers allows operators to significantly raise their stealth against user monitoring tools, and the dependence on scheduled tasks and legitimate load chains attacks the blind areas of many corporate architectures.

The operational context is also relevant. SprySOCKS has been related to a cluster linked to groups with Chinese links, and shows genealogy with families such as Trochilus and RedLeaves, indicating reuse of code and tradecraft shared between campaigns. Historically these actors have exploited N-day vulnerabilities in exposed services (Fortinet, Microsoft Exchange, GitLab, Telerik, Zimbra), so the presence of a Windows variant increases the risk for critical infrastructure and public agencies in multiple geographies.

In addition, there are limited signs of UEFI bootkit use probably taking advantage of the vulnerability known as CVE-2023-24932, which increases gravity: a firmware level commitment can survive reinitiations and many mitigation at operating system level. For technical details on this vulnerability see the official Microsoft guide: https: / / msrc.microsoft.com / update-guide / vulnerability / CVE-2023-24932. For a general monitoring of research and the historical context of SprySOCKS and related campaigns, readers can review firm resources and industry analysis on the intelligence sites of suppliers such as ESET: https: / / www.welivesecurity.com /.

What should security teams do right now? First, prioritizing patches and mitigations for known public access vectors; many previous intrusions exploited corrected vulnerabilities long ago. If your organization exposes services such as Fortinet, Exchange, GitLab, Telerik or Zimbra, check patches, access records and N-day operating alerts. Second, tighten controls on endpoints: disable Print Spooler on servers that do not require it, apply side-loading blocking policies (e.g. via AppLocker or Windows Defender Application Control), and require signed code and integrity checks for kernel drivers.

SprySOCKS reaches Windows: a backdoor that lifts the sigil with kernel drivers, DLL sid-loading and a possible firmware bootkit
Image generated with IA.

The detection should combine network and endpoint telemetry. Look for unusual connections on TCP / UDP and WebSocket, traffic peaks redirected to random ports, loads and DLL executions from atypical routes, presence of programmed tasks that launch load chains, and the appearance of drivers with suspicious names or hashes. EDR solutions with kernel instrumentation capacity are especially useful for identifying hidden drivers and holes in kernel space. In environments where there is suspicion of persistent commitment, consider the validation of the firmware and the state of Secure Boot, and the reconstruction of hosts if a bootkit is confirmed.

In response to incidents, isolate affected systems, capture memory and disk dumping for forensic analysis and look for laterality indicators: account creation, RDP / SMB movements, exfiltered credentials and remote administration tools if they appear. Notify internal response teams and relevant authorities or CERTs, and coordinate IoC exchange with the community to block known domains and hashes.

Finally, this reinforces a persistent lesson: the re-use of code between platforms and the adaptation of advanced techniques (drivers, UEFI, side-rolling) transform problems that seemed limited to an ecosystem at large-surface risks. Modern defense requires cross-track vision, with timely parking, restrictive implementation policies, centralized telemetry and regular firmware and driver integrity tests.

Coverage

Related

More news on the same subject.