【メールセキュリティの基礎①】差出人は本物なのに詐欺メール。 認証を通過した「EchoSpoofing攻撃」の仕組みと対策
公開日 2026.11.01
差出人は本物の企業のアドレス。メール認証も合格。それでも中身は詐欺。 2024年に公表されたEchoSpoofingを入り口に、メールの配送と認証の仕組みを紙模型のアニメーションで解説します。 封筒と便箋で異なる差出人、SMTP-AUTH、OP25B、SPF、DKIM、DMARCの役割を一つずつ整理します。認証が保証する範囲を知り、公式アプリや登録済みのブックマークから確かめる行動につなげます。 国内の不正アクセス事例を、原因から調べるポータルサイト運営してます https://bankenjp.com/ チャプター 参考情報（提供台本に記載された資料） 確認日：2026年10月29日。以下はいずれも仕様の原文、調査主体、提供元、公的機関の資料。台本中の「あおぞら商店」などは仕組みを説明するための架空例。 1. Guardio Labs / Nati Tal, “EchoSpoofing — A Massive Phishing Campaign Exploiting Proofpoint’s Email Protection to Dispatch Millions of Perfectly Spoofed Emails”, 2024年7月29日。 - 攻撃経路、公開検体のSPF・DKIM・DMARC合格、活動開始時期と配信規模の推計、組織の制限不足、署名機能の悪用を確認。 - https://site.guard.io/labs/echospoofing-a-massive-phishing-campaign-exploiting-proofpoints-email-protection-to-dispatch 2. Proofpoint Threat Research Team, 2024年7月29日公開のMicrosoft 365経由の中継悪用に関する報告（現行ページ名：Microsoft 365 Abuse Leads to onmicrosoft.com Spam）。 - 許可するテナントの制限不足、中継時のDKIM署名、許可テナントの明示とそれ以外の既定拒否を確認。影響は一部の構成で、Proofpoint Essentialsは対象外と説明されている。 - https://www.proofpoint.com/us/blog/threat-insight/scammer-abuses-microsoft-365-tenants-relaying-through-proofpoint-servers-deliver 3. IETF, RFC 5321, Simple Mail Transfer Protocol, §§2.3.1, 3.3, 4.1.1.2, 5。 - SMTPの配送、エンベロープ、MAIL FROMと配送失敗通知、相手サーバーの探索。 - https://www.rfc-editor.org/rfc/rfc5321 4. IETF, RFC 5322, Internet Message Format, §3.6.2。 - メッセージ内のFromヘッダーと表示名。 - https://datatracker.ietf.org/doc/html/rfc5322 5. IETF, RFC 4954, SMTP Service Extension for Authentication, §§3–5。 - SMTP-AUTHと認証された識別情報。 - https://www.rfc-editor.org/rfc/rfc4954 6. IETF, RFC 6409, Message Submission for Mail、およびRFC 8314, Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access。 - 投稿と中継の区別、587番・465番、投稿時の認証とTLS。 - https://datatracker.ietf.org/doc/html/rfc6409 - https://www.rfc-editor.org/rfc/rfc8314 7. JPNIC, 「インターネット用語1分解説～OP25B(Outbound Port 25 Blocking)とは～」。 - OP25Bの仕組みと正規の直接送信にも影響すること。 - https://www.nic.ad.jp/ja/basics/terms/OP25B.html 8. IETF, RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, §§2.3–2.5。 - 接続元IPとMAIL FROMドメインの照合。SPFにはHELOの確認もあり、台本では通常の配送用差出人を用いる経路に絞って説明。 - https://www.rfc-editor.org/rfc/rfc7208 9. IETF, RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, §§2.5, 3.5, 3.7, 5.4。 - 署名ドメイン、秘密鍵・公開鍵、署名対象、From署名の必須要件、本文長指定。 - https://datatracker.ietf.org/doc/html/rfc6376 10. IETF, RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC), §§1, 4.4, 4.7, 4.10, 5.3, 7.4。 - SPFまたはDKIMの合格とアライメント、ポリシー、表示名やアドレスのローカル部を認証しないこと、認証合格が安全性を保証しないこと。 - https://datatracker.ietf.org/doc/html/rfc9989 - 2026年5月公開の現行仕様。事件当時のRFC 7489を置き換えている。台本は両仕様で共通する基本原理を中心に説明し、拒否方針だけによる自動拒否とは説明していない。 11. Google Workspace公式ヘルプ「SPFを設定する」「DKIMを設定する」「DMARCを設定する」。 - DNSでの公開と受信側の検証・処理の実装例。DMARCの厳密な仕様は上記RFC 9989を優先。 - https://knowledge.workspace.google.com/admin/security/set-up-spf?hl=ja - https://knowledge.workspace.google.com/admin/security/set-up-dkim?hl=ja - https://knowledge.workspace.google.com/admin/security/set-up-dmarc?hl=ja 12. 警察庁「フィッシング対策」。 - 公式アプリや登録済みブックマークから確認する対策。 - https://www.npa.go.jp/bureau/cyber/countermeasures/phishing.html 事実関係についての補足：Guardioの公開検体には、表示用・配送用の双方でdisney.comを使い、三つの認証が合格した例がある。Proofpointの報告には、同社が観測したメールではエンベロープ送信者を詐称できなかったという記述もある。このため、台本は「全攻撃メールが同じ配送用差出人・同じ認証結果だった」とは一般化せず、三つの合格はGuardioの公開検体に限定して記述した。両報告で共通する、中継許可の制限不足と正規のDKIM署名付与を事件説明の軸にしている。
YouTubeで見る動画のページ · 別タブで開く