Deep Dive: Turla's Kazuar Evolves into Modular P2P Infrastructure

Behavioral analysis is definitely the way to go here. We dealt with a similar P2P architecture last year, and signature-based AV was useless against the obfuscated module loaders. I'd recommend checking for unsigned PowerShell scripts executing with encoded commands; Turla loves using PowerShell for 'living off the land' tasks to inject the P2P payload into memory without touching the disk.

Solid query, but be careful with false positives from corporate VPN clients or mesh network agents (like Tailscale) which might exhibit similar traffic patterns. You might want to add a filter to exclude known corporate certificate issuers or verified signing status in the InitiatingProcessFileName clause to reduce noise for the SOC.

The modular aspect is the scary part. It implies they can update the botnet functionality without dropping new executables. We've started correlating WMI event subscriptions with network anomalies. If you see a WMI event consumer firing right around the time those P2P connections start, you're likely dealing with the persistence mechanism.

The modularity suggests heavy in-memory execution. Apart from WMI, look for memory-resident code that avoids disk writes. Scanning for unsigned DLLs loaded by trusted processes is a solid baseline. You can use PowerShell to check for this specific anomaly:

Get-Process | Select-Object ProcessName, @{Name='Modules';Expression={(Get-Process -Id $_.Id).Modules.FileName | Where-Object { -not (Get-AuthenticodeSignature $_).SignerCertificate }}}

With P2P infrastructure, we should focus on identifying "supernodes"—compromised hosts acting as relays. These often exhibit a high degree of distinct external connections in short bursts, bypassing standard volume thresholds.

You can hunt for this using KQL by correlating internal IPs with high unique destination counts over a 10-minute window:

DeviceNetworkEvents
| where Timestamp > ago(10m)
| summarize distinct_DestIPs=dcount(RemoteIP) by DeviceName
| where distinct_DestIPs > 50

Finding a workstation talking to 50+ unique peers is usually a strong indicator of botnet participation.

Excellent insights on the supernode behavior. It's also worth monitoring the DNS layer for the initial bootstrap phase. Even decentralized meshes often rely on hardcoded domains to find the first peer. We've caught similar P2P activity by flagging domains with high entropy or abnormal query lengths.

Here is a quick KQL snippet to hunt for these potential bootstrap domains:

DnsEvents
| where strlen(Name) > 32 and isnotempty(QueryTypeName)
| summarize dcount(SourceIP) by Name
| where dcount_SourceIP < 5

Focusing on low-prevalence, long domain names helps filter out standard corporate traffic while isolating potential C2 beacons.

To catch the modular plugin loading, don't overlook abuse of Living-Off-The-Land (LOL) binaries. Kazuar often uses rundll32.exe or regsvr32.exe to execute payloads directly from memory or remote URLs. I’d suggest hunting for anomalies where these system utilities spawn from non-standard parent processes or make network connections.

DeviceProcessEvents
| where FileName in ("rundll32.exe", "regsvr32.exe")
| where InitiatingProcessFileName != "explorer.exe"
| where ProcessCommandLine contains ".dll" and ProcessCommandLine matches regex @"http(s)?://"

To expand on detection, we should look at TLS fingerprinting (JA3/JA4). Modular P2P components often share identical SSL client configurations. Correlating unique fingerprints with unusual ports is a strong signal. You can hunt for this in your network logs using:

awk -F'\t' '{print $1, $9}' ssl.log | sort | uniq -c | sort -rn | head -n 10

Even without a known signature, spotting a common JA3 hash across disparate internal hosts is a red flag for lateral movement or C2 meshing.