ハクソク

世界を動かす技術を、日本語で。

GoogleがDKIMリプレイ攻撃で偽装された：技術的分析

289日前原文(easydmarc.com)

概要

  • 本記事は、Googleからの通知を装った高度なフィッシングメール事例の詳細な調査報告。
  • DKIMリプレイ攻撃によるメール認証のすり抜け手法を解説。
  • Google Sitesなど正規サービスを悪用した詐欺の危険性に言及。
  • 実際の攻撃フローや偽召喚状メールの特徴を具体的に説明。
  • 最後に、類似被害防止のための注意点・FAQも掲載。

Googleを装った偽召喚状メール：フィッシング攻撃の実態

  • 友人が受け取ったGoogleからの「召喚状通知」メールを精査した事例紹介。
  • メールは 正規のno-replyアドレス から届き、 文面や送信元ドメイン も正規に見える巧妙さ。
  • 不審な点 を感じたため、サンドボックス環境でメールヘッダーやリンクを精査。
  • SPF/DKIM/DMARC認証も すべて合格 しており、通常の判定では見抜けない偽装。
  • Google Sites を悪用した偽サポートページへ誘導する仕組み。

サンドボックスでの調査ポイント

  • メールヘッダーの SPF・DKIM・DMARC認証 結果の確認。
  • 不審なリンクの プレビュー やリダイレクト先の精査。
  • 添付ファイルやマクロ の有無、文法ミスの有無もチェック。

サイバー攻撃の進化

  • Google Sites など信頼性の高いインフラを悪用した偽ページ作成。
  • SSL証明書やブランド力 を利用し、ユーザーの警戒心を低下。
  • 自動化されたセキュリティチェック すらすり抜ける巧妙な設計。

DKIMリプレイ攻撃の手法と流れ

  • 攻撃者は Googleからの本物のメール を受信し、DKIM署名付きのまま保存。
  • そのメールを Outlookアカウント から送信し、 Jellyfish SMTP などのリレーサーバー経由でさらに転送。
  • Namecheap PrivateEmail などで新たなDKIM署名が追加されるが、元のGoogle DKIM署名は保持。
  • 最終的に Gmail受信箱 に到達した時点で、SPF/DKIM/DMARCすべて合格状態に。

DKIMリプレイ攻撃の特徴

  • メール本文・ヘッダー が改ざんされていないため、DKIM署名が有効。
  • SPFやDMARC もリプレイ時には無効化できない場合が多い。
  • 送信元が no-reply@google.com のまま、騙されやすい状況を作出。

偽召喚状メールの危険性と見分け方

  • 「召喚状」や「法的措置」など 緊急性・恐怖心を煽る 文面が特徴。
  • 本物の召喚状は 裁判所/弁護士/行政機関 から、正式な手続きを経て配達。
  • 個人への手渡し が原則で、メール送付は限定的かつ暗号化が必須。
  • 第三者サービス経由 や不審なリンクは要注意。

本物との違い

  • 正規の召喚状は 公式メールアドレス・暗号化 で送信。
  • Google Sites など、誰でも作れる無料サービス経由は不自然。
  • メールの ヘッダー情報・リダイレクト先 を必ず確認。

Google Sitesの悪用とセキュリティリスク

  • 無料・簡単 にサイト構築できる利便性が攻撃者に悪用される現状。
  • Google Workspace と連携し、公式ドメイン下に偽サイトを設置可能。
  • ブランド信頼・SSL証明書 による「正規感」を利用した詐欺。

Google Sitesの正規用途

  • 社内ダッシュボードやプロジェクト管理ページ
  • ドキュメント共有やイベント案内
  • ポートフォリオや学校課題提出など

攻撃再現：実際のインフラと手順

  • 攻撃者は Namecheap でドメインを取得し、 PrivateEmail を設定。
  • Google Workspace の無料トライアルでドメイン認証。
  • Google OAuthアプリ を作成し、通知メールの送信元を偽装。
  • Resent-From/Redirected-From ヘッダーで転送経路を隠蔽。
  • 被害者の受信箱には 本物と区別がつかないメール が届く。

よくある質問（FAQ）

  • Q: DKIMリプレイ攻撃とは？
    • 正規のDKIM署名付きメールを 再送信（リプレイ） し、認証をすり抜ける攻撃手法。
  • Q: SPFやDMARCで防げるか？
    • 完全には防げない。SPFは送信元IPとMAIL FROMの整合性のみ、DMARCは署名の整合性のみ確認。

フィッシング対策の基本

  • 不審なメールのリンクや指示には絶対に従わない こと。
  • 疑わしい場合はセキュリティ担当や専門家に相談、サンドボックス環境での検証推奨。
  • 不用意なクリックや返信は情報漏洩・乗っ取りのリスク。
  • 常に疑う姿勢 と 冷静な対応 が最良の防御策。

まとめ

  • 高度な認証技術を悪用したフィッシング が増加傾向。
  • Google Sitesや正規サービスの悪用 に要注意。
  • 緊急性を煽るメール は特に警戒し、即時対応せず、必ず正規手順で確認。
  • セキュリティ教育と情報共有 の重要性。

実際の被害事例やご質問があれば、ぜひ共有してください。

Hackerたちの意見

ステップ3: 攻撃者がOutlookからメールを送信する。受信ヘッダーにリストされたパスを偽装することはできないと思う。なぜなら、パス上のすべてのサーバーが自分の情報を追加するから。これがメールの出所を確認する方法で、これも見抜けたと思うと安心する。Googleからのメールは、Microsoftのサーバーを経由することはないよね。

└

ちょっと大胆に推測するけど、毎回のメールのヘッダーを手動でチェックしてるわけじゃないよね？Googleやその関連のメールだけでもないだろうし、何かフラグを立てたり可視化する方法はあるの？

└

最後の信頼できるサーバーのヘッダーを偽装することはできない、それだけだよ。

これは怖いね。親戚にこの投稿の教訓を説明しようとしたら、信頼できるドメインからのメールでも常に疑ってかかるべきだって…彼らの反応を想像するだけで気が滅入る。とはいえ、できることには限界がある。例えば、他の人のGmailアカウントからメッセージを偽造することはできないし。 > メッセージが転送されると、元のDKIM署名は通常そのまま残る。署名でカバーされているメールの内容やヘッダーが変更されない限り。To:ヘッダーがDKIM署名に含まれていないのは驚きだね。彼らは署名の設定を変えるべきだし、メールクライアントはメールが正当でも、受取人が変更されている可能性があると警告するべきだと思う。

└

常に疑ってかかれ、信頼できるドメインからのメールでも、dkim/dmarc/spfが全て通っても。 これは長い間、メールのデフォルトの状態だったし、今でも一部の人がメールに対して適用している注意レベルだね。「From」を決して信じるなって。

└

親戚にこの投稿の教訓を説明するのを想像してみて: 常に疑ってかかれ、信頼できるドメインからのメールでも、dkim/dmarc/spfが全て通っても。 親戚にdkim/dmarc/spfが何かを説明するのを想像してみて！これはすべて裏方の技術で、ユーザーが知っておくべきことじゃない。正直、この攻撃は思っているほど怖くないよ。記事は製品を売るために誤解を招いている。 > To:ヘッダーがDKIM署名に含まれていないのは驚きだね。実際、それはあまり重要じゃないと思う。Toヘッダーをどれくらいの頻度で読む？メールではToヘッダーに意図された受取人を含める必要はないことを忘れないで。

└

To: ヘッダーがDKIM署名に含まれていないのは驚きだね。実際には含まれているから、保存する必要があったんだよ。再現セクションの配信のスクリーンショットには、元のTo:アドレスが表示されている。これは配信先のアドレスではなくて、To:フィールドにどんなアドレスでも入れられるからね。

└

ここでのアドバイスはかなり標準的だよ：アクションが必要なメールを受け取ったら、直接ウェブサイトに行くこと。リンクはクリックしないで。手間はかかるけど、問題を解決するから。銀行やシステムに関しては、むしろ手間があった方がいい。

これはすごく混乱する内容だね。攻撃者がメールの本文を操作してフィッシングリンクを挿入した印象を与えるけど、実際にはその本文が操作された証拠は示されていない。むしろ逆のことを言ってる。私の理解では、DKIM署名にはメール本文のハッシュを含むbh=フィールドがある。技術的には、攻撃者が本文に追加できるようにするために、オプションのI=フィールドを含めることもできるけど、これはかなり大きなセキュリティホールだよね。Googleがそんな短いメールに対してI=を使うことはないと思う（no-reply@accounts.google.comからの自分のメールをいくつか確認したけど、I=はなかった）。だから、DKIMとDMARCを通過するためには、本文がそのままでなければならなかった。つまり、「フィッシングリンク」は実際にはGoogleからのもので、ただ別の受取人を意図していたってこと。私の分析が正しければ、TFAは怖いメールが間違った人に転送されたってことを言うために、たくさんの言葉を使ってるだけだね。もちろん怖いけど、「DKIMリプレイ攻撃」ってタイトルが示すほど技術的な人には怖くないと思う。編集: ああ、「The Takeaway?」がTFAの終わりだと思ったのは、彼らの製品のCTAがあったから。実際には、下にリンクがGoogleのOAuthアプリ名の一部で、それがGoogleのメールテンプレートに挿入されたことを説明する更新があるみたい。ひどい文章と構成で、攻撃の最も重要な部分を埋めてしまって、読者に恣意的な内容を送信できると誤解させてる。編集2: 他のコメント者が指摘したけど、メールのスクリーンショットが便利にカットされていて、Googleのメールテンプレートの固定部分が見えない。攻撃は見た目よりもさらに不器用かもしれないね。

└

同意する、この記事は意図的に誤解を招く内容だね。画像に示されているメールの部分が全体だと思わせるように書かれているけど、実際には誰でも疑念を抱くようなテキストが続いているはずだ。

└

そうだね、私の理解ではDKIMはちゃんとチェックされてるみたい。実際にGoogleから受け取ったメールをそのまま転送してるからね。本当の攻撃ベクトルは、Googleに自分がコントロールできるテキストのメールを送らせることなんだ。

おおお、やっと来た！！！数ヶ月前にほぼ同じメールを受け取ったんだけど、Googleドメインの管理者向けだったんだよね。もちろん、めっちゃ怖かったよ。リンクをクリックしないように我慢したけど、この詐欺に関する情報は全然見つからなかった。気づいたのは、全てのメールアドレスがマスクされていて、そのマスクが私が管理しているワークスペースのメールとは一致しなかったから。だけど、メール自体は本物だった。ググったら、テキストの部分が一致したし。私の場合は、故人のメールに関するメールだったから、もちろん現実とは合わなかった。でも、ある時点では、誰かが本当にGoogleを騙して私が亡くなったことにして、私のGoogleアカウントにアクセスしようとしているんじゃないかって、めっちゃ怖かった！

最近、私の受信箱でも似たような攻撃を見たよ。人々がGmail.comの代わりにyourgoogleaccount@google.comにメールを送って、その後Googleのメールサーバーからのバウンスをyourgoogleaccount@gmail.comに転送して、最後にスパムメッセージを忍ばせるってやつ。全てのチェックを通過するんだ。ポストマスターエラーがフィッシングキャンペーンと絡むのはちょっと変だけど、非技術的なユーザーには見過ごされがちだね。私の場合、フィッシングキャンペーンは私が建設用具に当選したって言ってきた。

└

ここ数週間、その手のメールが来てるから、Googleがメールを諦めたのかと思っちゃう。

実は、以前にFBIが私のGoogleアカウントの資料を押収したことがあるんだ。コンピュータハッキングで有罪になった時にね。捜索は2016年と2018年に行われて、2回目は全て持っていかれた。まあ、彼らはこんな風にはやらないよ。特定の部署にメールを送って、そのコミュニケーションを取るだけだから。気づかれないようにかなり手間をかけるんだ。

└

面白いね。そのリクエストって、どこかで記録されたりタグ付けされたりして、「あなたの」アカウントの全データに入ってくることってあるのかな？例えば、GDPRの「私のアカウントに関連するデータを全部見せて」みたいなリクエストで。

└

金曜日だし、君のコメントが最初に10%目を覚まさせてくれたよ。ぜひ、詳しく教えて！何かストーリーがあるに違いない…

私の意見では、ここでの本当の脆弱性は、Google OAuthアプリのアプリ名にURLを入れられることだと思う。そうすると、GoogleはそのURLを無返信メールで任意のアドレスに表示するんだ。（たとえその表示がクリックできなくても、周りのテキストが怖ければ、被害者はそこに行っちゃう。）DKIMを維持するための転送サービスがいくつも重なるのは二次的な問題だけど、教育的ではあるね。OAuthアプリのアプリ名にURL、特にgoogle.comを含める正当な理由はないはずだから、ここを修正すべきだと思う。

今のところ、メールのスパムで一番イライラするのは、メインストリームのクライアントがヘッダーをレビューするのをめっちゃ難しくしてることだね。

これに対する解決策を考えてるところだよ（GoogleやYahooの共著者がいるから、ちゃんとしたやつ）：https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva... ただし、これでGoogleがユーザー提供のテキストを含むメッセージを送るのを防げるわけじゃないけど、SMTPのFROM/TOが保護されてるから、Googleが意図しない形でリプレイされるのは防げるよ。モチベーションのドラフトには技術的な詳細は含まれてないから、関連する文書の初期ドラフトを見てみてね： https://datatracker.ietf.org/wg/dkim/documents/

└

ちぇ、データトラッカーには候補文書が載ってない。直接リンクをいくつか貼るね： https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/ https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header... https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi... https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce... https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...

└

これ、メーリングリストやグループでどう機能するんだろう？よくあるパターンは、例えばaccounts-payable@example.comへの第三者からのメールが、関連チームのメンバーに自動転送されることだよね。受け取る側のチームメンバーのシステムは、メーリングリストの転送者を「信頼」するように設定する必要があるのかな？それとも、元の受取人であるaccounts-payableが有効な受取人だと理解するために、どのリストにいるかを内部で追跡する必要があるのかな？

そうだよね、DKIM、DMARC、SPFとか色々あるのに、まだ危険なスパムメールが来るの？