Cavern Manticore Abuses SysAid and WinDirStat DLL Sideloading to Deploy Cavern C2 Framework

Iran-linked threat actor Cavern Manticore has been using trusted IT administration tools and DLL sideloading to deploy a modular command-and-control framework called Cavern against Israeli organizations.

The campaign, documented by Check Point Research, focuses on Israeli government and IT-sector targets. Researchers said the actor abused existing remote monitoring and management access inside victim environments, then used software deployment workflows to move malware across trusted systems.

A key finding is that SysAid itself was not compromised and no SysAid vulnerability was involved. Instead, the attacker had already gained access and abused legitimate deployment functionality connected to SysAid remote support to deliver a malicious WinDirStat package.

How the Cavern Manticore attack works

The observed execution chain starts with a software update mechanism that pushes a bundle containing WinDirStat, a legitimate Windows disk usage utility. The bundle also contains a malicious DLL named uxtheme.dll.

When the legitimate WinDirStat executable runs, it loads the attacker’s uxtheme.dll file instead of the expected legitimate library. That trojanized DLL acts as the Cavern Agent, which then loads a separate communication module named n-HTCommp.dll.

This is a classic sideloading pattern. MITRE ATT&CK describes DLL side-loading as a technique where attackers place a malicious DLL where a legitimate program will load it, causing the trusted application to execute the attacker’s payload.

Stage	Component	Purpose
Initial access	Existing RMM access	Gives attackers a trusted administrative channel
Deployment	SysAid software update feature	Delivers the malicious WinDirStat package
Execution	WinDirStat.exe	Runs as a legitimate application
Sideloading	uxtheme.dll	Loads the Cavern Agent backdoor
Communication	n-HTCommp.dll	Handles C2 traffic over HTTPS or WebSocket
Post-exploitation	Cavern modules	Provides file, database, LDAP, network, and tunneling functions

Cavern is built as a modular C2 framework

Cavern is not a single-purpose backdoor. It is a modular post-exploitation framework built on .NET, with a core agent and separate mission-specific modules.

According to the Check Point report, the framework separates communication from operational tasks. The Cavern Agent coordinates activity, while additional modules can browse files, query databases, enumerate Active Directory data, scan networks, or create tunnels.

The Hacker News also reported that the framework has been linked to attacks on Israeli organizations and attributed to a cluster that shares tactical overlaps with Iranian threat groups such as MuddyWater and Lyceum.

• mhm.dll handles file operations, enumeration, recursive search, archive handling, and file transfer.
• db.dll supports SQL database browsing, query execution, export, and manipulation.
• ode.dll supports LDAP and Active Directory reconnaissance.
• n-ten.dll provides network reconnaissance, port scanning, share enumeration, and SMB brute-force capabilities.
• n-sws.dll provides SOCKS5 proxy and WebSocket tunneling functions.

Why the WinDirStat sideloading chain matters

The attack works because defenders and users generally expect known IT utilities to behave normally. WinDirStat is a legitimate open-source disk usage analyzer for Windows, not malware.

The malicious behavior comes from the surrounding deployment chain and the trojanized DLL placed beside the legitimate executable. This lets attackers hide behind the credibility of the WinDirStat utility while running their own code through a trusted process.

For defenders, that means detection cannot rely only on program names. Process lineage, file paths, recently created folders, unsigned DLLs, and unusual DLL loads matter just as much as the executable itself.

Legitimate element	How attackers abused it	Defensive focus
RMM access	Used as a trusted path to deploy malware	Review administrative actions and deployment logs
Software update workflow	Delivered files that looked like an update package	Validate package sources and approval chains
WinDirStat.exe	Loaded a malicious DLL during execution	Monitor suspicious DLL placement and load events
uxtheme.dll	Masqueraded as a legitimate Windows library	Flag unexpected uxtheme.dll copies outside normal Windows paths
HTTPS or WebSocket traffic	Used for C2 communication	Inspect unusual outbound traffic from admin tools

Anti-analysis choices slow down defenders

Cavern uses three different .NET compilation formats across its components: .NET Framework, Mixed-Mode C++/CLI, and .NET 8 NativeAOT. That forces malware analysts to switch between different reverse-engineering workflows.

Some modules keep readable .NET metadata, while others compile into native-only binaries with stripped symbols and runtime-resolved capabilities. This does not make analysis impossible, but it slows down triage and complicates quick incident response.

The campaign also uses per-module AppDomain isolation and removes modules from memory after execution. That cleanup reduces the amount of evidence available after a module finishes its task.

Targets include Israeli IT and government organizations

Cavern Manticore appears focused on Israeli targets, especially organizations in government and IT services. IT providers matter because they often hold trusted access to other customers and partner environments.

Researchers said they observed cases where the actor moved from an initially compromised IT provider to a second-hop provider before reaching the intended target. This makes the campaign a supply-chain risk as much as a malware story.

The Hacker News report notes that the actor’s use of trusted provider relationships matches the broader value attackers see in software supply chains and managed service environments.

SysAid abuse does not mean SysAid was hacked

The most important operational distinction is that the campaign did not exploit a SysAid vulnerability. The attacker abused access and functionality that already existed in the victim environment.

SysAid’s remote control documentation describes remote support software as a way for IT teams to connect to devices, provide support, and manage sessions. Those same administrative workflows become risky when attackers obtain privileged access or compromise an IT provider.

Security teams should not respond by assuming every RMM product is malicious. They should instead harden access, review who can deploy software, require approvals for high-risk changes, and monitor unusual remote sessions.

1. Review recent RMM software deployment activity, especially updates pushed from IT-provider accounts.
2. Search for unexpected WinDirStat folders or binaries under C:\ProgramData and other writable locations.
3. Flag uxtheme.dll files outside expected Windows system directories.
4. Investigate WinDirStat.exe loading DLLs from the same folder as the executable.
5. Review outbound connections to suspicious domains tied to hospitalinstallation[.]com and related infrastructure.
6. Limit remote access privileges and enforce separate approval for software deployment.

Indicators defenders should prioritize

Static indicators are useful for hunting, but Check Point warns that defenders should also focus on behavior. The actor can change hashes, file names, and infrastructure, while the operational pattern remains more stable.

MITRE ATT&CK’s DLL side-loading technique is the right behavioral lens for this case because the attack depends on a legitimate application loading a malicious DLL from an attacker-controlled location.

Useful hunting points include unexpected uxtheme.dll placement, WinDirStat execution from unusual directories, NativeAOT-style modules, RMM-initiated software deployment, and C2 traffic over HTTPS or WebSocket from systems that normally should not initiate those connections.

Type	Indicator	Description
SHA-256	37e123bd7998af4eae32718ce254776f36365a80ba56952593dab46f536d4066	uxtheme.dll Cavern Agent build 02
SHA-256	92cae0ad7f98f51a14bcc0ee05e372ebdc29ea96ea7bd161bd3f55198767603b	uxtheme.dll Cavern Agent build 04
SHA-256	5dc08bda6919a57a85e5f38b857985fa71529ca39c8299868d5a49a987e19b18	Older uxtheme.dll Cavern Agent build
SHA-256	a4aa217def4c38f4ecacdf47b1cd687f60cc74c18ab75195be3c4357a790bf41	n-HTCommp.dll communication module
SHA-256	b630c96d3763182533d4fb9b614134382bd644cb02c6c1c3ade848b6ecc31e86	n-HTCommp.dll communication module
Domain	hospitalinstallation[.]com	Parent C2 infrastructure domain
Domain	auth.hospitalinstallation[.]com	C2 domain used by older Cavern Agent builds
Domain	google.com.hospitalinstallation[.]com	C2 domain used by newer Cavern Agent builds
File	uxtheme.dll	Trojanized DLL sideloaded by WinDirStat.exe
File	n-HTCommp.dll	Native communication module used for C2 traffic
Mutex	MYMUTEX123HELLP, MYMUTEX123HELLP02, MYMUTEX123HELLP04	Mutex names observed across Cavern Agent builds

What organizations should do now

Organizations that use RMM platforms should review access controls, deployment permissions, and audit logs. The main risk comes from attackers abusing trusted administrative channels after they already have access.

Teams should also build detections around behavior rather than only hashes. A legitimate executable running from an unusual directory and loading a suspicious DLL should trigger investigation, especially when it follows an RMM deployment event.

Cavern Manticore’s campaign shows how attackers can combine trusted IT tools, supply-chain relationships, and custom malware to move quietly. The best defense is strict control over administrative access, fast review of unusual software deployments, and monitoring that connects RMM activity with endpoint behavior.

FAQ