C2 Resilience: Turla's Kazuar Shifts to Modular P2P Mesh

Heuristics are definitely the way to go here. We've started implementing Sigma rules to alert on processes performing DNS queries for 'dead' domains (DGA) or making frequent connections to multiple distinct geo-locations. The modular nature of Kazuar means the disk footprint is tiny, so EDR scanning might miss it if it's purely memory-resident. We are forcing memory dumps on any alerts involving rundll32.exe or regsvr32.exe with network activity.

This reminds me of the shift we saw with other APTs moving to P2P to bypass perimeter firewalls. The real pain point is lateral movement. Once they are peer-to-peer, identifying the 'patient zero' becomes incredibly difficult because the traffic looks like internal mesh chatter. I'd recommend checking your NetFlow data for large data transfers between endpoints that don't normally communicate.

Good post. Just a heads up—Kazuar has historically been tied to .NET environments. If your org runs a lot of custom .NET internal tools, be extra careful with process hollowing detection. Turla loves injecting into legitimate processes. That PowerShell snippet is handy, but don't forget to check for unsigned DLLs in the AppData directory as well.

The modular approach implies a distinct stager phase before the P2P mesh stabilizes. We've found success hunting for the initial dropper by correlating rundll32.exe or regsvr32.exe execution with immediate network connections, which often precedes the plugin loading. You can catch this early behavior using a simple PowerShell filter on Sysmon Event ID 1:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} | Where-Object {$_.Message -match '(rundll32|regsvr32)' -and $_.Message -match 'NetworkConnect'}

Catching the stager is easier than dissecting the established mesh traffic later on.

Great points on the stagers. To expand on the mesh aspect, network telemetry becomes crucial once the P2P network stabilizes. Since peers constantly update their status, you’ll often see high distinct destination connection counts that don't align with standard business traffic.

We’ve had success hunting this behavior using KQL to flag internal nodes acting as unexpected hubs or scanners:

DeviceNetworkEvents
| where ActionType has "Connection"
| summarize dcount(RemoteIP) by DeviceName, bin(Timestamp, 5m)
| where dcount_RemoteIP > 15

Don't overlook WMI Event Subscriptions for persistence. Since Kazuar aims for a low footprint, actors often use WMI to re-infect without touching the disk, bypassing standard file scans. You can audit current subscriptions with this snippet:

Get-WmiObject -Namespace root\subscription -Class __EventFilter | Select-Object Name, Query

Correlating these query strings with known IOC patterns can reveal dormant nodes waiting to reconnect to the mesh.

Since the modular design includes keylogging, credential theft is a high-priority risk here. I’d recommend pivoting to identity telemetry to catch the usage of those stolen creds rather than just the dropper. We look for impossible travel or unusual time-of-day access. For those in the Microsoft ecosystem, this KQL query helps identify users signing in from multiple distinct locations within minutes:

SigninLogs
| summarize Locations = make_set(Location) by UserPrincipalName, bin(TimeGenerated, 15m)
| where array_length(Locations) > 1

Building on Diana’s point about telemetry, the P2P heartbeat often creates a distinct 'small packet, high frequency' signature. We’ve had luck isolating these nodes by filtering for low-byte-count flows over non-standard ports. This KQL query helps hunt for that behavior to separate the mesh from background noise:

DeviceNetworkEvents
| where SentBytes  20