The Russian state-linked hacking group
Turla
has upgraded its custom backdoor Kazuar into a modular peer-to-peer (P2P) botnet designed for stealth and long-term access to compromised systems.
According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), Turla is believed to be connected to Center 16 of Russia’s Federal Security Service (FSB). The group is also known by various aliases in the cybersecurity community, including ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard (previously Krypton), Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug, and WRAITH.
Turla primarily targets government, diplomatic, and defense organizations in Europe and Central Asia. It has also been observed exploiting systems previously compromised by Aqua Blizzard (also known as Actinium and Gamaredon) to further the Kremlin’s strategic goals.
“This enhancement supports Secret Blizzard’s overarching goal of maintaining long-term access to systems for intelligence gathering,” the Microsoft Threat Intelligence team
stated
in a report released Thursday. “While many threat actors increasingly use native tools (living-off-the-land binaries, or LOLBins) to evade detection, Kazuar’s evolution into a modular bot demonstrates how Secret Blizzard is building resilience and stealth directly into their tools.”
Kazuar is a key component of Turla’s toolkit. This
advanced .NET backdoor
has been actively used since 2017. Microsoft’s recent analysis tracks its development from a “monolithic” framework into a modular bot ecosystem composed of three distinct component types, each with specific functions. These updates allow for flexible configuration, a smaller observable footprint, and a wider range of tasks.
 |
| Overview of Kernel, Bridge, and Worker module interactions |
Attacks deploying the malware have been seen using droppers like Pelmeni and ShadowLoader to decrypt and execute the modules. The three core module types that form Kazuar’s architecture are:
-
Kernel
: Serves as the central coordinator for the botnet. It assigns tasks to Worker modules, manages communication with the Bridge module, logs actions and collected data, performs anti-analysis and sandbox checks, and configures the environment. Its settings cover command-and-control (C2) communication, data exfiltration timing, task management, file scanning/collection, and monitoring. -
Bridge
: Functions as a proxy between the leader Kernel module and the C2 server. -
Worker
: Logs keystrokes, hooks Windows events, tracks tasks, and collects system information, file listings, and Messaging Application Programming Interface (
MAPI
) details.
The Kernel module uses three internal communication methods (Windows Messaging, Mailslot, and named pipes) and three ways to contact attacker-controlled servers (Exchange Web Services, HTTP, and WebSockets). It also “elects” a single Kernel leader to communicate with the Bridge module for all other Kernel modules.
 |
| How the Kernel leader coordinates Worker tasking and uses the Bridge |
“Elections occur over Mailslot, and the leader is chosen based on the amount of work (how long the Kernel module has been running) divided by interrupts (reboots, logoffs, process termination),” Microsoft explained. “Once elected, the leader announces itself and instructs all other Kernel modules to enter SILENT mode. Only the elected leader remains active, allowing it to log activity and request tasks through the Bridge module.”
Another function of the module is to start various threads to create a named pipe channel for communication between Kernel modules, select an external communication method, and enable Kernel-to-Worker and Kernel-to-Bridge communication via Windows messaging or Mailslot.
The Kernel’s primary role is to fetch new tasks from the C2 server, interpret incoming messages, assign tasks to the Worker, update configurations, and send task results back to the server. It also includes a task handler to process commands issued by the Kernel leader.
Data gathered by the Worker module is then compiled, encrypted, and saved to the malware’s working directory, from which it is exfiltrated to the C2 server.
“Kazuar uses a dedicated working directory as a centralized on-disk staging area to support its operations across all modules,” Microsoft said. “This directory is specified in the configuration and consistently accessed using fully qualified paths to prevent confusion across different execution contexts.”
“Within this directory, Kazuar organizes data by purpose, separating tasking, collected output, logs, and configuration files into distinct locations. This structure allows the malware to separate task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activities between modules while minimizing direct contact with external infrastructure.”
