Skip to Main Content

Article

Surtr Ransomware Pays Tribute to REvil

Share

3/18/2022

Executive Summary

In February 2022, Arete investigated a Surtr ransomware incident where the ransomware author(s) paid tribute to the now defunct REvil (aka Sodinokibi) group by making a registry key change to the infected host. REvil was an infamous Russian-speaking Ransomware-as-a-Service (RaaS) operation known for the Kaseya attack. In October 2021, a multinational effort disrupted REvil’s operations, followed by Romanian and Russian law enforcement largely dismantling the group by arresting individuals and seizing millions in cash and cryptocurrency.

Arete notes that the developers of Surtr ransomware likely do not have a direct connection to the now defunct REvil ransomware group. However, it is likely that the developers of Surtr are leveraging their REvil tribute to gain popularity. Arete also notes that multiple ransomware groups and affiliates work in a closed ecosystem, sharing source code, strategies, initial access brokers, functionality, and development resources. Thus, it is possible a Surtr developer previously worked with the REvil ransomware group.

Research revealed that Surtr ransomware:

  • Changes the victim’s system manufacturer name with a sentence paying tribute to REvil.
  • Uses a message box to warn affiliates not to run the malware in the Commonwealth of Independent States (CIS) — a group of countries in Eastern Europe and Asia formed by Russia and other republics after the dissolution of the Soviet Union — or they will be banned.
  • Displays messages not common on mature ransomware, which could indicate that the ransomware’s development is still in the early stages.
  • Like other ransomware, encrypts files in network shares, deletes volume shadow copies, clears Windows event logs, and has a list of whitelisted file extensions, file names, and folders.
  • Has multilayer obfuscation.
  • Creates persistence through registry key changes to start as a service, in registry run keys, and make a copy of itself in the StartUp directory.
  • Creates a mutex value to prevent another copy of the process from running in the system.

Background

Surtr is a new RaaS operation, first observed in December 2021. Like many other ransomware groups, Surtr avoids its execution in the CIS countries and adopts the double extortion scheme of stealing and threatening to leak data if ransom demands are not met. In this investigation, the ransomware targeted Windows systems and employed several anti-debugging/anti-sandboxing techniques. At present, there are no public decryptors or logical flaws to recover files encrypted by Surtr.

Technical Analysis

Surtr ransomware is packed and has an entropy value of 7.62115.  The malware has multilayer obfuscation.  The native Windows Application Programming Interface (API) “CryptDecrypt” unpacks the first layer of packed content. The packer used Microsoft Enhanced RSA and Advanced Encryption Standard (AES) Cryptographic Provider (CALG_AES_256) to decrypt the data. The unpacked sample is once again UPX packed, which drops the actual payload.

Figure 1. Decrypt function

 

Figure 2. Decrypting PE file in the memory (encrypted vs decrypted)

 

Upon decrypting the Portable Executable (PE) file, the packer spawns the same as a new child process with the original packed executable name. Using Windows API “VirtualAllocEx”, it allocates an address space in the spawned child process and writes the process memory with newly decoded binary, later resuming the child process.

Figure 3. Process injection

The decrypted sample shown in Figure 2 is UPX packed. Upon successful unpacking, the analyst gets the Surtr ransomware payload.

Surtr ransomware retrieves file attributes for a specified file or directory “NoRunAnyWay”. If the file or directory does not exist, the program continues creating a folder “Service” at “%ProgramData%”. Later, the sample checks for “config.txt” at the same directory. It appears the ransomware stores its configuration at the “C:ProgramDataServices” folder at a later point in time.

The ransomware tries to open mutex by the name “SurtrMUTEX”. If the mutex does not exist, it continues the execution or the ransomware terminates the current program. This activity ensures that a single instance of the program is running.

Figure 4. Creating Mutex

Similar to other ransomware, Surtr avoids execution in the CIS countries, which include Armenia, Azerbaijan, Belarus, Kazakhstan, Kirghizstan, Moldavia, Uzbekistan, Russia, Tajikistan, Turkmenistan, Ukraine, to avoid infecting users where the operators and affiliates most likely reside and visit to prevent arrest by local authorities. Initially, the sample checks the IP address of the victim’s machine and collects IP-related information using ip-api[.]com, which returns a JSON file containing the country of IP origin. Later, this is compared against the list of countries hardcoded in the sample. If there is a match, it avoids execution, leaving a comment “WARNING. Surtr does not run in this country if you do it again you will be banned.” Note: The ransomware also works without proper response from the ip-api[.]com.

Here is the list of countries the ransomware avoids:

Figure 5. Comparing CIS name to avoid execution

 

Ransomware anti-sandboxing techniques are shown below.

  1. The ransomware keeps track of anti-sandboxing techniques using a counter. As shown below, the sample initially checks for API Hooks “E9” for the Windows function “CreateProcessA”. The counter is updated accordingly.

Figure 6. Anti-Sandbox-1

  1. The ransomware checks if the total physical memory (RAM) of the host machine is less than 500MB using the API “GlobalMemoryStatus”. If the victim’s hardware passes this check, the counter is incremented.
  2. Later, using DeviceIOControl, the ransomware gets the geometry (File size) of the C:\ drive and compares it with a hardcoded constant. If the victim’s hardware passes this check, the counter is incremented.[1]

Figure 7. Anti-Sandbox-2, 3

Ransomware anti-debugging techniques are shown below.

  1. Initially, the ransomware checks if any hardware breakpoints (DR0, DR1, DR2, DR3) are set. If the condition satisfies the debugging, the counter is incremented.

Figure 8. Anti-Debugging-1

  1. It also leverages the Windows API “IsDebuggerPresent” To check if the process is being debugged or not and updates the counter accordingly.

Figure 9. Anti-Debugging-2

  1. It appears the program accesses the “Configuration Directory” itself and checks if “GlobalFlagsClear” is set to 0. If yes, the counter is updated.

Figure 10. Anti-Debugging-3

 

  1. The ransomware checks for the NtGlobalFlag value of the Process Environment Block, which is set to the default value “0” by the operating system. When debugging the malware with a software debugger, the NTGlobalFlag value would be set to 0x70. Passing this check would indicate the presence of a debugger and the counter would be updated [2]

Figure 11. Anti-Debugging-4

 

Upon these checks, the ransomware compares these calculated individual counters of anti-debugging/anti-sandboxing with the value 2. If either of these counters is more than 2, the ransomware exits with a message box saying, “WARNING. SandBox/Debugger Detected!!!”

The key characteristic of the program is using multithreading for file encryption. Arete observed that multiple threads were created during the execution process, which delays malware analysis and hastens data encryption.

The program makes sure to remove system backups, shadowcopies, and system logs.

Figure 12. Removing system backups, Shadowcopies, System logs.

As part of initial encryption process, the ransomware creates and assigns a random ID to the victim’s machine. The ID is later stored in “c:ProgramDataServicesID.surt” and used in further file encryption.

Figure 13: Creating victim ransomware ID

The ransomware checks mounted drives from (A to Z) using Windows native API “GetDriveTypeW”. Once the ransomware enumerates all mounted drives and shares, it encrypts all files except the following:

File Extensions: “.exe”, “.DLL”, “.lnk”, “.surt”

File Names: “surt”, “NTUSER.DAT”, “WIN.INI”, “UsrClass.dat”, “Pagefile.sys”, “hiberfil.sys”, “DumpStack.log.tmp”, “Config.msi”, “boot”

Folders: “Windows”, “Microsoft”, “Windows.old”, “Windows kits”, “WindowsApps”, “Tor Broswer”, “Google”, “Mozilla”, “DropBox”

The ransomware uses the “net use” command to connect the remote host device’s share “ADMIN$”. If the connection is successful, the share is added to the encryption list.

Figure 14. Enumerating network shares

The ransomware acquires a targeted file’s handle. Later, it generates a 64bit random value using a Windows Native API “CryptGenRandom” as shown in Figure 15.

Figure 15. Generating 64-bit random value

 

The generated random value creates XOR keys, which are used to further encrypt the file contents. Upon encryption of the file, the ransomware encrypts the generated random value using asymmetric encryption and stores the encrypted key at the end of the file as shown in Figure 17.

Figure 16.  File encryption loop

 

Figure 17. Dissecting encrypted file

Figure 17.1. “SURTR”-The attacker identifies if the file was encrypted by the Surtr ransomware using the keyword.

Figure 17. 2. Asymmetric encrypted 64bit random generated values.

Figure 17. 3. Delimiter.

The ransomware achieves persistence by copying itself to the “StartUp” folder, creating schedule tasks that execute the ransomware “ONLOGON” and add a registry value in “Run” and “RunOnce” key to make the ransomware restart on a system reboot.

Figure 18. Achieving persistence

Arete found that the threat actor also updates the system manufacturer name to “Tribute to the REvil <3” by adding/modifying the “OEMInformation” registry value.

  Figure 19. Adding “Tribute to REvil” registry entry

The registry changes mentioned above are shown below.

Figure 20. Updating the system manufacturer

The ransomware further tries to hide by updating its file attributes, thus complicating forensic investigations to identify the same.

Figure 21.  Updating file attributes

Upon successful execution of the ransomware, Surtr changes the background of the victim’s machine as shown below and reboots the system.

Figure 22. Changes desktop background

 

Ransom note name: SURTR_README.hta, SURTR_README.txt.

Figure 23. Ransomware note

Conclusion

A new ransomware on the scene, Surtr could be one to keep an eye on as it mentions REvil’s name in its operations. As more information unfolds, Arete could assess the future of Surtr ransomware. Arete has countermeasures coverage to detect Surtr payloads and artifacts via Arsinal Threat Management and Threat-ID.

Countermeasure

Yara rule:

rule Surtr_ransomware_executable

{

meta:

author = “agundmi@areteir.com”

copyright = “Copyright © 2022 by Arete Advisors, LLC.”

md5 = “565951acb3eb5fe91f3be723a2d633b9”

 

strings:

$id = {E8 [4-8] 99 F7 FF 42 83 FA ?? 7? ?? 83 FA ?? 7? ?? 8D 42 ?? 83 F8 ?? 7? ?? 88 96 [4-8] 46 83 FE 0E 7?}

$str1 = “vssadmin.exe Delete” wide nocase

$str2 = “Tribute to the REvil” nocase

$str3 = “\\.\PhysicalDrive0” wide nocase

$str4 = “DisableTaskMgr”

$str5 = “surt” wide nocase

$str6 = “\NoRunAnyWay” wide nocase

$str7 = “\ProgramData\Service\” wide nocase

 

condition:

((uint16(0) == 0x5A4D) and (uint32(uint32(0x3C)) == 0x00004550)) and (($id) and (1 of ($str*)))

}

IOCs:

MD5Sample
B7966CCA3C6FE9B9C64D772EC7DF804CPacked
460FDD0198A286067211BFCF47825B11UPX Packed
FD16AC037269708C1AB135653483E891Payload

 

URL
2i74xfkhsu4zd6qv5aiifv3wznj6vq3jo6mle3zxux6vpftyuezxhmad[.]onion

 

References:

https://www.pcrisk.com/removal-guides/22650-surtr-ransomware
https://twitter.com/Securityblog/status/1474085713280999439

[1] https://disassemble.blog/2022/01/26/whispergate-part-1/

[2] https://osandamalith.com/2016/04/23/debugger-detection-using-ntglobalflag/