Detecting BlackCat Ransomware credential dumping in Windows with Security Events Explorer

A couple days ago, Italian cyber security blogs have begun to spread the news that University of Pisa was hit by the BlackCat ransomware, also known as ALPHV. This piqued my interest, and searching on the web I discovered that Microsoft analyzed two security breaches and detailed how attackers were able to dump credentials to elevate privileges and move laterally. In this blog, we see how to build custom detection rules in Security Events Explorer able to detect BlackCat ransomware activity.

Introduction

BlackCat (aka AlphaVM or AlphaV) is a recent ransomware family, first observed in late 2021. The peculiarity of this ransomware is that it is written in Rust programming language. Many Threat Intelligence researchers believe that the choice of this language, uncommon for ransomwares at the time of writing, is motivated by the fact that it should helps evade detection. Furthermore, BlackCat is operated under a ransomware-as-a-service (RaaS) model. In particular, attackers carry out double-extortion, demanding ransom from victims to get the decryption key and not to see confidential data posted on the Internet.

In this post we will carry out a simulated detection exercise. Indeed, Microsoft has publicly disclosed the attack chains of the group related to two data breaches. As we will see, the way in which attackers are able to get a foothold into the system may vary, but once they're in they use the same tecniques to discover more Active Directory credentials in order to both move laterally inside the network and escalate privileges, with the goal of encrypting and exfiltrating as much information as possible.

From a defender perspective, I think that it is useful to understand how these attackers act, in order to be able to recognize specific attack patterns if they happen. Actually there are many indicators of compromise on the web, that were obtained from other data breaches, but these signatures give little added value because, as Microsoft researchers highlight, this ransomware is customized for the victims and attacks are carefully pre-planned, so probably different payloads will be deployed on different targets, having therefore different signatures.

On the contrary, it is interesting to see which are their techniques and tactics. We will see that in both reported attacks, credential dumping techniques are employed. These activities will result in certain events that will be logged in the Windows Event Viewer. We will therefore replicate these attacks, see the events that are generated and try to identify a pattern. Then, we will use Security Event Explorer to show how custom orchestration rules can be simply created to detect these activities.

BlackCat Case Study n.1

In the first security incident, attackers managed to enter the target network by exploiting unpatched Exchange servers.

Once they were in, they began to look around and found a directory containing various passwords (!). However, in order to move laterally they also decided to dump the memory of the Local Security Authority Subsystem Service (LSASS) process, which holds the hashes of the passwords of the users that had previously logged onto the machine.

Instead of dropping Mimikatz on the machine, they simply ran Task Manager and collected the LSASS memory dump. As Task Manager has no known command-line switches to perform the dump, we can replicate the dump by simply running the task manager (with elevated privileges), selecting LSASS process, right clicking on it and finally creating the dump file:



Now, let's see how we can detect what is going on by looking at the security events logged into the Windows Event Viewer after we perform the memory dump.

Among the many events that are generated, especially if you enabled full logging, there are four events that explain what is happening.

The first one is the event ID 4690. This event is generated because a process duplicated a handle to an object. But what handle? To answer this question you have to look at the SourceHandleId field: this field contains the ID of the duplicated handle, and we will see shortly that this handle is exactly the one used to access the memory of the LSASS process.

If we search our logs by the same SourceHandleID, we'll find out that the next event that we find is event ID 4656. This makes sense, because this event is generated when a request for an object handle is made. So, previously we duplicated the handle to the LSASS process memory and now we ask to use such handle to actually access the memory. If we look at the contents of the logs, we see that the ProcessName is C:\Windows\System32\Taskmgr.exe and that the ObjectName (the object which is accessed) is \Device\HarddiskVolume3\Windows\System32\lsass.exe. So, we detected an attempted access from TaskManager to the memory of the LSASS process, but we don't know yet if the requested access was granted by the OS.


To discover if the requested memory access was granted by the OS, we need to search for event id 4663, which is the event that is generated when the OS actually grants the source process the rights to access the requested object. In this case, if we search again the logs by the same SourceHandleID we'll actually find the event 4663, meaning that LSASS memory was actually accessed by TaskManager.


Finally, the handle has to be closed, and indeed we can find event id 4658, which is generated every time the handle to an object is closed. We can check again the SourceHandleID in order to verify that this event is actually related to the handle we were investigating.



So, now that we have seen which are the traces left behind a LSASS memory dump carried out with Task Manager, it is time to see how we can implement a custom detection rule using the Security Events Explorer orchestrator.

I will use a chain of three events, happening in very close sequence (less than 0.1 seconds)

First event:

EventID=4656 AND ProcessName CONTAINS Taskmgr.exe AND ObjectName CONTAINS lsass.exe

Second Event:

EventID=4663 AND ProcessName CONTAINS Taskmgr.exe AND ObjectName CONTAINS lsass.exe

Third Event:

EventID=4658 AND ProcessName CONTAINS Taskmgr.exe

which actually maps to the following rule in Security Events Explorer:


And if we draw the timeline of the events, we see that the orchestrator actually detects the LSASS dump, indeed we have two hits in the bottom of the timeline (there are actually many events 4656, 4658 and 4663, for this reason it builds two chains).



In the second part of this post we will analyze the second BlackCat (ALPHV) ransomware attack reported by Microsoft, still focusing on logs:

https://thebytemachine.com/detecting_lsass_credential_dumping_by_blackcat_ransomware_pt2_wdigest_and_mimikatz

References

https://www.microsoft.com/security/blog/2022/06/13/the-many-lives-of-blackcat-ransomware