Secret Blizzard’s Kazuar P2P Botnet: Dissecting the FSB Implant That Replaced Traditional C2 With Leaderless Mesh Infrastructure

For two decades, Kazuar was a textbook .NET backdoor. One assembly, one config, one C2, one beacon. Every infected box phoned home. Then Microsoft’s May 14, 2026 writeup dropped, and the picture flipped: Turla’s flagship implant is now a three-process IPC mesh where most of the infected estate has gone dark on the network and a single elected node speaks for the rest. If your detection strategy is “find the beacon,” you’ve already lost the game.

Who Secret Blizzard Actually Is

Before the architecture, the operator. Secret Blizzard is Microsoft’s name for the cluster the rest of the industry has been chasing under a dozen aliases: Turla, Snake, Uroburos, Venomous Bear, Waterbug, Pensive Ursa, Iron Hunter, Krypton. CISA assesses the group as Center 16 of the FSB. MITRE tracks it as G0010. Whatever name you prefer, the targeting tells you everything: foreign ministries, defense contractors, parliamentary networks, embassies, and increasingly the Ukrainian government and its supporting infrastructure across NATO members.

Operationally, Turla has a habit that should worry every defender who shares a continent with them. They piggyback on access already established by Aqua Blizzard (Gamaredon), the noisier FSB unit responsible for the wide, sloppy spearphishing operations against Ukrainian targets. Gamaredon kicks the door in, Turla walks in behind them and installs something quiet. Kazuar is the something quiet.

This is not a smash-and-grab actor. They burn implants on purpose to keep better ones in reserve. The 2026 Kazuar variant is what happens when a team like that spends a few years rethinking what a backdoor should look like in an EDR-heavy world.

Kazuar’s 20-Year Lineage: From .NET Backdoor to Mesh Implant

Kazuar’s code lineage traces back to around 2005 and the older Carbon/Snake family. It surfaced as a named .NET backdoor in 2017 (Palo Alto Unit 42’s original writeup), reappeared in 2020 in operations against European foreign ministries, and was deployed heavily against Ukrainian targets through 2023. Through all of that, the architecture was structurally the same: a single .NET assembly, an embedded config, direct HTTP/HTTPS comms to operator-controlled web infrastructure, and a tasking loop you could draw on a napkin.

What Microsoft documented in May 2026 is not version N+1 of that backdoor. It is a redesign. The monolith was decomposed into three cooperating processes per host, internal traffic was rebuilt on top of Windows IPC primitives, and the network-egress surface was collapsed onto a single elected node per environment. Same family genealogy, same code reuse in places, but a fundamentally different operational philosophy.

The reason this matters: most detection engineering against Turla has been built around the napkin diagram. Beacon to C2, identify C2, block C2, dead implant. That entire detection chain assumes the implant has somewhere to call home from. The 2026 variant kicks that assumption out from under you.

Delivery: Pelmeni, ShadowLoader, and Host-Bound Payloads

Initial access still looks like Turla. The two named loaders feeding the new Kazuar are Pelmeni and ShadowLoader, both well-established in Turla’s catalog.

Pelmeni is the more interesting of the two for a defender. It is a dropper that embeds the encrypted next-stage payload as a byte array inside its own body, and it derives the AES key for that payload from properties of the target host, most commonly a hash of the machine name or domain identifier. The practical consequence: if you grab a Pelmeni sample off a sandbox detonation in a generic Windows VM, the second stage will never decrypt. You get a dropper that does nothing visible and a hash you can’t pivot on. The payload only exists when it touches the box it was built for.

This is host-bound payload binding, and it is specifically designed to defeat the way most threat intel teams work. Static hash hunting fails. Sandbox detonation fails. YARA on the second stage fails because the second stage doesn’t exist on disk in cleartext anywhere except the targeted host’s memory.

ShadowLoader is the lighter-weight option, a small .NET loader frequently registered as a COM in-process server and invoked via CoCreateInstance. It pulls the Kazuar module bytes, calls Assembly.Load(byte[]), and runs the whole thing in memory. No final-stage file lands on disk.

// Illustrative pattern of the loader stage — not the actual ShadowLoader
// Real samples obfuscate API names, use reflection, and bypass AMSI first.

[ComVisible(true)]
[Guid("9F2E4A1C-7B33-4E91-B4D0-3A6F2C9D1E08")]
public class Loader
{
    public void Run(string blobPath)
    {
        byte[] encrypted = File.ReadAllBytes(blobPath);
        byte[] key = DeriveKeyFromHost();  // SHA-256 of MachineName + DomainSid

        byte[] cleartext = AesDecrypt(encrypted, key);

        // In-memory load — never touches disk after decrypt
        Assembly mod = Assembly.Load(cleartext);
        mod.EntryPoint.Invoke(null, new object[] { new string[] { } });
    }
}

The COM registration itself is the persistence anchor. A CLSID under HKCU\Software\Classes\CLSID\{GUID}\InProcServer32 pointing at the loader DLL, hijacked or newly registered. When a legitimate process calls CoCreateInstance on the matching CLSID, the loader gets activated inside that process’s address space. No Run key, no scheduled task, no service. Just an entry in the user’s COM registry that most baseline tools don’t even look at.

The Three-Module Architecture: Kernel, Bridge, Worker

Once the loader fires, three modules come up on the host. All three are required for the implant to function. Microsoft labels them in ALL CAPS internally; I’ll use the same convention.

The split is the design. WORKER has no idea where the C2 is. BRIDGE has no idea what data it’s forwarding. KERNEL holds the state and is the only component that knows both sides. If you dump a WORKER process and reverse it, you find collection logic and IPC stubs, but no C2 indicators of any kind. The thing you most want to see (where does this talk to?) is intentionally not in the process you’re most likely to catch.

KERNEL on each host runs anti-analysis on startup. Standard fare for state-grade implants: process-name enumeration looking for procmon, wireshark, x64dbg, ida, common sandbox processes; canary file probes; DLL presence checks for known sandboxing libraries; timing checks against GetTickCount vs. wall clock. If any check fails, the module exits silently. No noisy bail-out, no log, no artifact. This is part of why public sample counts for the 2026 variant are low: most curiosity-driven sandbox runs never produce a working sample.

If the checks pass, KERNEL reads its embedded configuration. Old Kazuar kept config in separate files on disk, often easy to spot. The 2026 variant embeds the config inside the sample and supports up to 150 distinct configuration types, grouped into eight functional categories covering transport selection, injection methods, bypass toggles, exfiltration timing, task management, file harvesting, keylogging behavior, and operational state. The config is updatable at runtime over the BRIDGE channel from C2, which means an operator can flip the entire personality of the implant without touching the disk.

The Leader-Election Algorithm: Silencing the Mesh

Here is where the architecture stops being clever modular design and starts being a serious detection problem.

When KERNEL comes online, it does not immediately reach out to C2. It first looks for other KERNEL instances on the local network. Discovery happens over Mailslots, the largely forgotten Windows IPC primitive that uses datagram-style messages over the \\<server>\mailslot\<name> namespace and rides on top of SMB/NetBIOS. Mailslots are broadcast-capable: you can send to \\*\mailslot\name and every machine in the browse list receives it. They are also almost never monitored by EDR, and most defenders forget they exist.

Each KERNEL broadcasts a small heartbeat over a named Mailslot containing a stability score. The score is built from runtime metrics, primarily uptime since the last reboot or user logoff, with adjustments for things like number of interruptions and recent crash counts. The KERNEL with the highest score wins. The election outcome:

• One node enters LEADER state. It opens a named pipe server, connects to BRIDGE on its own host, and becomes the single point of external communication for the entire infected set in that segment.
• Every other node enters SILENT state. It does not initiate C2 traffic. It does not contact BRIDGE. It connects to the LEADER’s named pipe as a client and waits for tasks.

// Conceptual model of the election heartbeat — illustrative
public class KernelElection
{
    private const string SLOT = @"\\*\mailslot\<actual-name-from-sample>";

    public ElectionState RunElection()
    {
        long myScore = UptimeMinutes()
                     - (RebootCount * 60)
                     - (LogoffCount * 30);

        BroadcastHeartbeat(SLOT, myScore, Environment.MachineName);

        // Listen for peer heartbeats for a fixed window
        var peers = CollectHeartbeats(SLOT, TimeSpan.FromMinutes(2));

        if (peers.All(p => p.Score < myScore))
            return ElectionState.LEADER;

        return ElectionState.SILENT;
    }
}

What this buys the operator is brutal in its simplicity. Imagine Turla has compromised twelve hosts in a target ministry: eight workstations, two file servers, two jump boxes. In the old Kazuar architecture, you’d see twelve hosts beaconing to C2. Twelve flow records. Twelve chances for a SOC analyst to notice one of them. In the 2026 architecture, you see one host generating external traffic. The other eleven look completely clean from any network vantage point. They are not clean. They are keylogging, harvesting mailboxes, and staging exfil. They just aren’t talking to the internet themselves.

Failover is built in. If the LEADER host goes offline (reboot, shutdown, user logoff, EDR kill), the remaining SILENT nodes detect the missing heartbeat on the next election cycle and re-elect. Continuity is maintained. From a network defender’s perspective, the egress point shifts to a different host on a different day, which destroys your ability to even build a reliable “this host is suspicious” baseline.

This is the single most important thing to internalize about modern Kazuar: the absence of external traffic is not evidence of cleanliness. It is, statistically, the expected state for any given infected host in a Kazuar mesh.

The Encrypted IPC Protocol: AES + Protobuf Over Pipes, Mailslots, and Window Messages

Internal communication between modules uses three transports, chosen because they are noisy with legitimate traffic on a Windows host and rarely monitored seriously.

Named pipes carry the bulk of LEADER-to-SILENT KERNEL traffic and KERNEL-to-BRIDGE traffic on the LEADER host. Each pipe is created with a name that looks unremarkable, frequently mimicking patterns of legitimate Microsoft pipes (the actual names are in Microsoft’s writeup and shift between builds, which is exactly why you can’t write a signature on the literal string).

Mailslots are used primarily for the leader-election broadcast and for periodic peer-presence announcements.

Windows Messages are used for in-process and limited cross-process signaling, particularly between KERNEL and the injected WORKER thread when the operator has configured KERNEL to inject WORKER into a legitimate host process. Messages are registered via RegisterWindowMessage with operator-chosen identifiers and sent via PostMessage/SendMessage.

On top of those transports, messages are serialized with Google Protocol Buffers and then AES-encrypted. Protobuf gives them a compact, versioned, language-agnostic wire format. The schema (reconstructed from sample analysis, not published by Microsoft) looks roughly like:

syntax = "proto3";

message KazuarMessage {
  enum MessageType {
    HEARTBEAT      = 0;
    TASK_REQUEST   = 1;
    TASK_RESULT    = 2;
    CONFIG_UPDATE  = 3;
    EXFIL_CHUNK    = 4;
    ELECTION_VOTE  = 5;
  }
  MessageType type        = 1;
  bytes       node_id     = 2;
  uint64      sequence    = 3;
  bytes       payload     = 4;   // AES-encrypted inner blob
  uint64      timestamp   = 5;
}

The AES key for IPC is derived per-environment, often based on a value distributed during the initial deployment that the LEADER includes in election traffic. This means a captured pipe dump from one environment can’t decrypt traffic from another, and dumping the AES key requires live memory access to a running KERNEL process.

BRIDGE translates outbound EXFIL_CHUNK and TASK_RESULT messages into one of three external protocols based on config:

EWS is the most dangerous of the three because EWS traffic is almost universally allowed outbound from corporate environments, terminates at Microsoft or on-prem Exchange, and is rarely subjected to content inspection. The data exfiltrates as an EWSProxyRequest from what appears to be a normal user mailbox. Without EWS audit logging explicitly enabled and forwarded to a SIEM, you will not see this.

The 150-Configuration Operator Console

The configuration space deserves its own moment. 150 configuration types across eight functional categories means an operator can produce, from a single binary, implants that behave so differently that you’d struggle to recognize them as the same family. Some of the more notable knobs:

• Transport selection: HTTP-only, WebSocket-only, EWS-only, or weighted blends. Operators against Ukrainian government targets reportedly favor EWS; against European diplomatic targets, WebSocket has been observed more often.
• Injection method: WORKER can run as its own process or be injected into a host process. Injection technique itself is configurable (classic CreateRemoteThread, NtMapViewOfSection, APC queuing).
• AMSI / ETW / WLDP bypass toggles: Each can be turned on individually. AMSI bypass patches AmsiScanBuffer in-process. ETW bypass patches EtwEventWrite or similar. WLDP bypass disables the Windows Lockdown Policy check that would otherwise block unsigned .NET assembly loads in CLM environments.
• Exfil chunk size and pacing: Configurable per-byte sizes and per-message delays. Operators set this against the target’s known monitoring posture. Tight environments get small chunks at random intervals during working hours; loose environments get full file uploads at night.
• Collection scope: Which file extensions, which paths, MAPI yes/no, keylogging yes/no, screenshot cadence, USB monitoring on/off.

The configuration is updateable at runtime over BRIDGE. An operator who notices their LEADER node is being scrutinized can push a config update to switch transports, reduce collection scope, and back off pacing, all without touching the binary or the disk. This is what separates a serious state implant from commercial malware: the implant is the platform, the config is the campaign.

What the Worker Actually Steals

The collection capability set is comprehensive, which is unsurprising for a 20-year-old family that has had time to accumulate every collector its operators have ever wanted:

• Keylogging via low-level keyboard hook (SetWindowsHookEx with WH_KEYBOARD_LL).
• Windows event hooking for window focus, clipboard activity, and UI events.
• Screenshot capture on schedule or trigger.
• File enumeration and collection matched against operator-supplied extension/path lists.
• MAPI email harvesting through direct Outlook profile access.
• Browser artifact collection: history, cookies, saved credentials from Chrome, Edge, Firefox profile directories.
• System inventory: running processes, installed software, network shares, USB device history, network configuration.
• Task results from operator-issued commands run via cmd or PowerShell.

All collection output is AES-encrypted and written to a working directory whose path is set in the config and referenced by fully qualified path everywhere it appears. Inside that directory, output is organized into subdirectories by function: tasks/, output/, logs/, config/. The point of this layout is to maintain operational state across reboots, keep async work coordinated between modules, and minimize how often KERNEL has to hit network resources to know what’s going on.

For a defender, the working directory is one of the better hunt anchors, because the path is non-standard, encrypted blobs are written to it constantly, and the name of the directory is not in a typical user or system path.

Why Network-Based C2 Hunting Fails Here

I want to nail this down explicitly because it’s the central thing to understand. Traditional perimeter detection against backdoors operates on three core assumptions:

1. The implant generates outbound traffic from the host it runs on.
2. The traffic has identifiable patterns (beacon interval, JA3 fingerprint, domain reputation).
3. Multiple infected hosts produce multiple flow records that correlate.

The 2026 Kazuar architecture violates all three:

1. Most infected hosts generate zero external traffic. SILENT mode is the baseline.
2. The LEADER’s traffic uses legitimate protocols on legitimate ports to either compromised legitimate sites or to Microsoft’s own EWS endpoints. There is no exotic protocol to fingerprint and no rare port to alert on.
3. Even if you correlate flow records across the environment, the correlation tells you nothing about which other hosts are compromised, because they aren’t generating records.

The asymmetric egress pattern is the only network-level fingerprint and it’s a weak one. “One host in this subnet talks to the internet more than the others” is a description of half the developer laptops in any company.

This is why Microsoft’s own detection guidance is overwhelmingly host-behavioral. You cannot solve this problem from the perimeter. You solve it on the endpoint or you don’t solve it.

Detection Engineering: What Actually Catches It

Behavioral telemetry beats signature telemetry here, and the specific telemetry sources you want are the ones operators have historically assumed nobody monitors.

Sysmon, the Right Way

Sysmon v15+ with a config that captures named pipe and process-access events is the floor. The events that matter:

The single highest-yield correlation in my experience: a process that creates a named pipe server (EID 17), accepts multiple inbound connections from other processes on the host or remote hosts (EID 18), and also makes external network connections (EID 3) within the same hour. That triple is the LEADER. Find that, you find the egress node, and from there you pivot to every host that connected to its pipe.

ETW Providers Worth Subscribing To

Verify ETW and AMSI are actually producing events. The single most overlooked detection failure is assuming a bypass didn’t succeed. If you have a host that stopped producing AMSI events at a specific time and didn’t reboot, treat that as a positive signal.

Sigma: Anomalous Pipe Creation

title: Kazuar-Like Named Pipe Created by Non-System .NET Process
id: 8f5e2a1c-7b33-4e91-b4d0-3a6f2c9d1e08
status: experimental
description: Detects named pipe creation by .NET processes outside trusted system paths, consistent with Kazuar KERNEL leader-mode IPC.
logsource:
  product: windows
  category: pipe_created
detection:
  selection:
    EventID: 17
  filter_trusted_paths:
    Image|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
  filter_known_pipes:
    PipeName|startswith:
      - '\wkssvc'
      - '\srvsvc'
      - '\lsass'
      - '\winreg'
      - '\spoolss'
      - '\ntsvcs'
  condition: selection and not (filter_trusted_paths or filter_known_pipes)
fields:
  - Image
  - PipeName
  - ProcessId
  - User
falsepositives:
  - Legitimate developer tools, custom enterprise applications using IPC
level: medium
tags:
  - attack.command_and_control
  - attack.t1090.001

KQL for EWS Audit Anomaly

// Programmatic EWS access from non-mail-client processes
// Requires Exchange mailbox audit logging enabled and forwarded
OfficeActivity
| where Operation == "EWSProxyRequest"
| where ClientProcessName !in~ ("OUTLOOK.EXE", "msedge.exe", "chrome.exe", 
                                "firefox.exe", "Teams.exe")
| where ClientIPAddress !startswith "10."
   and ClientIPAddress !startswith "172.16."
   and ClientIPAddress !startswith "192.168."
| summarize RequestCount = count(),
            DistinctMailboxes = dcount(MailboxOwnerUPN)
          by ClientProcessName, ClientIPAddress, bin(TimeGenerated, 1h)
| where RequestCount > 5

Asymmetric Egress Detection

This requires Zeek/Suricata or NetFlow correlated against host pipe activity in your SIEM. The logic in plain English: in any subnet, identify the single host generating all external HTTPS traffic. Then check whether two or more other hosts in that subnet have active inbound named pipe connections from that host or active intra-subnet SMB activity to that host’s Mailslot namespace. That combination is a Kazuar mesh fingerprint. It’s not a high-confidence single alert, but it’s a high-confidence hunt starting point.

MITRE ATT&CK Mapping

Hardening and Response

For an environment that hasn’t been hit yet, the prevention story is mostly about closing the loader’s path and breaking the IPC mesh:

• Enforce Constrained Language Mode in PowerShell across the estate. ShadowLoader variants that lean on PowerShell die immediately.
• Enable WDAC or AppLocker policies that block user-writable COM server registrations. The HKCU CLSID trick stops working when the registered DLL can’t be loaded.
• Enable Defender Tamper Protection and Attack Surface Reduction rules, particularly Block process creations originating from PSExec and WMI commands, Block Office applications from creating child processes, and Block credential stealing from LSASS.
• Block workstation-to-workstation named pipe and Mailslot traffic at the host firewall by default. Workstations have almost no legitimate reason to be Mailslot or pipe servers for other workstations. This single rule destroys the P2P mesh.
• Enable EWS audit logging and forward EWSProxyRequest events to your SIEM. If you can, enforce EWS Application Access Policies to restrict which client applications can hit EWS programmatically.
• Disable Mailslots entirely via Group Policy if you can confirm no legacy applications need them. Most environments can.

For a confirmed Kazuar infection, manual cleanup is not viable. The combination of in-memory modules, COM persistence, configurable injection targets, and live runtime reconfiguration means you will miss something. Reimage the host, rotate every credential that touched it, audit Exchange for mailbox rules and EWS app registrations created during the dwell period, and validate that EWS audit logging is forwarding to SIEM before the rebuilt host goes back into production. Treat the discovery of one LEADER as a confirmation that there are SILENT peers, and hunt the rest of the subnet before declaring the incident closed.

Key Takeaways

• The 2026 Kazuar variant is an architectural break from 20 years of Turla backdoor lineage. Treat it as a new family that happens to share genealogy, not as a Kazuar update.
• The leader-election design means the absence of network beaconing is not evidence of host cleanliness. SILENT mode is the expected state for most infected hosts.
• Perimeter detection is structurally inadequate against this implant. Defenders relying on C2 hunting are not playing the right game.
• Behavioral host telemetry, specifically named pipe activity (Sysmon 17/18), in-memory .NET assembly loads, and EWS audit logs from non-mail-client processes, is where Kazuar is actually visible.
• Blocking workstation-to-workstation pipe and Mailslot traffic at the host firewall breaks the P2P mesh with a single policy change. If you do nothing else, do that.
• Host-bound payload binding via Pelmeni defeats static hash and sandbox-based threat intel. Pivot strategies need to be built around behavioral indicators, not file hashes.
• Any confirmed Kazuar host is a reimage, not a clean. The modular architecture means manual remediation will leave something behind, and Turla operators will notice.

Related Tutorials

• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup

References

• www.microsoft.com
• attack.mitre.org
• www.bleepingcomputer.com
• thehackernews.com
• blog.polyswarm.io
• gbhackers.com
• cyberinsider.com
• www.rescana.com