The File Server Got Encrypted and the EDR Console Is Empty
A file server's shares are encrypted. Thousands of documents are unreadable. The ransom note is sitting in every directory. You pull up the EDR console for that host expecting to see a malicious process, a suspicious binary, a CryptoGuard-style behavioral alert. There's nothing. No process executed. No payload landed. No PowerShell, no script, no DLL injected into anything. The endpoint agent did its job and saw a quiet, healthy machine the entire time the files were being destroyed.
This is remote ransomware encryption, and it's the technique behind a growing share of incidents that leave endpoint defenders staring at empty timelines. The encryption never happens on the victim. The attacker mounts the victim's SMB shares from a separate machine they control, reads the files over the network, encrypts them on their own infrastructure, and writes the ciphertext back to the original paths through the same SMB session. From the file server's perspective, a remote user authenticated and performed file reads and writes. That's it. No malware executes in the victim environment, so process-based and behavior-based endpoint detection has nothing to fire on.
Sophos' Counter Threat Unit documented this clearly in their analysis of WantToCry in 2026, and CrowdStrike has been tracking the same pattern across big game hunting operations since 2024. The technique isn't new in concept, but its adoption is accelerating because it sidesteps the one control most organizations have invested in most heavily. If your ransomware detection strategy assumes the encryptor runs on the box getting encrypted, that assumption is now a liability.
How the Attack Actually Works
The mechanics are simpler than most ransomware operations, which is part of why they work. WantToCry's operators scan the internet for SMB services exposed on TCP/139 and TCP/445. A January 2026 Shodan scan referenced by Sophos found more than 1.5 million exposed SMB ports, with over 600,000 in the United States alone. Exposed SMB at that scale is a target-rich environment.
Once they find an exposed service, the attackers establish an authenticated SMB session, either by brute-forcing credentials or using previously stolen ones. From there, the operation is mechanical. They enumerate accessible shares, exfiltrate the files to their own server, encrypt the data on attacker-controlled infrastructure, then write the encrypted versions back to their original locations over the same SMB session. WantToCry's ransom demands ran low compared to major operations — between $300 and $1,800 in Bitcoin — which fits the volume-driven, opportunistic nature of internet-wide SMB scanning.
The detection problem is structural. The victim's file server hosts the data, but the encryption logic runs elsewhere. The MITRE technique here is Data Encrypted for Impact (T1486), but the execution happens through Remote Services: SMB/Windows Admin Shares (T1021.002) and Network Share Discovery (T1135). Endpoint detection is built around the assumption that malicious code runs locally. Strip out the local execution and you've removed the entire signal surface that endpoint tools depend on. There's no process tree, no parent-child relationship, no command line, no in-memory injection, no driver load. There is only an SMB session doing reads and writes that look, at the protocol level, almost identical to a busy user copying files.
There's a related variant worth keeping in mind. Some operators don't just encrypt remotely; they pair it with encryption that doesn't change filenames or extensions. The classic ransomware detection heuristic watches for mass file renames where report.xlsx becomes report.xlsx.locked. Strip that signal too, and file-extension-based detection (like Splunk's common ransomware extensions analytic) sees nothing abnormal. Combine remote encryption with in-place, extension-preserving encryption and you've defeated both the endpoint behavioral layer and the file-naming heuristic in a single design choice.
Why the EDR Trust Boundary Is the Real Problem
The deeper issue isn't that remote encryption is clever. It's that it operates outside the endpoint trust boundary entirely, and most detection stacks are concentrated inside that boundary.
Consider where the data lives versus where the action originates. The file server has an EDR agent. It's healthy, patched, reporting telemetry. But the agent watches that host's own processes, memory, and disk activity. When a remote host writes data to a share, the agent sees file system writes attributed to the SMB service (System process, PID 4) handling a network request. That's not anomalous on its own. File servers handle remote writes constantly. The encryptor — the thing an EDR would actually want to catch — is running on a machine that, in many cases, has no EDR agent at all. It might be an attacker-controlled VPS. It might be an unmanaged device on the network the attacker compromised earlier. Either way, it's outside your visibility.
This is the same blind spot that makes BYOVD and EDR-killer campaigns effective, approached from the opposite direction. Where an EDR killer blinds the agent by terminating it, remote encryption never gives the agent anything to see in the first place. The 2026 wave of EDR-evasion tooling — like the loader chains observed terminating hundreds of endpoint-agent drivers — gets a lot of attention. Remote encryption is quieter and arguably harder to address, because there's no malicious driver to detect and no agent termination event to alert on. The attack succeeds by simply not being where your sensors are.
The practical conclusion: detection has to move to telemetry sources that sit outside the endpoint. SMB protocol activity, Windows file-share audit events, authentication logs, and network flow data. These are the layers that stay visible when the endpoint agent is structurally blind.
Where the Signals Actually Live
The good news is that remote encryption is loud in exactly the places endpoint detection is quiet. The attack requires authenticated SMB access and generates a distinct pattern of file operations. You just have to be collecting the right logs.
Windows file-share auditing is the primary source, and it's off by default. You need to enable "Audit Detailed File Share" (Event ID 5145) and "Audit File Share" (Event ID 5140) on file servers through Group Policy or secpol.msc. Event 5140 logs when a network share is accessed and captures the account name, source IP, and share name. Event 5145 goes deeper, logging object-level access — which specific files were touched and what access was requested via the access mask. For remote encryption, 5145 is the high-value event because the attack reads and writes thousands of files in sequence, and 5145 captures each one with the requesting account and source IP attached.
The detection pattern is a single source IP, under one account, performing read followed by write operations across a large number of files in a short window. Legitimate file activity rarely looks like this — users open a handful of documents, not every file in a tree, with each file both read and rewritten. In your SIEM, the logic is a threshold on 5145 events grouped by source IP and account where access masks include both read (ReadData/0x1) and write (WriteData/0x2) operations, with the count crossing a baseline within minutes:
EventID=5145
| stats dc(RelativeTargetName) as unique_files,
values(AccessMask) as masks
by SourceAddress, SubjectUserName, _time_window(5m)
| where unique_files > 200
AND masks LIKE "%0x2%"
| sort -unique_filesTune the threshold to your environment. A file server backing a large team will have higher legitimate baselines than a departmental share. The point is the shape of the activity: mass sequential file writes from a single remote source.
Authentication telemetry is the earlier signal. The attack starts with either brute-forcing SMB credentials or using stolen ones. Brute-force attempts generate Event ID 4625 (failed logon) with logon type 3 (network) in volume from a single source IP. A spike of network logon failures against a file server, followed by a successful 4624 from the same IP, is a precursor worth alerting on independent of any encryption that follows. Sophos specifically called out brute-force attempts against SMB as an early warning sign, and they're right — the authentication phase is your best chance to catch this before any data is touched.
Network detection fills the gap when host logging is incomplete. NDR or firewall flow data showing sustained SMB sessions (port 445) between an external or unexpected internal IP and a file server, with bidirectional transfer volumes consistent with bulk read-and-write, is the network-layer signature. This is also where you catch the exfiltration component, since many of these operators steal the data before encrypting it. Inbound SMB from internet-facing IPs should never be happening; if your firewall allows TCP/139 or TCP/445 inbound, that's the first thing to close.
What to Actually Do This Week
The mitigations here are mostly unglamorous network hygiene, which is probably why exposed SMB remains a 1.5-million-port problem.
Block inbound SMB at the perimeter. There is almost no legitimate reason for TCP/139 or TCP/445 to be reachable from the internet. If you have exposed SMB, that's the single highest-priority fix, ahead of any detection engineering. Internet-facing SMB is the initial access vector for this entire class of attack.
Inside the network, the controls are about constraining and observing SMB rather than eliminating it. Disable SMBv1 entirely. Remove guest and anonymous SMB access. Enforce SMB signing to break NTLM relay paths. Segment file servers so that workstations can't freely reach administrative shares (ADMIN,C, C , IPC$) on hosts they have no business touching, and alert on Event 5140 when those shares are accessed from unexpected sources. Make sure backups live somewhere that isn't reachable over the same SMB sessions an attacker would ride in on — a backup that gets encrypted alongside production data because it sat on an accessible share is not a backup.
For detection specifically, the priority order is: turn on 5145 and 5140 auditing on file servers if they aren't already (this is the detection that survives when EDR is blind), build the mass-file-write-from-single-source rule in your SIEM, alert on SMB brute-force patterns via 4625 volume, and add NDR coverage for SMB flows if you have the tooling. Endpoint-side, some vendors have shipped specific countermeasures — CrowdStrike's File System Containment is designed to detect and block remote encryption over SMB at the file server by identifying the malicious write pattern even when no local process is responsible. If your EDR has an equivalent feature, turn it on and verify it's actually enabled, because it's often not on by default.
The thing to sit with is what this technique says about where defensive investment has concentrated. A decade of endpoint detection maturity, and the counter is to simply not run anything on the endpoint. The attacker doesn't defeat the EDR. They route around it, using a protocol that's been in every Windows network since the 1990s and a file operation pattern that the endpoint agent, by design, was never positioned to see
