Interesting Multi-Stage StopCrypt Ransomware Variant Propagating in the Wild
Overview
The SonicWall Capture Labs threat research team recently observed an interesting variant of StopCrypt ransomware. The ransomware executes its malicious activities by utilizing multi-stage shellcodes before launching a final payload that contains the file encryption code.
Infection Cycle
At the start of execution, it creates a string of msim32.dll on the stack, and, using LoadLibrary, loads the Dll. The significance of why it is doing this is a mystery, as that is not used in the process.
It has a long, time-delaying loop of 65,18,40,312 iterations wherein the same data is copied to a location and the count is incremented. Many more similar loop-delaying techniques are used throughout the malware execution.
The possible reason for using such techniques is to evade detection. These loops serve a nefarious purpose: to thwart time-sensitive sandboxes and security mechanisms by artificially prolonging the execution time of the malicious code.
Figure 1: Loop for delaying time
Next, it allocates the memory using LocalAlloc API, and it then uses VirtualProtect to change the permission of the memory block to READ, WRITE and EXECUTE.
First Stage Payload
In this stage, it dynamically resolves the required APIs using the Kernel_GetProcAddress API.
The Ransomware constructs API function calls by constructing the function names or strings containing API names directly on the stack. It does this instead of using straightforward API calls, which can be easily identified and analyzed by security tools.
Figure 2: Constructing API names on the stack
The malware resolves the addresses of the following APIs:
- GlobalAlloc
- VirtualAlloc
- SetLastError
- Sleep
- CreateToolHelp32Snapshot
- Module32First
- CloseHandle
CreateToolhelp32Snapshot is utilized to take a snapshot of the current process that includes all its modules (0x8 = TH32CS_SNAPMODULE):
Figure 3: Kernel32_ CreateToolhelp32Snapshot Win32 API call
The Ransomware extracts information about the first module of the process using the Module32First API.
It then calls the VirtualAlloc API to allocate the memory with READ, WRITE and EXECUTE permissions.
Second Stage of Payload
In this stage, the primary task of the shellcode is to perform process hollowing.
API function names are also dynamically created on the stack during this phase.
Figure 4: Constructing API names on the stack
The malware resolves the addresses of the following APIs:
- MessageBoxA
- GetMessageExtraInfo
- WinExec
- CreateFileA
- WriteFile
- CloseHandle
- CreateProcessA
- GetThreadContext
- VirtualAlloc
- VirtualAllocEx
- VirtualFree
- ReadProcessMemory
- WriteProcessMemory
- SetThreadContext
- ResumeThread
- WaitForSingleObject
- GetModuleFileNameA
- GetCommandLineA
- NtUnmapViewOfSection
- NtWriteVirtualMemory
- RegisterClassExA
- CreateWindowExA
- PostMessageA
- GetMessageA
- DefWindowProcA
- GetFileAttributesA
- GetStartupInfoA
- VirtualProtectEx
The Ransomware then checks the FileAttributes of the non-existent file “apfHQ” using the kernel32_GetFileAttributesA API.
Figure 5: Kernel32_GetFileAttributesA Win32 API call
The purpose for this operation is not known – this could be a marker to identify specific systems where the file might be present.
The file then registers a window class called “saodkfnosa9uin” using the user32_RegisterClassExA API.
Figure 6: Kernel32_RegisterClassExA Win32 API call
It then calls user32_CreateWindowExA API to create the window.
The ransomware calls the VirtualAlloc API to allocate the memory with READ, WRITE permissions
to store the path returned by the GetModuleFileNameA API. The path is the current location from where the ransomware is running. Next, it calls the kernel32.GetStartupInfoA API to retrieve startup information.
Figure 7: Kernel32_GetStartupInfoA Win32 API call
Using the kernel32_CreateProcessA API, it launches its own copy as a new process in a suspended state. This is where the process hollowing begins.
Figure 8: Kernel32_CreateProcessA Win32 API call
The GetThreadContext API is called to retrieve the context of a specific thread:
Figure 9: Kernel_ GetThreadContext Win32 API call
The ReadProcessMemory API is used to get the loaded base address of the image.
The Ntdll_NtUnmapViewOfSection API is used to unmap a view of a section from the virtual address space of the process.
Figure 10: Ntdll_NtUnmapViewOfSection Win32 API call
The VirtualAllocEx API is used to allocate new space in the newly created process.
Figure 11: Kernel32_ VirtualAllocEx Win32 API call
The Ntdll_NtWriteVirtualMemory API is used multiple times to write the data into the memory of the newly created process which is in a suspended state.
Figure 12: Ntdll_NtWriteVirtualMemory Win32 API call
Once the section by section data is written into the memory of the remote suspended process, it calls the Kernel32_SetThreadContext API. The SetThreadContext API is used to set the context for the remote thread:
Figure 13: Kernel32_SetThreadContext Win32 API call
The ResumeThread API is used to start the execution of the thread process that was in a suspended state.
Final Payload
The ransomware then launches a resumed process with the following parameter: “–Admin IsNotAutoStart IsNotTask.”
Figure 14: Launching process with “–Admin IsNotAutoStart IsNotTask” as a parameter
The ransomware creates a new directory in C:\\Users\<user_name>\AppData\Local and copies the current malware image(binary) into it.
It then launches the “icacls.exe” process, which is the command-line utility used to view and modify access control lists (ACLs) in Windows.
The command icacls.exe <path> /deny “s-1-1-0:(OI)(CI)(DE,DC) is used to deny permissions to a specific security identifier (SID) on a file or directory in Windows.
Overall, this command denies the “Everyone” group permission to delete the specified file or directory and its contents, effectively restricting their ability to modify or delete it.
Figure 15: Using the Icacls command to deny permission for deleting file or directory
The ransomware creates a scheduled task that executes a copy of the final payload with a command line argument –Task, every five minutes.
Figure 16: Task added in the task scheduler.
The ransomware encrypts the files and appends the .msjd extension to the encrypted files.
Figure 17: Ransomware encrypted filenames
The ransomware note is kept in every encrypted folder as _readme.txt
Figure 18: Ransomware note
SonicWall Protections
SonicWall Capture Labs provides protection against this threat via the following signature:
- GAV: StopCrypt.RSM (Trojan)
This threat is also detected by SonicWall Capture ATP w/RTDMI and the Capture Client endpoint solutions.
*this blog was originally titled in a way that indicated that this was a new ransomware variant, but this was done in error and has been corrected
