Outlookのエラーが実は攻撃成功のサイン【CVE-2024-21413】

Moniker Link脆弱性（CVE-2024-21413）を手元で検証すると、「ファイルが見つかりません」というエラーが出ているのに、なぜか攻撃は成功している、という不思議な場面に出くわします。
この記事では、その現象がなぜ起きるのかを入り口に、攻撃者が手に入れる「NTLMv2ハッシュ」とは一体何者で、なぜそれが危険なのかを、守る側の視点で解きほぐしていきます。

はじめに：Moniker Link（CVE-2024-21413）とは

Moniker Link（CVE-2024-21413）は、2024年2月にMicrosoftが修正したOutlookの脆弱性です。攻撃者が細工したリンクをメールで送り、受信者がそれをクリックすると、Outlookの安全機能をすり抜けて、受信者のWindows認証情報（NTLMハッシュ）を外部へ送らせることができるというものです。

深刻度はCVSSスコア9.8のCritical（最高ランクに近い深刻度）と評価されており、SentinelOneの脆弱性データベースによれば、実際に悪用が確認された脆弱性としてCISA（米国のサイバーセキュリティ・インフラセキュリティ庁）の「Known Exploited Vulnerabilities（KEV）カタログ」にも登録されています。攻撃者にとっては「メールを1通送り、リンクを1回クリックさせる」だけで成立しうる、実害の大きい脆弱性です。

以下では、この脆弱性を手元の検証環境で試したときに出会った「エラーが出たのに攻撃が成功していた」という現象を入り口に、その裏で何が起きているのかを一つずつ見ていきます。

エラーが出たのに、実は成功していた

CVE-2024-21413を手元の検証環境で試していたときのことです。攻撃対象のWindows上でOutlookのリンクをクリックしたところ、こんなダイアログが出ました。

Microsoft Outlook
We can't find '\\<攻撃者IP>\test!exploit'.
Please make sure you're using the correct location or web address.

「ファイルが見つかりません」。普通に読めば失敗です。ところが攻撃者側で待ち受けていたツールを見ると、対象マシンから認証情報がしっかり飛んできていました。「見つからない」というエラーが出ているのに、攻撃としては成立している。 この一見矛盾した状況が、この脆弱性を理解する一番の入り口でした。

なぜこうなるのか。それを理解するには、Outlookが本来やるはずだった「安全策」と、それがどう回避されるかを知る必要があります。

Outlookの安全策「保護ビュー」と、それを回避する仕組み

Outlookは、外部から来た怪しいファイルやリンクを、いきなり開かず「保護ビュー（Protected View）」という読み取り専用の隔離環境で開くようになっています。file:// のような、ローカル／ネットワークのファイルを指すリンクは、本来この安全策の対象です。

CVE-2024-21413のポイントは、リンクの中に特定の文字（!）と適当な文字列を足すと、この保護ビューの判定をすり抜けてしまうことにあります。SentinelOneの脆弱性データベースによれば、この不具合の根本原因は、Outlookが file:// を含む細工されたハイパーリンクを解析する際の「入力値の検証不備（CWE-20）」だと分類されています。つまりOutlook側が、本来なら弾くべき形式のリンクを「これは安全だ」と誤って通してしまう、というのが本質です。

その結果、Outlookは保護ビューを経由せずに、リンクが指す先へ直接アクセスしにいきます。ここで指定されているのが \\攻撃者IP\test のような UNCパス（Windowsのファイル共有を表すパス） です。

この「クリックから認証情報の流出まで」の一連の流れを、先に図で示します。

flowchart TD
    A("① 細工リンクをクリック<br/>（file:// に ! を含む）") --> B("② 保護ビューを回避<br/>（! で安全と誤判定）")
    B --> C("③ SMBで攻撃者へ接続を試みる")
    C --> D("④ 接続の過程で自動的にNTLM認証")
    D --> E("⑤ Net-NTLMv2ハッシュを攻撃者が捕捉")
    C --> F("「見つからない」エラー表示<br/>（共有は実在しない）")
    F -.->|"エラーは失敗ではなく<br/>接続を試みた証拠"| D
    classDef step fill:#6474ef,stroke-width:0px,color:#ffffff;
    classDef goal fill:#1f7a8c,stroke-width:0px,color:#ffffff;
    classDef err fill:#fdecec,stroke:#c1121f,stroke-width:2px,color:#c1121f;
    class A,B,C,D step;
    class E goal;
    class F err;

「見つからないエラー」の正体

上の図で③から枝分かれしている「エラー表示」が、冒頭のエラーの正体です。

Outlookが \\攻撃者IP\test にアクセスしにいくと、Windowsはこれを「ネットワーク上のファイル共有へのアクセス」と解釈し、SMBプロトコル（TCP 445番）で攻撃者のマシンに接続を試みます。 攻撃者側には実際には共有フォルダなど存在しないので、最終的に「そんな場所は見つからない」というエラーになる ―― これが画面に出たダイアログの正体です。

つまりあのエラーは、「Outlookが言われるがまま、攻撃者の指定した共有へ接続を試みた」ことの証拠です。保護ビューが正しく効いていれば、そもそもここまで到達しません。エラーが出るのは「共有が実在しなかった」からであって、「攻撃が防がれた」からではない。攻撃の目的は、ファイルを開かせることではなく、この接続そのものを発生させることだったわけです。

なぜ接続を発生させたいのか。それが次の話です。

本当の狙い：認証情報（NTLMv2ハッシュ）の窃取

Windowsには、SMBでファイル共有に接続する際、自動でその場のユーザーの認証情報を使って認証を試みるという性質があります。ここが攻撃の核心です。

複数の解説（Medium上の技術記事や、SonicWallの脅威分析など）が一致して指摘しているのは、共有フォルダが実在しなくても、接続の過程で認証だけは試みられるという点です。だから攻撃者は、存在しない共有を指すリンクを送りつけるだけで、被害者のWindowsに「認証情報を送らせる」ことができます。

このとき飛んでくるのが Net-NTLMv2ハッシュです。攻撃者はこれを、共有サーバのふりをして待ち受けるツールで捕まえます。捕まえた行は、だいたい以下の形をしています。

ユーザ名::ドメイン名:サーバチャレンジ:NTProofString:blob(タイムスタンプ等)

長い16進数の羅列が続くので圧倒されますが、この1行まるごとで1個のハッシュです。途中で切って一部だけコピーすると壊れるので、行全体を1セットとして扱います。

盗まれた「ハッシュ」の正体

「NTLMハッシュを盗まれた」と聞くと、「パスワードが漏れた」と思いがちですが、ここには重要な区別があります。この捕まえたNet-NTLMv2ハッシュには、平文パスワードは入っていません。 それどころか、Windows内部に保存されている「NTハッシュ」そのものとも別物です。

なぜそうなるのか。NTLMv2は「チャレンジ&レスポンス方式」の認証プロトコルだからです。仕組みを噛み砕くと、

1. サーバ（今回は攻撃者）が「チャレンジ」と呼ばれるランダムな値を出す
2. クライアント（被害者）は、自分のパスワードを鍵にしてそのチャレンジを計算処理し、結果を返す
3. サーバは、正しいパスワードを知っていれば同じ計算ができるので、一致すれば認証成功とみなす

Praetorianやcsandker.ioなどの解説によれば、ネットワーク上を流れるのは「パスワードそのもの」でも「パスワードのハッシュそのもの」でもなく、**「パスワードを鍵にした計算結果（＋そこに使われたチャレンジやタイムスタンプ）」**です。だから通信を盗聴しても、そこからパスワードやNTハッシュを直接取り出すことはできません。

ではなぜ危険なのか。この計算結果は、オフラインで総当たり／辞書攻撃にかけられるからです。攻撃者は手元で「パスワード候補 → 同じ計算 → 捕まえた結果と一致するか」を延々と試せます。当たれば、被害者の平文パスワードが判明します。

この「別物である」という区別は、防御を考えるうえで実務的にも効いてきます。混同しやすい2つのハッシュを、下の表で整理します。

表1：「NTハッシュ」と「Net-NTLMv2ハッシュ」は別物

同じ「パスワード由来」でも、成り立ちも入手経路も使い道もまったく別、というのが要点です。System Weakness誌の解説も、この取り違えが「初学者がほぼ全員つまずく」ポイントだと明言しています。

守る側は、この一連の流れのどこを見るべきか

ここまでの流れを守る側から逆算すると、検知・対策のポイントが見えてきます。

「Outlookのリンクを1回クリックしただけ」で、内部から外部（あるいは攻撃者）へ向けてSMB認証が発生し、認証情報が流出する ―― これが起きうる、という点がまず怖いところです。攻撃者は特別なマルウェアを送り込む必要すらありません。

対策は「1つの決め手」ではなく、攻撃のどの段階を止めるかで役割が分かれます。下の表に整理します。

表2：対策と、それが効く段階

「怪しいメールを開かない」という運用面の話に閉じず、ネットワーク境界の制御（外向きSMBを止める）で被害を止められるというのは、ネットワークやセキュリティを担当する立場の方は覚えておいてもいいのかなと思います。

実際、SentinelOneの脆弱性データベースも、パッチ適用と並んで「境界での外向きSMB／WebDAV遮断」「SMB署名の強制」を推奨として挙げています。

まとめ

• Moniker Link（CVE-2024-21413）は、Outlookに細工リンクを送り、1クリックでWindows認証情報を外部へ送らせる深刻な脆弱性（CVSS 9.8、CISA KEV登録）。
• Outlookの保護ビューは、リンクに ! を含める細工で回避される（入力値検証の不備が原因）。
• 「ファイルが見つからない」エラーは失敗ではなく、Outlookが攻撃者の指定した共有へSMB接続を試みた「成功の証拠」。
• 攻撃者が捕まえるNet-NTLMv2ハッシュには平文パスワードは含まれない。それはチャレンジ&レスポンスの計算結果であり、オフラインクラックかリレーを経て初めて悪用される。
• 守る側は、パッチ適用に加えて「外向きSMBの遮断」でこの流れを断ち切れる。

分からなかった点・確認しきれていない点

• この脆弱性は「NTLM認証情報の窃取」だけでなく「リモートコード実行（RCE）」にも分類されています（Moniker LinkがWindowsのCOMを利用するため）。ただし、あるMedium記事は「RCEを実証する公開PoCは存在しない」と述べており、認証情報窃取の先にあるRCEの具体的な条件までは、今回確認しきれていません。
• リレー攻撃（クラックせずに認証を別サーバへ中継する手法）は「SMB署名が有効だと弾かれる」といった前提条件があるとされますが、その成立条件の細部は追いきれませんでした。

参考にしたサイト

• SentinelOne — CVE-2024-21413 脆弱性データベース
  深刻度・CISA KEV登録・CWE-20分類・緩和策
• SonicWall — Microsoft Outlook Remote Code Execution Vulnerability
  脆弱性の挙動とSMB経由のNTLM認証について
• Praetorian — NTLMv1 vs NTLMv2
  Net-NTLMv2ハッシュの構造
• csandker.io — NTLM Authentication: A Wrap Up
  通信上を流れるのは計算結果であり、パスワードやNTハッシュそのものではないこと
• System Weakness — NTLM Authentication Explained
  NTハッシュとNet-NTLMv2の違い
• Understanding the Microsoft Outlook Vulnerability: CVE-2024-21413 (Medium)
  RCEを実証する公開PoCは存在しないという指摘

海洋

NWエンジニア

XContact

ネットワーク・セキュリティを中心に、業務や検証環境で実際に触れた内容を記録しています。
現職ではネットワークの運用・構築を担当。

保有資格
ネットワーク：ネットワークスペシャリスト / CCNA
セキュリティ：情報セキュリティマネジメント / ISC2 CC
クラウド　　：AZ-104 / AZ-305
その他　　　：応用情報技術者 / LinuC レベル1

記事の内容に誤りなど見つけられた際は、ご指摘いただけると助かります。