Detecting RMM Tool Abuse (T1219): A SOC Analyst's KQL & SPL Playbook

If your SOC has a detection for Mimikatz but not for AnyDesk, you are catching the noisy step and missing the quiet one. Over the last eighteen months, the single most reliable signal across Scattered Spider, Black Basta, Akira, and nearly every commodity ransomware affiliate has not been a custom implant — it has been a perfectly legitimate, code-signed remote management tool installed on a workstation that never needed one.

MITRE ATT&CK tracks this as T1219 — Remote Access Tools, and it is the technique most likely to be sitting in your environment right now, unalerted, signed by a vendor your EDR trusts. This guide walks through why RMM abuse defeats traditional controls, and gives you production KQL for Microsoft Sentinel / Defender and SPL for Splunk — pulled directly from the df00tech detection library — to find it.

Why RMM Abuse Is the Detection Engineering Blind Spot

Remote Monitoring and Management (RMM) tools — TeamViewer, AnyDesk, ScreenConnect (ConnectWise Control), Atera, Splashtop, NinjaOne — exist to give a remote operator full interactive control of a machine over an encrypted, firewall-friendly channel. That is exactly what a help desk needs, and exactly what an intruder needs. The overlap is the problem.

Three properties make this technique resist signature detection:

1. The binary is legitimately signed. Your allowlisting and reputation scoring give it a pass. There is no malicious hash to block.
2. The traffic looks like SaaS. RMM sessions ride outbound 443 to vendor cloud relays (*.anydesk.com, *.screenconnect.com). It is indistinguishable from normal web traffic at the firewall.
3. It is frequently already approved somewhere. If your MSP uses Atera, “atera.exe running” is not inherently anomalous — until it appears on a finance workstation it has no business touching.

The attacker’s playbook is consistent: gain initial access (often via a phishing lure or help-desk social engineering), push a second, unsanctioned RMM tool to guarantee persistence even if the first foothold is cleaned, and use the interactive session for hands-on-keyboard discovery and lateral movement. The RMM tool is the C2 channel — which is why you should treat a surprise AnyDesk install with the same urgency as a Cobalt Strike beacon.

The Detection Anchor: Inventory Deviation, Not Process Name

You cannot detect RMM abuse by alerting on “anydesk.exe ran” — in an MSP-managed environment that fires thousands of times a day. The detectable artifact is a remote access tool that deviates from the approved inventory: a tool your organization does not license, on a host that should not have it, launched by a parent process that is not your deployment system.

The KQL from T1219 below enumerates the full RMM family and, critically, classifies each hit by how it was launched — service-installed (persistence) versus interactively user-launched (hands-on-keyboard) — so triage can prioritize:

let RATProcessNames = dynamic([
  "teamviewer.exe", "teamviewer_service.exe",
  "anydesk.exe", "anydesk_service.exe",
  "screenconnect.exe", "screenconnectclient.exe", "connectwisecontrol.client.exe",
  "logmein.exe", "lmi_rescue.exe", "logmeinrescue.exe",
  "ammyyadmin.exe", "aa_v3.exe",
  "supremo.exe", "supremoservice.exe",
  "rustdesk.exe", "splashtop.exe", "splashtopremote.exe",
  "ateraagent.exe", "ninjaone.exe", "ninjaremote.exe",
  "simplehelp.exe", "dwrcs.exe", "dwrcst.exe",
  "tmate", "vnc.exe", "tvnserver.exe", "vncviewer.exe",
  "uvnc_service.exe", "winvnc.exe",
  "remotedesktopmanager.exe", "mstsc.exe",
  "chrome_remote_desktop.exe", "remote_assistance_host.exe"
]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any (RATProcessNames)
| extend IsService = InitiatingProcessFileName in~ ("services.exe", "svchost.exe")
| extend IsUserLaunched = InitiatingProcessFileName in~ ("explorer.exe", "cmd.exe", "powershell.exe")
| extend RATCategory = case(
    FileName has_any ("teamviewer", "anydesk", "screenconnect", "connectwise"), "Commercial RMM",
    FileName has_any ("vnc", "tvnserver", "winvnc", "uvnc"), "VNC",
    FileName has_any ("logmein", "lmi_rescue"), "LogMeIn",
    FileName has_any ("ammyy", "aa_v3"), "AmmyyAdmin",
    FileName has_any ("rustdesk", "splashtop", "supremo"), "Other RMM",
    FileName has_any ("atera", "ninja", "simplehelp", "dwrcs"), "MSP Tool",
    "Unknown")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         RATCategory, IsService, IsUserLaunched
| sort by Timestamp desc

To turn this from a hunt into a low-noise alert, join the output against your CMDB or a watchlist of approved tools and alert only on the complement. The IsUserLaunched flag is your highest-fidelity field: an RMM client spawned by powershell.exe or an Office process is almost never legitimate IT activity.

The Splunk Equivalent

For Splunk shops on Sysmon, the same logic ports cleanly to SPL. This query from the T1219 detection page keys off Sysmon Event Code 1 (process creation) and applies the same category and launch-context enrichment so your analysts get an identical triage picture:

index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (Image="*\\teamviewer.exe" OR Image="*\\anydesk.exe"
   OR Image="*\\screenconnect*.exe" OR Image="*\\connectwisecontrol*.exe"
   OR Image="*\\atera*.exe" OR Image="*\\ninja*.exe"
   OR Image="*\\rustdesk.exe" OR Image="*\\splashtop*.exe"
   OR Image="*\\simplehelp*.exe" OR Image="*\\winvnc.exe" OR Image="*\\tmate")
| eval RATCategory=case(
    match(Image, "(?i)(teamviewer|anydesk|screenconnect|connectwise)"), "Commercial RMM",
    match(Image, "(?i)(vnc|tvnserver|winvnc|uvnc)"), "VNC",
    match(Image, "(?i)(atera|ninja|simplehelp|dwrcs)"), "MSP Tool",
    1=1, "Other RMM")
| eval IsService=if(match(ParentImage, "(?i)(services\.exe|svchost\.exe)"), "Yes", "No")
| eval IsUserLaunched=if(match(ParentImage, "(?i)(explorer\.exe|cmd\.exe|powershell\.exe)"), "Yes", "No")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine, RATCategory, IsService, IsUserLaunched
| sort - _time

A useful refinement on the Splunk side is to wrap this in a tstats-accelerated lookup against an approved_rmm.csv per host group — finance, HR, and engineering endpoints almost never need any RMM agent, so for those asset classes a single hit is an alert, not a hunt.

Don’t Forget the Network and Persistence Side

Process telemetry is the strongest signal, but a complete T1219 detection strategy covers two more surfaces:

• Network egress to RMM relays. Alert on first-seen connections to vendor cloud domains (anydesk.com, screenconnect.com, rustdesk.com) from hosts with no corresponding approved agent. When attackers self-host the relay to evade domain reputation, this slides into T1572 — Protocol Tunneling and T1090 — Proxy, so pair the two detections.
• Installation and persistence. RMM tools are frequently dropped via T1105 — Ingress Tool Transfer and persisted as a Windows service. Watch for new service creation referencing an RMM binary path, and for the graphical variants tracked under T1219.002 — Remote Desktop Software.

If the access arrived through an internet-facing gateway rather than a dropped binary, the relevant technique is T1133 — External Remote Services; and where the operator pivots into your cloud tenant using the same session, correlate with T1078.004 — Cloud Accounts.

Triage: From Alert to Decision in Four Steps

When the rule fires, the T1219 detection page ships a triage playbook. The condensed version your Tier 1 analysts should run:

1. Inventory check. Is this tool and version on the approved software list in the CMDB? If yes and the host is in-scope for that tool, likely benign.
2. Launch lineage. Was the parent explorer.exe (a human double-clicked it), services.exe (installed as persistence), or powershell.exe/an Office app (almost certainly malicious)?
3. Change correlation. Is there an open help-desk ticket or change request justifying remote access to this host at this time? No ticket plus an interactive session is a strong escalation trigger.
4. Session scope. Pull the RMM process’s outbound connections and any child processes. An RMM session that immediately spawns cmd.exe, net.exe, or discovery tooling is hands-on-keyboard activity — escalate to incident response.

The Takeaway

RMM abuse is the technique that punishes detection programs built around malware signatures and rewards those built around environmental baselines. You already have the telemetry — process creation events and network logs — and the query logic is not complex. What it requires is the one input no vendor ships you: an authoritative list of which remote access tools are supposed to be where. Build that watchlist, wire it into the T1219 detection, and you convert a ransomware affiliate’s favorite living-off-the-land technique into one of your highest-fidelity alerts.

Browse the full set of copy-ready KQL and SPL rules across 700+ MITRE ATT&CK techniques in the df00tech detection library, or start with the related lateral movement and command-and-control playbooks to round out coverage of the post-exploitation chain.