既知の攻撃はブロックできても、その「振る舞い」は止められるか

執筆: Sila Ozeren Hacioglu氏(Picus Security、セキュリティリサーチエンジニア)

防御スコアが示すのは、あるコントロールが「何を認識できるか」に過ぎません。そのコントロールが「実際に何を阻止できるか」までは教えてくれないのです。

4年目を迎えたPicus LabsのBlue Report 2026は、2026年1月から6月にかけて実際の顧客環境で実行された3億3,800万件を超える攻撃シミュレーションをもとに、企業の防御・検知機能が実運用でどれだけ機能しているかを測定したレポートです。

見出しとなる数字は、留保付きながらも確かな回復を示しています。防御効果は62%から69%へと上昇し、2024年のピーク水準に戻りました。

しかし、この数字はスタック全体の平均値にすぎず、その内側にある脆弱な実態を覆い隠しています。

よく知られた攻撃ツールをブロックできるはずの同じコントロールが、同一の手法をわずかに変えただけの「静かなバージョン」には易々とすり抜けられてしまいます。結果を左右するのは導入している製品そのものではなく、攻撃者の手法がどれだけ「見覚えのあるもの」であるか、そしてその静かな変種を誰かがテストしていたかどうかなのです。

IOCベースのテストとTTPベースのテストは、それぞれ異なるものを測定する

ある防御が実際に機能するかどうかは、2つの問いのうちどちらを投げかけるかによって変わってきます。

IOCベースのテストが問うのは、コントロールが「既知の脅威」を認識できるかどうかです。実際に出回っているマルウェアサンプルをダウンロード試行の形で送り込み、ファイアウォール、Webプロキシ、セキュアメールゲートウェイといった境界防御がそれをブロックするかどうかを確認します。

この層に関してはこれが適切な測定方法です。既知の悪性コンテンツを境界で止めることこそ、これらのコントロールの本来の役割だからです。

一方、振る舞い(TTP)ベースのテストが問うのは、経路を問わずその「行動」自体を阻止できるかどうかです。「Mimikatzを検知できるか」ではなく、「このホスト上のプロセスが、そもそも認証情報を取得できてしまうかどうか」を問うのです。

これはエンドポイントおよび侵入検知系のコントロールが答えなければならない問いです。なぜなら、これらのコントロールが関与する頃には、攻撃者はほぼ確実にすでに実行段階に入っているからです。

攻撃の痕跡(アーティファクト)は容易に変えられますが、振る舞いはそう簡単には変わりません。

Image

もちろん、両方が必要です。そして「片方だけで十分だ」と主張する財務部門の意見には、異議を唱えるべきでしょう。

この非対称性は構造的なものであり、意図されたものでもあります。

残念ながら、境界防御そのものにも綻びが生じています。

Image

今年のデータでは、マルウェアダウンロードに対するIOCベースの防御率は顧客環境全体で50%まで低下しました。前年は60%、2024年は71%でした

シグネチャによるカバー率が最も高いはずのこの層でさえ、後退が見られます。そして、この層でのスコアが良好であっても、その裏にある「振る舞い」については何も語ってくれません。ここで登場するのがMimikatzの結果です。あらかじめお伝えしておくと、決して良い結果ではありません。

Mimikatzの認証情報窃取手法を変えただけで、防御率は94%から3%へ急落

Picus Autonomous Penetration Testingを用いて、顧客環境では同じツール「Mimikatz」を使い、同一の目的を3通りの方法で試行しました。その防御スコアは衝撃的なほどにばらつき、これ以上ないほどかけ離れた結果となりました。

  • LSASSプロセスメモリから認証情報をダンプする、古典的でシグネチャによる検知が手厚い経路は、94%の試行でブロックされました。良好な結果です。

  • 同じツールで別のメモリ領域からRDP認証情報を抜き取る手法は17%。芳しくありません。

  • ローカルレジストリからLSA Secretsを読み取る手法はわずか3%。目を疑うほどの結果です。

この3つはいずれも、「OS Credential Dumping(T1003)」という同一の親テクニックに属する兄弟であり、どの経路をたどっても最終的には攻撃者が貴重な認証情報を手中に収めることになります。

唯一の変数は、その経路がどれだけ「目立つ」ものであったかという点でした。今回のケースでは、スポック氏の有名な台詞「長寿と繁栄を」ならぬ「静かに忍び込んで成功を収める」が現実のものとなっています。

Mimikatz-prevention score

この差が生じる理由は、その仕組みを見れば明らかです。

LSASS経由の手法は、識別可能な形で「目立つ」ものです。プロセスがlsass.exeのハンドルを開いてそのメモリを読み取るという動作は、長年にわたりベンダー各社が検知の仕組みを整備してきたイベントだからです。一方、LSA Secretsの読み取りはlsassには一切触れず、SYSTEM権限でレジストリハイブを読むだけで、通常の特権操作と見分けがつきません。最初のイベントを前提に構築されたコントロールには、2つ目のイベントに反応する術がないのです。

しかも、その94%という数字自体も、見た目ほど堅牢なものではありません。この数値は、あるオープンソースツールの既知の1つのビルドに対して測定されたものであり、その「認識されやすさ」はツールが何を行うかではなく、どのようにコンパイルされたかに由来しているにすぎません。

  • シグネチャが手がかりとする文字列をリネームしたり、再コンパイルしたりするだけで、ハッシュ値や特徴的な痕跡は新しいものに変わってしまいます。

  • リフレクティブローディングを用いれば、コードはディスク上に一切現れず、検知される機会もありません。

  • あるいは、そもそもそのビルドを使わずとも、ProcDumpやcomsvcs.dllといったMicrosoft署名済みの正規ユーティリティで同じダンプを取得し、オフラインで解析することもできます。

いずれの経路をたどっても、最終的な結果は同じです。攻撃者は認証情報を手にします。振る舞いそのものは変わらず、シグネチャが探していたものだけが変化しているのです。

環境内部に侵入されると、防御率は37%まで低下

Mimikatzは一つの振る舞いにすぎませんが、同じ構図は内部全体にわたって繰り返されています。全体の防御率69%は、境界においてコントロールがどれだけ攻撃を阻止できているかを測定したものです。一方、自律型ペネトレーションテストが測定するのは、もっと厳しい現実です。すなわち、攻撃者が「認証済みユーザー」として内部に侵入した後、実際に何を達成できてしまうかということです。こうした侵害後の一連の行動全体を通じて、ブロックできたのはわずか37%にとどまりました。

境界では3回の攻撃のうち2回を阻止できますが、内部に侵入されると、それが3回に1回程度にまで落ち込んでしまうのです。

Autonomous pentesting actions

「目立つ」行動はきちんと検知されていました。横展開(ラテラルムーブメント)は約90%の確率で検知され、UACバイパスは約85%、認証情報の再利用やActive Directoryの悪用は約63%となっています。

しかし、その後、数字は一気に底が抜けてしまいます。

メモリやレジストリから受動的に読み取られる認証情報は22%、ローカルレジストリからのシークレット抽出に至ってはブロック率1%未満でした。偵察・情報収集についても10%にとどまり、SharpHoundによるドメイン列挙やローカルファイル収集は、ほぼ完全に無防備な状態で実行されてしまっています。

この22%という数字は、レジストリ経由という変種が大規模に通用してしまっていることを示しており、10%という数字も同様の構図です。手がかりとなる検知シグナルが何もない以上、攻撃者は目的達成に向けて完全に、そして何の妨げもなく突き進んでしまうのです。

ギャップを埋めるために

両方のテストを実施し、それぞれが何を測定しているのかを正しく理解することが重要です。

既知の脅威に基づくテストは、境界防御の基準となるものです。ファイアウォール、Webプロキシ、WAF、セキュアメールゲートウェイなどがこれに当たります。既知の悪性サンプルをダウンロード試行として送り込み、境界でブロックできるかを確認するもので、境界防御が機能しているかどうかは分かりますが、その裏にある振る舞いや、内部に侵入された後に何が起こるかについては何も教えてくれません。

もう一方の要素である振る舞い検証は、エンドポイントおよび検知層が担うべき領域です。EDR、IDS、SIEMのコンテンツなどがこれに該当します。認証情報アクセスへの対策が万全であることを証明するには、LSASSメモリ、レジストリ、代替のメモリ領域、正規ツール、再コンパイルされたビルドなど、あらゆる経路をテストする必要があります。

有名な手順だけを検証して済ませてしまうと、本来はまだ「未対応」のはずの項目を「対応済み」として片付けてしまうことになりかねません。これは、検証プログラムが下し得る中で最も危険な誤った判定です。

これを手作業で行うのはスケールしません。そこで役立つのがPicus Swarmです。これは、一つの攻撃が持つ数多くの振る舞いバリエーションを環境全体にわたって実行するオーケストレーション層であり、それぞれを導入済みのコントロールに対して検証します。これにより、カバレッジはシグネチャがすでに認識している一つの手順ではなく、実際の振る舞いによって証明されることになります。

いよいよ、良い知らせをお伝えしましょう。これは決して、より大規模なセキュリティスタックを求めるものではありません。必要なのは、すでに保有しているどのコントロールが攻撃の連鎖を断ち切れるのかを正確に把握することです。そうすれば、あらゆるエクスポージャーについて「パッチ適用」「緩和策」「監視」「証拠に基づく容認」のいずれかを、根拠を持って選択できるようになります。

The recovery missed the interior

レポート全文を読む

ここで紹介した内容は、Picus Labsによる4回目の年次調査The Blue Report 2026のほんの一部にすぎません。このレポートは、実験室ではなく実運用の現場で、企業の防御・検知機能がどれだけ機能しているかを明らかにするものです。
本編には、さらに多くの内容が収録されています。

  • あなたの業界・地域が今年実際にどのようなスコアを記録したか。

  • 今年最も悪用された脆弱性(多くは試行の25%未満しか阻止できていません)。

  • 防御力が最も後退した脅威グループとランサムウェア

  • ログスコア58%、アラート率14%という数字の背後にある検知の失敗

Blue Report 2026をダウンロードして、自社の業界がどのようなスコアだったのか、そしてまず何に取り組むべきかを確認しましょう。

翻訳元: https://www.bleepingcomputer.com/news/security/your-controls-block-known-attacks-what-about-the-behavior/

本記事は bleepingcomputer.com の記事を翻訳・要約したものです。