What is Cavern Manticore?

Meet the new kid on the espionage block: a modular command-and-control setup that researchers have nicknamed Cavern Manticore. This toolkit is tied to an Iranian state-linked actor and has been used to poke around IT service providers and government shops in Israel. Think of it as a toolbox with interchangeable bits — a core communicator plus plug-in modules that do the dirty work.

The whole thing is built on a .NET foundation but gets sneaky about how it’s compiled and loaded. The operators mix pure .NET assemblies with mixed-mode C++/CLI and Native AOT components so that analysts have to juggle multiple toolchains to understand what’s happening. The upshot: harder reverse engineering and lower forensic visibility for the folks on the receiving end.

How they get in, what they load, and why it’s clever (and annoying)

This crew favors supply-chain shortcuts. They start with a compromised IT vendor, hop to another provider when convenient, then arrive at the final target — abusing trusted relationships and remote-management tools to move like a ghost through networks. They also sometimes use browser-based remote desktop tricks and even remote printing to slip data out when conventional file transfer paths are blocked.

The main infection route documented used a software updater to trigger a classic Windows trick: DLL side-loading. A trojanized DLL (disguised as a legitimate component) drops the Cavern agent. That agent then pulls in a communication DLL to reach out to a C2 host (reported as hospitalinstallation[.]com) and dynamically fetch additional modules over HTTPS or WebSocket.

  • mhm.dll — file handling: search, archive work, recursive enumeration, and two-way file transfer
  • db.dll — database poking: enumerate SQL instances, run queries, export or tweak data
  • ode.dll — Active Directory reconnaissance: user/group enumeration, LDAP-focused brute-force attempts
  • n-ten.dll — network mapping: port scans, share enumeration, SMB brute attempts
  • n-sws.dll — tunneling and proxying: SOCKS5 and WebSocket-based tunnels

Interestingly, the framework splits responsibilities and compilation styles across modules. Several modules are plain .NET Framework assemblies, while others (including the network and tunneling pieces) are compiled ahead-of-time as native binaries. The agent itself mixes managed .NET code with native C++ bits and runs a dispatcher that treats modules whose names start with “n-” as native libraries (loaded via the usual Windows APIs) and everything else as managed assemblies loaded into separate application domains. This layered approach is part functionality, part anti-analysis trick.

Why you should care (and quick defensive tips)

Beyond the flashy technical details, this campaign highlights two boring-but-critical realities: attackers love trusted suppliers, and they’re getting better at hiding inside legitimate update flows. When an IT provider gets popped, customers often get hit next — so the usual perimeter thinking isn’t enough.

Quick, practical steps defenders should consider:

  • Harden and monitor vendor access: treat third-party admin tools as high-risk assets.
  • Hunt for odd DLLs and unexpected load chains, especially around software updaters and RMM agents.
  • Segment and restrict remote management protocols, and log remote desktop/printing activity.
  • Patch exposed internet-facing services and watch for credential stuffing or brute-force attempts against webmail or OWA endpoints.

Finally, this campaign sits alongside other Iranian-linked activity that has used widespread scanning and known vulnerabilities to harvest credentials and exfiltrate data. Put simply: attackers are mixing broad reconnaissance with surgical follow-ups. If you manage IT services or rely on third-party providers, assume you could be in the line of fire and plan accordingly.