В открытый доступ вышел исследовательский инструмент GhostLock. Он демонстрирует злоупотребление штатным механизмом Windows API CreateFileW и параметром dwShareMode в функции CreateFileW(), который управляет тем, смогут ли другие процессы открывать файл, пока он уже открыт текущим процессом. Когда файл открывается с помощью клавиши dwShareMode = 0`, Windows предоставляет процессу эксклюзивный доступ к файлу, не позволяя другим пользователям или приложениям открывать его. Последующие попытки открыть его на чтение, запись или удаление завершаются ошибкой совместного доступа. Это не баг и не новая уязвимость, а документированное поведение Windows. Microsoft описывает, что при нулевом режиме совместного доступа файл или устройство нельзя открыть снова до закрытия текущего дескриптора.
Дисклеймер: GhostLock — не то же самое, что GhostLocker ransomware. В сети уже есть материалы про вымогательское ПО GhostLocker, но этот исследовательский кейс касается другой техники.
GhostLock превращает нормальный механизм в массовую блокировку. Инструмент рекурсивно проходит по файлам на SMB и удерживает открытые дескрипторы.
Например, следующий код откроет файл finance.xlsxв монопольном режиме, предотвращая доступ к нему для любых других процессов.
HANDLE hFile = CreateFileW(
L"\\\\server\\share\\finance.xlsx",
GENERIC_READ,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL
);
Пока эти дескрипторы активны, другие пользователи и приложения получают ошибку STATUS_SHARING_VIOLATION. На практике это выглядит как «файл занят другим пользователем», только в масштабе десятков тысяч или сотен тысяч файлов.

Классический шифровальщик меняет файлы: шифрует, переименовывает, создаёт новые расширения, пишет записки с требованием выкупа. GhostLock не делает ничего из этого. Он не портит содержимое файлов и не оставляет изменённого состояния на диске. Доступ возвращается после закрытия дескрипторов, завершения процесса, разрыва SMB-сессии или перезагрузки затронутой системы.
Проблема в другом: бизнесу всё равно, почему файл недоступен, если бухгалтерия, документооборот, ERP или файловый архив перестали работать. Исследователь описывает GhostLock как атаку на доступность, а не как уничтожение данных. Это ближе к точечному отказу в обслуживании внутри файловой инфраструктуры, но с эффектом, который для пользователей напоминает массовую блокировку файлов.
SMB остаются основой файловой инфраструктуры во многих компаниях. Там лежат общие документы, проектные каталоги, выгрузки из учётных систем, инженерные файлы, отчёты, договоры и рабочие папки отделов. GhostLock интересен именно тем, что для демонстрации не нужны права администратора. Достаточно доменной учётной записи с доступом на чтение к целевой папке.
На странице исследования указано, что под удар попадают организации с файловой инфраструктурой SMB-backed: Windows File Server, NAS-платформы, DFS-пространства имён и облачные SMB-сервисы, если они корректно реализуют поведение SMB2 ShareAccess. Исследователь упоминает, что в область риска входят и облачные файловые сервисы с SMB-доступом, включая Azure Files.
В тестовом описании проекта заявлена высокая скорость: GhostLock использует многопоточную обработку и может за минуты получить эксклюзивные дескрипторы для большого числа файлов. Репозиторий описывает сценарий с 32 потоками и массовой блокировкой файлов без записи на диск. Но скорость будет зависеть от NAS, сети, числа файлов, прав пользователя и ограничений платформы.
Многие защиты от вымогателей ищут массовую запись, переименование файлов, резкий рост энтропии, создание новых расширений, изменение большого числа документов или срабатывание файлов-ловушек. GhostLock работает иначе: он открывает файлы и содержит дескрипторы. Для EDR это может выглядеть как обычная активность файлового индексатора, резервного копирования или приложения, которое легально открывает документы.
Ключевой сигнал, на который указывает исследователь, находится не в привычных Windows Event Logs и не в типичной телеметрии EDR. Речь о количестве открытых файлов с эксклюзивным режимом доступа в рамках одной SMB-сессии на стороне файлового сервера или NAS. Проще говоря, защитникам надо смотреть не только на рабочую станцию, но и на таблицы открытых файлов и сессий в самой системе хранения.
Публичных данных о CVE для GhostLock нет. Исследователь пишет, что это не дефект продукта, а штатное поведение API и SMB-механики. Документация Microsoft подтверждает: нулевой dwShareMode запрещает последующие открытия файла или устройства для операций чтения, записи и удаления до закрытия текущего дескриптора. Такой режим нужен обычным приложениям, например редакторам документов и другим программам, которым требуется контроль целостности файла во время работы.
Именно поэтому просто пропатчить эту механику нельзя без риска сломать совместимость. Ограничивать надо не сам факт эксклюзивного открытия, а аномальное массовое использование: один пользователь, одна сессия, тысячи файлов, долгие удержания дескрипторов, отсутствие реальных операций записи.
Восстановление сводится к поиску и завершению проблемной SMB-сессии, процесса или соединения, которое держит эксклюзивные дескрипторы. После закрытия дескрипторов доступ возвращается.
Сложность в операционной части. Команде реагирования нужны люди, которые умеют быстро работать с файловым сервером или NAS: смотреть открытые файлы, сессии, IP-адрес источника, пользователя и массовые exclusive opens. Простая смена пароля может не дать мгновенного эффекта, если активная SMB-сессия уже установлена и продолжает жить до разрыва соединения или таймаута.
Администраторам файловой инфраструктуры стоит проверить, умеют ли их NAS, Windows File Server и системы мониторинга показывать число открытых файлов на сессию с эксклюзивным режимом доступа. Полезный базовый сигнал — резкий рост открытых дескрипторов у одного пользователя или с одного IP-адреса без сопоставимого объёма записи.
Командам SOC стоит добавить сценарий GhostLock в плейбуки реагирования на «массово недоступные файлы». Важный вопрос при инциденте: файлы зашифрованы или просто заняты дескрипторами? От ответа зависит способ восстановления и необходимость запускать резервное копирование.
Инфраструктурным командам стоит пересмотреть права на SMB. Чем шире доступ, тем больше площадь для такой атаки после фишинга или компрометации обычной доменной учётки. Минимальные права, сегментация, ограничения по сессиям, мониторинг открытых файлов и быстрая процедура разрыва подозрительных SMB-соединений — способ защититься.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.