Forensic Analysis of Windows Ransomware Attacks by Team Viewer with DeepBlueCLI



Hello everyone! In the last months I have the feeling that I just keep talking about cases and oddities related to the forensic analysis that we execute https://www.zerolynx.com/at Zerolynx, but unfortunately cyberattacks do not stop increasing, so we have to be prepared and updated regarding the modus operandi of cybercrime.

For about three or four years now we have had many practically identical cases related to ransomware. Victims and environments vary, ransomwares used vary, and attacker kits vary, but at its core, the attack chain is usually maintained, and the most common input vector we're seeing is still Team Viewer. Sometimes criminals manage to delete the logs, in other cases they stay halfway, in others, they do not even try, but in one way or another we always end up finding evidence that proves that Team Viewer has been the most possible way of entry. Therefore, today I wanted to dedicate this post to show you how to easily identify such behaviour in an attacked device, and what would be some of the first evidence that we could collect.

To illustrate the attack drill, I've prepared 2 Windows 11 test environments on VirtualBox, and installed Team Viewer on both. Default Settings. I give internet access to the machines and... let's go!



Now, and assuming that the attacker has obtained the ID and login credential (this topic can be addressed in another post), I authenticate:



And at this point I've done some “evil” things from the attacking machine, simulating the behaviour of a criminal.

At this stage, our forensics would begin, and we will assume that we have followed the correct procedure, adhering to the proper chain of custody, cloning the disk bit by bit (for example, with dd), and that we have processed it with some forensic tool like Autopsy. In the archive of Flu Project, you will find multiple posts where I talk about it at length :). And by the way, you have Forensic articles since 2011. In fact, the other day, while looking for a command, I came across with a compilation of 43 posts I made in 2013. But you have 50 more articles with newer techniques, tools and procedures.

Returning to our subject today, for this case I will use a SANS tool, DeepBlueCLI, which Pablo showed me a long time ago, and of which he already told you about in El Lado del Mal.

It is very easy to use: first you extract the Windows event logs, and then you introduce them as a parameter:
  • .\DeepBlue.ps1 .\Forensics\eventsExtracted\security.evtx
You can do it on the logs of your Windows system without introducing any parameters:


As you can see, DeepBlue shows us that someone has recently created a user named "attacker” and has given this user administrator permissions. We take this data and go to the Windows event viewer to look for a "4720" event. And....here we are! we will easily find that someone has created the aforementioned user:



If we review the above events, we should find at some point the logon, event "4624":



As you can see, authentication occurs at 19:28 P.M. Now, if we refer to the Team Viewer event log, we will see that there was indeed a session that began at that time (the time is not well synchronized and you will see a gap of 2 hours), and that ended 3 minutes later:




In this type of attacks, it is common to find ID 4672 (special privileges assigned to the new login). Here is the detail of the Microsoft FAQ:

You may also find some traces related to the blockinb by the antivirus. You can see this with 7031 or 7000, that is, with the IDs that indicate that a service has been blocked and it has been prevented from starting:

We come up with this situation very frequently and clients always rise their eyebrows and go like: BUT I DID HAVE ANTIVIRUS! ARE YOUR KIDDING?! Well, sweetheart, if the attacker managed to become an administrator... your antivirus can't stop it. So there is nothing much that can be done than to avoid using users with privileged permissions.

And finally, and to conclude with the post, you may also find it useful to look for 11707 identifier which reflects that an application has been installed on the attacked machine. In all likelihood, a port scan or similar will have been executed. You can find it by the end of the table presented on the following Microsoft page:

Kino's blog may also be useful for this type of cases, since from time to time he dedicates post to topics related to the audit of Windows events. For example, this one where he explains how to monitor changes in the log may be useful. It is likely probable that the attacker uses a kit executed from powershell, and has to modify something in the log, such as execution directives.


This article provides you with some basic concepts to quickly investigate an incident of this kind. There are better attackers who delete logs and make things more difficult for us, and others who are blinded by success and leave more traces than they would like, but one way or another we always end up getting the information we need to prove the attack. Identifying the attacker is another story... IP addresses from China is what we're finding more recently, but I'm sure this doesn't come as a surprise to you :).

See you on the next post!