Summary:

• • Howler Cell investigated the new v3 variant of MedusaLocker, the well-known ransomware family active since late 2019. This ransomware is also known as the BabyLockerKZ variant.
    
    
• Industry Impact
  
  
  • Healthcare, Finance, Government, and Manufacturing sectors are impacted. Regardless of past victimology, any industry or company is at risk of this threat.
    
    
• Systems & Operations Impact
  
  
  • The group or groups that deploy MedusaLocker have been known to conduct brute-force attacks against open or exposed RDP (Remote Desktop Protocol) to gain an initial foothold in their victims' environments.
  • Rapidly encrypts local and network data using AES-256, deletes backups, halts databases, steals sensitive files for double extortion, and operates without command-and-control servers to maximize damage.
  • Common campaigns are delivered through stolen credentials, exposed VPN/edge vulnerabilities, malspam containing malicious attachments or download links.
    
  
  
• Threat Actor Capability Improvement
  
  
  • Increased blast radius with functionality to parse CIDR notation and work with entire subnets.
  • Multi-threaded encryption allows for simultaneous encryption across disks and mapped shares, increasing impact in large environments.
  • Ability to mount volumes that are hidden or unmounted.
  • Advanced anti-debugging techniques to detect time manipulation.

• How to Mitigate
  
  
  • Maintain offline backups
  • Patch systems
  • Secure RDP/VPN access,
  • Employ MFA
  • Monitor external attack surface
  • Train employees on best practices
  • Deploy tools that detect ransomware behavior.

Overview:

Howler Cell has been tracking and investigating the new variant of MedusaLocker. MedusaLocker is a well-known ransomware family active since late 2019. This malware continues to evolve with new variants. v3 incorporates advanced anti-analysis tricks, improved persistence, multi-threaded encryption, and process/service targeting to maximize impact. The MedusaLocker v3 variant is also known as BabyLockerKZ.

This investigation shows the detailed analysis of MedusaLocker v3, based on a command-line sample from a threat landscape perspective. v3 signals MedusaLocker’s adaptation to modern defenses, shifting toward modular design, customizable command-line operations, and stronger evasion traits that align it with more mature ransomware-as-a-service (RaaS) operations.

The group(s) that deploy MedusaLocker have been known to conduct brute-force attacks against open or exposed Remote Desktop Protocol (RDP) to gain an initial foothold in their victims' environments. Sectors impacted include Healthcare, Finance, Government, and Manufacturing. Regardless of past victimology, any industry or company is at risk of this threat.

MedusaLocker Evolution Timeline:

Below is an overview of MedusaLocker from its initial release to advanced v3 variants.

Technical Analysis

Initial Access & Delivery:

While this analysis focuses on the execution stage, MedusaLocker campaigns are typically delivered through:

• Brute-force attacks or stolen credentials for RDP/SMB.
• Exploitation of exposed VPN/edge vulnerabilities.
• Malspam containing malicious attachments or download links.

These methods give attackers an initial foothold, after which the MedusaLocker payload is deployed manually or via loaders.

Execution Flow & Command-Line Arguments:

MedusaLocker v3 accepts three arguments:

• -network → encrypt across network shares.
• -shares=<path> → encrypts specified network shares.
• -path=<path> → encrypts a specific path.

If no arguments are provided, MedusaLocker defaults to local volume enumeration and mounts additional targets discovered dynamically.

Configuration Loading:

Configuration and settings are embedded in the binary as encrypted resource data. Decryption key: PUTINHUILO1337 Decryption routine uses a custom XOR loop with modulus-based index calculation:

Figure 1 Config Decryption Routine

The configuration blob is decrypted directly into memory, after which it is parsed to extract the encryption keys, ransom note, excluded paths, and runtime commands. Once loaded, the ransomware interprets this configuration and executes the specified actions accordingly. Figure 1 shows the config decryption routine.

MedusaLocker creates a registry key under HKCU\SOFTWARE\PAIDMEMES as shown in Figure 2 and stores values labeled Public and Private. The labels PUBLIC and PRIVATE suggest the malware may be storing configuration values (like encryption keys, tokens, or settings).

Figure 2 Creates Registry in HKCU\SOFTWARE\PAIDMEMES

Persistence Mechanism:

To achieve persistence on the infected system, the Medusalocker creates a registry entry under HKCU\Software\Microsoft\Windows\CurrentVersion\Run with the value name BabyLockerKZ pointing to its executable path as shown in Figure 3. This ensures the malware will automatically execute every time the user logs in, maintaining a foothold on the system.

Figure 3 Creates persistence with value as BabyLockerKZ

File Encryption:

MedusaLocker uses an embedded public key to carry out AES-256 encryption on victim files. This public key is written in base64 encoded form in the config file. Due to the way the implementation is designed, victims have no means of decrypting their files without obtaining the corresponding private key from the ransomware operators.

Command Execution (Sysnative Bypass):

To execute attacker-controlled commands, the malware employs a Sysnative cmd.exe bypass. Instead of launching commands directly, it constructs the following chain, as shown in Figure 4

\SysWOW64\cmd.exe /c %windir%\sysnative\cmd.exe /c <command>

Figure 4 Sysnative bypass string

This technique allows a 32-bit malware process to run commands in a 64-bit command interpreter, thereby avoiding Windows WOW64 redirection. Each command is executed asynchronously, with its output captured and processed by the malware.

This approach ensures that all attacker instructions execute in the intended 64-bit environment, making the malware more versatile and resilient across Windows architectures.

Drive Enumeration:

Before starting file encryption, MedusaLocker enumerates all available logical drives on the victim’s system. This is done through a call to the Windows API GetLogicalDrives, which returns a bitmask representing the drives present (A: through Z:). Figure 5 shows how logical drives are enumerated.

For each active drive letter, the malware:

• Builds the path string (e.g., C:\, D:\) dynamically.
• Checks the drive type with GetDriveTypeW.
• Filters for removable, fixed, and network drives, while skipping invalid or unknown types.
• Converts the path into a \\?\ format, which allows handling of long file paths.
• Stores the resulting drive paths in an internal list for later use in the encryption routine.

Figure 5 Logical Drives Enumeration

Running Self-Process with -network Command (Non-Elevated):

By default, if MedusaLocker is executed without any command-line arguments, it limits its encryption scope to local volumes. As part of this, it also attempts to mount unassigned or hidden volumes dynamically, ensuring no local target is missed.

However, the malware relaunches itself with the -network command line argument, and it explicitly expands its scope to include network resources such as mapped drives and accessible UNC paths. To achieve this stealthily, MedusaLocker:

• Re-executes itself with the additional -network argument.
• Runs the new instance non-elevated with Explorer.exe set as the parent process, blending into normal user activity and avoiding suspicion.

This dual execution strategy allows MedusaLocker to cover both attack surfaces:

• Base execution (no arguments): Ensures local encryption by mounting hidden/unassigned volumes.
• Secondary execution (-network): Enables lateral movement-like behavior by encrypting files across network shares.

In short, the -network argument is the malware’s switch to extend ransomware impact beyond the infected host to the broader enterprise environment. Figure 6 explains how the non-elevated child process is executed with a spoofed parent process

Figure 6 Non-elevated child process with a spoofed parent process

Mapped Network Drive Enumeration:

In addition to local drives, MedusaLocker also attempts to discover and encrypt files stored on mapped network drives with the above technique. The malware reuses the same GetLogicalDrives API to iterate over drive letters, but applies an extra filter using GetDriveTypeW. Only drives of type DRIVE_REMOTE (4) are considered, which indicates a mapped network location. Figure 7 shows enumerations of mapped network drives via WNetGetConnectionW.

For each mapped drive found:

• The malware calls WNetGetConnectionW to resolve the remote UNC path (e.g., \\Server\Share).
• If the API succeeds, the resolved network path is copied into an internal buffer and stored in the ransomware’s target list.
• These collected paths are later traversed during the encryption routine to maximize damage by hitting shared resources.

Figure 7 Enumerating mapped network drives via WNetGetConnectionW

If WNetGetConnectionW fails, the malware even prints a debug-style message to the console:

[!] WNetGetConnection failed 0x%X

This suggests the sample was either compiled with leftover debugging output or the developers wanted runtime visibility during testing, as shown in Figure 8.

Figure 8 Debug-style console message

Mounting Volumes to Drive Letters:

MedusaLocker contains functionality to mount volumes that do not currently have a drive letter assigned, effectively making otherwise hidden or unmounted storage accessible for encryption.

The routine leverages several Windows APIs:

• GetVolumePathNamesForVolumeNameW – retrieves possible path names for the given volume.
• GetLogicalDrives + GetDriveTypeW – searches for unused drive letters (e.g., E:\, F:\) by checking for DRIVE_NO_ROOT_DIR.
• SetVolumeMountPointW – assigns the volume to an available drive letter.

If the mounting succeeds, the malware prints a success message to the console:

[+] Mounted: <VolumeGUID> -> <DriveLetter>

If it fails, it reports an error instead:

[!] Not mounted: <VolumeGUID> -> <DriveLetter>, error: 0x%X

By mounting previously hidden or system-reserved volumes, the ransomware increases its attack surface, ensuring that it encrypts not just visible drives but also volumes that might normally be overlooked by users and security tools. Figure 9 shows how volumes gets mounted.

Figure 9 Volume mounting routine

Classless Inter-Domain Routing Parsing and Network Awareness:

MedusaLocker v3 doesn’t just stop at handling plain IPv4 addresses, it also includes functionality to parse CIDR (Classless Inter-Domain Routing) notation, which allows it to work with entire subnets rather than just individual hosts. This is a clear indication that the ransomware is designed with network-wide reach in mind.

In this MedusaLocker v3 variant, we did not observe any Command-and-Control (C2) communication with external servers. Instead, its design is purely focused on ensuring it can reach as many machines as possible within the victim’s environment, leveraging subnet awareness to maximize encryption impact.

Multi-Threaded Encryption: Scaling the Thread Pool

One of the reasons MedusaLocker v3 encrypts victim environments so quickly is its ability to dynamically scale the number of worker threads during runtime. The function responsible for this behavior, internally referenced as ThreadPoolSetWorkerCount, acts as the ransomware’s custom thread pool manager, as shown in Figure 10.

Figure 10 ThreadPoolSetWorkerCount routine

Instead of relying on a single-threaded encryption routine, MedusaLocker v3 intelligently distributes the workload across multiple threads. This achieves two critical goals:

• Performance – Files across local disks and mapped network shares are encrypted simultaneously, drastically reducing the time before victims notice the attack.
• Impact – Multi-threaded design allows the ransomware to maximize damage, especially in enterprise environments with large storage.

Anti-Debugging Checks:

MedusaLocker v3 incorporates well-known anti-debugging techniques to evade analysis. One such routine, internally referenced as AntiDebug_Check, utilizes high-resolution timing checks to detect abnormal execution conditions.

To enhance reliability, the routine combines two independent timers:

• MW_QueryPerfCounter (analogous to QueryPerformanceCounter)
• Xtime_get_ticks (A system tick counter in nanoseconds)

By comparing these sources, MedusaLocker can detect time manipulation often used by debuggers to slow down execution or bypass anti-analysis checks, as shown in Figure 11.

Figure 11 Anti-Debug Checks

Insights from the Config:

Configuration shown in Figure 12 reveals the ransomware’s strategy, exclusions, and runtime actions.

Figure 12 Medusalocker Ransomware Configuration

Pre-Infection / Anti-Recovery Behavior:

MedusaLocker v3 executes a large set of commands before beginning encryption to disable recovery mechanisms and stop database services. These include:

• exe Delete Shadows /All /Quiet
• wbadmin delete backup -keepVersion:0 -quiet
• wbadmin DELETE SYSTEMSTATEBACKUP
• wbadmin DELETE SYSTEMSTABACKUP -deleteOldest
• exe SHADOWCOPY /nointeractive
• exe /set {default} recoverynabled No
• exe /set {default} bootstatuspolicy ignoreallfailures

It also terminates SQL-related processes to maximize impact against enterprise workloads:

• taskkill -f -im sqlbrowser.exe
• taskkill -f -im sqlserv.exe
• taskkill -f -im msmdsrv.exe
• taskkill -f -im Ssms.exe
• taskkill -f -im SQLAGENT.EXE
• taskkill -f -im ReportingServicesService.exe
• taskkill -f postgres.exe

By doing this, MedusaLocker ensures databases are offline and their backups unrecoverable, making ransom payment the only way to recovery.

Encryption Strategy:

The config defines block sizes for partial encryption:

• nEncryptionBlockBytes = 750016
• nEncryptionSkipBytes = 250048
• nEncryptionLimitBytes = 7707136

Meaning: files are encrypted in chunks instead of fully, which increases speed while keeping files unusable.

Encrypted files are appended with the extension:

• sEncryptedFileExtension = ".meduza216"

Exclusions (Skip Rules)

To avoid system instability and allow remote control tools to keep functioning, MedusaLocker skips certain file types and paths.

Skipped file extensions:

.exe, .dll, .sys, .ini, .rdp, .lnk, .bmp, .mov, .cab, .url, .vsix, .msi, .pyc, .pyd

Skipped directories:

• C:\Intel
• C:\Dell
• C:\AMD
• C:\Drivers
• C:\inetpub
• C:\ProgramData\AnyDesk
• C:\Program Files
• C:\Program Files (x86)

This reflects a targeted strategy: only business-critical data is encrypted, while OS and remote admin software remain untouched.

Ransom Note & Victim Communication:

Figure 13 Ransom Note

The ransom note shown in figure 13 (How_to_back_files.html) instructs victims to contact the attackers and is copied into every encrypted directory as well as the victim desktop.

Emails used:

• ithelp01@securitymy[.]name
• ithelp01@yousheltered[.]com

Onion site:

qd7pcafncosqfqu3ha6fcx4h6sr7tzwagzpcdcnytiw3b6varaeqv5yd[.]onion

The note threatens:

"We gathered highly confidential/personal data… If you decide to not pay, we will release your data to public or re-seller.”

This clearly shows MedusaLocker v3 is operating under the double extortion model (encryption + data theft).

MITRE ATT&CK Mapping for MedusaLocker v3:

Indicators of Compromise (IOCs):

Detection & Mitigation Strategies:

Detection

• Watch for suspicious LOLbin events and network communication.
• Monitor registry changes that make programs auto-start.
• Alert on mass file renaming (e.g., .meduza216).
• Look for unusual network drive access or hidden volume mounting.

Mitigation

• Keep offline backups (not connected to your network).
• Patch systems and secure RDP/VPN access.
• Use strong passwords + MFA everywhere.
• Segment networks to stop ransomware from spreading.
• incorporate employee best security practice trainings.
• Use security tools that detect ransomware behavior.

Conclusion:

MedusaLocker v3 shows how ransomware continues to evolve with smarter features, network-wide reach, and double extortion tactics. This variant avoids relying on external servers, instead focusing on spreading across every possible machine in the victim’s network. Its advanced persistence, multi-threaded encryption, and anti-recovery tricks make it especially dangerous for organizations.

Back to Top