RMM Abuse Isn't the Vulnerability
Why Most "RMM Attacks" Are Really Identity and Trust Failures
Remote Monitoring and Management (RMM) tools have quietly become one of the most abused components in modern intrusions.
They appear in incident reports, SOC escalations, cyber insurance questionnaires, and breach disclosures—often framed as the vulnerability itself:
- "The attacker used ScreenConnect."
- "A rogue RMM was installed."
- "PDQ was abused for persistence."
But here's the uncomfortable truth:
RMM tools are almost never the root vulnerability.
They are the operational layer attackers exploit after trust has already failed.
Just like prompt injection in AI systems, RMM abuse is a delivery mechanism, not the flaw. Treating it as the vulnerability leads to incomplete remediation, false confidence, and attackers quietly regaining access weeks later.
Reframing RMM Abuse the Right Way
From a security architecture perspective, RMM abuse maps cleanly to concepts we already understand.
- RMM ≈ legitimate administrative capability
- The vulnerability ≈ unsafe trust, identity, and authorization boundaries
- The impact ≈ persistence, lateral movement, and data access
We don't report PowerShell as a vulnerability.
We report what PowerShell was allowed to do without controls.
RMM tools deserve the same treatment.
What Attackers Are Actually Doing
Across real-world intrusions investigated by SOCs and IR teams, the pattern is consistent:
- Initial access via phishing, stolen credentials, MFA fatigue, or OAuth abuse
- Installation of a signed, legitimate RMM tool
- Use of that RMM to deploy a secondary (or tertiary) RMM
- Layered persistence that survives partial cleanup
This is not accidental or opportunistic.
It is deliberate tradecraft.
Attackers are borrowing from classic command-and-control design principles—redundancy, fallback access, and operator flexibility—but implementing them with commercial software defenders are trained to trust.
Real-World Example: Multi-RMM Chaining in the Wild
In multiple documented incidents:
- A phishing lure installs GoTo Resolve
- GoTo Resolve is used to deploy ScreenConnect
- ScreenConnect installs SimpleHelp or another RMM
- Each RMM connects to a different attacker-controlled domain
This works because most incident response efforts stop at:
"We removed the suspicious RMM."
Attackers assume—correctly—that defenders won't hunt for the second one.
This is persistence through defender fatigue, not technical sophistication.
When RMM Fails Without an Attacker: The NinjaOne Update Incident
RMM risk isn't limited to adversaries.
In 2024, a faulty NinjaOne update caused widespread endpoint issues, corrupting RMM functionality and disrupting managed environments. Systems lost management capabilities, remediation required manual intervention, and MSPs were forced into emergency response mode.
No attacker was involved.
Yet the impact was real:
- Centralized control failed
- Endpoints entered inconsistent states
- Recovery required hands-on effort at scale
This incident exposed an uncomfortable reality: RMM tools are single points of operational failure.
Whether abused by attackers or broken by updates, RMM platforms carry blast-radius risk that most organizations do not formally model.
Why "Multiple RMMs" Is a Critical Signal
When defenders discover more than one RMM present, it is often rationalized as:
- Legacy tooling
- Vendor leftovers
- MSP sprawl
Attackers rely on that ambiguity.
Multiple RMMs provide:
- Persistence layering
- Tool specialization
- Detection evasion
- Operator flexibility
This is living-off-the-land, not malware delivery.
The Real Vulnerabilities Behind RMM Abuse
In the vast majority of cases, the root causes are architectural, not tool-specific.
No RMM Trust Model
Most organizations cannot answer:
- Which RMM tools are authorized
- Who owns them
- Where they are allowed to be installed
- Which domains they should communicate with
Without a trust model, defenders cannot distinguish legitimate remote access from hostile persistence.
Installation Context Is Ignored
High-confidence malicious indicators routinely missed:
- RMM installed from Downloads or Temp
- RMM installed immediately after phishing
- RMM installing another RMM
- RMM calling newly registered or consumer-style domains
These are incident-level signals, not hygiene alerts.
Identity Is Treated as "Solved"
RMM abuse almost always follows credential compromise.
If an attacker can authenticate, install signed software, and register persistence, identity controls—not endpoint tooling—have already failed.
RMM simply makes that failure durable.
Why Blocking RMMs Alone Doesn't Work
Blocking RMM software fails because:
- Many RMMs are operationally required
- Attackers rotate tools faster than blocklists
- Binary blocking ignores how access was gained
This mirrors the mistake of blocking macros instead of fixing macro trust.
Where the Real Fixes Live
Effective defense focuses on trust boundaries, not software names.
Treat RMM as Privileged Infrastructure
Govern RMM like:
- Domain admin access
- VPN concentrators
- Vendor remote access
Require explicit approval, ownership, auditing, and removal on role change.
Detect Abuse by Behavior, Not Presence
High-signal behaviors include:
- RMM installing another RMM
- RMM launching scripting engines
- RMM calling non-business domains
- RMM appearing on endpoints that never needed remote access
These should trigger containment—not ticket creation.
The Bottom Line
RMM abuse isn't going away.
Eliminating RMM tools is as unrealistic as eliminating administrative access.
The real security question is:
What happens when a trusted tool is abused—or fails?
If the answer is "we detect and contain it quickly," your architecture is sound.
If the answer is "we'd probably miss it," the vulnerability isn't the RMM.
It's the system design.
SecureStepPartner Perspective
Security controls should not rely on trusted tools behaving correctly. They should assume those tools will eventually be abused—or break.
Related Insights
Assess Your Security Posture
Identify architectural trust gaps across your IT, OT, and cloud environments.