Googleの本物のログイン画面を中継するBiTMフィッシング　パスワード・2FAコード・認証済みセッションを窃取

NordVPNのThreat Intelligenceチームが、Googleの正規ログイン画面を攻撃者側のブラウザで実行し、その画面を被害者へリアルタイムに中継するフィッシング基盤を確認したと、Hackreadが2026年9月8日に報じました。

この攻撃では、一般的な「Googleそっくりの偽ログインページ」を表示するだけではありません。攻撃者が管理するブラウザ上で実際のGoogleサインイン処理を動かし、被害者の操作を中継するBrowser-in-the-Middle（BiTM）型の仕組みが使われています。

被害者が入力したパスワードや2段階認証（2FA）コードは攻撃者側を経由し、認証成功後のセッションも攻撃者が利用できる可能性があります。そのため、SMSやTOTPなどのワンタイムコードを使うMFAを有効にしていても、リアルタイム型フィッシングでは防げない場合があります。

なお、今回のキャンペーン固有の解析結果はNordVPNがHackreadへ共有したもので、9月9日時点ではNordVPN自身が公開した詳細な一次調査レポートを確認できませんでした。本記事では、キャンペーン固有の事実はHackreadへの帰属を明示し、攻撃方式と対策についてはNordVPN、Google、CISAの公開一次情報で補足しています。

Googleログインを中継するBiTMフィッシングのサマリー

確認できている内容：

• Hackreadは2026年9月8日、NordVPNのThreat IntelligenceチームがGoogleアカウントを狙うBiTM型フィッシング基盤を確認したと報じました。
• 攻撃の誘導には、Google Voiceのボイスメール通知を装ったメールが使われていました。
• NordVPNの調査では、侵害された正規メールアカウントからフィッシングメールが送られるケースが確認されています。
• 当初はCEOや経営層が主な標的として確認されましたが、その後は他の企業従業員にも対象が広がっていました。
• 被害者がアクセスすると、攻撃者が管理するブラウザ上で実行されるGoogleの正規ログイン画面がリアルタイムに中継されます。
• パスワード、2FAコード、Google側から返される認証画面などが攻撃者側を経由します。
• 認証成功後のセッションも攻撃者が利用できるため、ワンタイムコードだけでは防げない可能性があります。
• 攻撃基盤には、オペレーターが被害者の進行状況を監視・操作できる管理パネルが確認されています。
• セッショントークンにはキャンペーンIDやプロジェクトIDが含まれ、NordVPNはPhishing-as-a-Service（PhaaS）として利用されている可能性を指摘しています。
• 自動解析を妨げる目的でCloudflare Turnstileが利用されていました。
• 同じインフラでは、ブラウザ通知を許可させる別のプッシュ通知詐欺も確認されています。
• 今回の事案はGoogleの認証基盤が侵害されたことを意味しません。Googleの正規ログイン処理を攻撃者側から中継する手口です。

現時点で確認できない内容：

• 攻撃者・脅威アクターの身元
• キャンペーンの正式名称
• 被害組織数・被害アカウント数
• 日本企業への具体的な被害
• 攻撃開始時期
• フィッシング基盤の運営者と利用者の関係
• 侵害されたメールアカウントの総数
• Google Workspaceと個人Googleアカウントの被害内訳

項目	内容
公表	Hackread、2026年9月8日
調査主体	NordVPN Threat Intelligence
攻撃手法	Browser-in-the-Middle（BiTM）型フィッシング
誘導	Google Voiceのボイスメール通知を装うメール
送信元	侵害された正規メールアカウントを利用した事例を確認
標的	当初はCEO・経営層、他の企業従業員にも拡大
窃取対象	パスワード、2FAコード、認証済みセッション
Googleの侵害	確認されていません
PhaaS	管理パネルやキャンペーン識別情報から利用可能性を指摘
解析回避	Cloudflare Turnstileを利用
攻撃者帰属	確認されていません
推奨対策	パスキー、FIDO2セキュリティキーなどフィッシング耐性認証

偽のGoogle画面ではなく「本物のGoogleログイン」を中継

従来型のフィッシングでは、攻撃者がGoogleのログイン画面をコピーし、偽サイト上へ再現する手法が一般的です。

今回NordVPNが確認した方式は異なります。

Hackreadによると、被害者のブラウザに見えているGoogleログイン画面は、攻撃者が管理するブラウザ上で動作している正規のGoogleサインイン処理をリアルタイムに中継したものです。

大まかな流れは次のように整理できます。

1. 被害者がフィッシングメールのリンクを開く
2. 攻撃者側のブラウザでGoogleの正規ログイン画面が開く
3. その画面が被害者側へリアルタイムに中継される
4. 被害者がメールアドレス・パスワードを入力する
5. 入力内容が攻撃者側を経由してGoogleへ送られる
6. Googleが2FAを要求すると、その画面も被害者へ中継される
7. 被害者が2FAコードを入力する
8. 認証が成立すると、攻撃者側のブラウザに認証済みセッションが残る可能性がある

この構造では、被害者から見える画面の内容自体はGoogleが返した正規の画面である場合があります。

そのため、「ロゴやデザインが本物か」「ログイン画面の見た目がおかしくないか」だけでは見破りにくくなります。

Browser-in-the-Middle（BiTM）とは

Browser-in-the-Middleは、攻撃者が管理するブラウザを被害者と正規サービスの間に置き、画面や入力操作をリアルタイムに中継するフィッシング手法です。

一般的なAdversary-in-the-Middle（AiTM）型フィッシングでは、攻撃者のリバースプロキシが被害者と正規サービスのHTTP通信を中継します。

BiTMでは、攻撃者側で実際のブラウザセッションを動かし、そのブラウザの表示や操作を被害者側へ転送します。

どちらも、

• 正規サイトの認証画面をリアルタイムに利用する
• パスワードを中継する
• MFA認証を中継する
• 認証済みセッションを奪う

という目的は共通しています。

一方、実装方式は同じではありません。

関連記事：中間者攻撃(AiTM攻撃)とは？多要素認証で防げない理由と対策を解説

Browser-in-the-Browser（BitB）とは別の手法

BiTMと似た用語にBrowser-in-the-Browser（BitB）があります。

BitBは、Webページの中に「ブラウザのポップアップ画面そのもの」をHTMLやCSSで偽装して表示する手法です。

たとえば、GoogleのSSOポップアップに見える枠、アドレスバー、鍵アイコンまで偽造して、本物のログインウィンドウのように見せます。

一方、今回報告されたBiTMは、攻撃者側の実ブラウザで正規Googleの処理を動かし、それを中継します。

手法	主な特徴
従来型フィッシング	正規ログイン画面をコピーした偽ページ
BitB	ブラウザ内に偽のログインポップアップを描画
AiTM	リバースプロキシなどで認証通信をリアルタイム中継
BiTM	攻撃者側のブラウザを動かし、画面・入力をリアルタイム中継

企業の利用者教育では、これらをすべて識別させることより、「メール内リンクから認証しない」「認証先の実URLを確認する」「フィッシング耐性MFAへ移行する」といった共通対策へ落とし込む方が運用しやすくなります。

Google Voiceのボイスメール通知を装って誘導

Hackreadによると、今回確認されたフィッシングメールはGoogle Voiceのボイスメール通知を装っていました。

受信者には「新しいボイスメールが届いた」と思わせ、確認用リンクをクリックさせます。

ボイスメール通知は企業でも違和感が生じにくい題材です。

• 営業電話
• 顧客からの連絡
• 採用候補者
• 取引先
• 海外拠点

などの連絡と思わせれば、受信者がリンクを開く可能性があります。

セキュリティ対策Labでも、Googleの正規通知やボイスメールを装うフィッシングを過去に扱っています。

関連記事：Googleの正規通知を装うフィッシングが拡大-「noreply」から大量送信

侵害された正規メールアカウントから送信

今回の調査では、フィッシングメールの一部が侵害された正規メールアカウントから送信されていました。

この場合、送信元ドメインだけを見れば正規です。

正規のメールサーバーを使って送信されれば、

• SPF
• DKIM
• DMARC

などのメール認証を正常に通過する場合があります。

SPF、DKIM、DMARCは送信元ドメインのなりすましを防ぐための仕組みであり、「正規アカウントそのものが乗っ取られて悪用されているか」を判定する仕組みではありません。

そのため企業のメールセキュリティでは、認証結果に加えて、

• URLの新規性
• 通常と異なる送信パターン
• メール本文の内容
• 利用者の行動
• 送信アカウントの異常ログイン

などを見る必要があります。

当初はCEO・経営層、その後は一般従業員も標的

NordVPNのThreat Intelligenceチームは、調査当初、CEOや経営層が主な標的になっていると確認しました。

その後、Hackreadによると、フィッシングメールは経営層だけでなく、他組織の従業員にも送られていました。

経営層のGoogleアカウントが侵害された場合、

• Gmail
• Google Drive
• Google Calendar
• Google Contacts
• Google Workspace上の共有文書

などへアクセスされる可能性があります。

また、経営者のメールアカウントは、取引先や社内従業員を狙うBEC（Business Email Compromise）の起点として悪用される可能性もあります。

ただし、今回のキャンペーンで実際にどのGoogleサービスからデータが窃取されたか、BECへ発展したかは公表されていません。

ワンタイム2FAコードを入れても防げない理由

SMSや認証アプリのTOTPは、パスワードだけの認証より安全です。

しかし、リアルタイム型フィッシングでは、被害者が入力したコードを攻撃者がその場で正規サービスへ中継できます。

ワンタイムコードの有効時間内に使われれば、攻撃者側のブラウザで認証が成立します。

さらに今回のBiTMでは、認証成功後のブラウザセッションが攻撃者側に存在します。

このため、攻撃者は毎回パスワードや2FAコードを再入力しなくても、認証済みセッションを利用できる可能性があります。

Google自身も、SMSコードなど一般的な2段階認証より、パスキーやセキュリティキーをより強いフィッシング対策として案内しています。

セッションを奪われるとパスワード変更だけでは不十分な場合がある

リアルタイム型フィッシングでは、認証後のセッションが攻撃者側に残る可能性があります。

そのため、利用者から「フィッシングサイトに入力した」と申告があった場合、パスワード変更だけで対応を終了しない方が安全です。

Googleは、アカウント侵害が疑われる場合、

• 最近のセキュリティイベントを確認する
• ログイン中のデバイス・セッションを確認する
• 心当たりのないセッションからログアウトする
• パスワードを変更する
• 回復用情報やセキュリティ設定の不審な変更を確認する

よう案内しています。

Google Workspace管理者は、ユーザーのセッションCookieに関する不審なイベントをAudit and Investigation ToolやSecurity Investigation Toolで確認できます。

Googleは「User signed out due to suspicious session cookie」というイベントも提供しています。

人間がリアルタイムに操作する管理パネル

Hackreadによると、NordVPNは攻撃基盤にオペレーター向けの管理パネルを確認しました。

オペレーターは被害者の認証進行を監視し、

• パスワード誤入力
• 追加のセキュリティ確認
• 想定外の認証画面

などが表示された場合に、人間が対応できる構造になっていました。

この点は、単純な自動フィッシングキットとは異なります。

攻撃者側がリアルタイムに被害者の画面遷移へ追従できるため、認証フローが利用者ごとに変化しても攻撃を継続しやすくなります。

PhaaSとして提供されている可能性

NordVPNは、セッション情報にキャンペーンIDやプロジェクトIDが含まれていたことなどから、この基盤がPhishing-as-a-Service（PhaaS）として複数の攻撃者に提供されている可能性を指摘しています。

PhaaSでは、フィッシング基盤の開発者と、実際に標的へメールを送る攻撃者が別になる場合があります。

利用者側は、

• フィッシングページ
• 認証中継機能
• 被害者管理パネル
• セッション管理
• 解析回避

などを自前で開発せずに攻撃を実行できます。

ただし、今回のサービス名、運営者、販売経路、料金体系などは公表されていません。

Cloudflare Turnstileを解析回避に利用

NordVPNは、攻撃基盤がCloudflare Turnstileを使って自動解析を妨げていたと説明しています。

Turnstile自体は、Webサイトがボットや自動アクセスを判定するための正規サービスです。

今回の事例では、その機能がセキュリティ研究者や自動サンドボックスからフィッシング基盤を見えにくくするために利用されていました。

Hackreadによると、NordVPNが自動アクセスを試みた際にはTurnstileによってブロックされたケースがありました。

これはCloudflareのサービスが侵害されたという意味ではありません。正規のボット対策機能が攻撃者側の解析回避に転用されたものです。

同じ基盤でプッシュ通知詐欺も確認

NordVPNは同じインフラ上で、Googleアカウント窃取とは別のプッシュ通知詐欺も確認しています。

被害者には「Subscription confirmed」などの画面を表示し、ブラウザ通知を許可させます。

Hackreadによると、画面には「22,726 subscribers」という固定値が表示されていました。

利用者が通知を許可すると、その後もブラウザ経由で攻撃者から通知を送れるようになります。

この機能はGoogleアカウント窃取と同じ目的とは限りません。

同一の攻撃インフラを複数の詐欺・フィッシング用途へ再利用している可能性を示す要素として扱う必要があります。

Google自体が侵害されたわけではない

今回の見出しだけを見ると、「Googleのログインページがハッキングされた」と受け取る可能性があります。

しかし、確認されている攻撃はGoogleの認証サーバーへ侵入するものではありません。

攻撃者は、

• 被害者を自分たちのサイトへ誘導
• 攻撃者管理ブラウザから正規Googleへ接続
• Googleが返したログイン画面を中継
• 被害者の入力を攻撃者側経由でGoogleへ送信

しています。

問題はGoogleのログイン画面の脆弱性ではなく、利用者とGoogleの間に攻撃者側ブラウザを介在させるソーシャルエンジニアリングです。

BiTM型PhaaSは今回が初めてではない

Browser-in-the-Middleを利用したPhaaSは、今回初めて確認された手法ではありません。

Netcraftは2026年6月、「Bluekit」と呼ばれるPhaaSを分析し、BiTMを利用する攻撃基盤が実際に運用されていることを確認しています。

Netcraftは、Bluekitが被害者のブラウザ操作をリアルタイムに攻撃者側へ中継し、従来のAiTM型リバースプロキシとは異なる実装を採用していると報告しました。

Bluekitと今回NordVPNが確認した基盤が同一であるとの情報はありません。

別の事例として、BiTMが実運用されるフィッシング手法になっていることを示しています。

対策は「MFAを入れる」から「フィッシング耐性MFAへ移行する」

今回の攻撃では、MFAそのものを破るのではなく、利用者に正規の認証操作を実行させ、その結果を中継します。

そのため、SMSコードやTOTPなど、利用者が入力できる秘密情報は中継される可能性があります。

CISAは、フィッシング耐性MFAとしてFIDO/WebAuthnを推奨しています。

Googleも、Googleアカウントの保護策としてパスキーやハードウェアセキュリティキーを案内し、セキュリティキーを「最も安全な確認方法」としています。

パスキーやFIDO2セキュリティキーは、認証先ドメインと暗号学的に結び付いているため、攻撃者のフィッシングサイトへ認証情報を渡しにくい仕組みです。

関連記事：パスキーとは？メリットや概要を解説

経営層・IT管理者にはGoogle Advanced Protectionも選択肢

Googleは、標的型攻撃を受けるリスクが高い利用者向けにAdvanced Protection Programを提供しています。

Googleが対象例として挙げているのは、

• ジャーナリスト
• 活動家
• 政治キャンペーン関係者
• ビジネスリーダー
• IT管理者

などです。

Advanced Protectionでは、サインイン時にセキュリティキーまたはパスキーを要求します。

今回のように経営層が標的となるキャンペーンでは、一般従業員と同じ認証ポリシーだけでなく、高リスクアカウントを別枠で強化する方法があります。

Google Workspace管理者が確認したいログと設定

Google Workspaceを利用している企業では、フィッシング教育だけでなく、管理側で侵害を検知・封じ込められるかを確認します。

主な確認項目は次のとおりです。

• Google WorkspaceでMFAを必須化しているか
• CEO、役員、IT管理者へパスキー・セキュリティキーを優先導入しているか
• 新しいデバイス・ブラウザからのログインを監視しているか
• 通常と異なる国・地域・IPからのサインインを検知できるか
• 不審なセッションCookieイベントを調査できるか
• 心当たりのないセッションを即時失効できるか
• パスワード変更時に既存セッションの扱いを確認しているか
• Gmailの転送設定・フィルタ・委任設定の不正変更を確認できるか
• OAuthアプリや新しい認証方法の追加を監視しているか
• 侵害時にGoogle DriveやGmailへのアクセス履歴を追跡できるか

Google Workspaceのエディションによって利用できる調査機能は異なります。

自社の契約でSecurity Investigation ToolやAudit and Investigation Toolのどこまで利用できるかを事前に確認します。

メール認証を通ったメールも安全とは限らない

今回のフィッシングでは、侵害された正規アカウントが送信に使われています。

このため、

「SPF・DKIM・DMARCがPassなので安全」

という判断はできません。

企業のメールセキュリティでは、

• 正規アカウントからの異常送信
• 新規・低評価URL
• Google Voiceなど業務上もっともらしい誘導
• ログインを要求する外部リンク
• 同一文面の短時間大量配信

などを組み合わせて検知します。

関連記事：フィッシング詐欺とは? 手口や対策を解説

フィッシングに入力した場合の初動

利用者がGoogleのID、パスワード、2FAコードを入力してしまった場合は、パスワード変更だけで終わらせません。

確認する順序の例は次のとおりです。

1. 影響アカウントをインシデントとして扱う
2. 心当たりのないセッション・デバイスをログアウトする
3. パスワードを変更する
4. MFA・パスキー・回復手段の不審な追加を確認する
5. Gmailの転送設定・フィルタ・委任を確認する
6. OAuthアプリ・サードパーティアクセスを確認する
7. Google Drive・Gmailなどの監査ログを調査する
8. 不審なメール送信がないか確認する
9. 同じパスワードを他サービスで利用している場合は変更する
10. フィッシング耐性MFAへ移行する

Google公式も、アカウント侵害が疑われる場合には、最近のセキュリティイベント、ログイン中デバイス、パスワード、回復情報などを確認するよう案内しています。

情報システム部門への示唆

今回の攻撃は、「MFAを導入済みならフィッシング対策は完了」という前提が成り立たないことを示す事例です。

企業では次を確認できます。

• MFA導入率ではなく、MFA方式別の利用者数を把握しているか
• SMS、TOTP、プッシュ通知からパスキー・FIDO2へ移行する計画があるか
• CEO・経営層・IT管理者など高リスクアカウントを優先できるか
• Google Workspaceのセッションを管理者側から失効できるか
• 不審なセッションCookieをログで検知できるか
• 正規アカウントから送信されたフィッシングを検知できるか
• メール認証結果だけで安全判定していないか
• Google Voiceやファイル共有通知を装うメールから直接ログインさせない教育を行っているか
• 認証はブックマークや公式アプリから開始するよう案内しているか
• 利用者から「2FAまで入力した」と報告された場合のRunbookがあるか
• セッション窃取を想定してパスワード変更以外の初動を定義しているか
• OAuthアプリ、パスキー、回復情報の不審な追加を確認する手順があるか

MFAは依然として有効なセキュリティ対策です。

ただし、入力可能なワンタイムコードはリアルタイム型フィッシングで中継される可能性があります。

Google Workspaceを業務基盤として使う企業では、「MFAを有効化しているか」から、「どの認証方式を使い、認証済みセッションをどのように監視・失効できるか」まで確認範囲を広げる必要があります。

出典

• Hackers Stream Real Google Login Pages to Steal Passwords and 2FA Codes – Hackread
• Adversary-in-the-middle (AitM) phishing attack explained – NordVPN
• Sign in with a passkey instead of a password – Google Account Help
• Make your account more secure – Google Account Help
• Get Google’s strongest account security with the Advanced Protection Program – Google Account Help
• Secure a hacked or compromised Google Account – Google Account Help
• See devices with account access – Google Account Help
• Investigate and take action on suspicious session cookies – Google Workspace Admin Help
• Implementing Phishing-Resistant MFA – CISA
• Bluekit Phishing-as-a-Service: Browser-in-the-Middle, Evolved – Netcraft