RMM Abuse (T1219)

What is RMM abuse?

RMM abuse is an attacker using legitimate remote monitoring and management software, such as AnyDesk or ConnectWise ScreenConnect, to control a compromised machine. MITRE ATT&CK tracks it as T1219 and classifies it as command and control. Because the software is signed, trusted and often already in use, ordinary controls tend to allow it.

The awkward word in that definition is legitimate. Remote monitoring and management software is how a great many organizations are administered. If you find an agent on a machine and half your fleet is supposed to be running something like it, the question is not what the binary is. It is whether this one is yours.

One classification belongs before the mechanics, because no vendor explainer on this subject seems to mention it. MITRE does not file this under initial access or persistence. T1219 sits under command and control, and the technique record is current: renamed to Remote Access Tools, version 3.0, last modified 12 May 2026, with three sub-techniques. Two of them, IDE Tunneling and Remote Access Hardware, are not what anyone pictures when they say RMM.

What follows is why this software gets through controls that stop other things, what actually separates an authorized remote session from an attacker's, and what CISA told defenders to do about it.

Explain It Like I'm 10

A building lets the maintenance company come and go. They have a key, a badge and a van with a logo on the side, and nobody stops someone dressed like that, because people in that uniform belong here. So the easiest way in is not to pick the lock. It is to turn up in the uniform. Nobody forces the door. Someone holds it open.

RMM abuse, RATs and C2: where the boundary sits

These get used interchangeably and they are not the same thing. The difference is less about what the channel does than about who bought the software.

MITRE's own wording is the useful part: a remote access tool creates "a session between two trusted hosts". A RAT has to hide. An abused RMM agent does not, because nothing about it is out of place except the person on the other end.

Why signed, legitimate software gets through

The best explanation of this belongs to CISA, the NSA and MS-ISAC, in a joint advisory they published in January 2023:

"Using portable executables of RMM software provides a way for actors to establish local user access without the need for administrative privilege and full software installation - effectively bypassing common software controls and risk management assumptions."

No administrative privilege. No installation. That combination is what most defenders have not internalized, because it removes the two events an endpoint control is usually watching for.

The rest of the evasion set follows from being a real product:

• The binaries are commercially signed, so signature checks pass. As Red Canary puts it in its own detection research, just because something is signed does not mean it is legitimate.
• The destinations are the vendor's own infrastructure, so blocking by reputation means breaking a service that other teams may legitimately use.
• Installation can create persistence by itself, because the installer registers a Windows service. Nobody had to write persistence code.

One irony, one sentence: ATT&CK notes that adversaries may similarly abuse the remote-access response features built into EDR and other defensive tools.

None of this makes the software illegitimate. It is doing precisely what it was built to do, for someone who should not be asking.

How it arrives, and who uses it

The documented route is social, not technical. In the campaign behind that 2023 advisory, criminals sent phishing emails that led victims to download legitimate RMM software, then used it in a refund scam to take money from bank accounts. The phishing was help-desk themed, and it went to federal staff's personal addresses as well as their government ones.

The same route reappears in a more recent advisory, aimed at helpdesks rather than inboxes. CISA and the FBI record Scattered Spider directing employees to run commercial remote access tools for initial access, and deploying RMM tools after compromising an account to establish persistence. Both are mapped to T1219 in the advisory itself.

Why this counts as command and control

The sharpest evidence sits in MITRE's own procedure examples. Cobalt Group used Ammyy Admin and TeamViewer for remote access, "including to preserve remote access if a Cobalt Strike module was lost."

Read that twice. A crew running one of the best-known C2 frameworks in the world kept commercial remote-administration software as the backup channel, specifically so that losing their implant would not cost them the network. The fallback for their command and control was a product the victim already trusted.

The pattern is not unusual. Akira uses AnyDesk and PuTTY to maintain access, BlackByte has used AnyDesk, DarkVishnya used DameWare Mini Remote Control for lateral movement, and Egregor checked for the LogMeIn event log. This is also why the clock on an intrusion runs long: a channel nobody flags is a channel nobody investigates.

How do you detect unauthorized RMM software?

The question in practice is almost never "what is this binary". It is "is this ours".

The field's instinctive answer is a list of bad tools, and the list does not scale. LOLRMM, a community catalogue of remote-access tools historically abused by attackers, held 317 tools when its API was queried on 12 August 2026. No organization is maintaining a deny list against that, and the next campaign will use the one that is not on it.

What does scale is the authorization question.

MITRE's own analytic works the same way, which is the point: it is shaped by behaviour rather than by product. Detection strategy DET0496 describes a four-stage chain:

1. Initial execution of a remote-control or assist agent under user context.
2. Persistence via a service or autorun entry.
3. A long-lived outbound connection or tunnel to external infrastructure.
4. Interactive control signals, such as shell or file-manager child processes spawned by the agent.

None of those four stages names a product. That is what makes the analytic survive a tool nobody has written about yet.

One rule is worth adopting outright, and it is the cheapest thing on this page. Red Canary observes multiple RMM tools appearing on a single host as a recurring pattern. For an organization that sanctions exactly one, the usable form is blunter: a second RMM agent is high-signal by definition. It costs nothing to alert on and it does not care which product the attacker chose.

The catalogue is still useful, just not as a blocklist. It records installation paths, PE metadata, the artifacts each tool leaves on disk, in event logs, in the registry and on the network, and Sigma rules to match them. It is a reference for the hunt, not a wall. Which indicator you choose to pivot on, and how cheaply an attacker can change it, is a decision with its own framework behind it.

What CISA told defenders to do

The advisory quoted earlier deserves naming properly, because it does not appear anywhere on the first page of Google results for this subject. It is AA23-025A, a joint advisory from CISA, the NSA and MS-ISAC, last revised 26 January 2023. It is three and a half years old, and the campaign it describes is history. The mechanism and the checklist are not.

The recommendations, close to the advisory's own wording:

• Audit remote access tools on the network to identify currently used and authorized RMM software.
• Review logs for execution of RMM software running as a portable executable.
• Detect RMM software that is only ever loaded in memory.
• Apply application controls, including allowlisting of RMM programs.
• Block both installation and execution of portable versions of unauthorized RMM software.
• Require authorized RMM to be used only from within the network, over approved paths such as VPN or VDI.

The first item is the whole argument of this page, published by three government agencies three years before the field's blog posts arrived at it. The same advisory independently describes RMM software as a backdoor "for persistence and/or command and control", which is the second, non-vendor source for the classification this article opened with.

Where this argument stops

Three bounds, because the case above is easy to over-read.

• Tool-specific detection genuinely works. Red Canary's research gives concrete, usable examples: a binary named `Invoice.exe` carrying ScreenConnect metadata should trigger isolation, and ScreenConnect instances calling domains registered within the last 30 days are, in its words, nearly always indicative of malicious activity. The honest position is both: tool-specific detections catch the campaign in front of you, and the authorization question is what survives the next one.
• The government checklist includes a list. CISA's own recommendations call for allowlisting named RMM programs. Lists are not the enemy; relying only on a list of the bad ones is.
• 317 is a catalogue, not an inventory. It counts tools recorded as historically abused, it changes, and it is not a measure of what is attacking anyone.

The number this page will not repeat unscoped

The figure circulating for this topic is a 277% rise in RMM abuse in 2025. Three things travel with it, and they are usually left behind:

• Whose data it is: Huntress's own telemetry, in its 2026 Cyber Threat Report - not an industry measurement.
• What it compares: 2025 against 2024.
• What is missing: no published methodology, sample size, or description of the customer base it was drawn from.

It is being repeated as a bare fact, including by at least one search engine's own answer summary. Attribute all three or do not use it. The same applies to the related claim that over half of cases following suspicious Atera activity link to ransomware, whose timeframe is not stated. This page publishes no industry prevalence rate for RMM abuse, because none exists in a form worth citing.

One thing that should not need saying, said anyway: none of this makes remote monitoring and management software illegitimate. It is how enormous numbers of organizations are run, including by many of the people reading this. Authorized use looks like a licensed tool, deployed by deployment tooling, reaching the organization's own tenant, from inside the managed estate. The problem is never the category. It is the instance nobody authorized.

Common questions about RMM abuse

Which MITRE tactic is RMM abuse? Command and control. It is filed under T1219, Remote Access Tools. The field usually describes it as an initial-access or persistence problem, and it can serve both, but the framework's own classification is the channel itself.

Why didn't EDR or antivirus flag it? Because there was often nothing anomalous to flag. The software is commercially signed, its destinations are the vendor's real infrastructure, and a portable executable can run without an installation event at all.

What is LOLRMM? A community-maintained catalogue of remote-access tools that have historically been abused, recording each tool's installation paths, metadata and the artifacts it leaves, along with Sigma detection rules. It is a hunting reference, not a blocklist.

If I remove the tool, is the attacker gone? No. Uninstalling an agent says nothing about credentials, tokens or devices added while it was running. Removal closes one channel; it is not eviction, and the account changes made through that channel are a separate problem with a separate checklist.

Is RMM abuse the same as a RAT? No. A RAT is the attacker's own software and it survives by hiding. An abused RMM agent is a legitimate product, and it survives by belonging.

What to go check

This is command and control that your organization pays for, so the question is authorization rather than reputation.

Two moves, in order.

First, write the list. Which remote-access tools does this organization authorize, and where are they allowed to run from? That is the first item on CISA's checklist and the precondition for everything below it. Most organizations have never written it down, which is why the second step usually has nothing to compare against.

Then hunt for what is not on it. A second RMM agent on a host that already has the sanctioned one. An agent installed under a user context rather than by deployment tooling. An outbound session to a remote-access service nobody subscribes to.

The uniform works because nobody checks the work order. Go write the work order.