Arsenal do FishMonger atualizado: SprySOCKS para Windows

A equipe de pesquisa da ESET identificou duas variantes para Windows até então não documentadas do SprySOCKS, um backdoor anteriormente exclusivo para Linux que, segundo relatos, é utilizado pelo FishMonger, grupo que se acredita ser operado por uma empresa contratada pelo governo chinês chamada I SOON. Embora tenhamos descoberto inicialmente as amostras de malware no VirusTotal, a telemetria da ESET mostra atividade real entre 2023 e 2024, com diversas vítimas em Honduras, Taiwan, Tailândia e Paquistão, tendo como alvo principalmente organizações governamentais.

As variantes para Windows descobertas são identificadas internamente como WIN_DRV e WIN_PLUS. Ambas incluem uma configuração de C&C (comando e controle) embutida no código e oferecem suporte à comunicação por meio dos protocolos TCP, UDP e WebSocket. A funcionalidade principal do backdoor em ambas as versões inclui suporte a mais de 30 comandos de C&C, abrangendo diversas capacidades, como coleta de informações do sistema, enumeração de processos, gerenciamento de serviços e operações de gerenciamento de arquivos, como listar, criar, excluir e transferir arquivos.

Além da funcionalidade principal do backdoor, a versão WIN_DRV utiliza drivers de kernel para ocultar conexões de rede, processos, arquivos e chaves de registro do malware, além de permitir o redirecionamento de tráfego TCP. Esse recurso possibilita que os operadores do malware enviem comandos ao backdoor por meio de uma porta TCP aleatória no dispositivo da vítima, sem expor a porta real utilizada pelo backdoor para escuta dentro do tráfego de rede.

De acordo com a telemetria da ESET, há indícios limitados de que alguns cenários de ataque envolvendo o SprySOCKS possam incluir um componente do tipo bootkit UEFI, possivelmente explorando a vulnerabilidade CVE-2023-24932.

A análise apresentada neste relatório nos leva a atribuir essas novas variantes para Windows ao FishMonger com alto grau de confiança.

Pontos-chave desta publicação

• Descobrimos duas variantes do backdoor SprySOCKS do FishMonger para Windows, até então não documentadas.
• A telemetria da ESET mostra atividade entre 2023 e 2024, tendo como alvo principalmente organizações governamentais em Honduras, Taiwan, Tailândia e Paquistão.
• Ambas as variantes para Windows oferecem suporte à comunicação por meio dos protocolos TCP, UDP e WebSocket, e implementam mais de 30 comandos.
• A variante WIN_DRV cria um backdoor TCP passivo e furtivo, apoiando-se em um driver de kernel para redirecionar o tráfego para a porta TCP oculta do backdoor quando dados especialmente projetados são detectados dentro de um pacote TCP recebido.

Perfil do FishMonger

O FishMonger, que se acredita ser operado por um contratado chinês chamado I SOON (veja nosso Q4 2023–Q1 2024 APT Activity Reportv), é um grupo de ciberespionagem que faz parte do guarda-chuva do Winnti Group e que muito provavelmente opera a partir da China, especificamente da cidade de Chengdu. Também é conhecido como Earth Lusca, TAG-22, Aquatic Panda ou Red Dev 10. Publicamos uma análise do FishMonger no início de 2020, quando o grupo tinha como alvo principal universidades em Hong Kong durante os protestos civis iniciados em junho de 2019. O grupo também é conhecido por realizar ataques do tipo watering hole, conforme relatado pela Trend Micro. O conjunto de ferramentas do FishMonger inclui ShadowPad, Spyder, Cobalt Strike, FunnySwitch, SprySOCKS e o BIOPASS RAT.

Análise técnica

Nesta seção, apresentamos uma análise técnica dessas novas variantes para Windows do backdoor SprySOCKS do FishMonger.

O arquivo que levou a essa descoberta foi carregado no VirusTotal em abril de 2024 com o nome klelam00007.zip; seu conteúdo é mostrado na Figura 1.

Esse arquivo contém diversos componentes, incluindo alguns arquivos legítimos utilizados para hospedar ataques de DLL side-loading, além de três arquivos criptografados com a extensão .dat que despertaram suspeitas. Nossa análise posterior revelou que esses arquivos criptografados contêm uma nova variante para Windows do backdoor SprySOCKS do FishMonger, até então não documentada, identificada por seus desenvolvedores como WIN_DRV. Investigações adicionais também revelaram outra versão do backdoor, denominada WIN_PLUS, na telemetria da ESET.

Acesso inicial

O FishMonger é conhecido por ter como alvo servidores expostos à internet (public-facing servers) de suas vítimas, explorando com frequência vulnerabilidades N-day baseadas em servidor para obter acesso inicial. Embora não tenhamos conseguido confirmar o método exato utilizado pelo FishMonger para comprometer os sistemas das vítimas nesta campanha, a presença de sistemas operacionais de servidor em alguns dos dispositivos afetados, juntamente com o modus operandi característico do grupo, sugere que os invasores possam ter obtido acesso por meio de aplicações expostas à internet configuradas incorretamente ou sem as correções de segurança necessárias.

SprySOCKS para Windows

Em setembro de 2023, a Trend Micro publicou um relatório sobre um novo backdoor para Linux do FishMonger, que seus analistas denominaram SprySOCKS. O código desse backdoor é baseado em um remote access trojan (RAT) de código aberto para Windows chamado Trochilus e compartilha diversas características com o backdoor RedLeaves. No entanto, ele foi expandido e modificado a ponto de ser considerado um novo backdoor. Neste relatório, analisamos duas variantes para Windows da versão 1.8 do SprySOCKS que ainda não haviam sido divulgadas:

• Uma delas, denominada WIN_DRV por seus desenvolvedores, utiliza um driver de kernel para alcançar um nível mais elevado de furtividade.
• A outra, sem o driver, é denominada WIN_PLUS.

Como mostrado na Figura 2, o tipo e o número da versão do backdoor estão codificados de forma fixa (hardcoded) no binário.

A grande maioria dos artefatos e funcionalidades presentes na versão Linux do backdoor SprySOCKS apresentada no relatório da Trend Micro também está presente nas novas variantes para Windows descritas neste relatório. Entre elas estão:

• O mesmo formato de mensagens de C&C;
• Comandos de C&C muito semelhantes, além de alguns adicionais;
• As mesmas chaves e algoritmos de criptografia; 
• O uso da mesma biblioteca de rede vinculada estaticamente (statically linked networking library), HP-Socket.

Para ambas as novas variantes do SprySOCKS, a funcionalidade principal do backdoor relacionada à comunicação com o servidor de C&C e aos comandos disponíveis é muito semelhante. As diferenças mais notáveis estão na forma como o backdoor final é carregado, nos aprimoramentos de furtividade (stealthiness) e nos nomes e caminhos dos componentes utilizados.

Nas subseções a seguir, analisamos primeiro os componentes envolvidos na cadeia de execução (execution chain) de cada variante do SprySOCKS e, em seguida, descrevemos o componente do backdoor, que é praticamente o mesmo em ambas as variantes.

Componentes do WIN_DRV

Em um arquivo carregado no VirusTotal, descobrimos a versão WIN_DRV do SprySOCKS, que inclui uma configuração de C&C vazia. Como resultado, essa versão não entra em contato ativamente com endereços remotos; no entanto, continua sendo capaz de iniciar um servidor TCP em uma porta aleatória no dispositivo da vítima, atuando assim como um backdoor passivo. Curiosamente, os invasores não precisam conhecer o número da porta TCP desse servidor, pois, conforme explicado mais adiante, o driver RawWNPF utilizado pela versão WIN_DRV permite o desvio silencioso (silent diversion) do tráfego TCP recebido em qualquer porta aberta diretamente para o backdoor (mais detalhes na seção sobre o driver RawWNPF).

Como mostrado na Figura 1, o arquivo que contém a versão WIN_DRV do SprySOCKS inclui vários componentes:

• klelam00007.bat: um script em lote responsável pela persistência do backdoor que, conforme mostrado na Figura 3:
  • copia todos os arquivos do diretório de trabalho atual para o diretório SystemRoot%\Fonts (para funcionar corretamente, o arquivo em lote deve ser implantado no mesmo diretório que os demais arquivos do arquivo compactado);
  • cria uma tarefa agendada denominada ApphostRagistreationVerifier, configurada para executar ApphostRagistreationVerifier.exe (um executável legítimo, devidamente assinado, renomeado pelos invasores para imitar o AppHostRegistrationVerifier.exe assinado pela Microsoft) com privilégios NT AUTHORITY\SYSTEM a cada inicialização do sistema. Os invasores utilizam a conhecida técnica de DLL side-loading, explorando a forma como o Windows carrega DLLs para carregar sua própria DLL maliciosa (neste caso, tpsvcloc.dll) por meio de uma aplicação legítima assinada. Mais especificamente, utilizam a técnica de malware sideloading por meio de DLL satélite do MFC (observe a cadeia de caracteres «loc» no nome do arquivo tpsvcloc.dll ).
• ApphostRagistreationVerifier.exe: executável legítimo e assinado do serviço de criação de impressoras AutoConnect da ThinPrint (SHA-1: FFC3AA7909D4E72C360D65A1F45260DFFE5C99B7), que carrega a biblioteca tpsvc.dll.
• tpsvc.dll: biblioteca legítima e assinada que carrega a biblioteca tpsvcloc.dll.
• tpsvcloc.dll: carregador (loader) do backdoor SprySOCKS.
• X1B5206BDC1743DD.dat: contêiner criptografado que inclui o backdoor SprySOCKS e cópias dos dois arquivos a seguir.
• KX1B5206BDC1743DD.dat: DriverLoader, um driver de kernel criptografado responsável por carregar outro driver de kernel a partir de KW1B5206BDC1743FP.dat.
• KW1B5206BDC1743FP.dat: RawWNPF, um driver de kernel responsável por ocultar os arquivos e a atividade de rede do backdoor.

A Figura 4 mostra a cadeia de execução da variante WIN_DRV do SprySOCKS.

As três subseções a seguir apresentam análises técnicas dos componentes mencionados anteriormente: o carregador (loader) do SprySOCKS, o driver DriverLoader e o driver RawWNPF.

Loader do SprySOCKS

O loader começa com verificações iniciais para detectar a presença de um ambiente virtual e de alguns produtos de segurança. Ele procura bibliotecas específicas (em particular: snxhk.dll, SxWrapper.dll, SxIn.dll, SXIn64.dll e SbieDll.dll) dentro do processo do loader e encerra sua execução caso encontre qualquer uma delas.

Como etapa seguinte, verifica se a persistência foi configurada corretamente pelo script klelam00007.bat, mostrado na Figura 3. Para isso, verifica se a imagem atual do loader foi carregada a partir do diretório %SystemRoot%\Fonts\ e tenta acessar os arquivos %SystemRoot%\Fonts\X1B5206BDC1743DD.dat, %SystemRoot%\Fonts\tpsvc.dll e %SystemRoot%\Fonts\tpsvcloc.dll. Caso detecte que algum desses arquivos não está no local esperado, ele configura a persistência por conta própria por meio de:

cópia de X1B5206BDC1743DD.dat, tpsvc.dll, tpsvcloc.dll e ApphostRagistreationVerifier.exe do diretório de trabalho atual para o diretório %SystemRoot%\Fonts\;

registro da aplicação %SystemRoot%\Fonts\ApphostRagistreationVerifier.exe como debugger de vds.exe (um serviço de disco virtual que pode ser executado automaticamente na inicialização do sistema), gravando o caminho da aplicação no valor de registro HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vds.exe\debugger; e

criação do arquivo affair-build.bat no diretório %SystemRoot%\Fonts\ e sua posterior execução por meio do cmd.exe. Esse script, mostrado na Figura 5, remove os rastros desse processo apagando os arquivos do diretório de implantação e executando novamente o malware (agora a partir de %SystemRoot%\Fonts\) por meio da reinicialização do serviço vds.

Quando a persistência está estabelecida, o loader continua carregando os payloads a partir de um contêiner criptografado localizado em %SystemRoot%\Fonts\X1B5206BDC1743DD.dat. O algoritmo e a chave de descriptografia são AES de 128 bits no modo ECB, utilizando a chave codificada de forma fixa (hardcoded) uXQLESMXGaRMs6BL.

Isso produz um shellcode gerado pela ferramenta de código aberto DllToShellCode. Antes de executar o shellcode, o loader extrai os demais payloads criptografados do contêiner para arquivos separados:

• %SystemRoot%\Fonts\KX1B5206BDC1743DD.dat
• %SystemRoot%\Fonts\KW1B5206BDC1743FP.dat

Após concluir essa etapa, o loader cria um novo processo svchost.exe utilizando CreateProcessAsUserW com um token obtido de spoolsv.exe e injeta o shellcode do backdoor nesse processo utilizando a técnica de process doppelgänging. Durante o processo de injeção, o shellcode é gravado em um arquivo temporário com o prefixo TH em seu nome, dentro do diretório %TEMP%.

Como etapa final, o loader descriptografa e executa o DriverLoader, um driver de kernel oculto dentro do arquivo previamente implantado KX1B5206BDC1743DD.dat. O DriverLoader é primeiro descriptografado e, em seguida, seu conteúdo é salvo em C:\Windows\System32\drivers\fsdiskbit.sys.

Para executá-lo, o loader instala esse driver como um minifilter driver, criando manualmente uma nova chave de serviço no Registro chamada msidiskserver, com um valor ImagePath apontando para o driver implantado (como mostrado na Figura 6), e invoca a função da API do Windows NtLoadDrive com essa chave de registro como parâmetro para carregá-lo. Caso nenhum erro seja detectado, o loader remove tanto a chave de registro msidiskserver quanto o arquivo fsdiskbit.sys. Após isso, o loader encerra sua execução.

Driver DriverLoader

Antes de abordar a funcionalidade do DriverLoader, é importante destacar um ponto: com o lançamento do Windows Vista, a Microsoft introduziu a imposição de assinatura de drivers (Driver Signature Enforcement – DSE), um recurso que garante que apenas componentes em modo kernel devidamente assinados possam ser executados no kernel do Windows. Isso significa que, para executar o driver fsdiskbit.sys (DriverLoader), os invasores precisam assiná-lo com um certificado confiável.

Para fazer com que o driver funcione ao menos em alguns sistemas desatualizados ou configurados incorretamente, os invasores utilizaram um certificado vazado (leaked certificate) disponível no GitHub, no repositório do projeto PastDSE, e assinaram o driver fsdiskbit.sys com esse certificado. As informações sobre o certificado utilizado podem ser vistas na Figura 7.

Agora, quanto à funcionalidade. O propósito desse componente é bastante direto: carregar outro driver inteiramente em memória (in-memory). Primeiro, ele lê e descriptografa o conteúdo do arquivo C:\Windows\Fonts\KW1B5206BDC1743FP.dat, previamente criado pelo loader. Para isso, utiliza o mesmo algoritmo e a mesma chave empregados pelo loader: AES de 128 bits em modo ECB com a chave uXQLESMXGaRMs6BL.

Os dados descriptografados contêm um binário PE nativo (descrito na seção do driver RawWNPF), que é então mapeado manualmente (manually mapped) e tem seu ponto de entrada executado.

O binário do DriverLoader contém o seguinte caminho PDB incorporado:

C:\Users\xdd\Desktop\今天\2023-4-11\2023‑04‑10__注册表驱动加载功能__集成到内测3中-未完成\DriverMemoryLoadDriver\x64\Release\DriverMemoryLoadDriver.pdb

As partes em chinês simplificado podem ser traduzidas como:

• 今天: Hoje.
• 注册表驱动加载功能__集成到内测3中-未完成: Função de carregamento de driver via Registro integrada à versão beta interna 3, não concluída.

Como pode ser observado no caminho dos símbolos, esse componente parece estar em desenvolvimento desde, pelo menos, abril de 2023, o que coincide com o timestamp de compilação do DriverLoader. Da mesma forma, as cadeias de caracteres presentes no caminho sugerem que o projeto do qual esse driver faz parte provavelmente ainda estava em desenvolvimento no momento de sua compilação.

Driver RawWNPF

O driver RawWNPF é o componente que torna a variante WIN_DRV do backdoor SprySOCKS significativamente mais furtiva em comparação com a variante WIN_PLUS. Ele permite ocultar a atividade maliciosa do backdoor no sistema comprometido e pode ser configurado por meio da chamada de códigos de controle de E/S personalizados do driver (custom I/O control codes, IOCTLs).

O driver cria um dispositivo chamado \Device\RawWNPF; a lista de IOCTLs disponíveis, juntamente com breves descrições, é apresentada na Tabela 1.

Tabela 1. Lista de IOCTLs gerenciados pelo driver RawWNPF.

Ocultação de processos específicos

O driver RawWNPF pode ser configurado para ocultar processos com base em seus IDs de processo (process IDs), e a lista de processos ocultos pode ser gerenciada por meio da chamada dos IOCTLs do driver 0x220358, 0x22035C, 0x220354 e 0x220350. Para ocultar um processo, o driver intercepta (hooks) a execução da chamada de sistema (system call) NtQuerySystemInformation e modifica sua saída quando são consultadas informações sobre os processos em execução (ou seja, quando SystemProcessInformation é passado no parâmetro SystemInformationClass). Se algum dos processos retornados por essa função da API corresponder a um processo presente na lista de processos ocultos do driver, ele é removido da saída da função. A forma como o driver de kernel implementa o hook sobre a chamada de sistema NtQuerySystemInformation parece ser fortemente baseada no código-fonte do projeto InfinityHookPro.

Ocultação da atividade de rede

O driver pode ser configurado para ocultar conexões ativas específicas (com um IP, uma porta ou uma combinação de ambos definidos), de modo que elas não apareçam na saída de ferramentas comuns de administração de rede, como o netstat.exe. Isso é obtido por meio de uma técnica conhecida (por exemplo, [1], [2], [3], …), na qual os invasores interceptam (hook) a IoCompletionRoutine para o IOCTL 0x12001B  dentro da função DeviceIoControl do driver de kernel do Windows nsiproxy.sys. O código dentro do manipulador do IOCTL 0x12001B no nsiproxy é responsável por recuperar a lista de conexões ativas e, ao interceptar sua IoCompletionRoutine, os invasores podem percorrer a lista obtida, verificar a presença de portas, endereços ou ambos, e ocultar a conexão específica quando encontram uma correspondência.

A Figura 8 mostra a função de hook responsável por ocultar as conexões de rede.

Além de ocultar conexões de rede ativas, o driver inclui uma funcionalidade interessante que permite redirecionar pacotes TCP recebidos em qualquer porta TCP aberta para uma porta TCP específica configurada por meio do IOCTL 0x220200 (que, na prática, corresponde à porta do servidor TCP do backdoor SprySOCKS), mas apenas quando os dados TCP recebidos contêm informações especialmente elaboradas (specially crafted data).

Para realizar isso, o driver registra seus próprios objetos de filtragem de pacotes utilizando funções da API Windows Filtering Platform (WFP), analisa manualmente o conteúdo dos pacotes IPv4 transferidos (tanto o tráfego de entrada quanto o de saída é inspecionado) e redireciona o tráfego caso detecte esses dados especialmente elaborados dentro de um pacote TCP recebido.

O objetivo dessa funcionalidade parece ser principalmente permitir a comunicação com o backdoor malicioso sem a necessidade de incluir um endereço de C&C dentro do binário. Além disso, embora esse tráfego redirecionado possa ser analisado com ferramentas como o Wireshark, a porta real (para a qual o tráfego é redirecionado) não é revelada; portanto, pode ser difícil investigar o destino real desse tráfego malicioso.

Os filtros de pacotes instalados, juntamente com suas informações de identificação, estão listados na Tabela 2.

Tabela 2. Objetos de filtragem WFP registrados pelo driver RawWNPF.

Ocultação dos arquivos do backdoor

O driver oculta/protege os arquivos do backdoor SprySOCKS registrando-se como um minifilter driver e instalando os seguintes callbacks:

• Callback de pré-operação (pre-operation callback), ativado em cada solicitação de E/S IRP_MJ_CREATE, responsável por retornar STATUS_NO_SUCH_FILE diante de qualquer tentativa de criar ou abrir um arquivo ou diretório que faça parte da lista de arquivos ocultos/protegidos pelo driver.
• Callback de pré-operação (pre-operation callback), ativado em cada solicitação de E/S IRP_MJ_DIRECTORY_CONTROL , responsável por filtrar solicitações não relacionadas à enumeração de diretórios, de modo que apenas aquelas vinculadas a essa tarefa sejam encaminhadas ao callback de pós-operação.
• Callback de pós-operação (post-operation callback), ativado em solicitações de E/S IRP_MJ_DIRECTORY_CONTROL que passaram pelas verificações do callback de pré-operação. Esse callback é responsável por remover as entradas correspondentes aos arquivos ocultos/protegidos de qualquer tentativa de listagem de diretórios.

A seguinte lista de nomes de arquivos codificados de forma fixa (hardcoded) é protegida pelo driver:

• \SystemRoot\Fonts\tpsvc.dll
• \SystemRoot\Fonts\tpsvcloc.dll
• \SystemRoot\Fonts\ApphostRagistreationVerifier.exe
• \SystemRoot\Fonts\X1B5206BDC1743DD.dat
• \SystemRoot\Fonts\KX1B5206BDC1743DD.dat
• \SystemRoot\Fonts\KW1B5206BDC1743FP.dat

Proteção da persistência

O driver invoca CmRegisterCallbackEx para instalar uma rotina RegistryCallback responsável por ocultar a chave de registro utilizada para a persistência do loader do SprySOCKS: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vds.exe.Como resultado, qualquer tentativa de abrir ou enumerar essa chave é filtrada pelo driver.

Componentes do WIN_PLUS

Na versão WIN_PLUS do SprySOCKS, primeiro descobrimos o contêiner criptografado malicioso em nossa telemetria, com a primeira detecção registrada em julho de 2024 no dispositivo de uma vítima no Paquistão. Esse contêiner continha o backdoor SprySOCKS e o loader do SprySOCKS.

A configuração de C&C estava presente e é mostrada na Figura 9.

O contêiner criptografado estava localizado no seguinte caminho do sistema comprometido:

C:\Windows\System32\spool\drivers\color\config.dat

Após ser descriptografado, o contêiner contém o loader do SprySOCKS e o próprio backdoor SprySOCKS. Uma análise posterior do backdoor contido nesse arquivo mostrou que, neste caso, parecia existir um componente adicional responsável por carregar o loader do SprySOCKS a partir do contêiner criptografado.

Esse componente, denominado first-stage loader nesta análise, deve ser instalado como um print processor por meio da seguinte chave de registro:

HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\VSPMsg

Curiosamente, ao pesquisar em nossa telemetria por qualquer elemento relacionado à cadeia VSPMsg, descobrimos um arquivo implantado em dois dispositivos de vítimas em Honduras, localizado em: C:\Windows\System32\spool\prtprocs\x64\VSPMsg.dll.Esse arquivo revelou ser o first-stage loader responsável por executar o loader do SprySOCKS a partir do arquivo config.dat mencionado anteriormente.

A Figura 10 ilustra um diagrama de execução da variante WIN_PLUS do SprySOCKS.

Loader de primeira etapa

Esse loader começa verificando se foi executado pelo spoolsv.exe  e encerra sua execução caso contrário. Isso oculta seu comportamento de sandboxes automatizadas de análise de malware, já que ele foi desenvolvido para ser executado como um print processor.

Em seguida, ele continua descriptografando o loader do SprySOCKS a partir do contêiner criptografado localizado em: \Windows\System32\spool\drivers\‌color\config.dat. Primeiro, descriptografa o loader utilizando AES de 128 bits no modo ECB com a chave codificada de forma fixa (hardcoded) uXQLESMXGaRMs6BL. Posteriormente, injeta o loader em um novo processo svchost.exe por meio da técnica de process doppelgänging. Enquanto isso, o loader do SprySOCKS é gravado em um arquivo temporário, cujo nome começa com o prefixo TH, dentro do diretório %TEMP%.

A amostra exporta duas funções:

• GetErrorMessageModule
• SetErrorMessageModule

Embora a função SetErrorMessageModule não execute nenhuma ação, a função GetErrorMessageModule foi projetada para estabelecer a persistência do próprio loader. Ao ser executada, ela registra o loader como um print processor criando a chave de registro:HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\VSPMsg e define o valor de registro Driver como VSPMsg.dll. Em seguida, copia o arquivo C:\ProgramData\Microsoft Event\PFs\VSPMsg.dll, cujo caminho está codificado de forma fixa, para o diretório: C:\Windows\System32\spool\prtprocs\x64\.Depois, copia o contêiner criptografado de: C:\ProgramData\Microsoft Event\PFs\config.dat para: C:\Windows\System32\spool\drivers\color\config.dat.Após essa etapa, gera e posiciona o script em lote (batch script) affair-build.bat no diretório: C:\Windows\System32\spool\drivers\color\ e o executa. Como mostrado na Figura 11, o objetivo desse script é remover rastros do loader, apagando os arquivos do diretório original de implantação e acionando a execução do print processor recém-instalado ao reiniciar o serviço de print spooler.

Loader do SprySOCKS

Esse loader começa criando um mutex com o nome codificado de forma fixa (hardcoded) fqwhi2d1qaz2 e, em seguida, prossegue com o carregamento do backdoor SprySOCKS a partir do contêiner criptografado localizado em: C:\Windows\System32\spool\drivers\color\‌config.dat.Ele descriptografa o backdoor utilizando AES de 128 bits no modo ECB com a chave codificada de forma fixa (hardcoded) uXQLESMXGaRMs6BL e, posteriormente, injeta o backdoor em um novo processo svchost.exe por meio da técnica de process doppelgänging. Enquanto isso, o loader do SprySOCKS é gravado em um arquivo temporário cujo nome começa com o prefixo TH, dentro do diretório %TEMP%.

Backdoor SprySOCKS

Por fim, passamos à análise do próprio backdoor SprySOCKS. Em ambas as variantes, WIN_DRV e WIN_PLUS, a funcionalidade do backdoor é praticamente idêntica, e as diferenças estão limitadas aos caminhos específicos de arquivos utilizados, às chaves de registro empregadas e, conforme mencionado anteriormente, ao fato de que a versão WIN_PLUS não utiliza o driver RawWNPF para alcançar um nível mais elevado de furtividade.

Ambas as variantes analisadas neste relatório são DLLs com o nome original PrcsServer.dll, que exportam uma função chamada Stop. Inicialmente, elas criam um mutex chamado prcs-server-run e, em seguida, inicializam a funcionalidade principal do backdoor, que inclui a inicialização e execução dos canais de comunicação com o C&C (baseados na configuração codificada de forma fixa) e a ativação do keylogger. Além disso, a versão WIN_DRV do backdoor inicializa o driver RawWNPF invocando seu IOCTL 0x222000 e, em seguida, oculta seu próprio processo chamando o IOCTL 0x220350.

O keylogging é ativado somente se existir um arquivo INI em %appdata%\Microsoft\Vault\lgf.dat que contenha uma seção config com uma propriedade chamada key definida como 1. Caso essas condições sejam atendidas, ambas as variantes criam um mutex chamado Global\{DCAA7ED8-521B-4EAB-BE21-65254CF59239}e registram periodicamente dados da área de transferência, juntamente com o título da janela ativa e as teclas pressionadas, no arquivo %appdata%\Microsoft\Vault\lg.dat. Os dados desse arquivo são criptografados utilizando uma cifra XOR de um único byte com a chave 0x44.

Comunicação C&C

O backdoor oferece suporte a três protocolos para se comunicar com o C&C: TCP, UDP e WebSocket, e pode atuar tanto como cliente quanto como servidor. A funcionalidade de rede é amplamente baseada no framework HP-Socket, e algumas funções criptográficas foram implementadas utilizando a biblioteca Crypto++.

A configuração de C&C está incorporada ao backdoor e pode incluir:

• Até três endereços IP com suas respectivas portas, cada um especificando um endereço de C&C e sua porta para um dos canais de comunicação (TCP, UDP ou WebSocket); e
• Até três números de porta que indicam em quais portas o backdoor deve escutar para novas conexões (uma para o servidor TCP, uma para o servidor UDP e uma para o servidor WebSocket).

A Figura 9 mostra um exemplo de configuração da versão WIN_PLUS, que contém:

• O endereço e a porta C&C para o canal de comunicação TCP: 207.148.78[.]36:443;
• O endereço e a porta C&C para o canal de comunicação UDP: 207.148.78[.]36:53;
• O endereço e a porta C&C para o canal de comunicação WebSocket: 207.148.78[.]36:80;
• A porta de escuta do servidor TCP do backdoor: 53781.

Antes de iniciar qualquer conexão ou servidor, a versão WIN_DRV do SprySOCKS oculta as conexões de/para os endereços ou portas definidos na configuração, invocando os IOCTLs 0x220340 e 0x220200 do driver RawWNPF. Como resultado, essas conexões não aparecem na saída de ferramentas como o netstat.exe, mesmo quando estão ativas.

Além disso, ambas as versões do backdoor executam o utilitário netsh.exe duas vezes:

netsh.exe netsh advfirewall firewall delete rule name="Core Networking - Packet Too Big(ICMPv6 - In)"

netsh advfirewall firewall add rule name="Core Networking - Packet Too Big(ICMPv6 - In)" dir=in action=allow protocol=tcp localport=53781

O primeiro comando remove uma regra específica do firewall, e o segundo adiciona uma nova regra com o mesmo nome, permitindo todo o tráfego TCP de entrada direcionado à porta do servidor TCP do backdoor definida na configuração.

Se a configuração de C&C estiver vazia (como no caso da versão WIN_DRV detectada no VirusTotal), o backdoor inicia um servidor TCP que escuta em uma porta aleatória no sistema comprometido e oculta essa porta invocando o IOCTL 0x220200 do driver RawWNPF. Essa chamada não apenas impede que o servidor TCP apareça em ferramentas padrão de monitoramento, como também ativa a funcionalidade de redirecionamento TCP fornecida pelo driver. Esse recurso permite que os invasores enviem comandos ao backdoor sem conhecer a porta real em que ele está escutando, simplesmente enviando dados TCP especialmente elaborados para qualquer porta TCP aberta na máquina da vítima.

Para o canal de comunicação TCP, o protocolo C&C parece ser o mesmo da versão Linux analisada no relatório da Trend Micro. Antes do envio dos dados reais, é enviado um cabeçalho de 12 bytes contendo o CRC de 32 bits do restante do cabeçalho, um valor mágico DWORD 0xACACBCBC e um DWORD que especifica o tamanho dos dados que seguem o cabeçalho.

Para os canais UDP e WebSocket, os valores mágicos são diferentes, assim como o formato e o tamanho do cabeçalho das mensagens. No canal UDP, o valor mágico é 0xACACBFBC e está localizado no deslocamento 0x1C dentro de um cabeçalho de 36 bytes, seguido por um DWORD que indica o tamanho dos dados. No canal WebSocket, o valor mágico 0x1BDCCBAA é utilizado como MaskingKey dentro do cabeçalho WebSocket. A Figura 12 mostra uma captura de tráfego de rede com os valores mágicos utilizados em cada canal de comunicação.

Após o cabeçalho (header), encontra-se novamente um CRC de 32 bits, seguido pelo valor WORD 0x0003 (provavelmente indicando o método de criptografia) e, então, dados criptografados com AES de 128 bits no modo ECB (utilizando a chave codificada de forma fixa (hardcoded) QFTHEYjzX3RBOMgZ) que foram codificados em Base64.

A Figura 13 mostra um exemplo de uma mensagem C&C antes e depois da decodificação e descriptografia.

O valor __msgid dentro da mensagem C&C descriptografada é utilizado para especificar um comando, identificado por um ID de mensagem (message ID), que deve ser executado pelo backdoor.

A lista de IDs de mensagem suportados pelo backdoor, juntamente com suas descrições, pode ser encontrada na Tabela 3. Vale destacar que nem todos esses comandos foram analisados em profundidade; portanto, algumas descrições representam apenas uma visão geral aproximada da parte do código ou funcionalidade relacionada a cada ID de mensagem.

Tabela 3. Comandos C&C do SprySOCKS; as descrições marcadas com * são avaliações preliminares.

Infraestrutura de rede

Nesta campanha, foi identificado um único endereço de C&C: 207.148.78[.]36. Esse endereço está codificado de forma fixa na configuração (mostrada na Figura 9) da variante WIN_PLUS  do backdoor SprySOCKS.

As portas definidas na configuração que o backdoor deve utilizar para se comunicar com o C&C são:

• TCP: 443
• UDP: 53
• WebSocket: 80

Conforme mencionado no relatório da Trend Micro, o endereço IP 207.148.75[.]122, pertencente ao mesmo intervalo de IP 207.148.64.0/20 do C&C anterior, foi utilizado pelos operadores do FishMonger como servidor de entrega do SprySOCKS em junho de 2023. Esse intervalo de IP pertence ao provedor de hospedagem em nuvem Vultr.

A variante representa uma expansão

A descoberta de uma variante para Windows do SprySOCKS, anteriormente conhecido como um backdoor exclusivo para Linux, representa uma expansão significativa das capacidades multiplataforma do FishMonger.

Nossa análise mostra que a versão para Windows mantém grande parte da arquitetura principal de sua contraparte para Linux, incluindo o protocolo de C&C, a criptografia utilizada e a lógica geral de gerenciamento de comandos, ao mesmo tempo em que incorpora mecanismos nativos do Windows quando necessário e aprimora o nível de furtividade do backdoor por meio do uso de drivers de kernel.

Considerando os indícios limitados sobre uma possível participação de um UEFI bootkit, recomendamos monitorar de perto as atividades desse grupo.

Para qualquer dúvida sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco pelo e-mail threatintel@eset.com.

Indicadores de Comprometimento

Arquivos

Rede

Técnicas MITRE ATT&CK

Esta tabela foi elaborada utilizando a versão 19 do framework MITRE ATT&CK.