Hackers patrocinados pelo estado russo **Turla** (também conhecido como Secret Blizzard) aprimoraram significativamente sua backdoor **Kazuar**, transformando-a em uma botnet modular sofisticada, projetada para discrição e persistência. **Vínculos da Turla com o FSB** De acordo com a Agência de Segurança de Infraestrutura Cibernética dos EUA (**CISA**), a **Turla** é afiliada ao Centro 16 do Serviço Federal de Segurança da Rússia (**FSB**). O grupo é rastreado sob vários nomes, incluindo ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard, Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug e WRAITH. Conhecida por atacar os setores governamental, diplomático e de defesa na Europa e Ásia Central, a **Turla** também ataca endpoints previamente invadidos pelo Aqua Blizzard (também conhecido como Actinium e Gamaredon) para atingir objetivos estratégicos.  ### Transformação do Kazuar A equipe de Inteligência de Ameaças da **Microsoft** observou que este aprimoramento reflete o objetivo do Secret Blizzard de manter acesso de longo prazo aos sistemas para coleta de inteligência. Em vez de depender de ferramentas nativas para evadir a detecção, a **Turla** está incorporando resiliência e discrição diretamente em suas ferramentas. O **Kazuar**, uma backdoor escrita em .NET ativa desde 2017, evoluiu de uma estrutura monolítica para um ecossistema de bot modular. Esta nova arquitetura apresenta três tipos distintos de componentes: * Kernel * Bridge * Worker Cada módulo tem uma função específica, permitindo configuração flexível, redução da pegada observável e otimização da execução de tarefas.  _Visão geral das interações dos módulos Kernel, Bridge e Worker_ ### Funções dos Módulos A distribuição do malware depende de droppers como Pelmeni e ShadowLoader para descriptografar e executar os módulos. As funções principais de cada módulo são: * **Kernel**: O coordenador central, emitindo tarefas para os módulos Worker, gerenciando a comunicação com o Bridge, mantendo logs, realizando verificações anti-análise e de sandbox, e configurando o ambiente. A configuração inclui parâmetros para comunicação command-and-control (C2), tempo de exfiltração de dados, gerenciamento de tarefas, escaneamento de arquivos, coleta e monitoramento. * **Bridge**: Atua como um proxy entre o Kernel e o servidor C2. * **Worker**: Registra pressionamentos de teclas, intercepta eventos do **Windows**, rastreia tarefas e coleta informações do sistema, listas de arquivos e detalhes da Messaging Application Programming Interface (**MAPI**). O módulo Kernel usa Windows Messaging, Mailslot e named pipes para comunicação interna, e Exchange Web Services, HTTP e WebSockets para comunicação externa. Um único líder Kernel é eleito para se comunicar com o módulo Bridge.  _Como o líder Kernel coordena a atribuição de tarefas do Worker e utiliza o Bridge_ ### Eleição e Comunicação As eleições de líder Kernel ocorrem via Mailslot, com base no tempo de atividade dividido por interrupções. O líder eleito se anuncia, direcionando outros módulos Kernel a entrarem em modo silencioso. Isso permite que o módulo Kernel líder registre atividades e solicite tarefas através do módulo Bridge. O módulo também configura um canal de named pipe entre os módulos Kernel e facilita a comunicação Kernel-para-Worker e Kernel-para-Bridge via Windows messaging ou Mailslot. O Kernel consulta novas tarefas do servidor C2, analisa mensagens, atribui tarefas ao Worker, atualiza a configuração e envia os resultados das tarefas de volta para o servidor. Um manipulador de tarefas processa os comandos emitidos pelo líder Kernel. Os dados coletados pelo Worker são agregados, criptografados e gravados em um diretório de trabalho antes de serem exfiltrados para o servidor C2. ### Manuseio Organizado de Dados O **Kazuar** utiliza um diretório de trabalho dedicado como área de staging centralizada para suas operações internas. Este diretório é definido através da configuração e usa caminhos totalmente qualificados para evitar ambiguidades. Dentro do diretório de trabalho, o **Kazuar** organiza os dados por função, isolando tarefas, resultados de coleta, logs e material de configuração. Este design desacopla a execução de tarefas do armazenamento e exfiltração de dados, mantém o estado operacional entre reinícios e coordena a atividade assíncrona entre os módulos, minimizando a interação direta com a infraestrutura externa.