「正規のGoogle通知」に化けたメールがすり抜ける——Google Cloud Application Integration「Send Email」悪用の本質

今日の深掘りポイント

• 攻撃者はGoogle CloudのApplication Integrationにある「Send Email」を“送信基盤”として借用し、DMARCや許可リストに依存した防御の盲点を突いています。
• 送信元インフラが正規（Google管理）であることが、受信側の信頼判断やゲートウェイの許容設定を迂回する決定打になっています。
• メール本文のリンク先やリダイレクトのふるまい、NRD（新規登録ドメイン）との組み合わせが、実運用での検知分岐点になります。
• 技術対策単独では限界があり、BECの業務プロセス対策（支払・口座変更の二経路確認など）とセットでの被害抑止が必要です。
• 受信側のセキュリティだけでなく、自社のSaaS/OAuth連携ポリシーとクラウド利用の棚卸しを同時に進めることが、将来の踏み台化と後続被害の抑止につながります。

はじめに

クラウドの「信頼」を攻撃者が借りる——それが今回の事件の肝です。Google CloudのApplication Integrationに用意された「Send Email」タスクを使い、正規のGoogle生成メールに見える体裁で大量送信が行われました。研究者の観測では、短期間に数千の組織が狙われ、数千通規模のフィッシングが配信されています。Googleはすでに当該悪用をブロックし、追加対策を講じていますが、今回の手口はブランド・ドメインの信頼を根拠にしたゲートウェイ設定や運用慣行の弱点を突くもので、再発可能性の高いパターンだと捉えるべきです。

このPickUpでは、事実関係を整理したうえで、「なぜ効くのか」「どこで止めるか」を、ゲートウェイ・SOC・業務プロセスの3レイヤで具体化します。

深掘り詳細

事実整理（観測とベンダ対応）

• セキュリティ研究者は、Google Cloud Application Integrationの「Send Email」タスクを悪用したフィッシングの詳細を公開しています。短期間で多数の組織に向けて正規のGoogle生成メールに見えるメッセージが配信され、メールセキュリティのフィルタ回避が確認されています。Googleは当該活動をブロックし、追加の乱用防止策を実施しています。The Hacker Newsの報道に基づく要点です。
• 送信の中核はGoogle側に用意された通知機能で、攻撃者は自身のインフラを用いず、Googleの送信基盤からメールを届けています。このため多くの環境でSPF/DKIMが成立し、結果的にDMARCや許可リスト運用の抜け道になりえます（報道の要点からの推察であり、具体的なヘッダ値や個別ドメインは公開情報に依存します）。

出典はいずれも公開報道に基づく二次情報で、ベンダーの一次資料の細部（ヘッダ例や検知シグネチャ）は本稿時点で参照可能な範囲に限ります。検証用のサンプル入手やヘッダ差分解析は各社環境での実地確認を推奨します。

なぜ効くのか（インサイト）

• 信頼の転用問題：メールの「正しさ」を支えるのは送信インフラとドメインの組み合わせです。今回のようにクラウド事業者の正規インフラから出る通知体裁のメールは、ヘッダ認証面で“正しい”ため、受信側で「Google由来＝安全」の短絡に陥りやすいです。許可リストや配信元評価の閾値も緩みます。
• DMARCの限界：DMARCはなりすまし抑止に有効ですが、「正規ドメインからの正規送信」を前提にした検知回避には弱いです。ブランド信頼に寄りかかった判定は、本文リンク先・リダイレクト・フォーム遷移のふるまいまで見て初めて補完されます。
• スケールと持続性：攻撃者が自前でIPレピュテーションを育てる必要がなく、アカウントBANの弾力が高い大手クラウドを媒介にできるため、封じ込めてもTTPを横展開しやすいです。別のクラウド事業者や別機能への乗り換えも容易で、検知・対策は「特定ドメインを止める」から「ふるまいとコンテンツの整合性で止める」へシフトが不可欠です。
• BECとの親和性：通知風のメールは、請求・配送・共有といった業務の“普段”に寄り添います。ここに支払口座の更新や認証再構成などの行動を自然に混ぜ込むと、BECの初手として極めて刺さります。

脅威シナリオと影響

以下は公開情報を踏まえた仮説シナリオです。具体的なテクニックのマッピングはMITRE ATT&CKに沿って整理します。

• シナリオA：通知装いのリンク誘導からの資格情報搾取

  • Resource Development: T1583.006（インフラ取得：Webサービス/クラウドの送信機能を確保）
  • Initial Access: T1566.002（スピアフィッシングリンク。Google通知体裁のメール本文に外部リンク）
  • Defense Evasion: T1036（偽装。正規ブランドの体裁で信頼を獲得）
  • Credential Access: T1556.002やT1110系は直接適用しにくいが、実態としては偽ログインページでの認証情報入力（資格情報収集）に該当
  • Impact/Risk: 盗まれたIDでのSaaS侵害、転送ルール設定や支払情報改ざんを介したBEC

• シナリオB：OAuth同意フローへの誘導（仮説）

  • Resource Development: T1583.006
  • Initial Access: T1566.002
  • Defense Evasion: T1199（信頼関係の悪用。正規クラウドと見せかけた同意要求）
  • Persistence/Privilege: T1098（アカウント操作）やT1550（トークンの悪用）に連なる可能性
  • Impact/Risk: 永続的なAPIアクセス付与、MFA回避を伴うデータ流出・送金詐欺

• シナリオC：請求・見積・人事通知を装った業務プロセス介入

  • Initial Access: T1566.002
  • Collection/Exfiltration: T1567（Webサービス経由の流出。フォームや外部サイトでの機微情報入力）
  • Impact: 請求書改ざん、口座振替の変更、サプライチェーン宛先の迂回などのBEC被害

影響は単発のアカウント侵害に留まらず、承認プロセスの「人」を巻き込むことで、部門横断の業務被害に波及しやすいです。特に「Googleからの正規通知に似ている」という点は、教育済みの従業員でさえ注意力を削がれるリスクが高いです。

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

実務に落ちる優先順位と、技術・運用の両輪での対策を提案します。

• ゲートウェイ/メール検知の是正

  • 大手クラウド送信（例：Google由来）の許可リスト運用を見直し、「Fromドメインの正当性」だけで無条件通過させない方針に改めます。
  • コンテンツとリンクの整合性チェックを強化します。具体的には「Fromがgoogle.com等のブランド名義にもかかわらず、本文の主リンク/フォーム送信先が非ブランド・NRD・短縮URL」という条件の高リスク化です。
  • 正規通知テンプレートの“揺らぎ”検知（ブランド名、差出人表示名、フッターの定型表現、アンsubscribeヘッダの有無など）をルール化します。これは誤検知とのトレードオフがあるため、まず監視モードでのヒット状況確認を推奨します。
  • URL多段リダイレクトの展開解析（クラウド先→外部ドメイン）をサンドボックスやクラウドURL解析で必ず行います。

• アイデンティティ/業務プロセスの堅牢化

  • BECガードレール：支払口座変更・大口送金・ベンダ登録の更新などは、メール起点では完結させず、二経路（電話/Teams等）での確認を必須化します。
  • SaaS同意とOAuthのポリシー設定を強化します。組織外の未審査アプリの同意を既定で禁止し、例外申請・審査を通す運用にします。
  • 高価値アカウント（財務・購買・人事）のMFAを段階的MFA（リスクベース）にし、メール起点のサインインや新規アプリ同意要求時に追加認証を必須化します。

• 監視とハンティング

  • SIEMでのユースケース例（要環境調整）：短期間に「Fromが大手クラウドブランド」かつ「本文主要リンクが外部NRD」の受信増加、同一件名・同一本文ハッシュの分散送信、返信先（Reply-To）と送信者表示名の乖離などを相関します。
  • プロアクティブハンティング：最近登録ドメイン（NRD）へのユーザクリック/HTTPトラフィックと、直前のメール受信事実を相関して、潜在的フィッシング到達を可視化します。

• 自社クラウド/送信機能の点検

  • 自社のGCP/他クラウドで提供されるメール送信機能の権限・用途を棚卸しし、不要な「任意宛先への送信」を無効化します。インターナル用途は宛先制限・DKIMセレクタ分離・送信レート制御を入れます。
  • 異常送信（送信レート急増、送信先分散、テンプレート変化）のアラートを導入し、踏み台化の早期検知に備えます。

• ユーザ教育の焦点合わせ

  • 「正規ブランドの通知に見える」事例の演習を取り入れます。見分け方として、本文中リンクのホバーでのドメイン確認、Google系通知ならリンク先がgoogle.com系で完結しているか、を具体的に示します。
  • 「メールの正しさ＝ヘッダや緑色の鍵マーク」ではないことを強調し、業務上重要な要求は常に第二の確認経路を使う習慣を定着させます。

最後に、今回のケースは「一社をブロックすれば終わる」種類ではありません。攻撃者は別クラウドや別機能に容易に移るため、私たちは送信者の“由来”ではなく“ふるまいと文脈”で脅威を判別する設計に段階的に移行する必要があります。メールセキュリティ、ID保護、業務プロセスという三位一体の防御に、今日から手を入れていきたいです。

参考情報

• The Hacker News: Cybercriminals Abuse Google Cloud Email Feature to Send Phishing Emails（2026-01-02） https://thehackernews.com/2026/01/cybercriminals-abuse-google-cloud-email.html