Russian state-sponsored hacking group known as
Turla
has transformed its custom backdoor Kazuar into a modular peer-to-peer (P2P) botnet engineered for covert and persistent access to compromised hosts.
According to the US Cybersecurity and Infrastructure Security Agency (CISA), Turla is believed to be affiliated with Center 16 of Russia’s Federal Security Service (FSB). This overlaps with activity traced by the broader cybersecurity community under the names ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard (formerly Krypton), Snake, SUMMIT, Euroburros, Venomous Bear, Waterbug, and WRAITH.
The hacking group is known for attacks targeting government, diplomatic and defense sectors in Europe and Central Asia, as well as endpoints previously breached by Aqua Blizzard (aka Actinium and Gameradon) to support the Kremlin’s strategic objectives.
“This upgrade is consistent with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence collection,” the Microsoft Threat Intelligence team said in a report published Thursday. “While many threat actors rely on the increasing use of native tools (living-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progress into a modular bot highlights how Secret Blizzard is engineering flexibility and stealth directly into their tooling.”
A key tool in Turla’s arsenal is Kazaaar, a sophisticated .NET backdoor that has been in continuous use since 2017. Microsoft’s latest findings show its evolution from a “monolithic” framework to a modular bot ecosystem, consisting of three distinct component types, each with their own well-defined roles. These changes enable flexible configuration, reduce observable footprint, and facilitate a wide range of functions.
|
| Overview of kernel, bridge, and worker module interactions |
It has been found that attacks that distribute malware rely on droppers like Pelmeni and Shadowloader to decrypt and launch modules. The three module types that form the foundation of Kazuyu’s architecture are listed below –
-
kernels
which acts as the central coordinator for the botnet by issuing tasks to the worker module, managing communications with the bridge module, maintaining logs of tasks and collected data, performing anti-analysis and sandbox checks, and setting up the environment through a configuration that specifies various parameters related to command-and-control (C2) communications, data exfiltration time, task management, file scanning and collection, and monitoring. -
Bridge
Which acts as a proxy between the leader kernel module and the C2 server. -
laborer
Which logs keystrokes, hooks Windows events, tracks tasks, and collects system information, file listings, and messaging application programming interface (MAPI) details.
The kernel module type exposes three different ways to interact with internal communication mechanisms (via Windows Messaging, mailslots, and named pipes) and attacker-controlled infrastructure (via Exchange Web Services, HTTP, and WebSockets). The component also “elects” a single kernel leader to communicate with bridge modules on behalf of other kernel modules.
|
| How does the kernel coordinate leader worker actions and use bridges |
“Elections take place on mailslots and the leader is elected by dividing the amount of work (duration of kernel module running) by interruptions (reboots, logoffs, process terminations),” Microsoft explained. “Once a leader is elected, it declares itself the leader and tells all other kernel modules to set silent. Only the elected leader is not silent, which allows the leader kernel module to log activity and request actions through the bridge module.”
Another function of the module is to start various threads to establish a named pipe channel between kernel modules for inter-kernel communication, specify an external communication method, as well as facilitate kernel-to-worker and kernel-to-bridge communication over Windows Messaging or Mailslot.
The ultimate goal of the kernel is to poll new tasks from the C2 server, parse incoming messages, assign tasks to workers, update the configuration, and send the results of the tasks back to the server. In addition, the module includes a task handler that makes it possible to process commands issued by the kernel leader.
The data collected by the worker module is then aggregated, encrypted, and written to the malware’s working directory, from where it is sent to the C2 server.
“Czure modules use a dedicated working directory as a centralized on-disk staging area to support their internal operations,” Microsoft said. “This directory is defined through configuration and is consistently referenced using fully qualified paths to avoid ambiguity in execution contexts.”
“Within the working directory, Czuar organizes data by function, separating tasking, archive output, logs, and configuration content into separate locations. This design allows the malware to separate 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.”
