Iran's Cav3rn C2: Analyzing the New MOIS Framework
Just caught the latest report from Check Point Research regarding a new modular C2 framework dubbed 'Cavern' (or Cav3rn). It appears an Iranian threat cluster affiliated with MOIS is actively using this to target Israeli organizations, specifically zeroing in on IT providers and government sectors.
What stands out here is the modularity. Much like other modern frameworks we've seen from nation-state actors, Cav3rn appears designed to swap out payloads and plugins to evade signature-based detection. Since IT providers are in the crosshairs, the supply chain risk is significant—compromise a provider, and you get access to the fortress.
I've been looking into detection strategies for these types of modular C2s. Since the framework is new, static signatures might be sparse. We're focusing heavily on behavioral anomalies, specifically around process injection and network traffic patterns.
For those using Sentinel, here's a basic KQL query we're testing to catch potential C2 heartbeats based on timing intervals and user-agent anomalies:
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort in (443, 80) and InitiatingProcessFileName in ("powershell.exe", "cmd.exe", "python.exe")
| extend Entropy = hash_sha256(NetworkCommunicationDirection)
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName, SentBytes, ReceivedBytes
| where SentBytes 3 // Consistent beacons
Has anyone else started seeing IOCs related to Cav3rn in their honeypots? I'm particularly interested if anyone has isolated the loader yet.
We haven't seen direct hits yet, but we're blocking known MOIS infrastructure at the edge. The focus on IT providers is the real concern here. We're enforcing strict jump-host access controls for our vendors and monitoring for unusual lateral movement. If you get the loader hash, please share—we'll get it into our blocklist immediately.
The modularity is what worries me. It’s likely they are using encrypted channels over standard ports (443/80) to blend in. Your KQL query is a good start, but I'd also recommend correlating that with DeviceProcessEvents looking for suspicious memory allocation calls. Ntdll.dll spoofing is common with these loaders.
# Python snippet to check for suspicious hollowing indicators in mem dumps
import pefile
# Placeholder for hollowing check logic
Stay vigilant out there.
From an MSP perspective, this is a nightmare scenario. If they compromise the management tools (RMM/PSA) used by IT providers, the blast radius is huge. We've moved our admin consoles to a completely isolated VLAN with no internet access, forcing a jump through a bastion host with MFA. It adds friction, but beats being a entry vector for Cav3rn.
The focus on modularity suggests heavy reliance on process injection to bypass static analysis. Since signature evasion is key, monitoring for AMSI/ETW tampering is crucial. You can quickly scan for potential unhooking attempts on endpoints using this PowerShell snippet to check for suspicious module loads:
Get-Process | Where-Object {$_.MainWindowTitle -eq ""} | Select-Object ProcessName, @{Name='Modules';Expression={(Get-Process -Id $_.Id).Module.FileName}}
Has anyone managed to isolate the specific staging protocol they use for initial dropper deployment?
To complement the AMSI monitoring, ensure Script Block Logging is active (Event ID 4104). Modular frameworks often load .NET assemblies directly into memory using PowerShell reflection. Since this avoids disk writes, hunting for these specific API calls in logs is crucial. Here is a basic query to start flagging suspicious assembly loading patterns:
Event
| where EventID == 4104
| where Message has "Assembly.Load" or Message has "InvokeMember"
| project TimeGenerated, Computer, Message
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access