A newly disclosed offensive technique called GhostLock can render corporate file servers completely inaccessible to every user on a network.
Achieving the full business impact of ransomware while bypassing every conventional ransomware defense, including EDR agents, honeypot canary files, write-rate anomaly detectors, and SIEM correlation rules. No malware is deployed. No files are encrypted. No CVE exists. No patch is coming.
GhostLock is an availability attack technique discovered by Kim Dvash, an Offensive Security Team Leader, during an authorized red team engagement.
Published in May 2026 alongside a companion whitepaper on Zenodo and a proof-of-concept tool on GitHub, the technique exploits a fundamental, three-decade-old behavior of the Windows operating system to cause enterprise-wide file access failures without writing a single byte to disk.
Unlike conventional ransomware, which stages payloads, escalates privileges, encrypts data, and drops ransom notes, GhostLock requires only a standard domain user account with read access to a corporate Server Message Block (SMB) file share. The attacker’s footprint is indistinguishable from a search indexer performing a routine document scan.
GhostLock Locks 500K Files Without Encryption
The technique relies entirely on a single Windows API call: CreateFileW invoked with dwShareMode set to 0x00000000. When this parameter is set to zero, the calling process acquires an exclusive deny-share handle on the target file.
Every other process or network client that subsequently attempts to open that file for any purpose, including read, write, or delete, receives a STATUS_SHARING_VIOLATION error (0xC0000043) until the handle is voluntarily released or forcibly terminated by a storage administrator.
This is not a software defect. It is the same sharing mode Microsoft Office has used since Windows NT 3.1 when opening a document for editing. No CVE has been filed, and no patch is planned, because the operating system is behaving as expected. The attack surface has existed for thirty years.
What elevates GhostLock from a theoretical curiosity to an operational threat is its engineering for scale. The proof-of-concept tool, written in Python using a ctypes wrapper that requires no administrative rights or external dependencies, employs a 32-thread parallel work-stealing file scanner.
Each thread calls os.scandir() on a directory and feeds subdirectories back to the thread pool, parallelizing SMB2 QUERY_DIRECTORY round-trips across all available bandwidth.
Against a 500,000-file share containing 38,000 directories, a sequential os.walk() scan required more than 61 minutes. The GhostLock parallel scan completed in just 6 minutes and 22 seconds, resulting in a roughly 10x speedup.
Handle acquisition across 500,000 files completed in 2 minutes and 37 seconds, achieving a 99.6% lock success rate during experimental testing against isolated infrastructure.
During a 60-second hold period, victim simulations recorded a 99.8% block rate for file access. A single SMB session can hold up to 64,000 exclusive handles simultaneously; with ten parallel sessions, an attacker can exceed 500,000 locked handles sufficient to paralyze a significant fraction of an entire enterprise NAS deployment.
What makes GhostLock particularly alarming for security teams is its systematic evasion of the entire modern enterprise defense stack. Dvash’s research evaluated the technique against seven categories of enterprise security controls:
Honeypot and canary files produced zero alerts; canary systems trigger on write events, and GhostLock performs no writes. Write-rate anomaly detectors produced zero alerts; the metric they monitor never appears.
Behavioral AI ransomware engines produced zero alerts. GhostLock’s read-open system call profile is indistinguishable from a legitimate backup pre-scan agent or search indexer. Commercial EDR agents produced zero alerts. The system call sequence mirrors Microsoft Word opening documents for editing.
NDR and deep packet inspection produced zero alerts. SMB2 traffic showed only CREATE and CLOSE requests, identical to normal document access patterns. SIEM correlation rules produced zero alerts, no existing ruleset monitors per-session exclusive handle accumulation.
The business impact from the victim’s perspective is identical to a ransomware infection: critical files become inaccessible, enterprise resource planning (ERP) applications crash, and shared workflow pipelines fail. The estimated mean time to recovery in tabletop exercises without a pre-built runbook ranged from 4 to 8 hours.
One critical edge case extends the threat window even further: if an attacker’s Active Directory credentials are revoked after detection, the existing authenticated SMB session and all its exclusive handles can persist for 15 to 60 minutes beyond that, depending on platform configuration, before session timeout.
The sole reliable indicator of a GhostLock attack resides inside the NAS management layer itself, the per-session count of simultaneously held exclusive handles.
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.
The critical gap identified in the research: this metric is available on every major enterprise NAS platform via management APIs, but it is not ingested by any of the enterprise SIEMs reviewed during the study.
It sits on storage platform management interfaces, monitored by storage operations teams, and is completely invisible to security operations.
Mitigation
Dvash and the research paper outline three concrete defensive steps organizations can take immediately:
- Integrate NAS session telemetry into the SIEM: Export per-session exclusive-handle counts from the NAS management API. Set an alert threshold at 500 simultaneously held exclusive handles per session, with graduated severity levels at 1,000 and 5,000 handles.
- Deploy an NDR rule for bulk open-without-write behavior: Alert when a single source IP generates more than a threshold number of SMB
CREATErequests with no correspondingWRITEoperations over a rolling 30-minute window. A backup agent briefly exhibits this pattern; GhostLock sustains it indefinitely. - Establish a joint SecOps/StorageOps runbook: Pre-built procedures for NAS session termination, specifically for this type of availability attack, as recovery currently requires storage administration expertise that security operations teams typically do not possess.
We urge NAS vendors to expose per-session exclusive-handle counts as standard security telemetry alongside existing syslog output. SIEM vendors are called on to build native storage platform integrations that ingest this data by default.
The GhostLock tool and source code are publicly available at github.com/kimd155/ghostlock, and the companion research site is at ghostlock.io.
FAQ
Q: Does GhostLock require administrator or elevated privileges to execute?
No, it requires only a standard low-privileged domain user account with read access to the target SMB file share.
Q: Is there a CVE or patch available for the GhostLock technique?
No CVE has been filed, and no patch is forthcoming because GhostLock exploits documented, intentional Windows behavior that has existed since Windows NT 3.1.
Q: How quickly can GhostLock lock files across a large enterprise file share?
In testing, GhostLock locked 500,000 files in just 2 minutes and 37 seconds, achieving a 99.6% lock success rate.
Q: What is the single most effective defensive measure against a GhostLock-style attack?
Integrating per-session exclusive-handle counts from the NAS management layer into enterprise SIEM systems and alerting on any session accumulating more than 500 simultaneous exclusive handles.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
