Why do attackers use multiple RMM tools on the same host?

Why This Matters for Security Teams

Multiple remote monitoring and management tools on the same host usually indicate deliberate redundancy, not convenience. Attackers often want a fallback path if one product is detected, blocked, or removed, and that pattern can reveal how seriously they expect defenders to respond. It also complicates containment, because different RMM products may use different services, installers, update channels, and remote execution methods. NIST guidance on access control and system monitoring in NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful anchor for judging whether remote administration is authorised, monitored, and limited.

The security risk is not just persistence. A host with several RMM agents can blur the line between legitimate administration and adversary activity, especially in organisations that already use remote support tools. That is why defenders should look for tool combinations, install timing, service names, and outbound connections rather than relying on any single signature. The MITRE ATT&CK Enterprise Matrix is helpful here because it frames remote services, persistence, and valid account use as linked behaviours, not isolated events. In practice, many security teams encounter the second RMM only after the first one has already been blocked, rather than through intentional asset and software inventory controls.

How It Works in Practice

In real intrusions, multiple RMM tools are often installed to hedge against control failure. One tool may be used for initial access, another for persistence, and a third as a backup if endpoint controls or security teams remove the first. Some operators also mix widely known tools with niche or renamed binaries to reduce the chance that a single blocklist or detection rule will disrupt their access. This is especially common where defenders depend on static signatures or on allowlisting that is too broad.

For defenders, the practical workflow is to treat unexpected RMM presence as both a software inventory issue and a threat-hunting lead. Useful checks include:

• Confirm whether each RMM agent is approved for that host, user, and business unit.
• Compare install times, service creation events, and scheduled task activity to change tickets.
• Inspect outbound connections, especially to remote support infrastructure not normally used in the environment.
• Correlate local admin use, new services, and remote execution with endpoint and SIEM telemetry.

Threat hunters should also separate legitimate IT support from adversary tradecraft by looking at context, not just tool name. The CISA cyber threat advisories and the ATT&CK technique catalogue can help map how remote access, persistence, and defense evasion tend to appear together. Where AI-assisted operations are involved, the pattern can become even more adaptive, as described in Anthropic’s first AI-orchestrated cyber espionage campaign report, which highlights how operators iterate rapidly when one route is disrupted. These controls tend to break down when remote support tooling is already normalised across many teams because alert fatigue makes a malicious second agent look like routine administration.

Common Variations and Edge Cases

Tighter control over RMM software often increases operational overhead, requiring organisations to balance remote support speed against containment and auditability. That tradeoff is real in managed services, distributed workplaces, and incident response, where staff may need fast remote access to endpoints that are offline from the corporate network.

Best practice is evolving for how much RMM diversity is acceptable. Some environments allow only one sanctioned tool, while others permit several products for business reasons but require strict device scoping, signed installers, and continuous logging. There is no universal standard for this yet, but guidance consistently points toward inventory accuracy, least privilege, and rapid revocation when a tool appears outside policy.

Edge cases matter. A host may legitimately run more than one remote support platform during migration, vendor handover, or break-glass operations. However, that should be time-bound and documented. If the environment includes agentic automation or AI-assisted response workflows, additional care is needed because the control plane itself can become a target. Current guidance suggests treating tool sprawl as a governance problem first and a malware indicator second. The MITRE ATLAS adversarial AI threat matrix is relevant where automation is used to select, deploy, or retry access methods, but it should not be overstated for purely conventional RMM abuse.

Related resources from NHI Mgmt Group

• How should security teams govern AI workflows that use multiple tools and data sources?
• What breaks when multiple people use the same shared account password?
• What breaks when ransomware attackers can use legitimate admin tools inside the network?
• Why do RMM tools help attackers in cargo theft campaigns?