Every ransomware defense you have built assumes the attacker needs to write something. Encrypt a file, rename it with a .locked extension, scribble high-entropy garbage across a document tree, any transformation that leaves a forensic signature, a canary alert, or a write-rate anomaly. The entire multi-billion-dollar ransomware detection industry rests on that single assumption, and it is wrong.

cover

GhostLock, a technique and open-source proof-of-concept published in May 2026 by Kim Dvash (whitepaper, GitHub repository), demonstrates this with uncomfortable clarity: a standard domain user account, the kind you might harvest from any generic phishing campaign, can lock hundreds of thousands of files on an enterprise NAS within minutes, causing STATUS_SHARING_VIOLATION failures across ERP systems, document management platforms, and shared workflow pipelines. Zero bytes written. Zero files renamed. Zero encryption-related I/O. The ghost leaves no trace.

How the lock actually works

The mechanism is not a vulnerability. It is not even particularly obscure. It is the Windows CreateFileW API called with dwShareMode = 0x00000000, as documented in the official CreateFileW function reference. When the sharing mode bitmask has no bits set, the I/O Manager grants the caller an exclusive deny-share handle: no other process or network client can open that file for any purpose (read, write, or delete) until the handle is voluntarily closed or the session is killed by a storage administrator. Microsoft’s documentation on creating and opening files is explicit on this point, and the behavior has been part of the Win32 API since Windows NT 3.1.

info

Over SMB2, the dwShareMode value travels across the network as the ShareAccess field in the SMB2 CREATE request, defined in section 2.2.13 of the MS-SMB2 specification. The protocol is unambiguous: if a client opens a file with a given share mode, the server must enforce that share contract and deny conflicting opens until the handle is closed. Every conforming SMB server must obey this, and there is no standard SMB2 mechanism allowing a server to impose a maximum hold duration or a per-user open file count limit at the protocol layer.

At the kernel level, the NTFS driver enforces share semantics via the SHARE_ACCESS structure maintained per file control block, consulting the IoCheckShareAccess and IoCheckShareAccessEx routines as documented in the Windows Driver Kit. If an exclusive handle already exists, any new open request fails with STATUS_SHARING_VIOLATION before any disk I/O occurs. The check is enforced entirely in memory, with no user-mode bypass possible.

There is even a kernel flag, IO_IGNORE_SHARE_ACCESS_CHECK, which allows local kernel components to bypass sharing checks on local volumes, but as driver-level research confirms, it has no effect on files opened across the network. Across SMB, the server-side share access checks remain mandatory.

The GhostLock tool: scale is the attack

A single exclusive handle on one file is an annoyance. Half a million exclusive handles held indefinitely across an entire NAS namespace is a ransomware incident in operational, financial, and legal terms. The technique is conceptually similar to what we have described when discussing LOLBins: the abuse of legitimate, documented system behavior to produce damage that bypasses detection entirely. The PoC achieves enterprise scale through two engineering choices worth understanding in detail.

File discovery uses a 32-thread parallel work-stealing pattern built on concurrent.futures.ThreadPoolExecutor. Each thread calls os.scandir() on one directory and feeds subdirectories back to the pool, parallelizing SMB2 QUERY_DIRECTORY round-trips across all available bandwidth. Against a 500,000-file share with 38,000 directories, sequential scanning (os.walk()) took 61 minutes; the parallel scan completed in 6 minutes and 22 seconds, a roughly 10x speedup that persists at all tested scales. In practice, a large enterprise NAS is fully mapped before detection has had any meaningful time to react.

Handle accumulation relies on Python’s ctypes module calling kernel32.CreateFileW with GENERIC_READ and FILE_SHARE_NONE = 0x00000000, directly binding to the Win32 API function defined in fileapi.h. Files transiently locked by legitimate users are retried with exponential backoff (0.25s, 0.5s, 1.0s). Against the 500,000-file test volume, 498,203 handles were acquired in 2 minutes and 37 seconds, with a 99.6% success rate. For all handles acquired, the victim blocking rate was effectively 100%.

A discovery cache serialized as JSON means that if the attacker’s session is terminated and must be re-established, re-locking the same share takes seconds rather than minutes. This directly undermines the most obvious administrative response. The GhostLock source code makes both the CreateFileW binding and the parallel discovery architecture available for inspection.

Why every detection control misses this

This is where the paper becomes genuinely uncomfortable reading for anyone who has spent time tuning a ransomware detection stack.

Canary and honeypot files alert on write, rename, and delete events, the same behaviors targeted by the major academic ransomware detectors: CryptoDrop by Scaife et al. (IEEE ICDCS 2016), which monitors file type changes and Shannon entropy of written data; UNVEIL by Kharraz et al. (USENIX Security 2016), which uses sandbox analysis of write activity and desktop state changes; and ShieldFS by Continella et al. (ACSAC 2016), a transparent filesystem shim that models write behavior and recovers from shadow copies. All three systems share the same foundational assumption: ransomware must write to disk to cause harm. GhostLock opens canary files with read-only access and an exclusive share mode. The canary file is locked, no one else can open it, but no write event fires. The detection mechanism never sees anything.

Write-rate anomaly detectors are counting writes. GhostLock produces exactly zero writes on the target share. There is no threshold to tune, no baseline to calibrate, no alert to suppress. The signal the detector monitors is simply absent, regardless of how the baseline was computed or how sensitive the detector is configured.

Behavioral AI ransomware detection in EDR and NDR products is trained on features extracted from observed ransomware executions: Shannon entropy of written data, bulk rename rates, new extension appearances, sequential read-then-write patterns. These are precisely the features documented in CryptoDrop, UNVEIL, and ShieldFS evaluations. GhostLock’s behavioral profile, sequential read-opens across many files with no writes, matches the signature of a file system indexer, a search crawler, or a backup pre-scan agent. All commercial behavioral AI products tested in the research produced zero alerts.

EDR sees a Python interpreter making NtCreateFile system calls over the network redirector. That is indistinguishable from any file synchronization agent, search indexer, or backup tool. No shellcode injection, no DLL sideloading, no code hollowing. Nothing to hook.

NDR and deep packet inspection see SMB2 CREATE requests with ShareAccess = 0x00000000 and CLOSE requests, all conforming to the MS-SMB2 wire format. No WRITE, SET_INFO, or RENAME operations. The traffic is indistinguishable from a user opening hundreds of Word documents in rapid succession, which on a large enterprise network is background noise.

DLP requires bulk access combined with bulk data transfer to trigger. GhostLock opens each file and reads essentially nothing, a pattern consistent with metadata inspection rather than exfiltration, never reaching DLP thresholds. The relationship between DLP limitations and broader detection gaps is something we explored earlier in Indicators of Leakage: DLP having its EDR moment.

The only layer that holds a reliable signal is the NAS management session table: the per-session count of simultaneously held exclusive handles. This metric is available on every major SMB server implementation, exposed through platform management APIs as an operational monitoring feature. A legitimate application, even a backup agent, opens a file, processes it, and closes the handle. It does not accumulate tens of thousands of exclusive handles indefinitely. A single session holding 500 or more simultaneous exclusive handles has no benign explanation at scale. The critical finding is that this metric is not ingested into any enterprise SIEM reviewed during the research. It sits in storage platform management interfaces monitored by storage operations teams, invisible to the security operations team.

Detection layer Signal present? Why it fails What would be needed
Canary files No No writes generated Alert on exclusive-open events
Write-rate anomaly No Zero writes Open-rate anomaly detection
Behavioral AI No Profile matches file indexer Exclusive-hold count model
EDR No Identical syscall profile to Word ShareAccess=0 heuristic at scale
NDR / DPI No Identical to Word document opens Per-session open count rule
DLP No Minimal data transferred Open-without-read detection
NAS session table Yes Metric not ingested into SIEM Storage telemetry pipeline

DFIR perspective: what an incident looks like

From a DFIR standpoint, a GhostLock incident presents as a wide-scale application availability failure with no forensic artifact on disk. Applications start throwing file access errors. ERP operations fail. Users cannot save or open documents. The instinctive first response, checking for ransomware indicators, encrypted files, and high-entropy writes, returns nothing. The volume looks completely untouched: no new files, no renamed files, no modified timestamps on content.

The STATUS_SHARING_VIOLATION (0xC0000043) error code that victims receive is typically surfaced only in application-level logs, if those logs are collected at all. Microsoft’s file sharing documentation notes that conflicting access and sharing modes cause CreateFile to fail with a sharing violation, but very few operational runbooks treat this as a security-relevant symptom worth escalating. Incident responders unfamiliar with STATUS_SHARING_VIOLATION may spend hours pursuing the wrong hypothesis, ransomware encryption that simply is not there, while the lock holds.

Recovery requires a storage administrator to access the NAS management interface, enumerate active SMB sessions, identify the offending session by source IP and user account, and execute a session termination command. In organizations where storage operations and security operations are separate teams, this path requires cross-team coordination that is rarely pre-planned. Most incident response runbooks document procedures for isolating endpoints and revoking credentials, but not for terminating NAS sessions. That is exactly the gap that tabletop exercises are designed to expose before an attacker does. The paper’s tabletop estimate for mean time to recovery without a pre-built runbook is 4 to 8 hours.

There is one additional complication. If the incident response team revokes the attacker’s Active Directory credentials (the correct first step in most runbooks), the existing SMB session and its handles may persist for another 15 to 60 minutes depending on platform session timeout configuration. The session was already authenticated before credential revocation. Killing the credential does not kill the lock. This behavior is consistent with how SMB2 session state is defined in the MS-SMB2 specification.

What blue teams should build right now

The prevention analysis is sobering. CreateFileW with dwShareMode = 0 is used by Microsoft Office, SQL Server, version control systems, and build tools, and is explicitly documented behavior in the Win32 API contract. Restricting it for standard users would break the Windows file integrity model across the entire application ecosystem. No CVE will be filed. No patch will be issued. As with many classes of abuse-of-legitimate-behavior attacks, including the threat modeling primer published here last year, the practical path forward is detection, not prevention.

Primary detection: NAS session telemetry into the SIEM. Work with storage operations to export the per-session exclusive-handle count from the NAS management layer. Most enterprise NAS platforms expose this data through management APIs that operators consult for capacity planning; nothing stops you from forwarding it as security telemetry. A reasonable starting alert threshold is 500 simultaneously held exclusive handles per session, well above any legitimate single-user application and well below GhostLock’s operational minimum. The whitepaper provides Splunk SPL pseudocode as a starting point, with graduated severity at 1,000 and 5,000 handles.

Example Splunk query pattern (adapt field names to your NAS telemetry schema):

index=nas sourcetype=nas:session_metrics
| stats latest(exclusive_handle_count) as exclusive_handles,
		latest(open_file_count) as open_files,
		latest(client_ip) as client_ip,
		latest(username) as username
  by session_id, nas_host
| where exclusive_handles >= 500
| eval severity=case(exclusive_handles>=5000, "critical",
					 exclusive_handles>=1000, "high",
					 true(), "medium")
| table _time nas_host session_id username client_ip exclusive_handles open_files severity
| sort - exclusive_handles

Secondary detection: SMB open-without-write pattern in NDR. Build a rule that alerts when a single source IP generates more than a threshold number of SMB CREATE requests with no corresponding WRITE operations over a rolling 30-minute window. NDR products that parse SMB2 commands according to the MS-SMB2 specification can implement this. A backup agent shows this pattern briefly; GhostLock sustains it indefinitely, which is the differentiating characteristic.

Expected false positives and tuning controls:

  1. Backup discovery phases: whitelist known backup service accounts and backup subnet ranges, but alert if hold time exceeds expected job windows.
  2. Enterprise indexing and e-discovery crawlers: baseline normal open-without-write rates per scanner host, then alert on deviations above the 95th percentile.
  3. Antivirus or EDR mass scan windows: suppress during scheduled maintenance windows only, and keep alerts active for unscheduled bursts.
  4. Developer build farms on shared code volumes: add per-share allowlists, but keep hard caps on simultaneous exclusive handles per session.

Quick MITRE ATT&CK alignment for reporting:

  1. T1486 (Data Encrypted for Impact): GhostLock does not encrypt data, but creates equivalent availability impact at application and business process level.
  2. T1499 (Endpoint Denial of Service): sustained exclusive handle holds can be documented as a protocol-level denial condition against file service consumers.
  3. T1078 (Valid Accounts): the technique relies on legitimate low-privilege domain credentials, not malware execution or exploit chains.

Response runbook: build it before the incident. The runbook should cover: (1) identifying the offending session ID and source IP from the NAS session table; (2) correlating to a user account via AD or RADIUS logs; (3) executing the session termination command on the NAS platform; (4) disabling the account in Active Directory in parallel; (5) verifying that handle counts have returned to baseline. Both security operations and storage operations teams need pre-granted access to the NAS management interface and need to have exercised the runbook together. The USN Journal and other Windows filesystem forensic artifacts covered in a previous post on NTFS forensics will show nothing unusual for a GhostLock incident. That absence is itself a forensic finding worth documenting.

Per-session open file limits on the NAS. Most enterprise NAS platforms expose vendor-specific controls that cap per-user or per-session open file counts. These are documented as performance tuning features, disabled by default, and require careful calibration to avoid disrupting backup agents and database engines. Enabling them is non-trivial, but they represent the only platform-level mitigation with genuine preventive impact.

The GhostLock repository includes both an interactive mode for authorized testing and a generated-files mode that creates and locks only its own test files, never touching existing data. This makes it appropriate for demonstrating the technique and measuring detection coverage in production-equivalent environments without operational risk.

The uncomfortable conclusion is that the ransomware defense industry has spent a decade instrumenting for encryption I/O while an entire orthogonal class of availability attack remained uncharacterized and undetected. The attack surface is present in every enterprise running SMB-backed shared file infrastructure, which is effectively every enterprise on earth. The question is not whether your detection stack can catch this. It almost certainly cannot, yet. The question is how quickly you build the one layer that can.