AnyDesk Trace File Forensics
Research findings on AnyDesk trace file artifacts, authentication methods, and forensic data extraction for incident response.
AnyDesk trace files contain rich forensic data for incident response investigations. This post documents research findings on what data is available, how authentication is logged, and which artifacts matter most for detecting unauthorized remote access.
Trace File Locations
AnyDesk stores trace files differently depending on installation type.
Installed Mode (Program Files):
1
2
C:\ProgramData\AnyDesk\ad_svc.trace # Service trace (primary)
C:\Users\<user>\AppData\Roaming\AnyDesk\ad.trace # User trace (supplemental)
Portable Mode (standalone executable):
1
<exe_directory>\ad.trace # Single trace file
The service trace (ad_svc.trace) contains network and authentication events. The user trace (ad.trace) contains session metadata like remote alias, OS, and version. In portable mode, both types of data appear in a single file.
Authentication Methods
AnyDesk supports multiple authentication methods, each logged differently in trace files.
Official Authentication Types
| Method | Description |
|---|---|
| Manual Accept | User clicks “Allow” on connection prompt |
| Unattended Password | Pre-configured password for remote access |
| Token (Auto-login) | Saved token from previous successful auth |
| 2FA | TOTP code in addition to password |
Trace File Patterns
The service trace logs authentication events with specific patterns:
| Log Pattern | Meaning |
|---|---|
Authenticated by local user (elevated) | User accepted with admin elevation |
Authenticated by local user | User clicked Allow |
Authenticated by password | Unattended password used |
Authenticated with permanent token | Saved token authentication |
Authenticated with correct passphrase | Passphrase authentication |
For forensic purposes, these can be grouped into three categories:
| Category | Patterns | Forensic Significance |
|---|---|---|
user_accepted | by local user | Someone was at the keyboard |
user_accepted_elevated | by local user (elevated) | Admin consent given |
unattended_password | by password, with permanent token, with correct passphrase | Non-interactive access (higher risk) |
Unattended authentication is particularly significant in investigations. It indicates the attacker had pre-configured credentials, suggesting prior compromise or insider access.
Forensic Data Fields
The trace files contain several fields valuable for incident response.
Network Indicators
| Field | Log Pattern | Example |
|---|---|---|
| Remote IP | Logged in from X.X.X.X:port | Logged in from 203.0.113.45:7070 |
| Relay IP | Using IPv4: X.X.X.X | Using IPv4: 185.20.97.12 |
| Connection Type | Route type: direct (LAN)? | Route type: direct |
The remote IP is the attacker’s actual IP address. The relay IP is AnyDesk’s infrastructure used for signaling, even on direct connections.
Remote Client Identifiers
| Field | Log Pattern | Example |
|---|---|---|
| Client ID | Client-ID: X (FPR: Y) | Client-ID: 1810556864 |
| Fingerprint | Client-ID: X (FPR: Y) | FPR: a1b2c3d4e5f6... |
| Remote Alias | Incoming session request: Name (ID) | Incoming session request: Alex (1810556864) |
The fingerprint is particularly useful for correlation. It persists across IP changes and can link sessions from the same remote AnyDesk installation.
Session Metadata
| Field | Log Pattern | Example |
|---|---|---|
| Remote OS | Remote OS: X | Remote OS: Windows |
| Remote Version | Remote version: X.X.X | Remote version: 8.2.0 |
| Session Start | Timestamp from Accept request from | 2026-01-30 14:23:45.123 |
Connection Type Detection
AnyDesk connections fall into three categories:
| Type | Log Indicator | Meaning |
|---|---|---|
direct_lan | Route type: direct (LAN) | Same local network |
direct_wan | Route type: direct (no LAN) | Direct internet connection |
relay | No “direct” route type | Traffic routed through AnyDesk servers |
Direct LAN connections are particularly interesting in investigations. They indicate the attacker was on the same network as the victim, suggesting internal threat or lateral movement.
Session State Detection
A critical forensic consideration is detecting in-progress sessions. The pattern works by comparing timestamps:
1
2
Accept request from ... (timestamp A)
Authenticated ... (timestamp B)
- If
A > B(accept is newer than auth): Session is establishing, auth hasn’t completed yet - If
B > A(auth is newer than accept): Session is fully established
This matters for live response. During active sessions, you may see the accept event but not yet the authentication event.
Data Source Comparison
AnyDesk creates multiple log files. Here’s what each contains:
| File | Content | Parsing Value |
|---|---|---|
ad_svc.trace | Network events, authentication, IPs | High (primary source) |
ad.trace | UI events, remote alias, OS, version | Medium (supplemental) |
connection_trace.txt | Structured connection log | Medium (less detail than .trace) |
user.conf / system.conf | Configuration only | Low (no session data) |
The .trace files provide richer data than connection_trace.txt, making them the preferred source for forensic parsing.
Artifacts Not Covered
Some AnyDesk artifacts require separate analysis:
| Artifact | Location | Use Case |
|---|---|---|
| File transfers | Trace files (different patterns) | Data exfiltration detection |
| Chat logs | Trace files | Communication analysis |
| Screenshots | Not logged | Unavailable |
File transfer detection is a separate use case with different patterns and would warrant its own parsing logic.
Implementation Notes
When building automated parsing:
- Handle both install types - Check process path to determine if installed (Program Files) or portable
- Merge data sources - In installed mode, combine service trace (network/auth) with user trace (metadata)
- Use last-match logic - For repeating patterns, the most recent entry reflects the current/latest session
- Generate session hashes -
SHA256(client_id|session_start)[:16]provides a correlation key across workflows