A newly disclosed attack technique called GhostLock is forcing the security community to confront an uncomfortable truth: ransomware defenses built around detecting encryption are blind to a growing class of availability attacks that never encrypt a single byte. Discovered by Kim Dvash, an Offensive Security Team Leader, GhostLock weaponizes a fundamental, decades-old Windows file-sharing behavior to paralyze enterprise file shares — and evades every conventional ransomware detection mechanism tested against it.
The Attack: Locking Files Without Encrypting Them
GhostLock exploits the standard Windows CreateFileW API with dwShareMode set to 0x00000000. This forces an exclusive deny-share handle on any file, causing a STATUS_SHARING_VIOLATION (0xC0000043) error for every other process or network client attempting to open that file — for read, write, or delete — until the handle is voluntarily closed or forcibly terminated by a storage administrator.
The technique is not a software defect. CreateFileW with dwShareMode = 0 is the same mode Microsoft Office uses when opening a document for editing — a behavior that has existed since Windows NT 3.1. No CVE has been filed because there is nothing to patch. The attack is entirely within the bounds of normal Windows operation.
Critically, any authenticated domain user with standard read access can execute GhostLock. No administrative rights are required. The Python-based tool uses a ctypes wrapper requiring no external dependencies, making deployment trivially simple for an insider threat or a compromised standard user account.
Industrial-Scale File Locking
To scale across enterprise NAS deployments, GhostLock employs a 32-thread parallel work-stealing scanner that parallelizes SMB2 QUERY_DIRECTORY round-trips. In experimental testing against isolated infrastructure:
- File discovery across 500,000 files completed in just 6 minutes 22 seconds (down from 61+ minutes single-threaded)
- Handle acquisition across 500,000 files completed in 2 minutes 37 seconds
- Lock success rate: 99.6%
- During a 60-second hold period, victim simulations recorded a 99.8% file access block rate
A single SMB session can hold up to 64,000 exclusive handles simultaneously. With just ten parallel sessions, an attacker can exceed 500,000 locked handles — sufficient to paralyze a significant fraction of an entire enterprise NAS deployment. From the victim’s perspective, the impact is functionally identical to a ransomware infection: critical files become inaccessible, ERP applications crash, and shared workflow pipelines fail.
Complete Evasion of Ransomware Defenses
GhostLock was evaluated against seven enterprise security control categories — and produced zero alerts across all of them:
- Honeypot/canary files: No alerts — canaries trigger on write events; GhostLock performs no writes
- Write-rate anomaly detectors: No alerts — the metric they monitor (write operations) is simply absent
- Behavioral AI ransomware engines: No alerts — GhostLock’s read-open profile is indistinguishable from a search indexer or backup pre-scan agent
- Commercial EDR agents: No alerts — the system call profile mirrors Microsoft Word opening documents
- NDR/deep packet inspection: No alerts — SMB2 traffic showed only CREATE and CLOSE requests, identical to normal document access
- SIEM correlation rules: No alerts — no existing ruleset monitors per-session exclusive handle accumulation
The only reliable detection signal exists inside the NAS management layer itself: the per-session count of simultaneously held exclusive handles. A legitimate single-user application rarely holds more than a few dozen exclusive handles at once, while GhostLock accumulates tens of thousands. However, this metric is not ingested by any enterprise SIEM reviewed in the research.
Recovery Is Not Straightforward
Even after detection, recovery presents its own challenges. Terminating the offending SMB session requires storage administration expertise, and in most large enterprises, the storage operations team and security operations team operate independently without pre-built joint runbooks. The estimated mean time to recovery in tabletop exercises without a pre-built runbook was 4 to 8 hours.
Notably, even if the attacker’s Active Directory credentials are revoked, the existing authenticated SMB session and all its locks can persist for an additional 15 to 60 minutes before session timeout, depending on platform configuration — providing significant additional dwell time.
Defensive Recommendations
Dvash calls on NAS vendors to expose per-session exclusive-handle counts as standard security telemetry alongside existing syslog outputs, and urges SIEM vendors to build storage platform integrations that ingest this data. For immediate action, organizations are advised to:
- Alert on any single SMB session accumulating more than 500 exclusive handles
- Implement an NDR rule for bulk SMB CREATE requests with zero corresponding WRITE operations over a 30-minute window
- Establish a joint SecOps/StorageOps runbook specifically for NAS session termination
- Review whether existing ransomware coverage policies would cover GhostLock-style availability attacks, since no encryption or data exfiltration occurs
The GhostLock tool and source code are publicly available at github.com/kimd155/ghostlock. The disclosure serves as a stark reminder that availability attacks do not require encryption — and that the security industry’s singular focus on write-based ransomware detection has left a significant blind spot wide open.