Medusa Locker Over the Network Uncovered via Agentic MDR

On 29 October 2026, our investigation confirmed that a Medusa Locker affiliate used a stolen administrator credential to encrypt files over the network on several workstations at [redacted customer name], and that SentinelOne terminated every attempt and rolled back each affected business file.

The endpoint controls performed as designed, but the most important part of the forensic picture is that we couldn’t collect from the unmanaged devices from which both stages of the attack originated never appeared in any console and therefore produced no artifacts for us to examine.

This post follows the Guardz MDR investigation from the first credential access event through containment and scoping, and we redacted every device name, IP address, domain name, username, and customer identifier, while presenting timestamps, counts, and artifacts exactly as recorded.

This article redacts customer assets, but the IOCs are available.

For more incident write-ups and threat research, visit the Guardz Blog.

Medusa Locker Incident Context #

The affected environment is [redacted customer name], a small business whose IT is managed by an MSP, with a domain controller, a file server, network shares, and a NAS in the on-premises estate and SentinelOne deployed on only part of the endpoints under a license tier that provides neither Deep Visibility nor data lake telemetry, which meant that our evidence was limited to alerts and threat storylines.

This telemetry gap shaped the entire investigation because we had to reconstruct the intrusion from seven threat storylines comprising roughly 32,000 events that all originated on the protected hosts, while nothing was visible from the machines that launched the attack.

Stage One, Credential Dump With No Binary

At 06:12:23 UTC, which was 02:12 local time, a computer without an agent opened a remote session to the first workstation using an MSP-managed administrator account, started the Remote Registry service, and saved the SAM and SECURITY registry hives to a temporary file in C:\Windows\Temp, after which the same sequence was repeated against the second workstation two minutes later.

Each hive copy was 32,768 bytes and was read back over the network, and because the evidence shows no dropped executable and no outbound connection from either host, the activity is consistent with the footprint of Impacket secretsdump and maps to OS credential dumping of the SAM database.

SentinelOne raised a “Security Hive Save” detection on the first workstation and a “Syskey Query” detection on the second, together with pass-the-hash, remote memory allocation, and service creation indicators on the svchost.exe instance hosting Remote Registry, and the agent terminated both sessions and rolled back the changes within seconds.

Analysts who maintain blocklists should note that SentinelOne labels this svchost.exe as NotSigned, but it is a genuine Windows binary whose signature lives in the system catalog instead of being embedded in the file, and since the attacker abused the legitimate process rather than planting a malicious one, blocking its hash would disrupt the host while catching nothing.

Our initial reading of the storyline suggested code executing on the workstation, but that turned out to be wrong. The evidence shows neither stage ran a local dumping tool or encryptor, and every action was carried out through a remote session authenticated with the stolen account.

Automated triage dispositioned both credential access alerts as True Positive at 06:20 and assigned them to an analyst, yet the credential those alerts exposed remained valid until the attacker used it again at 08:19, and the lesson for MDR operations is that a killed session does not undo the theft, so any alert indicating a credential dump should immediately mark the account as compromised and trigger a hunt for the source host while the attacker is still inside the environment, which in this case meant a window of two hours.

Stage Two: Medusa Locker Encryption Over the Admin Share #

At 08:19:57 UTC, the attacker returned from a second unmanaged computer on the same subnet as the workstations, authenticated with the same account, and began renaming files to .leaked4 through the C$ administrative share (T1021.002) while writing RANSOM_NOTE.html into every folder (T1486), with encryption on the second workstation starting eight seconds after the first.

SentinelOne stopped the first sessions about three minutes after encryption began by terminating them, removing the ransom notes, and rolling the files back, but the attacker kept reconnecting, and five ransomware detections fired across the two hosts before the last malicious event at 08:25:23, after which the Guardz MDR team isolated the workstations at 08:28:35 and 08:29:10.

The storylines for the second workstation show how the encryptor walked the disk, with a first wave covering the recovery folder, the program folders of a security product, an Office download folder, and a folder that is likely an EDR canary, followed by a second wave through the administrator account’s user profiles, OneDrive, AppData, and the locale files of an installed communications application, which indicates that the attacker intended to encrypt the entire C: drive, and the host also contained Bitdefender program folders alongside SentinelOne, some of whose files were encrypted.

Attack Timeline

Tracking an incident from initial access to full containment requires analyzing both automated endpoint defenses and human analyst response. This timeline captures the MedusaLocker attempt’s progression from remote registry exploitation and automated triage to ransomware execution, automated rollback, and final endpoint isolation and full clean of the environment.

The credential dump at 06:12 and the encryption at 08:19 were separated by about two hours, during which the stolen account remained valid, and the source host went unidentified.

The Guardz platform records each SentinelOne alert as an issue, and closes them through a platform incident.

The incident shown below, titled Malware Detected, was created with the status completed successfully, and its investigation steps cite the SentinelOne Static Engine flagging advanced_port_scanner.exe as malware with high confidence, a file with a valid code signature that ran from its installation path and was launched by explorer.exe under a user account, while recording that the agent killed the process, quarantined the file, and reported the mitigation status as mitigated.

The Guardz agentic MDR investigation steps for the Malware Detected incident, with the endpoint, hash, signer, and user name redacted.

Advanced Port Scanner is a legitimate network discovery tool that ransomware affiliates also use, so we recorded its presence as an observation, and the detection alone does not establish who ran it.

The Guardz issue list, with device names and serial numbers redacted.

What Was Restored and What Was Not

In total, the encryptor wrote about 13,700 ransom notes, one into every folder it touched, and that placement gives responders a dependable way to scope the affected file systems.

Rollback is a recovery control and says nothing about exfiltration, so although the protected workstations show no outbound connections or archiving and the Microsoft 365 logs show no mass download or external sharing, none of that covers the on-premises network, where an affiliate practicing double extortion had two hours of unmonitored access from two computers against a customer that very likely holds patient health information, and data theft should therefore be assumed until firewall logs prove otherwise.

The Microsoft 365 Hunt #

We reviewed Microsoft 365 logs (sign-in, Exchange, and SharePoint audit logs) from the last month and found no attacker sign-ins, mailbox rules or forwarding configurations, application consent, signs of data theft, or other post-compromise activity related to this attack.

The most useful finding came from the SharePoint file audit trail rather than from any alert, because OneDrive on two computers without an agent uploaded ransom notes into SharePoint and was still syncing at 08:41, well after the workstations had been isolated, which turned cloud sync audit logs into an endpoint sensor for machines that had none and gave us two additional victims that no detection had reported.

We examined and scoped three other observations in the tenant as follows.

• Password spraying against several mailboxes was still active on the day of the incident, with one mailbox receiving 6,934 attempts from 2,511 addresses since 28 September and another receiving 483 attempts from 474 addresses, although no sign-in succeeded.

• Two accounts appeared for the first time on 28 October, one being an admin-style account most likely created by the MSP and the other signing in for the first time through a commercial VPN range seen across about 150 unrelated tenants after an expired temporary password and forced MFA registration, and although both are probably benign, we flagged them for confirmation because a first sign-in through a shared VPN range on the day before ransomware is not something to dismiss without verification.

• The MSP’s cloud admin account showed no compromise, since all nine of its sign-in addresses are shared with MSP staff or other MSP clients, but we still recommended a reset in case its password is synchronized from the domain account.

Medusa Locker Attribution #

We assess the ransomware as MedusaLocker, most likely the current MedusaLocker3 (FarAttack) variant, but we cannot prove this attribution because the encryptor ran on a computer outside SentinelOne’s visibility, and we didn’t capture a binary hash or ransom note text for analysis.

The ransom note text reinforces the assessment. It announces that the files have been encrypted, includes a per-victim key identifier, and directs the victim to a Tor negotiation portal and two contact email addresses, while claiming it gathered and stored highly confidential and personal data on a private server.

The operators state that the data will be released publicly or resold if payment is not made, that the victim may send two or three non-important files for free test decryption, that the data will be published on a Tor blog if the victim does not make contact, and that the price will rise if contact is not made within 72 hours. This is the double extortion model that MedusaLocker affiliates operate, and the note also refers the victim to an HTML instruction file named HOW_TO_RECOVER_DATA.html for recovery instructions.

The recovered ransom note, with the per-victim key identifier blacked out.

No free decryptor exists for the current MedusaLocker, so you can recover data encrypted outside the agent’s protection only from backups.

Why This Was Possible #

A deployment of several agents on a site that also hosts a domain controller, a file server, and a NAS is a sample of the environment rather than coverage of it, which is why the attack was launched from two computers that no analyst could see and why two further computers were reached without producing a single alert.

The root cause analysis points to a single administrator account holding rights on C$ for both workstations, which enabled the remote hive dump and the remote encryption, to a password that was already in the attacker’s possession before SentinelOne recorded any activity, to a Remote Registry service that could be started remotely, and to the absence of Deep Visibility, which left no history from which to trace earlier stages of the intrusion.

MSPs should pull the agent-to-endpoint ratio for every tenant they manage this week, then enumerate which accounts have local administrator rights on more than one workstation, because the results will likely be uncomfortable.

Hunting and Hardening Notes #

The hive dump leaves a distinctive artifact that is well suited to hunting, namely a 32 KB file named with eight random letters and a .tmp extension under C:\Windows\Temp, written by a remote session shortly after the Remote Registry service starts on a workstation, and it is the remote origin of the write that separates this activity from local tools touching the same hives.

For the encryption stage, detections should key on mass renames to a single new extension over an administrative share together with one ransom note per folder, and on the cloud side a burst of OneDrive uploads of an unfamiliar HTML file into many SharePoint sites is a reliable indicator that some endpoint, managed or not, is being encrypted. The hardening measures that would have mattered here are well known: restrict administrative share access from ordinary workstations, give every workstation a unique local administrator password, prevent any single account from holding administrator rights everywhere, and disable Remote Registry wherever it is not required.

Medusa Locker Indicators of Compromise #

Internal addresses, device names, storyline, and ITDR identifiers are withheld, and because no encryptor hash is available, the ransom note and file extension are the most reliable markers for scoping.

Access the complete list of indicators in the Medusa Locker .leaked4 Indicators of Compromise

Outcome #

The attack was blocked at both stages on every machine that carried a SentinelOne agent, with the credential dump sessions terminated within seconds, the encryption sessions stopped and rolled back, and every business file restored apart from four Office installation files that an Office repair replaces, while no new encryption or alerts were recorded and the site agents were isolated or queued for isolation.

The Guardz agentic MDR pipeline added speed and breadth. Triage dispositioned the credential dump alerts about eight minutes after they fired, the MDR team isolated both workstations about three minutes after the last encryption attempt, and by the end of the same day the investigation had reviewed all seven threat storylines, roughly 32,000 events, together with two months of Microsoft 365 sign-in, Exchange, and SharePoint logs, which is how the two additional victims surfaced from OneDrive sync activity.

At the time of writing, the two computers that launched the attack remained uncontained and unexamined because neither has an agent, so the encryptor binary, entry point, and full extent of data access on the on-premises network are still to be established from the forensic images and firewall logs described above.

Key Resources

• CISA Advisory:AA22-181A, #StopRansomware: MedusaLocker
• Guardz Threat Intelligence: Research repositories and detection artifacts in theGuardz Security Research Labs Threat-Intel repository.
• Guardz Cybersecurity Blog: More threat research and security insights on theGuardz Blog .