Russian state-sponsored hackers **Turla** (also known as Secret Blizzard) have significantly enhanced their **Kazuar** backdoor, turning it into a sophisticated, modular botnet designed for stealth and persistence. **Turla's** Ties to the FSB According to the U.S. Cybersecurity and Infrastructure Security Agency (**CISA**), **Turla** is affiliated with Center 16 of Russia's Federal Security Service (**FSB**). The group is tracked under various names, including ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard, Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug, and WRAITH. Known for targeting government, diplomatic, and defense sectors in Europe and Central Asia, **Turla** also targets endpoints previously breached by Aqua Blizzard (aka Actinium and Gamaredon) to further strategic objectives.  ### Kazuar's Transformation The **Microsoft** Threat Intelligence team noted that this upgrade reflects Secret Blizzard's aim to maintain long-term system access for intelligence collection. Instead of relying on native tools to evade detection, **Turla** is embedding resilience and stealth directly into their tooling. **Kazuar**, a .NET backdoor active since 2017, has evolved from a monolithic framework to a modular bot ecosystem. This new architecture features three distinct component types: * Kernel * Bridge * Worker Each module has a specific role, enabling flexible configuration, reducing the observable footprint, and streamlining task execution.  _Overview of Kernel, Bridge, and Worker module interactions_ ### Module Functions Malware distribution relies on droppers like Pelmeni and ShadowLoader to decrypt and launch the modules. The core functions of each module are: * **Kernel**: The central coordinator, issuing tasks to Worker modules, managing communication with the Bridge, maintaining logs, performing anti-analysis and sandbox checks, and configuring the environment. Configuration includes parameters for command-and-control (C2) communication, data exfiltration timing, task management, file scanning, collection, and monitoring. * **Bridge**: Acts as a proxy between the Kernel and the C2 server. * **Worker**: Logs keystrokes, hooks **Windows** events, tracks tasks, and gathers system information, file listings, and Messaging Application Programming Interface (**MAPI**) details. The Kernel module uses Windows Messaging, Mailslot, and named pipes for internal communication, and Exchange Web Services, HTTP, and WebSockets for external communication. A single Kernel leader is elected to communicate with the Bridge module.  _How the Kernel leader coordinates Worker tasking and uses the Bridge_ ### Election and Communication Kernel leader elections occur over Mailslot, based on uptime divided by interrupts. The elected leader announces itself, directing other Kernel modules to enter a silent mode. This allows the leader Kernel module to log activity and request tasks through the Bridge module. The module also sets up a named pipe channel between Kernel modules and facilitates Kernel-to-Worker and Kernel-to-Bridge communication over Windows messaging or Mailslot. The Kernel polls new tasks from the C2 server, parses messages, assigns tasks to the Worker, updates configuration, and sends task results back to the server. A task handler processes commands issued by the Kernel leader. Data collected by the Worker is aggregated, encrypted, and written to a working directory before being exfiltrated to the C2 server. ### Organized Data Handling **Kazuar** uses a dedicated working directory as a centralized staging area for its internal operations. This directory is defined through configuration and uses fully qualified paths to avoid ambiguity. Within the working directory, **Kazuar** organizes data by function, isolating tasking, collection output, logs, and configuration material. This design decouples task execution from data storage and exfiltration, maintains operational state across restarts, and coordinates asynchronous activity between modules while minimizing direct interaction with external infrastructure.