Turla Transforms Kazuar Backdoor Into Modular P2P Botnet for Persistent Access

TL;DR — Turla, a Russian state-sponsored group assessed by CISA to be affiliated with the FSB's Center 16, has evolved its Kazuar .NET backdoor from a monolithic framework into a modular peer-to-peer botnet. The redesign introduces three component types—Kernel, Bridge, and Worker—that coordinate over multiple communication channels to enable stealth, resilience, and long-term access. No CVE has been assigned; defenders should monitor for the droppers Pelmeni and ShadowLoader, which distribute Kazuar modules.

What happened

Microsoft Threat Intelligence published findings on the architectural evolution of Kazuar, a sophisticated .NET backdoor that Turla has deployed since 2017. The malware has been redesigned from a single monolithic codebase into a distributed, modular botnet with three distinct component types.

The Kernel module serves as the central coordinator. It issues tasks to Worker modules, manages communication with the Bridge module, maintains logs of actions and collected data, performs anti-analysis and sandbox detection, and configures parameters governing command-and-control communication, data exfiltration timing, task management, file scanning and collection, and monitoring. The Kernel module exposes three internal communication mechanisms—Windows Messaging, Mailslot, and named pipes—and three methods for contacting attacker infrastructure: Exchange Web Services, HTTP, and WebSockets.

The architecture includes an election mechanism to designate a single Kernel leader. Elections occur over Mailslot based on uptime divided by interrupts (reboots, logoffs, process terminations). Once elected, the leader announces itself and directs other Kernel modules into a SILENT state. Only the elected leader logs activity and requests tasks through the Bridge module.

The Bridge module acts as a proxy between the leader Kernel and the C2 server.

The Worker module collects keystrokes, hooks Windows events, tracks tasks, gathers system information, file listings, and Messaging Application Programming Interface (MAPI) details. Data collected by Workers is aggregated, encrypted, and written to a dedicated working directory before exfiltration to the C2 server. Kazuar organizes this directory by function, isolating tasking, collection output, logs, and configuration into separate locations. This design allows the malware to decouple task execution from data storage and maintain operational state across restarts.

Attacks distributing the modular Kazuar rely on droppers including Pelmeni and ShadowLoader to decrypt and launch the modules.

Why it matters

The modularization significantly reduces Kazuar's observable footprint on disk and network. By distributing functionality across Kernel, Bridge, and Worker components, Turla can deploy only the modules necessary for a given target or phase of an operation, limiting what defenders can detect. The P2P architecture and multi-channel communication (Windows Messaging, Mailslot, named pipes for internal coordination; EWS, HTTP, WebSockets for C2) create redundancy, making it harder for defenders to sever attacker control.

The design reflects a strategic shift: rather than relying solely on living-off-the-land binaries (LOLBins) to avoid detection, Turla is embedding resilience and stealth directly into its tooling. This suggests the group intends long-term access for intelligence collection against government, diplomatic, and defense targets in Europe and Central Asia.

For SOC analysts, the modular architecture means that a single compromised host may not reveal the full scope of Kazuar's presence. Worker modules may exfiltrate data to the working directory while Kernel modules coordinate silently. Defenders need to monitor for the initial dropper stage (Pelmeni, ShadowLoader) and the behavioral signatures of inter-module communication over named pipes and Mailslot.

Affected systems and CVEs

Kazuar (.NET backdoor, in use since 2017)
Pelmeni (dropper)
ShadowLoader (dropper)
Windows (target OS)
Exchange Web Services (one C2 channel)

No CVE assigned at the time of publication.

What to do

The source article does not provide patch or remediation guidance. Mitigations should focus on detection and containment:

Monitor for Pelmeni and ShadowLoader droppers in your environment.
Hunt for suspicious inter-process communication over Windows Messaging, Mailslot, and named pipes, especially patterns consistent with leader election (Mailslot traffic indicating uptime and interrupt metrics).
Inspect working directories for centralized data staging consistent with Kazuar's design.
Monitor for C2 communication over Exchange Web Services, HTTP, and WebSockets to known or suspected Turla infrastructure.
Isolate hosts showing evidence of Kernel, Bridge, or Worker module activity to prevent lateral movement and data exfiltration.
Review logs from endpoints previously compromised by Aqua Blizzard (Actinium, Gamaredon), as Turla is known to reinfect endpoints cleared by other threats.

Open questions

No CVE identifiers are provided for Kazuar or its variants.
The source does not specify which organizations or countries have been targeted by this particular modular variant.
No Indicators of Compromise (IoCs) or detection signatures are included.
The timeline of when the modularization occurred is not specified.
No specific statistics on the scale or scope of attacks using the modular Kazuar variant are provided.
Detection mechanisms specific to the new architecture are not discussed.