A Russian state-sponsored hacking group known as Turla transformed the custom backdoor Katar into a modular peer-to-peer (P2P) botnet designed for stealthy and persistent access to compromised hosts.
According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), Turla has been assessed as belonging to Center 16 of Russia’s Federal Security Service (FSB). This overlaps with activity tracked by the broader 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 attacks targeting government, diplomatic, and defense sectors in Europe and Central Asia, as well as endpoints previously compromised by Aqua Blizzard (also known as Actinium and Gamaredon) in support of the Kremlin’s strategic goals.
“This upgrade is in line with Secret Blizzard’s broader objective of gaining long-term access to the system for intelligence collection,” the Microsoft Threat Intelligence team said in a report released Thursday. “While many threat actors rely on increased use of native tools (resident binaries (LOLBins)) to avoid detection, Kazuar’s evolution to a modular bot highlights how Secret Blizzard is building resilience and stealth directly into its tools.”
A key tool in Turla’s arsenal is Katar, a sophisticated .NET backdoor that has been used consistently since 2017. Microsoft’s latest findings demonstrate an evolution from a “monolithic” framework to a modular bot ecosystem featuring three distinct component types, each with a clearly defined role. These changes allow for flexible configuration, reduce visible footprint, and facilitate a wide range of tasks.
Overview of kernel, bridge, and worker module interactions
Attacks distributing malware have been found to rely on droppers such as Pelmeni and ShadowLoader to decrypt and launch modules. The three module types that form the foundation of Zuar’s architecture are listed below.
The kernel acts as the central coordinator of the botnet by issuing tasks to worker modules, managing communication with bridge modules, maintaining logs of actions and collected data, performing anti-analytics and sandbox checks, and setting up the environment with configurations that specify various parameters related to command and control (C2) communication, data extraction timing, task management, file scanning and collection, and monitoring. Bridge acts as a proxy between the reader kernel module and the C2 server. Workers log keystrokes, hook Windows events, track tasks, and collect system information, file lists, and Messaging Application Programming Interface (MAPI) details.
The kernel module type exposes three internal communication mechanisms (via Windows Messaging, Mailslot, and Named Pipes) and three different ways to connect to attacker-controlled infrastructure (via Exchange Web Services, HTTP, and WebSockets). This component also “elects” a single kernel leader that communicates with the bridge module on behalf of other kernel modules.
How kernel leaders coordinate worker tasks and use bridges
“Elections are held via mailslots, and leaders are elected based on workload (the length of time a kernel module is running) divided by interruptions (reboots, logoffs, process terminations),” Microsoft explained. “Once a leader is elected, it announces itself as the leader and tells all other kernel modules to set SILENT. Only the elected leader is not SILENT, so the leader kernel module can log activity and request tasks through the bridge module.”
Another feature of this module is to start various threads, set up named pipe channels between kernel modules for interkernel communication, specify external communication methods, as well as facilitate kernel-to-worker and kernel-to-bridge communication via Windows Messaging or mailslots.
The kernel’s ultimate goal is to poll for new tasks from the C2 server, parse incoming messages, assign tasks to workers, update configuration, and send task results back to the server. Additionally, this module includes a task handler that allows it to process commands issued by kernel readers.
The data collected by the worker module is then aggregated, encrypted, and written to the malware’s working directory, from where it is exfiltrated to the C2 server.
“Kazuar uses a dedicated working directory as a central staging area on disk to support internal operations across modules,” Microsoft said. “This directory is defined by configuration and is consistently referenced using a fully qualified path to avoid ambiguity across execution contexts.”
“Within the working directory, Kazuar organizes data by functionality, separating tasks, collection output, logs, and configuration materials into separate locations. This design allows the malware to separate task execution from data storage and extraction, maintain operational state across reboots, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure.”
Source link
