Remote Access Tool Abuse in Enterprise Networks

Key judgments

Remote access tools are now a mainstream intrusion method. Two independent datasets point the same way. Verizon’s Data Breach Investigations Report shows RMM abuse in system intrusion breaches up 240% on the prior reporting period. Huntress reports a 277% rise in its own telemetry. The populations differ, so the numbers are not interchangeable. The direction is not in doubt. Confidence: moderate to high.
The tool is rarely the intrusion. It is the channel an attacker uses after a lure, a stolen credential or an exploited server gives them a way in. Finding the agent tells you how they stayed. It does not tell you how they got in.
The binary cannot settle the question. Context can. Who installed it, from which account, which vendor tenant it reports to, how it persists and what ran under it decide whether a session was administration or an attack.
Scoping usually fails at the first agent. Actors deploy more than one tool for redundancy. A response that removes the one agent it found will often leave a second one running.

What has been observed

The pattern is documented well enough that the main entry routes can be separated by evidence rather than by guesswork.

Lure-delivered agents. CISA, NSA and MS-ISAC described a campaign in which help-desk-themed phishing led victims to download ScreenConnect and AnyDesk. The actors ran them as portable executables that connect straight to an attacker-controlled server. Nothing was installed, no administrator rights were needed, and the guidance notes that this kind of use generally does not trigger antivirus alerts. The same guidance warns that managed service providers and IT help desks are favored targets because one trust relationship can expose many customers.

Social engineering that ends in an install. The joint advisory on Scattered Spider describes actors impersonating help desk staff and persuading employees to install remote access tools. It lists AnyDesk, TeamViewer, ScreenConnect, Splashtop, Level.io, Pulseway, Tactical.RMM, Fleetdeck.io, Tailscale, ngrok and Teleport.sh among the tools used after access. It adds a point that matters for triage: legitimate tool use alone does not indicate compromise.

Ransomware operators. MITRE ATT&CK, under the Remote Access Tools technique, records Akira, BlackByte, INC Ransom and Medusa using tools such as AnyDesk, ConnectWise and Atera for access, lateral movement or exfiltration.

Attacks on the management platform itself. CISA reported ransomware actors exploiting an unpatched SimpleHelp RMM server at a utility billing software provider and using it to reach the provider’s downstream customers, causing service disruption and double extortion. In that case the attacker did not bring a tool into the estate. The victim’s own trusted tool was the way in.

What attackers do with them. Huntress, as reported by Dark Reading, found ScreenConnect used mainly for credential harvesting, NetSupport for fast staging and PDQ Connect for initial malware delivery. It also found traditional hacking tool use fell 53% as RMM abuse rose. Attackers are swapping custom malware for software that is already trusted.

Three ways it reaches your network

Entry route	What defenders usually see	First question to answer
User-run lure	A portable executable launched from a downloads or temp folder by a non-IT user, shortly after a call or email from “IT”.	Who contacted the user, and what did they do while the session was live?
Post-compromise install	A tool deployed using an account with admin rights, often on servers, outside any change record.	How did the actor obtain that account, and where else has it been used?
Your own RMM or MSP platform	Sessions, scripts or new technician accounts that originate from a tool you approved and trust.	Was the platform itself compromised, and what has been pushed through it?

Each route leads to a different investigation. A lure case is mainly about one user and one host. A post-compromise case is about identity and lateral movement. A platform case is a supply chain incident and can touch every managed endpoint.

Why triage goes wrong

Remote access tools are signed, widely deployed and talk to well-known vendor infrastructure over encrypted channels. Most large estates already run at least one approved RMM, so an analyst who sees another one has good reason to assume it is a colleague’s work. The attacker is counting on that reasoning.

The failure mode is a ticket closed as administrative activity because the tool is on the allowlist. It happens even where the alert fires correctly. The check that is missed is whether this particular instance of the tool, reporting to this particular tenant, was one the organization deployed.

Separating administration from attack

No single artifact is conclusive. The weight comes from several together. Most agents record the vendor instance or tenant they connect to in configuration files, service names or command lines, which makes tenant identity the strongest single check.

Evidence	Consistent with administration	Consistent with attack
Provenance	Deployed from your management platform or software distribution tool.	Launched from a user profile, downloads or temp folder; no matching change record.
Reporting tenant	Connects to an instance or tenant your organization owns.	Connects to an instance you cannot match to any approved contract or console.
Launching account	Named technician or service account with a ticket.	Standard user, newly privileged account or an account used outside its normal pattern.
Persistence	Installed through your normal agent policy.	New service or autorun created by a manual install, sometimes on a server that never ran an agent.
Activity under the agent	Scripted tasks that match a maintenance window.	Interactive shells, file browsing, credential access tools or archive creation spawned by the agent process.
Tool count	One approved platform per function.	Two or more remote access tools on the same host or the same account.

MITRE’s detection logic for this technique follows the same shape. It looks for a remote-control agent starting under user context, persistence through a service or autorun, a long-lived outbound connection to external infrastructure, and interactive processes spawned by the agent. It works across tools because it describes behavior rather than names.

Scoping the incident

A defensible scope answers five questions: which tools, which hosts, which accounts, what was done in the sessions, and what left the network. The order below keeps the first containment action from destroying evidence you will need.

Preserve first. Capture the agent configuration, installer, service entries, logs and, where practical, memory from the host before removing anything.
Fingerprint the tool. Record the vendor, version, reporting tenant or instance identifier and relay addresses. These become your search keys.
Hunt the estate for the same fingerprint and for every other remote access tool. Search endpoint telemetry, DNS, proxy and firewall logs for the tenant identifier, the relay and any remote access product not on the approved list.
Reconstruct session activity. Use the process tree under the agent, vendor session logs and any session recordings you have enabled. Identify what ran, what was read and what was copied.
Follow the credentials. List accounts that were logged on to touched hosts during sessions. Treat them as exposed and trace where they authenticated next.
Check for staging and exfiltration. Look for archives, transfers to cloud storage and the precursors of ransomware, including backup tampering and security tool changes.
Audit your own platform. Review new technician accounts, API keys, pushed scripts and policy changes in your approved RMM console for the same period.

Working rule. Treat any unapproved remote access tool combined with interactive child processes as an incident until you can show otherwise. Treat an approved tool reporting to a tenant you do not own the same way.

Containment and the observation trade-off

Cutting a live session stops the immediate harm, but it also tells the actor they have been seen. If the tool is one of several, the actor will switch to another. The practical sequence is to identify the full set of tools first where the risk allows, then isolate hosts, block the relay and tenant at the proxy and DNS layer, revoke the sessions and reset exposed credentials together. Doing these in one coordinated window is more reliable than doing them as each tool is found.

What to change before the next case

Know what is approved. Keep an inventory of authorized remote access tools, including the tenants and instance identifiers they should report to. Without it, analysts cannot answer the tenant question.
Block what is not approved, including portable copies. CISA recommends application controls that stop both installation and execution of unauthorized RMM software. Allowlisting that checks only installed software misses the portable case.
Restrict outbound access. Allow connections to remote access services only for approved tools, and only from approved paths. CISA also advises allowing authorized RMM use only from inside the network through VPN or VDI, and blocking common remote access ports at the perimeter.
Treat the RMM platform as privileged infrastructure. Patch it on the same urgency as other internet-facing systems, require phishing-resistant MFA on the console, and retain and review its audit log.
Fix the help desk path. Both the CISA guidance and the Scattered Spider advisory show social engineering of IT staff and users as the delivery mechanism. Verification steps for password resets, MFA changes and “please install this tool” requests belong in process, not in awareness slides.
Hold providers to the same standard. If an MSP manages your endpoints, ask how they secure their platform, how they separate customers and whether you receive its audit logs.

Limits of the evidence

The growth figures come from two different sources with different populations, and the Verizon figure is cited here as reported by SC Media. Tool lists in advisories describe what was observed in specific campaigns. They will go out of date, and they should not be used as a detection list. No public source gives a reliable measure of how long malicious RMM sessions stay undetected, so any claim about dwell time for this technique should be treated as unsupported.

Next step

Take your last three remote access tool alerts and ask whether the file would show the reporting tenant, the launching account and the process activity under the agent. If any of those cannot be answered from existing telemetry, that is the gap to close first. Cybrilliant can support an independent review of investigation readiness for this class of activity where an outside view would help.

Sources

CISA, NSA and MS-ISAC. Protecting Against Malicious Use of Remote Monitoring and Management Software. cisa.gov
CISA. Ransomware Actors Exploit Unpatched SimpleHelp Remote Monitoring and Management to Compromise Utility Billing Software Provider. cisa.gov
CISA, FBI and international partners. Scattered Spider cybersecurity advisory (joint advisory, updated edition). cisa.gov
MITRE ATT&CK. Remote Access Tools (T1219) and its sub-techniques. attack.mitre.org
Verizon. Data Breach Investigations Report (latest edition), as reported by SC Media: “Verizon DBIR: vulnerability exploits top initial access as patching coverage falls.” scworld.com
Huntress. Cyber Threat Report (latest edition), as reported by Dark Reading: “RMM Abuse Explodes as Hackers Ditch Malware.” darkreading.com