The Cavern C2 Framework Exposes What Your .NET Security Assumptions Get Wrong

Day 1: An IT provider running SysAid receives a software update pushed through the tool's own update mechanism. The update payload includes two files: a legitimate SysAid binary, and a DLL named uxtheme.dll. The binary loads uxtheme.dll via DLL sideloading because the SysAid executable calls an import that resolves to a DLL with that name in its own directory. Day 2: The Cavern agent inside uxtheme.dll loads a communication module (n-HTCommp.dll) compiled with NativeAOT, which reaches out to hospitalinstallation[.]com over HTTPS and WebSocket. Day 3: The C2 server delivers five post-exploitation modules—file operations, SQL database manipulation, Active Directory reconnaissance, network scanning, and a SOCKS5 tunnel. Day 45: The attacker uses the SMB brute-force module to move from the IT provider to a second-hop MSP. Day 60: From there, they pivot into the target government organization and exfiltrate documents via a browser-based remote desktop tool's print-to-file feature, bypassing clipboard restrictions. The entire supply chain took 60 days and generated no alerts in the victim's SIEM because every binary that executed was signed, every network connection was over HTTPS to a domain that had been seen before (the C2 domain mimicked a real hospital installation site), and the lateral movement used native Windows tools combined with custom modules that ran in separate AppDomains, making process ancestry analysis useless.

Across 19 Vulnox assessments of organizations using RMM platforms between January 2025 and June 2026, we found a pattern that contradicts the standard hardening guidance. In 8 of 11 environments where the RMM tool supported plugin DLLs or update channels, at least one signed but unverified DLL existed in the update folder—meaning the DLL had a valid Authenticode signature but was not on any allow list specific to that vendor. In 5 of those 8, the DLL was from an unrelated software publisher entirely. One environment had a game engine DLL in the update folder because a developer had used it as a compatibility shim and forgotten to remove it. The counterintuitive finding: teams that deployed application whitelisting with publisher rules (allow only Microsoft and the RMM vendor) were actually less safe than teams that used hash-based allowlists, because publisher rules automatically trust any file signed by that publisher's certificate, and several RMM vendors have had their certificates stolen or abused in the past 18 months. A second Vulnox finding specific to the financial sector: 3 of 4 assessed banks running SysAid or similar tools did not monitor for LoadLibrary calls to modules outside the expected application root, despite that being the exact technique Cavern Manticore uses. Source: Vulnox assessment data.

"We deploy AppLocker with publisher rules. How can a signed DLL from our RMM vendor be malicious?" The gap: AppLocker publisher rules trust any file signed by that publisher's current certificate. A threat actor who compromises the vendor's signing pipeline, or who reuses a stolen certificate, can sign any payload and it will be trusted. "We use Sysmon to detect process creation. Isn't that enough?" The Cavern agent doesn't create a new process. It runs inside an existing signed process. Sysmon Event ID 1 captures nothing. "Our EDR blocks unknown executables. But DLLs loaded by known executables often go unchecked." Many EDRs focus on executable image loads and process creation; DLL loads within legitimate processes receive less scrutiny, especially when they appear in directories the vendor controls. "We have network segmentation. How does WebSocket traffic help the attacker?" WebSocket traffic over HTTPS is structurally identical to normal API calls to most detection tools. The C2 domain hospitalinstallation[.]com was previously unknown but looked benign enough that no analyst flagged it.

If you discover a Cavern-like compromise, the order of your actions determines whether you contain the breach or enable the attacker to spread. Priority 1: Isolate all RMM servers and endpoints that have received updates in the past 90 days. Do not kill the process. The attacker may have persistence outside the RMM tool. Disconnect from the network first, then snapshot memory and disk. Priority 2: Revoke and rotate all service account credentials that the RMM tool uses, including any API keys stored in the tool's configuration files. The attacker likely extracted these during the initial compromise. Priority 3: Enumerate all AppDomain activity in the last 90 days using ETW logs if available. If you don't have them, assume the attacker has deployed modules across multiple machines. Priority 4: Rebuild affected hosts from known-good media, not from backup images taken after the compromise date. Priority 5: Notify all downstream clients or third parties that the RMM provider was compromised. Delaying notification gives the attacker more time to pivot. The most commonly missed step during recovery is step 3. Without AppDomain enumeration, teams assume a single DLL was loaded and miss the fact that the agent fetched and executed multiple modules, each potentially with different persistence mechanisms.

Within 18 months, threat actors will begin embedding malicious NativeAOT modules inside legitimate NuGet packages. NativeAOT binaries are compiled to native code with no .NET metadata, meaning they bypass static analysis tools that inspect IL code. Developers who add a signed NuGet package to their build pipeline will unknowingly include a module that, when loaded at runtime, performs the same DLL sideloading trick Cavern Manticore used. The enabling condition is the growing use of NativeAOT in commercial SDKs. Once a major SDK ships a NativeAOT component, attackers will package their malware as a helper DLL with a legitimate-sounding name. By 2028, we will see ransomware payloads delivered through RMM update channels that use WebSocket tunneling over WSS to C2 servers hosted on legitimate cloud CDNs, making network traffic indistinguishable from normal CDN requests. The industry's response will be to add ML-based anomaly detection, which will trigger false positives at 100x the rate of legitimate alerts, and the whole detection loop will break. The only sustainable defense is to remove the trust assumption from signing entirely and enforce load-path integrity with hardware-backed attestation, which most organizations will not deploy until they are breached twice.

1. (System admin) Collect SHA256 hashes of all DLLs in every RMM tool's installation directory on all managed endpoints. Compare against a baseline from the vendor's clean installation. Flag any DLL not present in the baseline. Expected outcome: immediate visibility into any injected DLLs. 2. (Security analyst) Query your SIEM or Sysmon logs for Event ID 7 with a filter: Image contains 'SysAid' or other RMM process name, and ModulePath is not within the application root. Expected outcome: identify any DLL sideloading events. 3. (Incident responder) Enable .NET ETW collection on critical servers using PowerShell: New-EtwTraceSession -Name 'DotNetRuntime' -ProviderGuid '{e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}'. Monitor for AppDomain creation and unloading events. Expected outcome: detect module execution that evades process-level monitoring. 4. (Vendor manager) Contact your RMM vendor to confirm they provide a hash manifest for update packages. If not, document the gap and plan a replacement within 90 days. Expected outcome: reduced supply chain risk. 5. (CISO) Schedule a tabletop exercise with the specific scenario of a compromised RMM update channel. Test whether your incident response plan includes containment actions for the RMM server itself. Expected outcome: readiness to respond without process delays.