
2026年、日本のサイバーセキュリティは大きな転換点を迎えました。長年の懸案だった能動的サイバー防御の法整備がついに実現し、国が攻撃者のインフラに先手を打てる体制が整いつつあります。
しかし同じ2026年5月、その制度設計の前提を根本から揺るがす攻撃技法が公表されました。名前はGhostLock。暗号化もしない、通信の痕跡も残さない、それでいて組織の業務を数分で完全停止させるこの技法は、従来のサイバーセキュリティの常識を静かに、しかし確実に書き換えています。
▼ この記事の要約
能動的サイバー防御とは何か、何を想定しているか
2025年5月23日に公布された「サイバー対処能力強化法」と「サイバー対処能力整備法」は、2026年中の施行を目指して整備が進んでいます。この制度が機能するためにはいくつかの前提条件があり、その前提こそがGhostLockとの衝突を生む起点となっています。
制度の核心
能動的サイバー防御の核心は、平時から国が通信情報を監視・分析し、攻撃の予兆を検知した段階で相手方の攻撃サーバーへの侵入・無害化を行う法的権限を持つことにあります。これまでの「攻撃を受けてから対応する」受け身の防御から、「攻撃が来る前に攻撃インフラを叩く」欧米型の考え方への転換です。
制度を支える組織面でも動きがあります。2025年7月1日には内閣サイバーセキュリティセンター(NISC)が発展的に改組され、強力な司令塔機能を持つ国家サイバー統括室(NCO)が新設されました。
制度設計が前提としていること
この制度が機能するためには、次の2つの条件が不可欠です。
これらの前提は、ランサムウェアや標的型攻撃(APT)といった従来型の脅威にはよく当てはまります。問題は、GhostLockがそのいずれの前提も満たさないことです。
GhostLockとは何か——暗号化しないのに業務が止まる
GhostLockは、イスラエル航空産業のオフェンシブセキュリティチームリーダーであるKim Dvash氏が2026年5月に公表した研究ツールです。論文はZenodo(学術論文リポジトリ)に登録されており、PoCコードはGitHubで公開されています。以下では、その仕組みと規模感を具体的に解説します。
攻撃の仕組み——たった1つのAPIコール

GhostLockの仕組みは驚くほどシンプルです。WindowsのAPIであるCreateFileWを、dwShareModeパラメータをゼロ(0x00000000)に設定して呼び出すだけです。
dwShareModeとは、あるプログラムがファイルを開いている間に他のプログラムがそのファイルへどのようにアクセスできるかを指定するパラメータです。これをゼロにすると、Windowsは呼び出し元に排他的なdeny-shareハンドルを付与します。この状態になると、他のすべてのユーザーやアプリケーションはそのファイルを読み取り・書き込み・削除のいずれの目的でも開くことができなくなり、STATUS_SHARING_VIOLATION (0xC0000043)というエラーを受け取り続けます。
重要なのはここです。この動作はMicrosoft OfficeがWordやExcelのファイルを編集用に開くときに使っているものとまったく同じです。Windows NT 3.1以来30年以上変わらない、正式に文書化された仕様通りの動作であり、CVEは存在せず、パッチも存在しません。
スケールと実測値
1ファイルへのAPIコール1回では企業規模のファイル共有は麻痺しません。GhostLockが脅威として成立する理由は、この仕組みを高速でスケールさせる実装にあります。
GhostLockは32スレッドの並列スキャナを採用し、SMBプロトコルのQUERY_DIRECTORYリクエストを並列化することでファイル探索を劇的に高速化しています。実際の検証では次の結果が得られています。
| 項目 | 実測値 |
|---|---|
| 対象ファイル数 | 50万ファイル |
| ディレクトリ探索時間 | 6分22秒 |
| ハンドル取得時間 | 2分37秒 |
| ロック成功率 | 99.6% |
| アクセス遮断率(60秒保持時) | 99.8% |
| 必要権限 | 標準ドメインユーザーのみ |
1つのSMBセッションで同時に保持できる排他ハンドルは最大64,000件です。10セッションを並列で使えば50万ハンドルを超え、企業の大規模NAS全体を麻痺させるのに十分な数に達します。管理者権限も脆弱性の悪用も不要である点が、この技法の最大の特徴です。
なぜ能動的サイバー防御が機能しないのか
GhostLockは、従来型の攻撃が持つ「つかめる痕跡」をほぼすべて排除した設計になっています。これが能動的サイバー防御の対抗手段と噛み合わない根本的な理由です。
C2サーバーが存在しない
能動的サイバー防御の対抗手段の中核は、「攻撃者が利用するサーバーに侵入・無害化する」ことです。しかしGhostLockの攻撃者が必要とするのは、標準ドメインユーザーアカウントとSMB共有へのネットワークアクセスだけです。
外部のC2サーバーは一切不要で、攻撃者はSMBセッションを保持し続けるだけで攻撃を継続できます。「無害化すべきサーバー」が存在しないため、法的権限を行使する対象がそもそもありません。
通信の監視でも予兆をつかめない
国の監視機構が予兆を検知するためには、通信レベルで何らかの異常なシグナルが必要です。しかしGhostLockの通信は、SMB2プロトコルのCREATEとCLOSEリクエストのみです。
これはMicrosoft Wordがネットワーク上のファイルを開閉する際の通信と区別がつきません。ディープパケットインスペクション(DPI)を持つNDRシステムでも、現時点ではGhostLockの通信を通常のファイルアクセスと識別することは不可能です。
企業内の防御層も7種すべてが沈黙する
攻撃が始まっても、国の仕組みだけでなく企業内部の防御層も機能しません。Dvash氏の論文は7種類のセキュリティ制御を評価し、すべてでアラートがゼロだったと報告しています。
以下にその理由をまとめます。
| セキュリティ制御 | 無効になる理由 |
|---|---|
| ハニーポット・カナリアファイル | 書き込みイベントをトリガーにするが、GhostLockは書き込みを一切行わない |
| 書き込みレート異常検知 | 監視対象のメトリクス(書き込み操作)が存在しない |
| 振る舞いAIランサムウェアエンジン | 読み取り・オープンのプロファイルが検索インデクサやバックアップと区別不能 |
| 商用EDRエージェント | Microsoft Wordがドキュメントを開閉する挙動と同一に見える |
| NDR・ディープパケットインスペクション | SMB2のCREATEとCLOSEのみで、正常なファイルアクセスと識別不能 |
| SIEM相関ルール | セッション単位の排他ハンドル累積数を監視する既存ルールが存在しない |
| ファイル拡張子・エントロピー監視 | 拡張子変更なし、エントロピー変化なし |
この表が意味するのは、「GhostLockが実行されても、現時点のほとんどの組織は攻撃が起きていることを知る手段を持っていない」という現実です。
対象となる企業の現実
GhostLockは特定の業種や規模を狙うものではなく、満たすべき条件が2点だけである点が脅威の広さにつながっています。自社がその条件に当てはまるかどうかを確認することが最初のステップです。
2つの条件で成立する
対象環境の条件は次の2点です。
エクスプローラーで\\server\shareの形式のフォルダにアクセスできるなら、その環境は対象です。オンプレミスのファイルサーバを使っている企業も、Azure上でSMBファイル共有を使っている企業も同様に対象となります。Windows 365(クラウドPC)を利用している場合も、そのクラウドPCから社内SMB共有にアクセスできる構成であれば攻撃の起点になりえます。
逆に対象外となるのは、ファイル共有をSharePoint OnlineやOneDrive(HTTPSベース)のみで運用しており、オンプレミスのSMBファイルサーバを完全に廃止済みの環境です。
パッチは永遠に存在しない
通常のサイバー攻撃であれば、ベンダーがパッチをリリースし適用することで根本的な対策が取れます。しかしGhostLockに対して、Microsoftがパッチを出すことは理論上ありません。
理由はシンプルで、仕様通りの動作だからです。これは脆弱性管理の通常サイクル(CVE公表→パッチリリース→適用)が完全に機能しない攻撃クラスであることを意味します。対応の主体は「OSベンダー」ではなく、「各組織のSecOpsとStorageOpsの連携体制」に移っています。
ADクレデンシャルを無効化しても止まらない
攻撃者のアカウントを発見してActive Directoryで無効化しても、既存のSMBセッションとそこで保持されているハンドルは、プラットフォームの設定によってさらに15〜60分継続します。「アカウントを止めれば終わる」という直感的な対処が通用しません。
また、GhostLockは攻撃済みのファイルパスをJSONキャッシュに保存するため、セッションが切断されても再接続すれば数秒で全ファイルのロックを再取得できます。最も素早い管理者対応であるセッション切断を実質的に無力化する設計です。
企業が今できること
パッチが存在しない以上、対応の方向性は検知体制と運用体制の整備に絞られます。優先順位の高いものから順に解説します。
検知:NASの管理層にシグナルを作る
唯一信頼できる検知シグナルは、NAS管理コンソール内の「セッション単位の同時排他ハンドル数」です。正規のアプリケーションが同時に保持する排他ハンドルはせいぜい数十件であり、GhostLockが積み上げる数万〜数十万件とは桁が違います。
具体的には次の2点をSIEMに組み込むことが推奨されます。
まずはNASベンダーのドキュメントを確認し、どのログやAPIでこの数値を取得できるかを確認することが現実的な最初の一手です。
運用:SecOpsとStorageOpsの合同ランブックを作る
Dvash氏の論文が特に強調するのは、インシデント発生時の組織的な回復能力の弱さです。GhostLockを検知してSMBセッションを強制切断するには、ストレージ管理の専門知識が必要です。
多くの企業ではセキュリティ運用チームとストレージ運用チームが独立して動いており、事前に合同ランブックが存在しない場合の平均復旧時間(MTTR)は4〜8時間に達するとされています。事前に整備しておくべき内容は次の通りです。
予防:SMB依存の段階的な解消
SMBファイルサーバを段階的にSharePoint OnlineやOneDrive(HTTPSベース)に移行することが、長期的な解決策の一つです。これらはSMBプロトコルを使用しないため、GhostLockの攻撃対象になりません。短期的には、SMB共有への最小権限化を進め、業務上必要のないユーザーやデバイスからのSMBアクセスを遮断することで被害範囲を限定できます。
まとめ——制度に頼りきらない組織防衛を
能動的サイバー防御は、日本のサイバーセキュリティを大きく前進させる制度です。従来型のランサムウェアや国家支援型APTが利用するC2インフラへの対抗手段として、重要な役割を果たすことになるでしょう。しかし、GhostLockはその制度設計の「想定の外」にある攻撃クラスを可視化しました。
C2サーバーを持たない、通信の異常を生まない、ディスクに何も書かない——これらの特性を持つ攻撃に対して、国の監視機構も企業の既存防御層も、現時点では有効なシグナルをほぼ持っていません。エネルギー・物流・金融・医療といった重要インフラを支えるファイル共有インフラが、標準ドメインユーザー権限のみで数分間停止しうる時代に入っています。
制度整備と並行して、自組織のNASテレメトリの整備、SecOpsとStorageOpsの連携体制の確立、そしてSMB依存の段階的な解消——これらを地道に進めることが、今この時点で企業が取れる現実的な防衛策です。能動的サイバー防御が守ってくれる部分と、自分たちで守らなければならない部分を正確に見極めることが、2026年以降のセキュリティ担当者に求められる視点です。
参考情報
- Kim Dvash, “GhostLock: SMB Deny-Share Handles as a Zero-Privilege Availability Weapon”, Zenodo, 2026年5月(DOI: 10.5281/zenodo.20070064)
- GitHub: kimd155/GhostLock(https://github.com/kimd155/ghostlock)
- Cyber Security News, “GhostLock Tool Leverages Windows API to Lock File Access Like Ransomware”, 2026年5月11日
- Andrea Fortuna, “GhostLock: when ransomware impact requires no ransomware”, 2026年5月10日
- サイバー対処能力強化法・サイバー対処能力整備法(2025年5月23日公布)




コメント