Turla transforma o backdoor Kazuar em botnet modular ponto a ponto para acesso persistente

A evolução do Kazuar separa coordenação, proxy e coleta em módulos distintos, reduzindo exposição de infraestrutura e ampliando persistência em ambientes Windows comprometidos.

Componente	Backdoor .NET Kazuar, usado pelo Turla/Secret Blizzard desde 2017 e agora reorganizado em módulos Kernel, Bridge e Worker.
Vetor	Execução de módulos por droppers como Pelmeni e ShadowLoader, que descriptografam e iniciam componentes do malware em sistemas Windows já comprometidos.
Impacto	Acesso persistente para coleta de inteligência, captura de teclas, inventário de arquivos, dados de sistema, detalhes de MAPI, comunicação interna entre módulos e exfiltração assíncrona para infraestrutura de comando e controle.
Prioridade	Caçar sinais de comunicação por Windows Messaging, Mailslot, named pipes, Exchange Web Services, HTTP e WebSockets, além de diretórios de trabalho usados como área de preparação em disco.
Artefatos	Módulos Kernel, Bridge e Worker; droppers Pelmeni e ShadowLoader; canais internos por Windows Messaging, Mailslot e named pipes; canais externos por Exchange Web Services, HTTP e WebSockets.
Mitigação	Isolar hosts com sinais compatíveis, preservar artefatos de diretório de trabalho, revisar persistência e execução de processos .NET, bloquear comunicação suspeita por EWS/HTTP/WebSockets e validar exposição de contas, correio e arquivos coletáveis.

Resumo técnico

O Turla, também rastreado por nomes como Secret Blizzard, Snake, Uroburos, Waterbug e Venomous Bear, passou a operar o Kazuar como um ecossistema modular com comportamento de botnet ponto a ponto. A mudança é relevante porque o backdoor deixa de depender de um único bloco funcional e passa a distribuir responsabilidades entre componentes com papéis definidos. O objetivo operacional permanece o acesso de longo prazo para coleta de inteligência, mas a arquitetura reduz o volume de sinais externos, melhora a continuidade após reinicializações ou encerramentos de processo e permite que tarefas sejam processadas por módulos locais antes de qualquer exfiltração direta.

O Kazuar é um backdoor .NET conhecido desde 2017 e associado a operações contra setores governamentais, diplomáticos e de defesa, especialmente na Europa e na Ásia Central. A versão descrita no contexto técnico separa coordenação, intermediação e execução em três tipos de módulo: Kernel, Bridge e Worker. Essa divisão permite que apenas um módulo Kernel líder fale com o Bridge, enquanto outros componentes ficam em modo silencioso. Na prática, essa escolha diminui ruído, centraliza logs e tarefas, e preserva a capacidade de operação mesmo quando há interrupções locais, como reinicialização, logoff ou término de processo.

Fluxo técnico

A cadeia começa com droppers como Pelmeni e ShadowLoader, responsáveis por descriptografar e iniciar os módulos do Kazuar. O papel desses carregadores é importante para a análise defensiva porque eles separam a etapa de implantação da lógica principal do backdoor. Em vez de entregar um binário monolítico que concentra comunicação, coleta e controle, a operação coloca módulos especializados em execução e os coordena por mecanismos nativos do Windows. Isso dificulta uma leitura linear do incidente, pois um host pode exibir apenas parte do comportamento total em determinado momento.

O módulo Kernel atua como coordenador central. Ele expõe mecanismos internos de comunicação por Windows Messaging, Mailslot e named pipes, além de selecionar métodos externos de contato com infraestrutura controlada pelo operador por Exchange Web Services, HTTP e WebSockets. Entre múltiplos módulos Kernel, ocorre uma eleição de liderança sobre Mailslot. O critério descrito usa a quantidade de trabalho, representada pelo tempo de execução do módulo, dividida por interrupções como reinicialização, logoff ou encerramento do processo. Depois da eleição, o líder anuncia seu papel e instrui os demais módulos Kernel a operar em modo SILENT, deixando apenas o líder responsável por registrar atividade e requisitar tarefas por meio do Bridge.

O Bridge funciona como proxy entre o Kernel líder e o servidor de comando e controle. Essa separação limita a quantidade de componentes que precisam se comunicar diretamente com infraestrutura externa e cria uma camada de intermediação entre tasking local e tráfego de rede. O Kernel consulta novas tarefas, interpreta mensagens recebidas, atualiza configuração, encaminha comandos para módulos Worker e envia resultados de volta ao servidor. O fluxo também inclui um manipulador de tarefas capaz de processar comandos emitidos pelo Kernel líder, o que reforça o desenho de botnet modular com coordenação local e execução distribuída.

O Worker concentra a coleta. Suas funções incluem registro de teclas, hooks de eventos do Windows, rastreamento de tarefas, coleta de informações do sistema, enumeração de arquivos e obtenção de detalhes de MAPI. Os dados reunidos são agregados, criptografados e gravados no diretório de trabalho do malware antes da exfiltração. Esse diretório é definido por configuração e referenciado por caminhos totalmente qualificados, reduzindo ambiguidade entre contextos de execução. A organização por função separa tarefas, saídas de coleta, logs e material de configuração, permitindo persistência de estado entre reinicializações e coordenação assíncrona entre módulos.

Superficie afetada

A superfície primária é composta por endpoints Windows nos quais um dropper consiga executar e iniciar módulos .NET do Kazuar. O contexto não descreve o vetor inicial de comprometimento, portanto a exposição deve ser tratada como pós-intrusão: o risco existe quando o adversário já obteve capacidade de execução no host ou em um ponto da cadeia de implantação. Ambientes com contas de correio acessíveis por Exchange Web Services, uso de MAPI, grande volume de arquivos sensíveis em estáções de trabalho e baixa visibilidade sobre named pipes e Mailslot têm maior dificuldade para distinguir atividade legítima de coordenação maliciosa.

A arquitetura também amplia a superfície de detecção para além de rede. Como a comunicação entre módulos ocorre por IPC local e a exfiltração depende de uma área de preparação em disco, sinais podem aparecer em telemetria de processo, sistema de arquivos, eventos de mensagens do Windows, criação de canais nomeados e acesso a componentes de correio. A presença de apenas um Kernel líder se comunicando com o Bridge significa que a ausência de múltiplas conexões externas não reduz o risco; módulos silenciosos podem permanecer ativos localmente, aguardando tarefas ou mantendo estado operacional.

• Endpoints Windows com execução de módulos .NET e sinais de droppers Pelmeni ou ShadowLoader.
• Hosts com comunicação interna por Mailslot, named pipes ou Windows Messaging associada a processos incomuns.
• Contas e clientes com acesso a Exchange Web Services ou dados consultáveis por MAPI.
• Diretórios de trabalho configurados pelo malware com subáreas para tarefas, logs, configuração e saída de coleta.

Hunting e telemetria

A caça deve começar pela correlação entre execução de carregadores, processos .NET incomuns e criação de canais locais de comunicação. Como a arquitetura depende de eleição de liderança por Mailslot, named pipes entre módulos e troca de mensagens via Windows, a telemetria de endpoint precisa capturar criação de IPC, árvore de processos, módulos carregados, caminhos de execução e escrita em diretórios de trabalho persistentes. A investigação não deve depender somente de conexões externas, pois a maior parte da coordenação pode ocorrer localmente até que o Kernel líder encaminhe tarefas ao Bridge.

No tráfego de rede, os pontos de atenção são conexões compatíveis com Exchange Web Services, HTTP e WebSockets feitas por processos que não deveriam atuar como clientes desses protocolos. A análise deve considerar horários de beaconing, volumes pequenos e repetitivos, uso de proxy, destino recorrente e mudanças de método externo definidas por configuração. Em disco, a busca deve priorizar diretórios que concentrem arquivos criptografados, logs, resultados de coleta, material de configuração e saídas separadas por função. Em identidade e correio, acessos anômalos a recursos MAPI e EWS por estáções de trabalho comprometidas podem indicar coleta ou canal de comunicação.

• Criação ou uso incomum de Mailslot, named pipes e mensagens do Windows por processos sem justificativa operacional.
• Processos .NET lançados por carregadores ou executáveis temporários, especialmente com escrita recorrente em diretórios de preparação.
• Conexões de processos não usuais para Exchange Web Services, HTTP ou WebSockets com periodicidade ou destino persistente.
• Arquivos criptografados ou agrupados por função contendo tarefas, logs, configuração e resultados de coleta.
• Eventos de keylogging, hooks de eventos do Windows, enumeração ampla de arquivos e consulta a informações de sistema ou MAPI.

Mitigação

A resposta deve tratar o caso como comprometimento persistente com componentes cooperando entre si. O primeiro passo é isolar sistemas com sinais de Kazuar, preservar memória, processos, diretórios de trabalho e artefatos de IPC, e só então remover componentes. Encerrar apenas um processo pode disparar nova eleição ou deixar módulos remanescentes operando em modo silencioso. A análise forense deve reconstruir quais módulos estavam presentes, qual Kernel atuava como líder, se havia Bridge ativo, quais tarefas foram processadas por Worker e quais dados foram preparados para exfiltração.

A contenção precisa combinar endpoint, rede e identidade. Em endpoint, revisar persistência, execução de binários .NET, carregadores, diretórios configurados e permissões locais. Em rede, bloquear ou inspecionar comunicação suspeita por EWS, HTTP e WebSockets, com atenção a processos sem necessidade legítima desses protocolos. Em identidade, revisar contas com acesso a correio, eventos MAPI, sessões anômalas e possíveis credenciais expostas por keylogging. Como o contexto não fornece hashes, domínios ou endereços IP, a mitigação deve priorizar comportamento e telemetria em vez de listas estáticas de indicadores.

• Isolar hosts suspeitos e preservar imagem de memória, árvore de processos, diretórios de trabalho e artefatos de comunicação local.
• Procurar e remover droppers Pelmeni e ShadowLoader somente depois de coletar evidências para entender o fluxo de execução.
• Bloquear tráfego EWS, HTTP e WebSockets anômalo por processo e revisar regras de proxy, inspeção TLS e logs de saída.
• Revisar contas de correio, acessos MAPI, sessões EWS e credenciais que possam ter sido capturadas por keylogging.
• Validar que não restaram módulos Kernel, Bridge ou Worker ativos, em modo silencioso ou aguardando tarefas em diretórios persistentes.