2026年8月中旬以降、企業ユーザーから有効なGoogleセッションを窃取するフィッシング攻撃が確認されています。防御側がリンクの安全性を判断する際に頼る指標は、すべて「問題なし」という結果を返していました。攻撃者が意図的にそうなるよう攻撃チェーンを構築していたためです。
このキャンペーンを特定したのは、Material SecurityのThreat Researchチームです。同チームは「Operation CloudFire」と名付けた対策作戦で、攻撃者が使用していた数百のドメインを閉鎖に追い込みました。以下では、調査で明らかになった内容を紹介します。
おとり：Googleカレンダーの招待状
攻撃メッセージはGoogleカレンダーの招待状として届きます。BCCで送られることもあり、受信者がすでにやり取りしたことのある組織から送信されるケースも少なくありません。口実はありふれたもので、ボイスメール通知、RFP・RFIの依頼、裁判所の召喚状、支払い遅延の通知などです。
リンクの大半はGoogle自身のドメインを指しています。典型的なのは、Googleの/urlリダイレクタを使い、本当の宛先をクエリパラメータに埋め込む手口です。ほかにも、share.googleやGoogleドライブのファイルリンクを同じ目的で使う波がありました。Intuitの取引通知リンクを使った亜種もあります。
いずれの場合も、メッセージを評価すると、表示されるドメイン、証明書、レピュテーションはすべて正規かつ信頼できるものでした。
窃取：Googleログインページの前段に置いたリバースプロキシ
攻撃者は、本物のGoogleログインページの前段で稼働するリバースプロキシを運用しています。被害者がパスワードを入力すると本物の認証プロンプトが届き、それを承認します。その間、攻撃者はセッションの様子をリアルタイムで監視しています。
サーバーは、SMSコード、認証アプリのコード、Googleの「はい」をタップする番号照合、電話によるアカウント復旧を、届くたびにGoogleへ中継します。このため、どの第2要素の対策もセッションの窃取を止められません。
背後にあるフレームワーク「Nyasher」は、JavaScript内にハードコードされた鍵が見つかったことから、2月以降に公に文書化されています。
対策が機能しない理由
レピュテーションシステムが答えるのは、所有者に関する問いです。つまり、誰がそのドメインを登録したのか、ほかに何をホストしてきたのか、苦情が寄せられたことがあるのか、といった点です。今回のキャンペーンは、これらの答えが常に無害になるよう組み立てられており、3つの層で構成されています。
第1の層は、Googleのリダイレクタです。第2の層はCloudflare Turnstileのチャレンジで、ビルドによってはCloudflare自身のインフラから配信される本物のウィジェットが使われます。第3の層は、パスワードを窃取するページそのものです。このページにはスキャン可能な静的Webサイトがありません。
訪問者がチャレンジを通過した後、JavaScriptがブラウザ内でページを構築します。そのためクローラーが取得できるものはなく、プロキシのログにも記録が残りません。Materialの知る限り、キャンペーンが文書化されるまで、これらのページをスキャンした者はいませんでした。
インフラは使い捨てを前提に設計されています。最初に観測されたキャンペーンでは、複数のレジストラにまたがる多数のおとりドメインが使われ、その大半は使用のわずか数日前に登録されたものでした。受信エンドポイントは、対応する攻撃の波の1〜20日前に準備されていました。
あるワイルドカード証明書は、対象ドメインが登録される46分前に発行されていました。個々の構成要素をブロックしても、攻撃者に生じる負担はわずか数ドルの費用と午後ひと仕事分の作業にすぎません。
防御の実際
Materialは、おとり、ゲート、受信エンドポイントが入れ替わるたびに各亜種を追跡し、キャンペーンの開始当初から監視を続けてきました。8月以降、キャンペーンを特定して検知機能を構築してからは、悪意あるメッセージの99%超を捕捉しています。再分類率は0.01%です。
攻撃者がTTP、テーマ、おとりの文面を変え、静的検知、機械学習による検知、エージェント型の検知をすり抜けようとしたため、これは継続的な取り組みとなりました。
この手法が有効なのは、単一のシグナルで結果が決まらないからです。レピュテーションだけでは検知できませんでした。リンク解析単独でも同様です。最初の遷移先はGoogleのURLであり、最終的なページはブラウザが構築するまで存在しないためです。
Materialは、技術的な指標、メッセージの意図とみられる内容、リンクの実際の解決先、メッセージの背後にある送信者との関係性をスコアリングしています。そのうち1つでも該当すれば、対処に踏み切るには十分です。
1つのシグナルに依存した検知は、そのシグナルの死角をそのまま引き継ぎます。そして今回の攻撃者は、その死角を洗い出すために相当な労力を費やしていました。
分析を実行する場所も重要です。カレンダーの招待状は、転送中のメールを検査するよう設計されたゲートウェイとは相性が悪いものの、このキャンペーンの多くは招待状として届きます。
Materialはカレンダーの招待状をそれ自体が脅威の入り口になると捉え、技術的なシグナルに加えて、アカウントの全履歴をコンテキストとして活用しています。
被害が及ぶ範囲
被害がパスワードの窃取ではなくセッションの乗っ取りである場合、その痕跡はWorkspaceの監査ログに残ります。有効なGoogleセッションがあれば、メールやドライブにアクセスでき、被害者の名義でOAuthアクセスを付与することもできます。被害の範囲は受信トレイをはるかに超えます。
防御側は、2つの点を自問すべきです。誰がそのログを確認しているのか、そして、どれだけ迅速に対応に移れるのかです。同様に重要なのが、1時間以内にセッションを失効させ、OAuthの許可を封じ込め、影響を受けたアカウントをリセットできるかどうかです。
多くの組織ではそれができません。有効なセッションを握った攻撃者は、その間に多くのことを実行できます。
Operation CloudFire：インフラそのものを標的に
Materialは9月下旬までに、ルールの調整、モデルの再学習、エージェントの更新だけでは問題を解決できないと結論づけました。検知は顧客を守りますが、次の攻撃の波を準備している運用者には何の影響も与えないためです。
そこでMaterialのThreat Researchチームは、インフラそのものを標的とするOperation CloudFireを開始しました。
チームは、メッセージが送信されている最中にゲートウェイとバックエンドのURLを分析し、Cloudflareの不正報告システムを通じて報告しました。Cloudflareの不正対策チームは、偽の中間ページと、その背後にあるプロキシ化されたGoogleログインページを確認したうえで、それらの宛先に独自のフィッシング警告ページを適用しました。
これには2つの効果がありました。1つは、攻撃者のインフラが使えなくなったことです。報告された各ゲートウェイと受信エンドポイントは、運用者が送信を再開する前に、再登録、再設定、証明書の再取得が必要になりました。もう1つは、インターネット全体も恩恵を受けたことです。
報告されたリンクをクリックした人は、Materialの顧客かどうかにかかわらず、認証情報の入力フォームではなく警告を目にしました。
1か月間の数字
以下の数値はMaterialとのデータ共有に同意した顧客のものだけで、実際の合計はこれより多くなります。Operation CloudFireの1か月間で、Materialは次のように記録しました。
- ブロックしたキャンペーンメッセージ：68,676件
- 分析した固有の悪意あるURL：2,112件
- 閉鎖したユニークドメイン：897件
- 侵害された送信元アドレス：6,354のルートドメインにまたがる8,570件
- 米国の営業時間に沿った送信パターン
送信元の数からは、このキャンペーンがどのように信頼性を獲得したのかがわかります。侵害されたアドレスはいずれも、最初の招待状が送られる前から攻撃者の支配下にあったアカウントのものでした。各アカウントは、被害者の保存済み連絡先などに招待状を送信していました。
受信者が目にしたのは、見覚えのある名前やドメインで、履歴にも問題がなく、時間帯ももっともらしいものでした。レピュテーションフィードにはフラグを立てる理由がなく、所有者や履歴をスコアリングする層はすべて「問題なし」の結果を返しました。
現状
フィッシングのテーマは、カレンダーの招待状から、Googleドライブのファイルやドキュメントの共有招待へと移っています。Materialは、ほかのおとりやTTPの増加は確認しておらず、このグループの活動は分散したとみています。キャンペーンは終息したように見えます。
ただし、これは最終的な判断ではなく、現時点の状況報告にすぎません。インフラの再構築は安価です。フレームワークは2月から公開されています。さらに運用者は、稼働中のGoogle向けコードと並行して、未完成のMicrosoft 365向けブランチも配布していました。
このブランチには、スタイルシートのパス、2つ目のハーネス、Microsoftのサインインプロンプトにデコードされるタイトル文字列が含まれています。これらのパスは現時点ではいずれも解決されません。また、ブランドを追加するには、コードを変更せず、ファイルを1つ配置するだけで済みます。
運用者は次の攻撃手段をすでに用意していますが、まだ有効化していません。Materialは、テーマの入れ替えを活動の終了ではなく改良の繰り返しと捉えています。次の方向転換も、ブランドを変えただけで今回とよく似た形になると予想しています。
インジケーターやタイムラインを含む詳細な技術解説は、関連ホワイトペーパーで公開されています。自組織の環境でこの活動を調査するチームは、まずこちらを参照してください。
