GhostLockはSMB共有を暗号化なしで業務停止させる

TL;DR

---

GhostLockは、ランサムウェアっぽい停止を暗号化なしで作る。
Andrea Fortunaが2026年5月10日に紹介した分析と、Kim Dvashが公開したPoCは、Windowsの正規API CreateFileW の共有モードを使ってSMB共有上のファイルを大量に排他ロックする。

やっていることは脆弱性悪用ではない。
dwShareMode = 0 でファイルを開くと、MicrosoftのCreateFileWドキュメントどおり、既存ハンドルが閉じられるまで後続の読み取り・書き込み・削除目的のオープンが拒否される。
SMB2ではこの共有モードが SMB2 CREATE リクエストの ShareAccess として運ばれる。MicrosoftのMS-SMB2仕様でも、FILE_SHARE_READ、FILE_SHARE_WRITE、FILE_SHARE_DELETE の組み合わせで共有可否を表すフィールドになっている。

普通のアプリが正しく使うための仕組みを、閉じないハンドルとして大量に積み上げる。
それだけで他のユーザーや業務アプリは STATUS_SHARING_VIOLATION にぶつかり、ファイルを開けなくなる。

ファイルを壊さないのに止まる

従来のランサムウェア対策は、暗号化I/Oやファイル名変更をかなり強く見ている。
Cisco FMCをInterlockランサムウェアが悪用した記事で扱ったような攻撃チェーンでも、最終的な被害としては暗号化、バックアップ破壊、横展開後のデータ処理が観測対象になりやすい。

GhostLockはそこを通らない。
PoCの説明では、通常のドメインユーザー権限と対象共有への読み取り権限があれば、Pythonから CreateFileW を呼び出して排他ハンドルを保持できる。
報告されているテストでは、32スレッドの並列探索で50万ファイル規模の共有を約6分で走査し、その後約2分半で49.8万件の排他ハンドルを取得している。成功率は99.6%。

暗号化しない。
拡張子を変えない。
中身を書き換えない。
ハニーファイルにも書き込まない。

被害側から見ると、業務アプリやOffice文書や共有フォルダが突然「使用中」扱いになる。
ディスク上のタイムスタンプやファイル内容だけ見ても、ランサムウェアの痕跡は出ない。

排他ハンドルは正規動作なので塞ぎにくい

dwShareMode=0 は不審な裏技ではない。
Microsoftのドキュメントは、共有モード0を「後続の読み取り・書き込み・削除アクセスを防ぐ」値として説明している。
共有オプションはハンドルが閉じられるまで有効、という挙動も明記されている。

これをAPIレベルで禁止すると、Office、SQL Server、ビルドツール、バージョン管理ツールのような正規アプリまで壊す。
排他オープンは、同時編集や破損を防ぐための基本機能だからだ。
Fortunaの記事も、CVEや通常のパッチとして処理される性質の問題ではないと見ている。

SMB側でも事情は同じだ。
クライアントが ShareAccess を指定し、サーバーがその共有契約を守る。
ここを「たくさん開いたら無視する」と雑に変えると、Windowsファイル共有の互換性を壊す。

flowchart TD
    A[侵害された通常ユーザー] --> B[SMB共有を走査]
    B --> C[CreateFileWを共有モード0で呼び出し]
    C --> D[排他ハンドルを大量保持]
    D --> E[他ユーザーのオープンが失敗]
    E --> F[業務アプリが停止]
    D --> G[NASセッション表に排他ハンドル数が残る]

検知信号はNAS側に寄る

Fortunaの記事とGhostLockのREADMEが強調しているのは、ほとんどの検知層が「書き込み」を前提にしている点だ。
ランサムウェア検知、ハニーファイル、DLP、NDRの大量転送検知は、暗号化やリネームや大量読み取りを見に行く。
GhostLockではその信号が出ない。

層	見ているもの	GhostLockで欠けるもの
ハニーファイル（おとりファイル）	書き込み、リネーム、削除	読み取りオープンだけでロック成立
書き込み量検知	大量のWRITE	ターゲット共有への書き込みゼロ
EDR（端末検知・対応）	注入、暗号化処理、不審プロセス	ファイル索引やバックアップ前走査に近い見え方
NDR（ネットワーク検知・対応）	SMB WRITE、RENAME、SET_INFO	CREATEとCLOSE中心
DLP（データ漏洩防止）	大量読み取りと外部転送	ほぼデータを読まない
NAS管理テーブル	セッション別の開いているファイル数	排他ハンドルの異常な蓄積が見える

一番使える信号は、NASの管理セッションテーブルにある。
1つのSMBセッションが同時に持っている排他ハンドル数だ。
通常のアプリはファイルを開き、処理し、閉じる。
1セッションが数百から数千の排他ハンドルを持ち続ける動きは、バックアップやインデクサでも説明しづらい。

GhostLock側の提案では、1セッションあたり500件超の排他ハンドルをアラート閾値の起点にしている。
この値は万能ではないが、従来の暗号化I/O検知よりは攻撃の芯に近い。

復旧はアカウント停止だけでは足りない

地味に嫌なのが復旧手順だ。
侵害アカウントをActive Directoryで無効化しても、すでに認証済みのSMBセッションが即時に消えるとは限らない。
Fortunaの記事では、設定次第で15〜60分ほどハンドルが残りうると説明している。

つまり、ID側の初動だけではロックが解除されない。
ストレージ管理者がNAS側で該当セッションを見つけ、強制切断する必要がある。
セキュリティ運用チームがEDR画面だけを見ていると、ファイルは暗号化されていないのに業務だけ止まる、というかなり面倒な事故になる。

ランブック（対応手順書）には、少なくとも次の作業が入る。

作業	担当
NASのセッション表で排他ハンドル数の多いセッションを探す	ストレージ管理
セッションID、ユーザー、送信元IPをADやVPNログと突き合わせる	SecOps
該当SMBセッションをNAS側で切断する	ストレージ管理
アカウント無効化と端末隔離を並行する	SecOps
排他ハンドル数が平常値へ戻ったことを確認する	両チーム

PoCには既存ファイルを対象にする前の安全機構や、生成したテストファイルだけをロックするモードがある。
だから防御側の検証には使いやすい。
ただし、本番共有で試すなら「読み取りだけだから安全」とは考えないほうがいい。
ファイルは壊れなくても、開けないだけで業務は止まる。

まだ独立検証は薄い

現時点で確認できる公開情報は、Andrea Fortunaの記事、GhostLockのGitHub README、Zenodoのホワイトペーパーが中心だ。
商用EDRやNDRがすべて無反応だったという記述は強いが、製品名や設定条件まで独立に比較した第三者検証はまだ見当たらない。

そこは割り引いて読む。
それでも、CreateFileW の共有モード0とSMB2の ShareAccess が正規仕様である点はMicrosoftの一次情報で確認できる。
PoCの数字だけを鵜呑みにしなくても、NASセッションの排他ハンドル数をSIEM（セキュリティ情報イベント管理）に入れていない組織が多い、という指摘はそのまま運用上の穴になる。