Remote management tools (RMM) are a permanent fixture in modern IT environments — ScreenConnect, AnyDesk, TeamViewer, and their counterparts are how sysadmins support remote workers, manage servers, and push updates. They’re also one of the most persistent detection challenges in enterprise security, because attackers have learned that deploying a legitimate RMM tool as their backdoor bypasses most EDR detections and raises no alerts from network controls that whitelist known software.
This technique is catalogued under MITRE ATT&CK T1219 (Remote Access Software) and appears in intrusion chains across ransomware groups (Black Basta, Silent Ransom Group/Luna Moth, Scattered Spider), nation-state actors, and financially motivated BEC actors. The detection surface is real but requires a different approach than standard malware hunting.
Why RMM Abuse Is Increasing
Several factors have converged to make RMM deployment the preferred backdoor technique for certain threat actors:
Signed binaries, whitelisted endpoints. ScreenConnect, AnyDesk, and TeamViewer are code-signed by their respective vendors and known to most endpoint security products. Execution of a signed binary from a known vendor does not trigger behavioural alerts.
Legitimate network destinations. Traffic to AnyDesk relay servers or TeamViewer cloud infrastructure blends with normal enterprise traffic. Network-based detection of C2 communications is ineffective against traffic that looks identical to legitimate IT support.
Operator-side access. Once installed, the RMM gives the attacker a persistent, reliable interactive session that survives reboots, patches, and even some endpoint agent restarts. It is functionally equivalent to a C2 beacon but draws none of the same scrutiny.
Low sophistication required. Deploying ScreenConnect requires no custom malware development. An attacker with initial access via phishing or credential theft can install ScreenConnect in seconds, hand off the session details to a different operator, and never use the compromised account again.
Detection Approach
Detecting unauthorised RMM deployment requires correlating several data sources:
- Process creation events — detecting the initial installation or execution
- Network connections — detecting communications to RMM relay infrastructure
- Parent-child process anomalies — legitimate RMM installations have predictable parents (installers, IT management tools); malicious deployments often have anomalous parents (Office applications, browsers, scripting engines)
- Filesystem indicators — RMM tools dropped to non-standard paths (Temp, AppData, Downloads) rather than Program Files
- Registry persistence — RMM tools that establish run keys or services for persistence
ScreenConnect (ConnectWise) Detection
ScreenConnect is the most commonly abused RMM tool in current ransomware intrusions. It appears in Black Basta, Silent Ransom Group, and multiple other ransomware pre-deployment chains. The client binary is typically named ScreenConnect.ClientService.exe but threat actors frequently rename the executable.
Sigma — ScreenConnect installation from unusual parent process:
title: Suspicious ScreenConnect Client Installation
id: a9f3f4e2-8b12-4d1e-9c3a-7f2e1b5d6c89
status: experimental
description: Detects ScreenConnect client process spawned from unusual parent processes
that suggest malicious deployment rather than legitimate IT installation
logsource:
category: process_creation
product: windows
detection:
selection_child:
Image|endswith:
- '\ScreenConnect.ClientService.exe'
- '\ScreenConnect.WindowsClient.exe'
filter_legit_parents:
ParentImage|endswith:
- '\msiexec.exe'
- '\setup.exe'
- '\ConnectWiseControl.ClientSetup.exe'
- '\svchost.exe'
condition: selection_child and not filter_legit_parents
falsepositives:
- Some enterprise deployment tools may use unusual parent processes
level: high
tags:
- attack.command_and_control
- attack.t1219
Sigma — ScreenConnect binary in suspicious path:
title: ScreenConnect Binary in User-Writable Directory
id: c2e5f8a1-3d47-4b9e-8f1c-6a2b7d4e5f93
status: experimental
description: Detects ScreenConnect executable running from temp or user-writable
directories indicating potential malicious deployment
logsource:
category: process_creation
product: windows
detection:
selection:
Image|contains:
- '\AppData\Local\Temp\'
- '\Users\Public\'
- '\ProgramData\'
- '\Downloads\'
Image|endswith:
- 'ScreenConnect.ClientService.exe'
condition: selection
falsepositives:
- Unusual but possible in some deployment scenarios
level: high
tags:
- attack.command_and_control
- attack.t1219
KQL (Microsoft Sentinel / Defender for Endpoint):
DeviceProcessEvents
| where FileName in~ ("ScreenConnect.ClientService.exe", "ScreenConnect.WindowsClient.exe")
| where not (InitiatingProcessFileName in~ ("msiexec.exe", "svchost.exe"))
| where FolderPath has_any (@"\AppData\Local\Temp\", @"\Users\Public\", @"\ProgramData\", @"\Downloads\")
| project Timestamp, DeviceName, AccountName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
AnyDesk Detection
AnyDesk is frequently used by ransomware groups and BEC actors as a secondary backdoor after initial access. The binary is often renamed and deployed from temp directories.
Sigma — AnyDesk installation with suspicious parent:
title: AnyDesk Deployed from Suspicious Parent Process
id: b7d3e9f5-1a24-4c8d-9e2f-5b3a6c8d7e01
status: experimental
description: Detects AnyDesk executed from Office applications, scripting engines,
or browsers — patterns inconsistent with IT-managed deployment
logsource:
category: process_creation
product: windows
detection:
selection_anydesk:
Image|endswith: '\AnyDesk.exe'
selection_suspicious_parents:
ParentImage|endswith:
- '\WINWORD.EXE'
- '\EXCEL.EXE'
- '\POWERPNT.EXE'
- '\mshta.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\powershell.exe'
- '\cmd.exe'
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
condition: selection_anydesk and selection_suspicious_parents
falsepositives:
- Unlikely; Office and browser parents are not legitimate AnyDesk deployment paths
level: high
tags:
- attack.command_and_control
- attack.t1219
Sigma — AnyDesk silent installation flags:
title: AnyDesk Silent Install with Password Setting
id: f4a7c2e8-9b51-4d6f-8c3e-2a5f7b9d1e47
status: experimental
description: Detects AnyDesk executed with --install and --password flags, consistent
with attacker-controlled unattended installation
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\AnyDesk.exe'
CommandLine|contains|all:
- '--install'
- '--password'
condition: selection
falsepositives:
- Legitimate IT automated deployments could match; verify against authorised deployment records
level: high
tags:
- attack.command_and_control
- attack.t1219
TeamViewer Detection
TeamViewer abuse is less prevalent than ScreenConnect or AnyDesk in recent intrusions but still documented. Detection focuses on registry persistence and non-standard deployment paths.
Sigma — TeamViewer service created outside normal installation:
title: TeamViewer Service Registration from Unusual Path
id: e3b8d5f2-7c19-4a8e-b6d4-9f1c3e7a2b85
status: experimental
description: Detects TeamViewer service creation from paths other than the standard
Program Files installation directory
logsource:
product: windows
category: registry_set
detection:
selection:
TargetObject|contains: 'TeamViewer'
TargetObject|endswith: '\ImagePath'
filter_legit:
Details|contains: 'Program Files'
condition: selection and not filter_legit
falsepositives:
- Non-standard but legitimate enterprise deployments
level: medium
tags:
- attack.persistence
- attack.t1543.003
- attack.t1219
Network-Based Detection
For environments with network logging, RMM relay traffic has distinctive characteristics:
ScreenConnect: Connects to relay infrastructure at *.screenconnect.com on TCP 443 and TCP 8040/8041. Internally hosted ScreenConnect instances communicate to custom relay domains.
AnyDesk: Uses a proprietary protocol on TCP 7070 with fallback to TCP 443. Relay infrastructure includes *.anydesk.com and IP ranges documented by the vendor.
TeamViewer: Communicates to *.teamviewer.com on TCP 5938 with fallback to TCP 443/80.
Detection logic: Alert on connections to these destinations from workstations where RMM tools are not in the authorised software inventory. This requires maintaining an accurate inventory of which devices have legitimate RMM clients installed.
KQL — Unusual network connection to RMM relay infrastructure:
DeviceNetworkEvents
| where RemoteUrl has_any ("screenconnect.com", "anydesk.com", "teamviewer.com")
| join kind=leftouter (
DeviceTvmSoftwareInventory
| where SoftwareName has_any ("ScreenConnect", "AnyDesk", "TeamViewer")
| distinct DeviceName
) on DeviceName
| where DeviceName1 == "" // device not in authorised software inventory
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP
| order by Timestamp desc
Post-Installation Lateral Movement Patterns
Once an RMM tool is established, watch for characteristic post-installation activity:
Process creation from RMM processes: Commands executed via RMM sessions appear as child processes of the RMM client binary. ScreenConnect.ClientService.exe spawning cmd.exe, powershell.exe, or net.exe is a strong indicator of attacker activity.
title: Command Execution via ScreenConnect Service
id: 1a9f7c3e-4b82-4d5a-9c7f-3b2e8d6a5f91
status: experimental
description: Detects command-line tools launched as child processes of ScreenConnect,
indicating active attacker session usage
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: '\ScreenConnect.ClientService.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\net.exe'
- '\nltest.exe'
- '\whoami.exe'
- '\wmic.exe'
condition: selection
falsepositives:
- Legitimate IT administration via ScreenConnect will also match
level: medium
tags:
- attack.execution
- attack.t1059
- attack.command_and_control
- attack.t1219
Hunting Approach
For threat hunters investigating potential RMM abuse:
-
Build a software inventory baseline. Export the list of all machines with authorised RMM client installations from your MDM/SCCM/Intune deployment records. Compare against process execution telemetry for any RMM process running on machines not in the authorised list.
-
Review first-seen timestamps. Legitimate enterprise RMM deployments are handled systematically — the installation date should correspond to a deployment window. RMM binaries that first appeared on a host during off-hours or correlate with other anomalous activity (phishing email receipt, unusual inbound connection) warrant investigation.
-
Check for renamed binaries. Threat actors rename RMM executables to masquerade as system processes. Hunting for the file hash of known RMM binaries regardless of filename uncovers this evasion. Imphash or authenticode certificate checks on binaries in user-writable directories are effective.
-
Correlate with authentication events. Successful RMM sessions that coincide with unusual authentication events (off-hours, new source IPs, newly created accounts) deserve immediate investigation.
The false positive rate for well-tuned RMM detection is manageable. The signal quality from parent process anomalies, installation path checks, and software inventory correlation is high enough to make this a priority detection category in environments where ransomware pre-deployment activity is a concern.