Turla Turns Kazuar Backdoor Into Modular P2P Botnet for Persistent Access

The Russian state‑sponsored group Turla, also known as Secret Blizzard, ATG26, Blue Python and several other aliases, has taken its long‑running Kazuar backdoor and rebuilt it as a modular peer‑to‑peer (P2P) botnet. The redesign, detailed in a Microsoft Threat Intelligence report released on May 15, 2026, adds a leader‑election mechanism, multiple internal communication paths, and a dedicated on‑disk staging area that together improve stealth and enable persistent access to compromised hosts.

---

Why the change matters

Turla’s traditional approach relied on monolithic .NET implants that communicated directly with a command‑and‑control (C2) server. That model left a clear network footprint and made the malware easier to spot with standard outbound‑traffic monitoring. By shifting to a P2P architecture, each infected machine can act as both client and server, distributing tasks internally and reducing the number of external connections.

“While many threat actors rely on increasing usage of native tools (living‑off‑the‑land binaries) to avoid detection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and stealth directly into their tooling,” – Microsoft Threat Intelligence team

The upgrade aligns with Turla’s historic focus on long‑term intelligence collection against government, diplomatic and defense entities in Europe and Central Asia. A more resilient botnet means the group can maintain footholds for months, even years, without triggering alerts.

---

Architecture at a glance

Kazuar now consists of three distinct module types that work together:

Module	Role	Key capabilities
Kernel	Central coordinator	Elects a leader among Kernel instances, manages task distribution, communicates with Bridge, performs anti‑analysis checks, and stores configuration.
Bridge	Proxy to external C2	Relays traffic between the elected Kernel leader and attacker‑controlled infrastructure using Exchange Web Services, HTTP or WebSockets.
Worker	Data collector	Logs keystrokes, hooks Windows events, gathers system information, MAPI details, and prepares exfiltration payloads.

Leader election and silent mode

All Kernel modules can talk to each other via Windows Messaging, Mailslot, or named pipes. They periodically run an election algorithm that selects a single Kernel leader based on the ratio of uptime to interruptions (reboots, logoffs, process termination). The elected leader stays non‑silent and maintains the Bridge connection, while all other Kernels switch to SILENT mode, suppressing outbound traffic and logging. This reduces the number of external connections to a single, rotating point, making network‑based detection far more difficult.

Multi‑channel communication

Kazuar supports three internal channels (Windows Messaging, Mailslot, named pipes) and three external transport methods (EWS, HTTP, WebSockets). The flexibility lets the malware adapt to environments where certain ports or protocols are blocked. For example, if outbound HTTP is filtered, the bot can fall back to WebSockets over port 443, which often blends with legitimate web traffic.

---

How the infection chain works

1. Initial dropper – Trojans such as Pelmeni or ShadowLoader deliver an encrypted payload.
2. Decryption & staging – The dropper writes the Kazuar modules to a dedicated working directory defined in the configuration (e.g., C:\ProgramData\Kazuar).
3. Module launch – Each module starts as a separate process, registers its communication endpoints, and begins the leader election.
4. Tasking – The leader Kernel contacts the Bridge, pulls tasks from the C2 server, and assigns them to Workers.
5. Data collection & exfiltration – Workers gather files, keystrokes, MAPI data, encrypt the results, and write them to the staging area. The leader then forwards the encrypted blobs to the Bridge for final exfiltration.

The use of a centralized on‑disk staging area lets the bot survive reboots and continue processing tasks even if a single component crashes. All paths are fully qualified, preventing ambiguity across user contexts.

---

Practical takeaways for defenders

Action	Why it helps	How to implement
Monitor for unusual inter‑process communication – Look for frequent use of Windows Messaging, Mailslot or named pipes between unrelated processes.	Kazuar’s modules rely heavily on these mechanisms.	Deploy endpoint detection and response (EDR) rules that flag high‑frequency IPC on systems that normally don’t use them.
Watch for silent‑mode patterns – A sudden drop in outbound connections from a host that previously communicated externally can indicate a Kernel module entering SILENT mode.	Only the elected leader talks to the Bridge.	Correlate network flow logs with process activity; alert on hosts that stop external traffic while still running suspicious processes.
Inspect the Kazuar working directory – The directory is configurable but often resides in common data locations (ProgramData, AppData\Local).	All collected data is staged there before exfiltration.	Use file‑integrity monitoring to detect creation of unknown subfolders with encrypted blobs or unusual file extensions.
Detect the specific droppers – Pelmeni and ShadowLoader have known hash signatures and drop patterns.	They are the first stage of the infection chain.	Update your antivirus and YARA rule sets with the latest signatures from Microsoft and CISA.
Limit Exchange Web Services (EWS) outbound – If the organization does not use EWS, block it at the firewall.	EWS is one of Kazuar’s external channels.	Create a deny rule for *.outlook.com EWS endpoints unless explicitly required.

---

Broader implications

Turla’s shift to a modular P2P botnet mirrors a trend among sophisticated APT groups: building custom, self‑healing infrastructures that avoid reliance on single points of failure. The election‑based leader model is reminiscent of older botnets like Storm but applied to a modern, .NET‑based implant.

For incident responders, the key lesson is to broaden detection beyond classic C2 traffic. Look for internal orchestration signals—IPC, shared directories, and process‑level coordination—that indicate a multi‑module framework at work.

---

References & further reading

• Microsoft Threat Intelligence blog post – Kazuar’s Evolution into a Modular P2P Botnet (May 15, 2026) – https://www.microsoft.com/security/blog/kazuar-modular-botnet
• CISA advisory on Turla activity – https://www.cisa.gov/turla-activity
• YARA rules for Pelmeni and ShadowLoader – https://github.com/Yara-Rules/malware
• Guide to monitoring Windows IPC – https://docs.microsoft.com/windows/win32/ipc

---

Stay vigilant. The modular nature of Kazuar means that even if you disrupt one component, the remaining modules can re‑elect a leader and resume operations. Continuous monitoring, strict outbound filtering, and endpoint hygiene are your best defenses against this evolving threat.