GhostLock proof-of-concept abuses Windows file-sharing API to disrupt file access without encryption

A researcher at Israel Aerospace Industries published a proof-of-concept tool called GhostLock that uses a legitimate Windows API call to make files unreadable without encrypting anything. The technique abuses the dwShareMode parameter of CreateFileW - setting it to 0 grants the calling process exclusive access, so every other user or app trying to open the file gets a sharing violation. GhostLock automates this recursively across SMB shares from a standard domain user account, no elevation required. Researcher Kim Dvash frames it as a disruption attack, not destructive - data is not lost, but operational downtime can mirror a ransomware incident.

Check

Review your EDR and SIEM detection rules for behavior-based ransomware indicators. Verify they cover sharing-violation spikes and ShareAccess=0 file-open counts, not just mass file write or encryption activity.

Affected

Windows file servers and SMB shares in environments where any standard domain user account can authenticate. No CVE has been assigned - GhostLock abuses intended Windows file-sharing behavior, not a flaw. Behavioral detection systems focused on mass writes or encryption operations will not flag this attack pattern; the attack also requires no elevation.

Fix

Implement detection at the file server layer: monitor per-session open-file counts with ShareAccess=0 - the reliable signal Dvash identifies, which lives in storage platform management interfaces, not Windows event logs or EDR telemetry. Pull the SIEM queries and NDR rule from the GhostLock whitepaper as a detection template. Limit which domain user accounts have read or write access to critical shares.