送信元は本物のGoogle、リンク先も google.com の下、パスワードマネージャーまで自動入力を勧めてくる。見分けるための手がかりが、そろって「本物」と答えるフィッシングメールがXに投稿され、話題になっています。2025年に対策が表明された手口と外形は同じで、使われた通知だけが違って見えます。同じ形が繰り返される理由は、どこにあるのでしょうか。
Vincent Bounce氏は2026年10月1日、送信元がno-reply@accounts.google.comと表示され、Gmailで警告が出ないフィッシングメールを受け取ったとXに投稿した。メールは「アプリパスワードが作成された」というGoogleのセキュリティ通知の体裁で、本文中のリンクはGoogle Sites上のページに誘導していた。同氏によれば、リンク先はCAPTCHAで確認を装い、パスワードマネージャーが自動入力を提案した。メールの詳細に表示された「mailed-by」のドメインはfwd.privateemail.comだった。2025年4月にも、Googleが自動送信した通知を転送してGoogle Sitesへ誘導する手口が報告されている。
送信元はGoogleの正規アドレスで、Gmailは警告を出さず、リンク先のページもGoogleのドメイン（google.com）の下にあります。Vincent Bounce氏がXに投稿した報告は、そうした条件がそろったフィッシングメールでした。同氏は入力の手前で気づき、Googleに報告しています。
この「Googleの名前で届く偽の警告」は、突然現れたものではありません。2025年4月の同じ型の攻撃や、Google Sitesを使ったフィッシングは、innovaTopiaでも個別の記事として伝えてきました。今回届いたメールの画面と、Googleの公開資料、メール認証の仕様をつなぎ直し、なぜこのメールが本物として届くのか、どこで見抜けるのかを読み解きます。
Googleの名前で届くフィッシングの経緯
| 時期 | 出来事 | 関連記事／出典 |
|---|---|---|
| 2025年1月 | Google広告の表示URLを ads.google.com に見せ、実際の誘導先を sites.google.com に置く攻撃が報告される | Google Adsを狙う新たなフィッシング詐欺手法 ─ 正規ドメインを悪用したマルバタイジングに注意 |
| 2025年2月 | PayPalの「ギフト用住所」機能を悪用し、PayPal自身の送信サーバからフィッシング文面を届ける手口が報じられる | BleepingComputer |
| 2025年4月16日 | ENSの主任開発者ニック・ジョンソン氏が、Googleの署名つきで届いた偽の召喚状通知をXで報告 | Google OAuthを悪用したDKIMリプレイ攻撃が発生、Googleが対策中 |
| 2025年4月 | Googleが報道機関に対し、保護策を展開中で、この悪用経路を閉じると説明 | Newsweekほか |
| 2025年10月15日 | Googleが「再設定用の連絡先（Recovery Contacts）」を発表 | Google公式ブログ、Google「Recovery Contacts」発表｜ロックアウト時に友人が本人確認代行 |
| 2026年8月28日 | 転送の経路を署名に含める次世代規格「DKIM2」の草案、第6版が公開される | IETF |
| 2026年10月1日 | Vincent Bounce氏が、アプリパスワードの作成通知を装うメールをXで報告 | X |
届いたメールは何だったのか
見出しは「アプリパスワードが作成されました」
同氏が公開した画面によると、メールの件名は「Security alert」、見出しは「App password created to sign in to your account（アカウントにログインするためのアプリパスワードが作成されました）」です。Googleのロゴ、青い「Check activity」ボタン、2026年の著作権表示まで、Googleの通知と同じ体裁で並んでいます。
アプリパスワードとは、Googleのログイン画面を使えない古いメールソフトなどのために発行する、16文字の専用パスワードです。2段階認証を有効にしたアカウントでだけ使え、作成するときに利用者がアプリの名前を入力します。作成されると、Googleはそのアカウントのメールや再設定用のメールアドレスなどに通知を送ります。2025年には、Googleがロシア国家支援の可能性が高いと評価する攻撃者が、標的にアプリパスワードを作らせ、メールボックスへのアクセスを得た事例も報告されています（関連記事：Googleアカウント乗っ取り新手法、ロシア国家支援グループがMFA突破に成功）。
本文には、「このパスワードを生成した覚えがなければ、アカウントが侵害されているおそれがあります。https://sites.google.com/view/delete-new-app ですぐに確認し、削除してください」という趣旨の文が入っています。通知の定型文に、攻撃者が付けた「名前」が差し込まれた形に見えます。名前欄の文字列が通知の本文に取り込まれる仕組みなら、警告文やURLも、Googleが自動で送る正規の通知の中に収まる可能性があります。
宛先に表示されたのは、本文と同じアドレス
画面の宛先欄と、本文のアカウント表示には、同じGmailアドレスが表示されています。Vincent Bounce氏は、このメールを「見知らぬGmailユーザー」に関する警告だったと説明しています。このアドレスが同氏のものでないとすれば、攻撃者が自分のアカウントでアプリパスワードを作り、Googleから自分宛てに届いた通知を、そのまま第三者へ転送したと考えることで、宛先の表示が説明できます。
2025年4月のジョンソン氏の事例も、宛先は攻撃者が用意した「me@」で始まるアドレスでした。宛先の名前を「me（自分）」にしておくと、受け取った側には自分宛てのように見えるという工夫です。
リンク先は、二つの確認画面を思わせる偽ページ
本文のリンクを開くと、URLは sites.google.com/view/delete-new… で、ページには大きく「google.com」、その下に「Performing security verification（セキュリティ確認を実行中）」と表示されます。GoogleのreCAPTCHAに見えるチェックボックスと、「Ray ID」と書かれた識別番号も表示されています。Ray IDはCloudflareの確認画面にも表示される識別子です。今回の画面は、その見た目にreCAPTCHA風の表示を組み合わせたものに見えます。画面に表示されているだけで、これらのサービスが実際に動いているとは限りません。
同氏によれば、この確認を通過した先で、メールアドレスとパスワードの入力を求められます。
なぜ本物として届くのか
DKIM署名が有効でも、配送先の正当性は保証されない
メールのなりすましを防ぐ仕組みには、SPF、DKIM、DMARCの3つがあり、それぞれ確かめる対象が違います。SPFは配送に使われたドメインから送信が許可されているかを、DKIMは署名したドメインと署名対象の内容を、DMARCは画面に表示される送信元のドメインがそれらと整合しているかを確認します。このうちDKIMは、送信したドメインがメールに電子署名を付け、受け取った側が本文と、署名の対象に指定されたヘッダーが改ざんされていないことを確かめる仕組みです。
ところが、DKIMの署名は、そのメールが「実際に誰へ届けられたか」という配送上の宛先（エンベロープ）を対象にしていません。Googleが攻撃者宛てに送った通知は、本文と署名対象のヘッダーを変えずに再配送すれば、Googleの署名が有効なまま別の宛先へ届く場合があります。この性質は「DKIMリプレイ」と呼ばれ、DKIMの仕様書（RFC 6376）自体が第8.6節で取り上げている、古くから知られた課題です。
2025年の事例と同じ仕組みだとすれば、厄介なのは、署名が偽造されたのではなく、本物の署名がそのまま運ばれている点です。名前欄への差し込みという見立てが正しければ、文面を組み立てたのはGoogleのシステムで、攻撃者が書き込んだのは利用者として入力できる欄だけ、という構図になります。
Gmailの「認証済み」は、送り主がGoogleだという意味ではない
Gmailのヘルプは、メールの詳細に「Mailed by」と「Signed by」が表示されていれば、そのメールは認証済みだと説明しています。ただ、この表示は、それぞれのドメインについて認証が通ったことを示すものです。
同氏が見抜いた決め手は、この「Mailed by」でした。表示されたドメインは fwd.privateemail.com で、Googleのドメインではありませんでした。2025年のジョンソン氏の事例でも、署名は accounts.google.com でありながら、mailed-by には privateemail.com と表示されていました。署名ドメインと「Mailed by」のドメインの違いは、配送経路を調べる手がかりになります。ただし、正規の転送でも生じるため、この違いだけでは偽物と断定できません。
もう一つの手がかりとして、同氏は「Googleの通知なら、操作は大きな青いボタンで促し、本文中のリンクでは促さない」点を挙げています。今回のメールにも青いボタンはありますが、誘導先のURLは本文の文章の中に書かれていました。
2025年の対策と、今回の違い
2025年に対策が進められたのはOAuth通知の悪用
2025年4月の攻撃で使われたのは、外部アプリにGoogleアカウントへのアクセスを許可するOAuthの仕組みでした。攻撃者はOAuthアプリを作り、その「アプリ名」にフィッシング文面を丸ごと書き込んでいました（関連記事：Google OAuthを悪用したDKIMリプレイ攻撃が発生、Googleが対策中）。
Googleは当初、ジョンソン氏の報告を「意図した動作」として扱いましたが、その後に方針を改めました。Laptop Magが伝えるNewsweekへの声明によれば、Googleは「Rockfoils」という脅威アクターによる標的型攻撃を把握しており、1週間にわたって保護策を展開してきたこと、まもなく完全に展開されてこの悪用経路が閉じられることを説明しています。
今回の画面が示しているのは、OAuthではなくアプリパスワードの作成通知とみられます。特定の通知に手当てをしても、別の通知に利用者の入力した警告文やURLが取り込まれるなら、同様の悪用につながる可能性があります。問題の本質は、特定の機能の不具合というより、「利用者が入力した文字列を含む通知を、サービスが自分の署名で送る」という構造そのものにあります。
この構造はGoogleに限りません。2025年2月にはPayPalの「ギフト用住所」欄が、同じ目的で使われていると報じられました。同じPayPalでは、同年12月にサブスクリプション機能の通知が使われた例も報じられています。Appleの公式アドレスからiCloudカレンダーの招待を送らせる手口も報告されています（関連記事：iCloudカレンダーでPayPalフィッシング攻撃、Apple公式メールアドレス悪用の新手法）。2026年に入ってからは、Googleの「再設定用の連絡先」の依頼通知を使った例を、米国のIT保守事業者がブログで報告しています（関連記事：Google「Recovery Contacts」発表｜ロックアウト時に友人が本人確認代行）。
正規の仕組みを攻撃の入り口に使う流れは、メール以外にも広がっています。2026年3月には、MicrosoftやGoogleの認証画面の正規のリダイレクト機能を入り口に、マルウェアを配る攻撃をMicrosoftが報告しました（関連記事：Microsoft OAuth認証の正規リダイレクト機能を悪用、政府機関を標的にマルウェア配信）。
sites.google.com が選ばれる理由
誘導先がGoogle Sitesなのも、2025年と同じです。Google Sitesでは、利用者が作ったページを sites.google.com というGoogleのドメインの下で公開できます。ジョンソン氏は、このサービスがスクリプトや外部の埋め込みを使える点を、フィッシングの温床になりやすい理由として挙げていました。
Google Sitesは2025年1月にも、Google広告を狙った認証情報の窃取で誘導先に使われていました（関連記事：Google Adsを狙う新たなフィッシング詐欺手法 ─ 正規ドメインを悪用したマルバタイジングに注意）。
仕様の側でも、宛先を署名に含める作業が進む
DKIMリプレイを仕様の側で防ごうとする作業も進んでいます。IETFのDKIMワーキンググループが検討している次世代規格「DKIM2」は、メールが転送されるたびに署名を重ね、各段階の送信元と宛先（SMTPのMAIL FROMとRCPT TO）を記録する設計です。宛先が署名に入れば、Googleが攻撃者宛てに送ったメールを別人に転送したことを、受け取る側が見分けられるようになります。
2026年8月28日に公開された草案の第6版には、Yahoo、Fastmailの技術者とともに、Googleの技術者も著者に名を連ねています。メールの送り手の大手自身が、仕組みの穴を仕組みで塞ぐ側に立っています。草案はまだRFC（標準）になっておらず、メールサービスで広く使われるまでには時間がかかります。
パスワードマネージャーが候補を出した理由
同氏の報告で見落とせないのが、パスワードマネージャーが偽ページでメールアドレスとパスワードの自動入力を提案した、という点です。同氏はその理由を、sites.google.com で本物のアカウントを使っていたためと説明しています。
「自動入力の候補が出ないサイトは偽物を疑う」という見分け方はよく勧められます。ただ、パスワードマネージャーが候補を出すかどうかは、主にページのドメインやホスト名で決まります。sites.google.com で正規に使った認証情報が保存されていれば、同じ sites.google.com 上にある偽ページでも候補が出ます。さらに、保存したURLと同じドメインの別のページでも候補を出す製品もあります。たとえばBitwardenは、既定の照合方法を「ベースドメイン」としており、google.com で保存したパスワードは、sites.google.com のようにドメインの後半が同じページでも候補になります。同氏が使っていた製品は明らかにされていません。
sites.google.com は本物のGoogleのドメインであり、誰でもページを公開できる場所でもあります。ホスト名やドメインで照合する設定では、そこに置かれた偽ページと正規のページを区別できません。自動入力の候補は、偽物を見抜く手がかりとしては働きませんでした。
最後に効く防御
同じ声明でGoogleは、対策が行き渡るまでのあいだ、2段階認証とパスキーを使うよう利用者に勧めていました。今回のような攻撃に対して、パスキーは理にかなった備えです。パスキーは、登録したサービスのドメインと結び付いた鍵でログインする仕組みで、パスキーでログインするときは、パスワードを打ち込む必要がありません。Googleのヘルプによれば、パスキーを追加しても既存のパスワードは残り、パスワードでのログインも引き続き選べます。それでも、パスキーでのログインを習慣にしておけば、パスワードを求める画面そのものが「いつもと違う」合図になります。
日々の操作で取れる対策は、メールのリンクからではなく、ブラウザに自分で myaccount.google.com と入力してアカウントの状態を見ることです。Googleの正規のログイン画面は accounts.google.com にあります。sites.google.com は、利用者が自分で作るページの置き場所です。アプリパスワードの作成通知が届いて心当たりがなければ、同じく自分で開いたアカウントのページで、アプリパスワードの一覧を確かめられます。
Googleの名前で届く通知は、これからもGoogleアカウントを使うすべての人の受信箱に届き続けます。その通知が信頼できるものであり続けるために、サービスの側では2025年の保護策や、署名の仕組みそのものの見直しが進められてきました。利用者の側でできるのは、通知のリンクを入り口にしない習慣と、パスワードを打たないログインへの移行です。両者がそろったとき、「本物の署名をまとった偽物」は、届いても役に立たないものになっていきます。
【参考記事】
Phishers abuse Google OAuth to spoof Google in DKIM replay attack（外部）
2025年4月の事例の報道。OAuthアプリ名に文面を入れて正規の通知を転送する手順と、Googleの方針転換を伝える。
How phishing emails are sent from no-reply@accounts.google.com（外部）
Kasperskyによる同じ事例の解説。署名者がGoogleと表示される理由と、Google Sitesが悪用される背景を説明する。
Beware: PayPal Subscriptions abused to send fake purchase emails（外部）
2025年12月、PayPalのサブスクリプション機能の通知に、偽の購入文面が入った事例を報じた記事。正規の送信元から届いた。
New phishing attack fooling Gmail’s security（外部）
GoogleがNewsweekに出した2025年4月の声明を引用し、保護策の展開と、2段階認証・パスキーの推奨を伝える記事。
【編集部後記】
2025年6月、Googleの脅威インテリジェンスグループは、アプリパスワードを悪用した攻撃の報告の中で、対策の一つとして作成時の通知を挙げていました。本人が意図して作ったのかを確かめるため、Gmailや再設定用のメールアドレスに知らせる仕組みです。
今回のメールが推定どおりなら、その確認のための通知が、そのまま偽の警告の器になったことになります。守るために送られる知らせほど、受け取る側は疑わずに開きます。通知の信頼そのものが攻撃の資源になるとき、送る側は何を基準に文面を組めばよいのでしょうか。
【用語解説】
アプリパスワード
Googleのログイン画面を使えない古いメールソフトなどのために発行する、16文字の専用パスワード。2段階認証を有効にしたアカウントでだけ作成でき、作成時にアプリの名前を入力する。作成されると、Googleはアカウントのメールなどに通知を送る。
2段階認証
パスワードに加えて、スマートフォンへの確認など2つ目の手段で本人を確かめるログイン方式。
DKIM（DomainKeys Identified Mail）
送信したドメインがメールに電子署名を付け、受信側が本文と署名対象のヘッダーの改ざんを確かめる仕組み。仕様はRFC 6376。
DKIMリプレイ
DKIMの署名が付いたメールを、本文と署名対象のヘッダーを変えずに別の宛先へ再配送し、署名が有効なまま届ける手口。
エンベロープ
メールの配送で使われる、実際の送信元と宛先の情報。画面に表示される差出人や宛先とは別に扱われる。
SPF（Sender Policy Framework）
配送に使われたドメインから、そのサーバが送信を許可されているかを確かめる仕組み。
DMARC（Domain-based Message Authentication, Reporting and Conformance）
画面に表示される送信元のドメインが、SPFやDKIMで確かめたドメインと整合しているかを確認する仕組み。
OAuth
パスワードを渡さずに、外部のアプリへアカウントへのアクセスを許可する仕組み。
DKIM2
IETFで検討中の、DKIMの次世代規格。転送のたびに署名を重ね、各段階の送信元と宛先を記録する設計。2026年8月時点で草案の段階にある。
パスキー
登録したサービスのドメインと結び付いた鍵でログインする方式。パスワードを入力せずに、端末の生体認証やPINで本人を確かめる。
ベースドメイン照合
パスワードマネージャーの照合方法の一つ。ドメインの後半が同じなら、別のホスト名のページでも保存した認証情報を候補に出す。
Ray ID
Cloudflareが確認画面などに表示する、リクエストごとの識別子。
IETF（Internet Engineering Task Force）
インターネットの技術標準を作る団体。
RFC（Request for Comments）
IETFが発行する技術文書。標準の仕様として扱われるものを含む。
【参考リンク】
X｜Vincent Bounce氏の投稿（2026年10月1日）（外部）
アプリパスワードの作成通知を装うフィッシングメールを受け取ったとする報告。メール画面とリンク先のページの画像を添付している。
Google アカウント ヘルプ｜アプリ パスワードでログインする（外部）
アプリパスワードの仕組みと作成・削除の手順、利用できる条件を説明するGoogleの公式ヘルプ。不要なものはここから削除できる。
Google アカウント ヘルプ｜パスキーでログインする（外部）
Googleアカウントでパスキーを使う方法の公式ヘルプ。パスキーを追加しても、既存のパスワードは残ることを説明している。
Gmail Help｜Check if a message is authenticated（外部）
Gmailでメールの詳細を開き、「Mailed by」と「Signed by」の表示から認証の状態を確かめる方法を説明する公式ヘルプ。
Google サイト ヘルプ｜独自ドメインでサイトを公開する（外部）
Google Sitesで作ったサイトを、sites.google.com以外の独自ドメインで公開する方法の公式ヘルプ。
Google Cloud Blog｜What’s in an ASP? Creative Phishing Attack on Prominent Academics and Critics of Russia（外部）
Googleの脅威インテリジェンスグループによる2025年6月の報告。アプリパスワードを悪用した攻撃と作成時の通知を説明する。
Google 公式ブログ｜Recovery Contacts（外部）
2025年10月15日に発表された「再設定用の連絡先」機能の公式発表。信頼できる人にアカウント復旧時の本人確認を頼める。
IETF｜DomainKeys Identified Mail Signatures v2（DKIM2）第6版（外部）
DKIMの次世代規格の草案で、2026年8月28日に公開された第6版。転送の各段階の送信元と宛先を、署名に記録する設計を示す。
RFC Editor｜RFC 6376 DomainKeys Identified Mail（DKIM）Signatures（外部）
DKIMの仕様書。署名の対象と検証の手順を定めており、第8.6節では署名済みのメールを再送するリプレイの問題を扱っている。
Bitwarden ヘルプ｜URI一致検出（外部）
パスワードマネージャーBitwardenの照合方法の説明。既定はベースドメイン照合で、ホスト名や完全一致にも変更できる。
Cloudflare Docs｜Turnstile feedback reports（外部）
Cloudflareの公式ドキュメント。確認画面の不具合を報告する方法と、その際に画面に表示されるRay IDの扱いを説明している。
