GhostLock Attack Exploits Windows SMB to Lock Files

Key Takeaways

• A new technique called GhostLock exploits standard Windows SMB file-sharing to render files inaccessible without encryption.
• It achieves business disruption similar to ransomware by exclusively locking files, preventing any other access.
• The attack leverages a fundamental, unpatchable Windows feature (CreateFileW API with dwShareMode=0), meaning no CVE is assigned.
• GhostLock evades most conventional ransomware defenses, as it performs no write operations, making detection challenging.
• Mitigation requires monitoring for anomalous numbers of exclusive file handles per SMB session and establishing coordinated SecOps/StorageOps incident response.

GhostLock: A New Paradigm in File Share Disruption

While traditional ransomware encrypts data and demands payment, a recently unveiled technique named GhostLock introduces a novel approach to achieving similar business disruption without altering a single byte on disk. This method focuses on denying access rather than encrypting files, presenting a significant challenge to existing cybersecurity defenses.

Discovered by Kim Dvash, an Offensive Security Team Leader, GhostLock exploits fundamental behaviors within Windows file-sharing protocols to induce widespread accessibility failures. By systematically holding files in an exclusively locked state, a low-privileged domain user with standard read permissions can effectively paralyze corporate Server Message Block (SMB) file shares.

From a victim’s perspective, the impact of GhostLock is functionally indistinguishable from a ransomware attack. Critical files become unavailable, enterprise resource planning (ERP) applications may crash, and shared workflow pipelines fail, necessitating specialized intervention to restore normal operations.

Technical Underpinnings of the Attack

The GhostLock technique leverages a well-documented and core behavior of the Windows operating system. By invoking the CreateFileW API and setting the dwShareMode parameter to 0x00000000, any authenticated domain user can acquire an exclusive deny-share handle on a file over SMB. This action prevents any other process or network client from opening that specific file for any purpose—be it reading, writing, or deleting—until the handle is either voluntarily released or forcibly terminated by a storage administrator.

This behavior triggers a STATUS_SHARING_VIOLATION (0xC0000043) error for all subsequent access attempts. It’s important to note that this attack surface is not new; the CreateFileW API with dwShareMode = 0 is the same mechanism Microsoft Office uses when opening a document for editing. This functionality has been present since Windows NT 3.1. Consequently, no CVE has been filed for GhostLock, as it exploits an intended, albeit potentially misused, operating system feature rather than a software defect requiring a patch.

GhostLock Attack at Scale

The GhostLock implementation utilizes a Python ctypes wrapper to execute the critical API call, requiring no administrative privileges or external dependencies. To scale this attack across an enterprise Network Attached Storage (NAS) environment, it employs a 32-thread parallel work-stealing scanner. This scanner optimizes SMB2 QUERY_DIRECTORY round-trips, drastically reducing the time required for file discovery. For instance, on a file share containing 500,000 files, the discovery time was cut from over 61 minutes to approximately 6 minutes and 22 seconds.

In isolated infrastructure tests, the acquisition of exclusive handles across 500,000 files was completed in just 2 minutes and 37 seconds, achieving an impressive 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 concurrently hold up to 64,000 exclusive handles, meaning ten parallel sessions could accumulate over 500,000 locked handles, sufficient to incapacitate a substantial portion of an entire enterprise NAS deployment.

Evasion of Conventional Defenses

One of the most concerning aspects of GhostLock is its ability to bypass nearly all conventional ransomware defense layers. The research evaluated the tool against seven categories of enterprise security controls, with alarming results:

• Honeypot/canary files: Produced zero alerts because canaries typically trigger on write events, and GhostLock performs no write operations.
• Write-rate anomaly detectors: Generated zero alerts as the monitored metric (write operations) is entirely absent from GhostLock’s activity.
• Behavioral AI ransomware engines: Also produced zero alerts, as GhostLock’s read-open profile is indistinguishable from legitimate activities like a search indexer or backup pre-scan agent.
• Commercial EDR agents: Exhibited zero alerts, as the system call profile mirrors common actions such as Microsoft Word opening documents.
• NDR/deep packet inspection: Showed zero alerts, with SMB2 traffic consisting only of CREATE and CLOSE requests, identical to normal document access.
• SIEM correlation rules: Produced zero alerts, as no existing rulesets are designed to monitor per-session exclusive handle accumulation.

The only reliable detection signal identified resides within the NAS management layer itself: the per-session count of simultaneously held exclusive handles. The research highlights that a legitimate single-user application rarely holds more than a few dozen exclusive handles concurrently, whereas GhostLock accumulates tens of thousands. However, this critical metric is not typically ingested by enterprise SIEMs, as noted in the study.

Recovery Challenges and Recommendations

Even after detection, recovery from a GhostLock attack is not straightforward. Terminating the offending SMB session requires specific storage administration expertise. In many large enterprises, storage operations and security operations teams function independently, often lacking pre-built joint runbooks for such incidents. Tabletop exercises without a pre-existing runbook estimated a mean time to recovery of 4 to 8 hours.

Furthermore, if an attacker’s Active Directory credentials are revoked, the existing authenticated SMB session and all its associated locks can persist for an additional 15 to 60 minutes, depending on platform configuration, before the session times out.

Dvash urges NAS vendors to expose per-session exclusive-handle counts as standard security telemetry, integrated with existing syslog outputs. He also calls on SIEM vendors to develop storage platform integrations capable of ingesting this crucial data.

The GhostLock tool and its source code are publicly available at github.com/kimd155/ghostlock, with further research details on the companion site at ghostlock.io.

What You Should Do

• Implement Anomaly Detection for Exclusive Handles: Configure alerts for any single SMB session accumulating more than 500 exclusive handles. This threshold can be adjusted based on your environment’s typical usage.
• Enhance Network Detection and Response (NDR): Establish an NDR rule to flag bulk SMB CREATE requests that are not followed by corresponding WRITE operations within a defined time window (e.g., 30 minutes).
• Develop Joint SecOps/StorageOps Runbooks: Create and regularly test a specific incident response runbook for NAS session termination, ensuring seamless coordination between security and storage administration teams.
• Pressure Vendors for Telemetry Improvements: Advocate for NAS vendors to expose per-session exclusive-handle counts as standard security telemetry and for SIEM vendors to integrate this data.
• Review Active Directory Session Timeouts: Evaluate and potentially reduce SMB session timeout configurations to minimize the persistence of malicious locks after credential revocation.

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.