Chapter 11: Investigating Ransomware Deployment Techniques

The main goal of a human-operated ransomware attack is to encrypt as much data as possible. In many cases, the threat actors use various ransomware families obtained via ransomware-as-a-service programs or developed by some of the team members. At the same time, in some cases, they may use legitimate software for encryption. Common examples are BitLocker and DiskCryptor.

Usually, at this point, ransomware affiliates have full control over the compromised network: they collected information about the available hosts, obtained elevated credentials, removed backups, disabled security products, and placed backdoors for redundant access.

In this chapter, we'll look at the most common techniques leveraged by threat actors to deploy ransomware in enterprise networks, and also briefly discuss the process of ransomware analysis.

We'll cover the following topics:

• Investigation of abusing RDP for ransomware deployment
• Investigation of abusing Administration shares for ransomware deployment
• Investigation of abusing Group Policy for ransomware deployment

Investigation of abusing RDP for ransomware deployment

You are already well aware of the fact that many threat actors involved in human-operated ransomware attacks attack public-facing Remote Desktop Protocol (RDP) servers to obtain the initial access. What's more, remote services and especially RDP is one of the most common techniques employed by ransomware affiliates for lateral movement. Unfortunately, many system and network administrators use it as well on a daily basis, so all the threat actors need is to get proper credential material.

So it shouldn't be a surprise to you that many ransomware affiliates abuse RDP to deploy ransomware as well.

In fact, in most cases, your investigation starts from the last stage of the attack life cycle – ransomware deployment. So the first thing you should do is to understand how the ransomware was deployed and what the source of infection was.

It's very common for modern ransomware to change encrypted files' extensions as well as to create files with instructions for the victim. It's quite a good idea to start from Master File Table (MFT) analysis so you can try to identify the first pivot point – the start of the encryption process.

Figure 11.1 – Files with decryption instructions created by ransomware

As you can see in the preceding screenshot, the encryption process started on November 14, 2021, around 10:37 (UTC). The piece of ransomware created multiple files named how_to_decrypt.hta – these files contain instructions for the victim on how to contact the threat actors in order to pay the ransom and receive decryption software.

Let's try to identify the ransomware executable. We can scroll the timeline up to the first created file. Here we can see a very suspicious Prefetch file:

Figure 11.2 – A Prefetch file potentially related to ransomware

I hope you remember that ransomware affiliates often remove their toolset from the compromised hosts. The same can be said about ransomware itself – many samples are capable of self-deletion. But still, in many cases, we have a wide variety of sources of evidence of execution. These artifacts often allow incident responders to identify malicious and suspicious executables used by the threat actors.

In this case, we don't have a malicious executable itself, but have a Prefetch file, pointing to a very suspicious file execution right before the start of creation files with instructions. Looks like the file was named .cr_hand.exe – not a very common name.

Another question you should try to answer is how the threat actor executed a piece of ransomware on the host or hosts. If we are talking about RDP, in most cases ransomware affiliates just copy a malicious file to the target host and execute it manually. What does it mean? We should have appropriate artifacts in NTUSER.DAT, for example, UserAssist:

Figure 11.3 – Relevant UserAssist records extracted with RegRipper

Now we can understand that the file in question was executed at 10:30:27 (UTC). But also we can see a few more records of interest.

The first one is NS.exe – a very popular tool among those ransomware affiliates focused on RDP compromise. This small utility allows the threat actors to find and mount available network shares and unmounted local drives.

The next is Everything.exe. It's a legitimate program for file indexing and searching, which is commonly used by ransomware affiliates for reconnaissance, so they can understand which files are available on the compromised host and how large they are.

OK, we've identified additional software used by threat actors, and we've also identified the account used for deployment – SigmA0. But we still need to make sure .cr_hand.exe is a ransomware sample.

Let's look at another evidence of execution source – Amcache. It's very interesting in our case as it contains SHA1 hashes among other data, so we can use it for malicious file identification.

Figure 11.4 – Malicious file information extracted from Amcache

Now we have hashes, so even if it's not possible to recover deleted executables, we still have a chance to identify them. As there are quite a few various online services focused on automatic malware analysis, we can use the obtained hashes to search our suspicious files there. A good example is VirusTotal – a service we discussed previously:

Figure 11.5 – Information on suspicious file detections

The most interesting detection is Ransom.Crylock as it sheds light on the ransomware family we are dealing with, which is Crylock.

One important note about using online services for malware identification – using hashes is safe, but you should never upload a ransomware sample yourself without proper analysis as it may contain information that can be used by the third party to identify the victim. For example, many samples have custom ransom notes (files with instructions for victims) with the name of the compromised organization.

Now we know for sure that the file we identified is a ransomware sample. Also, we know that it was executed manually by the user SigmA0, but how did the threat actor get onto the compromised host?

If we look into Windows event logs, we can see a record showing a successful RDP connection right before Crylock ransomware was executed on the host:

Figure 11.6 – Information on a successful RDP connection obtained from Windows event logs

In this case, it's an external address, so we can see that the compromised host was public-facing. The same can be observed with local IP addresses – ransomware affiliates can jump from the initially compromised host to other hosts in the network using RDP and execute ransomware on each of them.

Let's look at the Crylock ransomware.

Crylock ransomware overview

Before starting the encryption process, Crylock stops a number of services and kills a number of processes from a built-in list.

Then it removes shadow copies and backups to inhibit system recovery:

"C:WindowsSystem32cmd.exe" /c "vssadmin delete shadows /all /quiet"

"C:WindowsSystem32cmd.exe" /c "wbadmin DELETE SYSTEMSTATEBACKUP -keepVersions:0"

"C:WindowsSystem32cmd.exe" /c "wbadmin DELETE BACKUP -keepVersions:0"

"C:WindowsSystem32cmd.exe" /c "wmic SHADOWCOPY DELETE"

"C:WindowsSystem32cmd.exe" /c "bcdedit /set {default} recoveryenabled No"

"C:WindowsSystem32cmd.exe" /c "bcdedit /set {default} bootstatuspolicy ignoreallfailures"

vssadmin delete shadows /all /quiet

wmic SHADOWCOPY DELETE

To encrypt files, it uses a custom symmetric cipher, and the RSA algorithm to encrypt the key.

Crylock drops a ransom note named how_to_decrypt.hta, which contains the threat actors' contact details and instructions.

Of course, deploying ransomware manually isn't very effective, especially if the threat actors plan to deploy it on hundreds or thousands of hosts. That's why they also use other techniques, for example, abusing Administrative shares.

Investigation of Administrative shares for ransomware deployment

We have already discussed how ransomware affiliates may abuse Administrative shares to enable lateral movement. The same technique can be used by threat actors for ransomware deployment. A good example is PsExec. Some affiliates use pre-made batch files in order to copy a ransomware executable to the target hosts and then execute it with help of PsExec.

It's not the only technique that exploits Administrative shares, of course. Let's look at another example, and start from the MFT-based timeline one more time:

Figure 11.7 – Ransom notes created on the compromised host

On the preceding screenshot, you can see a bunch of ransom notes created by a malicious executable, and also a suspicious Prefetch file.

When we are talking about Administrative shares abuse, a very common artifact you should always focus on is a service installation event. You can find it in System.evtx Windows Event Log file – ID 7045:

Figure 11.8 – Ransom notes created on the compromised host

Here we have evidence that the suspicious file, msedgeupdater.exe, was executed from the host srvdc01, which is most likely a domain controller, via the creation of a new service.

OK, ransomware affiliates compromised one of the domain controllers during lateral movement activities and used it to deploy ransomware – a very common story if we are talking about human-operated ransomware attacks.

As most likely the service was created remotely, we can focus on events in the Security.evtx Windows event log, so we can reveal logon activity:

Figure 11.9 – Logon activity related to ransomware deployment

We can see that the threat actors used the Administrator account in order to deploy ransomware from the domain controller via remote service creation.

But we still haven't identified the ransomware strain. We have already used hashes for identification, but let's change tactics and focus on other artifacts created by the ransomware sample.

In many cases, the easiest way to identify it is to look into the ransom note:

Figure 11.10 – A part of the ransom note created by the ransomware sample

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

To identify the ransomware, it may be enough just to google one of the links:

Figure 11.11 – An example of search results

Based on search results, we can assume that we are dealing with REvil (Sodinokibi) ransomware.

Also, as many ransomware samples modify the registry, we can focus on unique keys and values. As we know that encryption took place on June 27, 2021, we can check for newly created or modified keys on this date.

Figure 11.12 – Suspicious registry key created after ransomware execution

If we look through the keys modified on the date of interest, we can see a very suspicious key named BlackLivesMatter. If we run a quick search using open source data, we can find a report by the BlackBerry Research & Intelligence Team on REvil ransomware, which mentions this key:

Figure 11.13 – An excerpt from the BlackBerry Research & Intelligence Team on REvil ransomware

So, we have enough information to understand that we are dealing with REvil ransomware, so it's high time to look at the sample itself.

REvil ransomware overview

First, REvil collects information about the system and fingerprints it. Before starting the encryption process, it kills a list of processes according to its configuration.

Configuration data is stored in resources in encrypted form. The key is 32 bytes long and located before the encrypted data:

Figure 11.14 – The key used to encrypt configuration data

Once the processes are killed, it removes shadow copies, so they can't be used for data recovery.

It encrypts files using curve25519/Salsa20. The key is encrypted with curve25519/AES-256-CTR. REvil adds a custom extension to encrypted files, for example, .1qu4746az.

It also changes the desktop wallpaper (dropped to the %Temp% directory) and creates ransom notes in all directories with encrypted files.

To achieve persistence, REvil modifies the SOFTWAREMicrosoftWindowsCurrentVersionRun registry key.

Abusing Administrative shares isn't the only technique used by threat actors to deploy ransomware enterprise-wide. Another common example is Group Policy modification.

Investigation of Group Policy for ransomware deployment

Another technique that's becoming more and more common among ransomware affiliates is Group Policy modification for ransomware deployment.

In most cases, the network is fully compromised, so it's not a big deal for the threat actors to move laterally to a domain controller and abuse Group Policy to execute ransomware enterprise-wide.

What's more, some ransomware samples have built-in capabilities to use Group Policy modification for self-distribution. A good example is LockBit ransomware.

You can use a similar technique we covered previously: find the first ransom note and start checking what happened before it was created. In this case, we can see that a very suspicious Group Policy Object (GPO) was created:

Figure 11.15 – Group Policy Object created by LockBit ransomware

As we can see, there's a new object created with the Globally Unique Identifier (GUID) {E97EFF8F-1C38-433C-9715-4F53424B4887}. What's more, there's a quite suspicious file, 586A97.exe, in the C:WindowsSYSVOLdomainscripts folder.

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

<NTService clsid="{AB6F0B67-341F-4e51-92F9-005FBFBA1A43}" name="SQLPBENGINE" image="4" changed="2022-01-16 14:15:49" uid="{94D8973D-A08E-4F28-B7D7-3745321C40A4}" disabled="0"><Properties startupType="DISABLED" serviceName="SQLPBENGINE" serviceAction="STOP" timeout="30"/></NTService>

The next file, Files.xml, copies the suspicious file from the shared folder noted previously to the Desktop folder on the target host:

Figure 11.16 – The contents of Files.xml

The last file, ScheduledTasks.xml, is used to create a scheduled task in order to stop listed processes and start the ransomware executable:

Figure 11.17 – An excerpt of the processes list from ScheduledTasks.xml

Another notable file is Registry.pol. It contains information about registry modification in order to disable various Windows Defender features, so it can't interrupt the encryption process.

We can use the 586A97.exe hash to try to identify it:

Figure 11.18 – Detections of the suspicious file

So, now we can clearly understand that we are dealing with LockBit ransomware. If we keep forensically analyzing, we can look into PowerShell-related Windows event logs to find the following record:

Figure 11.19 – Suspicious record in PowerShell Windows event logs

Here we can see that LockBit abuses PowerShell in order to force the update of group policies.

OK, let's look at the LockBit ransomware.

LockBit ransomware overview

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

vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

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

It also changes the wallpaper to the following:

Figure 11.20 – LockBit 2.0 wallpaper

LockBit creates ransom notes in every folder with encrypted files. The ransom notes have the following name: RESTORE-MY-FILES.txt.

LockBit ransomware may also create a Group Policy object in order to disable antivirus software, kill a list of processes, and distribute itself.

Summary

Ransomware affiliates use various techniques to distribute malicious code enterprise-wide. It depends on their skillset and the target, of course.

In this chapter, we've looked at the most common techniques for enterprise ransomware deployment observed in current human-operated attacks and learned how to use various forensic artifacts in order to detect and reconstruct them.

As we've already learned a lot about how to respond and detect various techniques employed by the threat actors during human-operated ransomware attacks, it's high time to sum it up and introduce the unified ransomware kill chain.

In the last chapter, we'll dive into various kill chains including the Cyber Kill Chain, the Unified Kill Chain, and MITRE ATT&CK, and build a new one with ransomware in focus – the Unified Ransomware Kill Chain.