# AnyDesk Attack Surface Analysis

## Architecture

- **Binary**: AnyDesk.exe (~30-40MB, C++, not packed, standard PE)
- **Protocol**: Custom proprietary (NOT RDP)
- **Codec**: DeskRT — proprietary video codec designed for screen capture, low-latency
- **Transport**: TCP (primary port 6568 for direct, or relay via AnyDesk servers on 80/443)
- **Encryption**: TLS 1.2 with RSA 2048 key exchange, AES-256 for session data
- **Platform**: Windows, macOS, Linux, Android, iOS

## Known CVEs (Sparse — Under-Researched Target)

| CVE | Year | Type | Impact | Details |
|---|---|---|---|---|
| CVE-2024-12754 | 2024 | Path traversal / symlink | Local privesc to SYSTEM | Background image copy runs as SYSTEM. Symlink junction → read SAM/SYSTEM/SECURITY hives. PoC published. Fixed in 9.0.1 |
| CVE-2024-52940 | 2024 | Info disclosure | Public IP exposure | "Allow Direct Connections" leaks public IP. Affects ≤8.1.0 |
| CVE-2025-25065 | 2025 | SSRF | Internal network access | RSS feed parser allows redirecting requests to internal endpoints |
| CVE-2024-45516 | 2024 | XSS | Session injection | Cross-site scripting in user sessions |

**Key observation**: Only 4 CVEs in recent history. Compare to RDP's 7 RCEs in 18 months. This means either AnyDesk is incredibly secure (unlikely for a complex C++ network application) or nobody is looking hard enough (much more likely).

## Attack Surface Map

### 1. DeskRT Codec (HIGHEST VALUE — RCE TARGET)

**What it is**: Proprietary video codec for encoding/decoding screen content. Designed for computer graphics (not video), optimized for text/UI rendering with low latency.

**Attack surface**:
- Frame decompression in the client
- Keyframe vs delta frame parsing
- Color space conversion
- Resolution/scaling calculations (integer overflow potential)
- Tile/block decomposition

**Why it's promising**:
- Fully proprietary — zero public security audits
- Complex binary parsing (decompression algorithms)
- Same bug class as RDP bitmap overflow (CVE-2025-29966): malicious server sends oversized/malformed frame → heap overflow in client
- DeskRT is the core of AnyDesk's value proposition, meaning it's complex and highly optimized (optimization often introduces bounds-checking gaps)

**Approach**:
1. Capture DeskRT frames between two AnyDesk instances (Wireshark/raw TCP capture)
2. Identify frame boundaries and header format
3. RE the decoder in AnyDesk.exe (look for decompression loops, memory allocation based on header fields)
4. Build a fake AnyDesk server that sends malformed DeskRT frames
5. Fuzz frame headers: width, height, stride, tile count, compressed size fields
6. Monitor for crashes (heap overflow, integer overflow, OOB read/write)

### 2. File Transfer (HIGHEST PROBABILITY — PATH TRAVERSAL)

**What it is**: AnyDesk has built-in file transfer (file manager + drag-and-drop).

**Attack surface**:
- Filename handling when receiving files from remote side
- Destination path construction
- Character encoding (UTF-8/UTF-16 filename handling)
- Symbolic link / junction following
- File size validation
- Metadata transfer (timestamps, attributes)

**Why it's promising**:
- Path traversal in file transfer has been found in RDP FOUR separate times (2019, 2020, 2025 x2)
- CVE-2024-12754 shows AnyDesk already has path handling issues (symlink/junction following)
- File transfer in remote desktop software is a consistently vulnerable feature
- If the receiving client doesn't sanitize `..\..\` or `../` in filenames from the remote side, you get arbitrary file write

**Approach**:
1. Set up two AnyDesk instances
2. Initiate file transfer, capture the protocol
3. RE the filename parsing in the receiving client
4. Test: send a file with name `..\..\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\payload.bat`
5. Test: send a file with name using forward slashes `../../`
6. Test: Unicode path separators, null bytes, double encoding
7. If path traversal works → arbitrary file write → Startup folder → code execution

### 3. Clipboard Sync

**What it is**: Bidirectional clipboard sharing between connected machines.

**Attack surface**:
- Clipboard format parsing (text, rich text, images, files)
- File copy/paste operations (FileGroupDescriptor equivalent)
- Image format parsing (bitmap data from clipboard)
- Large clipboard data handling (buffer allocation)

**Why it's promising**:
- Same attack surface that produced CVE-2019-0887 in RDP
- If AnyDesk supports file copy/paste via clipboard, the filename in the file descriptor is server-controlled input
- Image clipboard data requires decoding — potential for heap overflow

**Approach**:
1. Copy a file on the remote side, paste on the local side
2. Capture the clipboard protocol messages
3. RE the file descriptor format
4. Inject path traversal in the filename
5. Test image clipboard with oversized/malformed bitmap data

### 4. Auto-Update Mechanism

**What it is**: AnyDesk checks for and downloads updates automatically.

**Attack surface**:
- Update check URL — is it HTTPS with cert pinning?
- Download verification — signature check, hash verification
- Update extraction — temp directory, file permissions
- Update execution — does the new binary get verified before launch?

**Why it's promising**:
- If there's no cert pinning, a MITM (or DNS hijack) can serve a malicious update
- If signature verification is weak or bypassable, the update binary can be replaced
- The update runs with whatever privilege AnyDesk has (often SYSTEM if installed as service)
- CVE-2024-12754 showed AnyDesk's SYSTEM-level file operations are exploitable

**Approach**:
1. Monitor AnyDesk's update check (Wireshark + DNS capture)
2. Identify the update URL and certificate chain
3. Attempt MITM with a self-signed cert (test for cert pinning)
4. If pinned: look for pinning bypass (older TLS, fallback URLs)
5. If not pinned: serve a modified binary, check if it's accepted
6. Examine signature verification code in AnyDesk.exe

### 5. Protocol Framing / Handshake

**What it is**: The custom protocol that wraps all AnyDesk communication.

**Attack surface**:
- Message type/length fields — integer overflow in length parsing
- Handshake/authentication — can a malicious server send unexpected responses?
- Channel multiplexing — can you send data on unexpected channels?
- Compression — if messages are compressed, decompression bugs

**Approach**:
1. Capture raw TCP traffic between two instances
2. Identify the framing format (TLV? length-prefixed? delimiter?)
3. Map all message types
4. Build a fake server that sends malformed messages
5. Fuzz length fields, type fields, out-of-order messages

## Research Priority

| Target | Difficulty | Probability | Impact | Priority |
|---|---|---|---|---|
| File transfer path traversal | Low-Medium | Very High | High (arbitrary file write) | **1** |
| DeskRT codec fuzzing | Medium-High | High | Critical (heap overflow → RCE) | **2** |
| Clipboard file paste | Medium | High | High (arbitrary file write) | **3** |
| Auto-update MITM | Low-Medium | Medium | Critical (RCE as SYSTEM) | **4** |
| Protocol framing | Medium | Medium | Variable | **5** |

## Setup Requirements

1. Two Windows VMs (or one VM + host)
2. AnyDesk installed on both (free version works)
3. Wireshark with TCP stream capture
4. IDA Pro or Ghidra for RE of AnyDesk.exe
5. x64dbg attached to AnyDesk for dynamic analysis
6. Python for building fake server / protocol replayer

## Key Files to RE

| File | What to Look For |
|---|---|
| `AnyDesk.exe` | Main binary — all protocol handling, codec, file transfer |
| `*.dll` in AnyDesk install dir | Any helper DLLs (crypto, codec, etc.) |
| `%ProgramData%\AnyDesk\` | Config files, logs, connection data |
| `%AppData%\AnyDesk\` | User-level config |
| `ad.trace` / `connection_trace.txt` | Debug logs with protocol info |

## References

- [CVE-2024-12754 PoC and Analysis](https://securityonline.info/anydesk-exploit-alert-cve-2024-12754-enables-privilege-escalation-poc-available/)
- [CVE-2024-52940 IP Exposure](https://www.splashtop.com/blog/lessons-from-anydesk-ip-exposure-vulnerability)
- [AnyDesk February 2024 Breach](https://thehackernews.com/search/label/AnyDesk)
- [NCC Group: Threat Actors Leveraging AnyDesk](https://www.nccgroup.com/research/the-dark-side-how-threat-actors-leverage-anydesk-for-malicious-activities/)
- [AnyDesk CVE List](https://www.cvedetails.com/vulnerability-list/vendor_id-16953/Anydesk.html)
