- 攻撃者が DKIMリプレイ攻撃 を利用して、Googleを装ったフィッシングメールの送信に成功した事例
- メールの 送信元アドレスおよび認証結果 が本物のGoogle公式メールのように見え、利用者が容易にだまされる可能性がある
- 攻撃者は Google Sites を活用し、公式サポートページのように見えるサイトを作成して信頼性を高めた
- SPF、DMARC、DKIMの認証をすべて通過するが、本文や署名ヘッダーを変更せずに メールを再送 することが中核となる
- 実効的な対策として、DKIMキーの定期的なローテーション と利用者の認識向上が推奨される
はじめに: 正常に見えるフィッシングメール
- ある朝、知人が Googleアカウントに関する法的書類の要求 を受けたというメールを受信した
- 送信者は Google公式の no-reply アドレス と表示され、誤字や不審なリンク、異常なドメインもなく、巧妙に作成されていた
- 受信者は真偽の判断が難しく、専門家に調査を依頼した
メール詳細分析
- メールヘッダーおよびリンクプレビューを サンドボックス環境 で調査
- 送信元アドレス、ブランディング、言語品質、添付ファイルの有無 はいずれも正常だった
- しかし、SPF、DKIM、DMARCの認証結果を確認すると 異常な兆候 が見つかった
フィッシングメールへの注意点
- 不審なメール内のリンクをクリックしたり、指示を実行したりしないこと を強調
- サンドボックスではない環境でそのメールに返信したり添付ファイルを開いたりすると、情報漏えい、企業メール侵害、アカウント乗っ取り、ネットワーク侵害 の危険がある
- 疑わしい場合は直ちに専門的な分析を依頼し、セキュリティチームへ報告する必要がある
攻撃の流れ: Google Sitesの活用
- 攻撃メール内のリンクは、ログイン状態であれば直接 Google Sites に接続される
- Google Sitesは誰でも無料で作成できる 公式 google.com サブドメイン だが、内容そのものは公式サポートページではない
- 社内Wiki、プロジェクトダッシュボード、ドキュメント化、イベントWebサイトなど多様な用途で使われる一方、今回のように悪用される可能性がある
インフラへの信頼が脅威になる瞬間
- Google Sites（2008年公開）は Google Workspace と連携し、容易な作成・配布・SSL認証・ブランド信頼性を提供する
- 攻撃者は独自ドメインやホスティングなしでも、公式に見えるフィッシングサイトを容易かつ低コストで構築できる
DKIMリプレイ攻撃の詳細な過程
1段階: 実際のGoogleメールの確保
- 攻撃者は no-reply@accounts.google.com アカウントから正規メールを受信し、元の本文とヘッダーを保存した
2段階: 署名済みメッセージ再送の準備
- DKIM はメール本文の一部および特定のヘッダーに対してデジタル署名を付与する
- 元のメッセージと署名ヘッダーが維持されれば、再送時でも認証は維持される
3段階: Outlookを通じた再送
- 攻撃者は Outlookアカウント から攻撃用メールを送信した
- 発信元や経路情報の一部は変更されるが、DKIM署名は有効なまま残る
4段階: Jellyfish SMTP中継サーバーの利用
- Microsoftの Jellyfishシステム を経由してメールをルーティングした（送信元サーバーとの距離を確保）
5段階: Namecheap PrivateEmailを介した送信
- Namecheap の PrivateEmail サービスがメールを受信し、その後さらに中継の役割を果たした
- この過程で新しいDKIM署名が追加されるが、DMARC基準には適合しない
- 元のGoogle DKIM署名が一致かつ有効であるため、DMARC検証を通過する
6段階: Gmailへの最終配達
- 最終的に受信者は Google公式メール に見えるメールを受信する
- SPF、DKIM、DMARCがすべて認証を通過 する結果となる
偽の召喚状メールが危険な理由
- 「召喚状」メールは受信者に 恐怖、緊急性、混乱 を引き起こす
- 実際の召喚状の発行・送達方法とは異なり、正規であれば物理的な送達や公式チャネルを通じて行われる
- この種のフィッシングは非常に説得力が高く、技術的に熟練した利用者でも容易にだまされ得る
結論と対応
- 予期しない緊急メール ほど、常に真偽確認と専門家への対応依頼が必須
- リンクのクリック、返信、実行は一切しないこと
- セキュリティチームまたは調査専門人員への分析依頼を推奨
追加: 攻撃再現の過程
- 攻撃者は Namecheap でドメインを登録し、無料の PrivateEmail サービスを取得
- Google Workspace（無料トライアル）に登録し、ドメイン認証後に悪意ある Google OAuth App を作成
- App Name フィールドで任意の名前を設定可能（例: Google Support）
- Googleが送信したアカウント通知が PrivateEmail に転送され、送信元アドレスと返信先アドレスを操作できる
- 最終的に攻撃メールが狙ったターゲットへ配達される
よくある質問
- DKIMリプレイ攻撃: 攻撃者が有効なDKIM署名を含む正規メールを取得し、同一の内容・ヘッダーで再送すること
- SPF、DMARCによる遮断の限界: SPFは送信サーバー/IPのみを検証するため、リプレイ攻撃ではDKIM整合性があればDMARCも通過し得る
- 検知が難しい理由: 本文やヘッダーの改ざんがなく、署名検証だけでは識別が困難
- 攻撃におけるGoogle OAuthの迂回: 攻撃者は悪意あるOAuth Appを作成し、Googleが送信した公式通知を再送して信頼性を高める
- 対策: DKIMキーの定期的ローテーション（30日以下の周期） と利用者教育（不審なリンクへの注意、URL確認、報告文化の浸透）が重要
1件のコメント
Hacker Newsのコメント
私はこの問題の解決策を作っています（GoogleとYahoo出身の共著者たちと進めており、信頼できるプロジェクトです）
Draft: DKIM2 Motivation の文書を参照してください
この方式では、ユーザーが入力したテキストがGoogleから実際に送信されること自体は防げませんが、Googleの実際の意図なしにそのメッセージが再送されることは防げます
なぜなら SMTP FROM/TO フィールドが保護されるからです
モチベーションのドラフトには技術的な詳細は含まれておらず、関連文書でドラフトを見ることができます
DKIM Working Group Documents のリンクを参照してください
Datatrackerのサイトは候補文書をうまく表示してくれないので、直接リンクを貼っておきます
Draft: dkim2-dns
Draft: dkim2-header
Draft: dkim2-modification-algebra
Draft: dkim2-bounce-processing
Draft: dkim2-message-examples
この方式がメーリングリストやグループに対してどう機能するのか気になります
たとえば、外部から accounts-payable@example.com に届いたメールをチームメンバーへ自動転送することはよくあります
最終受信者のシステムでは、メーリングリストのフォワーダーを信頼する設定が必要になるのか、それともどのリストに含まれているかを追跡する内部ロジックが必要になるのか気になります
元の受信者である accounts-payable が有効な受信者であることを確認できる必要があります
実際にコンピュータハッキング容疑で有罪判決を受けた後、FBI に私の Google アカウント資料一式を押収されたことがあります
2016年に一度、2018年にもう一度持っていかれました
実際には、この記事のようなやり方ではありません
私の経験では、Google の特定部門にメールを送って公式なやり取りを進めます
捜査機関は、できるだけ捜査対象者に気づかれないよう慎重に動きます
usernotice@google.com から次のような内容のメールを受け取ります:
連邦大陪審の召喚状（Federal Grand Jury subpoena）では、通常、サービス提供者（Google など）があなたに通知できないように 1〜2 年の通知遅延を求めます
召喚状では一般的な記録（請求情報、ログイン記録など）のみが提供され、コンテンツ（メールなど）は提供されません
メールなどの実データについては別途捜索令状が必要で、Google は通常、そのような捜索令状が執行された事実を別途通知しません
金曜日ですが、このコメントで10%くらい目が覚めました
詳しい後日談が気になります
興味深いです
この依頼が GDPR の「自分のアカウントに関するすべてのデータをください」リクエストなどに含まれて、自分のアカウントデータ一式のファイルに記録やタグとして残るのか気になります
推測ですが、捜索令状は CFAA 違反、wire fraud、または conspiracy などで出ていたのではないかと思います
良い弁護士を雇って、うまく解決していたことを願います
最近、似たような攻撃が私のところにも来ました
攻撃者は yourgoogleaccount@google.com（正確には gmail.com ではありません）からメールを送り、その後 Google のメールサーバーから受け取った配送エラーメッセージ（bounce）を yourgoogleaccount@gmail.com に転送し、最後にスパムメッセージを差し込みます
すべてのセキュリティチェックを通過します
postmaster エラーとフィッシングキャンペーンが組み合わさっている点が本当に奇妙です
非技術者なら簡単に引っかかりそうです
私の場合、フィッシングメールの内容は建設工具が当たったというものでした
もう Google はメールを諦めたのではないかという気さえします
記事を読みながらとても混乱しました
攻撃者がメール本文を改ざんしてフィッシングリンクを挿入したかのように詳しく描写していますが、実際にはそのような証拠も改ざんもありませんでした
DKIM 署名には本文のハッシュが含まれます
技術的には I= フィールドを使ってハッシュ範囲を制限することは可能ですが、Google が短いメールにそのオプションを使っていないことは確認済みです（no-reply@accounts.google.com のメールを実際に確認した結果）
つまり、DKIM と DMARC の検査を通過するには本文が変更されていてはならず、したがってフィッシングリンクも元々 Google が送った内容だったことになります（ただし、想定された受信者は別だった可能性があります）
したがって、実際には「怖いメールが誤って転送された事例」のほうが本質であり、「DKIM replay attack」というタイトルは、この分野に不慣れな人にははるかに深刻に聞こえるかもしれません
編集: TFA の "The Takeaway?" を見てそこで記事が終わったと思ったのですが、その下のアップデートで、リンクが実際には Google OAuth アプリ名に埋め込まれ、Google のメールテンプレートに含まれていたことが説明されていました
ここがこの攻撃で最も重要な点なのに、記事の構成が悪すぎて埋もれており、まるで任意のコンテンツを送れるかのような誤解を招いています
追記: 別のコメントでは、メールのスクリーンショットが途中で切られていて、Google のメールテンプレートの固定部分が見えないように編集されていたことも指摘されていました
攻撃自体は思っていたよりずっと雑です
この記事は意図的に誤解を招くような書き方がされているように思います
キャプチャにある部分だけがメール全文であるかのように見せていますが、実際には警告になるような文面がその後に続いていたはずです
私の理解では、DKIM が検証されるのは、攻撃者が実際に Google から受け取ったメールをそのまま転送しているからです
本当の攻撃ベクトルは、Google に攻撃者がある程度コントロールできるテキスト入りのメールを送らせられる点にあります
個人的には、ここでの本当の脆弱性は、Google OAuth アプリ名に URL を入れられて、それが Google のルートドメインから no-reply メール内に任意のアドレスとして無差別にレンダリングされる点だと思います
たとえリンクがクリック不可能でも、周囲の文言を十分に脅威的にすれば、被害者が手でアクセスしてしまう可能性は高いです
DKIM の完全性が保たれる転送サービスが何段にも積み重なり得ることは、副次的に教育的な面があります
OAuth アプリ名に URL、特に google.com を含む URL が入ることは全面的に禁止すべきです
ついに！
数か月前、ほぼ同じメールを受け取ったことがあります（google domains の管理者宛てです）
確かに私もそのメールにはぞっとしました
私も軽率にリンクをクリックせず待って、この詐欺についてほかの参考情報を探そうとしました
奇妙だったのは、すべてのメールアドレスが伏せられていて、そのマスキングパターンが自分の管理しているメールとは一致しなかったことです
メール自体は legit で、ググってみると本文テキストも一致しました
私の場合は死亡したユーザーのアカウントに関するメールでしたが、実情とは一致していませんでした
それでも本当に誰かが Google を説得して、私が死亡したことにして私の Google アカウントを丸ごと乗っ取ろうとしているのではないかと、ほぼ100%疑っていました
ものすごく怖い体験でした
Step 3: 攻撃者が Outlook からメールを送信
私の知る限り、Received: ヘッダー上の経路を spoof することは不可能です
すべてのサーバーは自分自身の経路情報を追加し続けます
そのため、私はいつもメールの出所を検証する際にその情報を確認します
Google から来たメールが Microsoft のサーバーを経由するはずはありません
最後の「信頼できる（Trusted）」サーバーのヘッダーは偽装できませんが、それ以前の経路は偽装可能です
みなさんはすべてのメールのヘッダーを毎回手動で確認しているのか気になります
それとも、それを表示したり可視化したりするツールを使っているのでしょうか
本当に怖い状況です
この記事から得られる教訓を親戚に説明すると想像してみてください
信頼しているドメインから来ていて、dkim/dmarc/spf が順番にすべて通っていても、常に疑わなければならないと説明するのは気が重いです
ただ、この攻撃でできることの範囲はかなり限られています
たとえば、他人の Gmail アカウントからメッセージを偽造して送ることはできません
「メッセージが転送されるとき、DKIM 署名は本文と署名対象ヘッダーが変更されない限り保持される」
意外なのは、To: ヘッダーが DKIM 署名対象に含まれていない点です
署名設定の方法を変えるか、メールクライアントに、メール自体は正常でも To が変更されていたら警告する機能を追加すべきだと思います
この記事の教訓を親戚に説明すると想像してみてほしい ― 常に疑えと
dkim/dmarc/spf が何なのかから説明しなければならないのが厄介です
実際、こうした技術は本来ユーザーが知らなくてよいバックエンド技術です
この攻撃は、思われているほど怖くはありません
この記事は製品を売るために誇張して書かれている面があります
To: ヘッダーが署名に含まれていない点も、実はそれほど意味はありません
実際、メールの To は必ずしも最終受信者を書くものではありません
メールでは常に疑うという姿勢は、長い間デフォルト状態でした
From フィールド自体を決して信頼しないのが最善です
To: ヘッダーが DKIM 署名に含まれていないのが意外だと言っていましたが、実際には含まれています
だから元の To: 値は維持されていたはずです
再現セクションのスクリーンショットには元の To: アドレスが出ています
それはそのアドレスに配達されたという意味ではありません
本質的に、メールはどんなアドレスにも、どんな To: 値を持っていても配達できます
私の基本的な助言は、どんなメールでも何らかの action を促してくるなら、直接そのウェブサイトへ行くことです
どんなリンクもクリックしないことです
不便にはなりますが、結果的に問題を避けられます
特に銀行や重要なシステムでは、その不便を受け入れる価値は十分あります
この種の脅威状況は、私の職場ではすでにポリシーとして定着しています
インターネット上では何でも疑うのが良い慣行です
多くの中小企業やフリーランサーはいまだに MFA のようなものを使っておらず、使っていてもトークン窃取に簡単にやられます
そうしたアカウントが突破されると、本当に内部ユーザーから来たように見える悪意あるメールが飛んできます
ユーザー側から見ると本当に legit に見えます
だからメールは常に疑って扱うべきです
筆者は
"Here is the URL from that email [...] https://sites.google.com[...]";
このリンクこそが最初の red flag です
このポイントは三段落後ではなく、もっと冒頭で示すべきだったと思います
google.com のサブドメインをすべての人が知っているわけではありません
本当の問題点は（SSO の有効フィールドの問題に加えて）、Google がユーザーコンテンツをメインドメインのサブドメインで提供していることです
Drive のようなほかのサービスでも同様かもしれません
自分にとっては赤信号でも、うちの親にはそうではないかもしれません
全体として、メールセキュリティがどれほど脆弱なシステムかを示す事例だと思います
このフォーラムにはこれほど賢い人たちが集まっているのだから、こうした問題を一気に解決する代替案を出せるはずだと思います
Google も、こうしたサイトはメインドメインではなく hostedbygoogle.com のような分離ドメインで提供すべきです
なぜ今まで分けてこなかったのか不思議です
現実的に可能な代替案は、結局のところ、すべての統制権を単一企業に渡す仕組みになってしまいます
それでは、メールに残された主要な価値、つまり誰にも完全には支配されないシステムとしての価値を失ってしまいます
技術的な問題は十分解けますが、人間と利害関係の問題ははるかに難しいです
問題を解決する資源を持つ主体の多くは、完全にオープンなプラットフォームを作る動機がありません
金も支配権もすべて自分たちのものにならない限り、そのような努力はしないでしょう
逆に、すべての人が一社にすべての統制権を渡したいわけでもありません
これこそが技術的問題ではなくビジネス上の問題です
（メタバースで全サービスがアバターやアイテムを共有するのが事実上不可能なのもまったく同じで、技術的に不可能というより、権利者が絶対に認めない問題です）
Thiel が出資した新しいスタートアップ Shadowfax 発表！
私たちの安全で中央集権的な独占サービスは、AI・ブロックチェーンベースのレイヤーを搭載し、メールの古いシステムを置き換える予定です
すでに米国防総省の案件も獲得しており、2027年までに内外すべての連邦政府コミュニケーションの標準になる見込みです