Remote Access Tool Forensics: AnyDesk, TeamViewer and More

Commercial remote access and RMM software has become a favourite for intrusions: it is signed, trusted by EDR, tunnels through firewalls over HTTPS and gives the operator a full desktop. This guide shows you how to prove a tool was installed or run, extract session IDs, IPs and timestamps from each product's own logs, find file transfer traces, and separate attacker use from normal IT support. It builds on the RDP, PsExec and WinRM guide, which covers the native Windows techniques.

For a condensed field reference on the file locations, see the remote access tools artifact page.

Why RMM abuse is hard to spot

Attackers use remote access tools in three ways: dropping a portable binary after initial access, installing a full agent tied to their own account for persistence, or hijacking an RMM platform the victim already uses. The third case is the hardest, because every binary, service and network flow is legitimate. What differs is the account, tenant or session on the other side.

That shapes the investigation. You are not only asking "is AnyDesk here?" but "which instance, registered to whom, used from where, by which local user, and to move which files?" Most of those answers live in plain text logs written by the tool itself, not in Windows event logs.

Installation and execution evidence

Start with the generic evidence that any program leaves. It gives you a first-seen time and a path, which tells you whether you are looking at an IT deployment or an ad hoc drop.

• Services. Most tools install a service to survive reboots and handle UAC prompts. System 7045 records the service name and image path; the service key sits under HKLM\SYSTEM\CurrentControlSet\Services\ (see services). Typical names include AnyDesk, TeamViewer, ScreenConnect Client (<id>), SplashtopRemoteService, AteraAgent and RustDesk, but names can be customised by the installer or the attacker.
• Installed programs. MSI installs write MsiInstaller events (1033, 11707) in the Application log and uninstall entries under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and its WOW6432Node twin. The installed programs page lists the fields worth keeping, including InstallDate and InstallLocation.
• Prefetch and Amcache. Portable runs of AnyDesk.exe from Downloads or C:\Users\Public appear here even when nothing was installed. Amcache gives the SHA1, which you can compare to the vendor's release, and Prefetch gives run counts and last run times.
• Browser downloads. The download history and the Zone.Identifier stream on the installer give the source URL. A download from the vendor's site in the middle of the night, by a user who never needed it, is a strong lead. See Windows browser forensics.
• Process creation. 4688 or Sysmon event 1 shows the parent. An RMM installer launched from cmd.exe under a service account, or from a PowerShell download cradle, is not how IT deploys software.

# Services pointing to common remote access tools (live or mounted SYSTEM hive)
Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -match 'AnyDesk|TeamViewer|ScreenConnect|Splashtop|Atera|RustDesk|ConnectWise' } |
  Select-Object Name, StartMode, State, PathName

# Service installs from the System log
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Where-Object { $_.Message -match 'AnyDesk|TeamViewer|ScreenConnect|Splashtop|Atera|RustDesk' } |
  Select-Object TimeCreated, Message

Per-tool artifacts

The details below reflect commonly observed versions. Vendors rename, move and reformat logs between releases, so confirm against a lab install of the same version when a finding matters.

AnyDesk

• Locations: C:\ProgramData\AnyDesk\ for the installed service, %APPDATA%\AnyDesk\ for the user side and for portable runs.
• ad_svc.trace / ad.trace: verbose trace logs. Lines about incoming sessions often include the remote AnyDesk ID and the remote IP, either a relay address or a direct peer. Search for "Incoming session", "Logged in from" and "External address" style strings rather than exact formats.
• connection_trace.txt: one line per incoming connection with date, time, authentication method (for example User for an accepted prompt, Passwd for unattended password, Token for a saved session) and the remote AnyDesk ID. An unattended Passwd connection at 03:00 is a classic persistence pattern.
• Configuration: system.conf and service.conf hold the local AnyDesk ID and settings such as unattended access; user.conf holds per-user preferences. A newly set unattended password is an attacker favourite.
• File transfer: the trace log records file transfer activity, and some versions also write a dedicated file_transfer_trace.txt. Treat both as optional.

TeamViewer

• Connections_incoming.txt in the install folder (for example C:\Program Files\TeamViewer\): remote TeamViewer ID, display name, start and end time, local Windows user, connection type (remote control or file transfer) and a session GUID. It is the single most useful TeamViewer artifact.
• Connections.txt under %APPDATA%\TeamViewer\: outgoing connections made from this host, useful when the host was used as a jump point.
• Log file: TeamViewer<version>_Logfile.log in the install folder (older versions put the major version in the name) plus rotated _OLD copies. It contains participant details, and file transfer lines naming the files sent or written. The exact wording differs across versions, so search broadly for "file", "Write" and "Download".
• Registry: HKLM\SOFTWARE\TeamViewer (or WOW6432Node) holds the local ClientID and settings; a managed deployment usually shows an assignment to a company account.

ScreenConnect (ConnectWise Control)

• Service and folder: ScreenConnect Client (<16-hex id>) in C:\Program Files (x86)\ or C:\Program Files\. The id is derived from the server instance, so two different ids on one host mean two different ScreenConnect servers.
• system.config / user.config in the client folder: the relay host and port the client calls back to. This is the attacker's server if the instance is rogue.
• Application event log: the client writes events under a source named after the service. Messages describe connection and disconnection of a named participant, file transfers and commands run through the toolbox or backstage. This is unusual among RMM tools and very valuable.
• Transferred files and toolbox items commonly land under C:\Windows\Temp\ScreenConnect\<version>\ or a similar temp path, often with the original file name.
• Server side: if the victim hosts the server, its session database (SQLite in App_Data) and web logs record every session and operator. Collect it before anyone patches or rebuilds the server.

Splashtop

• Streamer service SplashtopRemoteService; logs such as SPLog.txt under the Splashtop Remote Server folder in Program Files (x86). Log names and folders vary by product edition (Business, SOS, Atera-integrated).
• Entries include session start and end, the remote account or device name and sometimes the peer IP.

Atera

• AteraAgent service in C:\Program Files\ATERA Networks\AteraAgent\, with packages downloaded into its subfolders.
• HKLM\SOFTWARE\ATERA Networks\AlphaAgent holds values such as AccountId and IntegratorLogin, the email of the Atera account the agent enrolled with. An unknown email here is close to a confession.
• Atera delegates interactive remote control to integrated tools (Splashtop, AnyDesk), so also check those artifacts.

RustDesk

• Open source, self-hostable, and increasingly seen in intrusions. User config and logs under %APPDATA%\RustDesk\ (config\RustDesk.toml, RustDesk2.toml, log\), and the service profile under C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\ on typical installs.
• RustDesk2.toml may contain a custom-rendezvous-server and relay entry: an attacker-run ID/relay server is a hard indicator.
• The peers folder lists remote IDs that this client connected to.

Quick Assist

• Built into Windows and now delivered as a Store app (quickassist.exe). It has been abused in vishing campaigns where the caller poses as help desk.
• It keeps very little local logging. Rely on Prefetch or the app package folder for execution, SRUM for per-app network usage (see SRUM forensics), process creation telemetry, and what the user ran right after the session.

Network and firewall evidence

Host logs are strongest when paired with network traces.

• Firewall rules and logs. Installers often add inbound rules. Rule creation appears in Microsoft-Windows-Windows Firewall With Advanced Security/Firewall (2004 on older builds, 2097 on newer ones), and pfirewall.log records allowed connections if logging was enabled. See Windows Firewall logs.
• WFP auditing. Security 5156 (connection permitted) names the application, the remote address and port, if "Filtering Platform Connection" auditing is on. It is noisy but decisive.
• Sysmon 3 and 22: network connections and DNS queries per process. Vendor relay domains (*.net.anydesk.com, *.teamviewer.com, a ScreenConnect relay host, *.splashtop.com) and RustDesk ports 21115 to 21119 are useful pivots.
• Perimeter data: proxy, DNS and NetFlow logs confirm the timeline and catch sessions on hosts where the local logs were deleted.

Remember that most tools connect through vendor relays. The IP in a log may be a relay, not the operator. Direct peer connections are the exception and are worth highlighting when you find them.

If a packet capture exists (a network tap, EDR capture or pktmon output converted to pcapng), PCAP Parser opens it in the browser and lists conversations, DNS lookups and TLS SNI, which is often enough to confirm the RMM relay domains contacted during the session.

Session attribution

For each session, build one row: tool, local host, remote ID, remote display name or account, remote IP (and whether it is a relay), local user, start, end, and what happened in between.

• Remote IDs (AnyDesk, TeamViewer, RustDesk) are stable identifiers. The same ID across several victims is a strong link, and vendors can resolve them through legal process.
• Tenant or account (Atera IntegratorLogin, ScreenConnect relay host, TeamViewer company assignment) tells you whether the instance belongs to your organisation at all.
• Local user and logon session: correlate the session start with 4624 on the host (a type 2 or 7 may follow unattended access, depending on how the tool handles the desktop) and with user artifacts. Tools running as SYSTEM act on whatever desktop is active, so check who was logged on at the time.
• What they did: process creation under the tool's process tree, files appearing in Downloads, Temp or the desktop, and PowerShell logs. A process tree rooted at AnyDesk.exe or the ScreenConnect client is interactive operator activity.

File transfer traces

File transfers are where RMM tools most often leak evidence of staging or exfiltration.

• Tool logs: TeamViewer log file lines, AnyDesk trace or file_transfer_trace.txt, ScreenConnect Application log events and temp folder.
• File system: new files with a creation time inside the session window. Parse the $MFT and USN journal for the window and look at who wrote them.
• Clipboard: several tools sync the clipboard, which can carry commands or small files. The clipboard history is worth a look if enabled.

Per-tool reference

MITRE ATT&CK tracks this behaviour as T1219. Recent versions name it Remote Access Tools with sub-techniques, and T1219.002 (Remote Desktop Software) is the one that fits these products.

Legitimate IT use or intrusion?

Build a baseline with IT before drawing conclusions:

• Which product and deployment method IT uses, and which tenant or account. Anything else is suspect by default.
• Install path: managed installs land in Program Files. Portable binaries in Downloads, AppData, ProgramData subfolders or C:\Users\Public are rarely IT.
• Timing: sessions outside the support desk's hours, or right after a suspicious logon, deserve a closer look.
• Configuration: unattended access enabled on a workstation that never needed it, a password set shortly after install, or a custom relay server.
• Stacking: two or three different remote tools installed within minutes is an attacker hedging against removal, never a helpdesk practice.

Pitfalls

• Treating the logged IP as the operator. Most sessions go through relays. Say "relay address" in the report unless you can show a direct connection.
• Relying on one log. Trace logs roll over and attackers delete them. Cross-check with Prefetch, the event logs, Sysmon and the file system.
• Missing the portable copy. Many investigations check installed programs only. Portable binaries write their logs under the user's AppData, not ProgramData.
• Assuming stable formats. A parser written for one AnyDesk or TeamViewer version can silently miss lines in another. Grep the raw text as well.
• Forgetting the legitimate RMM. If the attacker used the company's own platform, the host evidence looks normal. You need the RMM console's audit log, which lives in the vendor cloud or on the RMM server.
• Ignoring time zones. Some tool logs write local time, some UTC. Check against a known event before merging them into a timeline.

Workflow checklist

1. Inventory remote access tools on every host in scope: services, installed programs, Prefetch, Amcache, and portable binaries in user folders.
2. For each instance, record version, install path, install time and the account, tenant or relay it is tied to.
3. Collect the tool's logs and config from both ProgramData and every user's AppData, plus the Application log for ScreenConnect.
4. Build a session table: remote ID, remote name, remote IP (relay or direct), local user, start, end.
5. Map activity inside each session window: process trees under the tool, new files, PowerShell, credential access. See credential access forensics if tools such as Mimikatz appear.
6. Confirm with network evidence: firewall logs, 5156, Sysmon 3/22, proxy and DNS.
7. Compare with the IT baseline and classify each instance as sanctioned, suspicious or malicious.
8. Hunt the same IDs, tenants, hashes and relay hosts across the fleet, and place everything on the incident super timeline.