There’s nothing particularly suspicious about an IT administrator remotely connecting to someone’s laptop. They might be installing an update, fixing a problem or changing a configuration without ever needing to sit in front of the machine.
Remote monitoring and management software, usually shortened to RMM, exists to make exactly this kind of work possible. The problem is that an attacker may want to do almost exactly the same things. They want remote access to a device. They want to run commands, move files and make changes.
Once they’ve broken into an organisation, they may also want a reliable way to maintain that access. Instead of building malware to provide those capabilities, they can sometimes use legitimate remote-access software that already knows how to do all of them. And this is becoming increasingly common.
Verizon’s 2026 Data Breach Investigations Report recorded a 240 per cent year-on-year increase in the use of legitimate RMM software in System Intrusion breaches. Huntress, using a separate dataset covering more than 4.6 million endpoints and 9.4 million identities, found RMM abuse increased by 277 per cent year on year.
That leaves security teams with a slightly uncomfortable question. If the software itself isn’t malicious, what tells you that the person using it is?
Legitimate RMM Tools Give Attackers What They Need
To understand why RMM abuse has become so useful to attackers, it helps to start with what these tools are supposed to do. RMM software gives authorised IT teams a way to monitor and administer computers remotely.
Depending on the product and the permissions involved, that can include running commands, transferring files, changing configurations and maintaining ongoing access to a device. Those are useful capabilities when someone is trying to fix your laptop. They’re also useful capabilities when someone has broken into it.
Microsoft documented a particularly clear example in September 2026. Attackers used phishing lures to convince victims to download MSP360 software disguised as business documents, meeting invitations and other familiar content. The installer itself was legitimate and digitally signed.
Once installed, however, it gave the attackers remote-management access to the device. They then used MSP360 to install ConnectWise ScreenConnect, creating a second remote-access channel for further activity. Microsoft found no exploitation of ScreenConnect itself. That distinction is important because the attack didn’t depend on turning legitimate software into malware.
The attackers were taking advantage of functionality the software was designed to provide. Nor do attackers appear particularly attached to one RMM product. Microsoft’s investigation into threat actor Storm-2570 found Atera, MeshAgent, ScreenConnect, Splashtop, Remotely_Agent and NinjaRMM being used across different intrusions.
The actor sometimes deployed several remote-access tools during the same attack, including using Atera to install Splashtop for interactive access. The route into an organisation can vary just as much. Mandiant and Google Threat Intelligence Group recently found ShinyHunters exploiting an Oracle PeopleSoft vulnerability before deploying the legitimate MeshAgent RMM tool to maintain interactive access.
Here, remote-management software wasn’t the way into the environment at all. It became useful after the initial compromise had already happened. Google Cloud. So RMM tools aren’t attractive to attackers despite being legitimate. Their legitimate functionality is a large part of the attraction.
Once that software is running, simply recognising what it is can only tell a security team so much.
Software Reputation Can’t Tell You Who Is In Control
Security teams have good reasons to care about software reputation. Knowing that an application came from a recognised vendor, carries a valid digital signature and hasn’t been altered helps distinguish genuine software from malicious files pretending to be something they’re not. Application controls add another layer.
Application allowlisting, for example, lets an organisation define which software is permitted to run. If someone tries to install an unknown remote-access tool that employees have no legitimate reason to use, blocking it can prevent the problem from going any further. RMM abuse doesn’t make those controls obsolete.
It exposes a question they weren’t designed to answer. MITRE ATT&CK recognises malicious use of remote desktop software as a specific attack technique, T1219.002. Its guidance notes that products such as AnyDesk and ScreenConnect are commonly used for legitimate technical support and may already be permitted by application controls within an organisation.
That creates a very different detection problem. A security control may correctly identify the software as legitimate. An allowlist may correctly determine that the application is approved. Neither finding tells the security team who is controlling it at that particular moment, or whether what they’re doing is authorised.
Blocking every remote-management product isn’t much of an answer either. Organisations genuinely depend on these tools to support employees, manage endpoints and administer systems.
CISA’s ransomware guidance reflects that reality by recommending that organisations identify their authorised RMM software and restrict how approved solutions can be used, rather than treating all remote administration as inherently malicious. Attackers can make the distinction even harder by choosing software that already makes sense in the environment.
A tool the organisation has never seen before creates an obvious question. The same tool routinely used by its IT team creates much less friction simply by being there. So there are really two different security decisions being made:
- Is this software legitimate and allowed to run?
- And is what it’s doing right now legitimate and allowed to happen?
The first can be answered largely by understanding the application. The second needs much more context.
Context Separates Administration From Intrusion
Imagine an approved RMM tool opens a remote session on an employee’s laptop. On its own, that’s not much of a security signal. The employee may have raised a support ticket five minutes earlier and an administrator may be doing exactly what they’re supposed to do. Now change the surrounding details. The connection happens at an unusual time.
The account using it doesn’t normally administer that device. A second RMM application appears shortly afterwards, followed by file transfers and system changes that don’t fit the organisation’s normal support process. No single event necessarily proves an intrusion. Taken together, however, they start to tell a different story.
That’s the useful shift for security detection. Instead of asking the RMM application to carry the entire burden of proving whether activity is safe, defenders can combine what they know about the tool with what they know about the identity using it, the endpoint it appeared on and the behaviour surrounding the session.
Identity and authorisation
The first piece of context is the person or service operating the tool. If an administrator normally manages a particular group of systems through an approved account, seeing that identity perform expected work on one of those systems has a reasonable explanation. The picture changes when the relationship stops making sense.
Perhaps an account that doesn’t normally perform remote administration suddenly starts doing it. Or an administrator account begins accessing systems outside its usual responsibility. The account may have valid credentials and the correct privileged access, meaning it has permission to perform sensitive administrative actions, but permission alone doesn’t explain why those actions are happening.
This is why authentication context is useful alongside RMM activity rather than as proof that the activity is legitimate. An attacker who has stolen an administrator’s credentials may still be able to authenticate successfully. Security teams need to know not only which identity accessed the tool, but whether the access fits what that identity normally does.
That gives the SOC something more useful to investigate than a valid login attached to a valid application. It can start asking whether the identity, privilege and administrative task actually belong together.
Endpoint and deployment context
The device itself adds another layer. An approved RMM agent running on a server that IT routinely manages through that platform is very different from the same application suddenly appearing on an endpoint where it has never been needed before. The software hasn’t changed, but its presence on that particular device may be unusual.
How it arrived can add more context. Organisations usually have established ways to deploy approved administrative software, whether that happens through endpoint-management platforms, standard installation packages or another controlled process.
An RMM tool arriving through an unexpected download or being installed by another remote-access product deserves a closer look, even when the application itself is authorised. The same applies when multiple RMM products appear on one endpoint. There can be perfectly reasonable explanations for that, particularly in complex environments or where third-party support providers are involved.
But if the organisation already has an approved remote-management platform, the unexpected arrival of another creates a useful anomaly for the SOC to investigate. This is where a current application inventory becomes more valuable than a simple approved-software list.
Security teams need to understand not only which RMM products the business allows, but where those applications are expected to exist and how they normally get there.
Behaviour and network activity
Then there’s what happens once the remote session begins. Remote administration naturally creates behaviour that can look powerful from a security perspective. An administrator may transfer a file, execute a command, change a configuration or establish an outbound connection as part of perfectly ordinary work.
Alerting on every one of those actions would quickly bury a SOC in legitimate activity. The sequence surrounding those actions can tell a much richer story. MITRE’s detection guidance for remote desktop software reflects this approach.
Rather than relying on the presence of an RMM application alone, its detection strategy combines RMM execution with signals such as outbound connections, remote-session establishment and firewall changes. CISA similarly recommends reviewing RMM execution logs for abnormal use and looking for unexpected remote-management activity.
This is behavioural detection in a fairly practical form. It doesn’t require treating every unusual event as malicious. It means asking whether several pieces of activity make sense when viewed together. An approved RMM tool used by an expected administrator on the right endpoint during ordinary support work may fit the organisation’s normal pattern.
The same tool appearing through an unusual deployment route, controlled by an unexpected identity and followed by suspicious system changes creates a very different picture. Context turns a legitimate application from a simple allow-or-block decision into activity the security team can actually evaluate.
But there’s one thing the organisation needs before any of those comparisons become particularly useful: a clear idea of what legitimate RMM use looks like when everything is working normally.
RMM Governance Has To Go Beyond An Approved Tools List
Knowing which remote-management tools are authorised is a sensible place to start. If the SOC discovers a product that nobody recognises and nobody approved, that gives the team an immediate reason to investigate. But an RMM inventory can’t stop at product names.
Security teams also need to understand where those tools should be installed, which users and service accounts should operate them, how they’re normally deployed and what kinds of systems they’re expected to reach. Otherwise, an organisation can know that ScreenConnect is approved without knowing whether ScreenConnect appearing on a particular employee’s device at 2am is normal.
This baseline also makes duplicate remote-access capability easier to investigate. A second RMM product doesn’t automatically mean an attacker is present, but the organisation should be able to explain why it exists. If nobody can, the anomaly becomes much more useful than the fact that both applications happen to be legitimate.
The same thinking needs to shape security telemetry, which is simply the information security tools collect about what’s happening across systems. RMM logs are more useful when defenders can connect them with identity data, endpoint activity and network connections.
Without that surrounding information, the SOC may know a remote session occurred without having enough evidence to decide whether it belonged there. CISA recommends auditing remote-access tools to identify authorised RMM software and reviewing execution logs for abnormal use.
MITRE’s detection guidance similarly draws on endpoint, network and firewall activity rather than treating the RMM binary as the only useful signal. CISA. Incident response planning needs to account for the same possibility.
If an attacker has established access through legitimate administrative software, finding and removing conventional malware may not remove every route back into the environment. Responders need to know which remote-management channels remain active, who controls them and whether the identities or infrastructure behind them have also been compromised.
That makes remote access governance less about deciding which tools the organisation trusts and more about defining how authorised remote administration is supposed to work. Once the normal pattern is clear, deviations from it become much easier to see.
Final Thoughts: Legitimate Software Still Needs Security Context
There’s nothing inherently suspicious about an administrator remotely controlling a computer. That’s precisely what RMM software was built to enable. And there’s nothing contradictory about the same software appearing during an intrusion. It can still be genuine, digitally signed and functioning exactly as its developer intended.
The problem begins when those facts are treated as evidence that the activity itself must also be safe. As attackers make greater use of legitimate enterprise capabilities, the distinction between “good software” and “bad software” can only take defenders so far. Software reputation can establish what a tool is.
Application controls can decide whether it’s permitted to run. Effective RMM security also needs to understand who is using it, where it appeared, how it got there, what it’s doing and whether any of that fits the organisation’s normal operations. That doesn’t mean distrusting every administrative tool or filling the SOC with alerts every time somebody opens a remote session.
It means giving legitimacy the evidential weight it actually deserves. A legitimate application is one piece of the picture, not proof of legitimate intent. RMM abuse makes that gap particularly easy to see because the attacker and administrator may be using exactly the same capability.
As more attacks take advantage of genuine enterprise software, security teams will increasingly need controls that can recognise malicious behaviour without assuming the technology behind it must also be malicious.
RMM abuse is only one example of attackers learning to work with the tools enterprises already use rather than bringing obviously malicious ones with them. As that line becomes harder to see, EM360Tech will continue exploring what it means for the way security teams detect, investigate and respond to threats.
Comments ( 0 )