Weaponized RMM: Hunting the Adversary Abuse of Remote Monitoring Tools

Remote monitoring and management tools are now a standard access and persistence layer in hands-on intrusions. Adversaries increasingly use legitimate remote admin tools instead of custom malware to establish access, maintain persistence, move laterally, and stage follow-on activity over trusted software and network paths.

Huntress reported a 277% year-over-year increase in RMM abuse, with RMM involved in 24% of incidents in its 2026 reporting. ReliaQuest observed RMM tooling in over a third of intrusions from 2022 to 2024. Recent phishing-to-RMM campaigns now deliver legitimate remote access clients directly as the initial access vector, not just as a secondary tool.

Why RMM Tools Are a Preferred Adversary Primitive

RMM tools deliver remote-access trojan functionality through legitimate software: desktop control, file transfer, shell access, task execution, software deployment, and persistent services. This makes them attractive for hands-on intrusions where an operator directs activity within the environment.

Installers are usually trusted by users and security controls, reducing friction during execution. Traffic is encrypted. Cloud-relayed sessions may traverse vendor infrastructure, while self-hosted deployments, such as on-prem ScreenConnect or SimpleHelp, terminate on attacker-controlled servers. Once a host is enrolled in an attacker-controlled tenant or server, the operator gains access to a management plane for persistence, file movement, remote execution, and multi-host deployment.

In many intrusions, the RMM client replaces the need for a custom implant. It acts as both access and persistence, and often as the session channel for command execution and file transfer. In some cases, RMM is only used for initial access, with separate post-exploitation tooling added later.

Threat Landscape: Actors, Tools, and Documented Campaigns

Let’s take a look at what public reporting reveals about RMM abuse. The data points to a recurring group of tools, recognizable actor behaviors, and well-established delivery methods.

Commonly Abused RMM Platforms

A small set of commercial remote-support products appears repeatedly across threat reporting, phishing research, and state-linked intrusions.

Threat Actor Mapping

RMM abuse spans financially motivated intrusions, access brokers, fraud, and state-linked operations.

Trends in RMM Abuse

Three patterns stand out. First, direct RMM delivery in phishing chains: phishing pages, PDFs, and invitation lures deliver RMM installers directly, not traditional loaders. Second, multi-RMM redundancy: operators install multiple tools on the same host to survive partial remediation. Third, exploitation of exposed RMM infrastructure, especially ScreenConnect and SimpleHelp, turning trusted admin products into intrusion infrastructure.

A recent invitation-themed phishing campaign reporting documented roughly 160 suspicious links and approximately 80 phishing domains, primarily targeting U.S. organizations in education, banking, government, technology, and healthcare. That infrastructure is used for credential theft and, in some clusters, to deliver ScreenConnect, ITarian, Datto RMM, and related remote access tools.

Attack Chain: Delivery to Impact

RMM abuse attack chain from delivery to operator control

1. Delivery Vectors

Phishing is still the main delivery vector. Invoice, payment, support, contract, and invitation themes drive victims to open PDFs, click links, or run MSI/EXE installers that deploy RMM clients. Social engineering over phone and collaboration platforms normalizes RMM installation as part of support or problem resolution, as seen in Storm-1811 operations using Quick Assist and other remote tools.

Actors also use SEO poisoning, malvertising, and fake software portals to distribute weaponized RMM installers. When RMM servers are exposed, exploitation of ScreenConnect and SimpleHelp can replace phishing as the initial access vector.

2. Execution and Installation Tradecraft

Operators rarely modify RMM binaries. They stage legitimate installers, suppress user warnings, and use native tooling to enroll endpoints into attacker-controlled tenants or servers.

Common patterns include silent msiexec.exe execution from user-writable directories, renamed installers that look like invoices or updates, and script wrappers that disable SmartScreen or strip Mark-of-the-Web. Landing pages often trigger or prompt the download directly, instructing the victim to open the installer to view a document or invitation.

3. Persistence, Privilege Inheritance, and Lateral Movement

RMM agents are persistent by design. Once installed, they register as services, start automatically, and provide unattended access across reboots. Operators reinforce persistence by layering additional remote tools or using scheduled tasks and deployment functions.

Privilege escalation is often not a separate stage. The victim runs the installer with sufficient rights or is guided through prompts, so the agent runs as local admin or SYSTEM. Lateral movement uses the platform’s features: remote shell, deployment, file transfer, and pivoting into RDP, SMB, or other management paths.

4. Command and Control (C2)

In most RMM abuse cases, the platform itself carries the operator session. Desktop access, command execution, file transfer, and scripting occur over encrypted connections to vendor relays or attacker-controlled infrastructure. This is the dominant pattern in phishing-to-RMM and fraud activity where no separate malware beacon is present.

This model is not universal. Some intrusions use RMM only for initial access and persistence, then add separate tooling like Cobalt Strike or Meterpreter for later-stage C2, credential theft, and ransomware. In those cases, RMM remains an access channel and fallback, but not the only C2 mechanism.

Malicious vs. Legitimate RMM Use

Tool name alone rarely distinguishes malicious from legitimate use. The real differentiators are deployment context, account or tenant ownership, process ancestry, adjacent activity, and timing.

The operational test: if RMM installation matches inventory, approved accounts, expected process lineage, and routine timing, it is likely legitimate. If it appears after a lure, runs from user-writable paths, lands in an unapproved tenant, and is followed by discovery or payload staging, treat it as malicious until proven otherwise.

RMM Phishing Infrastructure Discovery via Netlas

Netlas query pivot for ScreenConnect.ClientSetup.msi references

The first pivot was the payload reference. This Netlas search surfaced partycelebrates[.]cfd, where the lure page is built to push a ScreenConnect installer behind an invitation-themed front end.

http.body:"ScreenConnect.ClientSetup.msi"

The page title, Elegant Invitation, is part of the lure template reuse and is useful as a secondary pivot for related infrastructure.

The code uses a staged download routine with a primary auto-download path and fallback logic, including the tryAutoDownload and manualDownload handling observed in the page logic. That pattern matters because it gives a stable fingerprint for hunting: invitation-themed content on the surface, but download orchestration underneath.

Suspicious staged download indicators in the lure page source

The HTML exhibits staged download orchestration with fallback navigation consistent with active payload delivery. The detected pattern includes blob URL cleanup via URL.revokeObjectURL(objectUrl) and a last-resort window.location.assign(...) fallback when earlier download mechanisms fail. This behavior is more consistent with payload delivery than static invitation content.

SmartScreen warning for the ScreenConnect installer delivery page

Microsoft Defender SmartScreen is already blocking ScreenConnect.ClientSetup.msi as unsafe, which is consistent with a direct installer-delivery flow rather than a benign invitation page.

Netlas title pivot for Elegant Invitation lure infrastructure

The Elegant Invitation page title observed on partycelebrates[.]cfd was then used as the next Netlas pivot to identify other infrastructure reusing the same front-end template.

http.title:"Elegant Invitation"

VirusTotal score for lovingcelebarates at the time of analysis

lovingcelebarates[.]my was among the results. At the time of analysis, the domain returned a clean VirusTotal score of 0/91, making it operationally significant as an active delivery page not yet detected.

GitHub raw content URL used as RMM payload hosting

The critical structural difference from the previous domain is the payload source. Where partycelebrates[.]cfd hardcoded ScreenConnect.ClientSetup.msi as a local or relative reference, lovingcelebarates[.]my sets const FILE_NAME to a GitHub raw content URL.

The delivery logic is structurally identical to Case 1 (i.e. partycelebrates[.]cfd)— the same tryAutoDownload() and manualDownload pattern, the same three-stage fallback sequence: hidden anchor click, hidden iframe, then fetch-to-blob with URL.revokeObjectURL(objectUrl) on a 10-second timer, and a final fallback to window.location.assign(url) if all else fails.

Direct curl retrieval of the GitHub-hosted MSI payload

The MSI was fetched directly from the GitHub raw URL using curl.

Sandbox analysis of the Elegant invite party MSI payload

Sandbox analysis of invite_sample.msi (Elegant invite party.msi) produced a threat score of 35/100 and an AV verdict of “marked as clean”, consistent with the VirusTotal score and confirming that at the time of analysis, the payload was evading static detection.

Comparison with partycelebrates[.]cfd

Additional Elegant Invitation infrastructure discovered through title pivoting

VirusTotal score for parinvits at the time of analysis

The Elegant Invitation title pivot expanded to parinvits[.]top, which uses the same staged delivery pattern but with a different GitHub raw payload path, weber7221/mnb/raw/refs/heads/main/partyinvit.msi, indicating the same kit with a new hosting path. At the time of analysis, the domain returned a clean VirusTotal score of 0/91, but the payload (Partyinvit.msi) had a threat score of 100/100.

Sandbox analysis of the partyinvit MSI payload

Indicators of Compromise (IoC)

Domains:

partycelebrates[.]cfd

lovingcelebarates[.]my

parinvits[.]top

Payload URL for Elegant invite party.msi:

https://github.com/cyygyzz/Eleg/raw/refs/heads/main/Elegant%20invite%20party.msi

SHA256 for Elegant invite party.msi:

f3bd3ed1971345b9bfb32028747963009be5746324ac4d574ea984c58dfea511

Payload URL for Partyinvit.msi:

https://github.com/weber7221/mnb/raw/refs/heads/main/partyinvit.msi

SHA256 for Partyinvit.msi:

260791a1d346a4a29665b34f1c38e4b21285aa51715f26eacaee6d13799d2759

Netlas Hunt Queries To Explore

The following Netlas hunt queries use unique, high-confidence attributes tied to observed RMM phishing campaigns. Use these as starting points for hunting adversary abuse of remote monitoring tools.

Query 1: Open Directory RMM Staging

(http.title:"Index of" OR http.title:"Directory listing for /") AND (http.body:"ClientSetup.msi" OR http.body:"AteraAgent.msi" OR http.body:"AnyDesk.exe" OR http.body:"TeamViewer" OR http.body:"SimpleHelp" OR http.body:"Splashtop") NOT domain:*connectwise.com NOT domain:*atera.com NOT domain:*anydesk.com

What it detects: Surfaces open directory listings exposing RMM installer files on non-vendor infrastructure.

Query 2: GitHub Raw-Hosted RMM Payloads.

http.body:"github.com" AND http.body:"raw" AND (http.body:"ClientSetup.msi" OR http.body:"AteraAgent.msi" OR http.body:"AnyDesk.exe" OR http.body:"ScreenConnect")

What it detects: Pages using GitHub raw content URLs to stage RMM installers, matching the hosting pattern seen in lovingcelebarates[.]my and parinvits[.]top.

Query 3: Adobe Acrobat-themed lure.

(http.title:"Adobe Acrobat" OR http.title:"Adobe Reader" OR http.title:"Adobe Acrobat Reader DC") AND (http.body:"tryAutoDownload" OR http.body:"manualDownload" OR http.body:"ScreenConnect.ClientSetup.msi" OR http.body:"ClientSetup.msi")

What it detects: Adobe Acrobat-themed lures delivering ScreenConnect.ClientSetup.msi, used in phishing-to-RMM chains where a fake document or reader page prompts the victim to download a ScreenConnect installer.

MITRE ATT&CK Mapping

Defensive Recommendations

The goal is not to ban all RMM use. The objective is to reduce unsanctioned deployment, restrict tenant or server abuse, and make malicious use visible.

Preventive controls:

• Maintain an approved inventory of RMM tools, tenants, relay domains, and self-hosted servers, and treat all non-inventory RMM detections as incidents.
• Restrict execution of .msi and .exe payloads from user-writable locations and enforce WDAC/AppLocker for approved publishers and paths.
• Patch and restrict internet exposure of ScreenConnect and SimpleHelp servers; limit admin interfaces to trusted networks.
• Require MFA and corporate-domain identities for sanctioned RMM administration.

Detection engineering:

• Alert on RMM installation from browser, mail, PDF, or script-derived process trees, especially where msiexec.exe launches from %TEMP%, %Downloads%, or %ProgramData% shortly after user interaction.
• Detect multiple distinct RMM products appearing on a single host in a short interval of time.
• Monitor for newly enrolled endpoints under unknown tenants, disposable identities, or unusual geographies where vendor telemetry is available.
• Hunt for invitation-themed auto-download pages and RMM file names in web, and internet-wide scans.

Incident response:

• Enumerate all RMM agents, services, tasks, and associated tenants or servers on affected hosts before removal to preserve evidence.
• Disable or suspend attacker-controlled tenants or servers where possible and isolate enrolled endpoints.
• Reconstruct install provenance: lure, landing page, download source, installer hash, tenant or server registration, and first operator activity.
• Remove unauthorized agents and persistence, then rotate credentials for affected users and admin paths.

Conclusion

RMM abuse is now a repeatable initial access pattern: phishing lures, branded download pages, and staged MSI delivery feed legitimate tools that give operators remote control inside the target environment. The Netlas cases show the same tradecraft: invitation-themed pages, GitHub-hosted payloads, and auto-download logic pushing ScreenConnect and related installers into victim workflows.

The detection problem is not the installer itself, but the context around it. Defenders should baseline approved RMM use, treat unsanctioned installs or unknown tenants as incidents, and hunt for lure, staging, and process-tree signals that separate malicious delivery from normal admin activity.

I can show you how deep the Internet really goes

Discover exposed assets, infrastructure links, and threat surfaces across the global Internet.

Request Free Trial Explore Free Plan