Dissecando a operação do malware como serviço CastelBot

O IBM X-Force tem investigado um novo framework de malware chamado CastleBot. Acredita-se que o malware faça parte de uma operação de malware como serviço (MaaS) e tenha sido projetado especificamente para implementação flexível de malware. Atualmente, o CastleBot é usado por cibercriminosos para entregar de tudo, desde infostealers até backdoors como NetSupport e WarmCookie, que foram vinculados a ataques de ransomware.

O que torna o CastleBot particularmente preocupante é a forma como ele está sendo distribuído: geralmente por meio de instaladores de software trojanizados baixados de sites falsos, atraindo usuários desavisados para o lançamento da infecção. Essa técnica faz parte de uma tendência crescente que o X-Force está observando. Muitas vezes, é ativado por meio de envenenamento por SEO, o que faz com que páginas maliciosas tenham uma classificação mais alta nos mecanismos de pesquisa do que distribuidores de software legítimos. Uma vez dentro, o CastleBot passa por um processo de três estágios: um stager/downloader, um carregador e um backdoor central, que solicita um conjunto de tarefas do seu servidor de comando e controle (C2). As informações coletadas da máquina infectada permitem que os operadores filtrem facilmente as vítimas, gerenciem infecções em andamento e implementem malware em alvos de alto valor com precisão.

O CastleBot ainda está evoluindo, e nossa pesquisa mostra que provavelmente está apenas começando. Neste relatório, detalhamos como funciona, como se espalha e por que é importante.

• O CastleBot é um novo malware, provavelmente operado como um malware como serviço, que pode ser usado para enviar uma ampla gama de cargas maliciosas
• As cargas subsequentes variam de infostealers a backdoors vinculados a ataques de ransomware, como NetSupport e WarmCookie
• O X-Force observou que instaladores de software trojanizados são o vetor de infecção mais comum para a entrega do CastleBot.
• O framework CastleBot abrange três componentes: um stager, um carregador e um núcleo, e parece estar em desenvolvimento ativo
• O malware parece permitir que os operadores filtrem facilmente as vítimas, atualizem cargas e gerenciem várias campanhas ao longo de seu ciclo de vida

O CastleBot apareceu pela primeira vez no início de 2025. O X-Force observou um aumento no volume de amostras e diferentes cargas a partir de maio e, desde então, observou a implementação de várias cargas de backdoor e infostealer. O vetor de infecção mais comum do CastleBot é o software trojanizado, que faz parte de uma tendência que o X-Force continua observando desde 2024. Pacotes e instaladores de software trojanizados são frequentemente distribuídos por meio de sites falsos usando envenenamento por SEO para atrair vítimas. O CastleBot também foi distribuído através dos repositórios do GitHub, se passando por software legítimo e por meio da popular técnica ClickFix.

O X-Force identificou três componentes como parte da estrutura de malware do CastleBot: um stager, um carregador e o núcleo/backdoor do CastleBot.

Observe que relatórios públicos anteriores da Prodraft referem-se ao mesmo framework de malware como o “CastleLoader”.

Na maioria dos casos, o componente central do CastleBot é implementado por meio de um stager do shellcode, que faz parte da mesma família de malware CastleBot. O stager é uma carga do shellcode leve que pode ser injetada por qualquer outro carregador de primeiro estágio. O X-Force observou vários sistemas de criptografia usados com a CastleBot, incluindo o Dave, um sistema de criptografia baseado em AutoIt e sistemas de criptografia simples compilados em C.

O malware utiliza o algoritmo de hashing DJB2 para resolver as APIs necessárias no tempo de execução. Antes de cada chamada de API, ele carrega a DLL correspondente e atravessa a Export Address Table (EAT) procurando a função de API por meio de hashes DJB2 pré-gerados. Caso a exportação seja encaminhada para outra DLL, o stager analisa o nome da DLL, carrega-a e resolve a função via GetProcAddress.

Após a execução, o stager baixa duas cargas via HTTP com o agente do usuário "Googlebot". Os caminhos de URL são semelhantes entre as amostras e endereça o mesmo servidor C2 que o componente central da CastleBot.

Exemplo de URLs de download:

Ambas as cargas são descriptografadas por meio de uma string XOR codificada, neste caso "GySDoSGySDoS" (codificado em UTF-16), revelando um PE (núcleo do CastleBot) e um stub de shellcode (carregador do CastleBot).

Em seguida, o stager usa o VirtualProtect para permitir a execução no heap para a região de memória que armazena a segunda carga do shellcode descriptografado. Este último, atuando como um carregador, é executado diretamente na memória e recebe um ponteiro para o PE descriptografado como argumento.

O carregador do CastleBot é um carregador de PE com todos os recursos, que começa mapeando cada seção do PE fornecido em uma nova região de memória alocada usando NtAllocateVirtualMemory. Ele passa a corrigir quaisquer realocações necessárias, resolver importações, definir as opções apropriadas de proteção de memória e executar as funções de retorno de chamada TLS existentes.

Notavelmente, o carregador também configura uma nova estrutura LDR_DATA_TABLE_ENTRY e os LDR_DDAG_NODE correspondentes (estendidos no Windows 8 e posteriores), que são então adicionados às listas duplamente vinculadas PEB_LDR_DATA contendo os módulos carregados para cada processo. Para os agentes de EDR que monitoram o PEB, isso faria com que a carga injetada parecesse mais carregada pelo sistema operacional.

A menos que o arquivo injetado seja uma DLL, o campo ImageBaseAddress do PEB também é definido para o endereço base da carga injetada.

Por fim, para executar a carga, o carregador do CastleBot executa o ponto de entrada ou aloca um novo console para aplicações de console.

Na amostra analisada acima, a carga injetada é o backdoor x86 CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

O núcleo do CastleBot usa o mesmo mecanismo de resolução de API que os componentes do stager e do carregador, exceto pelo algoritmo de hash, que é o AP hash, desenvolvido por Arash Partow.

Primeiro, o backdoor começa descriptografando sua configuração. Quase todas as strings em todo o binário, incluindo aquelas que fazem parte da configuração, são armazenadas como UTF-16 e descriptografadas em linha por meio de uma chave XOR exclusiva de 4 bytes para cada string. Durante a descriptografia, a seguinte estrutura de configuração é criada:

O malware tenta criar um mutex, usando o nome da configuração, para garantir que apenas uma única instância esteja em execução. Na próxima etapa, ele envia uma solicitação HTTP GET à URL permanente para recuperar suas configurações, usando a ID da campanha no caminho da URL:

Em resposta, o CastleBot recebe um bloco de dados criptografados.

Toda a comunicação C2 é criptografada por meio do algoritmo ChaCha simétrico, exceto a solicitação GET inicial do malware. Após a descriptografia, o protocolo C2 utiliza uma estrutura de dados serializada personalizada, internamente chamada de contêiner, que pode armazenar valores de diferentes tipos.

Na raiz da estrutura de dados serializados há sempre um campo do tipo ContainerFieldArray. As estruturas abaixo definem ainda mais como os tipos array e bool são configurados:

Ao analisar o contêiner descriptografado definindo as configurações solicitadas pela backdoor, os dados começam com o byte 0x0D, indicando o tipo ContainerFieldArray. Esse byte é seguido do nome do campo, que por si só tem o comprimento de 2 bytes seguido do nome codificado em UTF-16. Após o nome, um campo de matriz define um comprimento de 4 bytes de dados, seguido pelos próprios dados, que novamente começa com o primeiro byte definindo o tipo.

As configurações recebidas pela amostra analisada acima são analisadas da seguinte maneira.

Dados serializados:

Objeto desserializado:

Para cada configuração habilitada, as seguintes ações são executadas pelo CastleBot:

run_as_admin: o malware executará seu pai via "cmd.exe /c <parent_process>" via ShellExecuteW com o verbo "runas" para iniciá-lo como Administrador.

anti_vm: o CastleBot usará a instrução cpuid com a folha 0x40000000 para tentar detectar ambientes de hipervisor. Se o VMware ou o Parallels forem descobertos, o malware será encerrado.

prevent_restart: o CastleBot criará um novo arquivo oculto em %PROGRAMDATA% com o nome correspondente ao nome do mutex incorporado na configuração. Se o arquivo já existir, o malware será encerrado.

show_fake_error: o malware exibe uma caixa de mensagem "System error" com a mensagem "The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem."

Na próxima etapa, o CastleBot reúne informações sobre o host infectado para se registrar no servidor C2 e solicitar tarefas.

• Nome de usuário via GetUserNameW
• Nome NetBIOS via GetComputerNameW
• Arquitetura do sistema via IsWow64Process
• Nome de domínio DNS local, usando LsaQueryInformationPolicy para recuperar a estrutura PolicyDnsDomainInformation. O valor padrão é "WORKGROUP".
• Número de série do volume recuperado via GetVolumeInformationW. O CastleBot o utiliza para calcular uma ID de vítima única utilizando um gerador congruente linear (LCG) com um multiplicador de 0x41C64E6D e um adendo de 0x3039.
• Versão para Windows via RtlGetVersion e GetSystemMetrics(89)

As informações são compiladas no objeto abaixo, seguidas pela serialização e criptografia ChaCha:

Os valores codificados são a chave de acesso (idêntica ao Agente-Usuário da configuração), o identificador da campanha e a versão de compilação do CastleBot, que é "1.0" para a amostra analisada.

O backdoor envia os dados criptografados em uma solicitação HTTP POST para

 A resposta é um contêiner criptografado maior, que carrega as tarefas pré-configuradas do CastleBot.

O contêiner recebido do servidor C2 pela amostra do CastleBot analisada é descriptografado e desserializado em um objeto com os seguintes campos:

O campo "tasks" é um tipo personalizado de matriz conforme detalhado acima, contendo pelo menos uma matriz sem nome (nome de comprimento zero), cada uma representando uma tarefa. O CastleBot também pode receber uma matriz com múltiplas tarefas a serem realizadas uma após a outra. Cada tarefa contém uma ID e vários campos detalhando como a tarefa deve ser executada, que são copiados para uma estrutura de tarefa durante a desserialização.

O campo mais importante em cada tarefa é o "launch_method", que determina o tipo de carga a ser tratada pelo CastleBot.

Os outros campos podem ser utilizados para definir opções específicas para a execução da tarefa:

O CastleBot é compatível com injeção de processos simples para cargas do PE. Ele começa criando um novo processo suspenso, com base nos campos de caminho de instalação e argumento. Para trabalhar no Windows 11 24H2 e posterior, os desenvolvedores de malware optaram por fisgar a função NtManageHotPatch da NTDLL na memória para ignorar a verificação de memória recém-adicionada. Consulte o post de Hasherezade para mais detalhes, que também fornece a implementação exata de POC usada pelo CastleBot:

O restante da injeção do processo segue técnicas comuns de injeção, alocando memória no processo de destino, gravando as seções no buffer e modificando o contexto do thread antes de retomar a execução.

Se o campo do método de inicialização estiver definido como "1", o CastleBot estabelece persistência criando uma tarefa agendada. Para registrar a tarefa, o malware usa a interface ITaskService COM para se conectar ao serviço Task Scheduler. Ele cria uma nova tarefa e uma ação de execução para a carga de destino, que é acionada toda vez que o usuário atual faz login (TASK_TRIGGER_LOGON).

Cada tarefa no contêiner "tasks" é tratada de forma iterativa de acordo com seus campos especificados. Após uma tarefa ser concluída sem erros, o malware relata a execução bem-sucedida por meio de uma solicitação HTTP GET para:

O X-Force observou uma variante central do CastleBot atualizada, oferecendo suporte a novos métodos de inicialização e uma opção chamada "wow64_bypass", usada para iniciar especificamente binários de sistema de 32 bits na pasta SysWOW64.

A implementação adicional de injeção de processo (método de lançamento 6) grava o componente do carregador do CastleBot (consulte a seção de análise acima), bem como a carga do PE no processo de destino. Em seguida, ele usa QueueUserAPC e ResumeThread para transferir a execução para o carregador, que carrega corretamente a carga do PE na memória e a executa.

Essa técnica usa significativamente menos chamadas de API WriteProcessMemory e fornece uma funcionalidade de carregamento mais completa a partir do stub do carregador do CastleBot.

O principal objetivo do CastleBot é permitir a implementação de cargas secundárias em máquinas vítimas. O X-Force descobriu várias cargas diferentes distribuídas pelo CastleBot, muitas vezes com múltiplas cargas em uma única campanha. As cargas variam em sofisticação, desde infostealers de commodities até backdoors mais capazes, como NetSupport ou WarmCookie, que foram vinculadas a ataques de ransomware.

De acordo com a análise e as capturas de tela da Prodaft, o framework CastleBot MaaS parece permitir que os operadores filtrem máquinas infectadas e atualizem facilmente as cargas para gerenciar várias campanhas ativas com grande flexibilidade, de acordo com a análise e as capturas de tela da Prodaft do painel C2. Com a fluidez das cargas e a capacidade do operador de adicionar várias tarefas e cargas a uma única campanha, as cadeias de infecção do CastleBot são mais complexas em comparação com os estágios de malware tradicionalmente estáticos.

O X-Force não tem nenhuma evidência de um anúncio generalizado de MaaS na dark web, o que pode indicar que o serviço atualmente é vendido apenas para um grupo privado de afiliados.

Sem identificar o malware como seu próprio framework, vários fragmentos das campanhas que levaram ao NetSupport foram relatados publicamente por outros pesquisadores em junho e julho de 2025.

A DomainTools observou páginas DocuSign falsas empregando a técnica ClickFix para executar um script malicioso do PowerShell, que por sua vez faz o download do CastleBot para implementar o NetSupport. IoCs de campanha:

A Unit42 da PaloAlto relatou atividades semelhantes com sites que imitavam o DocuSign e Okta, usando o ClickFix para implementar o CastleBot por meio dos componentes do stager e carregador iniciais. Ele contém uma análise parcial de um "carregador do NetSupport RAT", que o X-Force identifica como o framework CastleBot. IoCs de campanha:

Uma das cargas mais interessantes do CastleBot é a backdoor do WarmCookie (também conhecido como Quickbind, BadSpace). Provavelmente, faz parte de um ecossistema de crimes cibernéticos maior que permite ataques de ransomware e estava entre as famílias de malware visadas com sucesso pela polícia internacional durante a Operação Endgame em 2024. Anteriormente, o agente da ameaça Hive0137 distribuía o WarmCookie por meio de campanhas maliciosas de e-mail, embora nenhuma atividade significativa tenha sido observada em 2025, de acordo com a visibilidade do X-Force. O WarmCookie está publicamente vinculado às operações do TA866/Asylum Ambuscade.

A campanha que o X-Force observou começou em junho com um arquivo ZIP armamentizado imitando um instalador de um software legítimo SSMS-20.2-enu.zip (4766f5cc6501fc40c7151a0ce1c9d2cc49fca9b0b9cab2a206dd2426947e9afe). Entre os componentes legítimos, ele contém um executável malicioso SSMS_Windows.x64.exe (05ecf871c7382b0c74e5bac267bb5d12446f52368bb1bfe5d2a4200d0f43c1d8), identificado como uma variante do Dave Loader, que descriptografa uma carga armazenada em seus recursos. Após a descriptografia, o Dave Loader injeta o backdoor do CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04), que recebe a tarefa de baixar e executar uma carga do WarmCookie (5bca7f1942e07e8c12ecd9c802ececdb96570dfaaa1f44a6753ebb9ffda0604cb4) de

O servidor WarmCook C2 está localizado em:

Uma segunda amostra encontrada no final de junho usou um executável semelhante, imitando um instalador para o software Zscaler Zscaler-Windows-4.4.0.379-instalador-x64.exe (bf21161c808ae74bf08e8d7f83334ba926ffa0bab96ccac42dde418270387890). O binário compilado pelo AutoIt é um carregador de shellcode simples, executando o stager incorporado do CastleBot, que por sua vez, faz o download do mesmo binário backdoor do CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

Execuções em área de testes da amostra principal do CastleBot indicam que o mesmo afiliado pode ter descartado uma carga StealC com um servidor C2 em "http://107.158.128[.]105/c91252f9ab114f26.php" durante a campanha; no entanto, o X-Force não conseguiu recuperar uma amostra. 

Ambas as campanhas utilizam a ID de campanha do CastleBot “81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3“.

Além disso, o X-Force está rastreando várias campanhas do CastleBot entregando vários infostealers. O malware é compatível com várias tarefas de download para qualquer campanha, o que resultará na implementação de várias cargas no mesmo cliente. O executável AMD_Chipset_DriverOnly_DCH_AMD_Z_V1.2.0.105_20238.exe (e6aab1b6a150ee3cbc721ac2575c57309f307f69cd1b478d494c25cde0baaf85) carrega a carga do núcleo do CastleBot incorporado (b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2) de seu recurso e a executa. O endpoint de configurações do servidor C2 está localizado em

que transmitiu um total de três tarefas separadas em uma única mensagem C2, cada uma implementando uma carga útil diferente:

• ID da tarefa: 0x16
• • URL de download: https[:]//google.herionhelpline[.]com/app/AcerUSBUpdate.exe
  • Carga: 03122e46a3e48141553e7567c659642b1938b2d3641432f916375c163df819c1 (Rhadamanthys)
  • Caminho de instalação: nenhum
  • Método de lançamento: 6

• ID da tarefa: 0x17 
• • URL de download: https[:]//google.herionhelpline[.]com/app/light1_v5_signed.html
  • Carga: 12de997634859d1f93273e552dec855bfae440dcf11159ada19ca0ae13d53dff (Remcos)
  • Caminho de instalação: %ProgramData%\AmazonApp\AmazonWebServiceUpdate.exe
  • Método de lançamento: 1

• ID da tarefa: 0x18
• • https[:]//google.herionhelpline[.]com/app/SlackUpdateWeb.html
  • Carga: c8f95f436c1f618a8ef5c490555c6a1380d018f44e1644837f19cb71f6584a8a (DeerStealer)
  • Caminho de instalação: %AppData%\SlackUpdate\SlackServiceUpdate.exe
  • Método de lançamento: 1

O X-Force descobriu ainda mais campanhas implementando o SecTopRAT (também conhecido como ArechClient), HijackLoader (também conhecido como Shadowladder) e MonsterV2 (também conhecido como Aurotun Stealer). 

SecTopRAT e HijackLoader:

• GlobalProtect-win-6.3.zip com sideloading executável msvcp140.dll (8bf93cef46fda2bdb9d2a426fbcd35ffedea9ed9bd97bf78cc51282bd1fb2095)
• Servidor C2 do CastleBot: http[:]//107.158.128[.]45/service/settings/81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3
• Carga hospedada em http[:]//107.158.128[.]45/service/download/Exchanger32.zip (4834bc71fc5d3729ad5280e44a13e9627e3a82fd4db1bb992fa8ae52602825c6)

MonsterV2:

• DLL libssl-1_1.dll (53dddae886017fbfbb43ef236996b9a4d9fb670833dfa0c3eac982815dc8d2a5) sideloaded, injeta refletivamente o stager do fora do CastleBot
• Servidor C2 do CastleBot: http[:]//107.158.128[.]45/service/settings/8306a6b35d4be6de72be58860791e3644468fd67f675e4045a246dd27fa5692c
• Carga hospedada em http[:]//107.158.128[.]45/service/download/CCver_Setup.exe (ab725f5ab19eec691b66c37c715abd0e9ab44556708094a911b84987d700aa62)

O CastleBot é a evidência mais recente de uma mudança nos vetores iniciais de infecção do cenário de ameaças do crime cibernético. Backdoors e frameworks MaaS são cada vez mais distribuídos por meio de sites falsos como parte de softwares trojanizados ou por meio da técnica ClickFix. Em poucos meses desde a observação de um aumento na atividade do CastleBot, os desenvolvedores já adicionaram várias novas funcionalidades e provavelmente tentarão manter-se atualizados com a adaptação das soluções de EDR e segurança de rede. A atividade atual sugere que várias afiliadas utilizam o CastleBot para implementar tanto infostealers quanto backdoors, o que pode levar a incidentes de ransomware de alto impacto.

Os defensores são aconselhados a permanecer vigilantes com as técnicas mencionadas neste relatório e tomar as medidas apropriadas para mitigar o risco de uma infecção pelo CastleBot.

• Garanta que o software EDR e os controles de segurança associados estejam atualizados
• Treine os usuários para terem cuidado extremo ao fazerem download de software e evitarem instalar software não autorizado ou não verificado
• Implemente autenticação multifatorial e monitore as credenciais corporativas vazadas
• Configure alertas ou considere bloquear conexões HTTP de saída (não HTTPS) e URLs contendo endereços IP em particular

O IBM X-Force Premier Threat Intelligence agora está integrado ao OpenCTI pela Filigran, fornecendo inteligência de ameaças praticável sobre essa atividade de ameaças e muito mais. Acesse insights sobre agentes de ameaças, malware e riscos do setor. Instale o X-Force OpenCTI Connector para aprimorar a detecção e a resposta, fortalecendo sua cibersegurança com a experiência do IBM X-Force. Obtenha hoje mesmo uma avaliação de 30 dias do X-Force Premier Threat Intelligence!