GhostLock Attack Locks Files Via Windows Sharing Like Ransom

By encrypting data and demanding payment for decryption keys, traditional ransomware disrupts organizations.

However, a newly disclosed technique called GhostLock demonstrates a fundamentally different availability attack that achieves the same business disruption without writing a single encrypted byte to disk.

Discovered by Kim Dvash, an Offensive Security Team Leader, GhostLock exploits standard Windows file-sharing behavior to cause widespread accessibility failures.

By systematically holding files in an exclusively locked state, a low-privileged domain user with standard read access can paralyze corporate Server Message Block (SMB) file shares. From the victim’s perspective, the impact is identical to a ransomware infection.

Critical files become inaccessible, enterprise resource planning applications crash, and shared workflow pipelines fail, requiring specialist intervention to restore operations.

The technique exploits a fundamental, well-documented behavior of the Windows operating system. By invoking the CreateFileW API with dwShareMode set to 0x00000000, any authenticated domain user can acquire an exclusive deny-share handle on a file over SMB.

This forces a STATUS_SHARING_VIOLATION (0xC0000043) error for every other process or network client attempting to open that file for any purpose, including read, write, or delete until the handle is voluntarily closed or forcibly terminated by a storage administrator.

The attack surface is not new. CreateFileW with dwShareMode = 0 is the same mode Microsoft Office uses when it opens a document for editing a behavior that has existed since Windows NT 3.1. No CVE has been filed because there is no software defect to patch.

GhostLock Attack Exploited

GhostLock implements this single API call through a Python ctypes wrapper requiring no administrative rights and no external dependencies.

To scale across an enterprise NAS, it employs a 32-thread parallel work-stealing scanner that parallelizes SMB2 QUERY_DIRECTORY round-trips, reducing file discovery on a 500,000-file share from over 61 minutes to approximately 6 minutes and 22 seconds.

Experimental testing against isolated infrastructure showed handle acquisition across 500,000 files completed in just 2 minutes and 37 seconds, achieving a 99.6% lock success rate.

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 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 dangerous is its complete evasion of every conventional ransomware defense layer. The paper evaluated the tool against seven enterprise security control categories:

• Honeypot/canary files produced zero alerts — canaries trigger on write events, and GhostLock performs no writes.
• Write-rate anomaly detectors produced zero alerts — the metric they monitor (write operations) is simply absent.
• Behavioral AI ransomware engines produced zero alerts — GhostLock’s read-open profile is indistinguishable from a search indexer or backup pre-scan agent.
• Commercial EDR agents produced zero alerts — the system call profile mirrors Microsoft Word opening documents.
• NDR/deep packet inspection produced zero alerts — SMB2 traffic showed only CREATE and CLOSE requests, identical to normal document access.
• SIEM correlation rules produced zero 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.

The paper notes that a legitimate single-user application rarely holds more than a few dozen exclusive handles at once, while GhostLock accumulates tens of thousands, but this metric is not ingested by any enterprise SIEM reviewed in the research.

Even after detection, recovery is not straightforward. 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, 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.

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 defensive action, the paper recommends alerting on any single SMB session accumulating more than 500 exclusive handles, implementing an NDR rule for bulk SMB CREATE requests with zero corresponding WRITE operations over a 30-minute window, and establishing a joint SecOps/StorageOps runbook specifically for NAS session termination.

The GhostLock tool and source code are available at github.com/kimd155/ghostlock and the companion research site at ghostlock.io.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.