National Cyber Warfare Foundation (NCWF)

Learn how AnyDesk forensic artifacts can help you uncover remote connections, attacker identities, and signs of data theft

The post Digital Forensics: AnyDesk – Favorite Tool of APTs first appeared on Hackers Arise.

Welcome back, aspiring digital forensics investigators!

AnyDesk first appeared around 2014 and very quickly became one of the most popular tools for legitimate remote support and system administration across the world. It is lightweight, fast, easy to deploy. Unfortunately, those same qualities also made it extremely attractive to cybercriminals and advanced persistent threat groups. Over the last several years, AnyDesk has become one of the preferred tools used by attackers to maintain persistent access to compromised systems.

Attackers abuse AnyDesk in a few different ways. Sometimes they install it directly and configure a password for unattended access. Other times, they rely on the fact that many organizations already have AnyDesk installed legitimately. All the attacker needs to do is gain access to the endpoint, change the AnyDesk password or configure a new access profile, and they now have quiet, persistent access. Because remote access tools are so commonly used by administrators, this kind of persistence often goes unnoticed for days, weeks, or even months. During that time the attacker can come and go as they please. Many organizations do not monitor this activity closely, even when they have mature security monitoring in place. We have seen companies with large infrastructures and centralized logging completely ignore AnyDesk connections. This has allowed attackers to maintain footholds across geographically distributed networks until they were ready to launch ransomware operations. When the encryption finally hits critical assets and the cryptography is strong, the damage is often permanent, unless you have the key.

We also see attackers modifying registry settings so that the accessibility button at the Windows login screen opens a command prompt with the highest privileges. This allows them to trigger privileged shells tied in with their AnyDesk session while minimizing local event log traces of normal login activity. We demonstrated similar registry hijacking concepts previously in “PowerShell for Hackers – Basics.” If you want a sense of how widespread this abuse is, look at recent cyberwarfare reporting involving Russia.

Kaspersky has documented numerous incidents where AnyDesk was routinely used by hacktivists and financially motivated groups during post-compromise operations. In the ICS-CERT reporting for Q4 2024, for example, the “Crypt Ghouls” threat actor relied on tools like Mimikatz, PingCastle, Resocks, AnyDesk, and PsExec. In Q3 2024, the “BlackJack” group made heavy use of AnyDesk, Radmin, PuTTY and tunneling with ngrok to maintain persistence across Russian government, telecom, and industrial environments. And that’s just a glimpse of it.

Although AnyDesk is not the only remote access tool available, it stands out because of its polished graphical interface and ease of use. Many system administrators genuinely like it. That means you will regularly encounter it during investigations, whether it was installed for legitimate reasons or abused by an attacker.

With that in mind, let’s look at how to perform digital forensics on a workstation that has been compromised through AnyDesk.

Investigating AnyDesk Activity During an Incident

Today we are going to focus on the types of log files that can help you determine whether there has been unauthorized access through AnyDesk. These logs can reveal the attacker’s AnyDesk ID, their chosen display name, the operating system they used, and in some cases even their IP address. Interestingly, inexperienced attackers sometimes do not realize that AnyDesk transmits the local username as the connection name, which means their personal environment name may suddenly appear on the victim system. The logs can also help you understand whether there may have been file transfers or data exfiltration.

For many incident response cases, this level of insight is already extremely valuable. On top of that, collecting these logs and ingesting them into your SIEM can help you generate alerts on suspicious activity patterns such as unexpected night-time access. Hackers prefer to work when users are asleep, so after-hours access from a remote tool should always trigger your curiosity.

Here are the log files and full paths that you will need for this analysis:

C:\Users\%username%\AppData\Roaming\AnyDesk\ad.trace
C:\Users\%username%\AppData\Roaming\AnyDesk\connection_trace.txt
C:\ProgramData\AnyDesk\ad_svc.trace
C:\ProgramData\AnyDesk\connection_trace.txt

AnyDesk can be used in two distinct ways. The first is as a portable executable. In that case, the user runs the program directly without installing it. When used this way, the logs are stored under the user’s AppData directory. The second way is to install AnyDesk as a service. Once installed, it can be configured for unattended access, meaning the attacker can log in at any time using only a password, without the local user needing to confirm the session. When AnyDesk runs as a service, you should also examine the ProgramData directory as it will contain its own trace files. The AppData folder will still hold the ad.trace file, and together these files form the basis for your investigation.

With this background in place, let’s begin our analysis.

Connection Log Timestamps

The connection_trace.txt logs are relatively readable and give you a straightforward record of successful AnyDesk connections. Here is an example with a randomized AnyDesk ID:

Incoming 2025–07–25, 12:10 User 568936153 568936153

reading connection_trace.txt anydesk log file

The real AnyDesk ID has been redacted. What matters is that the log clearly shows there was a successful inbound connection on 2025–07–25 at 12:10 UTC from the AnyDesk ID listed at the end. This already confirms that remote access occurred, but we can dig deeper using the other logs.

Gathering Information About the Intruder

Now we move into the part of the investigation where we begin to understand who our attacker might be. Although names, IDs, and even operating systems can be changed by the attacker at any time, patterns still emerge. Most attackers do not constantly change their display name unless they are extremely paranoid. Even then, the timestamps do not lie. Remote logins occurring repeatedly in the middle of the night are usually a strong indicator of unauthorized access.

We will work primarily with the ad.trace and ad_svc.trace files. These logs can be noisy, as they include a lot of error messages unrelated to the successful session. A practical way to cut through the noise is to search for specific keywords. In PowerShell, that might look like this:

PS > get-content .\ad.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adtrace.log

PS > get-content .\ad_svc.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adsvc.log

These commands filter out only the most interesting lines and save them into new files called adtrace.log and adsvc.log, while still letting you see the results in the console. The tee command behaves this way both in Windows and Linux. This small step makes the following analysis more efficient.

IP Address

In many cases, the ad_svc.trace log contains the external IP address from which the attacker connected. You will often see it recorded as “Logged in from,” alongside the AnyDesk ID listed as “Accepting from.” For the sake of privacy, these values were redacted in the screenshot we worked from, but they can be viewed easily inside the adsvc.log file you created earlier.

anydesk ad_svc.trace log file contains the ip adress of the user accessing the machine via anydesk

Once you have the IP address, you can enrich it further inside your SIEM. Geolocation, ASN information, and historical lookups may help you understand whether the attacker used a VPN, a hosting provider, a compromised endpoint, or even their home ISP.

Name & OS Information

Inside ad.trace you will generally find the attacker’s display name in lines referring to “Incoming session request.” Right next to that field you will see the corresponding AnyDesk ID. You may also see references to the attacker’s operating system.

anydesk ad.trace log contains the name of the anydesk user and their anydesk id

In the example we examined, the attacker was connecting from a Linux machine and had set their display name to “IT Dep” in an attempt to appear legitimate. As you can imagine, users do not always question a remote session labeled as IT support, especially if the attacker acts confidently.

Data Exfiltration

AnyDesk does not only provide screen control. It also supports file transfer both ways. That means attackers can upload malware or exfiltrate sensitive company data directly through the session. In the ad.trace logs you will sometimes see references such as “Preparing files in …” which indicate file operations are occurring.

This line alone does not always tell you what exact files were transferred, especially if the attacker worked out of temporary directories. However, correlating those timestamps with standard Windows forensic artifacts, such as recent files, shellbags, jump lists, or server access logs, often reveals exactly what the attacker viewed or copied. If they accessed remote file servers during the session, those server logs combined with your AnyDesk timestamps can paint a very clear picture of what happened.

anydesk ad.trace log contains the evidence of data exfiltration

In our case, the attacker posing as the “IT Dep” accessed and exfiltrated files stored in the Documents folder of the manager who used that workstation.

Summary

Given how widespread AnyDesk is in both legitimate IT environments and malicious campaigns, you should always consider it a high-priority artifact in your digital forensics and incident response workflows. Make sure the relevant AnyDesk log files are consistently collected and ingested into your SIEM so that suspicious activity does not go unnoticed, especially outside business hours. Understanding how to interpret these logs shows the attacker’s behavior that otherwise feels invisible.

Our team strongly encourages you to remain aware of AnyDesk abuse patterns and to include them explicitly in your investigation playbooks. If you need any support building monitoring, tuning alerts, or analyzing remote access traces during an active case, we are always happy to help you strengthen your security posture.