Google Workspaceのルールを使った“静音”窃取──研究・防衛メールが1年以上抜かれ続けた理由

今日の深掘りポイント

• 正常機能の武器化が主役です。Gmailのコンテンツコンプライアンス/ルーティング機能（BCC付与など）を使い、特定キーワードを含むメールだけを外部にコピーする“静音”の情報流出が成立します。
• 侵入点は研究現場のREDCapサーバーです。学術・医療の実務に密着した基盤が踏み台にされ、クラウドのコントロールプレーン（Workspace管理ルール）へとつながる導線が作られた構図です。
• キーワード約150件の監視で、軍事戦略や先端技術の情報を的確に抽出。低コスト・低リスクで高価値の情報だけを運び出す設計です。
• SaaSの“設定改ざん”は検知の盲点になりがちです。ユーザーや管理者の正規権限の範囲内で完結するため、EDRやネットワーク監視では気づきにくいのが実情です。
• いま手を打てる現実解は、Gmailルールのガバナンス強化（外部Bcc/転送の原則禁止と例外管理）、設定変更の常時監査、そして研究系公開サーバー（REDCap等）の公開範囲とパッチ体制の再設計です。

はじめに

中国に関連するとされるスパイ活動が、北米の医療・学術・軍事研究ネットワークで1年以上潜伏し、研究・防衛関連メールを静かに窃取していたと報じられています。攻撃の核は、Google Workspace（Gmail）の管理ルールを悪用した「特定キーワード一致メールの外部Bccコピー」。侵入の足場には病院や大学で広く使われるREDCapサーバーが使われ、攻撃者がバックドアを設置したうえで、被害組織のWorkspace設定を改ざんしていました。Googleの脅威チームはキャンペーンをUNC6508として識別し、被害者通知とインフラ遮断を実施したとされています。

本件は、クラウドSaaSの“正当機能”を逆手に取る設計思想が、地道で堅実な諜報活動にどれほど相性がよいかを示す象徴例です。日本の研究機関、医療機関、防衛・装備調達に関わる企業にとっても、対岸の火事ではありません。SaaSの設定が新しい境界であり、そこでの小さな隙が長期の情報流出に直結する時代です。

参考情報:

• The Hacker News: Chinese Hackers Abused Google Workspace Rules to Steal Research and Defense Emails

深掘り詳細

事実関係（確認できる範囲）

• 北米の医療・学術・軍事研究ネットワークに対して、1年以上にわたり潜伏が続いたと報じられています。
• 侵入の足場として公開されたREDCap研究サーバーが悪用され、攻撃者がバックドアを設置しました。
• その後、被害組織のGoogle Workspace（Gmail）管理設定を改ざん。特定キーワードに一致するメールを、攻撃者が制御する受信箱にBccコピーするルールを作成しました。
• 攻撃者は約150のキーワードを監視し、軍事戦略や先進技術に関連する通信を重点的に抽出したとされています。
• Googleの脅威インテリジェンス部門は本キャンペーンをUNC6508として識別し、被害者への通知・インフラ遮断を実施済みとしています。
• 上記は公開報道に基づく記述です（参考: The Hacker News）。

インサイト（筆者の考察）

• 正当機能の“低摩擦な武器化”です。Gmailのコンテンツコンプライアンス/ルーティングは、正規の運用でもBcc付与や外部転送を柔軟に設定できます。これが攻撃者の手に渡ると、監視対象をキーワードで厳選し、ユーザー体感ゼロの「見えない抜き取り」が長期継続してしまいます。メールは通常どおり届くため、ユーザー違和感も生まれません。
• 情報搾取の歩留まりが高いです。約150のキーワードで軍事・先端技術に的を絞ることで、不要ノイズを極小化し、検知リスクと転送のコストを抑えつつ、価値の高い通信だけを抽出できます。スパムのような大量外送が発生しないため、メールセキュリティ製品の異常検知にも引っかかりにくいです。
• 研究現場固有の“脆弱な表面”が突かれています。REDCapは研究現場の実務都合で外部公開や迅速な機能追加が優先されがちです。ここにパッチ遅延やアクセス制御の粒度不足が重なると、攻撃者にとって「地に足の着いた侵入動線」になります。研究支援システムとアイデンティティ/メール環境が緩く結びつく組織ほど、クラウド設定の奪取に至るリスクが高まります。
• 検知の焦点は“設定の差分”です。エンドポイントやネットワークの異常よりも、SaaS管理プレーン上の「誰が、いつ、どの条件で、どこにBcc/転送させたか」という設定差分と変更イベントが一次検知ポイントになります。これは従来のSOC運用が弱い領域で、可観測性の拡張とアラート整備が急務です。

脅威シナリオと影響

以下は、公開情報に基づく事実と、必要に応じて仮説を明示したシナリオです。

• 初期侵入（仮説を含む）

  • 公開REDCapの脆弱性悪用または認証情報窃取により侵入（MITRE ATT&CK: Exploit Public-Facing Application）。
  • 研究者・管理者のアカウント/セッション情報を窃取し、クラウド管理系（Google Workspace）へ横展開（Valid Accounts）。

• 権限確保と永続化（仮説）

  • 管理者もしくは相当権限を得た上で、Gmailのコンテンツコンプライアンス/ルーティングを改変（Account Manipulation）。
  • 特定キーワード一致時に外部アドレスへBccするルールを作成し、長期持続化。

• 収集と外送（報道ベース）

  • 約150の監視キーワードで軍事・先端技術関連のメールのみを選別（Email Collection: Auto-Forwarding）。
  • Bccコピーによりユーザー影響を与えず外送を継続。

• 防御回避（仮説）

  • ルールは正規機能であり、SPF/DKIM/DMARCの枠外で正当通信として扱われるため、メールゲートウェイやDLPの汎用シグネチャでは発見困難。

想定影響

• 機微研究・軍事関連の通信内容（要件、成果、試験計画、資材・装置の型番、提携先、資金・調達計画など）の長期的な流出。
• 研究競争力の低下、特許・移転価格・輸出管理（安全保障貿易）コンプライアンスの波及影響。
• 関係機関間のトラスト毀損。共同研究・資金提供者からの監査強化や条件見直し。

MITRE ATT&CKの観点（仮説を含む）

• Initial Access: Exploit Public-Facing Application（REDCap）
• Credential Access/Discovery: Valid Accounts（研究者/管理者アカウントの不正利用）
• Persistence/Privilege Escalation: Account Manipulation（SaaS設定の改変）
• Collection: Email Collection（Auto-Forwarding/Bccルールの悪用）
• Defense Evasion: 正規機能の悪用（設定ベースのためEDR/IDS網の外側）

本件は緊迫度と即応性がともに高い類型です。新規マルウェアの投下や大量送信のような“派手さ”はありませんが、成熟した運用と設定監査がなければ長期化しやすいのが最大の脅威です。

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

今日から着手できるプライオリティ順に整理します。

• 直ちに実施（24〜72時間）

  • Gmail設定の棚卸し
    • ドメイン全体・OU単位の「コンテンツコンプライアンス」「ルーティング」「不正なBcc付与」「外部自動転送」「フィルタ/転送設定」を全出力し、外部ドメインを宛先とする条件付きBcc/転送の有無を確認します。
    • 変更履歴（Admin audit/Gmail logs）から、ここ3〜6カ月に作成・変更・有効化されたルールを抽出し、変更者・変更元IP・管理APIの使用有無を精査します。
  • 監視強化
    • アラートセンター/ SIEMで「Gmail設定変更イベント（作成/更新/有効化/無効化）」のリアルタイム通知を有効化し、外部宛先が含まれる場合は高優先度でページングします。
    • メールログで“同一外部アドレスに複数アカウントからBcc/転送”が集中していないかを相関分析します。
  • アクセス制御
    • 管理者アカウントのフィッシング耐性MFA（FIDO2/Passkeys）を必須化し、SMS/音声を廃止します。
    • 管理コンソールへのアクセスを条件付きアクセス（社内ネット/VPN、デバイス健全性）で制限します。
  • 研究基盤の一次対応
    • 公開REDCapの最新版適用、不要モジュール無効化、外部公開の最小化（WAF/リバースプロキシ背後化、可能ならVPN/mTLS必須化）。
    • Webサーバーログにおける管理画面アクセスと不審POST、異常なファイル生成（php, aspxなどのWebシェル兆候）を確認します。

• 1〜4週間で整える中期施策

  • ガバナンス（原則と例外管理）
    • 外部宛先への自動転送・Bcc付与は原則禁止。業務上やむを得ない例外は申請・承認・期限付き・宛先ホワイトリストで管理します。
    • GmailのDLP/コンプライアンスで「機微ラベル付きメールの外部Bcc/転送」を拒否/隔離にするルールを作成します。
  • 可観測性の定着
    • Admin audit/Gmail/Groups/Drive等のSaaSログをクラウドSIEMへ常時転送し、設定変更系のユースケース検知（外部宛先の新規追加、正規表現を含む条件付き転送、ルールの大量作成/一括変更）を実装します。
    • レアドメイン宛て外送やBccの急増、特定外部アドレスへのマルチユーザー集中送信を行動分析で可視化します。
  • 権限と開発運用の是正
    • 管理権限は職務分掌し、Gmail設定変更は二人承認/変更管理チケットを必須化します。
    • 研究部門のSaaS連携（OAuthアプリ、ドメイン全体委任）は許可リスト方式に切り替え、スコープ過大なトークンを棚卸し・失効します。
  • 研究基盤の構成見直し
    • REDCapやLIMS等の研究系アプリは、IdP連携（SSO）と強制MFA、アプリ層のRBAC厳格化、脆弱性管理（定期スキャン/パッチ）を標準化します。
    • ファイル改ざん監視とバックアップ/復旧手順の訓練を行い、Webシェル残置の長期化を防止します。

• 30〜90日での恒久対応

  • データ中心の防御
    • メール・ドライブ・チャットの機密度ラベリング（自動/手動）と送信時ポリシー強制（コンテンツ＋宛先＋ラベルの複合条件）を整備します。
  • レッドチーム/テーブルトップ
    • 「管理ルール改ざん型の静音外送」を想定した演習を実施し、検知から封じ込め、法務/広報/渉外までの体制を通しで確認します。
  • 取引先・共同研究のセキュリティ条項見直し
    • 共同研究先のSaaS設定要件（自動転送禁止、MFA要件、監査ログ保持など）を調達・契約に組み込み、相互監査の仕組みを持たせます。

最後に強調したいのは、これは「ゼロデイの恐怖」ではなく「設定ガバナンスの勝負」だという点です。メールという最古参の業務基盤で、機能の柔軟性がそのまま攻撃面の広さになります。設定の原則化、変更の可視化、例外管理の厳格化——この三点が整えば、たとえ侵入されても“静音の抜き取り”は長期化しません。今日の棚卸しが、1年分の流出を止める第一歩になります。