Context on Cavern Manticore’s Reported Overlaps and Techniques
Thanks for sharing this summary. A few points worth adding for context, based on what is publicly known about the groups mentioned:
MuddyWater and Lyceum overlap
Both are established MOIS-linked clusters tracked for years by multiple vendors. MuddyWater is known for heavy use of legitimate remote access tools (including RMM-style utilities) and PowerShell-based loaders, while Lyceum has historically focused on telecom and critical infrastructure targets in the Middle East using DNS-based C2 and custom .NET tooling. Overlapping TTPs between distinct clusters is common in the Iranian threat landscape, since tooling, infrastructure, and even operators are sometimes shared or reused across campaigns, which is why attribution in these cases is usually expressed with moderate rather than high confidence.
RMM abuse as initial access
The trend of abusing already-deployed RMM software for initial foothold is consistent with broader industry reporting over the past few years. Because RMM tools are legitimate, signed, and expected in many corporate environments, they tend to blend in with normal administrative activity and are frequently missed by signature-based detection. Organizations should treat unexpected or unauthorized RMM installations/connections as a high-priority indicator, and restrict RMM usage to known, whitelisted vendor instances with logging enabled.
.NET compilation tricks (Mixed-Mode C++/CLI and Native AOT)
These are legitimate .NET features being repurposed for anti-analysis. Native AOT produces native machine code instead of the usual IL/MSIL, which breaks many standard .NET decompilers (dnSpy, ILSpy, etc.) that expect managed bytecode. Mixed-Mode C++/CLI binaries combine native and managed code in the same assembly, forcing analysts to pivot between disassemblers and decompilers. Per-module AppDomain isolation can also limit what forensic artifacts persist in memory once a module unloads, complicating memory-forensics efforts.
Low VirusTotal detection
Given the compilation techniques described, low or zero detection on first submission is plausible, since many engines still rely heavily on signatures tuned to standard IL-based .NET binaries. This is a good reminder that a clean or near-clean VirusTotal score should never be treated as proof of safety, especially for binaries using uncommon compilation formats.
For anyone encountering suspicious RMM activity or unfamiliar .NET binaries with these characteristics, the safest path is to isolate the host, capture the sample and relevant logs, and submit through the appropriate MalwareTips support section or to your security vendor for deeper analysis rather than relying solely on automated scan results.
