The Road to Ransomware Resilience, Part 2: Behavior Analysis

*This is the second in a series of articles. Follow this link to read from the beginning.

The road to constructing an effective novel response against ransomware begins with understanding the recent trends of the underground ransomware ecosystem: common targets of ransomware, typical ransomware behavior, common ransomware encryption schemes, as well as the construction and application of decryptors and other effective response approaches and tools.

In this upcoming series of articles, we will discuss each of these factors one by one.

‍

Ransomware Behavior Trends

We’ve looked at trends in victim selection as well as the underground ecosystem; however, what has proven most interesting has been the trends within the ransomware itself.

We analyzed 9 different ransomware and focused on these aspects of ransomware behavior: triggers, evasion and obfuscation techniques, and encryption schemes.

‍

‍

Trigger Analysis

Ransomware typically wants to encrypt and extract as many files as it can, as fast as it can, as long as it can; however, it needs to first ensure the targeted files are their worth encrypting — whatever the attackers’ motivations might be. In order to accomplish all of this, prior to execution, ransomware will typically perform environment and atomic execution checks.

‍

Environment Check

Ransomware will check the environment it’s currently located in to ensure it is not located in a sandbox, honeypot, or other virtual machine but in the target victim’s real environment. “Big game” targets typically have more mature defenses, meaning that ransomware only has one chance to trigger execution.

‍

‍

Wastedlocker, for example, checks for a specific interface to ensure the environment it’s currently located in is real and not a virtual machine.

‍

Atomic Execution Check

Ransomware developers are constantly looking for ways to increase encryption efficiency — encrypt more files in less time. One method commonly used across different ransomware is an atomic execution check that ensures files selected for encryption are only encrypted once.

Some take a more streamlined approach with a static mutex, such as ColdLock, Crypt7, and Prometheus. On the other hand, some ransomware took a more complicated approach with a dynamic mutex. RansomEXX generated the mutex name via MD5 hashing the endpoint’s computer name while Prometheus went a step further and directly hardcoded the process name into the code, and then later double-checked the targeted process name to ensure targeted files wouldn’t be double encrypted.

‍

‍

WastedLocker (pictured above) also took a much more dynamic approach with its mutex by only beginning encryption if the newly created mutex were “unique” for each endpoint. While WastedLocker seemed to “randomly” generate “unique” mutex names; however, this “random” mutex name was actually deterministic on the same endpoint and could therefore be reversed. That is, different endpoints would have different mutex names (“random” across “different endpoints”, making it harder for EDR/AV to detect), but the same endpoint would always have the same mutex name (so it wouldn’t double encrypt on the same endpoint).

For your reference, we created the chart below to help you better compare each of the studied ransomware samples.

‍

‍

Idiosyncratic Checks

While different strains of ransomware share similarities due to the specific nature of ransomware attacks, ransomware is still a reflection of the more unique motivations driving the developers.

Egregor, for example, checks for languages native to the Ex-Soviet CIS countries (Commonwealth of Independent States); this is most likely due to Egregor developers being located in, or from, one of the CIS countries and wanting to avoid attention from local law enforcement agencies.

When asked if they check the location of their victim, the leader of the LockBit ransomware group responded, “Yes, that’s a code of honor. You cannot attack your own nation. I was born in the Soviet Union.”[8]

Some checks could have been developed and implemented due to the cultural environment of the target as opposed to their digital environment. In the ColdLock case[5], the attackers waited for a long holiday weekend to allow the GPO to automate the distribution of the ColdLock ransomware throughout the entire system, maximizing the number of affected endpoints for the day of the attack. When the ransomware did trigger, it was at precisely 12:10 in the afternoon — Monday lunch break.

Compared to the rest of the analyzed ransomware, Prometheus was far more meticulous and sophisticated in both its environment and atomic checks.

However, some ransomware took a much more complicated approach; WastedLocker and RansomEXX both leveraged a dynamic mutex, with WastedLocker being the most dynamic and complex.

‍

Evasion and Obfuscation Techniques

Ransomware follows the design philosophy of encrypting and extracting as many files as it can, as long as it can. While environment and atomic checks help ensure targeted files get encrypted as efficiently as possible, obfuscation and evasion techniques help ensure the attackers have enough time to locate and encrypt sensitive files.

However, modern ransomware developers think in the long term. The longer it takes defense teams to reverse engineer ransomware and respond, the longer the ransomware gang can stay operational.

‍

Here are some highlighted obfuscation techniques.

Conti Ransomware: API Unhooking

API Hooking is a common technique used by both AV and EDR solutions in order to monitor processes and code behavior in near real-time and is typically done by adding jump instructions in front of functions the system wants to monitor.

MITRE ATT&CK (T1056.004) API HOOKING
Adversaries may hook into Windows application programming interface (API) functions to collect user credentials. Malicious hooking mechanisms may capture API calls that include parameters that reveal user authentication credentials. Unlike Keylogging, this technique focuses specifically on API functions that include parameters that reveal user credentials. Hooking involves redirecting calls to these functions and can be implemented via hooks procedures, import address table (IAT) hooking, or inline hooking.

Conti (pictured below) bypassed this by meticulously searching for jump opcode. If found, Conti would attempt to patch the jump opcode and unhook the API, leaving the AV or EDR solutions blind to Conti’s behavior.

‍

‍

Note the two highlighted green sections labeled “check jmp code” and “unhook function by copying 16bytes”. The first part of the code checks whether the opcode is a “jump” instruction, which is a potential sign of API hooking. Then, the second part of the code overwrites these instructions into ‘’nop” instructions to remove the hook.

‍

Conti Ransomware: String Obfuscation

Conti ransomware leveraged more than 100 string obfuscation functions in our sample alone. The particular obfuscation method pictured below is quite simple to decrypt manually; however, this quickly becomes burdensome when tasked to manually decrypt over 100 string obfuscation functions. In this particular case, a script was developed in order to automate the decryption process.

‍

‍

Prometheus Ransomware: GetString

Unlike Conti, Prometheus is implemented in managed code (.NET MSIL) and did not develop their own obfuscation method but rather used the commercial obfuscator SmartAssembly v7.5.2.4508. While this version of SmartAssembly gives Conti access to numerous obfuscation techniques, we wanted to highlight Prometheus’ use of the GetString function.

Every string reference has been replaced by the GetString function. From the code below, we see that function .\u001F is, in fact, the GetString function.

‍

‍

‍

In addition, every class within Prometheus ransomware has its own GetString function.

‍

‍

‍

As seen directly above, the GetString function itself is not complicated — just a few integer operations. After the ransomware has offset the string, it will reference resource stream {c4633a62–8069–4a7e-9e5d-1429bccb887a}, which after unzipped and decoded from the revealed Base64 format, will reveal the final string buffer where every string used by the ransomware is located.

‍

‍

The CreateGetStringDelegate function generates IL code during runtime and dynamically adjusts arguments pasted into GetString. This approach allows for not only every GetString function to have a unique metadata token but for each class to also have a unique formula to calculate the string index.

‍

Ransomware Encryption Schemes

Ransomware we analyzed typically followed the same two-layered encryption scheme seen in most ransomware. The first layer is file encryption leveraging symmetric encryption algorithms (such as AES); typically, a unique file encryption key is generated for each encrypted file. The second layer is the key encryption, often leveraging asymmetric encryption algorithms (such as RSA) and encrypting the file encryption key. The public key is used to encrypt the file encryption key on the victim’s computer while the private key is kept by the attackers.

‍

‍

Here, you can see that RSA is the most commonly used asymmetric encryption and AES the most common choice for symmetric encryption.

Some ransomware (as pictured above) used system built-in APIs, such as CryptEncrypt and Random.random(). Ryuk’s use of AES-256 and CryptEncrypt() for symmetric encryption and Conti’s use of CryptGenRandom() for RNG (random number generation) are good examples of this. Some ransomware, such as Conti, used statically linked libraries for cryptography operations.

‍

‍

Some ransomware leveraged encryption algorithms from other well-known malware, such as Conti’s use of ChaCha8 (pictured above) or Prometheus’s use of SALSA20 (pictured below). This approach was most likely taken to increase encryption efficiency.

‍

‍

Encryption Optimization

As mentioned earlier, ransomware typically has three priorities: find sensitive data fast, leverage evasion and obfuscation techniques to prolong the attack, and encrypt targeted data quickly and efficiently.

Encryption optimization is on every ransomware developer’s mind. The two main methods we have observed from our analysis were increasing the number of CPU threads and employing different encryption methods for files of different sizes.

Conti ransomware was notorious for its speed, which was due to its leveraging 32 threads. Conti isn’t alone in using multiple threads. Other ransomware developers have explored this approach, such as REvil, LockBit, Rapid, Thanos, Phobos, and MagaCortex.

Other ransomware (e.g., Prometheus and REvil) increased efficiency by employing different encryption methods based on file size. Smaller files would be fully encrypted while larger files, such as image or video files, would only be partially encrypted; even encrypting only the header to make the file inaccessible could be enough to serve the attackers’ purposes. Read more: Cycraft Releases Decryptor for Prometheus Ransomware

‍

The Long and Winding Road

On our next stop on the road to ransomware resilience, we will explore defense and preventative solutions: how to gather and leverage intelligence from hacker forums, the dark web, OSINT, and other sources to identify potential enterprise-targeting threats. Learn how to prevent attacks in advance by locating leaked documents, leaked PII, credentials for sale on the dark web, enterprise-related credentials leaked from 3rd party services, and more.

In addition, we will also discuss new innovative defense approaches including AI-based threat hunting, AD environment assessments, and developing digital vaccines for ransomware.

If you’re interested in learning about compromise assessments to ensure the health and security of your network, engage with us directly at contact-sea@cycraft.com