# GhostLock: How Attackers Can Abuse Legitimate Windows APIs to Paralyze File Access


A newly disclosed proof-of-concept tool reveals a sophisticated technique for blocking access to critical files across networks—without needing elevated privileges or triggering traditional detection systems. GhostLock exploits a fundamental Windows API feature to create denial-of-service conditions that could distract defenders while attackers conduct more damaging operations.


## The Threat


Security researcher Kim Dvash of Israel Aerospace Industries has released GhostLock, a proof-of-concept tool that demonstrates how attackers can weaponize the Windows CreateFileW API to lock files on local systems and SMB network shares. Unlike ransomware or destructive malware, GhostLock creates operational disruption by rendering files inaccessible to legitimate users and applications—effectively freezing critical business data without encrypting or deleting it.


The attack is remarkably efficient: it requires no administrative privileges, can be executed by standard domain users, and operates using legitimate Windows functions. When files are locked via GhostLock, users attempting to access them encounter Windows' STATUS_SHARING_VIOLATION error, preventing both reads and writes.


"The impact is disruption-based, not destructive," Dvash explained to BleepingComputer. "The parallel to ransomware is the operational downtime window, not data loss."


## Technical Details: How GhostLock Works


GhostLock exploits the dwShareMode parameter within the CreateFileW() function—a core Windows API designed to control file access permissions. Understanding the mechanism requires examining how Windows manages file sharing:


When a process opens a file using CreateFileW, it specifies a dwShareMode value that determines what access other processes have to that file while it remains open. The critical parameter is dwShareMode = 0, which grants the opening process exclusive access to the file. Windows then denies all subsequent attempts by other users or applications to open that same file.


### Example Attack Code


HANDLE hFile = CreateFileW(
  L"\\\\server\\share\\finance.xlsx",
  GENERIC_READ,
  0,  // dwShareMode = 0 (exclusive access)
  NULL,
  OPEN_EXISTING,
  FILE_ATTRIBUTE_NORMAL,
  NULL
);

When any other process attempts to open the file during this exclusive lock, Windows immediately returns a sharing violation error.


### Scaling the Attack


The GhostLock tool automates this by:


1. Recursively scanning SMB shares for files

2. Opening thousands of files in exclusive mode simultaneously

3. Maintaining active handles on those files to sustain the locks

4. Continuously reacquiring handles if processes are terminated, allowing the attack to persist even if some locks are broken


The attack becomes more potent when launched from multiple compromised devices simultaneously, distributing the file-locking workload across the network and making it harder to isolate and stop.


## Background and Context


Dvash published the GhostLock proof-of-concept on GitHub along with comprehensive technical documentation explaining the attack methodology. His motivation was educational: to demonstrate a gap between what security tools monitor and what attackers can actually exploit.


The researcher created this tool to highlight a critical blind spot in modern security monitoring. Most endpoint detection and response (EDR) systems, security information and event management (SIEM) platforms, and network detection and response (NDR) tools are calibrated to catch:


  • Mass file writes (ransomware signatures)
  • Encryption operations (cryptographic activity)
  • Suspicious process behavior (anomalous execution)

    • GhostLock generates none of these observable signals. Instead, it creates legitimate file-open requests—activity that appears completely benign to conventional security tools.


    ## Detection Challenges and Observable Signals


    The stealth of GhostLock lies in its use of normal, expected Windows operations. However, Dvash identified one reliable detection vector:


    > "The only observable that reliably identifies this attack is the per-session open-file count with ShareAccess = 0 at the file server layer — a metric that lives inside storage platform management interfaces, not in Windows event logs, not in EDR telemetry, not in network flow data."


    This means defenders must look beyond traditional endpoint and network monitoring and examine metrics available through:


  • Storage and file server management interfaces (NetApp, Dell EMC, Pure Storage dashboards)
  • SMB protocol analyzers capable of deep packet inspection
  • File server audit logs configured to track file-sharing mode parameters

    • Dvash provided SIEM queries and NDR detection rules in his GhostLock whitepaper as a starting point for organizations building custom detection strategies.


    ## Implications for Organizations


    ### Operational Impact


    GhostLock transforms a technical capability into a genuine business disruption vector:


  • Freezes critical workflows: Finance teams cannot access spreadsheets; development teams cannot reach repositories; HR cannot access personnel records
  • Requires no destructive capability: Unlike ransomware, no encryption or data deletion is needed—the simple act of holding file handles paralyzes operations
  • Survives process termination: If a single GhostLock process is killed, the attacker relaunches it, maintaining continuous disruption
  • Survives until logout or reboot: File handles only release when the SMB session terminates, the process is killed permanently, or the system reboots

    • ### Attack Scenarios


    Security teams should anticipate GhostLock used in these contexts:


    1. Smokescreen during intrusions: Attackers trigger widespread file-access disruptions to occupy IT staff while conducting data theft, lateral movement, or privilege escalation elsewhere

    2. Leverage for extortion: Attackers demand payment not for decryption (since files aren't encrypted) but for stopping the disruption

    3. Hybrid attacks: Combined with actual ransomware on other systems to amplify perceived severity and pressure victims to negotiate


    ## Recommendations for Defense


    Organizations should implement a multi-layered approach:


    ### For IT and Storage Teams


    | Action | Priority | Timeline |

    |--------|----------|----------|

    | Enable file server auditing for ShareAccess=0 conditions | High | Immediate |

    | Configure storage-layer alerts for abnormal open-file counts per session | High | 1-2 weeks |

    | Review SMB firewall rules and restrict lateral SMB access | High | Ongoing |

    | Implement session limits on SMB shares to cap concurrent opens | Medium | 1-2 weeks |

    | Test incident response playbooks for file-access disruption scenarios | Medium | Monthly |


    ### For Security Operations


  • Update SIEM rules using templates from the GhostLock whitepaper
  • Train analysts to recognize file-access disruption patterns distinct from encryption or malware
  • Correlate signals between endpoint activity and storage-layer metrics
  • Segment networks to limit SMB lateral movement

    • ### For System Administrators


  • Enforce network segmentation to restrict which systems can reach SMB shares
  • Use SMB signing and encryption to increase attack complexity
  • Implement just-in-time (JIT) access for shared storage, requiring authentication at the moment of need
  • Monitor process creation for tools that open files recursively

    • ---


    ## HackWire Analysis


    Why GhostLock matters now: This vulnerability exposes a critical gap in how we monitor and defend against file-system attacks. For years, the security industry has optimized detection around destructive operations—encryption, mass deletion, exfiltration. GhostLock inverts that paradigm: it achieves operational impact through *volume*, not *malice*. An attacker doesn't need to break anything; they just need to hold everything.


    The timing is significant because it arrives as organizations increasingly rely on hybrid and cloud-connected file systems. A GhostLock attack on an on-premises SMB share can now ripple across departments relying on seamless access. The technique is also democratized—Dvash published a working tool and detection guidance, meaning defenders and attackers both have immediate access to the same information.


    What makes this particularly concerning is the *detection blindness* Dvash documented. EDR vendors and SIEM vendors have built sophisticated models around detecting "bad" operations. But GhostLock is not a bad operation—it's an innocuous one repeated at scale. This is similar to past incidents where attackers used legitimate administrative tools to compromise systems; the detection gap exists not because the tool is hidden, but because the signal is indistinguishable from normal behavior.


    Organizations defending against this should recognize that file-access attacks may not be obvious until users report disruption. The remediation window depends entirely on how quickly storage teams can detect the condition and IT can reset SMB sessions. For critical systems, this could mean hours of downtime—more than enough time for a sophisticated attacker to complete secondary objectives elsewhere.


    The hidden risk: organizations running older storage systems may lack the management interfaces needed to see per-session open-file counts. This creates a cohort of potential targets with no visibility into GhostLock attacks until end-users sound the alarm.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)