注目

脅威動向 / THREATS / EMAIL SECURITY

Microsoft 365の「RejectDirectSend」を空のエンベロープ送信者で迂回 — ReliaQuestが検証、なりすまし対策の隙を報告

ReliaQuest Threat Researchは、Microsoft 365のExchange Onlineにある制御「RejectDirectSend」が、SMTPのエンベロープ送信者(Envelope From)を空にすることで迂回され、内部を装うフィッシングが受信者に届く恐れがあると報告した。同社の検証では、同一のFromヘッダーでもエンベロープを空にした1通だけがMicrosoft 365に受け入れられた。IP制限付きインバウンドコネクタではいずれの試行も遮断されたという。

攻撃手法
ソフトウェア

要点

  • 誰が何を報告したか: ReliaQuest Threat Researchが、Microsoft 365(Exchange Online)の制御「RejectDirectSend」の迂回を報告し、自社テナントで再現した。
  • 何が起きるか: SMTPのエンベロープ送信者(Envelope From)を空にすると、RejectDirectSendのドメイン判定を素通りし、内部アドレスに見えるFromヘッダーのまま未認証メールがMicrosoft 365に受け入れられる。
  • ReliaQuestは何を推奨しているか: 同社は、IP制限付きインバウンドコネクタの利用、フィルタリング例外の厳格な管理、空エンベロープと内部アドレスの組み合わせの監視を推奨している。

RejectDirectSendとは何か

Direct Sendは、デバイスやアプリが同一Microsoft 365テナントの受信者へ認証なしでメールを送る仕組みだ。ReliaQuestによると、RejectDirectSendは、組織ドメインを名乗る未認証のDirect Sendメールを拒否するためのExchange Onlineの制御で、SMTPのエンベロープ送信者に含まれるドメインを評価する。

しかし、エンベロープ送信者が空(null reverse-path)の場合、評価対象のドメインが存在しない。ReliaQuestは「空の値では判定するドメインがないため検査を素通りする」と説明している。これはMicrosoft製品の脆弱性ではなく、制御の適用範囲の限界だと同社は位置づけ、Microsoftへ複数回にわたり連絡したと記している。

ReliaQuestの検証 — 1つの空欄で結果が変わった

ReliaQuestは、自社保有のMicrosoft 365テナントでRejectDirectSendが有効な状態を事前に確認したうえで、2通のメッセージを同一条件で送信した。どちらも認証なしでテナントのメールホスト(*.mail.protection.outlook.com)へ直接送り、表示上のFromヘッダーは同一の内部ITサポートアドレスを用いた。違いはエンベロープ送信者だけだ。

  • ベースライン: テナントの受理ドメインに属するアドレスをエンベロープ送信者に指定 → Microsoft 365は拒否した
  • 空エンベロープ: エンベロープ送信者を空(<>)に指定 → Microsoft 365は受け入れ、キューに登録した

ReliaQuestによると、この1項目の違いだけで挙動が反転した。同社はPythonのsmtplibを用いた再現スクリプトを公開し、mail_fromを空文字列にして送信する手順を示している。

実際の悪用パターン

ReliaQuestは過去1年間に、この空エンベロープのパターンを用いた多数の事例を確認した。調査したケースでは、攻撃者は次のような手口を繰り返していた。

  • 自己宛て(self-addressed)メール: 送信者と受信者が同一に見える形で送り、受信者の警戒心を下げる
  • 業務を装う文面: 社内通知や取引先連絡を装う件名・本文
  • 狙われた役割: 経営層、管理職、顧客対応など対外業務の担当者

1件では、送信者認証がすべて失敗し、Microsoft 365側で高確度のフィッシングと分類されたにもかかわらず、なりすまされた幹部アドレスが許可リストに含まれていたため受信箱へ届いた。ReliaQuestは「フィルタリング例外は、特に権限を持つ利用者や頻繁になりすまされる利用者を対象とする場合、高いリスクを伴う信頼判断だ」と指摘している。

同社はまた、空エンベロープの手法が「認証情報も、なりすまし用ドメインの登録も、専用の送信基盤も不要で、1つの項目を空にするだけで成立する」ため、今後も継続的な悪用が予想されると評価している。

ReliaQuestが推奨する対策

記事中の対策は、ReliaQuestが実際に推奨として公表している内容に限定して整理する。

  • IP制限付きインバウンドコネクタを利用する: ReliaQuestの検証では、IP制限付きインバウンドコネクタを構成したテナントでは、エンベロープ送信者の値にかかわらずDirect Sendの試行をすべて遮断できた。同社は、受信メールを承認済み送信元IPに限定している組織は本手法の影響を受けないと説明している。
  • フィルタリング例外を厳格に管理する: 許可リストや例外は、なりすましの踏み台になり得る。ReliaQuestは、特に権限を持つ利用者や頻繁になりすまされる利用者を対象とする例外を厳格に管理するよう呼びかけている。
  • 空エンベロープと内部アドレスの組み合わせを監視する: エンベロープ送信者が空で、かつ表示上のFromヘッダーが内部ドメインに見えるメッセージを検知対象とするよう推奨している。

ReliaQuestは「RejectDirectSendだけに依存してDirect Sendのなりすましを防ぐべきではない」と述べている。

背景と位置づけ

ReliaQuestは本報告を、ReliaQuest自身の環境の脆弱性ではなく、第三者や広範な脅威環境に影響する外部脅威インテリジェンスとして位置づけている。報告日は米国時間2026年9月3日だ。

日本国内でもMicrosoft 365とExchange Onlineは広く利用されており、Direct Sendを用いる複合機や業務アプリがテナント内に存在する組織は少なくない。ReliaQuestが示したIP制限付きインバウンドコネクタの有無や例外設定の状況は、自組織の受信経路が本迂回手法の影響を受けるかどうかを判断する手がかりになる。

出典

この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。