anydeskrce-something/02-exploitable-vulns-and-attack-methods.md

AnyDesk — Exploitable Vulnerabilities & Attack Methods

Executive Summary

AnyDesk has only 4 publicly known CVEs in recent history — a suspiciously low number for a complex C++ network application handling video codecs, file transfers, clipboard sync, and custom protocol framing. The February 2024 breach (code signing keys + source code stolen) confirms the codebase exists in adversary hands. The attack surface is massive and almost entirely unresearched.

---

Known CVEs — Detailed Analysis

CVE-2024-12754 — Symlink/Junction Path Traversal → Local Privilege Escalation to SYSTEM

CVSS: 5.5 (Medium) — but functionally gives SYSTEM file read Discoverer: ZDI-24-1711 Affected: AnyDesk < 9.0.1 Fixed: AnyDesk 9.0.1

Technical Details: The AnyDesk service (running as SYSTEM) copies the user's desktop background image to a cache location during session setup. The vulnerability:

1. AnyDesk service reads the current user's background image path from registry
2. Service copies the file to an AnyDesk cache directory
3. The copy operation runs as NT AUTHORITY\SYSTEM
4. The service does NOT validate that the source path doesn't traverse through symlinks/junctions

Exploitation:

1. Attacker creates a junction point: C:\Users\<user>\AppData\Roaming\AnyDesk\wallpaper → \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\CONFIG\
2. Sets background image to point to a file in the junction target
3. AnyDesk service follows the junction (running as SYSTEM) and copies SAM/SYSTEM/SECURITY hive files
4. Attacker reads the copied hive files from the AnyDesk cache directory
5. Extract NTLM hashes from SAM + SYSTEM → credential theft → domain compromise

Key Insight for Further Research:

• AnyDesk's SYSTEM service performs file operations based on user-controlled paths
• If there are OTHER file operations the service performs (logs, configs, temp files), the same symlink attack class may apply
• The service likely also handles file transfer operations — does it validate paths there?

---

CVE-2024-52940 — Public IP Disclosure

CVSS: 7.5 Affected: AnyDesk ≤ 8.1.0 Type: Information disclosure

When "Allow Direct Connections" is enabled, AnyDesk leaks the user's public IP address in network traffic. This is lower severity but useful for:

• Deanonymizing targets behind VPNs
• Targeting specific IP ranges for network attacks
• Combining with other vulns for targeted exploitation

---

CVE-2025-25065 — SSRF in RSS Feed Parser

Type: Server-Side Request Forgery Impact: Internal network access from AnyDesk relay infrastructure

The RSS feed parser in AnyDesk can be redirected to make requests to internal endpoints. This targets AnyDesk's infrastructure rather than end-user clients, but demonstrates that input validation is weak across the codebase.

---

CVE-2024-45516 — XSS in User Sessions

Type: Cross-site scripting Impact: Session injection

Limited details available, but demonstrates that AnyDesk's web-facing components have injection vulnerabilities.

---

The February 2024 Breach — What Was Stolen

Timeline:

• December 2023: Attackers gain access to AnyDesk production systems
• Mid-January 2024: AnyDesk detects breach during security audit
• February 2, 2024: Public disclosure

What was compromised:

1. Source code — Complete AnyDesk source code including DeskRT codec
2. Code signing private keys — Used to sign AnyDesk.exe distributed to all customers
3. Production system access — Full access to build/distribution infrastructure

Impact:

• Over 500 samples of Agent Tesla malware signed with the stolen AnyDesk certificate were found on VirusTotal (dating back to June 2022 — the breach may have started earlier)
• AnyDesk revoked the old certificate and issued new one in version 8.0.8
• All customer passwords were force-reset

Why this matters for vulnerability research:

• The source code is in adversary hands — state actors likely have it
• If you can obtain or reconstruct the protocol through RE, you can build a fake AnyDesk endpoint
• The code signing key theft means signed malware could masquerade as legitimate AnyDesk
• The DeskRT codec source would make fuzzing trivial — but even without it, black-box fuzzing of the binary codec is viable

---

Unexplored Attack Surfaces (Original Research Targets)

1. File Transfer Path Traversal — HIGHEST PROBABILITY

Why this is almost certainly vulnerable:

• RDP file transfer has had path traversal FIVE times (2019, 2020, 2025 x3)
• CVE-2024-12754 proves AnyDesk has path validation issues
• File transfer is a common, complex feature that handles user-controlled filenames
• AnyDesk supports both file manager transfers AND drag-and-drop — two code paths to test

Attack scenario:

1. Victim connects to attacker's AnyDesk instance (or attacker connects to victim and has file transfer permission)
2. Attacker initiates file transfer with filename: ..\..\..\..\Users\<victim>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\payload.bat
3. If AnyDesk's receiving side doesn't validate the filename, the file lands in the Startup folder
4. Next login → payload executes → RCE

Testing approach:

1. Set up two AnyDesk instances on separate VMs
2. Capture file transfer traffic with Wireshark (TCP port 6568)
3. Identify the protocol message that carries filenames
4. Use a TCP proxy to modify the filename in transit (add ../ sequences)
5. Test both the file manager and drag-and-drop transfer paths
6. Test with: backslashes, forward slashes, Unicode path separators, null bytes, double encoding
7. Monitor the receiving side's filesystem to see where the file lands

Alternative approach (faster):

1. Attach x64dbg to receiving AnyDesk instance
2. Set breakpoints on CreateFileW, WriteFile, MoveFileW
3. Initiate a normal file transfer
4. Trace the call stack to find where filenames are processed
5. Look for validation (or lack thereof) in the filename handling code
6. If no validation exists → path traversal confirmed

---

2. DeskRT Codec — RCE via Malformed Frames

What DeskRT is:

• Proprietary video codec designed for screen content (not natural video)
• Optimized for text, UI elements, low-latency (<16ms)
• Up to 60 FPS
• Handles keyframes and delta frames
• Tile/block-based decomposition
• Color space conversion

Why it's vulnerable:

• Fully proprietary — zero public security audits
• Complex binary format with decompression algorithms
• Header fields control memory allocation sizes (width, height, stride, tile count, compressed size)
• Same bug class as CVE-2025-29966 (RDP bitmap heap overflow): malicious server sends crafted frame → client allocates undersized buffer → heap overflow
• DeskRT is highly optimized for performance — optimization routinely sacrifices bounds checking

Attack scenario:

1. Build a fake AnyDesk endpoint (or modify traffic via TCP proxy)
2. Send DeskRT frames with manipulated header fields:
   • Width/height that cause integer overflow in width * height * bytes_per_pixel
   • Compressed size field that doesn't match actual data
   • Tile count that exceeds allocated array
   • Delta frame referencing non-existent keyframe regions
3. Client's DeskRT decoder processes the malformed frame
4. Integer overflow → small allocation, large copy → heap overflow
5. Heap overflow → arbitrary code execution

Research approach:

1. Capture legitimate DeskRT frames between two AnyDesk instances
2. Identify frame header format: magic bytes, version, width, height, tile info, compression type
3. RE the decoder functions in AnyDesk.exe (search for decompression loops, alloc patterns)
4. Build a Python proxy that modifies DeskRT frames in transit
5. Systematic fuzzing: mutate each header field while monitoring for crashes
6. Use PageHeap + GFlags for enhanced heap corruption detection

---

3. Clipboard Injection

Attack surface:

• AnyDesk syncs clipboard bidirectionally
• Clipboard can carry: text, rich text, images, files
• File clipboard operations use descriptors with filenames (similar to RDP's FileGroupDescriptorW)
• Image clipboard data requires format-specific decoding

Path traversal via clipboard file paste:

1. Copy a file on the attacker side
2. AnyDesk sends clipboard sync message to victim
3. If the file descriptor carries an unsanitized filename → path traversal on paste
4. Same attack as CVE-2019-0887 but in AnyDesk instead of RDP

Image clipboard overflow:

1. Copy a crafted image to clipboard on attacker side
2. AnyDesk sends bitmap/image data to victim
3. If width/height/bpp fields are server-controlled and not validated → heap overflow on decode

---

4. Auto-Update MITM

The 2024 breach context:

• AnyDesk's code signing keys were stolen
• They issued new certificates, but the UPDATE MECHANISM itself may be weak

Research questions:

1. Does AnyDesk use certificate pinning for update checks?
2. What URL does it check? Is it HTTPS-only or does it fall back to HTTP?
3. Is the update binary signature-verified before execution?
4. Can a DNS hijack + self-signed cert serve a malicious update?
5. Does the update run as SYSTEM (since AnyDesk service runs as SYSTEM)?

If no cert pinning:

• MITM the update check → serve malicious AnyDesk.exe
• If signed with the stolen (now-revoked) cert, older clients may still accept it
• Update runs as SYSTEM → instant SYSTEM-level code execution

---

5. Protocol Framing Attacks

AnyDesk's custom protocol:

• Not RDP — entirely proprietary
• TLS 1.2 with RSA 2048 key exchange
• AES-256 for session encryption
• TCP primary (port 6568 direct, 80/443 via relay)
• Message types for: video, audio, file transfer, clipboard, control, input

Fuzzing approach:

1. Capture raw TCP traffic (pre-TLS if possible, or instrument AnyDesk to log plaintext)
2. Identify TLV or length-prefixed framing structure
3. Map all message type IDs
4. Build a protocol-aware fuzzer that mutates:
   • Message type field (send unexpected types)
   • Length fields (undersized, oversized, zero, 0xFFFFFFFF)
   • Out-of-order messages (data before handshake)
   • Compressed message bodies with bad decompression params

---

AnyDesk as a "Malicious Server" (Equivalent to Rogue RDP)

Can you RAT someone connecting to your AnyDesk?

Short answer: Yes, but differently from RDP.

AnyDesk permissions model: When someone connects to your AnyDesk instance, YOU control what they can do. But when YOU connect to someone else, they can grant you permissions. The attack vectors depend on the direction:

Scenario A: Victim connects to attacker's AnyDesk

• Attacker has full control of what the victim sees (screen content)
• If file transfer is enabled: attacker can SEND files to victim with potentially traversal paths
• If clipboard sync is enabled: attacker can inject clipboard content
• The DeskRT video stream to the victim is fully attacker-controlled → codec exploitation

Scenario B: Attacker connects to victim (with permissions)

• If victim grants file transfer: attacker can upload files to victim with path traversal
• If victim grants clipboard: attacker can inject clipboard content
• This is less interesting because it requires victim to grant permissions

The most interesting scenario is A — victim connecting to attacker, because:

• The attacker controls the DeskRT stream (codec exploitation)
• The attacker controls clipboard responses
• The attacker controls file transfer responses
• This mirrors the "rogue RDP server" attack model

---

Priority Research Roadmap

#	Target	Bug Class	Difficulty	Probability	Impact
1	File transfer path traversal	Path traversal	Low-Medium	Very High	Arbitrary file write → RCE
2	DeskRT codec fuzzing	Heap overflow / integer overflow	Medium-High	High	RCE (client-side)
3	Clipboard file paste traversal	Path traversal	Medium	High	Arbitrary file write → RCE
4	Clipboard image overflow	Heap overflow	Medium	Medium-High	RCE
5	Auto-update MITM	Signature bypass	Low-Medium	Medium	RCE as SYSTEM
6	Protocol framing	Various	Medium	Medium	Crash → potential RCE
7	SYSTEM service file ops (CVE-2024-12754 variants)	Symlink/junction	Low	High	Local privesc to SYSTEM

---

Tools Needed

Tool	Purpose
Two Windows VMs	Testing AnyDesk connections
Wireshark	Protocol capture on port 6568
mitmproxy or custom TCP proxy	Modify AnyDesk traffic in transit
IDA Pro / Ghidra	RE AnyDesk.exe (DeskRT decoder, file transfer handler)
x64dbg	Dynamic analysis, breakpoints on file/memory operations
WinAFL or libFuzzer	Coverage-guided fuzzing of DeskRT decoder
Python	Custom protocol replay / fake AnyDesk endpoint
GFlags / PageHeap	Enhanced heap corruption detection
Process Monitor	File system monitoring during file transfer

---

References

• CVE-2024-12754 PoC — AnyDesk Privilege Escalation
• CVE-2024-12754 Detailed Analysis
• AnyDesk February 2024 Breach — Akamai Analysis
• Huntress: AnyDesk Stolen Code Signing Certificate
• AnyDesk Breach — Cybereason Aftermath Analysis
• TechCrunch: AnyDesk Password Reset and Cert Revocation
• Synacktiv: Forensic Analysis of Remote Access Tools
• AnyDesk CVE List (CVEDetails)
• CVE-2024-52940: AnyDesk IP Exposure