ReliaQuestによると、脅威アクターは空のSMTPエンベロープ送信者を使用することで、Microsoft 365のRejectDirectSend保護機能を回避できることが判明しました。この手法により、フィッシングメッセージを信頼された社内ユーザーから送信されたかのように見せかけることが可能になります。
RejectDirectSendは、組織自身のMicrosoft 365ドメインから送信されたと偽る、未認証のDirect Sendメールを阻止するために設計されたExchange Onlineの制御機能です。
Direct Sendは、プリンター、スキャナー、アプリケーション、その他のデバイスが、サインイン認証情報を必要とせずに同一テナント内のユーザーへメッセージを送信する際によく利用されています。
しかしReliaQuestの調査により、この制御機能はSMTPエンベロープ送信者(MAIL FROMアドレスとも呼ばれる)内のドメインをチェックしているに過ぎないことが判明しました。
攻撃者がMAIL FROM:<>と表される空のエンベロープ送信者を使ってメッセージを送信すると、RejectDirectSendが評価すべきドメインが存在しなくなります。
それでも、目に見える「From」アドレスには、「IT サポート」や役員のメールアドレスといった、信頼できる社内の身元情報を依然として表示させることができます。
これはフィッシングのリスクを生み出します。メッセージが実際には外部から未認証の状態で送られてきたものであっても、受信者はメールクライアントに表示された送信者の身元情報を信用してしまう可能性があるためです。
ReliaQuestは制御された環境でテストを実施し、RejectDirectSendが有効化されたMicrosoft 365テナントに対して、未認証の2通のメッセージを直接送信しました。両方のメッセージは、同一の社内風「From」ヘッダー、受信者、送信元ホスト、SMTPセッション設定を使用していました。
唯一の有意な違いは、SMTPエンベロープ送信者でした。
基準となるメッセージは、エンベロープ送信者がテナントの許可済みドメインを使用していたため、Microsoft 365によって拒否されました。一方、空のエンベロープを使用したメッセージは、RejectDirectSendが検査すべき送信者ドメインを持たなかったため、配信が受理されました。
このバイパスは、必ずしも受信トレイへの配信を保証するものではありません。ReliaQuestのテストでは、Microsoft 365がこのメールを匿名かつ未認証と分類し、スパム信頼度レベル(Spam Confidence Level)9を割り当てて迷惑メールフォルダーに振り分けました。SPFおよびDKIMのチェックには合格せず、DMARCも失敗していました。
それでも、テナントのメールフローに受理されること自体が重要な意味を持ちます。実際にメールボックスへ配信されるかどうかは、その後のアンチスパム・フィッシング対策の制御機能、メッセージの内容、送信元インフラ、テナント固有の例外設定などに左右されるからです。
設定に不備のある許可ルールが存在すれば、こうした保護機能を無効化し、メッセージを受信者の受信トレイに到達させてしまう可能性があります。
ReliaQuestによると、2025年9月から2026年8月にかけて、空のSMTPエンベロープ送信者を使用した複数のフィッシング事例が確認されたとのことです。この攻撃活動は、役員、管理職、財務担当者、調達チーム、顧客対応部門の従業員を標的にしていました。
攻撃者は、文書共有通知、支払い要求、送金明細、調達招待、ボイスメールやファックスの通知などを、よく餌として使用していました。
一部のキャンペーンでは、ボイスメール録音を装ったSVG添付ファイルが使用されており、被害者を悪意あるリンクや認証情報窃取ページへ誘導する狙いがあったとみられます。
調査対象となったある事例では、Microsoft 365がこのメッセージを高確度のフィッシングと識別し、送信者認証が失敗していたことも判明しました。
それにもかかわらず、偽装された役員のアドレスが許可済み送信者として設定されていたため、このメッセージは受信トレイに到達してしまいました。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をよりスピーディーに-> ANY.RUNでSOCを強化
翻訳元: https://cyberpress.org/empty-sender-bypasses-rejectdirectsend/
