Cereal: como o grupo Turla se esconde em servidores Microsoft Exchange

Em um servidor Exchange comprometido, a atividade mais relevante nem sempre é aquela que chega à caixa de entrada do usuário. Imagine a seguinte situação: em um órgão governamental, um funcionário envia um e-mail a um colega de um país integrante de uma aliança militar transnacional. A mensagem passa por um servidor Microsoft Exchange e segue seu fluxo normal, sem levantar suspeitas. Mas, antes de deixar a rede da organização, um trecho de código a analisa silenciosamente, identifica seu conteúdo como relevante e separa uma cópia para encaminhá-la a terceiros. Enquanto isso, o e-mail original chega normalmente ao destinatário.

Foi nesse contexto que, em 28 de novembro de 2025, identificamos um conjunto de ferramentas instalado em um servidor Exchange de um órgão governamental no Cazaquistão. O que inicialmente parecia ser um conjunto de componentes suspeitos e sem relação aparente revelou um conjunto de ferramentas até então não documentado: uma coleção modular de malwares desenvolvidos com .NET, projetada para operar em servidores Microsoft Exchange. As ferramentas permitem receber comandos e executá-los diretamente na memória, mapear a estrutura da organização comprometida e coletar mensagens de e-mail específicas.

Após aprimorarmos nossas detecções, identificamos o mesmo conjunto de ferramentas em uma organização governamental na Romênia, comprometida em 23 de dezembro de 2025. Nesse segundo caso, a configuração buscava identificar mensagens enviadas para ou recebidas da Organização do Tratado do Atlântico Norte (OTAN) e da União Europeia (UE).

Como as ferramentas utilizam amplamente a serialização, técnica que permite empacotar dados e código para transporte, adotamos nomes iniciados pelo prefixo "Cereal" para identificá-las. O conjunto se destaca pela combinação de técnicas inéditas, que demonstram um conhecimento aprofundado do funcionamento interno do Exchange, e métodos pouco convencionais de execução de código em .NET.

Outro aspecto chama a atenção: a ausência de uma infraestrutura externa de comando e controle (C&C). Em vez de depender de servidores externos, os operadores transformam o próprio servidor Exchange comprometido em parte da infraestrutura de C&C. Dessa forma, a comunicação e a execução de comandos ocorrem por meio de um ambiente legítimo da organização, o que dificulta a identificação da atividade maliciosa.

Atribuímos o Cereal, com alto grau de confiança, ao grupo de ciberespionagem APT Turla, alinhado à Rússia. Essa avaliação se baseia no uso simultâneo de outro componente publicamente associado ao grupo e em semelhanças conceituais com ferramentas utilizadas pelo Turla em campanhas anteriores.

A análise técnica completa, incluindo os detalhes sobre o funcionamento e os recursos desse conjunto de ferramentas, está disponível em nosso white paper.

Principais pontos deste post:

Observamos inicialmente um conjunto de ferramentas não documentado em um órgão governamental no Cazaquistão. Depois de aprimorarmos a detecção dessas ferramentas em nosso produto, identificamos, um mês depois, outro órgão governamental comprometido na Romênia.

Identificamos um conjunto de ferramentas sofisticado, modular e fortemente interligado, projetado para funcionar em servidores Exchange de instituições comprometidas e sustentar ciberespionagem de longo prazo.

Não foi observada nenhuma infraestrutura de rede externa. Um dos componentes maliciosos, um backdoor passivo executado nos servidores Exchange, dá acesso à rede interna.

Os comandos são enviados pelos operadores na forma de executáveis separados, com uma estrutura semelhante e personalizada. Isso indica a existência de um framework que automatiza a compilação e a entrega dos comandos.

Um módulo automatizado de coleta de e-mails, injetado em processos legítimos do Microsoft Exchange, acessa e manipula o pipeline de transporte de e-mails. Isso exige um entendimento profundo do funcionamento interno do Microsoft Exchange e é uma técnica inédita.

O uso de diversos truques de .NET, como pontos de entrada não gerenciados e a exploração do cache de imagens nativas do .NET, torna esse conjunto de ferramentas bastante sofisticado em comparação com a maioria dos casos recentes de APT que pesquisamos.

Vítimas e contexto geopolítico

O Turla, também conhecido como Snake, atua desde pelo menos 2004 e é amplamente considerado parte do Serviço Federal de Segurança (FSB) da Rússia. Seus alvos habituais são governos, missões diplomáticas e organizações de defesa, principalmente na Europa, na Ásia Central e no Oriente Médio. Documentamos boa parte do arsenal do Turla no WeLiveSecurity. Em 2025, também relatamos uma cooperação incomum entre o Turla e o Gamaredon, em nosso post Gamaredon X Turla collab e em nosso white paper Gamaredon in 2025: Leveraging tunnels, workers, dead drops, and new alliances.

O conjunto de ferramentas do Cereal demonstra a capacidade do Turla de realizar uma intrusão lenta, cuidadosa e de longo prazo, construída em torno de servidores Microsoft Exchange.

Identificamos duas organizações governamentais nacionais comprometidas pelo Cereal, em regiões que coincidem, em grande medida, com as áreas de atuação conhecidas do Turla. Segundo a telemetria da ESET, cerca de 70% dos países visados pelo Turla desde 2022 são ex-repúblicas soviéticas ou países europeus que mantiveram estreitos vínculos com a antiga União Soviética. A distribuição geográfica dos dois comprometimentos confirmados é mostrada na Figura 1.

figure-1-pt — **Figura 1.** Países e setores nos quais identificamos comprometimentos pelo conjunto de ferramentas Cereal do Turla.

O caso da Romênia chama atenção porque um dos componentes, o CerealBox, foi configurado para coletar mensagens envolvendo endereços institucionais da OTAN e da UE. Esse foco combina com prioridades antigas da inteligência russa. Pode estar ligado também às tensões na região: desde o início de 2025, a Romênia relatou vários incidentes envolvendo drones russos que caíram perto de seu território ou dentro dele, o que gerou reações firmes das autoridades romenas e pedidos por uma missão da OTAN na região do Mar Negro.

O comprometimento no Cazaquistão também ocorreu em um contexto político relevante. Desde janeiro de 2026, o país teria começado a deportar alguns exilados russos e críticos do regime que antes haviam encontrado ali uma segurança relativa, depois da invasão em larga escala da Ucrânia pela Rússia. Comprometer um órgão governamental cazaque se encaixa em um cenário em que os operadores querem ter visibilidade sobre dissidentes russos conhecidos das autoridades do Cazaquistão, mas que ainda não constam de nenhuma lista de deportação.

Há mais um detalhe que merece registro. A atividade no Cazaquistão disparou em 15 de janeiro de 2026, um dia depois do Velho Ano Novo, feriado informal que ainda é comemorado na Rússia e em alguns países vizinhos. O malware não comemora feriados, mas seus operadores, sim.

Seguindo as migalhas do Cereal

Os primeiros componentes que encontramos não lembravam um backdoor clássico. Não havia um implante monolítico óbvio, nem uma lista de comandos embutida, nem um padrão simples de beaconing. Em vez disso, a atividade surgia como uma cadeia de componentes especializados: payloads criptografados no disco, assemblies .NET embutidos em outros assemblies .NET, processos legítimos do Windows carregando DLLs suspeitas e serviços do Exchange executando código que não deveria estar ali.

A reconstrução dessa cadeia revelou um conjunto de ferramentas modular, construído em torno de alguns princípios de projeto recorrentes: manter os payloads criptografados, manter a execução na memória sempre que possível, reaproveitar o servidor Exchange comprometido e entregar os comandos como assemblies .NET separados. A Figura 2 mostra as relações entre todos os componentes observados do conjunto de ferramentas.

figure-2-1-pt — **Figura 2.** Componentes usados nos ataques observados.

Os principais componentes são:

CerealLoader, que carrega e executa um assembly .NET a partir de um arquivo criptografado no disco. É o único componente do conjunto de ferramentas gravado no disco como um arquivo .NET reconhecível. Todo o resto é entregue dentro de contêineres criptografados, descompactado em tempo de execução e executado a partir da memória.
CerealRunner, que contém outros binários criptografados que são carregados e executados. Ele oferece uma forma de encapsular e entregar comandos, além de outros componentes.
CerealSprinter, semelhante ao CerealRunner, mas usado apenas para carregar e executar outros componentes.
CerealNeuron, um backdoor passivo sem comandos embutidos, mas capaz de executar assemblies contidos em binários do CerealRunner recebidos por requisições de rede. Demos esse nome em referência ao Neuron, uma família de malware documentada e atribuída ao Turla em 2017 pelo National Cyber Security Centre do Reino Unido, já que os dois são funcionalmente parecidos.
CerealHermit, uma variante do CerealNeuron sem funcionalidades de rede. Ele lê comandos de arquivos criptografados no disco.
CerealIron, um injetor que permite aos operadores carregar e executar assemblies .NET a partir de processos que não são .NET.
CerealBox, que processa, filtra e coleta mensagens de e-mail relevantes ao ser injetado no serviço de transporte do Microsoft Exchange.
CerealMoth, um componente simples que recebe um assembly e o nome de um método como argumentos, carrega o assembly e executa o método indicado.

Quando o Exchange da vítima vira a infraestrutura

O aspecto mais notável desta campanha é o que não encontramos: um servidor controlado pelos cibercriminosos.

A maioria dos backdoors se comunica periodicamente com seus operadores. Esse comportamento deixa rastros (domínios, endereços IP, provedores de hospedagem, padrões de horário) que os defensores identificam e bloqueiam. O CerealNeuron, o principal backdoor do conjunto Cereal, não faz nada disso. Em vez de iniciar conexões de saída, ele espera por requisições de entrada.

O CerealNeuron é executado no servidor Exchange comprometido e monitora passivamente requisições web em caminhos que se parecem com o tráfego comum do Exchange. Entre os caminhos que observamos:

https://*:443/owa/sdds/
HTTPS://*:443/AUTODISCOVER/PROXYSERVICE/
HTTPS://*:443/MICROSOFT-SERVER-ACTIVESYNC/INTEGRATED/API/

Nos registros de um firewall ou na análise do tráfego, as requisições a esses caminhos se misturam ao tráfego legítimo do Outlook Web Access, do Autodiscover e do ActiveSync. Se a requisição a um recurso em um desses caminhos estiver devidamente criptografada e passar por várias verificações de integridade, o CerealNeuron a descriptografa, trata o conteúdo como um comando e o executa. Se a requisição parecer incorreta, o CerealNeuron redireciona o cliente para uma página de erro do Exchange com aparência legítima.

As consequências são significativas:

Não há infraestrutura de C&C dedicada para descobrir, bloquear ou derrubar. O próprio servidor Exchange da vítima, exposto à internet, é o ponto de controle acessível aos operadores.
O rastreamento baseado em rede fica severamente limitado. Não conseguimos identificar os endereços IP de origem usados pelos operadores. Eles podem ter se conectado diretamente, por serviços de anonimização ou a partir de outros hosts comprometidos.
O tráfego malicioso convive com os serviços web legítimos do Exchange, exatamente o tipo de tráfego que os defensores têm menos probabilidade de bloquear.

A Figura 3 mostra o fluxo de comunicação entre os operadores e o CerealNeuron.

figure-3-1-pt — **Figura 3.** Fluxo de comunicação entre os operadores e o CerealNeuron para execução de comandos.

Abusar de um servidor Exchange comprometido como central operacional é uma técnica rara, usada por apenas um punhado de grupos APT. O Turla já usou variações dessa abordagem no passado. Com o Cereal, depender do servidor Exchange da vítima elimina a necessidade de uma infraestrutura dedicada dos cibercriminosos.

O conjunto de ferramentas também conta com um mecanismo de contingência. O CerealHermit é uma variante do CerealNeuron sem as partes de rede. Em vez de esperar por requisições web, ele lê arquivos de comando criptografados do disco e grava os resultados, também criptografados. Em algumas intrusões, os dois backdoors foram implantados juntos, o que deu aos operadores duas formas independentes de alcançar seus objetivos.

Comandos como programas descartáveis

Em vez de um único backdoor grande que contém todos os comandos possíveis, os operadores do Turla entregam cada comando em um programa .NET próprio, compilado de forma independente e com tamanho reduzido.

O principal componente de execução é o CerealRunner. Ele carrega dentro de si outros programas .NET criptografados, junto com os argumentos necessários para executá-los. Quando é executado, ele descompacta seus payloads, roda-os na memória e devolve a saída pelo mesmo pipeline, para que o CerealNeuron possa criptografá-la e enviá-la de volta.

Detectamos inúmeros binários do CerealRunner nas duas intrusões. Eles compartilham a mesma estrutura, mas diferem no pequeno trecho de código que implementa cada tarefa específica.

Os comandos incluem:

Recuperar caixas de correio ou mensagens específicas por meio do Exchange Web Services.
Consultar o Active Directory em busca de computadores, usuários, grupos e registros DNS.
Executar consultas WMI, por exemplo, para listar processos ou conexões TCP ativas.
Extrair LSA Secrets (credenciais que o Windows armazena localmente).
Listar snapshots de volume.
Listar, ler e excluir arquivos, muitas vezes os dumps de e-mail preparados pelo CerealBox.

A grande quantidade de binários quase idênticos, cada um compilado para uma tarefa específica, sugere fortemente que os operadores têm um framework interno que automatiza a compilação e o empacotamento dos comandos. Somado a uma base de código construída com componentes modulares e intercambiáveis, o que fica é a impressão de uma plataforma madura e bem projetada, e não de um amontoado de scripts soltos.

Técnicas avançadas de .NET

O que diferencia o Cereal da maioria dos casos recentes de APT é o grau de exploração dos recursos internos do .NET, o framework de software da Microsoft que sustenta boa parte do Windows e do próprio Exchange.

Normalmente, os programas .NET são executados pelo Common Language Runtime (CLR), que converte as instruções do programa em código de máquina logo antes da execução. Todo esse processo é visível para as ferramentas de análise padrão. O Cereal opera repetidamente fora desses caminhos padrão e observáveis.

Um programa .NET que executa código nativo antes de qualquer código .NET

O CerealLoader é o único componente do Cereal gravado no disco sem criptografia. Em um decompilador .NET, o código do ponto de entrada praticamente não faz nada, e um breakpoint definido no método malicioso nunca é acionado.

Na prática, o CerealLoader executa código nativo, de baixo nível, antes mesmo de o runtime do .NET começar a rodar suas instruções normais. Ele abusa de um recurso pouco usado da especificação do .NET, os Vtable Fixups, para construir uma ponte oculta do código nativo até um método .NET que nenhuma outra parte do programa parece chamar. Um analista que inspeciona apenas o lado .NET vê um código que parece não fazer nada. Nesse momento, o payload real já foi executado.

Sequestro de componentes legítimos do Windows

Como o CerealLoader consegue inicializar a si mesmo a partir de código nativo, os operadores podem colocá-lo em locais onde processos legítimos do Windows que não são .NET o carregarão. Em uma das cadeias de execução, o CerealLoader foi colocado como ncobjapi.dll dentro de C:\Windows\System32\wbem\, onde o serviço Windows Management Instrumentation o carregava automaticamente. Em outra, ele se passava por wbemcomn.dll na mesma pasta. A DLL maliciosa repassa as chamadas de função legítimas, de modo que o processo afetado continua funcionando normalmente.

Exploração do cache de imagens nativas do .NET

Para melhorar o desempenho na inicialização, o .NET mantém em uma pasta do sistema um cache com versões pré-compiladas de bibliotecas comuns. Quando um programa solicita uma dessas bibliotecas, o runtime verifica primeiro o cache e, se houver correspondência, carrega a versão em cache em vez de compilar o código do assembly com JIT. Os operadores colocaram arquivos CerealLoader maliciosos nesse cache, com nomes como Microsoft.Exchange.Search.Mdb.ni.dll. Quando o Exchange solicitava a biblioteca correspondente, o runtime carregava a versão maliciosa. Como o arquivo malicioso não contém nenhum código real de substituição, o .NET recorre silenciosamente à biblioteca original para executar as funções esperadas, mas só depois de o código do ponto de entrada nativo dos cibercriminosos ter sido executado. Em uma das amostras, o código malicioso só é ativado quando o processo pai é o serviço de pesquisa do Exchange.

Cada uma dessas técnicas está documentada em partes menos conhecidas da especificação do .NET. O incomum é vê-las combinadas de forma tão deliberada em um único conjunto de ferramentas, usadas especificamente para se esconder dentro do Microsoft Exchange.

CerealBox: interceptando o Exchange por dentro

O componente do Cereal que usa a técnica mais inédita é o CerealBox, um módulo de coleta de e-mails criado para o Microsoft Exchange.

O Turla já atacou servidores Exchange antes, inclusive por meio da exploração de agentes de transporte, um recurso legítimo do Exchange que permite aos desenvolvedores se conectar ao fluxo de e-mails para tarefas como filtragem de spam. No entanto, os agentes de transporte instalados deixam rastros visíveis na configuração do Exchange.

O CerealBox adota uma abordagem mais furtiva. Em vez de se registrar, ele é injetado diretamente no EdgeTransport.exe, o processo do Exchange que cuida do fluxo de e-mails. Chegar a esse ponto, porém, não é simples: o CerealBox é entregue por uma cadeia intrincada de componentes Cereal aninhados, ilustrada na Figura 4.

figure-4-1-pt — **Figura 4.** Cadeia de execução observada que entrega o CerealIron para executar o CerealBox.

Uma vez lá dentro, o CerealBox acessa as estruturas internas do Exchange, encontra os agentes de transporte existentes e envolve seus manipuladores com código malicioso. Os wrappers executam primeiro a lógica própria do CerealBox e depois devolvem o controle ao código original. O e-mail continua fluindo normalmente. Nenhum agente novo aparece na configuração do Exchange. O CerealBox não adiciona um novo agente: ele sequestra aqueles que já estão carregados na memória.

Com visibilidade do fluxo de e-mails, o CerealBox seleciona as mensagens de interesse. Uma mensagem é considerada relevante se tiver um anexo .doc, .docx ou .pdf e corresponder a pelo menos uma de várias listas fixas no código (endereços de remetentes, endereços de destinatários, trechos do assunto ou nomes de anexos), sem constar nas listas de exclusão. As mensagens de interesse são compactadas, criptografadas e armazenadas temporariamente em arquivos no disco. Depois, os operadores usam comandos comuns do CerealNeuron para exfiltrar e excluir esses arquivos.

Injetar código no serviço de transporte do Exchange e interceptar o fluxo de e-mails por dentro é uma técnica inédita, nunca documentada para nenhuma família de malware. Ela exige um entendimento profundo de como o pipeline de e-mails do Exchange é estruturado internamente, um tipo de conhecimento que demanda muito tempo e esforço para ser adquirido.

Um novo nível de sofisticação na ciberespionagem

O conjunto de ferramentas Cereal foi cuidadosamente desenvolvido para ciberespionagem furtiva e de longo prazo. Ele deixa pouco no disco, evita infraestrutura externa que poderia ser descoberta e bloqueada e se esconde dentro de processos legítimos do Exchange. O uso de pontos de entrada não gerenciados, VTable Fixups, exploração do cache de imagens nativas e injeção em memória no pipeline de transporte do Exchange reflete um nível de investimento em técnicas de .NET incomum até mesmo entre grupos APT sofisticados.

O conjunto de ferramentas do Cereal mostra que, para o Turla, os servidores Exchange não são apenas servidores de e-mail: funcionam como pontos permanentes de coleta de informações e centrais internas de execução e um ambiente adequado para esconder técnicas sofisticadas de .NET.