ブログ

Exchange OnlineのGhost-Sender欠陥:DMARCに加えて確認すべきこと

作成者: Jack Zagorski|2026/07/13 8:04:20

Ghost-Senderは、Microsoft Exchange Onlineが受信メールを受け入れる仕組みに新たに文書化された欠陥です。この欠陥を悪用すると、攻撃者は、なりすましメールを検出するはずの認証チェックにすべて失敗しているにもかかわらず、同僚や信頼できるブランドから届いたように見える偽装メールを受信トレイに届けることができます。セキュリティ研究者のInfoGuardは2026年6月9日にこの手法を公表し、Microsoftはこれを修正予定の不具合ではなく、既知のアーキテクチャ上の制限に分類しています。

この欠陥は、受信メールをMicrosoft 365に届く前にサードパーティのスパムフィルターを経由させている組織に影響します。この構成は一般的で、特にITを代理店やサービスプロバイダーが管理している企業でよく見られます。DMARCの強制(enforcement)はスプーフィングに対する通常の防御策ですが、この攻撃は止められません。偽装メールが、DMARCの判定が適用されない経路から入ってくるためです。以下のセクションでは、この手法の仕組み、認証だけでは止められない理由、そしてこの隙間を塞ぐMicrosoft 365の設定を説明します。

本ガイドの内容

Ghost-Sender欠陥とは何か?

Ghost-Senderは、偽装メールをMicrosoft 365の受信トレイに届けるための手法です。メールは信頼できる同僚や有名なブランドから届いたように装います。認証チェックはその主張を偽と判定しますが、Exchange Onlineはそれでもメールを配信します。

InfoGuardの研究者は2026年6月9日にこの手法を公表しました。彼らのテストでは、noreply@microsoft.comから届いたように装ったメールが、すべてのチェックで失敗の結果を伴って受信トレイに到達しました。SPFは失敗し、DKIMは付与されておらず、DMARCも失敗しました。通常、このような結果はメールが拒否されるかスパムフォルダーに入ることを意味します。しかしこのメールは配信されました。

この手法には、盗まれたパスワードも対象ドメインのDNSへの変更も必要ありません。Exchange Onlineが受信メールをルーティングする仕組みを悪用するため、SPF、DKIM、DMARCのレコードがすべて正しく設定されているドメインに対しても機能します。

攻撃者はどのようにExchange Onlineのフィルタリングを回避するのか

多くの組織は、ドメインのメールレコードをMicrosoftに直接向けていません。その手前にサードパーティのセキュリティゲートウェイ、つまりProofpoint、Mimecast、Barracudaといったベンダーのスパム・マルウェアフィルターを配置します。MXレコード(メールの配信先を世界に伝えるDNSエントリ)はそのフィルターを指しており、Microsoftを指してはいません。メールは一方向に流れるはずです。インターネットからフィルターへ、フィルターからMicrosoftへ、Microsoftから受信トレイへ、という流れです。

問題は、Microsoft自身の配信用アドレスが常に到達可能なままだという点です。すべてのMicrosoft 365組織(Microsoftの用語では「テナント」)は、yourdomain.mail.protection.outlook.comという形式の直接配信アドレスを持ち、インターネット上の誰からでもメールを受け入れます。このアドレスに送信した攻撃者はExchange Onlineに直接到達し、外部フィルターを完全に迂回します。フィルターはそのメールを一度も見ないため、スプーフィング対策やフィッシング対策のルールはどれも作動しません。

メールがMicrosoft自身のインフラを通じて届くため、Exchange Onlineはそれをオープンなインターネットから届くメールよりも信頼して扱います。この見当違いの信頼こそが、欠陥の核心です。

なぜSPF、DKIM、DMARCはこれを検出できないのか?

SPF、DKIM、DMARCは、メールが本当にFromアドレスのドメインから来ているかどうかを判断するために、受信側のメールサーバーが実行するチェックです。これらはドメインなりすましに対する中核的な防御であり、その大部分を阻止します。

Ghost-Senderはこれらのチェックを打ち破るわけではありません。チェックの結果が適用される配信上の地点を迂回するのです。偽装メールは、InfoGuardのテストが示したとおり、実際に3つすべてで失敗します。しかしメールはすでにMicrosoftの直接配信アドレスで受け入れられており、Exchange Onlineは内部扱いとするメールに対して同じDMARCの強制を適用しません。認証の判定は「fail」ですが、メールはそれでも配信されます。

だからといってDMARCが不要になるわけではありません。DMARCは依然として、日常的なスプーフィングを止める制御です。偽の取引先請求書、経営層になりすました送金依頼、Exchangeのエンドポイントに一切触れない類似ドメインからのフィッシングなどです。Ghost-Senderは狭い範囲のアーキテクチャ上の例外であり、その下でDMARCが必要である理由を何ら変えるものではありません。

この方法で偽装されたメールは、そもそもクリーンな認証を維持するのが難しいインフラに届きます。DMARCeyeの2026年第1四半期業界レポートによると、Microsoftのインフラに帰属するメールのコンプライアンスは90.0%で、SPFはメールの26.6%で、DKIMは19.6%で失敗していました。Microsoft経由で送信される正規メールのかなりの部分が、すでにクリーンに認証されていません。第1四半期のレポートが指摘するとおり、大手プロバイダーでのコンプライアンスの低さは、ほぼ常にプラットフォーム自体の欠陥ではなく、送信者側の設定の問題です。よくある原因は、正しいDKIMキーをDNSに追加していない顧客や、送信規模がSPFレコードの範囲を超えてしまった顧客です。

重要なのは、Microsoftのメールが脆弱だということではありません。重要なのは、Microsoft 365のメールフローを正しく設定するのが複雑だということであり、Ghost-Senderは受信ルーティングの構成における1つの特定の隙間を突いています。

詳細なレポートは以下からダウンロードできます。

 

Microsoftの対応:「既知のアーキテクチャ上の制限」

InfoGuardは2026年4月21日にこの問題をMicrosoftに報告しました。Microsoftは翌日に内部的な緩和策を展開しましたが、4月27日にそれを取り消しました。2026年5月29日、MicrosoftはGhost-Senderを製品の脆弱性ではなく既知のアーキテクチャ上の制限に分類し、その時点でプラットフォームレベルの修正は存在しませんでした。

実際には、これは隙間を塞ぐ責任が、自動的に届くパッチではなく各組織にあることを意味します。Microsoftは関連する既定設定を強化しており、新規テナントでは、攻撃が依拠する機能であるDirect Sendが、Microsoftが2026年初頭に展開を開始した変更により、既定で拒否されるようになりました。既存のテナントは、管理者が変更するまで現在の構成を維持します。

外部フィルターを使ってMicrosoft 365を運用している場合、修正が届くのを待つことはできません。自分で設定を確認し、調整する必要があります。

あなたは影響を受けるか?Exchange Onlineの設定を確認する方法

次の2つが当てはまる場合、影響を受ける可能性があります。組織がMicrosoft 365(またはハイブリッド構成のExchange)を使用しており、ドメインのMXレコードがMicrosoftに直接ではなくサードパーティのフィルターを指していることです。専用のセキュリティゲートウェイをMicrosoftの手前に配置するのは一般的な設計であるため、これは管理対象テナントの大部分に当てはまります。

InfoGuardのスキャンでは、バグバウンティプログラムを通じてテストしたExchange Onlineドメインの20%超が脆弱に見え、外部MXレコードを使用している環境の半数未満しか何らかの緩和策を導入していないことが分かりました。

テナントを確認するには、次の3つの問いを順に検討します。

  • MXレコードはどこを指しているか? *.mail.protection.outlook.com以外を指している場合、メールはサードパーティを経由してルーティングされており、Microsoftへの直接エンドポイントは依然として露出しています。
  • 受信コネクタは制限されているか? Exchange管理センターで受信コネクタを確認してください。送信者をIP範囲またはTLS証明書で制限するコネクタが、この隙間を塞ぐ制御です。そのような制限が存在しない場合、テナントはおそらく無防備です。
  • Direct Sendは有効になっているか? Direct Sendは、認証なしでメールが受信トレイに届くことを可能にします。これが有効で、それを補う転送ルールがない場合、偽装メールが通り抜ける可能性があります。

今すべきこと:実践的な緩和策

2つの構成がGhost-Senderを確実にブロックし、Microsoft自身のDirect Sendの制御機能が3つ目の層を追加します。

  1. 受信コネクタを制限する。 パートナー組織の受信コネクタを、任意のドメインからのメールに適用され、IP範囲またはTLS証明書の検証に合格したメッセージのみを受け入れるように作成または調整します。これにより、Exchange Onlineに対して、受信メールをフィルターのアドレスからのものだけ信頼し、直接配信アドレスを見つけた誰からのものでも信頼しないよう指示します。
  2. 内部を装った信頼できないメールを検疫する。 最優先(優先度0)の転送ルールを追加し、承認済みの送信元からのX-MS-Exchange-Organization-AuthAs: Internalヘッダーを持たない、または承認済みのIP範囲から届いていない受信メッセージをすべて検疫します。平たく言えば、これは内部を装いながら信頼できる経路で届かなかったメールを捕捉します。
  3. Direct Sendを無効にする。 Direct Sendは、デバイスやアプリが認証なしでテナント経由でメールを送信できるようにするMicrosoft 365の機能です。これを無効にする(RejectDirectSend設定)と、Ghost-Senderが悪用する特定の経路が取り除かれます。まず、正規のプリンター、スキャナー、業務アプリが認証済みのコネクタを使用していることを確認してください。

これはDMARCの問題ではなく、Microsoft 365の設定の問題であり、解決策もMicrosoft 365にあります。DMARC monitoringが加えるのは可視性です。偽装メールがSPF、DKIM、DMARCに失敗しても、Microsoftはその失敗を記録し、DMARC集計レポートに含めます。これらのレポートを代わりに読み取るツールは、認識のない送信元からあなたのドメインを名乗って送られた、認証に失敗した偽装メールを示します。これはまさに、Ghost-Senderのような手法があなたに対して使われているという兆候です。DMARCeyeの無料プランは1ドメインをカバーし、レポートの生データを、誰があなたを名乗って送信し、何が失敗しているのかを分かりやすく示すビューに変換します。

自分のドメインが現在何を公開しているかをすぐに確認したい場合は、現在のDMARCレコードから始めてください。

 

実践的なまとめ

メールセキュリティは層で機能し、単一の層ですべてを網羅することはできません。DMARCは不可欠な中核です。Fromアドレスのドメインを認証し、メール詐欺の大半を占める広範なスプーフィングを阻止します。この欠陥がその中核を弱めることはありません。この欠陥が露呈させるのは別の層、つまりMicrosoft 365が自らの内部メールフローに置く信頼です。DMARCはこの層を管理するようには設計されておらず、それを守れるのはあなたのMicrosoft 365の設定だけです。

代理店やITプロバイダーにとって、クライアントへのメッセージは同時に両方です。DMARCの強制はスプーフィングの大半を止めるので維持し、DMARCが届かないExchange Onlineの隙間は塞ぐ、ということです。

この2つで一組の答えこそ、私たちが最も重要だと考える仕事です。DMARCeyeは、誰が自分のドメインを名乗って送信しているのかを明確に可視化し、スプーフィングとそれがもたらす実際のリスク、そして機能する対策を、今回のようにDMARC自体の範囲を超えるものも含めて説明するために存在します。