Turla (Secret Blizzard): affiliation and targets
The threat actor commonly known as Turla is described in public reporting as a Russian state-sponsored group. Per the U.S. Cybersecurity and Infrastructure Security Agency (CISA), Turla is assessed to be affiliated with Center 16 of Russia's Federal Security Service (FSB). Microsoft and other observers link the activity to a range of cluster names used by the community, including ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard (formerly Krypton), Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug, and WRAITH.
According to the reporting, Turla has concentrated operations against government, diplomatic, and defense targets in Europe and Central Asia, and has also used endpoints previously breached by another actor tracked as Aqua Blizzard (aka Actinium and Gamaredon) to support the Kremlin's strategic objectives. The group's work on Kazuar is presented as part of that long-term intelligence collection mission.
Kazuar's modular architecture: Kernel, Bridge, and Worker
Kazuar, a .NET backdoor in Turla's toolkit since 2017, has evolved from a single, monolithic framework into a modular, peer-to-peer botnet with three distinct component types: Kernel, Bridge, and Worker. Microsoft characterizes the redesign as enabling flexible configuration, a reduced observable footprint, and broader tasking capability.
- Kernel — the central coordinator that issues tasks to Workers, manages communication with Bridge modules, keeps logs, performs anti-analysis and sandbox checks, and establishes runtime environment parameters such as C2 communication, timing for exfiltration, task management, file scanning and collection, and monitoring.
- Bridge — a proxy between the Kernel leader and the command-and-control (C2) server.
- Worker — the data-collection engine that logs keystrokes, hooks Windows events, tracks tasks, and gathers system information, file listings, and Messaging Application Programming Interface (MAPI) details.
How the Kernel coordinates communications and leadership
The Kernel supports multiple internal communication mechanisms — Windows Messaging, Mailslot, and named pipes — and can contact attacker-controlled infrastructure by three methods: Exchange Web Services, HTTP, and WebSockets. Microsoft describes a built-in election process: Kernel modules elect a single leader over Mailslot based on a ratio of the “amount of work (length of time the Kernel module has been running) divided by interrupts (reboots, logoffs, process terminated).”
Once elected, the leader announces itself and instructs all other Kernel modules to set SILENT; only the elected leader remains active for logging and requesting tasks through the Bridge module. The Kernel also spawns threads to create named-pipe channels for inter-Kernel communications and to facilitate Kernel-to-Worker and Kernel-to-Bridge messaging via Windows Messaging or Mailslot. The Kernel's operational objective is explicit: poll the C2 for tasks, parse incoming messages, assign work to Workers, update configuration, and send task results back to the server.
Delivery chains and on-disk staging: Pelmeni, ShadowLoader, and the working directory
Microsoft's findings tie Kazuar deployments to droppers such as Pelmeni and ShadowLoader, which decrypt and launch the modules. Once active, the Worker aggregates collected data, encrypts it, and writes it into Kazuar's working directory for subsequent exfiltration to the C2 server.
Microsoft notes Kazuar uses a dedicated working directory as a centralized on-disk staging area defined through configuration and referenced with fully qualified paths to avoid ambiguity across execution contexts. Inside that directory the malware organizes information by function — isolating tasking, collection output, logs, and configuration into discrete locations. This design is intended to decouple task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure.
What this means for technologists, policymakers, and affected enterprises
- Technologists and security teams: The modular, P2P design and multiple internal/external communication channels mean defenders must look for behavioral indicators across persistence, interprocess messaging (Windows Messaging, Mailslot, named pipes), and unexpected use of Exchange Web Services, HTTP, or WebSockets for outbound tasking. The working-directory staging behavior is a concrete artifact to hunt for.
- Policymakers and regulators: CISA's assessment linking Turla to Center 16 of the FSB and Microsoft's description of the toolset underline that these capabilities are being used to pursue long-term intelligence collection, which bears on cross-border cyber policy and disclosure priorities.
- Affected enterprises and procurement leaders: The use of known droppers such as Pelmeni and ShadowLoader reinforces the value of endpoint detection on initial launcher activity and robust controls around software that can decrypt and load .NET modules; attention to interprocess communications and on-disk staging locations is likewise warranted.
Turla's rework of Kazuar into a modular P2P botnet represents an intentional shift from single-process tooling toward a resilient, stealth-oriented architecture that preserves state, decentralizes control, and separates discovery from exfiltration. Microsoft frames that shift as engineering resilience and stealth directly into the malware, rather than relying solely on living-off-the-land techniques. The technical specifics — election over Mailslot, fully qualified working-directory paths, and multiple internal and external communication methods — give defenders concrete behaviors to monitor even as they contend with a persistent, state-aligned adversary.
Source: Turla Turns Kazuar Backdoor Into Modular P2P Botnet for Persistent Access — The Hacker News
