Microsoft 365「Direct Send」の評価抜け穴──空のエンベロープ送信者で内部なりすましが成立します

今日の深掘りポイント

• これは「ゼロデイ脆弱性」ではなく、メール受信・認証評価・スパム分類・メールボックス配置という別々の制御が生む“縫い目”を突く手口です。特にDirect Sendの評価における空のエンベロープ送信者（MAIL FROM: <>）の扱いが盲点になっています。
• 送信者認証の外側にある「例外（許可リストや社内扱いの緩和）」が、なりすましを“社内らしく見せる”最後の一押しになります。運用で積み上げた例外が攻撃面を拡げがちです。
• スピアフィッシングの初期侵入としては古典的でも、内部ドメイン偽装は承認フロー・購買・資金移動に直結するB2B/BECリスクを押し上げます。国家支援型の標的型メールにも十分に使われ得ます。
• 実装のキモは「空のエンベロープ送信者」「P1/P2アドレスの乖離」「Direct Send評価の境界」の三点にあります。検出は、空エンベロープ×内部ドメイン×未認証（Anonymous）×高SCLの併合条件での相関が効きます。
• 対抗策は“ひとつのノブ”では足りません。RejectDirectSendの有効化に加え、メールフロー規則での空エンベロープ＋内部ドメインの強制隔離、アンチ・インパーソネーションの徹底、DMARC厳格化、そして「例外の棚卸し」がセットで効きます。

はじめに

Microsoft 365のDirect Sendは、プリンターやスキャナーなどの機器が同一テナント宛に認証なしでメールを送れるように設計された仕組みです。便利さと引き換えに、評価ロジックの外縁にあるデータ点（SMTPのP1、すなわちエンベロープ情報）の扱いが難所になります。今回指摘されたのは、エンベロープ送信者（P1）が空の状態、すなわちMAIL FROM: <>のときに、Direct Send拒否の評価（RejectDirectSend）をすり抜け、内部ユーザーを名乗ったメッセージが成立する可能性があるという点です。

ここで重要なのは、Microsoft 365や特定ベンダの「バグ」ではないことです。メールというプロトコルの仕様的許容（空のエンベロープは本来NDRなどで正当）と、クラウドメール基盤の運用選択（Direct Send・例外・偽装対策の優先度）が交差した結果、攻撃者にとって再現性のある“通り道”が生まれていることにあります。つまり、直せば終わりの単発課題ではなく、設計・運用の積み重ねとして向き合うべきテーマです。

深掘り詳細

事実関係（レポートから読み取れること）

• 攻撃者はSMTPのP1フィールド（エンベロープ送信者）を空にする（MAIL FROM: <>）ことで、Exchange OnlineのRejectDirectSend評価を回避できるケースがあると報告されています。内部のように見えるFrom（P2ヘッダー）を使うことで、社内ユーザー名義のスピアフィッシングが成立し得ます。
• 検証では、空のエンベロープ送信者を用いたメッセージが受け入れられ、スパム信頼度（SCL）が最大値の9として評価される挙動が確認されています。SCL 9は通常Junk送りですが、許可リストや“社内扱い”の例外が存在すると、意図せず収容や振り分けが緩むことがあります。
• これはMicrosoftや特定ベンダ製品の脆弱性ではなく、Direct Sendトラフィックの評価設計に内在する制約が露呈した形です。メールの受信可否、送信者認証（SPF/DKIM/DMARCや内部認証）、スパム/フィッシング分類、最終配置（Inbox/Quarantine/Junk）は別レイヤの判断であり、その境界に緩和や例外が挟まりやすい現実があります。

※ 上記は提供レポートの内容に基づく要約であり、運用設定やテナント条件によって再現性は変動し得ますと注記しておきます。

インサイト（編集部の視点）

• P1（エンベロープ）とP2（ヘッダーFrom）の分離が“身元の二重性”を生みます。DMARCはP2.Fromのドメインに対するSPF/DKIM整合で評価しますが、P1が空のときは評価系が分岐し、運用上の例外（社内ドメインは緩く見る、特定送信元は許す）が重なると、内部なりすましが生き残る余地が出ます。攻撃者はここに着目しているはずです。
• 直接の受信拒否に頼るだけでは不十分です。評価が通ってしまった後の経路（アンチ・インパーソネーション、ユーザー/ドメイン偽装保護、Display Name保護、Externalタグ付与、モバイルクライアントでの可視性確保）を積み上げることで、Inbox到達とユーザー騙しを同時に難しくすることができます。
• メトリクス上の“即応性・実行可能性が高い一方で、中位の新規性”というシグナルは、既存のBECやスピアフィッシングの延長線上で、すぐに手口へ実装され得ることを意味します。重要なのは、単独のスイッチではなく、相関・段階的防御の設計見直しにリソースを割けるかどうかです。

技術補遺（なぜ空エンベロープが効くのか）

• 空のエンベロープ送信者は、RFC上正当（NDR/DSN用途）で、受信側はスパム判定やバックサッター回避のため特別扱いすることがあります。Direct Sendのように匿名送信を前提とする導線では、ここが評価のブラインドスポットになりがちです。
• 受信、認証、スパム分類、配置の各段が独立しているため、どこかで“社内らしく見える”（P2.Fromが自社ドメイン）ד未認証（Anonymous）”ד空エンベロープ”という変則的な組み合わせが生き延びる可能性があります。検出は複数条件の相関でのアラート設計が要になります。

脅威シナリオと影響

• シナリオ1（経営層なりすまし→資金移動/BEC）

  • 手口: 空エンベロープ＋内部ドメインのFromでCFO名義メールを送信し、至急送金やギフトカード購入を依頼します。返信先は外部の攻撃者メールに設定します。
  • 影響: 高額送金、サプライヤー支払いの乗っ取り、決裁フロー攪乱です。
  • MITRE ATT&CK: T1566.002（Spearphishing Link）/T1566.001（Spearphishing Attachment、場合により）、T1036（Masquerading）、T1598（Phishing for Information、事前調査）。

• シナリオ2（ID窃取→クラウド侵入）

  • 手口: 内部総務やITヘルプデスクを装い、MFA再登録やパスワード失効の偽通知を送付、偽IdP/SharePointで資格情報を収集します。
  • 影響: Microsoft 365やその他SaaSへの不正ログイン、横展開、メール転送ルール悪用による継続的窃取です。
  • MITRE ATT&CK: T1566.002、T1078（Valid Accounts）、T1114（Email Collection）、T1059（Command and Scripting Interpreter、後段オートメーションがある場合）。

• シナリオ3（サプライチェーン偽装→請求書差し替え）

  • 手口: 内部の購買・経理担当を装い、取引先とのスレッドハイジャック風のメールで請求書差替えリンクを送付します。
  • 影響: 取引先への金銭的被害、自社と相手先双方の信頼毀損、インシデント対応コスト増です。
  • MITRE ATT&CK: T1566.003（Spearphishing via Service、既存スレッドやサービス経由の演出）、T1036（Masquerading）、T1585（Establish Accounts、必要に応じて外部送信基盤準備）。

地政学リスクの観点では、公的機関・重要インフラ・防衛関連に対する標的型フィッシングで、内部起点の信頼を装うことは古典ながら決定力があり、作戦初動の成功率を底上げします。セキュリティ境界というより「信頼の作法」を突かれるため、訓練と運用例外の排除が被害期待値を大きく下げます。

セキュリティ担当者のアクション

• 方針レベル（今すぐ決める）

  • Direct Sendの利用要否を再評価し、やむを得ず使う場合でも「明示的に承認した最小限インフラ」に限定します。できればSMTP AUTH（Modern Auth）やコネクタ＋証明書/MTA-STSなど、認証・暗号化前提の経路へ移行します。
  • “社内なら緩く”という例外思想を是正します。内部ドメインを名乗る未認証メールは、原則として拒否/隔離し、必要な例外は都度審査・期限付きで付与します。

• メールフロー（Exchange Online）での実装例（推奨）

  • 条件の組み合わせで隔離/拒否/件名タグ付けを実装します（検証→段階導入が前提です）。
    • 送信元が「組織外」かつ 5322.Fromが「自社の受信許可ドメイン」かつ 認証状態が「Anonymous」かつ エンベロープ送信者が「空（MAIL FROM: <>）」→ 拒否または隔離。
    • 上記に加えて「SPF=fail/none」「DKIM=fail/none」「DMARC=fail/none」「SCL>=5」をシグナルとして相関し、アラート・隔離の強度を調整。
  • 既存の「Bypass spam filtering」「優先配信」規則や安全な送信者/ドメインの例外を棚卸しし、内部ドメインを名乗る匿名メールを通す抜け道を廃止します。

• 偽装防御・ブランド保護

  • Defender for Office 365のユーザー/ドメイン偽装（アンチ・インパーソネーション）保護を強化し、経営層・金流関連担当者・高リスク部門を重点対象に設定します。Display Name保護や似名検知（lookalike）も併用します。
  • DMARCはp=rejectの導入を最終目標に、ruf/ruaレポートで可視化しながら段階的に強めます。空エンベロープ時の評価分岐を踏まえ、ヘッダーFromと認証結果の整合が取れないメールの扱いを厳格化します。

• 可視化・検出エンジニアリング

  • テレメトリ相関の観点で「空エンベロープ」×「ヘッダーFrom=自社ドメイン」×「認証=Anonymous」×「SCL高」×「外部タグ欠落（社内扱い）」をハント条件に加えます。メッセージトレースやAdvanced Hunting（EmailEvents/EmailPostDeliveryEvents）で、配送後操作（移動/削除）と合わせて検出します。
  • “Inbox直行はしていないが隔離から解放された”という事後回避を可視化し、承認フローやデリゲート運用が解除ボタンになっていないか点検します。

• UXと教育

  • 外部タグの付与は“内部ドメインの未認証メールにも付ける”運用へ拡張し、モバイル/プレビューでも視認できるよう工夫します。
  • 経営層・経理・購買・ヘルプデスクを対象に、“内部名義でもリンク/返信先/差出人詳細を検証する”訓練を半年スパンで継続します。

• ガバナンスと監査

  • Direct Sendを許容する機器・アプリの台帳化（用途・送信先範囲・代替手段の検討状況・失効日）を行い、棚卸しを四半期ごとに実施します。
  • メールフロー規則・スパム/フィッシングポリシー・偽装保護の差分を変更管理下に置き、例外付与はワークフロー化して自動失効を標準にします。

なお、本件は“コントロールの縫い目”の問題であり、単一ベンダに閉じた話ではありません。だからこそ、評価点の相関・例外の最小化・段階防御という3点セットを、今年度の運用改善テーマとして腰を据えて取り組む価値があると考えます。

参考情報

• Microsoft 365 Direct Sendの評価限界を突く手口（GBHackers報道）