In recent weeks Carbon Black’s Threat Analysis Unit (TAU) has seen an increase in the number of infections attributed to the Medusa Locker ransomware family. There were notable traits exhibited by Medusa Locker in these attacks that warranted further investigation to determine behavioral tactics that could be used by future malware families.
Medusa Locker used multiple stages of infection, starting with an initial batch file and text document, used to inject ransomware into memory for execution. Notably, it uses known PowerShell code to perform reflective injection of its code, causing PowerShell itself to perform the malicious activity.
This ransomware was involved in altering the system to permanently remove volume shadow copies and delete system services before encrypting data using standard AES-256 encryption.
This post focuses on the unique aspects of the malware, post-delivery, and their impact on the victimized environment.
Component: Malware loader script
The initial attack started with the execution of a batch file that executed PowerShell for further activity. This file is a batch script that is responsible for running multiple commands, shown below:
Figure 1: Malicious batch file contents
This file has very simple operations. It will look for a pre-established ASCII text file in the folder of C:\Windows\SysWOW64\. It will then read in the entire contents of that file, described below in Stage 2, and execute it. This file is entrenched into the system as a Windows service named “purebackup”, to ensure that the action is performed upon startup. The final character, “愀”, appears to be a Chinese hanji character, but it has no importance in the execution of the attack.
Component: Malicious code document
A text document is stored on the hard drive that contains the contents of known PowerShell code used for process injection using the publicly available PowerSploit script “Invoke-ReflectivePEInjection”. The earlier malicious batch file is responsible for reading in the entirety of text in this document and executing it, thus starting the ransomware process. Notably in this code is a reflective process injection that performs unique activity of injecting into the parent of the running process. Here, that is PowerShell.exe.
There were slight changes made to that file. Below are segments of code where there are differences from the malware, bolded, and the original code:
Figure 2: Abbreviated contents of stored PowerShell code
Notably, there were obfuscated additions and modifications of code used to ensure the malware is executed, shown below:
Figure 3: Original PowerShell code for AMSI bypass
There are various forms of obfuscation here, especially in the combination of rearranged strings. When cleaned up to make more readable, this code appears as:
Figure 4: Clean PowerShell code for AMSI bypass
This is an implementation of a known AMSI bypass, documented here. Specifically the six hex bytes are assembly operation codes (opcodes) that resolve to the code below:
Figure 5: Assembly code used to implement AMSI bypass
This small chunk of code replaces the AmsiScanBuffer() function, used by Windows AMSI to start scanning a PowerShell script, to return a hex value that equates to the Windows error of E_INVALIDARG, forcing AMSI to allow execution of the script.
This code is simply used to set the stage for the payload. Contained within the PowerShell code was a large set of Base64 data which was invoked with the PowerShell command “Invoke-SQLServ -PEBase64”.
Component: Ransomware Executable
The primary ransomware executable is run in memory as a fully qualified executable file. This malware performs a large number of system checks to configure itself, and the environment, for persistent execution.
As overall identification indicators, this ransomware will append each encrypted file with the extension of “.ReadInstructions” and place an HTML ransom note in every folder named “HOW_TO_RECOVER_DATA.html”.
This section will describe the overall actions taken by the malware and then additional detail for each on how it operates and, at times, why it is unique. One notable item about this ransomware is that it contains multiple debug messages. These are text strings inserted by the malware author to be printed to the screen during testing. Prior to final delivery, the malware author removed the function to print them to the screen. However, the messages remain with the prefix of “[LOCKER]”.
The malware performs a large amount of steps in its execution, more so than typical ransomware that we analyze. These include:
- Checking for a unique mutex
- Determining if user has administrative privileges and bypassing UAC
- Creating a registry key as a marker
- Creating persistence using a Windows Scheduled Task
- Terminating and deleting a set of predefined services
- Terminating a set of predefined processes
- Removing recovery data
- Emptying recycle bin
- Modifying SMB access
- Creating a list of files and folders to avoid encrypting
- Iterating through local volumes:
- Running Windows Restart Manager on each file to unlock it for encryption
- Encrypting file with AES-256 encryption key
- Iterating through the local network:
- Performing an ICMP ping against remote system to check connectivity
- Connecting via SMB, while avoiding hidden shares
- Encrypting remote files with the same AES-256 encryption key
Creating a Mutex
The malware contains a hard coded mutex of “{8761ABBD-7F85-42EE-B272-A76179687C63}”. This mutex is checked, and set, before any major activity takes place. A mutex is used by applications to register that they are currently running on the system. As any other application can access a mutex, this allows any subsequent execution of the malware to see if it is already running. If so, the new instance will simply terminate.
Figure 6: Code that shows the hardcoded mutex
Checking administrative privileges
The malware will next determine if it is running as an administrator privileged account or a regular user. This is done by checking its own execution in memory and seeing what privileges it has.
This is done using the typical method of opening its own process in memory and determining the user rights used to launch, using GetTokenInformation() as shown below.
Figure 7: Code that shows the method of checking administrative privileges
If the executable is not running as administrator, the malware will attempt to relaunch it after disabling UAC. This is done by using a known UAC bypass method, documented below.
Known UAC bypass method
Medusa Locker implements a known method for bypassing Windows’ User Account Control (UAC), a built-in security measure within Windows that prompts users to manually approve administrative actions. UAC bypasses have been long used for malware to surreptitiously run in the background without user visibility.
This bypass utilizes the CMSTP technique, discovered years ago, that leverages the Windows CMSTPLUA COM interface’s command execution method to run applications.
Figure 8: Code that shows the implementation of CMSTP UAC bypass
Creating Marker registry key
The malware will create a new key in the registry to store its file name, but not path location. This value is stored to: HKEY_CURRENT_USER\SOFTWARE\MDSLK\Self. It is not known the importance or usage of this registry key, but it’s an apparent abbreviation of “MeDuSa LocKer”. Similar keys have been used in other malware families as a method of determining if the machine has been compromised in the past or if it’s a new infection. Such markers have also been seen as simple vanity tagging, like graffiti on a wall.
Figure 9: Code that shows the creation of the marker registry key
Creating Persistence through Scheduled Tasks
The malware will create a scheduled task for continued persistence by utilizing the Windows task triggers. This is evidenced by the use of strings in a section of code used for scheduling a hidden task named “svhost”. This will point to a previously established copy of this malware stored in “%AppData%\Roaming\svhost.exe”. The values below refer to the “PT” structure, in which scheduled tasks are specified for timed intervals. In the case of this malware, it is set to “PT15M”, which causes it to run every 15 minutes.
Notably, this author used a formal method of creating a scheduled task using documented Windows programming APIs. While other malware use built-in Windows tools like schtasks.exe and at.exe, this author implemented a solution that mimics Microsoft’s example code almost exactly to create the task. The benefit to this implementation is that it can avoid many forms of behavioral detection that alert on executables running those commands directly.
Figure 10: Code that shows the creation of a scheduled task
The iteration period of 15 minutes is hard configured in the binary, appearing in execution as the configuration is being built:
Figure 11: Code that shows the scheduled task timer being written to the malware configuration
Terminating Services and Processes
Using a pre-established list of service names and process executables, shown below, the malware will begin to close and remove applications that may impair its ability to encrypt the system. It will start by detecting if a service name matches a predefined list, noted in the figure below. If a service is found, the malware will use Windows API calls to terminate it and delete it. These services relate to many security antivirus and business-related applications. The malware will then iterate through a list of executable file names and, if they are running on the system, terminate them.
The lists of services and processes are understandable for impairing the system, however it is noteworthy that the lists are almost identical to those used by Lockbit ransomware, with only slight differences such as additional processes.
Figure 12: Code that shows the set of services and processes to be terminated
In total, these services and processes are noted below:
| wrapper | Culserver | msmdsrv |
| DefWatch | RTVscan | tomcat6 |
| ccEvtMgr | sqlbrowser | zhudongfangyu |
| ccSetMgr | SQLADHLP | SQLADHLP |
| SavRoam | QBIDPService | vmware-usbarbitator64 |
| sqlservr | Intuit.QuickBooks.FCS | vmware-converter |
| sqlagent | QBCFMonitorService | dbsrv12 |
| sqladhlp | sqlwriter | dbeng8 |
Figure 13: List of services to terminate and delete from the system
| wxServer.exe | winword.exe | tomcat6.exe |
| wxServerView | QBW32.exe | java.exe |
| sqlservr.exe | QBDBMgr.exe | 360se.exe |
| sqlmangr.exe | qbupdate.exe | 360doctor.exe |
| RAgui.exe | QBCFMonitorService.exe | wdswfsafe.exe |
| supervise.exe | axlbridge.exe | fdlauncher.exe |
| Culture.exe | QBIDPService.exe | fdhost.exe |
| RTVscan.exe | httpd.exe | GDscan.exe |
| Defwatch.exe | fdlauncher.exe | ZhuDongFangYu.exe |
| sqlbrowser.exe | MsDtSrvr.exe |
Figure 14: List of processes to terminate if running
Removing recovery options
As is typical for most ransomware, Medusa Locker will run a series of Windows commands to alter the system to prevent easy recovery. In this case it uses a combination of “vssadmin” and WMI to remove all volume shadow copies – the built-in file system backups within Windows. It will also use the “bcdedit” command to prevent the system from being rebooted into Recovery Mode.
Figure 15: Code that shows the execution of system recovery limiting commands
Emptying the recycle bin
One of the early operations of the ransomware is to empty all contents of the Windows recycle bin. It is assumed to do this to prevent users from restoring any files that were later encrypted. However, this is a tactic that is uncommon and could just be a sign of how effective and complete the author wanted the destruction to be.
Figure 16: Code that shows the emptying of the Windows recycle bin
Modifying SMB connection settings
One feature of this ransomware is to change access to local SMB folder shares. This is done by changing one within the victim’s registry under SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Under this key, the value of EnableLinkedConnections is set to 0, or disabled. This allows network shares to be available for a user under both regular access and admin privileged access. This feature is disabled by this malware.
Figure 17: Code that shows the modification of the Windows SMB connection settings
Establish important folders to skip for encryption
During the file and folder enumeration process, the malware will determine if a found folder matches a set of known folders, with examples in the code below.
These appear to ensure that the services like Exchange and SQL Server are kept operational during encryption. Notably, this malware will skip and not encrypt any file, or the contents of any folder, with a “$” in the file or folder name. This may be in an attempt to avoid the effort of encrypting Microsoft Word temporary backup files or operating system backup folders like $Windows.~BT.
Figure 18: Code that shows the criteria of folders to avoid encrypting
Figure 19: Further code that shows the criteria of folders to avoid encrypting
Unlocking files through Windows Restart Manager
One unique aspect of Medusa Locker is its use of the Windows Restart Manager to ensure each file is accessible for encryption. This is necessary as many applications “lock” a file, preventing other applications from writing, or even reading, the contents. Typically, unlocking a file requires identifying the application that has the file open and terminating it. However, Windows has a built-in feature called Restart Manager that assists with that. The malware will use the Restart Manager API calls on each file to encrypt to determine if it is open and, if so, use these API calls to terminate the application. This ensures that as many files are encrypted as possible while performing safe, graceful closure of applications.
Figure 20: Code that shows the use of Windows Restart Manager to close applications
File encryption
Like many other ransomware families seen in the wild, Medusa Locker will utilize an embedded public key to perform AES-256 encryption on all file data. This public key is stored as a block of base64 data that represents the binary key shown below. There is no method within this implementation for the victim to decrypt their data without assistance from the ransomware group.
Figure 21: The encryption public key stored as base64 text
0000h: 0602 0000 00a4 0000 5253 4131 0008 0000 ........RSA1....
0010h: 0100 0100 57b3 7812 d351 daad 4b60 33f4 ....W.x..Q..K`3.
0020h: 823f 3659 9214 7248 1986 887b 5c29 f027 .?6Y..rH...{\).'
0030h: efe7 8fdb 6825 a015 ddb4 3af3 0487 c983 ....h%....:.....
0040h: 8ecf e414 7c78 d9f2 7e67 f096 1f51 09a1 ....|x..~g...Q..
0050h: c653 4f2e 2002 5f1d 96a9 1b8a 6099 44db .SO. ._.....`.D.
0060h: 3d65 03bf b9fe 6940 a7a1 996d ad7d b46d [email protected].}.m
0070h: e7a6 7663 058a ffb7 66ef b266 aca9 49fe ..vc....f..f..I.
0080h: bca1 101c c043 58a0 d1a1 5c72 599c f524 .....CX...\rY..$
0090h: 8bf5 fa3d 7814 e6f1 561f 8768 e897 b151 ...=x...V..h...Q
00a0h: b693 264f f3ea cf87 3686 21f7 bfaf ba1a ..&O....6.!.....
00b0h: cd9b 8e9c 1c6f 2c9b 74de 130e 9769 f2b5 .....o,.t....i..
00c0h: c227 cc80 8528 d55a 09a5 dcef 3f53 aaee .'...(.Z....?S..
00d0h: 6298 f622 89f0 7db6 587c dbc4 f8f2 aa75 b.."..}.X|.....u
00e0h: ecd2 45ef 3947 93bb f7be fbbc f8bd 8ac9 ..E.9G..........
00f0h: a720 ed1a 8c7d d574 9a36 cf27 5a2a 74df . ...}.t.6.'Z*t.
0100h: 2098 46d1 66cf 6b16 fbc9 93f8 66a3 2553 .F.f.k.....f..%S
0110h: c9f8 4cb3 ..L.
|
Figure 22: Base64 decoded Public Key
Network enumeration and file assessment:
The malware has a networking component where it will establish connections to remote systems on the local network and look for SMB shares. This process first involves sending an ICMP “Ping” to each system in order and checking for a response.
Figure 23: Code that shows the use of ICMP pings to remote systems
The malware will then scan that system for any open SMB shares. It will ignore shares with a “$” in their name, symbolizing hidden shares, and add the remainder to a list for later encryption.
Figure 24: Code that shows the scanning of SMB shares and exclusion of hidden shares
Figure 25: Data in memory showing the list of SMB shares from a remote system
Once a share meets demands for encryption, the files will be iterated through for encryption.
Figure 26: Data in memory showing the access to a SMB share on a remote system to encrypt
Appendix: Additional specifications / IOCs
In the analysis of this malware, a set of basic indicators were found and stored below.
Figure 27: Malware loader script metadata
Figure 28: Malicious code document metadata
Figure 29: Injected ransomware executable metadata
Figure 30: Ransom note displayed to user as HOW_TO_RECOVER_DATA.html
