How ransomware abuses AnyDesk: evidence from LockBit and Akira
CISA documents AnyDesk use by LockBit affiliates; Huntress details an Akira case with VPN, data theft, AnyDesk and Safe Mode. Evidence, forensic artifacts and response.
Updated: · Vietnam time (UTC+7)

Cross-checked against the CISA/FBI advisory, Huntress case, AnyDesk documentation and Sophos report. These sources support tool-abuse analysis, not a claim that AnyDesk appeared in a particular TUNGTEK .PIZ case.
[S1]–[S8] match the source list below. The cover and three diagrams are editorial illustrations, neither app screenshots nor incident evidence. The QR points to https://link.tungtek.com/215.
1. AnyDesk is legitimate: establish who controlled what and when
AnyDesk is legitimate remote support software. MITRE ATT&CK T1219.002 describes adversaries abusing remote desktop tools for control. The app's presence alone does not establish compromise. Put a session beside approved support tickets, operator identity, source device, time window and corroborating artifacts. [S1]
Distinguish authorized IT support, installation after VPN/RDP compromise, and social engineering that persuades a user to approve control. In the second scenario, AnyDesk is a post-access tool, not automatically a vulnerability or initial-access route.
2. LockBit: an advisory tool listing is not every intrusion path
Joint advisory AA23-165A, dated 14 June 2023, lists AnyDesk among tools used by LockBit affiliates to control victim devices. Its ATT&CK table groups it with Atera RMM, ScreenConnect and TeamViewer under T1219 for command and control. This documents observed use, not a claim that every LockBit intrusion used AnyDesk. [S2]
LockBit affiliates differ in tactics. An AnyDesk installation alone cannot identify LockBit or establish initial access. A case needs a chain of identity, infrastructure, process, file and impact evidence.
![Figure 1 — LockBit: advisory tool listing. Akira: a specific investigated sequence. Editorial diagram based on [S2] and [S3], not incident evidence.](/images/editorial/anydesk-teklink215/comparison-en.webp)
3. Akira: the sequence in one 4 August 2026 case
Huntress reports failed SonicWall SSL VPN logins from about 03:45 UTC on 4 August 2026, then a successful login at 03:52:42 UTC using a valid account on a VPN without MFA. Nearly two hours later the operator used RDP to access a domain controller, enumerated Active Directory, archived shares with WinRAR and uploaded staged data to an attacker-controlled S3 bucket with s5cmd. This exfiltration came before the encryption attempt. [S3]
The actor installed AnyDesk as an auto-start Windows service and established an inbound session. Huntress observed an inbound file transfer and four clipboard text blocks. The akira.exe process tree started about 27 seconds after the transfer finished. That interval belongs to this case; AnyDesk transfer was not the only data movement. [S3]
![Figure 2 — Sequence in the Huntress Akira case. The 27-second interval is specific to that incident. [S3]](/images/editorial/anydesk-teklink215/timeline-en.webp)
4. Safe Mode impaired defenses but broke the observed encryption
Huntress observed a Safe Mode with Networking reboot and a configuration change that allowed AnyDesk service to run there. The third-party protection agent did not start, while Windows Defender logged an error because its service could not run in Safe Mode. MITRE describes this pattern as T1688. It is a specific case observation, not a property of every AnyDesk deployment or Akira incident. [S3][S6]
On the investigated host, akira.exe ran out of virtual memory and encryption failed. Credentials and file-share data had already been taken. No encrypted files narrows the observed impact, but does not rule out exfiltration, account compromise or activity on other hosts. [S3]
5. Sophos 2026: keep the denominator attached to the claim
Sophos reviewed 661 sufficiently documented IR/MDR cases from 1 November 2024 through 31 October 2025. Within that case set, it describes AnyDesk as the most abused legitimate remote access tool. This is a ranking in Sophos's investigated population, not a global rate for organizations or ransomware incidents. [S4]
The finding supports inventorying approved remote tools, monitoring new service installations and reviewing sessions outside support windows. Each organization's baseline still matters: a team using AnyDesk daily will have different legitimate activity from one that prohibits it.

6. Correlate AnyDesk traces with identity and endpoint evidence
AnyDesk documents connection_trace.txt on the receiving device as recording request time, acceptance or rejection and requester. Standard Windows clients may write ad.trace under %appdata%\AnyDesk; installed services may write ad_svc.trace under %programdata%\AnyDesk. Custom clients use prefix-specific paths. Preserve originals and hashes, and note clock and time zone before correlation. [S5]
Compare traces with VPN/MFA, RDP and sign-in logs, new service records, process trees, EDR data, archive/upload activity and SafeBoot changes. Windows Security Event 4697 may record service installation when appropriate auditing is enabled; its absence does not prove no service was installed. Prefetch, Amcache, Registry, EVTX, $MFT and $UsnJrnl can help depending on acquisition and retention. [S3][S8]
A remote ID, trace or file extension is a lead, not final attribution. Establish which session matched an IT change, which account opened access, what moved, what ran next and whether data left the network.
7. Detect the sequence, not merely the app name
- Inventory approved remote tools, operators and support windows; flag service installation outside authorized changes.
- Correlate unusual or non-MFA VPN access with RDP to a sensitive host, then an AnyDesk service or unexpected inbound session. [S3]
- Put transfers and clipboard activity, WinRAR or upload tools, SafeBoot changes, protection outages and payload processes on one timeline. [S3][S6]
- Reduce false positives through ticket, technician, device management and Remote ID context; raise priority when independent layers agree.
- Retain VPN, firewall and endpoint logs and synchronize clocks; missing or skewed timestamps can reverse the apparent order.
8. Suspected unauthorized session: preserve, contain, recover
Follow an incident response plan: scope affected hosts, isolate suspected control and revoke abused sessions or accounts under proper authority. Consider volatile evidence before shutdown; record times, handlers and chain of custody. Immediately uninstalling AnyDesk or deleting logs may remove useful evidence. [S7]
Collect traces, service configuration, EVTX, EDR/network telemetry, file samples and exfiltration records, and look for other remote or persistence channels. Rotate credentials from clean devices, review MFA and privileges, validate segregated or immutable backups, then restore in stages. If data was taken, address information exposure and applicable notification duties as well as availability. [S3][S7]
9. .PIZ attribution limit and #TEKLink215
No verified public evidence establishes AnyDesk use in a particular TUNGTEK .PIZ case. The .PIZ extension is not a unique ransomware-family identifier. This article analyzes third-party published TTPs; it does not claim a live endpoint test or firsthand acquisition.
See this article and related updates at https://link.tungtek.com/215. 🇻🇳 Data incident? Call TUNGTEK.
Sources
Each source's scope and date are recorded separately when available. A citation does not independently verify every assessment.
Update history
· Published sourced AnyDesk abuse analysis with explicit .PIZ attribution limits.
· Expanded primary-source LockBit/Akira analysis and corrected the Huntress case sequence; replaced cover with the original transparent TungTEK signature and added three VI/EN diagrams.
· Enlarged the QR in 480/768 images for narrow screens; verified all six exported variants with OpenCV.
Corrections policy