Um carregador do Windows previamente não documentado, rastreado como OXLOADER, está distribuindo o ladrão de informações CASTLESTEALER por meio de anúncios maliciosos do Google, com baixas taxas de detecção em mecanismos de busca estática e detonações em sandbox. O carregador usa várias camadas de ofuscação (achatamento de fluxo de controle, predicados opacos, aritmética booleana mista), stubs de descriptografia automodificáveis e abusa da seção .reloc do Windows para inserir shellcode.

A Elastic Security Labs identificou o OXLOADER em uma campanha ativa direcionada a um de nossos clientes; as exclusões da região da CEI e do idioma russo apontam para um agente de ameaças com motivação financeira e que fala russo. Não encontramos nenhuma informação pública anterior sobre essa família.

Principais conclusões

• A Elastic Security Labs descobre um novo carregador (OXLOADER)
• OXLOADER foi detectado em campanhas que distribuíam CASTLESTEALER por meio de anúncios maliciosos do Google.
• A exclusão da região da CEI e as verificações de idioma russo sugerem um agente de ameaça de língua russa com motivações financeiras.
• Baixas taxas de detecção em motores estáticos e detonações em simulador.
• O Elastic Defend interrompe toda a cadeia de ataques usando recursos avançados de prevenção.

Como a publicidade maliciosa levou o OXLOADER às vítimas

O OXLOADER é distribuído por meio de anúncios maliciosos do Google Ads que se fazem passar por Node.js. As vítimas são redirecionadas por meio de um domínio intermediário para um script em lote hospedado pela Storj, que baixa e executa o OXLOADER.

A infecção começou quando o usuário pesquisou por lts version of node.js e clicou em um resultado patrocinado que levava a node-js[.]prentiva99[.]info, uma página de destino maliciosa projetada para se passar por uma plataforma legítima de implantação do Node.js. O agente da ameaça operava uma campanha do Google Ads direcionada a vítimas nos EUA; o anúncio foi exibido pela última vez em 23 2026 de abril, e o site agora está offline. O anunciante foi registrado sob o nome verificado ВОЛОДИМИР ТЕРЕЩЕНКО, com sede na Ucrânia. Não está claro se isso reflete o operador real, uma conta de fachada ou uma identidade comprada. Nos 14 2026 de maio, o anunciante e suas respectivas campanhas publicitárias foram completamente removidos do Google.

Após a interação, o usuário foi redirecionado através de app[.]miloyannopoulos[.]com/download?subid1=download, que respondeu com um 302 Found para o URL de carga útil link[.]storjshare[.]io/raw/jux4e4ky5mruo4jkxsssp42sau4q/ruslan/BATPackageBuilderSetup.bat. Isso gerou um script em lote do Windows, hospedado no serviço legítimo de compartilhamento de links da Storj , que o agente malicioso explorou para burlar a filtragem de reputação baseada em domínio.

O script em lote exibe uma interface de usuário falsa de assistente de instalação de software, baixa imediatamente o executável do próximo estágio do URL Storj link.storjshare[.]io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe via PowerShell e o executa com -Verb RunAs para acionar um prompt de elevação UAC.

Após a execução do script Batch, o Elastic Defend detectou comportamento malicioso (a política estava definida para detectar apenas), acionando várias regras comportamentais, incluindo Microsoft Common Language Runtime Loaded from Suspicious Memory, sugerindo uma carga útil baseada em .NET consistente com CASTLESTEALER.

A seguir, apresenta-se o gráfico de execução da cadeia de ataque, desde o download do payload até a implantação em CASTLESTEALER .

Carregador de malware OXLOADER: análise técnica

A primeira amostra do OXLOADER que nossa equipe analisou se disfarça como a ferramenta popular API Monitor , da rohitab.com. Devido à forte presença de código legítimo e técnicas de ocultação de código, este carregador consegue passar despercebido pelos analisadores de arquivos estáticos.

Como o OXLOADER se descompacta em tempo de execução

O malware começa a ser executado durante a fase de inicialização do CRT, antes que qualquer código do usuário seja executado. A função CRT cinit() invoca initterm(), que percorre a tabela de inicialização C++ (__xc_a → __xc_z) chamando cada entrada. O desenvolvedor do malware sequestrou uma dessas entradas, apontando para uma função que faz uma chamada RegisterClipboardFormatW() antes de pular para o primeiro stub de descriptografia.

O carregador utiliza técnicas de automodificação com vários fragmentos de descriptografia para se desenrolar. Abaixo, segue um exemplo de um trecho de código de descriptografia sendo inserido em tempo de execução, antes de prosseguir para ele.

Após a aplicação do patch, o carregador descriptografa uma região de 28.233 bytes. Cada byte é descriptografado com uma chave XOR de um único byte que é atualizada após cada iteração: o byte de texto simples recém-descriptografado é adicionado à chave, que é então usada para descriptografar o próximo byte. Essa rotina de descriptografia semelhante é executada três vezes no total, cada vez em uma região diferente.

Técnicas de ofuscação usadas para evitar detecção estática

O OXLOADER impede a detecção automática de limites de funções em ferramentas de análise binária, como o IDA Pro, usando quatro técnicas de ofuscação em camadas: achatamento de fluxo de controle (CFF), aritmética booleana mista (MBA), predicados opacos e fragmentação de funções em regiões de código não contíguas. As funções são interligadas por meio de saltos incondicionais, e algumas regiões são alcançadas através de saltos indiretos cujos endereços de destino são calculados em tempo de execução via aritmética MBA. O resultado é que o IDA Pro não consegue reconstruir os limites das funções de forma confiável, exigindo correções manuais.

O carregador descriptografa várias strings em tempo de execução usando o seguinte algoritmo de descriptografia de strings:

uint32_t obf_xor_a1_with_a2_plus_33FDA(uint32_t a1, uint32_t a2) { 
return a1 ^ (a2 + 0x33FDA); 
}

Após o código ser totalmente descompactado/descriptografado, o malware combina essa função de descriptografia de string com um algoritmo de hash da API Adler-32 para resolver dinamicamente suas importações.

Como o OXLOADER evita a detecção por sandbox e máquina virtual?

Após resolver suas APIs, o OXLOADER realiza diversas verificações para garantir que a máquina execute em um ambiente limpo, evitando a execução em ambientes de sandbox.

A primeira verificação tenta conectar-se a um recurso de rede deliberadamente malformado (*72s@1s) usando mpr!WNetAddConnection2W. Essa técnica parece burlar emulações/ambientes isolados que podem interceptar ou retornar uma conexão bem-sucedida incondicionalmente. O desenvolvedor do malware verifica essa chamada acessando o TEB diretamente para recuperar o LastErrorValue. O carregador espera que este código de erro seja ERROR_BAD_NAME (0x43), se o código de erro for qualquer outro valor diferente deste, o malware segue o caminho de falha e interrompe a execução.

A segunda verificação é um teste anti-sandbox baseado na contagem de processadores: o carregador exige que o host tenha pelo menos 3 CPUs para continuar. Muitas máquinas virtuais de teste e análise são provisionadas com uma ou duas CPUs para conservar recursos, portanto, esse limite filtra esses ambientes de análise automatizados.

A próxima verificação usa GlobalMemoryStatusEx() para verificar se o host tem pelo menos 3 GB de memória física disponível.

Uma verificação adicional usa WMI para consultar a taxa de atualização da tela do sistema, executando a instrução WQL SELECT CurrentRefreshRate FROM Win32_VideoController e comparando o valor retornado (em Hertz) com um limite de 20. Monitores físicos geralmente reportam cerca de 60 Hz ou mais, enquanto configurações sem monitor e virtualizadas por padrão normalmente reportam 0 ou 1, e valores abaixo de 20 fazem com que o carregador seja abortado.

Exclusões geográficas e linguísticas

As duas últimas verificações interrompem a execução se o host estiver localizado em um país da CEI ou configurado para o idioma russo. A primeira verificação nesta categoria usa GetUserGeoID para recuperar a região geográfica do sistema e a compara com uma lista codificada de GEOIDs de países da CEI.

A segunda verificação usa GetUserDefaultUILanguage e compara com LANGID (0x419 - Russian, Russia), a configuração padrão para uma instalação do Windows em russo.

Preparação do shellcode via .reloc seção e arquivo OCX

Após todas as verificações terem sido aprovadas, o malware faz uma cópia da DLL do mecanismo DirectUI do Windows (C:\Windows\System32\dui70.dll), armazenando-a em um local temporário usando um nome gerado aleatoriamente com a extensão .ocx (PFHemkxVk.ocx). Essa escolha de extensão inspirou o sobrenome OXLOADER.

O OXLOADER então cria uma nova seção chamada (.xtext) nesta DLL de destino (PFHemkxVk.ocx).

Esta nova seção (.xtext) está configurada com proteções RWX (leitura/gravação/execução) em preparação para armazenar e executar o próximo estágio do código malicioso.

Esta DLL atualizada (PFHemkxVk.ocx) é então carregada no processo de carregamento existente através de LoadLibraryA.

Em um executável normal do Windows, a seção .reloc contém uma tabela de blocos IMAGE_BASE_RELOCATION que o carregador do Windows aplica para corrigir endereços absolutos quando a imagem é carregada em um endereço diferente de sua base preferida. Neste exemplo, o desenvolvedor do malware está usando
a seção .reloc para abrigar código malicioso em vez das entradas de realocação base. Isso é um forte sinal de alerta de análise estática: cadeias de ferramentas legítimas não emitem código na seção .reloc .

Este shellcode da seção .reloc é então copiado para a seção recém-criada (.xtext) no arquivo OCX, e o carregador então chama este código.

Como observado anteriormente, existe outro bloco de descriptografia usado para descompactar esta próxima etapa.

Entrega de informações roubadas em memória via DonutLoader e assembly .NET

Este shellcode de próxima etapa é uma carga útil configurada a partir do DonutLoader, um gerador de shellcode de código aberto usado para encapsular assemblies, DLLs e EXEs do .NET em shellcode independente de posição (PIC) para execução na memória. Durante a descompactação, o shellcode descriptografa a configuração incorporada do carregador e o contexto de execução usando a cifra de bloco Chaskey-LTS no modo CTR com a chave (6E0A1F8F77F7011561F6F9CA96B71B8F) e IV (956C6128E9362E075F8D006C93616A66).

Após a descriptografia, a carga útil é descompactada via aPLib e então inicializada através da função RunPE() do DonutLoader. A carga final é um novo programa de roubo de informações descoberto pela Caçadora , chamado CASTLESTEALER. Esta atribuição é baseada na mesma chave AES usada para comunicações C2 encontradas entre marcadores 0xDEADBEEF em uma amostra anterior.

Segunda variante do OXLOADER: mesmo carregador, programa mascarado diferente

Uma segunda variante do OXLOADER se disfarça de instalador do Node.js em vez de monitor de API, mas usa o mesmo mecanismo de carregamento.

Em 13 de maio de 2026, descobrimos que o endpoint de redirecionamento app.miloyannopoulos[.]com/download respondeu com um dos dois campos de cabeçalho Location , escolhidos aleatoriamente:

• https://link.storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat
• https://link.storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe

O script de instalação em lote (BATPackageBulderSetup.bat, com um erro de digitação para “Builder”) permaneceu praticamente idêntico. A única diferença era que o link de carga útil Storj agora apontava para um binário diferente chamado node-v24.15.0-x64-86.exe.

A carga útil tenta se disfarçar de código CMake inofensivo, mantendo "node" no nome do arquivo, provavelmente para preservar a temática de isca. Acreditamos que a amostra anterior do "API Monitor" provavelmente foi um erro de distribuição por parte da operadora.

Após a execução, notamos o mesmo padrão: saltos indiretos usados para autodecriptografia na memória, seguidos pelo carregamento de mpr.dll e uma chamada para WNetAddConnection2W. Confirmamos que se trata do mesmo mecanismo de carregamento discutido anteriormente, e esta amostra também carrega CASTLESTEALER.

Abaixo segue um trecho onde ocorre a autodecriptografia. Aparentemente, strings fictícias relacionadas ao CMake são passadas como argumentos para uma chamada de função, que insere um pequeno trecho de código de descriptografia na memória imediatamente após o ponto de chamada. A execução então salta para o stub para descriptografar as instruções subsequentes, e este processo se repete 2 vezes até que o corpo principal do malware seja descriptografado.

Conclusão: por que os defensores devem acompanhar o OXLOADER

O OXLOADER está em fase operacional inicial, mas a engenharia por trás dele sugere que vale a pena acompanhar essa família de produtos. A ofuscação de código, as medidas anti-VM, o código de aparência benigna usado para mascarar seus binários e as técnicas de preparação exclusivas refletem escolhas de engenharia deliberadas para evitar análises. Esse investimento está dando frutos, resultando em baixas taxas de detecção em motores estáticos e testes de detonação, dando ao OXLOADER uma janela de operação antes de ser localizado.

REF8372 através da 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.

• Desenvolvimento de recursos
• Acesso inicial
• Execução
• Defense Evasion
• Descoberta
• Command and Control (Comando e controle)
• Coleta
• Exfiltração

Técnicas

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

• Adquirir infraestrutura: Malvertising
• Capacidades da Etapa: Carregar Malware
• User Execution: Malicious File
• Interpretador de comando e script: PowerShell
• Abuse do mecanismo de controle de elevação: ignore o controle de conta de usuário
• Arquivos ou informações ofuscados: Arquivo criptografado/codificado
• Deobfuscate/Decode Files or Information (Desofuscar/decodificar arquivos ou informações)
• Arquivos ou informações ofuscados: cargas úteis incorporadas
• Mascaramento: corresponder a nome ou local legítimo
• Fluxo de execução do Hijack: carregamento lateral de DLL
• Evasão de Virtualização/Sandbox: Verificações do Sistema
• System Location Discovery: System Language Discovery
• Carregamento de código reflexivo

Remediando REF8372

Prevenção

• Descoberta potencial de informações do navegador
• Possibilidade de evasão com pontos de interrupção de hardware
• Manipulação suspeita do contexto da thread
• Chamada de API VirtualAlloc de uma DLL não assinada
• Alocação de memória remota suspeita
• Execução a partir de bytes finais suspeitos da pilha
• Microsoft Common Language Runtime Loaded from Suspicious Memory
• Suspicious PowerShell Execution (execução suspeita do PowerShell)
• Modificação de módulos a partir de uma biblioteca copiada

YARA

O Elastic Security criou regras YARA para identificar essa atividade.

• Windows.Trojan.OxLoader
• Windows.Trojan.CastleStealer

Observações

Os seguintes observáveis foram discutidos nesta pesquisa.