Interesting Multi-Stage StopCrypt Ransomware Variant Propagating in the Wild



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
Security News
The SonicWall Capture Labs Threat Research Team gathers, analyzes and vets cross-vector threat information from the SonicWall Capture Threat network, consisting of global devices and resources, including more than 1 million security sensors in nearly 200 countries and territories. The research team identifies, analyzes, and mitigates critical vulnerabilities and malware daily through in-depth research, which drives protection for all SonicWall customers. In addition to safeguarding networks globally, the research team supports the larger threat intelligence community by releasing weekly deep technical analyses of the most critical threats to small businesses, providing critical knowledge that defenders need to protect their networks.