00 The Finding
A domain user with read access to a file share can produce
ransomware-equivalent availability impact using a single
documented Windows API call —
with zero writes, zero encryption, and zero signals
in every behavioral defense your enterprise has deployed.
The security industry has invested a decade building ransomware defenses around one foundational
assumption: to deny availability, an attacker must transform the data.
Encrypt it. Rename it. Write something to disk.
GhostLock invalidates that assumption entirely. By calling CreateFileW with
dwShareMode = 0x00000000 across a target share, a low-privileged user holds
files in an exclusively locked state indefinitely. Other clients receive
STATUS_SHARING_VIOLATION (0xC0000043) on every access attempt.
ERP systems fail. Workflow queues stall. The impact is indistinguishable from encrypted ransomware.
The attack produces none of the signals that encrypted ransomware produces.
This is not a vulnerability. There is no patch. CreateFileW with no sharing is
correct, documented behavior required for data integrity across thousands of enterprise
applications. The technique has been available to any authenticated Windows user for 30 years.
02 Mechanism
The
mechanism
CreateFileW and dwShareMode
Every file open on Windows goes through a single API: CreateFileW. Among its
parameters is dwShareMode — a bitmask that tells the operating system whether
other processes are allowed to open the same file concurrently. Three flags exist:
FILE_SHARE_READ, FILE_SHARE_WRITE, and
FILE_SHARE_DELETE. Setting any flag grants that type of concurrent access.
Setting none of them — passing 0x00000000 — is the exclusive mode.
When dwShareMode = 0, the Windows I/O Manager records the handle as exclusive
in the kernel's per-file SHARE_ACCESS structure. From that moment, any other
process or remote client attempting to open the same file for any reason receives
STATUS_SHARING_VIOLATION (0xC0000043) — immediately, before any disk I/O
occurs. The lock lives entirely in kernel memory. It requires no elevated privilege, no
driver, and no special capability. It is the same mode Microsoft Word uses when you open
a document for editing.
Over SMB, this exclusivity request travels as the ShareAccess field of an
SMB2 CREATE request. The file server receives it, records the exclusive open
in its session table, and begins rejecting all subsequent opens of that file from any other
client on the network. The handle persists — and the lock holds — for as long as the
TCP session remains alive. There is no timeout. There is no server-side limit on how many
files a single session may hold in this state.
The result is exactly what any user experiences when they try to open a file that someone
else already has open for editing:
↑ What every client sees while GhostLock holds the handle
GhostLock scales this single API call across an entire directory tree. Using a 32-thread
parallel scanner, it acquires exclusive handles on hundreds of thousands of files within
minutes. Every one of those files then produces this dialog — or its programmatic equivalent,
a STATUS_SHARING_VIOLATION error — for every other client on the network that
tries to access them. Business applications fail. ERP systems throw errors. Workflow queues
stall. The organization experiences the same operational impact as a ransomware attack.
Nothing was written. Nothing was encrypted. The ghost left no trace.
// The entire attack in one API call — repeated across every file
HANDLE CreateFileW(
L"\\fileserver\share\critical.xlsx",
0x80000000, // GENERIC_READ — standard user permission
0x00000000, // dwShareMode = 0 <-- deny ALL concurrent access
NULL,
3, // OPEN_EXISTING
0x00000080, // FILE_ATTRIBUTE_NORMAL
NULL
);
// Every other client now receives STATUS_SHARING_VIOLATION (0xC0000043)
// until this handle is closed or the session is forcibly terminated.
// No writes. No renames. No encryption. Nothing on disk changed.
Scale: parallel discovery
GhostLock uses a 32-thread parallel os.scandir() scanner to discover and lock
files recursively. Each directory listing is a separate SMB round-trip, so parallelizing
across threads cuts wall-clock time dramatically. On a share containing 500,000 files over a
standard 10 GbE LAN, full lock acquisition completes in under 10 minutes — faster than any
encryption-based ransomware operating against the same file set, generating none of the I/O
signatures encryption produces.
Persistence
If the attacker's session is terminated, re-running GhostLock against the same path
re-establishes all locks within minutes. The files are never modified, so there is no
partial state to reason about. The attacker can maintain their position indefinitely.
The victim has no recourse except to locate the session and terminate it — a task
requiring storage administration expertise most incident response teams do not have on-call.
Directory-level locking — one handle, entire folder
GhostLock v2 introduces a more surgical variant: locking the directory object
itself rather than individual files. By passing
FILE_FLAG_BACKUP_SEMANTICS alongside dwShareMode = 0,
a caller opens a directory with an exclusive deny-share handle using a single API call.
One handle. The entire folder.
Where the original technique requires one handle per file — potentially tens of thousands
of handles to cover a share — directory-level locking achieves targeted structural
disruption with a single handle. No file enumeration. No parallel scanner. No cache.
Just a path and a flag.
// Lock an entire directory with a single handle
HANDLE CreateFileW(
L"\\\\fileserver\\share\\finance",
0x80000000, // GENERIC_READ
0x00000000, // dwShareMode = 0 <-- deny all concurrent access
NULL,
3, // OPEN_EXISTING
0x02000000, // FILE_FLAG_BACKUP_SEMANTICS <-- opens directory objects
NULL
);
// One handle. One call. The directory becomes a namespace blackout.
What SMB enforces — empirical results
Controlled testing over a real SMB share confirms that the SMB server enforces
directory exclusivity more aggressively than local NTFS. The results reveal a
namespace blackout: the directory structure becomes frozen and
invisible to every other SMB client while the single handle is held.
| Operation |
Local NTFS |
Over SMB |
| Rename file inside dir |
Blocked |
Blocked |
| List directory contents |
Allowed |
Blocked |
| Recursive copy / backup |
Allowed |
Blocked |
| Open directory object |
Blocked |
Blocked |
The critical SMB-specific finding is directory enumeration. On local NTFS, child
operations are largely unaffected by an exclusive handle on the parent directory.
Over SMB, the server enforces the exclusivity at the namespace level:
Get-ChildItem, Explorer browsing, recursive backup operations, and
search indexers that enumerate directory contents all fail with
ERROR_SHARING_VIOLATION. The directory becomes a black box.
Individual files at known paths remain accessible — the lock does not block reads
or writes to files whose paths are already known. What it destroys is
discoverability. No client can learn what is inside the directory.
No backup can traverse it. No indexer can crawl it. With one handle held by one
standard user, an entire department folder tree becomes operationally invisible.
05 Frequently Asked
FAQ
Is there a patch?
No. CreateFileW with dwShareMode = 0 is correct, documented behavior specified in the SMB protocol and required for data integrity by thousands of enterprise applications including Microsoft Office, database engines, and version control systems. Patching this behavior would break the file integrity model that enterprise applications depend on. There is no CVE. There is no fix coming.
What privilege level is required?
A standard domain user account with read access to the target share. No elevation, no exploit, no special tools. This is the post-phishing state of virtually every successful intrusion in the modern threat landscape. If an attacker has any domain foothold at all, this attack is available to them immediately.
How do I recover if I'm attacked?
A storage administrator must identify the offending SMB session (by inspecting the file server's open session table), correlate it to a source IP and user account, and terminate the session. On most enterprise NAS platforms this requires platform-specific CLI or API knowledge. The files are never modified, so once the session is terminated, access is immediately restored. The challenge is that most incident response teams do not have this expertise on-call, leading to hours or days of downtime.
Can network controls block this?
No. A CREATE request with ShareAccess = 0 over SMB2 is indistinguishable at the packet level from a user opening a document in Microsoft Word for exclusive editing. There is no network signature that separates malicious use from legitimate exclusive file access. Any rule broad enough to catch GhostLock would block normal user activity at scale.
Does this work on cloud file shares?
Any SMB-backed share that correctly implements the SMB2 ShareAccess field is in scope. This includes on-premises NAS platforms, Windows File Server, and cloud services that expose SMB endpoints such as Azure Files. The technique is not vendor-specific — it is an SMB protocol behavior.
Is this legal to test?
Only against systems you own or have explicit written authorization to test. Running this tool against any system without written authorization is illegal regardless of intent. The sentinel file mechanism is a deliberate safety gate — the tool requires you to place an authorization marker in the target directory before it will operate.
Why does my EDR not detect this?
EDR agents look for shellcode injection, process hollowing, DLL sideloading, and encryption-related write patterns. GhostLock is a Python interpreter calling NtCreateFile over the network redirector — identical to a file indexer or backup pre-scan agent. No process behavior heuristic flags this workload without simultaneously flagging legitimate applications that do the same thing.
How fast does it lock files?
In controlled testing, GhostLock locked 500,000 files in under 10 minutes over a standard 10 GbE LAN. The parallel 32-thread scanner runs roughly 10x faster than sequential enumeration because each directory listing is a separate SMB round-trip — parallelizing them saturates available bandwidth. Handle acquisition itself is near-instant per file once discovered.
What happens when the attacker disconnects?
All handles drop when the session ends and files immediately become accessible again. However, the attacker can reconnect and re-establish all locks within minutes using the cached file list — the files were never modified so reconnection restores full lock coverage instantly with no re-discovery scan needed.
Does revoking credentials stop the attack?
Not immediately. The existing SMB session was authenticated before credential revocation, so handles may persist until session timeout — typically 15 to 60 minutes depending on platform configuration. Credential revocation alone is not sufficient for immediate recovery. A storage administrator must explicitly terminate the session.
How is this different from a denial-of-service attack?
Traditional DoS attacks flood network resources or crash services. GhostLock produces zero abnormal network traffic and crashes nothing. It operates entirely within the normal file access model. The impact is surgical — only files the attacker has chosen to lock are affected — and the attacker maintains full control over when access is restored, creating the same leverage as encryption ransomware without any of the infrastructure.
What is the maximum number of files that can be locked?
The limit is the NAS platform's per-session open file handle limit, typically ranging from 16,000 to 64,000 per session. Multiple sessions from different source endpoints multiply this linearly — three sessions means three times the coverage, all from the same standard user account with no additional privilege.
Can I use GhostLock in a penetration test?
Yes, with explicit written authorization that specifically covers availability impact testing against the target share. Standard penetration test scopes often exclude availability attacks — confirm your scope explicitly covers this before running the tool. Always use the sentinel file mechanism and test against non-production volumes first.
Has this been responsibly disclosed?
Yes. The technique was disclosed to the organization where it was discovered during an authorized engagement prior to any public communication. No CVE was filed because there is no software defect to patch. The research was published to enable defenders to detect and respond to this threat class — a threat that cannot be defended against if it has never been characterized.
Does this affect Linux or macOS SMB clients?
The tool as written uses the Windows CreateFileW API via ctypes and runs on Windows only. However, the underlying SMB2 protocol behavior is platform-agnostic — any SMB2 client capable of sending ShareAccess = 0 in a CREATE request can produce the same effect. The Windows implementation is the most practical because exclusive file handles are a standard part of the Win32 programming model.
How do I build detection for this in my SIEM?
The primary signal is per-session exclusive handle count from your NAS management layer. Alert when any single SMB session holds more than 500 files open with ShareAccess = 0 simultaneously. Secondary signal: bulk SMB CREATE operations from a single source IP with zero corresponding WRITE operations over a 30-minute window. See the research paper for full SIEM query examples.
What is the directory-level locking variant?
GhostLock v2 locks the directory object itself rather than individual files. One CreateFileW call with FILE_FLAG_BACKUP_SEMANTICS and dwShareMode = 0 acquires an exclusive handle on the entire folder. Over SMB this creates a namespace blackout: other clients cannot list directory contents, cannot rename anything inside, cannot recursively copy or backup the tree, and cannot open the directory object. Individual files at known paths remain accessible. The detection footprint is a single SMB2 CREATE on a directory path — indistinguishable from a backup agent opening a folder for traversal. One handle. One API call. No file enumeration required.
