Detecting BlackCat Ransomware credential dumping in Windows with Security Events Explorer - pt2

In this second part of the post, we will simulate and analyze the techniques used by attackers to steal credentials during a second deployment of the BlackCat (aka ALPHV) ransomware.

We previously simulated the techniques that according to Microsoft were used to dump credentials during a BlackCat ransomware infection. Basically, attackers used Task Manager (taskmgr.exe) with an Administrative account to dump the LSASS process memory. They did not upload Mimikatz on the host, they evidently ran it or similar tools offline to avoid detection. We saw however that if full auditing was enabled on the target host (we used a Windows Server 2019 for our lab, acting as domain controller), then Windows generated logs on the Windows Security Events that we showed that can be used to detect the activity in progress. Then, we built a detection rule using Security Event Explorer and run the tool to demonstrate that such a rule is able to detect LSASS memory dump via task manager. Finally, we have imported such rule into the SEE library to make it available for everyone without having to build it from scratch.

BlackCat Study Case n.2

Now let's move to the second case study reported by Microsoft, and see whether Windows Security events and Security Events Explorer can help in detecting this kind of attack too.

In this case, attackers got a foothold into the target organization via an internet facing Remote Desktop server, using compromised credentials. Once they were in, they used SMB to copy the Total Deployment Software, which they used to install Screen Connect, a remote desktop application that they used to remotely control the hacked device.

At this point, attackers started to search for additional credentials stored on the host. Instead of diretly getting the hash of the stored passwords, they decided to directly get plain-text passwords. This would save them time in cracking the hashes. To do that, they updated the Registry to allow cleartext authentication via WDigest. This is a well-know technique, and here's how it works.

First, you can test whether clear-text credential caching is enabled. Open a command prompt and type:

> reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential 

This option should be disabled by default for obvious security reasons. So the output that you should get is the following, telling that the requested key is not present in the registry:

> ERROR: The system was unable to find the specified registry key or value. 

Well, so what we have to do in order to emulate attackers' behaviour, is to create the Wdigest UseLogonCredential registry key to store plain-text passwords of logged users in memory. Type the following in a command prompt:

 > reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 

This is the first detection opportunity that we have. Actually, forcing WDigest to store plain-text credentials in memory is a highly suspicious event that should raise a high-priority alarm. The bad news, is that although you enable all the auditing on your Windows box, these event could go lost anyway. Indeed, the security event that notifies modification to the Windows Registry is Event 4657 - A registry value was modified. However, this event is not logged by default. To enable it, we have to:

- open the Registry Editor

- select the Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest registry key

- right click on it, then click on Permissions, Advanced and open the Auditing tab

- finally, to enable auditing on the Wdigest registry key, click on Add and Select a Principal

- insert the user or group name that will have auditing rights on the Wdigest key

Fig 1: Open Registry Editor and right click on the WDigest registry key

Fig 2: Enable auditing on the WDigest registry key

All Right! So if enabled WDigest auditing before the attackers actually carried out the attack, we should be able to see the event 4657 in the Windows Event Viewer. As you can see in the following image, the distinctive fields are:

- Event ID equal to 4657

- Object Name equal to \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\WDigest

- Value equal to 1

- ProcessName equal to C:\Windows\System32\reg.exe

Fig 3: Detect WDigest registry key modification in Windows Event Viewer

And this event is easily mapped into a Security Events Explorer rule. In figure 4, you can see that detecting this event is trivial, since a single event with three filter conditions is sufficient. This way, we can detect any modification to the WDigest registry key, although we have to remember that plain-text password caching is enabled only when the value is set to one. I have integrated this rule into the WDigest library rule, belonging to the T1003.001 technique (OS Credential Dumping: LSASS Memory)

Fig 4: Create a rule in Security Events Explorer to detect WDigest registry key modification

And if we export the security event logs and load it into Security Events Explorer, enabling the WDigest detection rule, we can observe that the tool is actually capable of making the right detection:

Fig 4: Detect WDigest registry key modification with Security Events Explorer rule

Ok, so now that we have seen how we could be able to detect attackers activity when enabling in-memory plain-text password caching, let's go back to our study case. Of course, attackers were not detected while performing this activity. However, at this point they have to wait for some user to login into the host, because you don't get plain-text passwords for the previous logins. And indeed Microsoft says that they basically took a break, and came bake after a while to dump the LSASS memory with Task Manager (we saw in part 1 of this blog post how we can detected LSASS memory dump via task manager).

However, this was not sufficient, and they came back again after eight hours, dropped Mimikatz onto the host and finally they retrieved plain-text passwords (likely) with the following commands:

C:\>mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/


mimikatz # privilege::debug
Privilege '20' OK

mimikatz # sekurlsa::wdigest

Authentication Id : 0 ; 228964 (00000000:00037e64)
Session           : Interactive from 1
User Name         : Administrator
Domain            : SEE
Logon Server      : SEEDC1
Logon Time        : 6/21/2022 8:25:56 AM
SID               : S-1-5-21-1796978674-3809065377-4260004323-500
        wdigest :
         * Username : Administrator
         * Domain   : SEE
         * Password : SuperSecretPassword


                   -- snip --

			  

The key point here is that if you run the sekurlsa::wdigest command in Mimikatz you can now get the plain text password, which in this case is SuperSecretPassword. If we did not add the previous registry key, we would have had Password : (null) because no plain-text would be available, and we would had to crack hashes in order to recover plain-text password. Instead, this method is much faster!

So before closing, let's see how we could detect the attackers' activity while using Mimikatz to retrieve plain-text passwords.

The first Security Event to look for is Event ID 4690 - An attempt was made to duplicate a handle to an object. Although no process name appears here, it is worth to take note of the SourceProcessID and the TargetHandleID fields: the Source Process ID identifies the process that is trying to duplicate the handle, while the Target Handle ID identifies the handle that is duplicated.

Fig 5: First Log - Event ID 4690 generated after Mimikatz's sekurlsa::wdigest command

If the Mimikatz command succeded, the handle has been duplicated, so now we have two handles pointing to the same object (LSASS memory). Therefore, the old handle can be closed, since Mimikatz will use the brand new one.

The second logged event indeed accounts for the closure of the first handle: it is the Event ID 4658 - The handle to an object was closed. Also in this case there are some things note.

First, the Process Id matches the SourceProcessId of previous event (figure 5). This means that the process that previously duplicated the handle, is now closing it, and this validates our analysis.
Second, in this case we have the process name: if we look at the ProcessName fields, we can see that the process is actually Mimikatz (C:\mimikatz_trunk\x64\mimikatz.exe).
Third, if we look at the handle that is being closed (field HandleId), we can see that it actually matches the TargetHandleId of previous event.

Fig 6: Second Log - Event ID 4658 generated after Mimikatz's sekurlsa::wdigest command

The third event is Event Id 4656 - A handle to an object was requested. This event is generated when Mimikatz tries to access the object via the handle. According to Microsoft: This event shows that access was requested, and the results of the request, but it doesn’t show that the operation was performed. To see that the operation was performed, check “4663". There are some interesting fields in this event too.

We can see that ProcessName is Mimikatz and that actually ProcessId matches the previously identified Process Id.

Then, the HandleId matches the SourceHandleId of figure 5, so this is a further confirmation of our suspects: the target handle id was used as source to copy the handle and then it was closed, while the Source Handle Id is actually the copy of the handle that will be used by Mimikatz.

Finally, the most important field is perhaps ObjectName, that actually tells us that the handle is used to access the LSASS process memory.

Fig 7 - Third Log: Event ID 4656 generated after Mimikatz's sekurlsa::wdigest command

Ok, if the LSASS object was actually accessed, then event id 4663 was generated, and this is actualy the case reported in figure 8.
While event 4656 indicated that acess was requested, event 4663 indicates that a specific operation was performed on the object.

Again, you can check that the highlighted fields in figure 8 contain the same values, so this event is correctly related to the previous ones.

In addition, take a look at the AccessList field. This field is not well-known as others, and actually Microsoft does not spend any word for it when describing the event 4663. However, we can guess that it deals with the kind of access to the object, and further searching on the Internet tells us that the value that we have, %%4484 likely matches to Read from process memory, which is exactly what we know Mimikatz is doing.

Fig 8: Fourth Log - Event ID 4663 generated after Mimikatz's sekurlsa::wdigest command

Finally, after Mimikatz has dumped the memory, it closes the handle, and event id 4658 is logged.

There is nothing special here, to be sure that you found the right event you can look at the highlighted fields (ProcessName, ProcessId, HandleId) and verify that their values match the previous ones.

The only thing to note here is that in my case this event was generated when I closed the Mimikatz executable, so maybe it could pass some time between the previous events and this one.

Fig 9: Fifth Log - Event ID 4658 generated after Mimikatz's sekurlsa::wdigest command

Finally, let's see how we can detect the Mimikatz execution with Security Events Explorer.

In the Orchestrator, enable the Mimikatz rule as shown in figure 10:

Fig 10: Security Events Explorer's Mimikatz detection rule

As you can see, the selected events are reported in the timeline, and in particular the Mimikatz detection rule triggered and identified the Mimikatz execution based on the Windows logs traces.

Fig 11: Security Events Explorer detects Mimikatz's activity

Conclusions

Microsoft's report describing two Blackcat (aka ALPHV) ransomware security incidents gave us the opportunity to deeply analyze and emulate the techniques used by the attackers to steal Windows credentials.

We have seen that in both cases they used well-known techniques to access credentials in memory, and we were able to replicate their actions in a lab environment, were full auditing was enabled.

Therefore, we have seen that actually the simulated activity left traces in our Windows logs, and we analyzed each trace and matched it to a specific pattern of events. Our goal was to prove that if we recognize a pattern of events in the Windows logs, then we can match it to the corresponding source activity on the host.

We showed how this process can be done by hand, by analyzing each event in every pattern. Then, we tried to automatize the process, building detection rules that work in Security Events Explorer, a tool that I developed to easily browse Windows Security Events.

Although the tests were carried out in a restricted environment, and for sure these rules could be refined and tuned, we showed that the tool was actually able to detect the various attackers techniques, showing that it could be potentially used during forensics operations, helping Security Analysts to spot attackers activities.

References

https://thebytemachine.com/detecting_lsass_credential_dumping_by_blackcat_ransomware (part 1)

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

https://support.microsoft.com/en-us/topic/microsoft-security-advisory-update-to-improve-credentials-protection-and-management-may-13-2014-93434251-04ac-b7f3-52aa-9f951c14b649