Remote Access Tools

T1219 sits in the middle of the intrusion. Initial access comes first, usually phishing, a callback or help-desk lure, or an exposed RDP or VPN edge. CISA's AA23-025A documented a callback-phishing campaign where a help-desk-themed email carried a phone number; the victim called, was steered to a malicious domain, and pulled down portable AnyDesk and ScreenConnect. Once that RMM channel is live it becomes durable interactive C2, the platform the operator runs discovery, lateral movement, and payload staging from.

The pattern is heavily documented. CISA warns the same tradecraft runs from commodity refund-scam crews through ransomware affiliates and nation-state APTs, because RMM lets them skip custom malware and hide inside traffic that looks like help-desk work. MSP compromise is the amplifier: one abused RMM tenant reaches every downstream customer, which is how a single RMM foothold scales into mass ransomware across an MSP's client base.

This is the technique where legitimate use drowns the signal. Your real help desk, a contracted MSP, and any sanctioned remote-support tool throw the same Event 4697 service installs and the same relay traffic an attacker would. Alerting on 'AnyDesk seen' alone will bury the SOC in help-desk noise. The fix is an allow-list built from what your environment actually runs: the specific RMM products IT sanctions, the accounts and endpoints they run on, and the relay domains or app IDs those tools legitimately use.

Then invert the logic. Signal is the tool NOT on the sanctioned list, for example an Atera install in a ScreenConnect-only shop, a first-seen relay endpoint, and RMM launched from %TEMP% or a portable path instead of Program Files. Tie every hit to a change or help-desk ticket: a sanctioned tool with a matching ticket is noise, an unsanctioned tool or an off-hours session with no ticket is worth a look. Keep the relay allow-list per vendor, since one AnyDesk relay pool looks like any other.

When an unsanctioned RMM alert fires, answer three questions fast. Is there a help-desk or change ticket that explains a remote session on this host right now? Is the tool on the sanctioned list at all? Did the RMM process spawn a child shell, such as ScreenConnect launching cmd.exe or powershell.exe, or reach out to other hosts? A signed binary with a ticket and no child processes is almost always the real help desk.

Escalate when it stacks up: an unsanctioned tool, plus a live interactive session, plus no ticket. Contain by killing the active session and the client process, then block the relay domain and the vendor app ID at the egress proxy so it cannot reconnect. If the RMM spawned a shell or touched a second host, treat it as hands-on-keyboard: isolate the endpoint, capture the process tree and the operator's relay ID for scoping, and hunt that same relay ID across the fleet.