2025年6月 Varonis Threat Labsは、Microsoft 365(M365)のメール機能“Direct Send”を悪用するフィッシングキャンペーンが拡大していると報告しました。2025年5月から継続して活動しており、既に70社以上(主に米国法人)が被害に遭っています。
目次
そもそもDirect Sendとは?
Direct Sendは、本来プリンターやネットワーク機器が認証なしで社内宛メールを送るための仕組みで、送信先は同一テナント内に限定されています。
一方で攻撃者にとっては「Sender認証を必要とせず」「M365インフラを通じて社内メールに見せかける」絶好の抜け穴となっています。
攻撃の手順:不正ログインすら不要
スマートホストの特定
Microsoft 365のDirect Sendでは、以下のようなスマートホストを使います
<tenant-name>.mail.protection.outlook.com
テナント名はドメイン名から容易に推測でき、スマートホストの構成も標準化されているため、特定は極めて容易です。
送信元アドレスの偽装
多くの企業の社内メールアドレス形式は「[email protected]」のように予測可能です。過去の情報漏洩や公開プロフィール、ソーシャルメディアからも容易に取得できます。
PowerShellで送信実行
攻撃者は、PowerShellのSend-MailMessageコマンドを使用し、以下のような形で偽装メールを送信します
Send-MailMessage -SmtpServer tenantname.mail.protection.outlook.com `
-To [email protected] `
-From [email protected] `
-Subject "新しいFAXメッセージ" `
-Body "新着FAXがあります。下記リンクからご確認ください。" `
-BodyAsHtml
ポイントは、「送信者=受信者」という“内部メールにしか見えない”構成にある点です。
Microsoft 365が内部通信と判断して受信
認証が行われていないにも関わらず、メールはMicrosoftのスマートホスト経由で届けられるため、多くのセキュリティ製品が「内部通信」と誤認してしまいます。
-
SPF、DKIM、DMARCをすべて失敗していてもブロックされない
-
サンドボックスやフィルタリング処理が無効化される
-
組織内のエンドユーザーが疑わずに開封してしまう
なぜばれないのか?
-
SPF/DKIM/DMARCエラーにも関わらず、M365のスマートホスト経由なら「社内メール」と扱われる
-
受信側のメールセキュリティ製品やExchangeでも内部送信と見なしブロックしづらい
-
「ユーザーからユーザーへ」「PowerShellを使った送信」など、通常とは異常な痕跡が見えにくい

Microsoftとしての対応方針
Microsoftも、Direct Sendが不要な顧客により安全なオプションを提供中です:
-
今後、すべてのテナントでDirect Sendをデフォルト無効化へ逐次移行
-
PowerShellや管理センターから“Reject Direct Send”(認証なし送信拒否)の設定が可能に
-
スマートホストを利用する場合の推奨設定:
-
SPFに固定IPを登録
-
DKIM/DMARCを厳格に運用
-
ポート25・TLSを使用
-
企業として今からやるべき対策
| 対策領域 | 推奨アクション |
|---|---|
| 技術設定 | ・Direct Sendは不要なら無効に ・SPFに静的IP登録/DKIM・DMARC強化 |
| 検知・監視 | ・未認証メールをQuarantine対象に設定 ・“PowerShellからの送信”“ユーザー宛に送信”などを監視 |
| 訓練・教育 | ・QRコード付きフィッシングへの注意喚起 ・Exchange運用者の設定教育 |
| 多層防御 | ・Exchange Online Protection(EOP)のアンチスプーフィングポリシー活用 ・MFAと条件付きアクセスでユーザーを保護 |








