How Mimikatz is Used in Modern Ransomware Attacks: Forensic Analysis and Detection Techniques

Chapter 9: Post-Exploitation Techniques

For attackers, initial access is just the first step. Early ransomware attacks aimed to immediately encrypt the first compromised host, but now many ransomware attackers focus more on post-exploitation. During this phase, they may use tools like Mimikatz for privilege escalation, credential harvesting, reconnaissance, and other actions to ensure control over the entire network, extract the most valuable data, and encrypt as many hosts as possible. Additionally, since many attackers also engage in data theft, they try to stay in the network longer to capture the most critical data. For the same reason, they may also need additional backdoors, such as legitimate remote access software.

As you learned in Chapter 5, “Strategies, Techniques, and Procedures of Ransomware Spread Groups,” the most common post-exploitation activities are credential access, reconnaissance, and, of course, lateral movement within the network.

In this chapter, we will focus on digital forensic evidence that can reconstruct the actions of ransomware operators during these three stages of the attack lifecycle. We will examine various methods used by individuals associated with one of the most active groups—Conti ransomware—and discuss the following topics:

• Methods of credential harvesting
• Methods of reconnaissance
• Methods of lateral movement within the network

Methods of Credential Harvesting Using Mimikatz

To begin lateral movement within the network, ransomware operators must obtain privileged credentials. Attackers use several popular methods to achieve this goal. For example, they can create a memory dump of the Local Security Authority Subsystem Service (LSASS) process to extract credentials or perform Kerberoasting attacks. Let’s see how digital evidence analysis can help us uncover these methods.

Using Hacking Tools Like Mimikatz to Dump Credentials

As you already know, the most popular credential-stealing tool is the notorious Mimikatz, developed and maintained by Benjamin Delpy. It is so widely used that even standard antivirus software can usually detect and remove it. However, attackers often disable built-in antivirus software, allowing some ransomware operators to load Mimikatz directly from the GitHub page onto the compromised host.

Figure 9.1. Description of Mimikatz from the GitHub page

The original Mimikatz is easily detectable, but we have encountered many modified versions, such as Invoke-Mimikatz, Pypykatz, SafetyKatz, etc. You may also come across versions adapted by attackers that are harder to detect.

Furthermore, in most cases, you will not see a file named mimikatz.exe (though there are exceptions)—more often, it may be named mimi.exe, m.exe, or x64.exe. These unusual malicious executable file names can provide important clues during your investigation. Additionally, ransomware users often delete the tools they use during post-exploitation, so you may need to focus on forensic evidence pointing to their execution, such as UserAssist, Shimcache, Amcache, Prefetch, etc.

Let’s try to find evidence of running a credential-dumping program similar to Mimikatz. A very good tool is Amcache because it not only saves execution timestamps but also metadata and even SHA1 hashes, allowing us to identify executables even if they have been renamed and deleted.

You can use tools like AmcacheParser to extract data from Amcache.hve.

Figure 9.2. Partial output of AmcacheParser

Figure 9.2 shows the execution evidence extracted using AmcacheParser. At first glance, we do not see anything related to Mimikatz, but there is a very suspicious file in the C:\ProgramData folder—o5981r8p.exe. Other temporary folders to note are Temp, AppData, and Windows.

Let’s try to learn more about this file by examining the metadata in Amcache.

• First execution time: 2021-11-28 12:00:15 (UTC)
• SHA1: 539c228b6b332f5aa523e5ce358c16647d8bbe57
• Size: 380928
• Product version: 2.2.19882.0

Unfortunately, besides the version information, we do not have any other information about the product, but we do have the SHA1 hash. A Google search confirms that this hash is related to GMER—a tool used to detect and remove rootkits. This is clearly a sign of criminal activity! Ransomware operators often use GMER to terminate various processes, such as antivirus software.

Although we have not yet found evidence of using a credential-dumping tool, we have identified a possible intermediate folder—ProgramData. Checking antivirus logs is always helpful. During the attack lifecycle, attackers use many tools, and finding some of these tools can serve as reliable starting points for investigation and response.

Event codes are very useful when responding to incidents, so it is wise to review Windows event logs.

In this case, we only have Microsoft Windows Defender. Detection information can be found in the Windows event log file Microsoft-Windows-Windows Defender%4Operational.evtx. The most interesting event, with a warning level, is 1116. We process this file using EvtxECmd.

Figure 9.3. Events extracted by EvtxECmd

As you can see, we have only one event with ID 1116. Let’s take a look at its contents.

• Malware name: Backdoor: Win64/CobaltStrike.NP!dha
• Description: Backdoor (high risk)
• Detection time: 2021-11-28T09:56:21.898Z
• File: C:\ProgramData\64.dll

Cobalt Strike! This is a tool commonly used by many hackers. It provides attackers with remote access to the host, allowing them to execute commands and files, extract data, and, of course, create credential dumps. More importantly, the corresponding DLL is located in the same folder—C:\ProgramData.

Let’s use MFTECmd to create a timeline based on $MFT and check if there are other signs of malicious files in that folder (see Figure 9.4).

Partial results from MFTECmd work output

Figure 9.5. Trace file of SK.exe

As you can see, shortly after o5981r8p.exe, another suspicious file—SK.exe—was created. We did not see it in the output of AmcacheParser, but it does have a trace file indicating it was executed (see Figure 9.5).

Based on $MFT analysis, we know this file still exists—we can hash it. By checking the hash on VirusTotal, we immediately get more information about it.

Figure 9.6. File information obtained from VirusTotal

We found that this is SafetyKatz—a slightly modified version of the original Mimikatz. Of course, these tools usually leave no fewer traces than Cobalt Strike Beacon, so ransomware users often use built-in tools for credential dumping.

Using Built-in Tools like Mimikatz to Dump Credentials

Attackers have successfully leveraged the capabilities of the Windows operating system itself—particularly for credential dumping. We know that many ransomware groups use comsvcs.dll to create dumps of lsass.exe.

Finding evidence of this activity can be very challenging because attackers abuse rundll32.exe to call the exported function MiniDump from comsvcs.dll. However, there are several very useful forensic pieces of evidence that can help you discover this method.

As you know, trace files not only contain evidence of execution but also lists of files and folders interacted with by the executable. Since rundll32.exe typically does not reference comsvcs.dll, we can investigate the related trace files.

In this case, there are seven trace files related to the executable under investigation. If you dissect each file, for example, using PECmd, you will find some suspicious records in the list of files interacted with by the executable (see Figure 9.7).

Figure 9.7. File interaction list extracted from rundll32.exe trace file

As shown, comsvcs.dll is referenced—the attacker likely used this technique to perform credential dumping as well as using SafetyKatz.

Let’s look at another piece of evidence often overlooked in forensic investigations—the PowerShell console history file. These files are located in the %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine folder and can be viewed in any text editor, and they are available by default from PowerShell v5 in Windows 10 and later versions. Check these files for useful clues:

Now we clearly see that the attacker abused comsvcs.dll to obtain a dump of lsass.exe. We also see evidence of another SafetyKatz (SK.exe) execution.

There is also a very interesting executable—Rubeus.exe. What is it? Let’s find out!

Kerberoasting with Mimikatz

Credential dumping is a very common method for attackers during human-operated ransomware attacks. But it is not always possible to obtain the credentials needed for lateral movement, so attackers must use other methods.

One method increasingly used by attackers is kerberoasting. This type of attack allows attackers to exploit existing Kerberos Ticket Granting Tickets (TGT) or intercept network traffic to obtain Service Granting Tickets (TGS) and then attempt to crack the passwords offline through brute force.

In the previous section, we saw evidence of the attacker downloading and running Rubeus.exe—a very popular tool for performing such attacks, particularly used by individuals associated with the Conti group. You may often encounter similar methods because attackers need valid credentials to begin lateral movement within the network.

We have already seen evidence of Rubeus execution in the PowerShell console history file, but let’s investigate some other sources not yet covered, such as the System Resource Usage Monitor (SRUM).

This feature, introduced in Windows 8, collects information about different executables and their resource consumption (including network traffic and total CPU time). This information is stored in an Extensible Storage Engine (ESE) database, typically located in the SRUDB.dat file in the C:\Windows\System32\sru folder.

We can use SrumECmd to extract the data we are interested in from this file.

Figure 9.8. Partial output of SrumECmd

As shown in Figure 9.8, this is another piece of evidence of Rubeus execution. It is very important to check different evidence sources because different executables may leave different traces in different situations. Additionally, do not forget that ransomware users often delete their tools from compromised hosts.

do not forget that ransomware users often delete their tools from compromised hosts.

Another important piece of evidence is the execution of netscan.exe. Let’s learn. First, we need to know its location. We have already analyzed the $MFT, so let’s start from there. $MFT analysis better shows which evidence might be useful for further investigation and allows viewing the attack from a file system perspective. Now we see that netscan.exe is located in the C:\Users\Public folder. Furthermore, we see a trace file was created immediately after the executable. As you know, this means the file was executed. But who executed it? Let’s look at another source of program execution information—this time, UserAssist. To extract the information, we need to obtain the NTUSER.dat file and process it using a tool like RegRipper. By analyzing the NTUSER.dat file located in the C:\Users\smith folder, we see that netscan.exe was executed by user smith. But are we sure that a network scan indeed occurred? Not yet! Let’s check the file properties. The file properties are clear: It looks like we are dealing with SoftPerfect Network Scanner. As you can see, file properties can reveal many characteristics about a file, including its version, developer, and so on. But let’s check the folder where we found it. As you can see, there are many interesting files in this folder. In fact, ransomware operators might use multiple intermediate folders to store their tools, so be sure to check every piece of evidence and try not to miss any valuable clues.

Figure 9.9. The path to netscan.exe obtained from $MFT

Now we see that netscan.exe is located in the C:\Users\Public folder. Additionally, we see a trace file was created immediately after the executable file. As you know, this means the file was executed. But who executed it? Let’s check another source of program execution information—this time, UserAssist. To extract the information, we need to obtain the NTUSER.dat file from the C:\Users\smith folder and process it with a tool like RegRipper. By analyzing the NTUSER.dat file located in the C:\Users\smith folder, we see that netscan.exe was executed by user smith. But are we certain that a network scan actually took place? Not yet! Let’s inspect the file properties. File properties are quite revealing: it looks like we’re dealing with the SoftPerfect Network Scanner. As you can see, file properties can reveal many characteristics about a file, including its version and developer. But let’s examine the folder where we found it. As you can see, there are many interesting files in this folder. In fact, ransomware-related individuals might use multiple intermediate folders to store their tools, so be sure to check every piece of evidence thoroughly without missing any valuable clues.

Let’s take another look at another source of program execution information – this time it’s UserAssist. To extract this information, we need to obtain the NTUSER.dat file and process it with tools like RegRipper.

Figure 9.10. UserAssist Data Analyzed with RegRipper

By analyzing the NTUSER.dat file located in the C:\Users\smith folder, we see that netscan.exe was executed by the user smith. But are we certain that network scanning actually took place? Not yet! Let’s check the file properties.

Figure 9.11. Properties of netscan.exe

The file attributes are quite clear: it looks like we are dealing with SoftPerfect Network Scanner. As you can see, the file attributes can reveal a lot about the file, including its version and developer. But let’s check the folder where we found it.

Figure 9.12. Contents of C:\Users\Public

As you can see, this folder contains many interesting files. In fact, ransomware operators may use several intermediate folders to store their tools, so be sure to check each piece of evidence and try not to overlook any valuable clues.

Active Directory Reconnaissance with Mimikatz

So, there are a few interesting files in the C:\Users\Public folder. One of them is AdFind.exe, which could be AdFind—a free tool used for gathering information from Active Directory. Additionally, there are several files with a .txt extension—are they related to AdFind?

In addition, there is another suspicious file in this folder— a.bat. Let’s take a look inside.

Now we can determine that the attackers used AdFind to gather information about Active Directory. Assuming they have already obtained credentials and collected information about the compromised network—what’s next? The next step is lateral movement within the network.

Methods for Studying Lateral Movement in Networks Using Mimikatz

Ransomware operators do not linger on the first compromised host—they need to collect network information and quickly move forward to find and gather valuable sensitive data, and reach the final stage—deploying the ransomware.

Managing Network Resources with Mimikatz

A common method for lateral movement is to exploit Windows administrative shared resources, such as C$, ADMIN$, and $IPC. If an attacker has already obtained the appropriate credentials, they can easily view files on a remote host and even copy files to it.

We have already reviewed the NTUSER.dat file. Let’s double-check, this time using Registry Explorer (see Figure 9.13).

Evidence from accessing drive C: of 192.168.1.76

We observed that the compromised user accessed the address 192.168.1.76. Interesting! Let’s obtain the $MFT file from this host and try to determine if any files were copied to it. We’ll process it using MFTECmd and review the results in Timeline Explorer.

Figure 9.14. Suspicious File on 192.168.1.76

Analysis revealed a very suspicious file in the C:\Users\Public folder—a common intermediate folder used by attackers. Let’s take a look at the contents of this file.

It looks like the attackers used this file to enable RDP connections. But was it ever run on the system? We will find the answer in the next section.

Using Mimikatz: A Guide Similar to PsExec

First, since we already know that rdp.bat can enable RDP connections by editing the registry, let’s check the SYSTEM registry file.

HKLM\System\CurrentControlSet\Control\TerminalServer contents

As shown in Figure 9.15, the fDenyTSConnections value is 0, which means the attacker successfully ran the script. Let’s try to gather more evidence. I believe you have noticed that the script also affected the firewall’s operation. We can review the Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx event log file and check for events with ID 2005.

Figure 9.16. Changes to Firewall Rules

We can see that the firewall rules have also been modified, which means we can confirm that the malicious script has run on the target system. But how did it run?

Let’s continue examining the Windows Event Logs—this time focusing on System.evtx and Event ID 7045.

Figure 9.17. Services Related to PsExec

As shown in Figure 9.17, you can see a very common piece of evidence related to PsExec—a popular remote execution tool typically used by system administrators and ransomware operators.

It is highly likely that this tool was run from the initially compromised host, but we still need to find evidence. Let’s check the Security.evtx event log file and search for ID 5140 or 4624 around the time PsExec was run.

We now have evidence that PsExec was run from the initially compromised host 192.168.1.77, and the attacker successfully obtained the credentials for the Administrator account.

Figure 9.18. Evidence of accessing network resources (5140)

So, the attackers enabled RDP—let’s find out if they used these connections.

RDP: Using Mimikatz for Remote Desktop Protocol

RDP is one of the most common methods attackers use for lateral movement within a network. You will frequently encounter this method when investigating human-operated ransomware attacks.

There are quite a few sources of evidence that can help you detect this activity. One of the most common is the Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx event log file. Typically, you should look for Event ID 21 (successful logon) and 25 (session reconnect).

Figure 9.19. Successful Session Restoration

Figure 9.20. Type 10 Logon

You can also use event ID 4624 in the Security.evtx file, focusing on login types of 10.

Therefore, we can conclude that the attacker obtained privileged credentials, conducted reconnaissance of the network and Active Directory, and began using various methods for lateral movement within the network. Of course, this is not the entirety of their activities.

Conclusion: Mimikatz

Human-operated ransomware attacks are quite sophisticated, consisting of multiple phases in the attack lifecycle. After establishing an initial foothold, attackers begin post-exploitation to take control of the entire network.

In this chapter, we explored various post-exploitation methods and reconstructed part of a ransomware attack based on different pieces of forensic evidence.

We learned how attackers acquire privileged accounts, conduct reconnaissance on the network and Active Directory, and perform lateral movement.

In the next chapter, we will focus on how ransomware operators address one of the main objectives of modern attacks—data theft.

Chapter 10: Data Exfiltration Methods Using Mimikatz

Once they have obtained the privileged account credentials and ensured they can move laterally within the network, ransomware users begin pursuing one of their primary objectives: data theft.

Certainly, not every group will engage in this type of operation, and some attackers with Data Leak Services (DLS) may not necessarily do so either. However, double extortion is quite common, and incident response experts need to be familiar with the methods extortionists use to steal confidential data from compromised networks.

In this chapter, we will explore the forensic evidence that allows us to understand how ransomware operators exfiltrate data. The methods used by different attackers can vary widely. Some prefer simple methods, such as using web browsers or cloud storage client applications, while others choose to use specialized applications that are often included in Ransomware as a Service (RaaS) packages.

We will explore the following topics:

• 研究滥用网络浏览器的方法。
• 研究滥用云存储客户端应用程序的方法。
• 研究滥用第三方云同步工具的方法。
• 研究使用专门工具的方法。

“Research Methods for Abusing Web Browsers Using Mimikatz”

As you learned in previous chapters, ransomware attackers frequently misuse Remote Desktop Protocol (RDP) connections for initial access and lateral movement, allowing them to easily leverage built-in legitimate tools for data theft.

One such tool is the web browser. Attackers can use it to upload collected confidential data to various file-sharing services, such as DropMeFiles.

Web browsers have extensive logging capabilities, allowing cybercrime analysts and incident response experts to always review browsing history for signs of data breaches.

Let’s take a look at the built-in web browser of the classic version—Microsoft Edge. Browsing history is stored in the WebCacheV01.dat file, which is an ESE (Extensible Storage Engine) database. There are many tools available to view and analyze its contents. A good choice is NirSoft’s ESEDatabaseView.

is the size of the executable, and is the path to StealBit:

As you can see, ransomware users can be very creative in stealing confidential data. For this, they can use a wide range of tools, so incident responders need to stay up-to-date with the latest cybersecurity threat investigation data.

Conclusion

Double extortion has become a very popular strategy among ransomware-related groups. Each year, confidential data from hundreds of organizations is publicly exposed online. Therefore, incident response experts need to be familiar with the methods and tools used by ransomware operators, as well as the forensic evidence that can be used to detect these activities. We must gain a deep understanding of the attackers and their methods.

In this chapter, we explored common methods attackers use to collect and steal data from compromised networks and learned about the forensic evidence that can be used to trace their activities.

In the next chapter, we will learn how cybercriminals achieve their ultimate goal—deploying ransomware.

## Chapter Eleven: Ransomware Deployment Methods

The main goal of human-operated ransomware attacks is to encrypt as much data as possible. To encrypt data, attackers use various tools, including those obtained from ransomware-as-a-service (RaaS) providers and tools they develop themselves. Sometimes legitimate encryption software is also used, with typical examples being BitLocker and DiskCryptor.

Usually, by this stage, ransomware users have full control over the compromised network: they have gathered information about available hosts, gained privileged accounts, deleted backups, disabled security products, and prepared for subsequent access.

In this chapter, we will explore the most common methods attackers use to deploy ransomware in enterprise networks and briefly discuss their analysis process.

We will cover the following topics:

– Investigating Methods to Abuse RDP
– Investigating Methods to Abuse Administrator Network Resources
– Investigating Methods to Abuse Group Policy

Investigating Methods to Abuse RDP As you know, many ransomware attackers gain initial access by targeting exposed Remote Desktop Protocol (RDP) servers. Additionally, remote access services, particularly RDP, are among the most common methods used by attackers for lateral movement. Unfortunately, many system and network administrators also frequently use these services, so attackers only need to obtain the corresponding credentials. Consequently, many cybercriminals not only abuse RDP for initial access and lateral movement but also use it to deploy ransomware.

In most cases, you need to start your investigation from the final stage of the attack lifecycle—ransomware deployment. Therefore, the first step is to determine how the ransomware was deployed and identify the source of the infection.

Modern ransomware typically changes the extensions of encrypted files and creates a file containing instructions for the victim. To try to find the initial point, i.e., the start of the encryption process, you can begin by analyzing the Master File Table (MFT).

As shown in Figure 11.1, the encryption process began around 10:37 GMT on November 14, 2021. The ransomware created a series of files named how_to_decrypt.hta, which contain instructions for the victim on how to contact the attacker to pay the ransom and obtain the decryption software.

Let’s try to identify the ransomware executable. We can scroll the timeline to the first created file. Here we see a very suspicious trace file.

Hopefully, you remember that ransomware users often delete the tools they used on the compromised host. Sometimes the ransomware itself has a self-deletion feature. However, we still have various sources of execution evidence. These pieces of evidence can help the incident response team identify the malicious and suspicious executables used by the attacker.

In this case, we do not have the malicious executable itself, but we have a trace file pointing to a suspicious file that ran immediately before the creation of the instruction files. The file is named .cr_hand.exe—this is not a common name.

Another question you need to answer is: How did the attacker run the ransomware on the host or multiple hosts? If RDP was used, in most cases, the ransomware user simply copies the malicious file to the target host and runs it manually. This means we can find related evidence in NTUSER.DAT, such as UserAssist.

Now we know the file of interest ran at 10:30:27 GMT. But there are other interesting records here. The first is NS.exe—a tool commonly used by ransomware users to crack RDP. This small tool allows attackers to find and connect to available network resources and unconnected local disks.

The second is Everything.exe. This is a legitimate file indexing and search program that ransomware operators often use for reconnaissance to find out what files are on the compromised host and their sizes.

We have identified the auxiliary software used by the attacker and the account used for deployment—SigmA0. But we need to confirm that .cr_hand.exe is the ransomware.

Let’s check another source of execution traces—the Amcache file (Figure 11.4). It contains SHA1 hashes that we can use to identify malicious files.

Now we have the hash, even if we cannot recover the deleted executable, we still have a chance to identify it. There are quite a few online services focused on automated malware analysis, and we can use these hashes to search for suspicious files. A good option is the VirusTotal service we have used before.

The most informative object is Ransom.Crylock. Therefore, we are dealing with the Crylock ransomware family.

An important note about using online services to identify malware: You can safely use hashes, but never upload ransomware samples to these sites without proper analysis—they often contain information that can identify the victim. For example, many samples include personalized ransom notes (victim instruction files) that contain the name of the victim organization.

Now we have confirmed that the discovered file is a ransomware sample. We also know that it was manually run by the user SigmA0. But how did the attacker gain access to the compromised host?

If we look at the Windows event logs, we will see successful RDP connection records shortly before the Crylock ransomware ran on the host.

In this case, it is an external address—indicating that the compromised host was exposed. In the case of a local host, a similar situation can be seen—the ransomware user can move from the initially compromised host to other hosts in the network via RDP and run the malware on each host.

Let’s learn about Crylock ransomware.

Crylock Ransomware Overview

Before initiating the encryption process, Crylock halts a series of services and processes from an internal list.

The ransomware then deletes shadow and backup copies to prevent system recovery:

To encrypt files, it uses a proprietary symmetric encryption algorithm and RSA to encrypt the keys.

Crylock then creates a ransom note named how_to_decrypt.hta, containing contact information and instructions for the victim.

Of course, manually deploying ransomware is inefficient, especially when attackers plan to encrypt hundreds or thousands of hosts. Therefore, they also use other methods, such as abusing admin shared network resources.

Investigating the Abuse of Admin Network Resources

As we discussed earlier, ransomware affiliates can abuse admin network resources for lateral movement. Attackers can use the same methods to deploy ransomware, a good example being PsExec. Some attackers use pre-prepared batch files to copy the ransomware executable to the target host and then use PsExec to run it.

Of course, this is not the only method involving admin network resources. Let’s look at another example, starting with a timeline based on the MFT.

Figure 11.7 shows many ransom notes created by the malicious executable and a suspicious trace file.

When investigating the abuse of admin network resources, you should pay attention to a common piece of evidence—service installation events. These can be found in the Windows System.evtx event log file—ID 7045.

We see that the suspicious file msedgeupdater.exe was run by creating a new service from the srvdc01 host (likely a domain controller).

Therefore, during lateral movement, the ransomware operator compromised a domain controller and used it to deploy the ransomware—a fairly common scenario. Since the service was likely created remotely, we can examine the login events in the Windows Security.evtx event log in detail.

We see that the attacker used an admin account to deploy the ransomware from the domain controller by creating a remote service.

However, we have not yet identified the type of ransomware. We already know how to use hashes, but let’s change our strategy and focus on other evidence left by the ransomware.

In many cases, the simplest method is to look at the ransom note.

As you can see, the ransom note contains two suspicious URLs: hxxp://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion/062E246860D29CB2 and hxxp://decoder[.]re/062E246860D29CB2.

A Google search of these URLs can identify the ransomware.

Based on the search results, we can infer that we are dealing with REvil (Sodinokibi) ransomware. Additionally, since many ransomware modify the registry, we should also pay attention to unique registry keys and their values. Since we know the encryption occurred on June 27, 2021, we can check the keys created or modified on that day.

We found a suspicious registry key named BlackLivesMatter. A quick search using public data reveals that this key is mentioned in a report by the BlackBerry Research & Intelligence Team on REvil ransomware.

Now we have enough information to confirm that we are dealing with REvil ransomware. It’s time to learn more about it.

REvil Ransomware Overview

First, REvil collects system information and identifies its characteristics. Before starting the encryption process, the ransomware stops processes from a list stored in the encrypted data. The key length is 32 bytes and is located at the beginning of the encrypted data.

[Ran the following steps, maintaining confidentiality of shared context] After stopping the processes, the ransomware deletes shadow copies to prevent using them for data recovery.

REvil uses curve25519/Salsa20 to encrypt files, and the key is encrypted with curve25519/AES-256-CTR. REvil adds its own extension to encrypted files, such as .1qu4746az.

REvil also changes the desktop wallpaper (placing its version in the %Temp% folder) and creates ransom notes in all folders containing encrypted files.

To remain undetected in the system, REvil modifies the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run.

Abusing admin network resources is not the only method attackers use to deploy ransomware enterprise-wide. Another common method is modifying Group Policy.

Investigating the Abuse of Group Policy

Modifying Group Policy is an increasingly popular method used by attackers to deploy ransomware.

In most cases, by the time of ransomware deployment, the network has been fully compromised, allowing attackers to easily move to the domain controller and abuse Group Policy to deploy ransomware enterprise-wide.

Additionally, some ransomware has built-in features to propagate themselves by modifying Group Policy. A good example is LockBit ransomware.

You can follow the path we discussed earlier: find the first ransom note and start checking what happened before its creation. In this case, we see a very suspicious Group Policy Object (GPO) was created.

As we can see, a new object with a globally unique identifier (GUID) {E97EFF8F-1C38-433C-9715-4F53424B4887} was created. Additionally, there is a very suspicious file 586A97.exe in the C:\Windows\SYSVOL\domain\scripts folder.

First, let’s look at a few Extensible Markup Language (XML) files. For example, Services.xml contains information about the services to be stopped. Here is an excerpt from that file.

The next file, Files.xml, copies the suspicious file from the previously specified shared folder to the target host’s Desktop folder (Figure 11.16).

Finally, the ScheduledTasks.xml file is used to create scheduled tasks to stop listed processes and run the ransomware executable (Figure 11.17).

Another notable file is Registry.pol. It contains information about registry changes used to disable various features of Windows Defender to prevent it from interrupting the encryption process.

We can use the hash of the 586A97.exe file to try to identify it (Figure 11.18).

So now we are sure that we are dealing with LockBit ransomware. Continuing with the forensic analysis, we look at the Windows event logs related to PowerShell and find records as shown in Figure 11.19.

As we can see, LockBit abuses PowerShell to force group policy updates. Let’s take a look at the LockBit ransomware itself.

Overview of LockBit Ransomware with Mimikatz Integration Before starting the encryption process, LockBit ransomware stops a series of processes and services to block system recovery by executing specific commands. LockBit uses AES-128 CBC mode to encrypt files on the infected host. It adds a .lockbit extension to each encrypted file and changes their icons. The ransomware also alters the desktop background to a specific image. LockBit creates ransom notes in all folders containing encrypted files. These ransom notes are named RESTORE-MY-FILES.txt. Additionally, LockBit ransomware can create group policy objects to disable antivirus software, terminate certain processes, and propagate itself across the network.

Before starting the encryption process, LockBit ransomware stops processes and services from a built-in list and blocks system recovery by executing the following commands:

LockBit uses AES-128 CBC mode to encrypt files on the target host. It adds the .lockbit extension to each encrypted file and changes their icons.

The ransomware also changes the desktop background to the following:

LockBit creates ransom notes in all folders containing encrypted files. The ransom note file is named RESTORE-MY-FILES.txt.

LockBit ransomware can also create group policy objects to disable antivirus software, terminate processes, and propagate itself.

Conclusion: Mimikatz

Ransomware operators use various methods to spread malicious code across enterprises based on their skills and targets.

In this chapter, we explored the most common methods observed in modern human-operated attacks for deploying ransomware across enterprises and learned how to use various forensic evidence to discover and reconstruct the attack.

Now that we have learned a lot about how to respond to ransomware attacks and the various methods attackers use, we can summarize and propose a unified ransomware attack lifecycle.

In the final chapter, we will explore various lifecycles, including the Cyber Kill Chain, MITRE ATT&CK, and Unified Kill Chain, and discuss a unified lifecycle specific to ransomware attacks—the Unified Ransomware Kill Chain.

Chapter 12: Unified Ransomware Attack Lifecycle with Mimikatz

Now that you understand the methods attackers use at various stages of the human-operated ransomware attack lifecycle, we discussed how to gather and use cyber threat intelligence, collect data from various sources, and perform digital forensic analysis to reconstruct different stages of the attack during incident response.

In this chapter, we will summarize this knowledge, examine different attack lifecycles, and form a unified ransomware attack lifecycle.

We will discuss the following topics:

• Cyber Kill Chain®
• MITRE ATT&CK®
• Unified Kill Chain
• Unified Ransomware Kill Chain

Cyber Kill Chain®: Using Mimikatz

The Cyber Kill Chain® was proposed by Lockheed Martin as part of the Intelligence-Driven Defense® model. This model is described in the official document “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains.”

According to the document, the Cyber Kill Chain® consists of the following seven stages:

1. Reconnaissance
2. Weaponization
3. Delivery
4. Exploitation
5. Installation
6. Command and Control
7. Actions on Objectives

Let’s take a closer look at each stage.

Reconnaissance with Mimikatz

In this stage, attackers gather information about the target by researching websites, social networks, and the target infrastructure, especially its public parts. During this stage, ransomware operators might communicate with initial access brokers to gather information about the future victim’s revenue to determine the ransom amount.

This stage is often underestimated. Attackers may spend weeks, months, or even years researching potential victims. This is not only to get a comprehensive external picture but also to study the business characteristics of the target enterprise.

Weaponization of Mimikatz

The Lockheed Martin document describes the process of preparing a malicious file that is then delivered via targeted phishing. Additionally, ransomware operators might need to exploit vulnerabilities to gain initial access, escalate privileges, or perform lateral movement. They also prepare and configure servers (e.g., Cobalt Strike) and select appropriate tools for the planned attack.

Delivery of Mimikatz

In this stage, malicious tools are delivered to the target system. The document describes the methods used for this purpose.

This stage can be divided into two parts. Ransomware operators might need to deliver a bot, remote access tool (RAT), or web shell to gain initial access. After post-exploitation and data theft, they need to deploy the ransomware.

In some cases, this stage might involve a separate attack team, including initial access brokers.

Delivery is part of the attack lifecycle. Another common method is to install an additional backdoor before deployment. As we have seen, most modern attackers do this to ensure they do not lose connection or get blocked.

Exploitation Using Mimikatz

This stage usually involves exploiting vulnerabilities to launch tools.

Of course, you remember vulnerabilities related to Microsoft Office, Microsoft Exchange, and other programs, but besides that, attackers might exploit human vulnerabilities, using various phishing-based methods.

Additionally, especially during ransomware deployment, attackers might use various built-in functions and “living off the land” tools, i.e., existing functionalities in the compromised system, to bypass protections and operate covertly.

Installation

In this stage, attackers must install the delivered tools on the compromised system to ensure subsequent access. This involves not just a software backdoor but a wide range of tools. Attackers might use credentials for public servers, organize VPN access to the compromised network, install legitimate remote access software, etc.

Notably, multiple tools and multiple work directories might be installed at this stage, including decoy directories created to divert the attention of incident response experts, aiming to mislead them away from the main tools.

Command and Control with Mimikatz

After successful installation, attackers need to ensure they can interact externally with the compromised host.

As you know, ransomware operators might use various tools and techniques: bots, RATs, web shells, and even legitimate remote access software. The specific communication channel used mainly depends on the attacker’s preference.

Actions on Objectives

This stage describes all actions taken by attackers to achieve their goals. It covers the entire post-exploitation process, which might include privilege escalation, credential harvesting, lateral movement, data exfiltration, and ransomware deployment.

Although the Cyber Kill Chain® was developed early on, it is now somewhat outdated as it mainly describes the initial stages of an attack. Let’s look at a more modern version—MITRE ATT&CK®.

MITRE ATT&CK®

ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. It was developed and is maintained by MITRE, with contributions from the global cybersecurity community.

We have already mentioned this knowledge base in this book. I recommend reading the “MITRE ATT&CK®: Design and Philosophy” document.

MITRE ATT&CK® describes 14 adversary tactics:

1. Reconnaissance
2. Resource Development
3. Initial Access
4. Execution
5. Persistence
6. Privilege Escalation
7. Defense Evasion
8. Credential Access
9. Discovery
10. Lateral Movement
11. Collection
12. Command and Control
13. Exfiltration
14. Impact

Let’s take a closer look at each tactic.

Reconnaissance with Mimikatz

Resource Development

This is a separate stage where attackers prepare the infrastructure: configure servers, register domains, prepare phishing emails, acquire ransomware or other malicious software and tools from third-party vendors, etc.

Initial Access

Attackers, including ransomware operators, might use various methods to gain initial access to the target network. As you know, they might exploit public-facing applications, conduct targeted phishing attacks, and abuse remote access services or trust relationships to move from one compromised network to another.

During the attack lifecycle, attackers need to execute various commands and binaries. These might be tools loaded and launched via malicious macros embedded in Microsoft Office documents, various reconnaissance commands executed via web shells, or ransomware binaries launched on remote hosts via PsExec.

Persistence

Attackers need to maintain their foothold. To ensure subsequent access to the compromised network, they might use legitimate remote access software or more traditional methods like editing the registry or creating scheduled tasks to maintain access after a reboot.

Privilege Escalation

In many cases, to effectively conduct post-exploitation operations, attackers need to escalate privileges. Ransomware operators might exploit various misconfigurations and vulnerabilities, as well as certain persistence methods, to achieve this.

Defense Evasion

Deploying ransomware without disabling security products installed on the target network is nearly impossible. Moreover, throughout the attack lifecycle, attackers need to avoid detection, so they obfuscate/encrypt their tools, delete evidence and log files to make the investigation and response process more difficult.

Credential Access

During the attack lifecycle, ransomware operators often need access to various servers, for example, for data exfiltration or backup deletion. To do this, they need the corresponding credentials. As you know, attackers can obtain these credentials by dumping them from memory, extracting them from various password stores, or performing kerberoasting attacks.

Discovery

To extract the most sensitive data and deploy ransomware on as many hosts as possible, attackers need to find information about installed software, accounts, shared network resources, and remote hosts.

Lateral Movement

Ransomware operators mainly target enterprise networks, so they need to move from one compromised system to another. In most cases, they use legitimate credentials and protocols like RDP and SMB.

Collection

To steal valuable data and upload it to a data leak site (DLS), attackers first need to collect it. They might extract data from local systems, shared network drives, emails, and other confidential data sources.

Command and Control with Mimikatz

To avoid detection during interaction with compromised systems,

Initial Access

In the first phase, the steps taken by attackers to gain access to the target system or network are described.

The lifecycle starts with researching the target (reconnaissance). Then, attackers need to prepare the infrastructure: malware (including ransomware) and other tools, as well as command and control infrastructure (weaponization). If certain objects, such as malicious documents, are used during weaponization, they need to be delivered to the target (delivery). Attackers must trick the victim into downloading and opening the malicious file (social engineering) or exploit vulnerabilities to initiate (exploitation). After launching the malicious object, attackers may need persistent access to the compromised system (persistence). To begin operations, attackers must bypass security measures (evasion) and continue interacting with the compromised system (command and control).

Lateral Movement

Once ransomware operators have a foothold in the target system, they can prepare to move to the next stage—lateral movement.

Attackers need to gather information about the compromised system to understand the current privileges and access levels (discovery). If privileges are insufficient, attackers may exploit vulnerabilities to escalate privileges (privilege escalation). With elevated privileges, ransomware operators can execute arbitrary code on the compromised system (execution). The ability to execute arbitrary code allows attackers to obtain credentials (credential access). With the appropriate credentials, ransomware operators can discover remote hosts (discovery) and begin lateral movement (lateral movement) to proceed to the target action.

Target Action

With the appropriate credentials and lateral movement capabilities, ransomware operators can move to the final stage—target action.

As you know, one of the main goals in most human-operated ransomware attacks is to obtain valuable data. Once this data is discovered, it is collected (collection) and exfiltrated (data exfiltration). After the data is exfiltrated, attackers can proceed to the final stage—deploying ransomware (impact).

We have examined different attack lifecycles; now let’s construct our own lifecycle—the Unified Ransomware Kill Chain.

Unified Ransomware Kill Chain

Through this book, you have learned a lot about ransomware-related cyber threats and examined the most common methods used by attackers. Now that you have a clear understanding of human-operated ransomware attacks, we are ready to construct our own lifecycle—the Unified Ransomware Kill Chain.

Gaining Network Access

Ransomware operators can gain access to the target network themselves or purchase access from initial access brokers. This can be access to a host within the network or access to the entire network via VPN credentials.

Methods for gaining access can range from common brute force attacks and phishing emails to more sophisticated supply chain attacks.

Preparing Attack Development

This stage can include various activities: gathering information about the compromised host, looking for privilege escalation and credential access methods, and disabling or evading security measures to start reconnaissance and lateral movement.

Additionally, attackers may need to establish persistent and backup access to the compromised system.

Network Reconnaissance

Before starting lateral movement, attackers need to gather information about remote systems to understand which targets to focus on first.

Discovering Key Objects

Not every host is equally important to attackers. They mainly focus on objects that can provide more privileged credentials, valuable information, and access to backups.

Lateral Movement

To access the most valuable objects, ransomware operators need to move laterally within the network. As you know, they often use legitimate tools and methods for this purpose.

Data Exfiltration

Sometimes ransomware operators steal data from a single host, such as a file server, and sometimes they collect and exfiltrate data from multiple sources. In some cases, these operations can last for months or even longer.

Typically, modern ransomware attacks are accompanied by data exfiltration, but sometimes attackers skip this stage.

Preparing Deployment

Attackers need to disable security products installed in the compromised network and delete data backups. This is done before deploying the ransomware.

Deploying Ransomware

At this stage, attackers aim to achieve their main goal—deploying ransomware. It is worth noting that in some cases, they do not even use malicious code but instead use legitimate tools (such as BitLocker and DiskCryptor) to encrypt data.

Most ransomware is very conspicuous, so attackers try to find new ways to bypass defenses.

Extortion

Encrypting the entire network and waiting for the victim to respond may not be efficient, so ransomware-related personnel have invented new methods to speed up the process. They may post samples of stolen data on data leak sites, call the victim’s employees, or even launch DDoS attacks on the already compromised infrastructure.

The three stages of the unified lifecycle are interconnected, as ransomware operators may perform the same operations on multiple hosts.

Incident response teams can use this lifecycle to reconstruct attacks during incident response and structure the final report to ensure each attack stage is clearly described with sufficient evidence.

Conclusion

Now you have learned a lot about modern ransomware attacks and know how to detect and track various cyber threat intelligence sources.

Understanding the ransomware attack lifecycle, you can use different models, including the Unified Ransomware Kill Chain, to reconstruct these attacks. Additionally, you now know how to use the most common forensic evidence to complete this task.

I hope this book not only helps you respond to incidents but also gives you a better understanding of the current threat landscape related to human-operated ransomware attacks.

One final important tip: do not limit yourself to the forensic evidence described in this book. Third-party information sources like SIEM and XDR are also very useful. Use as much data as possible; this will help you reconstruct attacks in detail and establish appropriate defenses to protect your (or your client’s) network from similar threats.

Recommended Books

• Cybersecurity: The Game Rules: How Managers and Employees Influence Company Security Culture
  • Author: Allison Cerra
• Big Brother is Watching: How to Protect Yourself in the Digital World
  • Author: Mikhail Reitman

Ransom Note Example

1. What happened to your files?
   • All your files have been encrypted using the RSA-2048 algorithm—search for “RSA encryption” on Google.
   • How to recover files?
     • RSA is an asymmetric encryption algorithm. You need one key for encryption and another key for decryption. This means you need the private key to recover your files.
     • Without the private key, it is impossible to recover the files.
   • How to obtain the private key?
     • To obtain the private key, follow these three simple steps:
       1. Pay 1.7 Bitcoins per infected computer, or 28 Bitcoins for all infected computers.
       2. After paying 1.7 Bitcoins, leave a message on our website with your hostname.
       3. We will send you the decryption program. Run it on the infected computer, and all encrypted files will be restored.
     • Our website:…
     • Our Bitcoin wallet:…
     • If you pay 28 Bitcoins for all infected computers, leave a message on the website saying “for all infected computers.”
     • You can also pay 14 Bitcoins to get 14 keys (randomly), and after verification, complete the payment to get the remaining keys.
   • How to access our website?
     • Download and install the Tor browser, and enter our website address in it.
     • Link to download the Tor browser:…
     • See Google “how to open onion websites.”
   • Test Decryption
     • You can download two encrypted files from our website, and we will decrypt them for you.
   • Where to buy Bitcoins?
     • We recommend buying Bitcoins with cash or through Western Union, as these methods do not require verification and are fast.
   • Deadline
     • If Bitcoins are not paid within seven days, we will delete your private key, and the files will be unrecoverable.
2. Your network has been compromised.
   • All files on each host have been encrypted using a secure algorithm.
   • Backup files have been encrypted, deleted, or backup disks have been formatted.
   • We have unique software to decrypt your files.
   • Do not restart or shut down your computer—this may damage the files.
   • Do not rename encrypted files or readme files.
   • Do not move encrypted files or readme files.
   • Do not delete readme files.
   • This may result in some files being unrecoverable.
   • To get payment information for decrypting files, contact us at the following address:…
   • BTC wallet:…
   • To ensure our sincerity:
     • Send two different random files, and we will decrypt them for you.
     • To ensure we can decrypt all files, you can send files from different computers in the network.
     • The two files must have a .LOCK extension. We will unlock two files for free.
3. Instructions
   • Download the Tor browser.
   • Open the link through the Tor browser:…
   • Fill out the form, your password is:…
   • We will contact you as soon as possible.
   • Always send files for test decryption.
4. Here is some personal information from companies compromised by DoppelPaymer. These companies decided to keep the leak secret. Now their payment time has expired.
5. Information about the Kaseya attack
   • On Friday (July 2, 2021), we attacked an MSP provider. Over a million systems were infected. Our decoder’s full price is 70 million dollars in Bitcoin, under these conditions, we will publicly release the decoder, making all affected files recoverable within an hour. If you are interested in our offer, please follow the instructions in the readme file on the affected devices to contact us.

Post Views:403 Appreciation