GhostLockとは何か：Windows正規APIを悪用する「ファイルロック型」妨害手法の脅威

GhostLockとは何か：Windows正規APIを悪用する「ファイルロック型」妨害手法の脅威

冒頭文
Windows環境の業務停止リスクとして、ランサムウェアのような暗号化攻撃ばかりが注目されがちです。しかし、ファイルを破壊せず、暗号化もせず、正規のWindows APIを利用するだけで、共有ファイルへのアクセスを妨害できる手法が現実味を帯びています。その代表例として注目されているのが、概念実証ツール「GhostLock」です。GhostLockは、Windowsのファイル操作に使われる正規機能を逆手に取り、ローカルファイルやネットワーク共有ファイルを他のユーザーやアプリケーションから開けなくする可能性があります。これは従来型のマルウェア検知では見落とされやすく、企業のファイルサーバー運用に新たな警戒ポイントを突きつけています。

GhostLockが示した新しい業務妨害の形

GhostLockは、Windowsの正規APIを悪用してファイルアクセスを妨害する概念実証ツールです。最大の特徴は、ファイルを暗号化したり削除したりするのではなく、ファイルを「開いたまま占有する」ことで他の利用者やアプリケーションのアクセスを阻害する点にあります。

従来、企業が最も警戒してきたファイル関連の攻撃は、ランサムウェアによる暗号化やワイパー型マルウェアによる破壊でした。これらはファイル内容そのものを改変するため、異常な書き込み、拡張子変更、大量の暗号化処理といった痕跡が比較的検知しやすい傾向があります。

一方、GhostLock型の手法は見え方が異なります。攻撃者はファイルを壊すのではなく、正規のファイルオープン処理を使ってアクセス権を占有します。その結果、他のユーザーがファイルを開こうとした際に共有違反が発生し、業務アプリケーションやファイル共有システムが正常に動作しなくなる可能性があります。

この手法が厄介なのは、表面的にはWindowsの通常操作に見えることです。ファイルを開くという処理自体は日常的に発生するため、セキュリティ製品が即座に悪意ある行動と判断するのは簡単ではありません。攻撃の本質が「破壊」ではなく「占有」にあるため、従来の検知ルールだけでは十分に捉えられない恐れがあります。

悪用されるCreateFileW APIとは

GhostLockが利用する中核的な仕組みは、WindowsのCreateFileW APIです。CreateFileWは、Windows上でファイルやデバイスを開く際に使われる正規のAPIであり、多くのアプリケーションが日常的に利用しています。

このAPIには、ファイルをどのような共有モードで開くかを指定するパラメータがあります。ここで重要になるのが、dwShareModeと呼ばれる指定です。通常、アプリケーションは他のプロセスと読み取りや書き込みを共有できるよう、一定の共有モードを設定します。たとえば、あるユーザーがファイルを読んでいる間も、別のユーザーが同じファイルを読み取れるようにする、といった制御です。

しかし、dwShareModeをゼロに設定すると、そのプロセスは対象ファイルに対して排他的なアクセスを取得できます。つまり、他のユーザーやアプリケーションが同じファイルを開こうとしても、Windows側が共有違反として拒否する状態になります。

この挙動自体は脆弱性ではありません。Windowsが本来備えているファイル共有制御の仕様です。問題は、この正規仕様を大量のファイルや共有フォルダに対して意図的に適用した場合、業務継続に大きな支障を与えられる点にあります。

ファイルを壊さずに業務を止めるリスク

GhostLock型の攻撃が持つ最大のインパクトは、ファイルを破壊しないにもかかわらず業務停止を引き起こせる点です。たとえば、部門共有フォルダ、経理データ、設計図面、顧客管理ファイル、業務アプリケーションが参照する設定ファイルなどが同時にロックされれば、利用者はファイルを開けなくなります。

この状態では、ファイルそのものは存在しています。暗号化もされていません。拡張子も変わっていません。バックアップから復旧する前に、まず原因の特定が必要になります。現場の利用者から見れば「共有フォルダが開けない」「いつものファイルにアクセスできない」「アプリがエラーを出す」という障害として認識されるでしょう。

さらに問題なのは、ネットワーク共有ファイルに対しても影響が及ぶ可能性があることです。企業ではSMB共有を通じてファイルサーバーを利用するケースが多く、複数の部門や拠点が同じ共有領域に依存しています。攻撃者が共有フォルダ内の多数のファイルを再帰的に開いてロックすれば、特定部署だけでなく広範な業務領域に影響が波及します。

ランサムウェアのように脅迫文が表示されるわけではないため、初動では単なるサーバー障害、アプリケーション不具合、権限設定ミスと誤認される可能性もあります。その間に攻撃者が別の目的を進めていた場合、対応チームは本来見るべき侵入経路や横展開の兆候を見逃すかもしれません。

標準ユーザーでも実行できる点が危険

GhostLock型の手法で特に警戒すべきなのは、高度な管理者権限がなくても実行できる可能性がある点です。標準的なドメインユーザーであっても、自分に読み取り権限やアクセス権がある共有ファイルを開くことは通常許可されています。

つまり、攻撃者が社内端末の一般ユーザーアカウントを侵害した場合、そのアカウントがアクセスできる範囲の共有ファイルに対してロック操作を仕掛けられる可能性があります。これは権限昇格を前提としないため、攻撃開始までのハードルが低くなります。

企業のファイルサーバーでは、利便性を優先して広めのアクセス権が設定されていることも珍しくありません。部門共有、全社共有、一時共有、プロジェクト共有など、複数のユーザーがアクセスできる領域が存在します。こうした環境では、侵害された一つのアカウントが想定以上に広い影響範囲を持つ可能性があります。

もちろん、アクセス権がないファイルまで自由にロックできるわけではありません。しかし、攻撃者にとっては「全ファイルを止める」必要はありません。重要な業務ファイル、頻繁に参照される共有フォルダ、業務アプリケーションが依存する一部のファイルを妨害するだけでも、現場には大きな混乱が生じます。

ランサムウェアとは異なるが軽視できない

GhostLockは、典型的なランサムウェアとは性質が異なります。ファイルを暗号化せず、復号キーを要求するわけでもありません。そのため、直接的な金銭要求を伴う攻撃として見ると、ランサムウェアほど派手ではないかもしれません。

しかし、業務停止という観点では軽視できません。ファイルにアクセスできない状態が続けば、請求処理、受発注管理、顧客対応、製造工程、設計作業、社内承認など、あらゆる業務が滞る可能性があります。特にファイルサーバー依存度の高い組織では、短時間のアクセス障害でも大きな損失につながります。

また、GhostLockのような手法は、単独の攻撃目的だけでなく、陽動として使われる可能性があります。IT部門やセキュリティ担当者が「共有ファイルにアクセスできない」という障害対応に追われている間に、攻撃者が認証情報の窃取、内部探索、データ持ち出し、横展開などを進めるシナリオです。

この場合、GhostLockによるファイルロックは本命ではなく、注意をそらすためのノイズになります。攻撃者にとって、検知されやすい破壊活動よりも、障害に見える妨害行為のほうが都合のよい局面があります。だからこそ、ファイルロックの大量発生を単なる運用トラブルとして処理するのではなく、侵害調査の入口として扱う必要があります。

なぜ従来のセキュリティ製品で検知しにくいのか

GhostLock型の手法が検知しにくい理由は、実行される操作が正規のファイルオープン要求だからです。多くのセキュリティ製品は、悪意ある挙動としてファイルの大量暗号化、大量削除、不審な書き込み、既知マルウェアのシグネチャ、異常なプロセス起動などを監視します。

ところが、GhostLockは必ずしもファイル内容を書き換えません。暗号化もしません。大量のファイルを開き、共有モードを制限した状態で保持することが中心です。これはログ上、単なるファイルアクセスとして見える可能性があります。

さらに、標準的なWindowsイベントログや一般的なEDRのテレメトリでは、ファイルサーバー上のセッション単位でどれだけ多くのファイルが開かれているか、どのクライアントが異常な数のファイルハンドルを保持しているか、といった観点が十分に可視化されない場合があります。

検知の焦点は、マルウェアの有無ではなく、ファイルサーバー層における「開かれているファイル数」「ロック状態」「共有違反の発生頻度」「特定セッションの異常な保持時間」へ移ります。これは従来のエンドポイント中心の監視とは異なる視点です。

観点	従来型ランサムウェア	GhostLock型の妨害手法
主な挙動	ファイル暗号化や拡張子変更	正規APIによる排他的ファイルオープン
ファイル内容	改変されることが多い	改変されない場合が多い
利用者への影響	ファイルが読めなくなる	ファイルを開けなくなる
検知の手がかり	大量書き込み、暗号化処理、不審プロセス	異常なオープンファイル数、共有違反
初動での見え方	サイバー攻撃と認識されやすい	障害や権限問題に見える可能性
対策の重点	バックアップ、EDR、暗号化検知	ファイルサーバー監視、セッション管理、権限最小化

 

SMB共有を利用する企業ほど影響を受けやすい

GhostLockの影響を考えるうえで、SMB共有の存在は重要です。SMBはWindows環境のファイル共有で広く利用されており、企業内のファイルサーバー運用では極めて一般的です。部門別フォルダ、全社共有フォルダ、アプリケーション用共有領域など、多くの業務データがSMB上に置かれています。

攻撃者がSMB共有上のファイルを多数開いてロックすると、サーバー自体が停止していなくても、利用者にとっては障害と同じ状態になります。ファイルサーバーは稼働しており、ネットワークもつながっているのに、特定のファイルだけ開けない、または大量のファイルで共有違反が発生するという現象が起きます。

このような障害は、原因切り分けが難しくなりがちです。ネットワーク障害なのか、権限設定の問題なのか、ファイルサーバーの負荷なのか、クライアント端末側の問題なのか、初動では判断に時間がかかります。その間にも、ロックを保持しているプロセスが動作し続ければ、業務影響は継続します。

特に注意したいのは、共有フォルダの構造が深く、ファイル数が多い環境です。再帰的にファイルを開く処理が実行された場合、短時間で多数のファイルが影響を受けます。古い共有領域や整理されていないファイルサーバーでは、不要なファイルが多く存在し、監視や棚卸しも不十分になりやすいため、異常の発見が遅れる可能性があります。

防御の鍵はファイルサーバー側の可視化

GhostLock型の手法に備えるには、エンドポイントだけでなくファイルサーバー側の可視化が欠かせません。特定ユーザーや特定端末が短時間に大量のファイルを開いていないか、通常より長くファイルハンドルを保持していないか、共有違反が急増していないかを監視する必要があります。

Windows環境では、管理者が開かれているファイルやセッションを確認できる機能があります。こうした情報を定期的に確認し、通常時の状態を把握しておくことで、異常発生時の判断が速くなります。重要なのは、単発のファイルオープンではなく、通常業務から逸脱したパターンを見ることです。

たとえば、一般ユーザーが短時間で数千単位のファイルを開いている、特定のクライアント端末から複数共有に対して不自然なアクセスが続いている、業務時間外に大量のファイルロックが発生している、といった状況は調査対象になります。こうした兆候は、マルウェア検知アラートが出ていなくても見逃すべきではありません。

また、ファイルサーバーのログと認証ログ、EDRのプロセス情報、ネットワーク通信ログを組み合わせることで、ロックを発生させた端末やユーザー、実行プロセスを特定しやすくなります。単一のログだけで判断するのではなく、複数の観点から関連付けることが重要です。

権限設計の見直しが被害範囲を左右する

GhostLock型の妨害は、アクセス可能なファイルに対して実行されるため、権限設計が被害範囲を大きく左右します。全社共有に広範な書き込み権限や読み取り権限が付与されている場合、一つのアカウント侵害が多くのファイルに影響する恐れがあります。

最小権限の原則は、こうした攻撃にも有効です。ユーザーには業務上必要なフォルダだけを許可し、不要な共有領域へのアクセスを制限することで、万一アカウントが悪用されても影響範囲を抑えられます。

特に、長期間使われていない共有フォルダ、退職者や異動者の権限が残っている領域、プロジェクト終了後も開放されたままのフォルダは見直しが必要です。攻撃者は、こうした管理の緩い領域を足がかりにする可能性があります。

権限見直しでは、単にアクセスを削るだけでなく、業務影響とのバランスも重要です。過度に制限すると現場の利便性が下がり、別の回避策や非公式なファイル共有を生む恐れがあります。そのため、重要度の高い共有領域から優先順位を付け、段階的に棚卸しすることが現実的です。

インシデント対応で見るべきポイント

共有ファイルへのアクセス障害が発生した場合、従来の障害対応だけでなく、セキュリティインシデントの可能性も視野に入れるべきです。特に、複数のユーザーから同時に「ファイルが開けない」という報告が上がった場合や、共有違反が広範囲で発生している場合は、単なる偶発的なロックではない可能性があります。

対応の初期段階では、どのファイルがロックされているのか、どのユーザーや端末が開いているのか、どのプロセスが関与しているのかを確認します。ロック元の端末が判明した場合は、ネットワーク隔離やプロセス停止を検討します。ただし、業務アプリケーションが正当にファイルを保持している可能性もあるため、影響範囲を見極めながら判断する必要があります。

同時に、ロック元アカウントの認証履歴も確認すべきです。普段利用しない端末からログインしていないか、業務時間外のアクセスがないか、複数のサーバーへ不自然に接続していないかを調べます。GhostLockのような妨害が陽動である可能性を考えるなら、データ持ち出しや横展開の痕跡も並行して調査する必要があります。

ファイルアクセス障害を復旧するだけで完了とせず、なぜその状態が起きたのか、同じアカウントで他に何が行われたのかを追跡することが、再発防止につながります。

バックアップだけでは解決できない問題

ファイル関連の攻撃対策としてバックアップは不可欠ですが、GhostLock型の手法ではバックアップだけで十分とは言えません。なぜなら、ファイル自体が破壊されていない場合、バックアップから戻すことが根本解決にならないからです。

問題はファイルの内容ではなく、現在のアクセス状態にあります。ロックを保持しているプロセスやセッションを解除しなければ、バックアップを復元しても同じようにアクセス妨害が続く可能性があります。もちろん、攻撃と同時に破壊や改ざんが行われている可能性もあるためバックアップ確認は必要ですが、GhostLock型では復旧の焦点が異なります。

重要なのは、ファイルサーバーのセッション管理、異常なファイルハンドルの特定、侵害端末の隔離、アカウントの無効化や認証情報のリセットです。バックアップは最後の砦であり、最初に見るべきものは「誰が、どこから、何を開き続けているのか」です。

この視点を持たないと、現場では「ファイルが壊れているのではないか」と誤解し、不要な復元作業やサーバー再起動に時間を費やす恐れがあります。結果として、本当の原因である不審なプロセスや侵害アカウントへの対応が遅れてしまいます。

企業が今すぐ確認すべき防御策

GhostLock型のリスクに備えるには、日常運用の中でファイルロックや共有違反を監視できる体制を整えることが重要です。特別な攻撃だけを想定するのではなく、通常業務で起こるファイルアクセスの状態を理解し、そこから逸脱した挙動を見つける仕組みが必要になります。

まず、重要なファイルサーバーについて、通常時のオープンファイル数やセッション数を把握することが出発点です。平常時の基準がなければ、異常値を判断できません。次に、短時間で大量のファイルを開くユーザーや端末を検知できるよう、監視項目を追加します。

加えて、共有フォルダの権限棚卸しも欠かせません。特に、全社共有や部門横断フォルダには注意が必要です。業務上不要なアクセス権を減らすことで、攻撃者が一つのアカウントから及ぼせる影響範囲を狭められます。

EDRやSIEMを導入している組織では、ファイルサーバーの情報を取り込んで相関分析できるか確認するべきです。エンドポイント側で不審な実行ファイルを検知できなくても、サーバー側の異常なファイル保持や共有違反の急増から攻撃を推測できる場合があります。

さらに、インシデント対応手順にも「大量ファイルロック」や「共有違反の急増」を想定した項目を追加しておくと、初動の迷いを減らせます。障害対応チームとセキュリティチームが別組織の場合は、共有ファイル障害がサイバー攻撃の兆候である可能性を連携ルールに含めることが重要です。

GhostLockが突きつけるセキュリティの盲点

GhostLockが示しているのは、悪意ある攻撃が必ずしも派手な破壊や暗号化を伴うとは限らないという現実です。正規のAPI、正規の権限、正規のファイル操作であっても、使い方次第では業務を止める武器になります。

これは防御側にとって大きな盲点です。セキュリティ対策は、不審なファイル、既知のマルウェア、異常な書き込み処理に注目しがちです。しかし、正規操作を組み合わせた妨害では、従来の「悪性か正常か」という単純な分類が通用しにくくなります。

今後の防御では、操作そのものが正規かどうかだけでなく、文脈が通常業務に合っているかを見る必要があります。一般ユーザーが短時間に大量の共有ファイルを排他的に開くことは、業務上自然なのか。特定端末が複数フォルダを一斉にロックすることは通常起こるのか。こうした振る舞いの異常性を捉える視点が求められます。

GhostLockは概念実証として登場したものですが、示された技術的発想は現実の攻撃に応用される可能性があります。ファイルを暗号化しないから安全、破壊しないから深刻ではない、という見方は危険です。業務に必要なファイルへアクセスできない状態そのものが、企業にとっては重大な被害になり得ます。

まとめ：ファイルを守るだけでなく「使える状態」を守る時代へ

GhostLockの登場は、企業のファイルセキュリティに新しい視点を求めています。これまでの対策は、ファイルを盗まれない、壊されない、暗号化されないことに重点が置かれてきました。しかし、今後はファイルが正常に存在していても、必要なときに利用できなければ業務継続は守れないという発想が重要になります。

正規APIを悪用したファイルロックは、派手な攻撃ではありません。それでも、共有ファイルに依存する企業にとっては、短時間で大きな混乱を招く可能性があります。さらに、陽動として使われた場合には、より深刻な侵害活動を覆い隠す役割を果たすかもしれません。

対策の中心は、ファイルサーバー側の可視化、権限の最小化、異常なオープンファイル数の監視、共有違反の急増検知、そして障害対応とセキュリティ対応の連携です。バックアップやEDRだけに頼るのではなく、ファイルが「誰に、どのように、どれだけ保持されているか」を見る運用が求められます。

GhostLockが示した脅威は、Windowsの欠陥というより、正規機能の悪用にどう備えるかという課題です。企業は、ファイルを保存する仕組みだけでなく、ファイルを安定して利用し続けるための監視と制御を見直す時期に来ています。