PEDÁGIO: O que é seu, eu sou seu

Introdução

Em setembro de 2025, a Texas A&M University System (TAMUS) Cybersecurity, uma provedora de serviços gerenciados de detecção e resposta, em colaboração com a Elastic Security Labs, descobriu uma atividade pós-exploração realizada por um agente de ameaças de língua chinesa que instalou um módulo malicioso do IIS, que estamos chamando de TOLLBOOTH. Durante esse período, observamos um framework webshell derivado do Godzilla, o uso da ferramenta de Monitoramento e Gerenciamento Remoto (RMM) GotoHTTP, juntamente com um driver malicioso usado para ocultar suas atividades. O agente malicioso explorou uma vulnerabilidade no servidor web IIS, que utilizava chaves de máquina ASP.NET encontradas em recursos públicos, como a documentação da Microsoft ou páginas de suporte do StackOverflow.

Uma sequência semelhante de eventos foi relatada pela primeira vez pela Microsoft em fevereiro deste ano. Nossa equipe acredita que esta é a continuação da mesma atividade de ameaça que a AhnLab também detalhou em abril, com base em malware e comportamentos semelhantes. Durante este evento, conseguimos aproveitar nossa parceria com o Departamento de Segurança Cibernética do Sistema Texas A&M para coletar informações sobre a atividade. Além disso, por meio da colaboração com a Validin, aproveitando sua infraestrutura global de digitalização, determinamos que organizações em todo o mundo foram impactadas por esta campanha. O relatório a seguir detalhará os eventos e as ferramentas utilizadas neste conjunto de atividades, conhecido como REF3927. Nossa esperança é aumentar a conscientização sobre essa atividade entre defensores e organizações, visto que ela está sendo ativamente utilizada de forma abusiva em escala global.

Principais conclusões

• Atores maliciosos estão explorando servidores IIS mal configurados, utilizando chaves de máquina expostas publicamente.
• Os comportamentos pós-comprometimento incluem o uso de drivers maliciosos, ferramentas de monitoramento remoto, extração de credenciais, implantação de webshells e malware do IIS.
• Os agentes maliciosos adaptaram o projeto de rootkit de código aberto "Hidden" para ocultar sua presença.
• O objetivo principal parece ser instalar um backdoor no IIS, chamado TOLLBOOTH, que inclui recursos de ocultação de SEO e webshell.
• Esta campanha incluiu exploração em larga escala em diversas regiões geográficas e setores da indústria.

Visão geral da campanha

Vetor de ataque

No mês passado, a Elastic Security Labs e a Texas A&M System Cybersecurity investigaram uma intrusão envolvendo um servidor Windows IIS mal configurado. Isso estava diretamente relacionado a um servidor configurado com chaves de máquina ASP.NET que haviam sido previamente publicadas na Internet. As chaves de máquina usadas em aplicações ASP.NET referem-se a chaves criptográficas utilizadas para criptografar e validar dados. Essas chaves são compostas de duas partes, ValidationKey e DecryptionKey, que são usadas para proteger recursos do ASP.NET, como ViewState e cookies de autenticação.

ViewState É um mecanismo usado por aplicações web ASP.NET para preservar o estado de uma página e seus controles entre requisições HTTP. Como o HTTP é um protocolo sem estado, ViewState permite que os dados sejam coletados quando a página é enviada e renderizada novamente. Esses dados são armazenados em um campo oculto (__VIEWSTATE) na página que é serializado e codificado em Base64. Este campo ViewState é suscetível a ataques de desserialização, permitindo que um atacante forje payloads usando as chaves da máquina do aplicativo. Temos motivos para acreditar que isso faz parte de uma campanha oportunista direcionada a servidores web Windows, utilizando chaves de máquina expostas publicamente.

A seguir, um exemplo desse tipo de ataque de desserialização, demonstrado por meio de uma solicitação POST em um ambiente virtual usando um gerador de payload de desserialização .NET de código aberto. O campo __VIEWSTATE contém uma carga útil codificada em URL e codificada em Base64 que executará um whoami e gravará um arquivo em um diretório. Com uma solicitação de exploração bem-sucedida, o servidor responderá com um HTTP/1.1 500 Internal Server Error.

Atividade pós-acordo

Após o acesso inicial por meio de injeção de ViewState, observou-se que o REF3927 implantava webshells, incluindo um framework de shell Godzilla, para facilitar o acesso persistente. Em seguida, eles enumeraram os privilégios e tentaram (sem sucesso) criar suas próprias contas de usuário. Quando as tentativas de criação de conta falharam, o invasor carregou e executou a ferramenta GotoHTTP Remote Monitoring and Management (RMM). O invasor criou uma conta de administrador e tentou extrair credenciais usando o Mimikatz, mas isso foi impedido pelo Elastic Defend.

Com as tentativas de ampliar ainda mais o escopo da intrusão bloqueadas, o agente da ameaça implantou seu módulo IIS de sequestro de tráfego, TOLLBOOTH, como forma de monetizar seu acesso. O agente também tentou implantar uma versão modificada do rootkit de código aberto Hidden para ofuscar seu malware. Na intrusão observada, o Elastic Defend impediu a execução tanto do TOLLBOOTH quanto do rootkit.

Análise EKP de Godzilla

Uma das principais ferramentas usadas por este grupo é um framework derivado do Godzilla chamado Z-Godzilla_ekp escrito por ekkoo-z. Esta ferramenta aproveita o projeto anterior do Godzilla, adicionando novos recursos, como um plugin para burlar o AMSI e mascarando seu tráfego de rede para parecer mais legítima. Este conjunto de ferramentas permite que os operadores gerem payloads em ASP.NET, Java, C# e PHP, conectem-se a alvos e oferece diferentes opções de criptografia para ocultar o tráfego de rede. Este framework utiliza um sistema de plugins controlado por uma interface gráfica com diversas funcionalidades, incluindo:

• Capacidades de descoberta/enumeração
• Técnicas de escalonamento de privilégios
• Execução de comando/execução de arquivo
• Carregador de shellcode, meterpreter, execução de PE em memória
• Gerenciamento de arquivos, utilitário de compactação
• Plugin de roubo de credenciais (lemon) - Recupera credenciais do FileZilla, Navicat, WinSCP e Xmanager
• Extração de senhas do navegador
• Análise de portas, configuração de proxy HTTP, anotações

Abaixo está um exemplo de tráfego de rede mostrando o tráfego do operador para o webshell (error.aspx) usando Z-Godzilla_ekp. O webshell receberá os dados criptografados com AES e codificados em Base64 da solicitação HTTP POST e, em seguida, executará o assembly .NET na memória. Essas solicitações são disfarçadas incorporando os dados criptografados em parâmetros HTTP POST, de forma a se misturarem com o tráfego de rede normal.

Análise de rootkit

O atacante ocultou sua presença na máquina infectada implantando um rootkit de kernel. Este rootkit funciona em conjunto com um aplicativo de espaço do usuário chamado HijackDriverManager, cujas strings de interface estão escritas em chinês, para interagir com o motorista. Para esta análise, examinamos tanto o rootkit malicioso quanto o código do projeto original de código aberto "Hidden", do qual ele foi derivado. Internamente, estamos chamando o rootkit HIDDENDRIVER e o aplicativo de espaço do usuário HIDDENCLI.

Este software malicioso é uma versão modificada do rootkit de código aberto Hidden, que está disponível no GitHub há anos. O autor do malware fez pequenas modificações antes da compilação. Por exemplo, o rootkit usa a Manipulação Direta de Objetos do Kernel (DKOM) para ocultar sua presença e manter a persistência no sistema comprometido. O driver compilado ainda contém a palavra "hidden" na string do caminho de compilação, indicando que foi utilizado o projeto de rootkit "Hidden".

Ao ser carregado inicialmente no kernel, o driver prioriza uma série de etapas críticas de inicialização. Primeiramente, invoca sete funções de inicialização:

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

Para preparar seus componentes internos antes de preencher seu objeto de driver e campos associados, como funções principais.

As seções seguintes detalharão cada uma dessas sete funções de inicialização críticas, explicando sua finalidade.

InicializarConfigurações

A ação inicial do rootkit é executar a função InitializeConfigs . O único propósito desta função é ler a configuração do rootkit a partir da chave de serviço do driver no registro do Windows, que é preenchida pelo aplicativo em espaço de usuário. Esses valores são extraídos e inseridos em variáveis de configuração globais que serão posteriormente utilizadas pelo rootkit.

A tabela a seguir resume os parâmetros de configuração que o rootkit extrai do registro:

InicializarAnalisadorDeKernel

Seu objetivo é examinar dinamicamente a memória do kernel para encontrar os endereços de PspCidTable e ActiveProcessLinks que são necessários.

O PspCidTable é a estrutura do kernel que serve como uma tabela para IDs de processos e threads, enquanto ActiveProcessLinks sob a estrutura _EPROCESS serve como uma lista duplamente encadeada conectando todos os processos em execução. Isso permite que o sistema rastreie e percorra todos os processos ativos. Ao remover entradas desta lista, é possível ocultar processos de ferramentas de enumeração como o Process Explorer.

LookForPspCidTable

Ele busca o endereço PspCidTable desmontando a função PsLookupProcessByProcessIdcom a biblioteca Zydis e analisando-a.

Procure por links de processos ativos

Esta função determina o deslocamento do campo ActiveProcessLinks dentro da estrutura _EPROCESS . Ele usa valores de deslocamento fixos específicos para diferentes versões do Windows. Possui um processo de varredura rápido que se baseia nesses valores codificados para encontrar o campo ActiveProcessLinks , que será validado por outra função. Caso não consiga encontrar o valor com os valores predefinidos, o programa adota uma abordagem de força bruta, começando com um deslocamento relativo predefinido até o deslocamento máximo possível.

InicializarPsMonitor

InitializePsMonitor Configura o mecanismo de monitoramento e manipulação de processos do rootkit. Essa é a essência da sua capacidade de ocultar processos.

Primeiramente, inicializa três estruturas de árvore AVL para armazenar informações (regras) para excluir, proteger e ocultar processos. Ele usa RtlInitializeGenericTableAvl para pesquisas de alta velocidade e as preenche com dados da configuração. Em seguida, ele configura diferentes funções de retorno de chamada do kernel para monitorar o sistema usando o conjunto de regras.

Registrando o retorno de chamada do gerenciador de objetos com (ObRegisterCallbacks)

Este gancho registra as funções ProcessPreCallback e ThreadPreCallback . O Gerenciador de Objetos do kernel executa esse código antes de concluir qualquer solicitação para criar ou duplicar um identificador para um processo ou thread.

Quando um processo tenta obter um controle sobre outro processo, a função de retorno de chamada ProcessPreCallback é chamada. Primeiramente, será verificado se o processo de destino é um processo protegido (está na lista). Se for esse o caso, em vez de não conceder acesso, simplesmente diminuirá seus direitos sobre o processo protegido com o acesso definido como SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION.

Isso garantirá que os processos não possam interagir com o processo protegido, inspecioná-lo ou encerrá-lo.

O mesmo mecanismo se aplica às threads.

Callback de Criação de Processo (PsSetCreateProcessNotifyRoutineEx)

O rootkit registra um retorno de chamada com a API PsSetCreateProcessNotifyRoutineEx na criação do processo. Quando um novo processo é iniciado, este retorno de chamada executa uma função CheckProcessFlags que verifica a imagem do processo em relação à lista configurada de caminhos de imagem. Em seguida, cria uma entrada para este novo processo em sua tabela de rastreamento interna, definindo seus indicadores excluded, protected e hidden de acordo.

Comportamento baseado em sinalizadores:

• Excluído
  • O rootkit irá ignorar o processo e simplesmente deixá-lo funcionar como esperado.
• Protegido
  • O rootkit não permitirá que nenhum outro processo obtenha um identificador privilegiado sobre ele, semelhante ao que acontece em ProcessPreCallback.
• Escondido
  • O rootkit ocultará o processo por meio da Manipulação Direta de Objetos do Kernel (DKOM). Manipular diretamente as estruturas do núcleo de um processo no exato instante de sua criação pode ser instável. Na função de retorno de chamada de criação de processo, se um processo precisar ser ocultado, ele será desvinculado da lista ActiveProcessLinks. No entanto, ele define um sinalizador postponeHiding que será explicado abaixo.

A função de retorno de chamada de carregamento de imagem (PsSetLoadImageNotifyRoutine)

Isso registra o LoadProcessImageNotifyCallback usando PsSetLoadImageNotifyRoutine, que o kernel chama sempre que uma imagem executável (um .exe ou .dll) é carregada na memória de um processo.

Quando a imagem é carregada, o retorno de chamada verifica o sinalizador postponeHiding ; se definido, ele chama UnlinkProcessFromCidTable para removê-lo da tabela de ID do processo mestre (PspCidTable).

InicializarFSMiniFiltro

A função define suas capacidades no FilterRegistration structure(FLT_REGISTRATION). Essa estrutura informa ao sistema operacional quais funções devem ser chamadas para cada tipo de operação do sistema de arquivos. Ele registra funções de retorno de chamada para as seguintes solicitações:

• IRP_MJ_CREATE: Intercepta qualquer tentativa de abrir ou criar um arquivo ou diretório.
• IRP_MJ_DIRECTORY_CONTROL: Intercepta qualquer tentativa de listar o conteúdo de um diretório.

FltCreatePreOperation(IRP_MJ_CREATE)

Esta é uma função de retorno de chamada pré-operacional; quando um processo tenta criar/abrir um arquivo, esta função é acionada. Ele verificará o caminho em relação à sua lista de arquivos a serem ocultados. Se uma correspondência for encontrada, o resultado da operação da solicitação IRP será alterado para STATUS_NO_SUCH_FILE, indicando ao processo solicitante que o arquivo não existe, exceto se o processo estiver incluído na lista de exclusão.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

Este é um retorno de chamada pós-operação; o gancho implementado essencialmente intercepta o diretório de escuta gerado pelo sistema e o modifica, removendo quaisquer arquivos listados como ocultos.

InicializarFiltroDeRegistro

Após ocultar seus processos e arquivos, o próximo passo do rootkit é apagar entradas do Registro do Windows. A função InitializeRegistryFilter realiza isso instalando um retorno de chamada de filtragem de registro para interceptar e modificar operações de registro.

Ele registra um retorno de chamada usando a API CmRegisterCallbackEx , usando o mesmo princípio que com arquivos. Se a chave ou o valor do registro estiver na lista de registro oculta, a função de retorno de chamada retornará o status STATUS_NOT_FOUND.

InicializarDispositivo

A função InitializeDevice realiza a inicialização do driver necessária e configura um IOCTL communication para que o aplicativo em espaço de usuário possa se comunicar diretamente com ele.

A seguir, encontra-se uma tabela que descreve cada comando IOCTL tratado pelo driver.

InicializarModoInvisível

Após configurar com sucesso sua configuração, callbacks de processo e filtros de sistema de arquivos, o rootkit executa sua rotina de inicialização final: InitializeStealthMode. Se o sinalizador de configuração Kbj_YinshenMode estiver ativado, ele ocultará todos os artefatos associados ao rootkit, incluindo chaves de registro, o arquivo .sys e outros componentes relacionados, usando as mesmas técnicas descritas acima.

Variações de código

Embora o malware seja fortemente baseado no código-fonte HIDDENDRIVER , nossa análise identificou diversas alterações menores. A seção a seguir detalha as diferenças de código notáveis que observamos.

O código original na função IsProcessExcluded exclui consistentemente o processo do sistema (PID 4) das operações do rootkit. No entanto, o rootkit malicioso possui uma lista de exclusão para nomes de processos adicionais, conforme ilustrado na captura de tela fornecida.

O retorno de chamada do código original para filtrar informações do sistema (incluindo arquivos, diretórios e registros) usava a função IsDriverEnabled para verificar se as funcionalidades do driver estavam habilitadas. No entanto, o rootkit observado introduziu uma verificação adicional e automática de lista branca para processos com o sequestro do nome da imagem, que corresponde ao aplicativo de espaço do usuário.

Uso do RMM

A ferramenta GotoHTTP é um aplicativo legítimo de Monitoramento e Gerenciamento Remoto (RMM), implantado pelo agente da ameaça para facilitar o acesso ao servidor IIS comprometido. Sua arquitetura "Navegador-para-Cliente" permite que o atacante controle o servidor a partir de qualquer navegador web padrão por meio de portas web comuns (80/443) roteando todo o tráfego através da própria plataforma GotoHTTP, impedindo a conexão de rede direta com a infraestrutura do atacante.

Os RMMs continuam a ganhar popularidade para uso em múltiplos pontos da cadeia de ataque cibernético e por diversos agentes de ameaças. A maioria dos fornecedores de antivírus não os considera maliciosos isoladamente e, portanto, não os bloqueiam completamente. O RMM C2 também flui apenas para sites legítimos de provedores de RMM e, portanto, possui a mesma dinâmica para proteções e monitoramento baseados em rede.

Bloquear a grande quantidade de RMMs atualmente ativos e permitir apenas o RMM preferido da empresa seria o mecanismo de proteção ideal. No entanto, esse paradigma só está disponível para empresas que possuem o conhecimento técnico adequado, ferramentas de defesa, políticas organizacionais maduras e coordenação entre os departamentos.

Análise de módulos do IIS

Observou-se que o agente da ameaça implantou versões de 32 e 64 bits do TOLLBOOTH, um módulo malicioso do IIS. O TOLLBOOTH já foi discutido anteriormente pela Ahnlab e pelo pesquisador de segurança, @Azaka. Algumas das principais funcionalidades do malware incluem camuflagem de SEO, um canal de gerenciamento e um webshell acessível publicamente. Descobrimos que versões nativas e gerenciadas pelo .NET estavam sendo implantadas em produção.

Estrutura de Configuração de Malware

O TOLLBOOTH recupera sua configuração dinamicamente de hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, e a criação do arquivo de configuração JSON de cada vítima é gerenciada pela infraestrutura do agente de ameaça. Entretanto, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json respondeu, mostrando uma falta de verificações anti-análise - permitindo-nos recuperar uma cópia de um arquivo de configuração para análise. É possível visualizar o conteúdo neste Gist do GitHub, e faremos referência a como alguns dos campos são usados conforme necessário.

Para módulos nativos, a configuração e outros arquivos de cache temporários são compactados com Gzip e armazenados localmente em um caminho fixo C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\. Para o módulo gerenciado, estes são criptografados com AES com chave YourSecretKey123 e IV 0123456789ABCDEF, compactados com Gzip e armazenados em C:\\Windows\\Temp\\AcpLogs\\.

Webshell

TOLLBOOTH expõe um webshell no caminho /mywebdll , exigindo uma senha de hack123456! para uploads de arquivos e execução de comandos. O envio do formulário envia uma solicitação POST para o endpoint /scjg .

A senha está codificada no binário, e este recurso de webshell está presente tanto em v1.6.0 quanto em v1.6.1 da versão nativa do TOLLBOOTH.

A funcionalidade de upload de arquivos contém um bug que surge da sua análise sequencial e dependente da ordem dos campos multipart/form-data . O formulário HTML padrão é estruturado de forma que o campo de entrada de arquivo apareça antes dos campos de entrada de diretório. O servidor que processa as partes da solicitação tenta lidar com os dados do arquivo antes do diretório de destino, criando um conflito de dependência que faz com que os uploads padrão falhem. Ao reordenar manualmente as partes multipart/form-data , ainda é possível realizar um upload de arquivo bem-sucedido.

Canal de gerenciamento

O TOLLBOOTH expõe alguns endpoints adicionais para fins de gerenciamento/depuração dos operadores de C2. Eles só podem ser acessados definindo o User Agent para um dos seguintes (embora seja configurável):

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

O endpoint /health fornece uma maneira rápida de avaliar a integridade do módulo, retornando o nome do arquivo para acessar a configuração armazenada em c[.]cseo99[.]com, informações de espaço em disco, o caminho de instalação do módulo e a versão do TOLLBOOTH.

O endpoint /debug fornece mais detalhes, incluindo um resumo da configuração, diretório de cache, informações da solicitação HTTP, etc.

A configuração analisada está acessível em /conf.

O endpoint /clean permite que o operador limpe a configuração atual excluindo os arquivos de configuração armazenados localmente (clean?type=conf) para atualizá-los no servidor da vítima, limpe quaisquer outros caches temporários que o malware usa (clean?type=conf), ou limpe ambos - tudo no caminho C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ (clean?type=all).

Ocultação de SEO

O principal objetivo do TOLLBOOTH é o SEO cloaking, um processo que envolve apresentar conteúdo otimizado para palavras-chave aos rastreadores dos mecanismos de busca, ocultando-o da navegação casual do usuário, para alcançar melhores posições nos resultados de busca. Quando um visitante humano clica no link dos resultados de pesquisa destacados, o malware o redireciona para uma página maliciosa ou fraudulenta. Essa tática é uma maneira eficaz de aumentar o tráfego para páginas maliciosas em comparação com alternativas como o phishing direto, porque os usuários confiam mais nos resultados de mecanismos de busca do que em e-mails não solicitados.

O TOLLBOOTH diferencia bots de visitantes verificando os cabeçalhos User Agent e Referer em busca de valores definidos na configuração.

Tanto os módulos nativos quanto os gerenciados são implementados de forma quase idêntica. A única diferença é que os módulos nativos v1.6.0 e v1.6.1 verificam o User Agent e o Referer em relação à lista seoGroupRefererMatchRules , e o módulo .NET v1.6.1 verifica o User Agent em relação à lista seoGroupUaMatchRules e o Referer em relação à lista seoGroupRefererMatchRules .

Com base na configuração atual, os valores para seoGroupUaMatchRules e seoGroupRefererMatchRules são googlebot e google, respectivamente. Um rastreador do GoogleBot teria uma correspondência de User Agent, mas não de Referer, enquanto um visitante humano teria uma correspondência de Referer, mas não de User Agent. Ao observar a lista de fallback contendo bing e yahoo , sugere-se que esses mecanismos de busca também foram alvos no passado.

O trecho de código abaixo é responsável por construir uma página repleta de links com palavras-chave que serão indexados pelos mecanismos de busca.

O módulo constrói uma rede de enlaces em duas fases. Primeiro, para construir a densidade de links internos, ele recupera uma lista de palavras-chave aleatórias de URIs de recursos definidos no campo de configuração affLinkMainWordSeoResArr . Para cada palavra-chave, gera um "link local" que aponta para outra página de SEO no mesmo site comprometido. Em seguida, constrói a rede externa recuperando "recursos de links afiliados" do campo affLinkSeoResArr . Esses recursos são uma lista de URIs que apontam para páginas de SEO em outros domínios externos que também estão infectados com o malware TOLLBOOTH. Os URIs têm a aparência de hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> na configuração. Em seguida, o módulo cria hiperlinks do site atual para essas outras vítimas. Essa técnica, conhecida como "link farming" (fazenda de links), tem como objetivo inflar artificialmente o posicionamento nos mecanismos de busca em toda a rede de sites comprometidos.

Abaixo, segue um exemplo do que um robô rastreador veria ao visitar a página inicial de um servidor web infectado com o vírus TOLLBOOTH.

Os prefixos do caminho da URL para as páginas de SEO contêm palavras ou frases do campo de configuração seoGroupUrlMatchRules . Isso também é mencionado na lógica de redirecionamento do site direcionada aos visitantes. Atualmente são:

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Os modelos e o conteúdo das páginas de SEO também são recuperados externamente de URIs que se parecem com hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> na configuração. Aqui está um exemplo de como uma das páginas de SEO se parece:

Para a lógica de redirecionamento do usuário, o módulo primeiro coleta uma impressão digital do visitante, incluindo seu endereço IP, agente do usuário, página de referência e a palavra-chave alvo de SEO da página. Em seguida, envia essas informações por meio de uma solicitação POST para hxxps://api[.]aseo99[.]com/client/landpage. Se a solicitação for bem-sucedida, o servidor responde com um objeto JSON contendo um landpageUrl específico, que se torna o destino para o redirecionamento.

Se a comunicação falhar por qualquer motivo, o TOLLBOOTH recorre à construção de um novo URL apontando para o mesmo endpoint C2, mas, em vez disso, codifica as informações do visitante diretamente no URL como parâmetros GET. Finalmente, o URL escolhido - seja da resposta bem-sucedida do C2 ou do fallback - é incorporado em um trecho de JavaScript (window.location.href) e enviado ao navegador da vítima, forçando um redirecionamento imediato.

Sequestrador de Páginas

Para os módulos nativos, se o caminho URI contiver xlb, o TOLLBOOTH responde com uma página de carregamento personalizada contendo uma tag de script. O atributo src deste script aponta para um URL gerado dinamicamente, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, que é usado para recuperar uma carga útil JavaScript ofuscada do próximo estágio.

A carga útil desofuscada parece ser uma ferramenta de substituição de página que é executada com base em palavras-chave de gatilho específicas (por exemplo, xlbh, mxlb) encontradas no URL. Uma vez acionado, ele contata um dos endpoints controlados pelo atacante em asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= ou ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key=, anexando o URL da página atual como um parâmetro codificado em Base64 para identificar o site comprometido. O script então usa document.write() para limpar completamente o DOM da página atual e substituí-lo pela resposta do servidor. Embora a carga útil final não tenha podido ser recuperada no momento da redação deste documento, esta técnica foi concebida para injetar conteúdo controlado pelo atacante, geralmente uma página HTML maliciosa ou um redirecionamento em JS para outro site malicioso.

Segmentação da campanha

Ao analisar o TOLLBOOTH e seu webshell associado, identificamos múltiplos mecanismos para identificar vítimas adicionais por meio de métodos de coleta ativos e semipassivos.

Em seguida, fizemos uma parceria com @SreekarMad da Validin para aproveitar sua experiência e a infraestrutura de escaneamento deles, a fim de desenvolver uma lista mais abrangente de vítimas.

No momento da publicação, foram identificadas vítimas de servidores 571 com infecções ativas pelo vírus TOLLBOOTH.

Esses servidores estão distribuídos globalmente (com uma grande exceção, descrita abaixo) e não se encaixam em nenhuma categoria vertical industrial bem definida. Por essas razões, juntamente com a enorme escala da operação, somos levados a crer que a seleção das vítimas não é direcionada e utiliza varreduras automatizadas para identificar servidores IIS que reutilizam chaves de máquina listadas publicamente.

A colaboração com a Validin e o Departamento de Segurança Cibernética do Sistema Texas A&M gerou uma quantidade robusta de metadados sobre as vítimas adicionais infectadas pelo TOLLBOOTH.

A exploração automatizada também pode ser empregada, mas a TAMUS Cybersecurity observou que a atividade pós-exploração parece ser interativa.

A Validin descobriu outros domínios potencialmente infectados, vinculados por meio das configurações de links de SEO farming, mas ao verificar a interface do webshell, constatou que ela estava inacessível em alguns casos. Após uma investigação manual mais aprofundada desses servidores, determinamos que eles haviam sido, de fato, infectados pelo vírus TOLLBOOTH, mas ou os proprietários corrigiram o problema ou os atacantes desistiram.

Análises subsequentes revelaram que muitos dos mesmos servidores haviam sido reinfectados. Consideramos isso um indício de que a remediação foi incompleta. Uma explicação plausível é que a simples remoção da ameaça não elimina a vulnerabilidade deixada aberta pela reutilização da chave da máquina. Assim, as vítimas que omitem esta etapa final provavelmente serão reinfectadas pelo mesmo mecanismo. Consulte a seção “Remediação do REF3927” abaixo para obter mais detalhes.

Geografia

A distribuição geográfica das vítimas exclui, notavelmente, quaisquer servidores localizados dentro das fronteiras da China. Um servidor foi identificado em Hong Kong, mas estava hospedando um domínio .co.uk . Essa provável geolocalização está alinhada com padrões de comportamento de outras ameaças criminosas, que implementam mecanismos para garantir que não tenham como alvo sistemas em seus países de origem. Isso atenua o risco de serem processados, uma vez que os governos desses países tendem a ignorar, ou mesmo a endossar abertamente, atividades criminosas contra estrangeiros.

Modelo Diamante

A Elastic Security Labs utiliza o Modelo Diamante para descrever as relações de alto nível entre adversários, capacidades, infraestrutura e vítimas de intrusões. Embora o Modelo Diamante seja mais comumente usado com intrusões únicas e aproveite o Encadeamento de Atividades (seção 8) para criar relações entre incidentes, um modelo centrado no adversário (seção 7.1.4) Essa abordagem permite a utilização de um único diamante.

Remediando REF3927

A remediação da infecção em si pode ser concluída por meio das melhores práticas do setor, como reverter para um estado limpo e lidar com malware e mecanismos de persistência. No entanto, diante da possibilidade de varreduras e explorações automatizadas, a vulnerabilidade da chave de máquina reutilizada permanece para qualquer agente malicioso que deseje assumir o controle do servidor.

Portanto, a correção deve incluir a rotação das chaves da máquina para uma nova chave gerada corretamente .

Conclusão

A campanha REF3927 destaca como um simples erro de configuração, como o uso de uma chave de máquina exposta publicamente, pode levar a uma significativa vulnerabilidade. Nesse incidente, a equipe de segurança cibernética do Sistema da Universidade Texas A&M e o cliente afetado agiram rapidamente para remediar o servidor, mas, com base em nossa pesquisa, continuam existindo outras vítimas que são alvo das mesmas técnicas.

A integração, pelo agente da ameaça, de ferramentas de código aberto, software RMM e um driver malicioso é uma combinação eficaz de técnicas que se mostraram bem-sucedidas em suas operações. Os administradores de ambientes IIS expostos publicamente devem auditar as configurações de chaves de suas máquinas, garantir um registro de segurança robusto e utilizar soluções de detecção de endpoints, como o Elastic Defend, durante possíveis incidentes.

Lógica de detecção

Regras de detecção

• Detecção de Web Shell: Processo de script filho de processos web comuns

Regras de prevenção

• Execução suspeita por meio de serviços do Windows
• Possível injeção de shellcode via webshell
• Execução a partir de diretório suspeito

Assinaturas YARA

A Elastic Security criou as seguintes regras YARA para impedir o malware observado em REF3927:

• Windows.Trojan.Tollbooth
• Windows.Trojan.HiddenCli
• Windows.Trojan.DriverOculto

REF3927 através do MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que as ameaças usam contra redes corporativas.

Táticas

As táticas representam o porquê de uma técnica ou subtécnica. É o objetivo tático do adversário: a razão para executar uma ação.

• Acesso inicial
• Execução
• Defense Evasion
• Acesso a credenciais
• Coleta
• Exfiltração

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Exploit Public-Facing Application
• Componente de software do servidor: Componentes do IIS
• Despejo de credenciais do sistema operacional
• Hide Artifacts: Hidden Files and Directories
• Dados do Sistema Local
• Rootkit
• Contas válidas

Observações

Os seguintes aspectos observáveis foram discutidos nesta pesquisa.

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/Z-Godzilla_ekp
• https://x.com/AzakaSekai_/status/1969294757978652947

Adenda

O HarfangLab publicou o rascunho de sua pesquisa sobre essa ameaça no mesmo dia em que este post foi divulgado. Nele, encontram-se informações complementares adicionais:

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/