Turla Turns Kazuar Backdoor into Modular P2P Botnet for Continuous Access
A Russian state-sponsored hacker group known as
Turla
turned its custom backdoor Kazuar into a peer-to-peer (P2P) botnet designed for stealth and continuous access to vulnerable hosts.
Turla, according to the Cybersecurity and Infrastructure Security Agency of the US (CISA), is being investigated for links to Center 16 of Russia’s Federal Security Service (FSB). It overlaps with work pursued by the wider cybersecurity community under the names ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard (formerly Krypton), Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug, and WRAITH.
The hacker group is known for its attacks targeting governments, intelligence and defense officials in Europe and Central Asia, and previously breached targets by Aqua Blizzard (also known as Actinium and Gamaredon) to support the Kremlin’s strategic goals.
“This development is consistent with Secret Blizzard’s broader goal of gaining long-term access to intelligence-gathering systems,” Microsoft’s Threat Intelligence team said in a report published Thursday. “While many threat actors rely on the increasing use of native tools (live-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progress on a modular bot highlights how Secret Blizzard is engineering strength and subtlety right into their tools.”
A key tool in Turla’s arsenal is Kazuar, a sophisticated .NET backdoor that has been in use since 2017. The latest findings from Microsoft chart its evolution from a “monolithic” framework to a modular bot ecosystem with three distinct types, each with its own well-defined role. These changes enable flexible configuration, reduce the visual footprint, and facilitate extensive work.
 |
| Overview of Kernel, Bridge, and Worker module interactions |
Malware distribution attacks have been found to rely on drops like Pelmeni and ShadowLoader to decrypt and unlock modules. The three types of modules that form the basis of Kazuar’s architecture are listed below –
-
The Kernel
acting as the main coordinator of the botnet by issuing tasks to the Worker modules, controls communication with the Bridge module, keeps logs of actions and collected data, performs anti-analysis checks and sandbox, and sets up the environment with a configuration that specifies various parameters related to command-and-control (C2), monitoring data collection and file collection, data scanning, data scanning, file scanning and data extraction. -
The bridge
which acts as a proxy between the leading Kernel module and the C2 server. -
An employee
which logs keystrokes, hooks Windows events, tracks activity, and collects system information, file lists, and Messaging Application Programming Interface ( MAPI ) information.
The Kernel module type exposes three internal communication methods (via Windows Messaging, Mailslot, and named pipes) and three different ways to communicate with attacker-controlled infrastructure (via Exchange Web Services, HTTP, and WebSockets). The component also “elects” one Kernel leader to communicate with the Bridge module on behalf of other Kernel modules.
 |
| Kernel leader how to coordinate task performance and bridge implementation |
“Election takes place via Mailslot, and the leader is chosen based on the amount of work (the length of time the Kernel module is running) divided by interruptions (reboot, lock, process terminated),” explains Microsoft. “Once a leader is selected, it declares itself as the leader and tells all other Kernel modules to QUIET. Only the selected leader is NOT QUIET, which allows the leader’s Kernel module to log a job and request jobs through the Bridge module.”
Another function of the module is to initiate various threads to set up a named pipe channel between Kernel modules for inter-Kernel communication, to specify an external communication method, and to facilitate Kernel-to-Worker and Kernel-to-Bridge communication through Windows messages or Mailslot.
The ultimate goal of the Kernel is to poll new jobs from the C2 server, analyze incoming messages, assign Worker jobs, update the configuration, and send job results 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 collated, encrypted, and written into the malware’s active directory, from where it is exported to the C2 server.
“Kazuar uses the active directory as a central disk space to support its internal functionality across modules,” Microsoft said. “This directory is defined by configuration and referenced consistently using fully qualified methods to avoid ambiguity in all operating conditions.”
“Within the performance index, Kazuar organizes data by task, separating tasking, output collection, logs, and configuration objects into separate areas. This design allows the malware to separate task execution from data storage and execution, maintain execution state across restarts, and direct synchronized work between modules while minimizing direct external interactions.”
