Cisco Talosは、同社が「UAT-11985」として追跡する攻撃者によるスピアフィッシングキャンペーンを確認しました。このキャンペーンは台湾の研究機関を標的とし、Googleのサインインページになりすますアドバーサリー・イン・ザ・ミドル（AitM）型のキットを使用しています。
このキットは、認証情報と多要素認証（MFA）のチャレンジをリアルタイムで中継し、認証済みセッションを乗っ取ります。
Cisco Talosが公開した調査によると、このキャンペーンは2026年半ばに確認されました。攻撃者は、台湾の欧州連合センター（Taiwan European Union Centre）、国立政治大学（NCCU）国際関係研究センター、台湾研究院（Taiwan Research Institute）になりすましていました。
攻撃者は実在する公開イベントの詳細を流用し、招待状を本物らしく見せかけていました。名前を騙られた機関はいずれも、送信者が自機関の職員や代表者であることを確認できませんでした。
メールはいずれも3部構成でした。壮大な地政学的な前置き、受信者に合わせたお世辞、そして登録手順を含むイベントの運営情報です。
繰り返される言い回しや入れ替え可能な賛辞、統一された文型からは、再利用可能なプロンプトテンプレートの存在がうかがえます。Talosは、LLMがメッセージを書いたと断定する証拠はないとしています。それでも、AIを使った文面の作成と個別化が行われたことを示す強い根拠があるとみています。
登録リンクは正規のGoogleフォームのURLに見えますが、実際のhrefはサードパーティのプラットフォーム上のフィッシングサイトに誘導します。Talosは、本物のイベント情報を使うこの手口を「正当性の洗浄（legitimacy laundering）」と呼んでいます。
一部のメールには、正規サイトからコピーしたイベントのポスターが添付されており、そのQRコードが悪意あるものに改ざんされていました。受信者がポスターを印刷し、オフィスの掲示板に貼り出す可能性があります。
そうなれば他の人々がコードを読み取ることになり、攻撃はメールから現実世界へと広がります。標的組織内での被害範囲も拡大します。
フィッシングページはGoogleフォームを装い、その後、偽のGoogleログインページへ強制的にリダイレクトします。ログインパネルが対応する言語は、簡体字中国語、繁体字中国語、英語のみです。表示言語はブラウザのnavigator.languagesの値から選択されており、標的が中国語話者であることを示しています。
HTMLの非表示セクションには、iframe（google-success-frame、sandbox=”allow-scripts”）が置かれています。このiframeはローカルページ（/google-login-assets/operation-success.html）を読み込み、ログイン成功を偽装します。
キットはJavaScriptをHTML文書の末尾に隠しています。大量のBase64文字列の配列、制御フローの難読化、while(!![])によるpush/shiftのシャッフルループを使っており、自動化された静的な難読化解除を困難にしています。
Talosは、簡体字中国語を母語とする人物がインターフェースを作成したと中程度の確度で評価しています。基本となる翻訳オブジェクトは簡体字中国語で記述され、zh-TWと英語のロケールは実行時にそこから派生します。
テキストには「账号」「计算机」「邮箱」といった中国本土の用語が使われており、コードのフォールバック分岐でも簡体字中国語がデフォルトになっています。
このキットは、完全な自動化ではなく、オペレーター主導の認証を前提に作られています。通信経路は2つです。HTTP POSTは、ブラウザのフィンガープリント、認証情報、チャレンジの送信内容、ハートビートのポーリングといったステートレスな情報の窃取に使われます。常時接続のWebSocketは、C2サーバーからのコマンドを流し、被害者にどのMFA画面を見せるかを決定します。
攻撃は段階的に進みます。まず、ページがgoogle_login_startリクエストでデバイス情報（ロケール、ユーザーエージェント、画面サイズ、モバイル端末かどうか）を送信します。サーバーはセッションを作成し、WebSocketが状態のスナップショットを返します。次に、被害者がメールアドレスまたは電話番号を入力すると、google_input_identifierとして送信されます。攻撃者はこれを本物のGoogleに中継し、アカウントが存在するか、パスキーが有効かを確認したうえで、被害者にパスワード画面かパスキーのプロンプトのいずれかを表示します。その後、被害者がgoogle_login_checkでパスワードを送信すると、サーバーがそれをGoogleに転送します。Googleが追加の検証を求めた場合、サーバーはMFAチャレンジの種類とレイアウトを返し、WebSocketが被害者を対応するMFA画面へ遷移させます。
この中継によってGoogleの認証状態がリアルタイムで反映され、攻撃者は完全な認証済みセッショントークンを取得できます。被害者に気付かれることなく、アカウントを完全に乗っ取れる状態になります。
防御側には、次の対策が求められます。表示されたURLだけでなく実際のリンク先を確認するよう従業員を教育すること。印刷物やメールで届いたポスターのQRコードを信頼できないものとして扱うこと。イベントの招待は、名前の挙がった機関に独立した経路で確認すること。フィッシング耐性のあるMFAを優先して導入し、異常なセッションの再利用を監視することです。
翻訳元: https://cyberpress.org/uat-11985-google-phishing-kit/
