セキュリティツールは、ある攻撃の既知のバージョンを阻止できても、同じ行動がより分かりにくい方法で実行されると、その行動を通過させる可能性がある。これが、Blue Report 2026に基づく分析の主な結論である。同レポートはPicus Labsが発表したもので、2026年1月から6月に実行された3億3,800万件を超える攻撃シミュレーションを通じ、実際の顧客環境における阻止および検知手段の性能を測定した。
全体的な阻止効果は、前年の62%から69%に上昇し、2024年の水準に戻った。しかし、この数値は防御エコシステム全体の平均を示すものであり、攻撃者が環境に侵入した後、または同じ目的を達成するために使用するツールや方法を変更した際に何を実行できるかを必ずしも示していない。
既知のインジケーターは行動に対する防御と同じではない
この分析は、2種類のテストを区別している。既知のインジケーターによるテスト、すなわちIOCベースのテストは、ファイアウォール、Webエージェント、セキュアメールゲートウェイが既知の悪性サンプルを識別し、そのダウンロード試行を阻止できるかを検証する。この測定は境界防御層には適しているが、別の問いには答えない。つまり、ツールや経路にかかわらず、攻撃者が実行する行為をエコシステムが阻止できるかという問いである。
そこで登場するのが、戦術・技術・手順（TTPs）に基づく行動テストである。このアプローチでは、Mimikatzというツールがシステムに知られているかではなく、端末上のあらゆるプログラムがユーザーの認証情報マテリアルを取得できるかをテストする。この問いは、エンドポイント保護ツールや侵入検知システムにとって重要である。なぜなら、これらの制御が介入段階に到達した時点で、攻撃者はすでに環境内で実行を開始していることが多いからである。
IOCに基づく既知のマルウェアダウンロードの阻止率は、2026年のデータでは50%に低下した。2025年は60%、2024年は71%だった。これは、シグネチャに最も依存する層でさえ安定したカバレッジを実現していないことを示している。また、既知のシグネチャテストで良好な結果が出ても、行動やその実行方法が変化した場合に何が起きるかは明らかにならない。
Mimikatzの例がギャップを明らかにする
顧客環境では、同じ目的、すなわち認証情報の抽出を達成するために、Mimikatzが3つの経路で使用された。LSASSプロセスのメモリからのデータ抽出は94%の試行で阻止された。これは従来型の経路であり、製品が広く監視している。しかし、同じツールを使ってメモリ上の別の場所からRDP認証情報を取得した場合、阻止率は17%に低下し、ローカルシステムレジストリからLSA Secretsを読み取った場合は3%に低下した。
3つのケースはいずれも同じ親技術であるOS Credential Dumping (T1003)に分類され、同じ結果、すなわち攻撃者が機密性の高い認証情報マテリアルを取得する結果に至る。違いは、セキュリティ制御から見た経路の分かりやすさにあった。lsass.exeのメモリを読み取ると、より容易に照合できるイベントが残る一方、SYSTEM権限でレジストリハイブを読み取る行為は、通常の管理活動に近く見える可能性がある。
また、既知のMimikatzの亜種に対する阻止が成功しても、その結果が安定するとは限らない。シグネチャが依存する文字列を変更したり、ツールを再コンパイルしたり、ディスクに残さずメモリにコードをロードしたり、ProcDumpやcomsvcs.dllなどMicrosoftが署名したツールを使用して後からデータを分析したりできる。こうした場合、シグネチャが探す痕跡は変化するが、行動と最終的な目的は変わらない。
環境内部の防御は境界防御より弱い
境界レベルで測定した全体の阻止率は69%だったが、認証済みユーザーとして侵入後に攻撃者が実行できることを測定する侵害後テストでは、阻止されたアクションはわずか37%だった。言い換えれば、防御は境界で攻撃の約3分の2を阻止する状態から、環境内部の行為の3分の1強を阻止する状態へ移行した。
ノイズの大きい行為ほど検知されやすかった。ラテラルムーブメントの検知率は約90%、UACのバイパスは85%を超えた一方、認証情報の再利用とActive Directoryの悪用の阻止率は約63%だった。これに対して、目立ちにくい活動では数値が低下した。メモリやレジストリから受動的に読み取られた認証情報マテリアルに対する防御率は22%にとどまり、ローカルレジストリシークレットの抽出では1%未満だった。また、探索および収集活動は10%を超えず、SharpHoundを使用したドメイン列挙やローカルファイルの収集は、ほとんど妨げられずに実行された。
実際には何が変わるのか
この分析から得られる実務上の結論は、セキュリティ検証プログラムが各テストを、それが何を測定しているかに基づいて解釈する必要があるということだ。単一の結果を、カバレッジ全体を示す証拠として扱うべきではない。既知のサンプルテストは、ファイアウォール、Webエージェント、Webアプリケーションファイアウォール、セキュアメールゲートウェイには引き続き適している。一方、EDR、IDS、SIEMコンテンツを含むエンドポイントおよび検知層では、同じ目的に至るすべての経路をテストする必要がある。LSASSメモリ、レジストリ、代替メモリ領域、ネイティブツール、再コンパイルされたバージョンなどである。
本稿は、著名な手順だけをテストすると、実際には依然として露出している項目を解消したと判断してしまう可能性があると警告している。この分析は、1つのシグネチャが1つのツールを識別したことを証明するだけでなく、同じ行動に対する複数のシミュレーションを使用して既存の制御を検証することを提案している。Picus Swarmは、同社の製品およびサービスの枠組みにおいて、これらのバリエーションを実行し、環境全体でテストするためのオーケストレーション層として挙げられている。
推奨事項は、必ずしも新しいツールを追加することではない。むしろ、攻撃チェーンを実際に断ち切れる既存の制御を特定し、各露出について、修正、緩和、監視、または証拠に基づく受容のいずれかを文書化して決定することである。記事によれば、レポートの結果は、業界および地域間の性能差、最も悪用されている脆弱性、58%のログ記録率、14%のアラート率を含む、より広範な調査の一部でもある。