Ransomware: Too Overt to Hide [Part 2]
Find more details on this series in Part 1.
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.
Analysis overview of a website infected with RIG EK
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:
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.
Analysis overview, GoldenEye
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
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 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:
Sage 2.0 ransomware: checking whether the application is running with elevated privileges
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.
Latest posts by Alexander Sevtsov (see all)
- Evasive Monero Miners: Deserting the Sandbox for Profit - June 20, 2018
- I Hash You: A Simple But Effective Trick to Evade Dynamic Analysis - April 10, 2018
- Olympic Destroyer: A new Candidate in South Korea - February 21, 2018
Latest posts by Clemens Kolbitsch (see all)
- Ransomware: Too Overt to Hide [Part 2] - April 13, 2017
- Party like it’s 1999: Comeback of VBA Malware Downloaders [Part 3] - November 10, 2016
- Lifting the Seams of the Shifu “Patchwork” Malware - September 4, 2015