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. Send Big2 June 2021 at 20:39

    Wow! Thank you! I constantly wanted to write on my site something like that. Can I take a portion of your post to my website? best Send large files free service provider.

    ReplyDelete
  2. 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

Post a Comment

Popular posts from this blog

Office365 Attacks: Bypassing MFA, Achieving Persistence and More

Image
APTs are actively attacking Office 365 (O365) – finding mechanisms to bypass MFA and to impersonate users regardless of whether you reset their passwords. When I was looking through the Mitre mapping of O365 attacks , I noticed that it didn’t include many methods of intrusion and actions on objectives that can occur with O365. In conversations with several clients, I couldn’t help but notice that there’s still a heavy focus on “endpoint” style attacks and not much resource / thought put into attacks that can occur in the cloud. Attacking O365 gives an attacker many benefits… it allows an attacker to impersonate users, alter MFA settings, register malicious devices, access Teams messages, download sensitive emails, access SharePoint, OneDrive, register malicious applications and various other actions that could allow them to maintain persistence in your environment. This blog post explores the various ways O365 can be attacked. I will be writing a Part II follow up that describes the me
Read more

Backdoor Office 365 and Active Directory - Golden SAML

Image
Backdoors can bypass all MFA requirements put in place by an organisation. Earlier this year, I worked an engagement with an APT group that had a keen interest on the client’s Office 365 environment, where this group found a way to bypass authentication controls to access the environment. Given that most clients either have a hybrid authentication model set-up or are fully in the cloud – I think it’s important that most blue teams / defenders / hunters are aware of the various techniques threat actors are using against Azure AD. Compromise of the AD FS server token-signing certificate could result in access to the Azure/Office365 environment by the attacker. By default, this certificate is valid for a year and will allow an attacker to log into Azure/Office365 as any user within AD regardless of any password resets and MFA. The implication of this, is that the attacker maintains persistence and has a means to re-enter into the environment, escaping detection. This blog post will cover
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