GhostLock PoC: 500K SMB files locked in 8 min via CreateFileW dwShareMode=0

TL;DR

---

GhostLock produces ransomware-like business disruption without encrypting a single file.
Andrea Fortuna’s analysis posted on May 10, 2026 and Kim Dvash’s PoC on GitHub use the Windows CreateFileW API’s share mode to hold exclusive locks on files across an SMB share.

This is not a vulnerability exploit.
Opening a file with dwShareMode = 0 prevents subsequent read, write, or delete opens until the handle is closed — exactly as Microsoft’s CreateFileW documentation describes.
In SMB2, the share mode travels as the ShareAccess field in an SMB2 CREATE request. Microsoft’s MS-SMB2 specification defines it as a combination of FILE_SHARE_READ, FILE_SHARE_WRITE, and FILE_SHARE_DELETE.

Stack up enough never-closed handles, and every other user or application hitting those files gets STATUS_SHARING_VIOLATION.

Files stay intact, but work stops

Traditional ransomware defenses focus heavily on encryption I/O and file renames.
Even in attack chains like the one covered in the Cisco FMC Interlock ransomware article, the observable damage involves encryption, backup destruction, and data manipulation after lateral movement.

GhostLock bypasses all of that.
According to the PoC README, a regular domain user with read access to the target share can call CreateFileW from Python and hold exclusive handles.
The reported test run: 32 threads scan a 500K-file share in about 6 minutes, then acquire 498K exclusive handles in roughly 2.5 minutes. Success rate: 99.6%.

No encryption.
No extension changes.
No file content modification.
No writes to honeypot files.

From the victim’s perspective, business apps, Office documents, and shared folders suddenly show “file in use” errors.
Checking timestamps or file contents on disk reveals no ransomware artifacts.

Exclusive handles are legitimate, so blocking them is hard

dwShareMode=0 is not a suspicious hack.
Microsoft documents share mode 0 as the value that “prevents subsequent open operations on a file requesting read, write, or delete access.”
The documentation also explicitly states that share options remain in effect until the handle is closed.

Blocking this at the API level would break Office, SQL Server, build tools, and version control — applications that rely on exclusive opens to prevent concurrent edits and corruption.
Fortuna’s article notes that this is not the kind of issue that gets a CVE or a patch.

The same applies on the SMB side.
The client specifies ShareAccess; the server honors the sharing contract.
Loosening that contract (“ignore exclusive mode after too many opens”) would break Windows file sharing compatibility.

flowchart TD
    A[Compromised regular user] --> B[Scan SMB share]
    B --> C[Call CreateFileW with share mode 0]
    C --> D[Hold exclusive handles in bulk]
    D --> E[Other users' opens fail]
    E --> F[Business apps stop]
    D --> G[NAS session table shows handle count]

Detection signals come from the NAS side

Fortuna’s article and the GhostLock README emphasize that most detection layers assume writes.
Ransomware detection, honeypots, DLP (data loss prevention), and NDR (network detection and response) bulk-transfer alerts all look for encryption, renames, or large reads.
GhostLock produces none of those signals.

Layer	What it watches	What GhostLock lacks
Honeypot files	Writes, renames, deletes	Lock established via read-only open
Write volume detection	High WRITE volume	Zero writes to target share
EDR (endpoint detection & response)	Injection, crypto routines, suspicious processes	Looks like a file indexer or pre-backup scan
NDR (network detection & response)	SMB WRITE, RENAME, SET_INFO	Mostly CREATE and CLOSE
DLP (data loss prevention)	High read volume + external transfer	Almost no data read
NAS management table	Per-session open file count	Abnormal accumulation of exclusive handles visible

The most useful signal sits in the NAS management session table: the number of exclusive handles held simultaneously by a single SMB session.
Normal applications open, process, and close files.
A single session holding hundreds or thousands of exclusive handles is hard to explain, even for backup or indexing software.

GhostLock’s authors suggest 500+ exclusive handles per session as a starting threshold for alerts.
That number is not universal, but it targets the core of the attack more directly than write-based ransomware detection.

Account disabling alone does not release the locks

The recovery side is where things get frustrating.
Disabling the compromised account in Active Directory does not necessarily kill already-authenticated SMB sessions.
Fortuna’s article explains that handles can persist for 15–60 minutes depending on configuration.

That means identity-side first response alone does not release the locks.
A storage administrator needs to find and force-disconnect the offending sessions on the NAS.
If the security operations team is only watching the EDR console, they face a confusing scenario: files are not encrypted, yet the business is down.

The runbook needs at least the following steps:

Step	Owner
Find sessions with high exclusive handle counts in the NAS session table	Storage admin
Correlate session ID, user, and source IP against AD and VPN logs	SecOps
Force-disconnect the offending SMB sessions on the NAS	Storage admin
Disable the account and isolate the endpoint in parallel	SecOps
Confirm exclusive handle counts have returned to baseline	Both teams

The PoC includes safety features — it can target only generated test files rather than existing ones.
That makes it usable for defensive testing.
But running it against a production share on the assumption that “read-only means safe” is a mistake.
Files survive intact, but if nobody can open them, the business is still down.

Independent verification is still thin

The publicly available information at this point centers on Fortuna’s article, the GhostLock GitHub README, and a Zenodo whitepaper.
The claim that commercial EDR and NDR products all failed to detect it is strong, but no independent third-party comparison with named products and configurations has surfaced yet.

Read those claims with appropriate skepticism.
That said, the fact that CreateFileW share mode 0 and SMB2 ShareAccess work exactly as specified is verifiable from Microsoft’s primary documentation.
Even without taking the PoC numbers at face value, the observation that most organizations do not feed NAS session exclusive handle counts into their SIEM is a real operational gap.