🚀 CloudSEK has raised $19M Series B1 Round – Powering the Future of Predictive Cybersecurity
Read More
Protect your organization from external threats like data leaks, brand threats, dark web originated threats and more. Schedule a demo today!
Schedule a DemoThe DJVU/STOP ransomware, since it was first detected in 2018, has been intermittently observed as part of ransomware attacks, but has not gained the notoriety of other ransomware like REvil or Conti. However, there has been a resurgence, with a new variant of DJVU/STOP becoming one of the most widespread file-encrypting malware of 2021. So much so that it has become a global nuisance, targeting entities across the United States, Europe, Asia, South American, and Africa. It has been detected in popular software crack packages or adware bundles, which are usually found on torrent sites and other platforms.
In this 2 part blog series we will delve into the modus operandi of the DJVU/STOP ransomware, its technicalities and features, how it identifies victims, and maintains persistence.
DJVU/STOP ransomware is a file encryption Trojan malware that secretly intrudes a victim’s computer and encrypts all the files to make them inaccessible. After which, it drops a ransom note notifying the victim of the encryption. The note also demands a specific sum of money as ransom for the decryption keys that will decrypt the compromised files and make them accessible to the victim.
The loader allocates a memory using VirtualAlloc Win32 API with function definition:
LPVOID VirtualAlloc( [in, optional] LPVOID lpAddress, [in] SIZE_T dwSize, [in] DWORD flAllocationType, [in] DWORD flProtect ); |
In the loader, the following arguments are used to call VirtualAlloc:
The allocated memory page is read/write and execute capable. While on the surface this may appear trivial, it is a common behavior seen in even the most sophisticated of malware to execute malicious code on a victim machine while being discreet.
flProtect : 0x40 flAllocationType: 0x1000 dwSize: lpAddress: 0x0 |
Memory with zero bytes:
The loader populates the allocated memory, from the previous step, with the shellcode.
The execution flow is then transferred to the newly allocated shellcode as seen below. And the CPU now points to the first instruction of the malicious shellcode as it starts executing.
The stage 1 primary shellcode is programmed to inject the secondary shellcode, which is responsible for “process hollowing,” to deliver the final ransomware crypter code.
The primary shellcode delivers modules into its address space, including but not limited to:
Address resolution is done by obtaining the address of one of the crucial functions in the kernel32 module which iskernel32.GetProcAddress. Malware authors use kernel32.GetProcAddressto dynamically resolve Win32 APIs to evade scrutiny of code analysis by looking at the import table of the program. A few interesting function addresses are also resolved to be used later in the program.
Once the malware obtains the address of kernel32.GetProcAddress function, it is used to resolve the addresses of following functions:
After resolving the addresses of various functions, the shellcode starts executing two Win32 APIs:
Arguments passed to CreateToolhelp32Snapshot are:
HANDLE CreateToolhelp32Snapshot( [in] DWORD dwFlags, [in] DWORD th32ProcessID ); |
Arguments passed to Module32First function are:
BOOL Module32First ( [in] HANDLE hSnapshot, [in, out] LPMODULEENTRY32 lpme ); |
The above-mentioned codes are functions commonly used to perform malicious activities. In this instance:
The Stage 1 shellcode allocates memory with formerly noted arguments for the stage 2 shellcode, using the VirtualAlloc Win32 API.
The next step involves writing shellcode into the allocated memory. The control is then transferred to the shellcode writing logic via “call 4AE04F2”.
The previous call lands in the code logic given below, which iteratively writes stage 2 shellcode into the allocated buffer.
Once the shellcode is transferred, the control is assigned to the shellcode by a JMP command as shown below:
After the jump, the CPU points to the beginning of the stage 2 shellcode. This shellcode is responsible for performing “process-hollowing” to deliver a ransomware crypter payload that encrypts user data. The second stage shellcode then loads user32.dll, ntdll.dll, and kernel32.dll modules into the current process.
Using kernel32.GetProcAddress, addresses of the following interesting functions are resolved:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The shellcode checks for a specific file named “apfHQ.” Our best assumption is that the file is used as a marker to identify victims. Even though the string is very common in various malware families, the exact reason for this behavior is still unknown.
The shellcode then creates a windows class using two APIs, namely user32.RegisterClassExA and user32.CreateWindwoExA. The name given to the class is “saodkfnosa9uin.”
The previously created window class is used to create a hidden window using user32.CreateWindowExA as shown below:
As mentioned above, the objective of the second stage shellcode is to perform process hollowing to deploy a ransomware crypter to encrypt the user data.
Process hollowing is a covert way of injecting malicious code into a benign and trustworthy process to evade detection and security. An intuitive explanation for process hollowing is carving the legit and original instruction of the benign application to replace it with a malicious one, without letting the application know about the change in code made by the threat actor. This is why attackers create a process in a suspended state and then resume it after the hollowing is done.
In the second part of the blog post we will continue to analyze the ransomware crypter code after obtaining the newly created process from the memory dump.
Discover how to navigate and protect against Dark Web threats. Learn about cyber risks, real-time monitoring, and securing your digital presence.
On 23 October 2023, CloudSEK’s Threat Intelligence Team detected a Ransomware-as-a-Service (RaaS) group, named QBit introducing a newly developed ransomware written in Go, boasting advanced features to optimize its malicious operations.
Cyclops, now renamed as Knight also known as Cyclops 2.0, debuted in May 2023. The Cyclops group has successfully developed ransomware that can infect all three major platforms: Windows, Linux, macOS, ESXi and Android.
Take action now
CloudSEK Platform is a no-code platform that powers our products with predictive threat analytic capabilities.
Digital Risk Protection platform which gives Initial Attack Vector Protection for employees and customers.
Software and Supply chain Monitoring providing Initial Attack Vector Protection for Software Supply Chain risks.
Creates a blueprint of an organization's external attack surface including the core infrastructure and the software components.
Instant Security Score for any Android Mobile App on your phone. Search for any app to get an instant risk score.
min read
Resurgence of DJVU/STOP Ransomware Strain in the Wild (Part 1/2)
The DJVU/STOP ransomware, since it was first detected in 2018, has been intermittently observed as part of ransomware attacks, but has not gained the notoriety of other ransomware like REvil or Conti. However, there has been a resurgence, with a new variant of DJVU/STOP becoming one of the most widespread file-encrypting malware of 2021. So much so that it has become a global nuisance, targeting entities across the United States, Europe, Asia, South American, and Africa. It has been detected in popular software crack packages or adware bundles, which are usually found on torrent sites and other platforms.
In this 2 part blog series we will delve into the modus operandi of the DJVU/STOP ransomware, its technicalities and features, how it identifies victims, and maintains persistence.
DJVU/STOP ransomware is a file encryption Trojan malware that secretly intrudes a victim’s computer and encrypts all the files to make them inaccessible. After which, it drops a ransom note notifying the victim of the encryption. The note also demands a specific sum of money as ransom for the decryption keys that will decrypt the compromised files and make them accessible to the victim.
The loader allocates a memory using VirtualAlloc Win32 API with function definition:
LPVOID VirtualAlloc( [in, optional] LPVOID lpAddress, [in] SIZE_T dwSize, [in] DWORD flAllocationType, [in] DWORD flProtect ); |
In the loader, the following arguments are used to call VirtualAlloc:
The allocated memory page is read/write and execute capable. While on the surface this may appear trivial, it is a common behavior seen in even the most sophisticated of malware to execute malicious code on a victim machine while being discreet.
flProtect : 0x40 flAllocationType: 0x1000 dwSize: lpAddress: 0x0 |
Memory with zero bytes:
The loader populates the allocated memory, from the previous step, with the shellcode.
The execution flow is then transferred to the newly allocated shellcode as seen below. And the CPU now points to the first instruction of the malicious shellcode as it starts executing.
The stage 1 primary shellcode is programmed to inject the secondary shellcode, which is responsible for “process hollowing,” to deliver the final ransomware crypter code.
The primary shellcode delivers modules into its address space, including but not limited to:
Address resolution is done by obtaining the address of one of the crucial functions in the kernel32 module which iskernel32.GetProcAddress. Malware authors use kernel32.GetProcAddressto dynamically resolve Win32 APIs to evade scrutiny of code analysis by looking at the import table of the program. A few interesting function addresses are also resolved to be used later in the program.
Once the malware obtains the address of kernel32.GetProcAddress function, it is used to resolve the addresses of following functions:
After resolving the addresses of various functions, the shellcode starts executing two Win32 APIs:
Arguments passed to CreateToolhelp32Snapshot are:
HANDLE CreateToolhelp32Snapshot( [in] DWORD dwFlags, [in] DWORD th32ProcessID ); |
Arguments passed to Module32First function are:
BOOL Module32First ( [in] HANDLE hSnapshot, [in, out] LPMODULEENTRY32 lpme ); |
The above-mentioned codes are functions commonly used to perform malicious activities. In this instance:
The Stage 1 shellcode allocates memory with formerly noted arguments for the stage 2 shellcode, using the VirtualAlloc Win32 API.
The next step involves writing shellcode into the allocated memory. The control is then transferred to the shellcode writing logic via “call 4AE04F2”.
The previous call lands in the code logic given below, which iteratively writes stage 2 shellcode into the allocated buffer.
Once the shellcode is transferred, the control is assigned to the shellcode by a JMP command as shown below:
After the jump, the CPU points to the beginning of the stage 2 shellcode. This shellcode is responsible for performing “process-hollowing” to deliver a ransomware crypter payload that encrypts user data. The second stage shellcode then loads user32.dll, ntdll.dll, and kernel32.dll modules into the current process.
Using kernel32.GetProcAddress, addresses of the following interesting functions are resolved:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The shellcode checks for a specific file named “apfHQ.” Our best assumption is that the file is used as a marker to identify victims. Even though the string is very common in various malware families, the exact reason for this behavior is still unknown.
The shellcode then creates a windows class using two APIs, namely user32.RegisterClassExA and user32.CreateWindwoExA. The name given to the class is “saodkfnosa9uin.”
The previously created window class is used to create a hidden window using user32.CreateWindowExA as shown below:
As mentioned above, the objective of the second stage shellcode is to perform process hollowing to deploy a ransomware crypter to encrypt the user data.
Process hollowing is a covert way of injecting malicious code into a benign and trustworthy process to evade detection and security. An intuitive explanation for process hollowing is carving the legit and original instruction of the benign application to replace it with a malicious one, without letting the application know about the change in code made by the threat actor. This is why attackers create a process in a suspended state and then resume it after the hollowing is done.
In the second part of the blog post we will continue to analyze the ransomware crypter code after obtaining the newly created process from the memory dump.