Kazuar's Evolution: Turla's Move to Modular P2P

Has anyone else dug into the latest reports on Turla’s Kazuar? The shift to a modular peer-to-peer (P2P) architecture is particularly concerning, especially given their assessed affiliation with the FSB's Center 16. Traditional C2 detection might struggle here if the nodes are communicating laterally within a compromised network rather than phoning home to a known sinkhole.

The persistence mechanisms usually involve Registry run keys or scheduled tasks, but the P2P aspect changes the game for egress filtering. Since Kazuar is known for targeting Windows environments heavily, we should be looking for anomalous process inheritance and stealthy scheduling.

I've updated our YARA rules to catch the specific encryption headers Kazuar uses, but the behavioral changes are tricky. If they are using standard OS APIs (Living-off-the-Land) for the P2P communication, we need to rely on parent-child process relationships.

Here is a quick KQL query to hunt for suspicious PowerShell execution often used in the initial staging:

DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine contains "-EncodedCommand"
| where InitiatingProcessFileName !in~ ("explorer.exe", "cmd.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName

The real challenge is the encrypted payload traffic. Has anyone seen similar lateral movement patterns in their recent traffic, or are we all still relying on IOCs from previous campaigns?