Detect Ransomware Affiliates Weaponizing Legitimate RMM Software (ScreenConnect, AnyDesk, Atera) as Post-Compromise Access Tooling in Elastic Security
Rather than developing custom malware, ransomware affiliates and initial access brokers increasingly obtain commercially available, code-signed Remote Monitoring and Management (RMM) software — ScreenConnect, AnyDesk, Atera, Splashtop, NetSupport Manager — for use as post-compromise remote-access tooling. Because these tools are legitimate, digitally signed, and widely deployed by managed service providers, they are frequently absent from allowlists built around known-malicious binaries (Mimikatz, Cobalt Strike, PsExec) and evade signature-based AV/EDR detection entirely. The documented Storm-1811/Black Basta chain (CISA AA23-325A) begins with email-bombing a victim with spam, then a threat actor impersonating IT/helpdesk staff calls the victim and talks them into opening Microsoft Quick Assist (quickassist.exe) or Windows Remote Assistance (msra.exe) to grant screen control; the actor then installs ScreenConnect or AnyDesk through that session to establish durable, unauthorized remote access before deploying ransomware. Detection therefore pivots from the acquisition itself (which occurs outside the victim environment via a legitimate vendor download/trial signup) to observing the installation and execution of RMM binaries that are not present on the organization's sanctioned-tooling allowlist, with highest confidence when that installation is directly preceded by a Quick Assist or Remote Assistance session on the same endpoint.
MITRE ATT&CK
- Tactic
- Resource Development
Elastic Detection Query
sequence by host.name with maxspan=4h
[process where event.type == "start" and
process.name : ("quickassist.exe", "msra.exe")]
[process where event.type == "start" and
process.name : ("screenconnect.clientservice.exe", "screenconnect.windowsclient.exe",
"anydesk.exe", "ateraagent.exe", "srservice.exe", "client32.exe",
"teamviewer.exe", "lmiguardiansvc.exe", "rustdesk.exe", "gotoresolve.exe")]EQL sequence reconstructing the highest-confidence variant of this scenario: a Quick Assist or Windows Remote Assistance session followed, on the same host within 4 hours, by the launch of any RMM client binary. This captures the documented Storm-1811/Black Basta chain directly; pair with a standalone Elastic rule alerting on any of the listed RMM binaries absent from an EDR exception/allowlist for the broader, lower-confidence unsanctioned-tool signal that this sequence cannot express alone.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate IT help desk workflows that use Quick Assist and then hand off to a sanctioned RMM tool for follow-on support
- Coincidental, unrelated RMM installation shortly after a genuine Quick Assist troubleshooting session
Other platforms for THREAT-RMM-UnauthorizedToolDeployment
Testing Methodology
Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate Quick Assist Followed by Unsanctioned RMM Binary Launch
Expected signal: Sysmon Event ID 1 / Security Event ID 4688: process creation for quickassist.exe (renamed notepad.exe copy) followed approximately 5 seconds later by process creation for anydesk.exe (renamed notepad.exe copy), both under the test account on the same host.
- Test 2Unsanctioned RMM Binary Execution Without Prior Remote-Assist Session
Expected signal: Sysmon Event ID 1 / Security Event ID 4688: process creation for ateraagent.exe (renamed notepad.exe copy), with no preceding quickassist.exe or msra.exe event on the same host.
References (4)
Response Playbook
Triage
- Identify which RMM binary launched, the full install path, and the parent process — a parent of explorer.exe following a browser download suggests a self-service install, while a parent of msra.exe or quickassist.exe indicates the tool arrived via a live remote-support session
- Check whether the account and device have any legitimate change ticket, MSP dispatch record, or help desk ticket authorizing remote access at the time of installation
- Pull DeviceNetworkEvents / firewall logs for the RMM process in the 15 minutes following install — a connection to the vendor's relay infrastructure (e.g., *.screenconnect.com, *.anydesk.com, *.atera.com) confirms an active remote session was established, not just a dormant install
- If a Quick Assist or msra.exe session preceded the install, pull Windows Event ID 4688 / Sysmon Event ID 1 to confirm the exact handoff timing and determine whether the same user was active on the console throughout (consistent with a live social-engineering call) versus the install occurring with no console interaction (consistent with a scripted/automated deployment, which points toward a different access vector such as a compromised RMM console itself)
- Check the RMM tool's configured connection ID / account email against known IAB (initial access broker) or affiliate infrastructure via threat intelligence — many Storm-1811 ScreenConnect instances reuse a small set of relay/licensing accounts across victims
- Determine whether the RMM session was used to stage additional tooling — query DeviceFileEvents for files written to disk by the RMM client process in the hour following connection (common staging: Cobalt Strike beacons, AnyDesk/ScreenConnect used to drop a second RMM tool for redundant access, or direct ransomware binary transfer)
Containment
- Immediately terminate the RMM client process and uninstall it; if the vendor's relay infrastructure is not otherwise used by the organization, block the vendor's domains/IP ranges at the firewall and web proxy
- Isolate the endpoint via EDR network containment if any follow-on tooling, credential access activity, or lateral movement is observed originating from the RMM session
- Force a password reset and revoke active sessions/tokens for the account that was active during the RMM session, since the actor had full interactive screen control
- Search the environment for the same RMM binary hash, install path, or connection ID across all endpoints — Storm-1811/Black Basta campaigns frequently touch multiple hosts per victim organization in a single engagement
- If the RMM tool was installed via a live help-desk-impersonation phone call, alert the broader user population (especially the same department) that a vishing campaign is active, since these campaigns typically target many employees within the same organization over a short window
- Revoke and rotate any licensing/relay credentials associated with the organization's own sanctioned RMM deployment if there is any indication the actor abused a legitimate existing RMM console rather than installing a new instance
Evidence Collection
- Full process creation record for the RMM binary: path, command line, parent process, hash, digital signature details, and install timestamp
- DeviceNetworkEvents / proxy logs showing the RMM client's connection to vendor relay infrastructure, including the destination FQDN and any embedded session/connection identifiers in the URL or TLS SNI
- Windows Event ID 4688 / Sysmon Event ID 1 for quickassist.exe or msra.exe on the same host in the hours preceding the RMM install, establishing the help-desk vishing timeline if present
- Call detail records or telephony/UC platform logs (Teams, RingCentral) if the organization can correlate an inbound call to the victim around the time of the Quick Assist session
- RMM vendor-side session logs (ScreenConnect/AnyDesk/Atera admin console audit logs), if the organization has an existing sanctioned deployment of the same vendor, to check whether the rogue session used a compromised legitimate license
- Any files written to disk by the RMM client process during the session (DeviceFileEvents), preserved for malware family identification if further tooling was staged
Escalation Criteria
- !The RMM binary is confirmed not on the organization's approved-tooling list AND made an outbound connection to vendor relay infrastructure (active, not just installed)
- !The RMM install was directly preceded by a Quick Assist or Remote Assistance session on the same host — the documented Storm-1811/Black Basta chain, treat as active intrusion, not just policy violation
- !The RMM session staged additional tooling (credential dumpers, a second RMM client, Cobalt Strike, ransomware binaries) or performed Active Directory reconnaissance
- !The same RMM binary/connection ID appears across multiple hosts or users in the organization within a short window
- !The affected account has privileged (Domain Admin, Global Admin, or server-tier) access
Investigation Guide
Related Techniques
Forensic Artifacts
- >
RMM client installation directory and configuration files (e.g., ScreenConnect: %ProgramData%\ScreenConnect Client*; AnyDesk: %ProgramData%\AnyDesk\; Atera: %ProgramData%\ATERA Networks\) — configuration files often embed the licensing/relay account identifier used to attribute the campaign - >
Windows Prefetch (%SystemRoot%\Prefetch\) for the RMM binary and for quickassist.exe/msra.exe, establishing execution order and timing - >
Sysmon Event ID 3 (Network Connection) for the RMM process, showing the relay server FQDN/IP and connection duration (session length) - >
Sysmon Event ID 13 / Registry — RMM tools commonly install a Run key or service entry for persistence; check HKLM\SYSTEM\CurrentControlSet\Services and HKCU/HKLM Run keys - >
Windows Security Event Log 4688 (Process Creation) and 7045 (New Service Installed) if the RMM client registers itself as a Windows service - >
AmCache.hve — first-execution timestamp and hash for the RMM binary, useful when the tool has since been uninstalled - >
Browser download history — if the RMM installer was self-service downloaded during the live session rather than delivered as a pre-staged file, the browser history will show the download URL and referrer
Tuning Guidance
This detection's entire value depends on maintaining an accurate, current watchlist/reference set/lookup table of the RMM tools your organization and its MSP actually use — without it, every legitimate support session alerts. Build the allowlist from your MSP contract and IT asset inventory, not from what you observe in the environment (observed tools may already include unauthorized shadow-IT RMM installs). Review and refresh the list whenever the MSP relationship changes or a new RMM vendor is contracted. The Quick-Assist-to-RMM correlation window (4 hours in the example queries) should be tightened to 30-60 minutes in environments with a fast, well-documented help desk handoff process, which reduces false correlation with unrelated later activity on a shared/kiosk device. Where possible, prefer blocking unsanctioned RMM vendor domains/relay infrastructure outright at the web proxy over pure detection — CISA AA23-325A recommends organizations audit and restrict which remote access/management tools are permitted to run at all, since the acquisition cost for adversaries (a free trial signup) is far lower than the cost of building custom tooling that this same watchlist approach would otherwise catch as "unknown."
Hunting Queries
Baselines every occurrence across the last 30 days where a Quick Assist / Remote Assistance session was followed within 4 hours by installation of any RMM client, regardless of sanctioned status. Reviewing this full history (rather than only unsanctioned-tool alerts) helps distinguish the organization's normal help-desk-to-RMM handoff pattern from anomalous instances, and retroactively surfaces intrusions that predate the watchlist being populated.
// Hunt for any host that has EVER run a Quick Assist / Remote Assistance session followed by
// installation of ANY RMM tool (sanctioned or not) — establishes a baseline of legitimate vs.
// suspicious help-desk-to-RMM handoffs across the environment for retrospective review
let RemoteAssistPrecursors = dynamic(["quickassist.exe", "msra.exe"]);
let RMMBinaries = dynamic([
"screenconnect.clientservice.exe", "screenconnect.windowsclient.exe", "anydesk.exe",
"ateraagent.exe", "srservice.exe", "client32.exe", "teamviewer.exe",
"lmiguardiansvc.exe", "rustdesk.exe", "gotoresolve.exe"
]);
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName has_any (RemoteAssistPrecursors)
| project DeviceName, QaTimestamp = Timestamp, QaProcess = FileName
| join kind=inner (
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName has_any (RMMBinaries)
| project DeviceName, RmmTimestamp = Timestamp, RmmProcess = FileName, AccountName
) on DeviceName
| where RmmTimestamp > QaTimestamp and RmmTimestamp - QaTimestamp <= 4h
| project DeviceName, AccountName, QaProcess, QaTimestamp, RmmProcess, RmmTimestamp
| sort by RmmTimestamp descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\quickassist.exe" OR Image="*\\msra.exe")
| rename _time as qa_time, Image as qa_image, host as qa_host
| join type=inner host [
search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\screenconnect*" OR Image="*\\anydesk.exe" OR Image="*\\ateraagent.exe" OR Image="*\\teamviewer.exe" OR Image="*\\rustdesk.exe")
| rename _time as rmm_time, Image as rmm_image
| table host, rmm_time, rmm_image, User
]
| where (rmm_time - qa_time) <= 14400 AND (rmm_time - qa_time) >= 0
| table qa_host, User, qa_image, qa_time, rmm_image, rmm_time
| sort - rmm_timeHunts for RMM binaries that establish an outbound network connection within an hour of being written to disk, confirming the tool was used for an active remote session immediately after installation rather than sitting unused — a strong indicator of adversary-driven deployment versus a routine IT provisioning task that may install the tool well ahead of first use.
// Hunt for RMM client processes making outbound connections shortly after a fresh install —
// confirms the tool was actively used for a remote session rather than sitting dormant
let RMMBinaries = dynamic([
"screenconnect.clientservice.exe", "screenconnect.windowsclient.exe", "anydesk.exe",
"ateraagent.exe", "srservice.exe", "client32.exe", "teamviewer.exe",
"rustdesk.exe", "gotoresolve.exe"
]);
DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName has_any (RMMBinaries)
| where ActionType == "FileCreated"
| project DeviceName, InstallTime = Timestamp, InstalledFile = FileName
| join kind=inner (
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName has_any (RMMBinaries)
| where RemoteIPType == "Public"
| project DeviceName, ConnTime = Timestamp, RemoteUrl, RemoteIP, InitiatingProcessFileName
) on DeviceName
| where ConnTime > InstallTime and ConnTime - InstallTime <= 1h
| project DeviceName, InstalledFile, InstallTime, ConnTime, RemoteUrl, RemoteIP
| sort by InstallTime descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
(TargetFilename="*screenconnect*" OR TargetFilename="*anydesk*" OR TargetFilename="*ateraagent*" OR TargetFilename="*teamviewer*" OR TargetFilename="*rustdesk*")
| rename _time as install_time, host as install_host
| join type=inner host [
search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
(Image="*screenconnect*" OR Image="*anydesk.exe" OR Image="*ateraagent.exe" OR Image="*teamviewer.exe" OR Image="*rustdesk.exe")
| rename _time as conn_time
| table host, conn_time, DestinationHostname, DestinationIp
]
| where (conn_time - install_time) <= 3600 AND (conn_time - install_time) >= 0
| table install_host, install_time, conn_time, DestinationHostname, DestinationIp
| sort - install_timeAtomic Red Team Tests
Simulates the Storm-1811/Black Basta help-desk vishing chain by launching a stand-in for quickassist.exe followed shortly after by a stand-in for an RMM client binary on the same host, validating that the join/sequence logic correctly correlates the two events within the 4-hour window. Uses copies of a benign Windows binary renamed to match the monitored process names, run with a harmless argument, to generate realistic process-creation telemetry without installing real remote-access software.
Command
copy C:\Windows\System32\notepad.exe "%TEMP%\quickassist.exe" && "%TEMP%\quickassist.exe" & timeout /t 5 & copy C:\Windows\System32\notepad.exe "%TEMP%\anydesk.exe" && "%TEMP%\anydesk.exe"Cleanup
taskkill /IM notepad.exe /F 2>nul & del /F /Q "%TEMP%\quickassist.exe" "%TEMP%\anydesk.exe" 2>nulExpected Telemetry
Sysmon Event ID 1 / Security Event ID 4688: process creation for quickassist.exe (renamed notepad.exe copy) followed approximately 5 seconds later by process creation for anydesk.exe (renamed notepad.exe copy), both under the test account on the same host.
Expected Detection
Main KQL/SPL detection fires with HelpDeskVishingChain=true / RiskScore=Critical since the RMM-named binary launch falls within the 4-hour correlation window of the Quick-Assist-named launch. Elastic EQL sequence rule matches directly. Note: since the renamed binaries are not digitally signed as the real vendor tools and do not match the FileName-only match logic exactly if hash/signature validation is layered on top in production — validate against process name matching only for this atomic test.
Simulates the lower-confidence variant of this scenario — an RMM client binary appearing on a host with no preceding Quick Assist/Remote Assistance session, representing a self-service or shadow-IT install that should still alert (at High rather than Critical severity) if the binary is absent from the approved-tooling watchlist.
Command
copy C:\Windows\System32\notepad.exe "%TEMP%\ateraagent.exe" && "%TEMP%\ateraagent.exe"Cleanup
taskkill /IM notepad.exe /F 2>nul & del /F /Q "%TEMP%\ateraagent.exe" 2>nulExpected Telemetry
Sysmon Event ID 1 / Security Event ID 4688: process creation for ateraagent.exe (renamed notepad.exe copy), with no preceding quickassist.exe or msra.exe event on the same host.
Expected Detection
Main detection fires with HelpDeskVishingChain=false / RiskScore=High, confirming the query correctly alerts on unsanctioned RMM execution even absent the help-desk vishing precursor, provided the test binary name is not present in the ApprovedRMMTools watchlist/lookup used in the deployed environment.