Google信頼ドメインを多段リダイレクトに悪用する大規模フィッシング：ゲートウェイ設計の盲点を突く検知回避です

今日の深掘りポイント

• Google SearchやGoogle Meetなど、信頼ドメインの正規リダイレクトを中継として悪用し、リンク検査をすり抜ける手口が確認されています。
• リダイレクト終端ではブランド偽装の資格情報収集ページが展開され、場合によってはScreenConnectの導入まで誘導するシナリオが示唆されています。
• URLフラグメント（#以降）に個別のメールアドレスなどを埋め込み、プロキシやゲートウェイの静的検査から意図的に隠す工夫が見られます。
• 企業の「大手クラウド・ドメインは原則許可」という運用前提が逆手に取られており、メールゲートウェイやURLフィルタの再設計が求められます。
• 直近リスクが高く、対処可能性もあるテーマです。検知・ブロックの強化だけでなく、ID・端末・RMM統制の多層で防御差を作るのが鍵です。

はじめに

信頼できるはずのクラウド基盤が、攻撃者の「目くらまし」に転用される時代です。Googleの正規ドメインを踏み台にした多段リダイレクトは、リンクベース検知やドメイン許可リストの“甘い前提”を突き、ユーザーを静かに目的地へと運びます。最終地点が資格情報搾取か、さらに一歩踏み込んでRMMの導入か。いずれにせよ、初動で見逃すと「いつもの業務フロー」のまま侵害が成立してしまいます。今日は、技術の細部よりも運用の前提に潜む盲点を洗い出し、明日から変えられる設計変更に落とし込む視点を重視して整理します。

深掘り詳細

事実関係（報道ベース）

• 大規模なフィッシングがGoogleインフラ（Google SearchやGoogle Meetの正規リダイレクト機構など）を経由し、最終的に攻撃者の管理下にあるフィッシングページへ誘導する手口が報告されています。ブランド偽装（Microsoft 365やFedExなど）を伴い、資格情報の搾取が目的です。URLフラグメントの活用により、受信者固有情報の引き回しや検査逃れが行われるとされています。さらに一部ケースでは、最終的にScreenConnect（ConnectWise Control）の導入へ至る流れが示唆されています。
  参考リンクの報告を基礎情報としています（本文末の参考情報を参照ください）。

• これらのリンクは「見かけ上はGoogleドメインのURL」から始まるため、受信者の心理的抵抗を下げ、またメールゲートウェイやセーフリンク類の「大手クラウド・ドメインを寛容に扱う」運用の穴を突く格好になります。
  出典: GBHackersによるキャンペーン報告

インサイトと運用への示唆

• 信頼ドメインはもはや“無条件の通行証”ではないです。リダイレクトの多段化により、静的なURL審査は形骸化しがちです。クリック時解析（time-of-click）で最終到達先を評価する仕組みと、正規ドメイン配下の「リダイレクト器」に対するグレートラスト（半信頼）運用が必要です。
• URLフラグメント（#以降）はHTTPトランザクションに送信されないため、メールゲートウェイや多くのプロキシでは“見えない”ことが多いです。攻撃者はここに個別識別子やメールアドレスを埋め込み、フロントエンドJavaScriptでフォームを自動補完して“本物らしさ”を高めます。対抗には、エンドポイント側のブラウザテレメトリと組み合わせ、クリック後の実到達URL・DOM変化を観測するアプローチが効きます。
• リダイレクト技術そのものは脆弱性ではなく正規機能です。だからこそ、“機能の悪用”に分類され、検知・ブロックの設計責任は企業側に残ります。大手クラウドの可用性と利便性を損なわずに「リダイレクトの終端」を厳格に判定できるかが運用の勝負どころです。
• 本件のメトリクスからは、短期的な顕在化可能性と、既存対策の回避優位（＝検知難度の上昇）が読み取れます。一方で、対処可能性も高い領域です。URL・ID・端末・RMM統制を束ね、可視化とブロックの“面”を作れば、損害を実用的な水準に収められます。現場では「Googleなど大手ドメイン由来リンクの扱い定義を更新できているか」を、最優先で棚卸しすべきです。

脅威シナリオと影響

想定される代表的なシナリオ（いずれも仮説を含みます）です。

• シナリオA：資格情報搾取で終わる短期侵害

  1. ブランド偽装メールのリンクがGoogleドメインの正規リダイレクトを経由。
  2. 終端で組織名・ロゴが最適化された偽ログインを提示、URLフラグメントからユーザー識別子を自動充填。
  3. 搾取したID/パスワードを即時にSaaSへ適用、メールボックスやファイルへアクセス。
  4. 被害は情報窃取・二次フィッシングの踏み台化に波及します。

• シナリオB：RMM（ScreenConnect）導入によるハンズオン侵害

  1. 上記Aのフローに続き、ユーザーへ“セキュリティ更新”や“サポート接続”を装ってRMM導入を促す。
  2. 管理者権限の昇格や横展開、バックドアの恒常化。
  3. 財務・人事・役員領域への静かで持続的なアクセスを確保し、BEC、不正送金、データ引き出しへと展開します。

• シナリオC：ID侵害を起点とした長期的なブランド・信頼毀損

  1. 侵害アカウントから社外へ二次フィッシング、DMARC/ARC整合を伴い信頼性を装う。
  2. 顧客・パートナーの連鎖被害に発展し、広報・法務・規制対応の長期コストが顕在化します。

MITRE ATT&CKマッピング（仮説）

• Resource Development: T1583.006（Webサービスの獲得/悪用としての正規クラウド基盤の利用）
• Initial Access: T1566.002（Spearphishing Link）
• Execution/User: T1204.001（User Execution: Malicious Link）
• Defense Evasion: T1036（Masquerading：ブランド偽装）
• Credential Access:（資格情報入力フォームによる収集。実装依存のため一般化）
• Command and Control/Exfiltration: T1071（Application Layer Protocol：HTTPS）
• Persistence/Remote Access: T1219（Remote Access Software：ScreenConnect等のRMM）
• Lateral Movement/Collection/Impactは環境依存のため、実装を確認のうえ個別評価が必要です。

影響の考察

• 電子政府・金融のように「大手クラウドの可用性」を重視する環境で、ドメイン許可の緩さが検知遅延を招く恐れがあります。
• 役員・財務・調達の業務ラインに直撃するIf-Clicked型の侵害で、短時間に不可逆な被害（認証情報流出、不正送金、サプライチェーンの信頼低下）へつながりやすいです。
• 教育だけでは埋まらない“UI/UXの欺き”が本質であり、設計変更（終端検査・RMM統制・パスキー化）を伴う防御が必要です。

セキュリティ担当者のアクション

すぐに運用へ落とせる打ち手を優先度順でまとめます。

• メール/URL制御の再設計

  • 大手クラウドのリダイレクト器（例：検索/会議サービス由来）の扱いを「許可」から「半信頼」に変更し、クリック時解析（time-of-click）で“最終到達先ドメイン（eTLD+1）”を評価する設計に切り替えます。
  • 「リダイレクトを2回以上経由する」「終端が社外SaaSログインや未知のeTLD+1」などの条件を高リスクとみなし、警告・ブロック・隔離へ分岐します。
  • URLフラグメント（#）に埋め込まれた識別子はゲートウェイから不可視になりがちです。エンドポイントのブラウザ拡張やEDRテレメトリで“クリック後の実URL”を収集し、メールセキュリティと相関させる仕組みを用意します。

• ブランド偽装と終端ページの自動検出

  • 企業名・ロゴ・ドメイン表記の混在（例：ロゴは自社/ドメインは微妙に異なる等）を特徴量にしたML/シグネチャの併用で、終端レンダリングを対象に検知を強化します。
  • セーフブラウジング系判定に頼り切らず、社内で観測された“最終到達先”の即時共有（TIP/SoC内IOC運用）を回すことで、短寿命の終端ドメインにも追随します。

• RMM（ScreenConnect等）の統制強化

  • RMMの導入元ドメイン/コード署名/インストールフローをホワイトリスト化し、逸脱時は管理者承認フローへ強制ルーティングします。
  • EDRで「ブラウザ経由ダウンロード直後のRMMプロセス起動」「msiexec/PowerShell経由のRMM展開」を高優先度アラートに設定します。
  • 既存端末におけるRMM資産の棚卸しと不審インスタンスの横断検出（バージョン・通信先・稼働ユーザー）を定期化します。

• ID防御の底上げ

  • パスキー（FIDO2）やデバイスバインド型の多要素を主要SaaSへ適用し、資格情報搾取の価値を減衰させます。
  • リスクベース認証で「短時間に新規ASN/新規デバイスからのログイン」「直前クリックの終端が新規ドメイン」などの相関条件を拒否または段階的チャレンジへ分岐します。
  • OAuth/同意フローのスコープ監視と、ユーザーによる不審アプリ承認の検出・取り消しを自動化します。

• ハンティングと可視化（実装指針）

  • プロキシ/EDR/メールの三点から「google系ドメイン → 302/リダイレクト連鎖 → 新規eTLD+1」パターンを相関し、クリックから5分以内にSOARで封じ込め（パスワードリセット・セッション失効・送信隔離）を自動実行します。
  • メール内リンクのクリック率より「最終到達先ユニークeTLD+1数」「1メールあたりの平均リダイレクト段数」などの運用KPIを導入し、検知の“穴”を定量把握します。
  • 役員/財務/調達を高リスク集団として分離保護（追加審査、URLプレビューの既定オン、ZIP/HTMLブロック方針の強化）します。

• レスポンスプレイブックの更新

  • 「Googleドメイン経由リンク踏み」の初動判定テンプレート化（終端URLの収集、同報者の特定、フォーム入力有無のヒアリング、RMM導入の痕跡確認）を進めます。
  • BEC・不正送金系リスクが見える場合は、会計・金融機関連携の即応ルートを明文化し、時間要件（例：30分以内の差止依頼）を運用SLAに織り込みます。

最後に、この種の攻撃は「教育」だけでは止まりません。ユーザーの“気づき”を期待しつつも、設計側で“見えないものを見える化する”仕組みを重ねることが、今年のうちにできる最大の防御差になります。

参考情報

• Global Phishing Campaign Abuses Google’s Infrastructure（GBHackers）: https://gbhackers.com/global-phishing-campaign/