How to Investigate Rogue Remote Access Tools in a Client Incident

Legitimate remote access software is one of the most common footholds in ransomware and extortion cases, because it is signed, trusted and often allowed straight through the firewall. When an unapproved copy turns up in a client estate, you need to answer three questions fast: where else is it, who was connected, and what did they do? This guide walks incident responders through scoping, evidence collection, timelining and containment across client environments.

Agree what is sanctioned before you hunt

Every client uses remote tools differently, and you cannot call something rogue until you know what is approved. Before you run a single query, confirm with the client contact which products, which vendor instances and which hosts are expected. An MSP's own RMM agent on every endpoint is normal. The same product connecting to a different vendor account is not.

Question	Why it matters	Where to get the answer
Which remote tools are approved?	Anything else becomes an immediate lead	Client asset register or software policy
Which vendor instance or account?	Attackers often install the same product the client uses, tied to their own account	Your RMM console, licensing records
Who administers it?	Tells you whose sessions are expected	Service desk rota, MSP engineer list
Is portable use allowed?	Portable executables run without admin rights and bypass software controls	Application control policy

Sweep the estate for remote access software

Scope first, then go deep. The aim of this step is a list of every host where a remote tool ran, with first and last seen times, the path it ran from and who signed it. Run the same sweep in every tenant you manage if the tool or vendor account is new to you, because attackers reuse their setup across victims.

Microsoft Defender XDR or Sentinel

This query looks for known executable names and product metadata, so it still catches renamed copies where the version information is intact.

let RmmFiles = dynamic(["anydesk.exe", "teamviewer.exe", "teamviewer_service.exe",
    "screenconnect.clientservice.exe", "screenconnect.windowsclient.exe", "rustdesk.exe"]);
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ (RmmFiles)
    or ProcessVersionInfoProductName has_any ("AnyDesk", "TeamViewer", "ScreenConnect", "RustDesk")
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
    Devices = dcount(DeviceName), DeviceList = make_set(DeviceName, 50),
    Paths = make_set(FolderPath, 20), Accounts = make_set(AccountName, 20)
    by FileName, ProcessVersionInfoCompanyName
| order by FirstSeen asc

Then check the network side. Process telemetry tells you the tool ran. Network telemetry tells you it actually reached the vendor's relay.

DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any ("anydesk.com", "teamviewer.com", "screenconnect.com", "rustdesk.com")
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), Connections = count()
    by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath
| order by FirstSeen asc

Splunk with Windows System logs

Installed copies usually create a service, which lands as Event ID 7045 in the System log. A new service with a random suffix, such as ScreenConnect Client (5f2a91c0d4e8b713), on a host your MSP does not manage is a strong lead.

index=wineventlog source="XmlWinEventLog:System" EventCode=7045
    (ServiceName="*AnyDesk*" OR ServiceName="*ScreenConnect*" OR ServiceName="*TeamViewer*" OR ServiceName="*RustDesk*")
| table _time host ServiceName ImagePath StartType AccountName
| sort _time

Read the session logs on each host

The vendor relay hides the operator's address from your firewall, so the tool's own logs are often the best record of who connected and when. Collect them before you change anything. Copy the files with a trusted triage tool or your EDR's file collection feature, hash them and work on the copies.

Search collected AnyDesk traces

This runs against the copies in your case folder, not the live host. The patterns pick out session requests, the line that carries the remote address, session acceptance and end, and file transfer activity.

$evidence = 'E:\Cases\CLIENT-0412\FS-02\AnyDesk'
Get-ChildItem -Path $evidence -Recurse -Include 'ad.trace', 'ad_svc.trace', 'connection_trace.txt' |
    Select-String -Pattern 'Incoming session request', 'logged in from', 'Accepting the connect request', 'Session stopped', 'files' |
    Select-Object Path, LineNumber, Line |
    Export-Csv -Path (Join-Path $evidence 'anydesk_hits.csv') -NoTypeInformation

Pull ScreenConnect events from an exported log

Get-WinEvent -FilterHashtable @{
    Path = 'E:\Cases\CLIENT-0412\WS-114\Application.evtx'
    Id   = 100, 101, 200, 201
} | Where-Object { $_.ProviderName -like 'ScreenConnect*' } |
    Select-Object TimeCreated, Id, ProviderName, Message

Build the session timeline

A remote access incident usually follows the same shape. The diagram shows the stages and the evidence that covers each one. Your job is to fill every box with times and facts, and to mark clearly which boxes you cannot fill.

Once the tool logs give you a session window, pull everything that happened on the host inside it. Children of the remote tool process are the clearest sign of hands on keyboard activity.

let HostPrefix = "fs-02";
let SessionStart = datetime(2026-11-09T02:10:00Z);
let SessionEnd = datetime(2026-11-09T03:40:00Z);
union
    (DeviceProcessEvents
    | project Timestamp, DeviceName, Source = "Process", Parent = InitiatingProcessFileName, Detail = ProcessCommandLine),
    (DeviceFileEvents
    | where ActionType == "FileCreated"
    | project Timestamp, DeviceName, Source = "File", Parent = InitiatingProcessFileName, Detail = FolderPath),
    (DeviceLogonEvents
    | project Timestamp, DeviceName, Source = "Logon", Parent = InitiatingProcessFileName, Detail = strcat(AccountName, " ", LogonType))
| where DeviceName startswith HostPrefix
| where Timestamp between (SessionStart .. SessionEnd)
| order by Timestamp asc

Look for discovery commands, new local accounts, archive tools, other remote tools being added for redundancy and connections to file shares. Each of those widens your scope to new hosts or accounts, so feed them back into the estate sweep.

Contain without losing the evidence

Containment order matters. Removing the tool first destroys logs and warns the operator, who may already have a second way in. Work through it in this order, with the client's agreement at each step.

• Collect tool logs, relevant event logs and EDR timelines from every affected host first.
• Isolate affected hosts with EDR network containment, which keeps your management channel open.
• Block the vendor domains for unapproved tools at the proxy and DNS layer for the whole tenant.
• Stop and remove the services and binaries, then confirm nothing restarts after a reboot.
• Add the tools to application control so a reinstall fails rather than alerts.

Report findings to the client

The client needs decisions, not raw logs. Lead with what you know, what you do not know yet and what you need them to do. Keep the technical appendix for their IT team.

• Scope: hosts and accounts involved, with first and last seen times in UTC.
• Access: how the tool arrived, which remote IDs or accounts connected and for how long.
• Actions: commands, file transfers and any data staging or access to sensitive shares.
• Gaps: hosts without EDR, logs that had rolled over, sessions you could not attribute.
• Actions for the client: credential resets, policy changes and whether regulators, insurers or data subjects may need to be told.

Be careful with attribution. A remote ID or display name in a log is a lead, not an identity. State the facts and leave conclusions about who was behind the keyboard to evidence that supports them.

Key takeaways

---

Save the sweep queries as shared hunting queries in every tenant you manage and run them weekly against each client's approved tool list. The next unapproved install then becomes a quick conversation with the client rather than a 02:00 incident.

Written by Chris, Lead IR Consultant, MSP