Ransomware is holding a tight grip on its victims and their most valuable data. As we already covered in Part 1 of this blog series, this type of malware uses two different delivery mechanisms to target users, and it uses different techniques, such as obfuscated scripts, to evade traditional security solutions.

In this second part of the series, we dive into how ransomware works: while each family has its unique characteristics, they all share the common goal of infecting the victims and locking them out of their data — demanding a ransom for undoing the damage. By understanding this common behavior present in all ransomware families, the Lastline analysis system is able to classify attacks belonging to this type of malware and to protect users from falling into the ransom trap.

Catching Ransomware on the Wire

The most commonly used infection vectors used by ransomware are email attachments, links in emails, compromised websites, and malvertising. The first type, attacks via email attachments, can be intercepted by a security or gateway appliance before a user even receives the lure – we have described this attack previously in a series of blog posts on VBA-based malware downloaders.

When an attack is using known compromised or malicious websites, it can be trivially blocked by looking at the domain or IP used in the link embedded in the email or the URL visited by a user. In practice, however, simple blacklisting approaches suffer from the relatively short lifespan of these drive-by landing pages.

To cope with this problem of blacklisting short-lived content, security solutions must find the attack “on the wire”. This means that the system either proactively probes for the content of a website or it waits until a real user is tricked into following the link to the exploit site and finds the attack in the live traffic.

One way this can be done is finding suspicious modifications of web page content, such as the use of inline frames with hidden attributes or obfuscated JavaScript. When such an anomaly is found in a page in transit, a security appliance can block a user from accessing any further content from this site. This prevents Exploit Kit (EK) code from reaching and exploiting a user’s browser.

However, not all attacks make use of exploit kits: often, victims are simply tricked into downloading and running the ransomware payload, as we have already described in the first part of the post:

Ransomware using social engineering attack

Thus, a security appliance needs to intercept these downloads and evaluate if the file is safe to be opened by a user – typically by running the program inside a sandbox.

Catching Ransomware in the Sandbox

Practically all ransomware attacks share certain features that allow classifying this specific type of attack quite reliably. We divide these common characteristics into two basic groups, core, and extended behaviors, that we will describe in more detail below:

The core characteristics are those actions that need to be performed by ransomware to be functional. Typically this means finding the user’s valuable data, building an encryption key sent to the attacker’s C&C server, encrypting the data, and demanding a ransom for restoring the files. We will dive into this group in more detail below.

The extended characteristics include those behavior patterns that allow the malware to execute the core characteristics while remaining undetected by a security solution that may prevent data encryption. This group will be the focus of a follow-up post.

File Encryption Activity

The key component of any ransomware attack is to block access to important data. The most common way for finding which files to encrypt is by enumerating available drives (such as system, network, or removable drives) and targeting specific file extensions.

In early ransomware variants, encryption algorithms were often based on custom algorithms and symmetric-key cryptography. That is, very often, the attackers used the same key for encryption and decryption. Files encrypted by these variants have been easily restored by reverse engineers, who are able to provide decryption tools for each variant in a relatively short amount of time.

Unfortunately, ransomware authors learned quickly from their mistakes, and they have adopted the concept of “don’t roll your own crypto“. Most recent ransomware variants make use of asymmetric-key cryptography, where data is encrypted with one (public) key, but decryption requires a different (private) key, which is not accessible to the victim. This thwarts any attempts at providing per-variant decryption keys and guarantees that attackers can enforce getting a ransom paid for revealing the private key required for decryption.

For generating a key pair and binding the private key to a particular victim, ransomware commonly calculates a unique value called victim ID. This value is computed from information collected from the victim machine, such as locale information, default language identifier, OS version and type, username, volume GUID path, and current system time. This victim ID is then sent to the attacker’s server, which generates a public/private key pair derived from the victim ID and returns the public key to the running malware.

In the next step, the actual file encryption begins. Interestingly, symmetric-key cryptographic algorithms (such as AES, RC4, DES, or Blowfish) continue to be in use: very often, the encryption uses a unique key for each individual file – these keys are called session keys and are generated randomly. To keep them secret, they are encrypted using asymmetric-key algorithms (such as RSA or ECC) before being stored within the encrypted file. This type of encryption is called hybrid encryption: a shared secret is encrypted with the private key, which is generated on the attacker’s server and will never be accessible to the victim.

Some particular malware families, such as Petya and GoldenEye, which were recently observed attacking targets in Germany, do not encrypt a user’s files directly. Instead, these variants target the hard drive’s Master File Table (MFT), overwriting the NTFS Master Boot Record (MBR) with a custom boot-loader. This boot-loader encrypts entire hard drive sectors using the Salsa20 algorithm. The MFT is a record that stores different information about the files located on NTFS volumes, such as file location, data, permissions, and timestamps. Encrypting this metadata allows the attacker to render the victim’s system completely inaccessible.

Another family called Mamba, responsible for locking up the San Francisco Municipal Transport Agency at the end of last year, uses an open source tool called DiskCryptor to achieve full disk encryption. By using an existing system for the encryption, the malware authors can piggyback on well-tested, secure algorithms implemented by security experts, rendering practically any attempt at restoring files useless. Furthermore, the use of the well-known, trusted, and digitally signed DiskCryptor utility allows the attacker to use a signed kernel driver, which is essential for full disk encryption.

Regardless of the type of encryption, a final behavior common to all ransomware attacks is to prompt a note asking for the ransom. This can happen in multiple ways, including popup windows, opening browsers, or even setting up a new wallpaper to draw the victim’s attention. In many cases, this ransom is paid using a cryptocurrency (such as bitcoins) and via anonymity networks (instead of the regular internet) to hide the payment trace from law enforcement.

Cerber Ransomware Note

Defeating Recovery

Microsoft Windows provides various built-in mechanisms that allow a user to (at least partially) restore a system that was locked down as mentioned above. To prevent this from happening, ransomware very often deletes the Windows Shadow Copies and disables other recovery mechanisms, such as Startup Repair, Advanced Boot Options, and the Windows Emergency Management System.

Fortunately (for the user, not so much for the attacker), these operations require full administrative privileges on recent versions of Microsoft Windows (starting with Windows Vista). For this reason, malware checks whether it needs to request elevated permissions through the User Account Control (UAC) system, which is responsible for asking for user consent when running non-system executables.

The Sage 2.0 ransomware disables recovery using system tools vssadmin and bcdedit, and it implements the required permission checks as we can see below:

Sage 2.0 ransomware: disabling recovery with elevated privileges

Sage 2.0 makes sure that it can run properly on Windows Vista and later versions of Microsoft Windows by elevating its permissions if necessary. It checks whether the user is a member of the local Administrator group and retrieves process privilege details, by calling GetTokenInformation with parameter TokenElevation type (0x14). If elevating privileges is necessary and possible, the malware then starts the system tools by calling ShellExecute and passing the runas verb. Otherwise, it simply invokes the tools directly:

Sage 2.0 ransomware: invoking system tools with elevated privileges

The helper methods is_user_admin and is_elevated_process are implemented using the process security tokens:

Conclusion

Ransomware attacks are evolving. They are improving their cryptographic algorithms to address weaknesses of earlier variants and are working around security mechanisms built into Microsoft Windows.

Fortunately, all ransomware families share certain core characteristics that the malware has to implement to reach their goal and demand a ransom for unlocking the victim’s data. By looking for these behaviors, either on the network or inside an analysis sandbox, security solutions can detect these types of attacks and protect their users.

Alexander Sevtsov is a Malware Reverse Engineer at Lastline. Prior to joining Lastline, he worked for Kaspersky Lab, Avira and Huawei, focusing on different methods of automatic malware detection. His research interests are modern evasion techniques and deep document analysis.

Clemens is a Security Researcher and engine developer at Lastline. As a lead-developer of Anubis, he has gained profound expertise in analyzing current, malicious code found in the wild. He has observed various trends in the malware community and successfully published peer-reviewed research papers. In the past, he also investigated offensive technologies presenting results at conferences such as BlackHat.