SprySOCKS chega ao Windows: um backdoor que eleva o sigilo com drivers de kernel, DLL side-loading e um possível bootkit de firmware

A recente detecção por parte de pesquisadores de uma variante para Windows de SprySOCKS — um backdoor que até recentemente era considerado exclusivo do Linux — marca um salto significativo na capacidade operacional de atores de ciber-espionagem que já mostravam ambição transplataforma. O achado das versões internas WIN_DRV e WIN_PLUS revela não apenas portabilidade do código, mas uma evolução: integração de controladores de kernel e técnicas de carga lateral (DLL side-loading) para ocultar presença e comunicações.

No técnico, as amostras do Windows mantêm o mesmo protocolo de comando e controle, criptografia e conjunto de comandos que a versão Linux, mas o fazem aproveitando mecanismos nativos do Windows. WIN_DRV carrega um driver do kernel (identificado nas análises como RawWNPF e implantado por um driver de carga criptografado) que lhe permite camuflar conexões de rede, processos e entradas de registro, além de implantar uma técnica de desvio de tráfego TCP para ocultar seu porto de escuta real. WIN_PLUS, por sua vez, abusa do serviço Print Spooler para executar um primeiro carregador que atua como processador de impressão e finalmente injeta o backdoor em svchost.exe.

Estes detalhes não são anecdóticos: a combinação de drivers kernel, side-loading e abuso de serviços legítimos complica a detecção tradicional e exige controles de segurança a múltiplos níveis. O uso de drivers permite aos operadores elevar significativamente seu sigilo frente a ferramentas de monitoramento de usuário, e a dependência de tarefas programadas e cadeias de carga legítimas ataca as áreas cegas de muitas arquiteturas corporativas.

O contexto operacional também é relevante. SprySOCKS tem sido relacionado com um cluster ligado a grupos com ligações chinesas, e mostra genealogia com famílias como Trochilus e RedLeaves, o que indica reutilização de código e tradecraft compartilhado entre campanhas. Historicamente, estes atores têm explorado vulnerabilidades N‐day em serviços expostos (Fortinet, Microsoft Exchange, GitLab, Telerik, Zimbra), pelo que a presença de uma variante Windows aumenta o risco para infraestruturas críticas e organismos públicos em múltiplas geografias.

Além disso, há indícios limitados de utilização de uma UEFI bootkit provavelmente aproveitando a vulnerabilidade conhecida como CVE-2023-24932, o que eleva a gravidade: um compromisso a nível do firmware pode sobreviver a reinícios e muitas mitigações a nível do sistema operacional. Para detalhes técnicos sobre essa vulnerabilidade consulte o guia oficial da Microsoft: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-24932. Para um acompanhamento geral da pesquisa e do contexto histórico de SprySOCKS e campanhas relacionadas, os leitores podem revisar recursos de assinaturas e análise da indústria nos sites de inteligência de fornecedores como o ESET: https://www.welivesecurity.com/.

O que devem fazer as equipes de segurança agora mesmo? Em primeiro lugar, priorizar adesivos e mitigações para vetores de acesso público conhecidos; muitas intrusões prévias exploraram vulnerabilidades corrigidas tempo atrás. Se a sua organização expõe serviços como Fortinet, Exchange, GitLab, Telerik ou Zimbra, verifique adesivos, registros de acesso e alertas de exploração N‐day. Em segundo lugar, endurecer controles em endpoints: desativar Print Spooler em servidores que não o exijam, aplicar políticas de bloqueio de side-loading (por exemplo, através do AppLocker ou Windows Defender Application Control), e exigir código assinado e verificações de integridade para drivers de kernel.

A detecção deve combinar telemetria de rede e endpoint. Procure conexões invulgares sobre TCP/UDP e WebSocket, picos de tráfego redireccionado a portos aleatórios, cargas e execuções de DLL desde rotas atípicas, presença de tarefas programadas que lancem cadeias de carga, e a aparição de drivers com nomes ou hashes suspeitos. As soluções EDR com capacidade de instrumentação de kernel são especialmente úteis para identificar drivers ocultos e hooks em espaço de kernel. Em ambientes onde houver suspeita de compromisso persistente, considere a validação do firmware e o estado do Secure Boot, e a reconstrução de hosts se um bootkit for confirmado.

Em resposta a incidentes, isole os sistemas afetados, capture memória e voltado de disco para análise forense e procure indicadores de lateralidade: criação de contas, movimentos por RDP/SMB, credenciais exfiltradas e ferramentas de administração remota se aparecerem. Notifique equipamentos internos de resposta e autoridades ou CERTs correspondentes, e coordene intercâmbio de IoC com a comunidade para bloquear domínios e hashes conhecidos.

Finalmente, isso reforça uma lição persistente: a reutilização de código entre plataformas e a adaptação de técnicas avançadas (drivers, UEFI, side-loading) transformam problemas que pareciam limitados a um ecossistema em riscos de ampla superfície. A defesa moderna requer visão cross-stack, com adesivo adequado, políticas de execução restritivas, telemetria centralizada e testes regulares de integridade de firmware e drivers.