Blog.

Introduction

Although in itself referencing quite a specific subsection of malware, ransomware is a term that can refer to an enormous variety of malicious software. From simplistic viruses with little to no defense evasion to advanced threats featuring heavy anti-analysis and anti-sandboxing tricks, the world of ransomware is as varied as it is lucrative for the cybercriminals behind it.

Fortunately, there are many common denominators in the behavior of all ransomware families, which help us in our efforts to detect and categorize these samples. This mini-series of blog posts will aim to outline how behavioral analysis can be a powerful tool in detecting and protecting against these threats and will provide an overview of how this works in practice using our Triage sandbox. In part 1, we will briefly go over some generic techniques which are not specific to any particular family, with more technical descriptions provided in future case studies of some, particularly interesting variants.

Ransom Notes

Practically all ransomware will create readable files in noticeable locations, which serve to inform the system owner they have been infected and instruct them on how to pay the ransom demand. As such, these files can often contain easily recognizable information, which can help to identify details of the infection such as family and version, as well as useful information for further investigation like bitcoin payment addresses and contact information.

As a method of protecting a live system, this approach obviously has limited value as generally ransom notes will only be created after the encryption process. However, as a method of detecting ransomware in a sandbox environment, this has some real value.

Ransom notes are not intended to be hidden - they often follow very distinct naming conventions and multiple copies are created throughout the file system. Some example file paths are listed as follows.

Most families of ransomware have a specific way of dropping these ransom notes and employ very distinct wording within the files (often even including the family name), making them a very useful method to categorize and identify samples.

Using the image above as an example, not only is the note extremely recognizable, but it also includes the personalized links created for each infection that victims would need to visit to pay the ransom. In other cases, it often includes a Bitcoin wallet address to be used for payment, or email addresses to contact the operators directly. This is all useful information to gather up when investigating ransomware campaigns, and which is often only accessible during dynamic analysis of a sample.

In a sandboxed environment, we have clear visibility on the files created and modified by a sample. By checking the contents of these files - especially the opening bytes, which as in the example above, often include identifying or unique information - we can identify which of these are ransom notes and dump them for further analysis.

Once relevant files have been found, it is simply a question of parsing the contents to extract whatever useful information is available.

Preventing system recovery

Deleting shadow copies

Shadow copies are a backup feature first introduced in Windows Server 2003. Initially, they functioned by tracking filesystem changes over time, enabling recovery of files at each modification, not unlike SCM solutions such as git. The term has now expanded to include multiple modes for creating these shadow copies, including the capability to create full ‘snapshots’ of a filesystem at a particular point in time. These ‘backups’ are created using techniques intended to minimize the time and disk space consumed by the process - the differential technique especially can provide backup functionality with far smaller storage requirements than a traditional full-disk copy.

Shadow copies are, by default, created when Windows creates a system restore point - a process that occurs in many systems as a daily task.

Whichever creation mode is used, shadow copies are now central to the built-in Windows backup and recovery tools, making them an obvious target for ransomware to make it harder for victims to recover from an infection without paying the ransom.

In practice, this is generally achieved through one of two (or both) Windows commands - vssadmin or wmic.

• vssadmin delete shadows /all /quiet
• wmic shadowcopy delete /nointeractive

These are easily detected during dynamic analysis, as they both create new processes rather than being internal commands. WannaCry is an excellent example of this functionality, as it includes both methods.

Disable recovery mode

Windows recovery mode enables users to access safe boot, and most of the built-in system restore features, including repairing a Windows installation from a recovery device. Many ransomware families will disable this mode to make recovery harder. As recovery mode is accessed when booting the system, this is disabled by editing the boot configuration settings using the bcdedit utility.

bcdedit /set {default} recoveryenabled no

This feature can commonly be seen in many families such as Phobos, WannaCry, and Cerber, although it is not as common as shadow copy deletion.

Delete backups

In addition to the shadow copy approach already discussed, Windows includes support for full-disk backups that take a copy of the entire filesystem state. As mentioned previously, these are far larger and more resource-intensive to create and store, so they are less common as an automatic process on most systems. However, they are another obvious target for anyone attempting to hinder system recovery.

These backups are accessed through the Windows Backup tools - through the command line; this means the wbadmin utility.

wbadmin delete catalog -quiet

This feature is present in most significant malware families as if used Windows Backup is an extremely easy way to bypass the ransom payment.

Clear logs

Although of limited value in the recovery process, some forms of ransomware also opt to destroy some system event logs during the infection process. This operation is less common than those discussed already, and is less specific to ransomware, but is worth covering briefly here for completeness.

The wevtutil command is provided in Windows to interact with the event logs via CLI, and malware can leverage this to clear logs. For example, the Zenis ransomware discovered in 2018 by MalwareHunterTeam uses this to clear all of the main Windows event logs -

• cmd.exe /C wevtutil.exe cl Application
• cmd.exe /C wevtutil.exe cl Security
• cmd.exe /C wevtutil.exe cl System

Presumably, this is intended to make it harder to analyze the origin of the infection but also functions as a clearly malicious attempt at hiding activities which is very visible during dynamic analysis.

The full report for this Zenis sample is available at https://tria.ge/reports/191030-4jjvvmbgys

Changing desktop wallpaper

Many varieties of ransomware modify the desktop wallpaper in some way - generally either by generating a bitmap image dynamically using a function like DrawText or setting it to an image bundled in the payload.

The usefulness of this action is limited, as the text content of the wallpaper is normally based on the ransom notes also dropped. It is, however, an unusual action for non-ransomware to perform, so it can be useful in automatically classifying a sample.

If the wallpaper were of specific interest, it would also be possible to hook the relevant APIs (like DrawText) to intercept the content being written to the image or employ a technique such as OCR to parse a pre-existing image. However, as mentioned, it is generally easier to get this information from the ransom notes.

File operations

The techniques covered so far have all been extremely specific - individual interactions that can be detected during dynamic analysis. This section is a little less defined but attempts to identify a ransomware infection by looking at patterns in file operations carried out on a system.

This approach specifically targets the encryption algorithm of the ransomware, which generally follows a clear process:

1. Enumerate files in a folder
2. Read and encrypt content of each file
3. Write encrypted content back to file, either overwriting the original or creating a new file
4. Clean up by removing the original file if not overwritten, or renaming the encrypted file to fit the ransomware’s naming convention.

When ransomware renames a file to include its specific file extension etc., it is actually performing a file move operation. If this is carried out for every file on a normal system this will involve large numbers of almost identical operations - potentially thousands of them - making it an extremely noisy process.

File moves can be carried out through a few different APIs. The most basic uses the MoveFile functions, passing a source and destination path. Other implementations may abstract this process a little, copying the contents of a file using ReadFile and then creating a new one with the amended filename using CreateFile to which it writes the now-encrypted file content.

As an example of the latter process, examining a WannaCry sample in Procmon shows patterns like the following -

Monitoring analyses for large numbers of file writes like this can be a good way of detecting ransomware of all kinds. If these APIs can be hooked during the analysis process, it is also possible to examine the buffers to confirm that encryption is taking place and eliminate the possibility that these are benign file operations.

Alternatively, another way to verify that these are likely operations coming from ransomware is by examining the file types that are written by the sample. Where the original files will have discernible headers, which programs like file can read to identify the file type, the post-encryption version will no longer have these distinguishing features, meaning that they will be detected as data or some similar, generic type. A sample which dumps large numbers of files with unrecognizable MIME types is likely a good indicator of the presence of a ransomware cryptor.

Conclusion

We hope this blog post has given a basic introduction to detecting ransomware in a dynamic environment. However, the general behavior is only part of the picture, and individual families generally contain far more functionality than outlined above.

This blog is the beginning of our mini-series on ransomware and more blogs will be released over the coming weeks. Watch this space for future blog posts in which we will examine some major ransomware families and look at ways of detecting and classifying those. We will also take a closer look at the configuration and ransom note extractors built into Triage and how these can automate the collection of useful information from malware campaigns.