Forensic Analysis of AnyDesk Logs

Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer. 

There are two locations for where AnyDesk logs are stored on the Windows file system:

  • %programdata%\AnyDesk\ad_svc.trace
  • %appdata%\Anydesk\ad.trace
The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed.

Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log:
  • Remote IP where the actor connected from
  • File transfer activity

Locating the Remote IP Connecting to AnyDesk

Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake:

info 2021-02-04 23:25:10.500       lsvc   9988   6992    3                anynet.relay_conn - External address: 116.255.x.x:47220.

Locating File Transfer Activity

Similarly, inside the "ad.trace" logs under each users' %appdata% folder you should be grepping for the terms "files" and "app.prepare_task". This will reveal to you, from which folder the files are being copied from and also the number of files copied. In the screenshot below, 1 file was copied from the host to the remote host and it shows you the directory it was taken from:

anydesk log analysis


Comments

  1. merzhin13 September 2021 at 05:55

    Hello, while looking for analysis elements on AnyDesk I found your post and according to my own tests, the IP located at the line "External address" is in fact the IP of the target computer and not of the remote computer.
    It seems to me that the IP of the remote computer is on the "Logged in from" line.
    Regards

    ReplyDelete
  2. Unknown29 September 2021 at 23:33

    The ip address we get is not the remote ip address, it is the ip address of the system from which logs are analysed.The "logged in from" line also is not able to provide remote external ip address. It just give internal ip address of remote system that was accessed

    ReplyDelete
  3. Anonymous21 October 2021 at 04:41

    Hi, Thanks for this post!

    The files you mentioned are deleted on my device (maybe they uninstalled it), but...

    I also found that "connection_trace.txt" exists in "Appdata\Roaming\AnyDesk\". There I found something like:

    Incoming YYY-MM-DD, HH:mm [Username] and a number with 9 characters.

    I guess the number is a connection number associated with the AnyDesk connection number at that moment.

    Maybe you can check if you have something simmilar and write something about it ;)

    Greetings!

    ReplyDelete
  4. yc16 November 2021 at 17:17

    Hello, thanks for the pc analysis. Can I know the contents of mobile forensics?

    ReplyDelete

Post a Comment

Popular posts from this blog

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more