Kim Dvash, the Offensive Security Team Leader for Israel Aerospace Industries, has released a proof-of-concept tool called GhostLock. The tool demonstrates how a legitimate Windows file API can be used to lock files on SMB network shares without writing, renaming, or encrypting anything.
GhostLock is a Python script that automates the technique using the Windows CreateFileW API and its dwShareMode parameter to acquire exclusive file handles. While a handle is held, no other process or network client can open that file.
He claims the GhostLock technique can “lock every file on an enterprise file server” without malware deployment, encryption, or admin writes.
In this article, we analyze his paper and the claims made.
What the GhostLock paper finds
The GhostLock paper describes something technically accurate and worth understanding. The Windows CreateFileW API, called with dwShareMode = 0x00000000, acquires an exclusive deny-share handle. Any other client attempting to open that file receives STATUS_SHARING_VIOLATION for the duration of the handle.
This is not a vulnerability. It is documented, correct behavior that has existed since Windows NT 3.1. Microsoft Office uses it every time you open a document for editing. It is one of the most common file operations in the Windows ecosystem.
What GhostLock contributes is automation and scale: a parallelized scanner that acquires these handles across an entire directory tree rapidly.
It’s the relevant threat modeling rather than the behavior itself that is new.
The paper also identifies a gap: Most enterprise SIEMs do not ingest per-session exclusive handle counts from NAS management interfaces, and storage operations teams and security operations teams rarely share instrumentation pipelines. Those are legitimate findings worth addressing.
The problem is what the research builds on top of them.
The ransomware framing does not hold up
The paper's central claim is that GhostLock produces "ransomware-equivalent organizational availability impact." That framing has generated significant attention. It does not survive scrutiny.
The critical distinction is permanence. Ransomware causes damage that is irreversible without either paying the ransom or restoring from backup. GhostLock causes disruption that resolves the moment the offending session is terminated, leaving files completely untouched on disk.
The moment the offending SMB session is terminated, every lock releases instantly. Recovery is not a data restoration problem. It is a session termination problem. Framing them as equivalent misleads defenders about the actual risk they are managing.
The LinkedIn security community pushed back on this framing immediately and correctly. It is a file-share DoS. A motivated attacker does not gain meaningful leverage from a lock that an administrator can dissolve in seconds once they know what to look for.
The “undetectable” claim is overstated
The paper evaluates GhostLock against seven enterprise security control categories and concludes that each one fails to produce an alert. That conclusion requires unpacking.
The traffic is visible. GhostLock generates a large volume of SMB CREATE requests, all with ShareAccess = 0x00000000. That traffic appears in EDR telemetry and SIEM pipelines. What does not exist today is an out-of-the-box detection rule that correlates bulk exclusive handle accumulation as an alert condition.
The paper conflates "no existing rule fired" with "cannot be detected," and those are meaningfully distinct claims.
The difference between "EDR generated no telemetry" and "EDR generated no alert" matters. The telemetry exists. The analytic does not, yet.
An EDR can absolutely be configured to watch for this call pattern. Closing that gap does not require a structural fix to Windows or SMB. It simply requires writing a detection rule.
The NAS session telemetry gap is the more legitimate finding. That metric genuinely is absent from standard SIEM pipelines in most enterprises, and surfacing it requires cross-team coordination that is often underprioritized. But that is a process and instrumentation gap, not an architectural blind spot in the security industry.
The threat model has real constraints
The paper describes a "standard domain user with read access to an SMB file share" as the only prerequisite. That is technically accurate for a single session from a single endpoint, and it understates what operational impact at scale requires.
A single SMB session hits per-platform handle limits. Locking a meaningful fraction of a large enterprise NAS requires multiple simultaneous sessions from multiple endpoints, or the ability to rapidly re-establish sessions after termination. Getting there requires either access to multiple endpoints or a propagation mechanism. And propagation generates exactly the signals the technique supposedly avoids.
If an attacker already has code execution across multiple domain-joined endpoints, file share DoS is not the most consequential thing they can do with that access. An attacker with that level of access and a willingness to deploy tooling has already cleared the bar for deploying actual ransomware. The choice to lock files instead of encrypt them is a choice, not a capability constraint. GhostLock's threat model inadvertently makes the case that the scarier problem is the access itself, not what the attacker does with it.
Another realistic concern, which the paper briefly acknowledges, is the low barrier to entry for insider threats and opportunistic disruption from a single endpoint. That is a legitimate and underappreciated risk category. It is also a narrower claim than "any phished credential equals organization-wide ransomware-grade impact."
What is worth taking from GhostLock disclosure
Strip away the ransomware framing and two narrow, actionable findings remain.
The NAS session telemetry gap is real but not novel. Per-session exclusive handle counts are not part of standard SIEM pipelines in most enterprises. That is a process and instrumentation gap that predates GhostLock and will persist after it.
A detection rule alerting on sessions accumulating more than a few hundred exclusive handles is straightforward to write. Equally absent from the paper’s mitigation section: Least privilege access to file shares limits the blast radius of a compromised credential and Allowlisting stops the tool from executing on any endpoint where Python is not approved.
None of these are novel recommendations. Both directly constrain the conditions GhostLock depends on.
The organizational gap between SecOps and StorageOps is similarly real and similarly not new. Most incident response runbooks cover endpoint isolation and credential revocation because those are the scenarios organizations have practiced. NAS session termination is not in the muscle memory of the average incident responder. That is worth fixing, and it would have been worth fixing before anyone wrote a parallelized file-locking tool.
Both gaps are addressable in an afternoon with the right cross-team coordination. Neither justifies the ransomware equivalence claim, the "undetectable" framing, or the implication that this represents a new category of threat.
What GhostLock actually demonstrates is that a well-understood OS behavior can be automated at scale and that storage telemetry is under-instrumented. Those are useful data points. They did not need the hype to be actionable. Conversely, the hype makes it harder to take them seriously.
ABOUT THE AUTHOR
Andrea Pomaranski is a Special Projects IT Engineer at ThreatLocker, working on R&D‑focused technical initiatives across enterprise systems, identity infrastructure, and platform integrations. She studied Computer Science at the University of Florida and began her career in IT before moving into software development, supporting mission‑critical systems in highly regulated production environments. A longtime CTF competitor, Andrea honed her security skills through university, independent study, and past workplaces, including as an active member of UF’s Security and Information Technology (SIT) organization. Outside of work, she maintains a hands‑on homelab where she experiments with hardware and operating systems. She brings a builder’s mindset and a deep interest in how vulnerabilities emerge in real‑world systems to product research and technical investigation.
