AnyDesk forensics in a ransomware incident: preserve evidence, build a timeline and protect encrypted data

1. How can AnyDesk relate to encrypted data?

An attacker may compromise VPN/RDP accounts, then use AnyDesk to control the GUI, download tools, move files and execute malware. CISA documented LockBit affiliates using AnyDesk; a 2026 Huntress investigation described an Akira case in which an AnyDesk session delivered the encryptor. This does not make AnyDesk an encryptor or prove that every machine running it has suffered ransomware. [S1][S2]

Business impact can extend from workstations to SQL Server (MDF/LDF), NAS, shared folders, VM/ESXi and backup repositories. Assessing recovery prospects requires separating the entry point, encryption activity, storage condition and backup state.

2. The first 15 minutes: preserve the incident scene

1. Scope the incident: identify systems being encrypted, accessed NAS/shares, unaffected machines and any active suspicious remote session.
2. Isolate with an impact assessment: stop unsafe access through the response process. Assess iSCSI, clusters, SAN, SQL Always On and hypervisor dependencies first to avoid additional data loss or split-brain.
3. Record timing: system clock, time zone, screen, ransom note, file extension and discovery time. Preserve sample hashes on copies; do not infer the ransomware family from an extension alone.
4. Preserve originals: do not overwrite data, run chkdsk /f, modify BCD, format, or create arbitrary snapshots on a damaged datastore. Prioritize imaging or cloning under the forensic policy.
5. Control emergency access: disable malicious sessions and change credentials from a clean machine under the IR plan. Avoid signing in with administrator credentials on a device still suspected of attacker control.

If an attack is continuing, preventing further harm takes priority over perfect evidence collection. Decisions may need to balance both objectives.

Preserve evidence before recovery

01Isolate appropriately

02Collect logs & services

03Build the timeline

04Validate recovery

Workflow illustration · TEKLab by TUNGTEK

3. Six important evidence groups

Vendor-documented locations for a standard AnyDesk client:

%APPDATA%\AnyDesk\ad.trace
%PROGRAMDATA%\AnyDesk\ad_svc.trace
%APPDATA%\AnyDesk\connection_trace.txt

connection_trace.txt is in the client's configuration files directory. Its location can vary by version and installation. Custom EXE/MSI clients commonly use ad_<prefix> or ad_<prefix>_msi subdirectories. Check all relevant user profiles, not only the signed-in user's %APPDATA%. [S3]

4. A quick read-only PowerShell survey

The script below does not uninstall software, delete Registry entries or initiate network connections. Use appropriate permissions. If saving output, use an approved evidence destination and record when and where it ran.

# TUNGTEK TEKLink215 | AnyDesk Forensic Quick Check
# READ-ONLY: inventory, khong sua registry/dich vu/file
$since = (Get-Date).AddDays(-30)

Write-Host '=== AnyDesk Services ==='
Get-CimInstance Win32_Service |
  Where-Object { $_.Name -match 'AnyDesk' -or $_.PathName -match 'AnyDesk' } |
  Select-Object Name, State, StartMode, PathName | Format-List

Write-Host '=== AnyDesk Processes ==='
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match 'AnyDesk' -or $_.ExecutablePath -match 'AnyDesk' } |
  Select-Object ProcessId, Name, ExecutablePath, CommandLine | Format-List

Write-Host '=== Service Creation (Event ID 7045) ==='
Get-WinEvent -FilterHashtable @{
  LogName='System'; Id=7045; StartTime=$since
} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'AnyDesk' } |
  Select-Object TimeCreated, Message | Format-List

Write-Host '=== Standard Trace Paths ==='
$roots = @("$env:ProgramData\AnyDesk")
$roots += Get-ChildItem "$env:SystemDrive\Users" -Directory -ErrorAction SilentlyContinue |
  ForEach-Object { Join-Path $_.FullName 'AppData\Roaming\AnyDesk' }
Get-ChildItem -Path $roots -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -match '^(connection_trace\.txt|ad.*\.trace)

**No results does not mean safe.** Familiar name/path searches miss renamed binaries, deleted portable clients and artifacts on other volumes. Creation and modification timestamps may also have been altered; treat them as leads for independent verification.

## 5. Build a timeline beyond AnyDesk logs

Start with the first renamed or encrypted file and work backwards through **VPN → Windows login/RDP → service creation → AnyDesk session → file transfer → tool execution → protection changes → encryption / exfiltration**. Normalize timestamps to UTC and retain local times in the report.

In the Akira case Huntress published on 4 August 2026, AnyDesk provided control and file transfer; `akira.exe` appeared about 27 seconds after the transfer event. This is **that case's timeline**, not a universal ransomware indicator. [S2]

Where Safe Mode is suspected, review System/Kernel-Boot, `SafeBoot\Network` Registry changes and service stop/start logs. **Safe Mode alone does not establish malicious activity**; administrators also use it for legitimate repairs.

## 6. Special considerations for SQL Server, NAS and VMware ESXi

### MDF/LDF databases

Establish SQL service and database state, MDF/LDF locations, snapshots/storage, SQL backups (.bak and log backups), and unusual access logs. Do not attach, detach or repair original databases simply to test them. For `.piz` files, preserve a hashed sample and assess headers/trailers, entropy and readable backups; **do not infer the ransomware family from `.PIZ` alone**.

### NAS/SMB

Capture NAS configuration, volume/RAID state, SMB audit logs where available, accounts and permissions, snapshots and backups. Share mapping or permission changes may stop an attack but also affect services; record those decisions in the timeline.

### ESXi / VM

Distinguish **actual VMDK encryption** from datastore faults, missing descriptors, snapshot-chain issues and VM boot configuration. Preserve vmware.log, VMDK/flat/delta structure, host timestamps, vCenter events and original images. Prefer read-only work; do not consolidate or delete snapshots before understanding the chain.

## 7. When can AnyDesk use be attributed to an attacker?

Use **correlated evidence**: installation outside the IT schedule, a remote ID outside the allowlist, sessions matching suspicious activity, processes started through the session, compromised accounts, data movement or malware execution. Reports should distinguish **confirmed**, **supported suspicion** and **insufficient evidence**.

For a customer's `.PIZ` incident, do not publish personal details, original filenames, IP addresses/AnyDesk IDs, sample hashes or infrastructure diagrams without authorization. Do not claim recovery success rates from file extensions or a single sample.

## 8. Recovery after investigation

1. Work on **verifiable copies** and keep originals unchanged.
2. Assess encryption type, file size and structure, encrypted regions, metadata and partial extraction opportunities.
3. Search for clean SQL backups, VSS, NAS snapshots, application-aware backups and offsite/immutable copies.
4. Test recovery in isolation and validate at application level: SQL `DBCC CHECKDB` on a copy, business samples and test VM startup.
5. Resolve the entry point and persistence, rotate credentials and improve monitoring before returning the environment to service.

## TEKLab's conclusion

**AnyDesk's presence is a forensic lead, not a verdict.** Timely examination, relevant artifacts, original-data preservation and a defensible sequence of activity support safe incident response and **encrypted-data extraction** decisions.

**CuuDuLieuMaHoa.com by TUNGTEK — 0963 509 115**  
🇻🇳 **Data incident? Call TUNGTEK.**

## Sources

- **[S1] CISA — LockBit AA23-165A:** https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a
- **[S2] Huntress — Akira and Safe Mode:** https://www.huntress.com/blog/akira-hits-safe-mode-ransomware-rebooting-around-edr
- **[S3] AnyDesk — Trace Files:** https://support.anydesk.com/what-are-trace-files
- **[S4] MITRE ATT&CK T1219.002:** https://attack.mitre.org/techniques/T1219/002/

*Technical guidance for defense and incident response. It does not replace forensic assessment of original devices. Illustrations and example IDs/paths are not customer information.*

### Scan the QR for #TEKLink215

![TEKLink215 footer QR](assets/qr-footer-teklink215.png)
 } |
  Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtc |
  Format-Table -AutoSize

No results does not mean safe. Familiar name/path searches miss renamed binaries, deleted portable clients and artifacts on other volumes. Creation and modification timestamps may also have been altered; treat them as leads for independent verification.

5. Build a timeline beyond AnyDesk logs

Start with the first renamed or encrypted file and work backwards through VPN → Windows login/RDP → service creation → AnyDesk session → file transfer → tool execution → protection changes → encryption / exfiltration. Normalize timestamps to UTC and retain local times in the report.

In the Akira case Huntress published on 4 August 2026, AnyDesk provided control and file transfer; akira.exe appeared about 27 seconds after the transfer event. This is that case's timeline, not a universal ransomware indicator. [S2]

Where Safe Mode is suspected, review System/Kernel-Boot, SafeBoot\Network Registry changes and service stop/start logs. Safe Mode alone does not establish malicious activity; administrators also use it for legitimate repairs.

6. Special considerations for SQL Server, NAS and VMware ESXi

MDF/LDF databases

Establish SQL service and database state, MDF/LDF locations, snapshots/storage, SQL backups (.bak and log backups), and unusual access logs. Do not attach, detach or repair original databases simply to test them. For .piz files, preserve a hashed sample and assess headers/trailers, entropy and readable backups; do not infer the ransomware family from .PIZ alone.

NAS/SMB

Capture NAS configuration, volume/RAID state, SMB audit logs where available, accounts and permissions, snapshots and backups. Share mapping or permission changes may stop an attack but also affect services; record those decisions in the timeline.

ESXi / VM

Distinguish actual VMDK encryption from datastore faults, missing descriptors, snapshot-chain issues and VM boot configuration. Preserve vmware.log, VMDK/flat/delta structure, host timestamps, vCenter events and original images. Prefer read-only work; do not consolidate or delete snapshots before understanding the chain.

7. When can AnyDesk use be attributed to an attacker?

Use correlated evidence: installation outside the IT schedule, a remote ID outside the allowlist, sessions matching suspicious activity, processes started through the session, compromised accounts, data movement or malware execution. Reports should distinguish confirmed, supported suspicion and insufficient evidence.

For a customer's .PIZ incident, do not publish personal details, original filenames, IP addresses/AnyDesk IDs, sample hashes or infrastructure diagrams without authorization. Do not claim recovery success rates from file extensions or a single sample.

8. Recovery after investigation

1. Work on verifiable copies and keep originals unchanged.
2. Assess encryption type, file size and structure, encrypted regions, metadata and partial extraction opportunities.
3. Search for clean SQL backups, VSS, NAS snapshots, application-aware backups and offsite/immutable copies.
4. Test recovery in isolation and validate at application level: SQL DBCC CHECKDB on a copy, business samples and test VM startup.
5. Resolve the entry point and persistence, rotate credentials and improve monitoring before returning the environment to service.

TEKLab's conclusion

AnyDesk's presence is a forensic lead, not a verdict. Timely examination, relevant artifacts, original-data preservation and a defensible sequence of activity support safe incident response and encrypted-data extraction decisions.

CuuDuLieuMaHoa.com by TUNGTEK — 0963 509 115
🇻🇳 Data incident? Call TUNGTEK.

Sources

• [S1] CISA — LockBit AA23-165A:https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a
• [S2] Huntress — Akira and Safe Mode:https://www.huntress.com/blog/akira-hits-safe-mode-ransomware-rebooting-around-edr
• [S3] AnyDesk — Trace Files:https://support.anydesk.com/what-are-trace-files
• [S4] MITRE ATT&CK T1219.002:https://attack.mitre.org/techniques/T1219/002/

Technical guidance for defense and incident response. It does not replace forensic assessment of original devices. Illustrations and example IDs/paths are not customer information.