RMM Abuse Is Now the #1 Endpoint Threat, And It's Using the Same Tools Your MSP Runs On

What Happened

Huntress published its inaugural "Tragic Quadrant" report this week, mapping the cyber risks doing the most damage to MSPs and the clients behind them [1][3]. The headline finding is not a new malware family or a clever zero-day. It is something far more uncomfortable for the channel: RMM abuse is now behind 45% of endpoint incidents tracked in the report [2][4][5].

That statistic should land hard for anyone reading this on an MSP dashboard. RMM tools are not shadow IT. They are the software your team installed on purpose, the connection your techs use to patch a server at 2 a.m., the access path baked into your service delivery model. Attackers have noticed that this access path, once compromised, looks exactly like a Tuesday.

This is not a surprise to anyone who has followed CISA's guidance. The agency first warned about malicious use of legitimate remote monitoring and management software back in 2023 [19], and it reiterated that warning again just weeks ago [20]. What has changed is the scale. RMM abuse has gone from "a threat to watch" to the single largest category of endpoint incidents MSPs are dealing with, according to this new data [2].

The tooling itself has not made this easier. ConnectWise ScreenConnect, one of the most widely deployed RMM platforms in the MSP market, has had a string of serious vulnerabilities land in the CISA Known Exploited Vulnerabilities catalog, including CVE-2025-3935 [10] and CVE-2026-3564 [11]. ConnectWise also disclosed a 2025 breach suspected to involve a nation-state actor [12]. None of this means ScreenConnect is uniquely bad. It means the most popular RMM platforms are also the most attractive targets, and every MSP running one needs to treat it like the internet-facing, privilege-rich software it actually is.

Why RMM Abuse Is So Hard to Catch

Here is the uncomfortable mechanic underneath the 45% figure: a compromised RMM session and a legitimate one generate nearly identical telemetry. Same binary. Same network path. Same admin-level actions, file transfers, script execution, remote desktop control. The difference is intent, and intent does not show up in a log line.

Most detection stacks are tuned to flag anomalies, new processes, unusual outbound connections, credential misuse. A skilled attacker using your own RMM tool against your own client doesn't trip any of that. They are not bringing malware. They are bringing your software, your protocol, your expected traffic pattern. The alert, if one fires at all, looks like routine admin work and gets triaged into the noise.

This is the core problem the Huntress data is pointing at. It is not that MSPs lack visibility into RMM traffic. It is that visibility without context produces a false negative dressed up as business as usual.

What a Partner Should Actually Do About It

A few things are within direct control right now, before the next incident report names your tool stack:

Build and maintain an approved-tool baseline per client. Know exactly which RMM platform, which version, and which admin accounts are supposed to be touching each environment. Anything outside that baseline is a signal, not noise.

Patch the RMM stack like it's internet-facing, because it is. The CVE history on major RMM platforms [10][11][13][15] is a reminder that the tool itself is a target, not just a conduit.

Require MFA and full session logging on every RMM connection, including the ones your own techs use. If you can't tell your session from an attacker's by looking at the log, neither can your SOC.

Limit standing privileged access. Just-in-time elevation beats permanent admin rights sitting in an RMM agent waiting to be hijacked.

Get a second set of eyes that knows the difference between your admin and someone else's. This is the part most stacks miss, and it's where detection tooling alone runs out of road.

The Vijilan Connection: Where Alerting Stops and Containment Starts

Here is the part that actually changes the outcome. Rogue RMM activity looks identical to legitimate administrative work in logs and in most alerting pipelines. A tool built to flag anomalies will often wave this through, because nothing about it is technically anomalous. It is a known binary doing known things.

What catches it is context a generic detection rule doesn't have: knowledge of what normal looks like for that specific client, that specific tech team, that specific RMM deployment. That's the approved-tool baseline our Global SOC maintains per client, correlated against identity, endpoint, and network telemetry inside ThreatRespond™, our Managed XDR service. When a session shows up outside that baseline, whether it's an unfamiliar admin account, an RMM binary installed somewhere it shouldn't be, or a connection pattern that doesn't match the client's known operations, the SOC doesn't just generate another alert for someone to maybe see on Monday.

It acts. That means killing the session and isolating the endpoint, containment steps taken by analysts with the authority and the client context to act, not a notification that sits in a queue hoping a human notices it before the attacker moves laterally. That distinction, detection with containment versus detection with a ticket, is exactly the gap the Huntress data is describing when it says RMM abuse drives nearly half of endpoint incidents. Somewhere in that 45%, an alert almost certainly fired. The question is whether anyone, or anything, was positioned to act on it.

For partners running their own stack, this slots in as a layer on top of what you already deliver, white-labeled under your brand, with the Global SOC watching for exactly this kind of blend-in activity around the clock. We never compete with our partners for their clients. We exist to catch what their own stack's alert fatigue lets through.

What This Means for Partners This Week

If you're an MSP reading the Huntress numbers and wondering where you stand, start with the baseline question: do you actually know, documented and current, which RMM tools and accounts are approved for every client you manage? If that list lives in someone's head instead of a system, that's the first gap to close, and it's the one attackers are counting on.

Build the list. Patch the stack. Then make sure something or someone is watching for the session that doesn't belong on it, and is authorized to shut it down the moment it shows up.

If you want to talk through how a Global SOC and ThreatRespond™ fit alongside your existing RMM and endpoint tooling, visit our MSP page. Pricing questions go to our pricing page.

Frequently asked questions

What is RMM abuse?

RMM abuse is when an attacker uses legitimate remote monitoring and management software, the same tools MSPs use to manage client endpoints, to gain or maintain access instead of deploying custom malware. Because the tool is legitimate and already trusted in the environment, the activity often blends in with normal administrative work.

Why is RMM abuse hard to detect?

A compromised RMM session generates the same type of telemetry as a legitimate one: same binary, same network behavior, same admin-level actions. Detection tools tuned for anomalies often don't flag it because nothing about the traffic pattern looks unusual on its own.

How common is RMM abuse right now?

A recent industry report found RMM abuse behind 45% of endpoint incidents, making it the leading category of endpoint threat tracked in that data [2].

What can an MSP do to reduce RMM abuse risk?

Maintain a documented, per-client baseline of approved RMM tools and accounts, require MFA and full session logging on RMM access, patch the RMM platform itself as a priority target, limit standing admin privileges, and ensure a monitoring team can take containment action, not just generate an alert, when activity falls outside the baseline.

How does Vijilan help with RMM abuse specifically?

Vijilan's Global SOC maintains an approved-tool baseline for each client and correlates RMM session activity against it through ThreatRespond™, our Managed XDR service. When activity falls outside that baseline, the SOC can take containment action directly, including killing the session and isolating the endpoint, rather than passing through a noisy alert.