Playing Hide-and-Seek with Ransomware, Part 1

• Intel SGX technology enables developers to isolate and encrypt a portion of code and data in the processor and memory in a trusted execution environment, known as an enclave.
• As enclaves are increasingly adopted to enable confidentiality-preserving applications, numerous researchers, including CrowdStrike, have asked the question of whether enclaves could be leveraged by ransomware authors to evade detection and ensure the decryption key cannot be retrieved by the victim after a successful attack.
• Numerous studies have investigated the viability of ransomware authors using enclaves for cryptographic key management. These studies underscore the significant complexity of executing this method as part of an attack, especially vis-à-vis more straightforward and proven alternatives, a likely contributing factor to the extremely low risk attributable to this tactic.
• The CrowdStrike Falcon®^® platform delivers unparalleled attack surface visibility for customers, including the attempted use of enclaves and related process behavior to rapidly detect malicious behavior and stop breaches.

At CrowdStrike, our mission is to stop breaches. To achieve this, we’re always on the lookout to defend customers against active attacks and preemptively protect them against emerging threats. 

In July 2021, researchers from Royal Holloway, University of London, published a white paper, “RansomClave: Ransomware Key Management using SGX,” that presents a novel ransomware based on an Intel feature called Software Guard Extension (SGX). The SGX technology aims to isolate a portion of memory from the rest of the system by encrypting it on a reserved part of the processor. 

This protected memory allows ransomware authors to manage their cryptographic operations without processing keys within the operating system’s memory, enabling them to evade forensic methods of key retrieval (e.g., memory dumps) and ultimately depriving victims of the means of retrieving their data after the attack. With SGX appearing to be such a highly effective method for ransomware authors, it stands to ask: Why does this model have such low prevalence in the wild? 

To answer this question, we will first examine how the Intel SGX technology works. We will present the challenges of key management that ransomware faces today and explain the extent to which enclaves provide a potential solution to this issue. In Part 2 of this blog series, we’ll dive into how ransomware using enclaves could be implemented and discuss the limits of this approach.

The CrowdStrike Falcon® platform sets the new standard in security. Watch this demo to see the Falcon platform in action.

Intel SGX 

The Intel SGX technology consists of a set of CPU instructions and structures released with the Skylake generation of Intel processors (launched in 2015). This feature provides a trusted execution environment (TEE) for Windows and Linux operating systems (OS) that allows kernel and user mode code to be executed within a protected memory context: an enclave. 

Architecture and Mechanisms

The enclave code is similar to the code of regular applications, with key differences in its loading method and execution context. Under the hood, the enclave code is stored encrypted in a dedicated part of the dynamic random-access memory (DRAM) called processor reserved memory (PRM). DRAM is a prevalent type of random-access memory (RAM), that differentiates itself from the static random access memory (SRAM) by its electronic composition. The enclave code encryption is based on the Intel Memory Encryption Engine (MEE), which uses keys generated at boot time and later stores them in the CPU. As the encrypted enclave pages can only be decrypted inside the CPU, the enclave code is inaccessible, even to code from ring-0. 

Executing within this environment prevents the enclave from accessing all regular processor instructions. This limitation includes instructions that may require privileges or execution-mode transition such as SYSCALL or INT, instructions that could result in a VMEXIT like CPUID, and I/O instructions such as IN or OUT (because errors they might cause can’t be handled in the TEE).¹ Furthermore, as far calls, far jumps and far ret are also illegal, enclaves executing any of the forbidden instructions will trigger a #UD (Undefined Instruction) error.

Still, the enclave may have legitimate cause to interact with OS-provided functionalities. To enable this, the architecture of applications using enclaves is divided into two parts: 

• The Trusted Space (the enclave): This is the portion of code and data isolated from OS and hypervisors.
• The Untrusted Space: This is also referred to as the classic core of the application, which is in charge of the enclave setup and serves as an intermediary between the enclave and the regular OS space.

This architecture supports the isolation of the enclave while enabling bidirectional communication with the regular cores of applications. To use enclave functionalities, the classic core of one application can invoke functions inside an enclave through what Intel calls an ECALL (“enclave call”). Similarly, to interact with the classic OS environment, enclaves perform an OCALL (“out call”) to the regular core of the applications, which passes it on to the OS. This enables enclaves to access the functionality they need through the classic core of the application. As ECALLs and OCALLs define the enclave’s boundaries, they need to be explicitly defined in the enclave’s source code (in an .edl file).

Figure 1. Basic architecture of applications using enclave

Enclave Signature 

To prevent malicious actors from exploiting enclaves, Intel has also integrated a signing requirement in the SGX architecture. While the enclave code can be locally compiled in debug mode without constraint, failure to comply with signing requirements will prevent the enclave load from compiling in release mode. For the sake of simplicity, we will focus here on the signing process for Intel Core processor-based platforms, as the process for Xeon platforms differs slightly.

In debug mode, a signing tool called sgx_sign is automatically run by Microsoft Visual Studio to allow the load of enclaves on a local machine. In release mode, things get trickier. The entity that develops the enclave, called the enclave signer, first needs to be allowlisted by Intel, which requires a signed Commercial Use License Agreement. Once the agreement is completed, the enclave is submitted to Intel for approval via  their Whitelist Registration Form. This form requires a hash of the enclave author’s public key, which is computed at the enclave load and is stored in the MRSIGNER register. If approved, this allowlisted signature allows one application to create, sign and use enclaves compiled in release mode with an enclave signing key. 

The signature embeds the hash result of the measurement of the enclave memory pages (code, data, stack, heap) and its metadata, which are computed at build time. Each time there is an attempt to load the enclave, the measurement is taken and the resulting hash is stored in the MRENCLAVE register. The value is then compared to the one embedded in the signature. If the results are inconsistent or if the enclave signer is not allowlisted, the load of the enclave is blocked.

For Intel, this enclave signing key both guarantees that the enclave is “safe” to be executed and doubles as a means for the enclave to further protect its secrets: with a process known as sealing. 

Sealing

From time to time, enclaves may need to access private data across reboots or share information with other enclaves. To support these scenarios, the Intel SGX technology created a process known as sealing. This operation allows enclaves to keep their data encrypted outside of the enclave boundaries and remain persistent across reboots. Sealing consists of an encryption process based on a value unique to the enclave, which is one of the two singing keys discussed in the previous section: the MRENCLAVE or the MRSIGNER. 

Sealing can either rely on: 

• The enclave identity, which is based on the MRENCLAVE value. As the MRENCLAVE value of one enclave remains the same across reboots, each enclave can use this value to access sealed data from a prior instance. 
• The signer identity, which is based on the MRSIGNER value. This allows two distinct enclaves developed by the same entity to share data, as long as they have the same author’s signature. This option also allows an application to use different versions of an enclave, a common requirement with software updates.

As data encryption happens inside the enclave, sealing allows data to be returned to the classic core of the application and safely stored for future use.

Why Ransomware Authors Use Enclaves 

As mentioned earlier, the SGX technology provides a trusted execution environment (TEE), one that can be used to support specific purposes. As this environment supports a very narrow scope of functionality — allowing little more than arithmetic operations — enclaves are primarily used for managing sensitive data, most notably cryptographic keys. The isolation of the enclave within the application architecture makes the enclave the perfect place to run cryptographic operations as it guarantees that cryptographic keys will be inaccessible for the rest of the system.

Brief Overview of Ransomware Key Management

One of the most challenging parts of writing secure cryptographic software is the creation, exchange and storage of cryptographic keys, a process collectively referred to as key management. Many early variants of ransomware families have vulnerabilities related to their key management. For example, an early version of Nemty passed an improper value within the dwflag argument to the function CryptAcquireContext, which instructed Windows to write the newly generated public and private RSA key to disk. What might seem like a minor flag passed as an argument led to an insecure cryptographic implementation; which gives victims a potential opportunity to recover the key needed to decipher their data.²

Most ransomware families use a combination of symmetric and asymmetric cryptography, but for our purposes we’ll focus on ransomware using only asymmetric encryption. A ransomware model that mixes both types of encryption would follow the same logic, so for the sake of simplicity we’ll detail only the asymmetric part. Within the context of asymmetric encryption, we’ll refer to the public key, which is used to encrypt the victim’s data, as Vpub, and to the private key, which is the deciphering key, as Vpriv. Assuming the deciphering key can be retrieved, we can consider that the key management in asymmetric cryptographic implementations will commonly occur via one of the following four scenarios:

1. Generate a pair of keys on the victim’s machine and send the private key to a command-and-control server.
2. Generate a pair of keys per victim on the attacker’s server and send the public key to the victim’s system for encryption.
3. Generate a pair of keys on the victim’s system, and encrypt the victim’s data with Vpub. Then, encrypt Vpriv with the attacker’s public key embedded in the binary and save it on the victim’s system.
4. Embed the public key in the malicious binary to use for encryption, and keep the private key on the attacker’s system.

Despite the range of approaches that ransomware authors could take, each of these scenarios has flaws that pose significant risks to the success of their attack.

In Scenario 1, keys are generated locally and the private key is extracted through the network. If the targeted system is offline, the encryption process cannot be performed as there is no way for the attacker to extract the private key. Furthermore, there are two potential means for forensic investigators to retrieve the deciphering key after a successful infection: through OS memory dumps or network traffic captures.

In Scenario 2, the attacker generates a pair of keys for each victim on the malicious server and sends the public key to each infected machine. This involves a setup of at least one malicious server with anonymity measures, but more importantly, has some important maintenance constraints. It requires constant monitoring to check the server is up and running to ensure that the victim’s infection process isn’t compromised. Furthermore, as with Scenario 1, the infection process requires victims to be online to successfully send keys.   

In Scenario 3, a pair of keys is generated on the local machine, and the private key is encrypted with the attacker’s public key embedded in the malicious binary. In this scenario, the private key will appear at some point as clear-text in memory and can therefore be retrieved with forensic methods. 

In Scenario 4, a ransomware campaign with one malicious binary encrypts the data of different victims with the same public key, which is embedded in the binary. Thus, if one victim is able to obtain the deciphering key, it can be used to decipher every other victim’s data. Alternatively, the ransomware authors could generate a unique binary per target and maintain a list of private keys associated with binaries, but this process requires much more work.

Across these scenarios, attackers using asymmetric cryptography for key management face the challenges of either not being able to target offline hosts or being thwarted by forensic retrieval of the deciphering keys. 

See how the Falcon platform protects against ransomware in this short video. 

The Enclave Benefit for Ransomware 

Enclaves allow ransomware authors to circumvent both obstacles, allowing them to use a single binary to generate local cryptographic keys on target systems and ensuring that the victim cannot retrieve the deciphering key. Indeed, cryptographic keys are generated inside the enclave, which can’t be accessed by any other process, and deciphering keys can be safely stored without ever appearing in clear-text on the OS memory. Furthermore, this method independently infects each target regardless of whether the victim’s machine is online or not.

Regarding encryption methods, enclaves support both symmetric and asymmetric encryption. In a symmetric encryption scenario, the enclave generates the key and receives the victim’s data to encrypt from the regular core of the application. The enclave encrypts and returns the ciphered data, which the regular core uses to override the victim’s file content. Then the enclave seals the symmetric key and returns it to the regular core that writes the sealed key on disk for a potential future decryption. 

The same logic applies to the asymmetric encryption process, as shown in Figure 2. First, the enclave generates the asymmetric pair of keys. The encryption can be performed either in the enclave, as in the previous case, or the ciphering key can be sent to the untrusted area, for the regular core of the application to directly encrypt the victim’s files. Then the enclave seals the deciphering key and returns it to the regular core, which saves it on disk. 

In both cases, enclaves allow ransomware to meet three of the ideal attack conditions:

• Only requires a single malicious binary to generate unique cryptographic keys for each victim
• Prevents the deciphering key from retrieval with common forensic methods
• Does not require a control-and-command server, enabling infection of  disconnected systems

Figure 2. Operation flow of a ransomware using enclave

Conclusion 

Enclaves can be a useful means of managing cryptographic operations, making sure the decryption key can’t be retrieved (in theory). In order to protect customers from this particular tactic, the CrowdStrike Falcon® sensor gives customers visibility on the use of enclaves and uses this data alongside event telemetry to determine whether a process is malicious and to respond to detected threats.

See for yourself how the industry-leading CrowdStrike Falcon® platform protects against modern threats like ransomware. Start your 15-day free trial today.

It is worth noting that this method also presents significant limitations that complicate the successful execution of ransomware attacks. In Part 2, we’ll illustrate how this ransomware approach could be implemented and we’ll discuss this model’s limitations. 

Additional Resources

• Learn more about how CrowdStrike protects customers from ransomware.
• Find out about CrowdStrike’s ransomware protection solutions.
• Read about adversaries tracked by CrowdStrike in 2021 in the 2022 CrowdStrike Global Threat Report and in the 2022 Falcon OverWatch Threat Hunting Report.
• Test CrowdStrike next-gen AV for yourself. Start your free trial of Falcon Prevent today.

References

1. “Intel^® Software Guard Extensions (Intel® SGX) Developer Guide”, revision 2.7, page 35, March 2020
2. Pranshu Bajpai, “Extracting ransomware’s keys by utilizing memory forensics”, 2020, Michigan State University