Trusted Software, Unauthorized Access: The Security Risk Behind RMM Tool Abuse
Not every persistent threat looks like malware. Sometimes it looks like IT administration.
Microsoft recently documented phishing campaigns in which attackers used legitimate remote monitoring and management software to establish access, then deployed a second legitimate remote-access platform as a redundant channel. The result: attacker activity that could blend into ordinary administrative operations. In new threat research published September 29, Microsoft detailed phishing campaigns that used a legitimate MSP360 RMM installer to gain a foothold and then deploy ConnectWise ScreenConnect as a second remote-access channel. The result was redundant access through software that can resemble ordinary IT activity.
The lesson is broader than one campaign. Legitimate software can still create unauthorized access. Organizations need to know which remote management tools are approved, where they may run, who can operate them, and what normal activity looks like.
What Microsoft Observed in the Campaign
Microsoft observed the activity in July 2026 across multiple industries. Phishing lures imitated meeting invitations, Zoom and Google Meet installers, Adobe and PDF updates, RSVP messages, job offers, document-signing requests, and delivery notifications.
Behind the deceptive filenames was a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer. When a user ran the file and approved the User Account Control prompt, the software installed services and autorun entries that provided persistent remote-management access.
The MSP360 agent then launched PowerShell, downloaded a ScreenConnect installer, and installed it silently. This gave the attacker a second channel independent of the first. Microsoft observed ScreenConnect being used to transfer and execute additional tools supporting credential access, information collection, and other post-compromise activity.
Microsoft did not report exploitation of a ScreenConnect vulnerability. The attacker abused legitimate remote administration software. Microsoft also observed a variation involving Faronics Deploy Agent before ScreenConnect, reinforcing that this is not a single-product problem.
How Attackers Abuse RMM Tools for Persistence
RMM tool abuse is difficult to detect because the software may be signed, reputable, and familiar to administrators. Its encrypted traffic can resemble normal support activity. Its services can survive restarts, and its built-in scripting, file-transfer, and remote-command features reduce the need for custom malware.
A second RMM product also creates resilience for the attacker. Removing the first agent does not end the intrusion if another remote-access channel remains active.
MITRE ATT&CK tracks this behavior as T1219, Remote Access Tools. The technique recognizes that adversaries may use legitimate remote access software for command and control, alternate communications, and redundant access.
A valid digital signature can help confirm who published a file. It does not prove that the installation was requested, the connected tenant is approved, the operator is authorized, or the activity serves a legitimate business purpose.
Trusted software ≠ trusted behavior.
Govern RMM Tools as Privileged Access
An RMM platform is an administrative control plane with the ability to act across systems. Organizations should govern it with the same discipline applied to privileged identities. Treat RMM as privileged infrastructure, not ordinary software.
Organizations should treat the approved configuration as a security baseline, not a one-time software list. Changes outside that baseline should trigger investigation, especially when an RMM agent launches PowerShell, installs another remote-access tool, or connects to unknown infrastructure. This gives security teams a practical way to distinguish legitimate administration from attacker-controlled use without blocking the remote support capabilities the business depends on.
How to Detect Unauthorized RMM Tools
Security teams need both inventory and behavioral visibility. A software list may miss portable tools, short-lived sessions, in-memory execution, or a second agent installed after the inventory was collected.
Detection should look for:
1. New or uncommon RMM software, especially from user-writable folders.
2. Services, autorun entries, or firewall changes outside the approved baseline.
3. RMM processes spawning PowerShell, command shells, installers, or credential utilities or credential-access tools particularly when those relationships are uncommon in the environment.
4. Silent MSI installations initiated by an RMM agent.
5. Connections to unknown management servers or unapproved tenants.
6. Multiple RMM products on one endpoint without a documented reason.
7. File transfer or remote execution outside approved maintenance windows.
CISA's StopRansomware Guide recommends auditing remote access tools, reviewing execution logs for abnormal use, identifying portable or memory-only RMM activity, and requiring approved remote-access paths.
This visibility depends on connected security operations. Endpoint, identity, network, email, and log data must give analysts enough context to distinguish expected administration from attacker-controlled access.
Respond to RMM Persistence as an Access Problem
An unauthorized RMM agent should trigger more than a software-removal ticket. Responders should determine how it arrived, which account elevated it, what infrastructure it contacted, which commands were run, what files were transferred, and whether another access method was added.
Containment must address every channel. Teams should hunt for related services, autoruns, installer activity, outbound sessions, secondary RMM products, credential access, and lateral movement. Accounts involved in a suspicious service installation may also need to be reset and investigated.
Organizations should include this scenario in incident readiness plans and tabletop exercises. The playbook should identify who can isolate endpoints, revoke RMM access, coordinate with an MSP, preserve logs, reset credentials, and confirm that no secondary channel remains.
Apply Ownership, Execution, and Validation
The Socium Security Operating Model provides a practical structure for RMM security.
Ownership defines approved tools, accountable owners, required controls, deployment scope, and exceptions.
Execution turns the standard into application-control policy, MFA, least privilege, centralized logging, detection logic, and incident-response procedures.
Validation continuously compares observed RMM activity with the authorized baseline and tests whether unapproved agents are blocked, alerts reach the right team, and responders can find redundant access.
The objective is not to eliminate remote administration. It is to make authorized use clear and unauthorized use visible.
Microsoft's research shows why trusted tools cannot automatically be treated as trusted behavior. Organizations need to know which RMM tools are authorized, who controls them, how misuse will be detected, and how responders will prove that every access channel has been removed.
Socium Security helps organizations turn these requirements into clear ownership, sustained execution, and continuous validation. Our managed cybersecurity services can help strengthen monitoring, control implementation, and response readiness around privileged remote access.
Ready to assess whether unauthorized remote management could persist in your environment? Contact Socium Security to review your RMM governance, detection coverage, and incident-response readiness.
