MedusaLocker Ransomware: Attack Lifecycle, MITRE ATT&CK TTPs, and Incident Response Guide

MedusaLocker is a Ransomware-as-a-Service (RaaS) operation first observed in September 2019 that primarily reaches victims through exposed Remote Desktop Protocol (RDP) endpoints.

This article is a standalone reference for incident response teams, MSPs, and security decision-makers. If MedusaLocker is active in your environment, our 24/7 incident response team can help you contain and scope it.

MedusaLocker ransomware at a glance

Live leak-site data (as of September 1st, 2026)

MedusaLocker remains active as of August 2026, with its leak site currently listing 88 publicly claimed victims across 22 countries (most recently updated August 27).

In the 30 days before this snapshot, the group added roughly nine victims. Its top three sectors by claimed count are Manufacturing (~17%), Technology (~16%), and Professional Services (~16%).

Disclaimer: Victim listings on ransomware leak sites represent unverified claims made by the threat actor. Treat them as unconfirmed unless corroborated by company disclosures, SEC filings, regulatory notifications, or law enforcement confirmation. Leak-site totals also undercount real activity, because many victims are extorted without ever being listed.

What is MedusaLocker ransomware?

MedusaLocker is a Windows-focused ransomware family that shifted to an affiliate-driven RaaS model as it matured. The joint CISA, FBI, and FinCEN advisory AA22-181A documents it and remains the canonical government reference for its tradecraft.

Attribution remains at moderate confidence. While widely linked to Russian-speaking cybercrime, public reporting has not confirmed specific individuals.

The family is best understood as a durable, opportunistic operation: it does not chase novel exploits, relying instead on the most common enterprise exposure in existence, and has outlasted most of its 2019-era peers.

MedusaLocker is not the same threat as Medusa (also covered on our blog). Medusa (tracked by Microsoft as Storm-1175 and cataloged in MITRE ATT&CK as S1244) emerged later and runs the separate "Medusa Blog" leak site. They are distinct codebases with separate infrastructure. MedusaLocker has no dedicated ATT&CK software entry.

How the MedusaLocker RaaS model works

MedusaLocker splits ransom proceeds on a fixed schedule: affiliates keep roughly 55%–60% of a payment, and the core developers take the remaining 40%–45%. The developers maintain the builder, the leak infrastructure, and the decryption tooling; affiliates perform the intrusion and deployment. This is a textbook Ransomware-as-a-Service division of labor.

Forensic consequences matter more than economics. Magdy Abdelaziz, Proven Data's Head of DFIR, notes that the ransomware operator is rarely the initial intruder. An access broker often steals and sells the credentials first. Consequently, initial log activity can predate payload detonation by weeks, or even months, though same-day handoffs also occur.

For MedusaLocker, whose entry point is so often a brute-forced RDP account, an investigation limited to the encryption event will routinely miss the true intrusion timeline.

Who MedusaLocker targets

MedusaLocker targets opportunistically across sectors. It prioritizes organizations with exposed remote-access services and valuable operational or customer data.

Geographically, the United States, Germany, the United Kingdom, France, and Canada lead the current leak-site listings.

MedusaLocker attack lifecycle

MedusaLocker intrusions follow a consistent operational sequence; deployments vary by affiliate. The phases below reflect behavior documented in CISA AA22-181A.

Phase 1: Initial Access

MedusaLocker gains access primarily through exposed RDP, via password brute-forcing, credential stuffing, or exploitation of unpatched vulnerabilities on internet-facing hosts.

Phishing and malspam carrying executable attachments or malicious document loaders are a documented secondary vector.

Phase 2: Execution and Privilege Escalation

MedusaLocker uses batch scripts (.bat) to launch PowerShell that performs Reflective PE Injection via Invoke-ReflectivePEInjection, loading code directly into memory.

It modifies the EnableLinkedConnections registry key, allowing elevated processes to access mapped drives created under standard user contexts. Restarting the LanmanWorkstation service then forces this change immediately.

Phase 3: Discovery

The malware sweeps for reachable hosts using ICMP (ping) and enumerates network shares and attached storage over SMB (port 445). This is how it locates the file shares and backup targets it will encrypt.

Phase 4: Defense Evasion

MedusaLocker attempts to stop and kill security, forensic, accounting, and database processes and services from the command line.

In some deployments, it reboots the host into Safe Mode with Networking, where most endpoint detection and response (EDR) agents do not load, and runs the encryptor there to avoid active monitoring.

Phase 5: Lateral Movement

Using harvested credentials, affiliates move laterally over RDP and SMB/Windows admin shares to extend reach across the domain before deployment.

Phase 6: Data Exfiltration

MedusaLocker steals data before it encrypts, making every incident a confirmed data breach rather than a file-availability event. Affiliates stage and exfiltrate using tools such as Rclone or MegaSync or PowerShell, then proceed to encryption only after the exfiltration is complete.

Phase 7: Encryption

MedusaLocker encrypts file contents with AES-256 in CBC mode and protects the per-file AES keys with RSA-2048.

A background thread re-runs every 60 seconds to discover and encrypt newly added files or freshly attached drives, so an incompletely isolated host keeps losing data after the first pass.

The encryptor skips system-critical paths, .exe, and .dll files to keep the host bootable enough to display the ransom note.

Phase 8: Inhibit Recovery and Extortion

Before or during encryption, MedusaLocker destroys local recovery options: it deletes Volume Shadow Copies, disables Windows startup repair, then drops HOW_TO_RECOVER_DATA.html and directs victims to a Tor negotiation portal.

Abdelaziz notes that the clearest indicator is a rapid cluster of events: disabled security tools, deleted shadow copies, accessed backup consoles, lateral remote execution, and staged payloads. When these occur within minutes of each other, responders should treat the event as an active ransomware deployment rather than isolated activity.

Extortion model and leak site

MedusaLocker runs a double-extortion operation: it encrypts to disrupt availability and threatens to publish stolen data to compel payment. Non-paying victims are named on a Tor leak site and stolen files are released or offered for sale.

Ransom demands in recent listings have ranged from tens of thousands to hundreds of thousands of dollars, stated in Bitcoin.

Pre-encryption exfiltration is standard for mature operators. The threat of leaking data creates maximum leverage when the stolen files are regulated, legally sensitive, or operationally critical.

That framing matters because payment does not reliably retract exposure, as deletion promises from criminal operators are unverifiable and have failed publicly and repeatedly.

Indicators of compromise

IOCs are grouped by type so responders can lift the block they need. MedusaLocker rotates campaign-specific artifacts; verify against the latest advisory and your own telemetry.

File and encryption indicators

Behavioral indicators

Network and contact indicators

Representative file hashes (SHA-256)

012657c4548d9c98223caa4cc7aa52fc083d6983d42fde16ca3271412e7fe3fe

1e9246e6a35731143368eaa0ade4f3cf576d6b22e6090152f6e94f1fa3070651

270c3354b3ee2940b499e365eaba143fba9d458f434dc38e663dc0f08e96121e

48046fb0e566f5a2d184f84b76d6cadc458762556daed0ae4a3a1200afbefb54

63eb3d2886d9cb880c9b0d54b94f3e149b3b5b6215a33a0ef63588a09dcd4499

b8c994e3ed7dcc9080916119ddc315533c129479f508676d7544b82b2e24745f

MITRE ATT&CK mapping

The techniques below are mapped at the ATT&CK technique level.

Detection and threat hunting

The highest-signal detection opportunity is the recovery-inhibition and defense-evasion cluster, because it fires only seconds to minutes before mass encryption. Instrument for it directly rather than relying on file-write volume alerts, which arrive too late.

• Recovery tampering: alert on vssadmin ... Delete Shadows, wmic shadowcopy delete, and any bcdedit invocation touching recoveryenabled or bootstatuspolicy. Legitimate use is rare and easily allow-listed.
• Reflective PowerShell: hunt for Invoke-ReflectivePEInjection and for powershell.exe spawned by cmd.exe/.bat parents with encoded or download-cradle arguments.
• Persistence: flag new scheduled tasks or Run keys (MSFEEditor) pointing at %APPDATA%\Roaming\svhost.exe or svhostt.exe (the legitimate Windows process is svchost.exe).
• Config tampering: monitor changes to EnableLinkedConnections, restarts of LanmanWorkstation, and unexpected reboots into Safe Mode.
• Discovery noise: correlate ICMP sweeps and SMB share enumeration from a single host against the account, time, and parent process; the differentiator between an admin and an intruder is context, not the tool.

What to do if MedusaLocker is active in your environment

If encryption is underway, the first hour determines whether recovery takes days or weeks. The goal is deliberate containment that preserves the assets and evidence recovery depends on.

Isolate deliberately, not destructively

Abdelaziz's guidance from live engagements is to sever network connectivity aggressively, switch ports, VLANs, and VPN concentrators, rather than powering machines off, and to isolate domain controllers and backup repositories first. He frames the reasoning plainly: recovery duration usually depends not on how much data was encrypted, but on whether Active Directory and backup infrastructure survive in a state you can still trust. Pull network cables, not power cords, and treat everyday channels like email and Teams as compromised.

Preserve evidence before remediation

Capture volatile data, logs, and encrypted samples first. See our guide on ransomware incident response actions.

Hunt persistence before restoring

Enumerate scheduled tasks, Run keys, and any modified GPOs. Remove MedusaLocker's %APPDATA%\Roaming scheduled task and MSFEEditor key, or a rebuilt host will be re-compromised.

Rotate credentials at scale

As the access was likely brokered and credentials likely stolen, reset domain accounts (including krbtgt), revoke sessions, and close MFA gaps before reconnecting anything.

Sequence recovery around trust

Rebuild identity and backup infrastructure to a known-clean state first; validate that restored systems are free of the persistence mechanisms above before returning them to production.

Engage counsel and assess regulatory exposure

Confirmed exfiltration triggers breach-notification obligations; involve legal counsel and your incident response provider early.

Can files encrypted by MedusaLocker be recovered?

No free public decryptor exists for MedusaLocker. The ransomware uses a sound AES-256 + RSA-2048 hybrid scheme, and current variants have no known cryptographic flaw that would allow decryption without the operators' private key.

Three realistic recovery paths exist:

1. Restoration from backups that were offline, immutable, or otherwise outside the blast radius. This is the only dependable option, and MedusaLocker actively tries to foreclose it by deleting shadow copies and hunting backup consoles.
2. The attacker's own decryptor, provided after payment. DO NOT PAY THE RANSOM. Paying carries legal and sanctions risk and offers no guarantee of full or clean recovery.
3. Recovering unencrypted remnants, mismanaged shadow copies, or data on segments the encryptor never reached, which is case-dependent and usually limited once the recovery-inhibition commands have run.

Security checklist

Each control below maps to a technique MedusaLocker actually uses in the attack chain described here.

• Eliminate or gateway external RDP. Direct internet-facing RDP is MedusaLocker's primary entry (T1133); place remote access behind a VPN with enforced MFA and IP allow-listing.
• Enforce MFA, don't merely offer it. Credential brute-forcing and the ~36% infostealer overlap on victim domains make single-factor remote access the core exposure. The system has to require MFA for it to limit human error.
• Segment and restrict internal SMB and ICMP. Constraining port 445 and ping between segments blunts discovery (T1018, T1135) and lateral movement (T1021.002).
• Isolate backups on separate identity. Store immutable or offline backups whose credentials do not authenticate against the primary domain; MedusaLocker deletes shadow copies and enumerates backup infrastructure before encryption (T1490).
• Alert on recovery-inhibition commands. Instrument SIEM/EDR rules to catch volume shadow copy deletion and boot configuration tampering prior to payload detonation.
• Monitor persistence locations. Watch %APPDATA%\Roaming scheduled tasks and the MSFEEditor Run key (T1053.005, T1547.001).
• Detect reflective PowerShell. Flag Invoke-ReflectivePEInjection and batch-spawned PowerShell (T1059.001).
• Watch for Safe Mode abuse. Alert on configuration changes that force Safe Mode with Networking (T1562.009).

Key takeaways for defenders

MedusaLocker's longevity comes from discipline, not innovation: it monetizes exposed RDP, steals before it encrypts, and destroys local recovery paths on the way out.

Effective defense relies on core security hygiene: disable internet-facing RDP, enforce MFA, isolate backups using separate credentials, and set alerts for shadow-copy deletion. Scope every engagement from initial exposure onward, accounting for pre-existing initial access brokers.