MedusaLocker Ransomware — Technical Analysis

MedusaLocker is a human-operated ransomware family that has been hitting healthcare, education and enterprise targets since 2019. This variant is notable for how thoroughly it prepares the ground before encrypting: it escalates through a CMSTPLUA COM UAC bypass, disables UAC entirely, stops and deletes interfering services, kills processes holding file locks, and destroys recovery options through three separate mechanisms rather than the usual single vssadmin call. Only then does the AES-256/RSA encryptor run — and a networking module hunts SMB shares so the damage does not stop at the local host.

This post walks through the full reverse engineering of the MedusaLocker payload, technique by technique, with the disassembly screenshots taken during the analysis.

Scope: stages 1 and 2 — initial access via maldoc and execution through a batch script that invokes PowerShell — are not covered here. This analysis targets the stage 3 ransomware executable itself.

⚠️ Note: This is a re-write by AI, but have been vetted by Author.

📄 The original report is also available as a PDF. Samples (password infected), recreated TTP code and detection rules are in the GitHub repository.

Key findings

MITRE coverage at a glance

The MedusaLocker executable touches an unusually wide span of the ATT&CK matrix. The sandbox mapping from a public report gives a sense of the breadth before diving in:

Mutex

MedusaLocker opens with the most common ransomware housekeeping step: a unique mutex so only one instance runs at a time. This matters more than usual here — the scheduled task re-executes the binary every 15 minutes, and worm-like families risk re-infecting themselves.

The disassembly (from a stripped binary) shows three functions:

1. A print subroutine that would emit [Locker] Is running — disabled in this build.
2. A string-format function that builds the unique mutex name.
3. The call that actually creates the mutex.

Privilege escalation: CMSTPLUA UAC bypass

Before any critical operation, MedusaLocker escalates locally by abusing COM objects to bypass UAC — specifically the well-documented CMSTPLUA COM interface bypass.

The CLSIDs reference the WScript shell exec object, used to run the attacker’s command with elevation. In the stripped binary the functions are meaningless; after renaming the functions and parameters, the intent becomes obvious:

ATT&CK mapping

• Tactic: Privilege Escalation
• Technique: Abuse Elevation Control Mechanism
• Sub-technique: Bypass User Account Control (T1548.002)

Defacement: the MDSLK marker

A genuinely unusual behaviour: MedusaLocker plants a marker registry key recording that the system has been infected.

HKEY_CURRENT_USER\SOFTWARE\MDSLK\Self

MDSLK is almost certainly shorthand for Medusa Locker. The operational purpose is not clear — it may be a defacement gesture, or simply a flag the operators use to identify their own victims. Either way it is a high-fidelity host artefact, precisely because it is so specific and has no benign equivalent.

ATT&CK mapping

• Tactic: Impact
• Technique: Defacement
• Sub-technique: Internal Defacement (T1491.001)

Persistence: a hand-rolled scheduled task

Most malware reaches for at.exe or schtasks.exe — both heavily monitored. MedusaLocker instead schedules its task programmatically in C++, using the official Microsoft Task Scheduler API straight from the MSDN sample code.

The sequence:

1. Copy itself to %APPDATA% as svhost.exe — a deliberate near-miss for the legitimate svchost.exe.
2. Register a scheduled task that re-executes it every 15 minutes, indefinitely.
3. On each re-execution, the mutex check ensures that if an instance is already running, the new one exits and lets the original continue.

This is why the mutex exists at all — persistence and single-instancing are two halves of the same design.

ATT&CK mapping

• Tactic: Persistence
• Technique: Scheduled Task/Job
• Sub-technique: Scheduled Task (T1053.005)

Defense evasion: disabling UAC

Having escalated via CMSTPLUA, MedusaLocker can now make system-wide changes — and the first one is to switch UAC off entirely through the registry:

The author deliberately set both: if the first fails, the second guarantees UAC is disabled once the machine reboots.

ATT&CK mapping

• Tactic: Defense Evasion
• Technique: Impair Defenses
• Sub-technique: Disable or Modify Tools (T1562.001)

Service stop and process termination

To ensure nothing holds a file lock or interrupts encryption, MedusaLocker enumerates a predefined set of services and processes and shuts them down. The list is recoverable through simple static string analysis:

Two mechanisms are used:

• Services — Windows Service Control Manager APIs to stop and, notably, delete the services outright. Stopping is common; deleting is not, and it makes recovery harder even after the ransomware is removed.
• Processes — the standard toolhelp trio: CreateToolhelp32Snapshot, Process32First, Process32Next.

ATT&CK mapping

• Tactic: Impact → Technique: Service Stop (T1489)
• Tactic: Defense Evasion → Technique: Impair Defenses: Disable or Modify Tools (T1562.001)

Inhibit system recovery

Where most ransomware settles for deleting shadow copies, MedusaLocker attacks recovery from multiple angles:

• vssadmin — delete shadow copies
• wbadmin — delete Windows Backup catalogs, a second and independent path
• bcdedit.exe — disable boot into recovery mode, preventing repair options
• Empty the recycle bin — closing the last easy restore route

Every one of these is launched through CreateProcessW, which treats the first whitespace as the boundary between process name and arguments. The subroutine sub_41E9A0 is the one spawning them:

ATT&CK mapping

• Tactic: Impact
• Technique: Inhibit System Recovery (T1490)

Encryption

MedusaLocker uses symmetric encryption for speed, wrapped in asymmetric encryption for control — the standard hybrid ransomware design:

The scheme:

1. A base64-encoded RSA public key is embedded in the binary (recoverable with FLOSS).
2. It is converted to binary form with CryptStringToBinaryA for use by the crypto APIs.
3. A random AES-256 key is generated per file using CryptGenKey.
4. That symmetric key is encrypted with the embedded RSA public key and written into the HTML ransom note — so only the attacker’s private key can recover it.
5. The encryptor then runs, honouring a list of folders and extensions to skip (visible in the extracted strings just below the public key) so the host stays bootable and payable.

ATT&CK mapping

• Tactic: Impact
• Technique: Data Encrypted for Impact (T1486)

Discovery and lateral movement

MedusaLocker carries a networking module that extends the blast radius beyond the local machine:

1. Send an ICMP ping to each system in the local network, sequentially.
2. For every host that responds, enumerate SMB shares.
3. Exclude hidden shares (those containing $ in the name).
4. Accumulate the remaining shares into a list — queued for encryption later.

ATT&CK mapping

• Tactic: Discovery → Technique: Network Share Discovery (T1135)
• Tactic: Lateral Movement → Technique: Remote Services: SMB/Windows Admin Shares (T1021.002)

Recreated TTPs and detections

Every technique below is paired with a detection rule or query. Most are recreated here as buildable C++; where the technique is long-established public research, the row points at the original author’s implementation instead. Links go to the write-up first, then the detection notes, then the source.

See the full project matrix on the ATT&CK coverage page.

Detection opportunities

• HKCU\SOFTWARE\MDSLK\Self created — the single most specific indicator in this entire chain. There is no legitimate reason for this key to exist; alert on it outright.
• EnableLUA or ConsentPromptBehaviorAdmin set to 0 — rare, high-impact, and almost always malicious outside of deliberate admin action.
• A process copying itself to %APPDATA%\svhost.exe — note the missing c; svchost.exe should only ever live in System32.
• Task Scheduler task created via the COM API rather than schtasks.exe, particularly one repeating every 15 minutes and pointing into %APPDATA%. Watch for the Task Scheduler operational log rather than process creation, since no schtasks.exe will appear.
• vssadmin Delete Shadows, wbadmin delete catalog, bcdedit /set {default} recoveryenabled No — any one of these deserves an alert; all three in sequence is a confirmed ransomware detonation.
• Service deletion following service stop — stopping services is noisy but common; deleting them is not.
• CMSTPLUA COM elevation — a moderate-integrity process instantiating the CMSTPLUA CLSID and spawning an elevated child.
• ICMP sweep of the local subnet followed by SMB share enumeration from a workstation process, especially immediately preceding heavy file I/O.
• Mass file modification with ransom note HTML files appearing across directories.

Per-technique detection rules and queries — with Sysmon, Defender and audit log screenshots — are published alongside each recreated TTP in the table above.

Indicators of compromise

Hash (SHA-256)

26af2222204fca27c0fdabf9eefbfdb638a8a9322b297119f85cce3c708090f0

Host artefacts

HKCU\SOFTWARE\MDSLK\Self                    infection marker (defacement)
%APPDATA%\svhost.exe                        persistence copy
Scheduled task repeating every 15 minutes   persistence, created via COM API
HKLM\...\Policies\System\EnableLUA = 0      UAC disabled
HKLM\...\Policies\System\ConsentPromptBehaviorAdmin = 0
HTML ransom note                            contains the RSA-encrypted AES key

⚠️ The sample in this repository is live ransomware, stored in an archive with the password infected. Detonate only inside an isolated, network-controlled VM with no access to production data or network shares — this family actively looks for SMB shares. See SECURITY.md.

Disclaimer

The artifacts, code and analysis in this repository are provided strictly for educational and research purposes. I do not condone or support any malicious use of this material.

← Back to all analyses