One of the things I enjoy in my free time is malware analysis and tracking so I decided to push out work from time to time and publish some of my findings in the blog.
I particularly enjoy tracking trojans, infostealers and ransomware for different reasons, among them, the fact that the threat actors are continuously forced to evolve in order to survive by modifying and adapting their software to evade host and network detection, making the analysis more and more challenging(also the trolling is funny, to be honest). However, this type of malware(ransomware or commodity) is usually not that complex, in other words, it can be straight forward and the threat actors tend rely heavily on obfuscation and packing to deliver their payload.
One of these examples is Deathransom, one of the hundreds of ransomware that are now spreading due the new business model possibly started by the GandCrab gang and that now is growing and evolving causing huge damage and losses to companies.
Apparently this ransomware started as a scam that never encrypted anything but the actor decided to implement that functionality after that fact went public.
According to this report by AhnLab this malware have been seen in campaigns attacking South Korea and using same packers as GandCrab, Sodinokibi and Nemty along with campaigns where it was downloaded after an initial compromise by Vidar Infostealer.
From this analysis, I found common IOCs and relationships between Deathransom and other families such as AZORult, Arkei Stealer, Sodinokibi and in some cases SmokeLoader. However further analysis is required to determine the degree of relationship.
Some of the public information available about Deathransom:
- Deathransom is not longer a joke and start encrypting
- Cybercrime: Maze and Deathransom
- New ransomware begins to make a name for itself
This is one of the samples that ended up in my hands:
MD5:c50ab1df254c185506ab892dc5c8e24b
One of the first things I always do is to check Open Source Intelligence and looks for basic information, previous activity and analysis since I’m probably not the first one dealing with it, relationships(IOCs), detections etc. It currently have many detections, which is good news, but the signatures can be confusing as by some engines is categorized as Generic Trojan, Emotet, DeathRansom and also other detections. This is probably caused by different signatures hitting on the generic loader that used by multiple malware families.
Starting analysis with hashes, PE sections, imports/exports and available pdb file. The data is revealing anomalies between Virtual and Raw sizes in the sections, lack of visible strings and the only import is Kernel32.dll library.
Jumping to manual analysis, the sample got hit by the signature for Microsoft Visual C/C++ compiler, however average size, lack of visible useful strings, few imports and entropy indicates that this sample is likely to be using a custom loader/protector to hide the payload from AV signatures as the tools are not recognizing it.
Opened in the disassembler to analyze the malware structure shows a flow that conducts to call GetProcAddress to locate and use the function VirtualProtect which is dynamically loaded. Some of the imported functions and the dynamically loaded functions are known to be used commonly by packers:
- GetProcAddress: dynamically resolve addresses of functions.
- LoadLibraryExW and LoadLibraryW: dynamically load DLLs.
- VirtualProtect: Change protection of memory pages.
After this part, the code goes into the first relevant loop that will load shellcode into a prepared space.
Once the loop has ended, checks the shellcode status at the instruction <cmp esi, 2435128> after each cycle and once is good to go executes the shellcode.
The shellcode which is the responsible of the unpacking process utilizes multiple calls to VirtualProtect and VirtualAlloc. This functions will change memory protections, allocate memory regions and initialize this memory address space to write the payload.
Once the aforementioned process has finalized, the shellcode decrypts and writes the payload in the new section. Scrolling down in the hexdump window after the writing operation has ended shows a binary file in the new section, indicating that the protected binary was unpacked in memory.
I had some issues to direct the execution to the unpacked code while debugging it so I dumped the memory to disk and carved out the bytes to start the analysis of the unpacked code.
Analysis of the payload
After carving the bytes, analysis of the unpacked payload of Deathransom (MD5:8e115fea16d84246e1e5d9b700c19f36) shows that it first checks the default language and performs multiple checks to find if the victim host is in any of the CIS countries by testing the result of the call to GetUserDefaultLangID against multiple hardcoded values. The malware checks Russian, Kazakh, Belarusian, Ukrainian and Tatar languages.
If any of the previous languages are found, the program exits. This step identifies the victim’s default language ID and keyboard layout.
First checks and deployment
The next step of the malware is the classic connectivity check. However, in this case it uses the function URLDownloadFileA to query “https://iplogger[.]com/1Zqq77”. The resource is downloaded to the file “ntos.database”.
Unlike other families, it doesn’t matter if the connection fails as the intended functionality is tracking and in many cases ransomware just works offline unless it contains a module to directly interact with the C2 servers.
This functionality probably just keeps track of the infected IP addresses/regions as the file “ntos.database” is never used.
Deathransom attempts to ensure no recovery is possible. Microsoft’s shadow copy technology allows Windows systems to create snapshots-backups of files and volumes. To delete them it uses the WMI query “select * from Win32_ShadowCopy” to list shadow copies and then deletes each instance by id.
The malware starts operating with the Windows registry to create the following keys:
- HKEY_CURRENT_USER\SOFTWARE\Wacatac\public
- HKEY_CURRENT_USER\SOFTWARE\Wacatac\private
These keys are used to store the encryption key pair that will be used later to encrypt the filesystem.
Recon and enumeration
The malware clears the RecycleBin and starts enumerating network resources and drives from “A:” to “Z:”. If the drive or network share listed is available, the malware encrypts it.
It creates the file “read_me.txt” to write the ransom note in each used directory. This filename is also included in the below hardcoded list of blacklisted files and directories excluded from the encryption process due host functionality reasons. Any other file or directory found is encrypted.
Encryption
The malware uses the algorithm curve25519 and the encryption process is complex, using additional algorithms like RSA and AES to generate additional keys and encrypting the filesystem. The curve25519 keys are used for Elliptic Curve Diffie-Hellman (ECDH) key exchange to send data securely via email to the attacker in case of paying the ransom as no network module was observed.
Deathransom uses multiple calls to SystemFunction036(RltGenRandom) to generate 32-byte values for different operations involving the encryption of encryption keys and files.
For each file the malware lists to encrypt, it generates a new encryption key. The data is recovered by using the attacker’s curve25519 private key which is likely to be hosted in the attacker’s C2 and the victim’s public curve25519 key that is obtained via the generated LockID.
Looking at other reports looks like old samples that didn’t have the encryption module used the file extension “.wctc” to fool the users as if their files were encrypted. However, the newer version of this malware shows that does not change the file extension of the files once it has finished the overwriting process, and the victim will not notice changes until the files are open.
Found in multiple samples that this family additionally marks each file appending the bytes AB EF CD AB as a signature for already encrypted files to avoid re-encrypting them. For more details on how crypto works, you can check this report made by Fortinet.
The ransom note is written to all directories where the malware encrypted files (see above the excluded directories) with the below message and email contact “deathransom@airmail.cc”, the Lock-ID which uses the base64 encoded value of the registry key HKEY_CURRENT_USER\SOFTWARE\Wacatac\private and the BTC address to pay the ransom.
Conclusion
Ransomware after the Wannacry and NotPetya campaigns went slowly down as a malware trend for a while but the tendency to use ransomware has increased again in the last years and is a very interesting and lucrative emerging market in the cybercrime ecosystem. More and more ransomware is being created either as ransomware for sale in forums or RaaS models like GandCrab and Maze.
Deathransom ransomware started as a ransomware scam but it changed completely to become a potent threat that should’t be underestimated. While this type of malware is usually lacks of complexity and dedication, they are very lucrative due the direct and potentially devastating effects that can cause to institutions and business. At the time of writing this analysis I did not find an available decryption tool for Deathransom.
IOC
- c50ab1df254c185506ab892dc5c8e24b — Sample Packed
- 8e115fea16d84246e1e5d9b700c19f36 — Sample Unpacked
Related Samples
886ee5834ae019a5c8bce4326b88cfb7
4ba2e1d4cf7a86753f9f8174b3bc74c8
a35596ed0bfb34de4e512a3225f8300a
fdcdfc8eecff8eebd671cf934423710e
Network
- https://iplogger[.]com/1Zqq77
MITRE ATT&CK
- T1135 Discovery — Network Share Discovery
- T1082 Discovery — System Information Discovery
- T1124 Discovery — System Time Discovery
- T1012 Discovery — Query Registry
- T1045 Defense Evasion — Software Packing
- T1486 Impact— Data Encrypted for Impact
- T1490 Impact — Inhibit System Recovery
- T1047 Execution — Windows Management Instrumentation
Author / Threat Actor
- scat01
