GRIDTIDEとは何ですか？

GoogleとMandiantが摘発した、中国系の国家支援アクターUNC2814による大規模なサイバー諜報作戦です。通信事業者と政府機関を標的とし、確認された侵害は42カ国53組織、疑いを含めると70カ国超に及びました。

GRIDTIDEはどうやってC2通信を隠していましたか？

C2（指令通信）にGoogle SheetsのAPIを悪用しました。攻撃者がスプレッドシートにコマンドを書き込み、感染端末がそれを読み取って実行、窃取データもセルに書き戻す形で持ち出すため、防御側からは「Google Sheetsへの正常なAPIアクセス」にしか見えませんでした。

GRIDTIDEは何を盗んでいましたか？

通信加入者の個人情報（PII）です。氏名・電話番号・生年月日に加え、有権者IDや国民IDといった個人を一意に特定できる情報を窃取しており、特定人物の監視を目的としていたとみられます。

GRIDTIDEはどうやって発見されたのですか？

ネットワーク通信ではなくホスト上のプロセスの振る舞いから発見されました。Mandiantが/var/tmp配下の見慣れないバイナリがshを起動しid（uid=0）を確認する典型的な挙動を検知し、Googleは2026年2月に攻撃者のクラウドプロジェクトとAPIアカウントを一斉に無効化しました。

GRIDTIDEから日本企業が学ぶべきことは何ですか？

「正規サービスへの通信＝安全」という前提が崩れている点です。Google APIやSaaSへのアウトバウンド通信を可視化し、業務ロジックを持たないサーバーからの予期しないAPIアクセスやビーコン的な定期通信を検知できるようにすること、境界防御だけでなくEDRによる振る舞い検知を併用することが重要です。

GRIDTIDE詳解 - Google Sheetsを司令塔に通信事業者を狙った中国系APT UNC2814のスパイ活動

GoogleとMandiantが、世界40カ国以上の通信事業者・政府機関を標的にした大規模なサイバー諜報作戦を摘発した。コードネームはGRIDTIDE、背後にいるのは中国系の国家支援アクターUNC2814とみられる。最も注目すべきは、攻撃者が指令通信（C2）の経路としてGoogle SheetsのAPIを悪用し、自らの通信を正規のクラウドトラフィックに紛れ込ませていた点だ。本稿では、この作戦の手口と、正規SaaSがC2に転用される時代に日本企業の情シスが何を監視すべきかを実務目線で解説する。

概要

脅威アクター：UNC2814。中国（PRC）系と疑われる国家支援のサイバー諜報グループで、Google Threat Intelligence Group（GTIG）が2017年から追跡。
標的：通信事業者と政府機関。確認された侵害は42カ国の53組織、標的の疑いを含めると70カ国超（アフリカ・アジア・南北アメリカ）に及ぶ。
マルウェア：C言語製バックドア「GRIDTIDE」。任意シェルコマンド実行・ファイル送受信が可能で、C2にGoogle Sheets APIを悪用する。
目的：加入者の個人情報（PII）窃取。氏名・電話番号・生年月日・有権者ID・国民IDなどを抜き、特定人物の監視に用いたとみられる。
対応：2026年2月、Googleが攻撃者の管理するクラウドプロジェクト・インフラ・APIアカウントを一斉に無効化し、IOC（侵害指標）を公開して作戦を妨害した。

何が起きたのか

Google Threat Intelligence Group、Mandiant、およびパートナーは、通信事業者と政府機関を狙ったグローバルなスパイ活動「GRIDTIDE」を摘発し、その基盤を無効化した。攻撃者UNC2814は2017年から追跡されてきた中国系の諜報グループとみられ、今回の作戦では4大陸にまたがる広範な標的を侵害していた。

通信事業者が狙われるのには明確な理由がある。通信網はあらゆる人物の通話・通信・位置情報・加入者データが集約される結節点だからだ。国家系アクターにとって、特定の要人・反体制派・外国政府関係者を監視するうえで、通信事業者の内部システムは「合法的傍受（lawful intercept）の仕組みごと乗っ取れる」究極の標的になる。実際GRIDTIDEが窃取していたのは、氏名・電話番号・生年月日に加え、有権者IDや国民IDといった個人を一意に特定できるPIIであり、監視対象者を割り出す目的が色濃い。

Googleは2026年2月、攻撃者が司令塔として悪用していたGoogle Cloudプロジェクトとサービスアカウントを特定し、まとめて無効化した。同時にIOCを公開し、世界中の防御側が自組織の侵害有無を確認できるようにした。

技術的な解説

Google Sheets を「司令塔」にするC2

GRIDTIDE最大の特徴は、C2（コマンド&コントロール）通信にGoogle SheetsのAPIを悪用した点にある。通常、マルウェアは攻撃者が用意したサーバーと通信して指令を受け取るが、その通信は「見慣れない宛先への怪しい接続」として検知されやすい。

GRIDTIDEはこの弱点を、正規クラウドサービスへの「擬態」で回避した。具体的には次のように動く。

攻撃者は特定のGoogleスプレッドシートに、コマンドを書き込む
感染端末上のGRIDTIDEは、Sheets APIで定期的にそのセルを読み（例：セルA1の値を取得）、指令を受け取る
コマンドはBase64エンコードされたシェルコマンドとして渡され、端末上で実行される
窃取データは45KB程度の断片に分割され、スプレッドシートのセルへ書き戻す形で持ち出される

防御側のファイアウォールやプロキシから見れば、これらは「Google Sheetsへの正常なAPIアクセス」にしか見えない。多くの企業がGoogle Workspaceを業務利用している以上、Googleドメインへの通信を一律ブロックするのは現実的でなく、攻撃者はその「正規サービスは信頼される」という前提を逆手に取った。これは正規ツールを悪用するLOLBinsの発想を、クラウドサービスのレイヤーに拡張したものと言える。

systemd と「xapt」による永続化

Linuxサーバーに居座るため、GRIDTIDEは/etc/systemd/system/xapt.serviceという悪性のsystemdサービスを作成し、/usr/sbin/xaptのバイナリをroot権限で起動させる。xaptという名前は、Debian系に存在する正規ツールを連想させる偽装であり、管理者がプロセス一覧を眺めても見過ごしやすい。

さらに攻撃者はSoftEther VPN Bridgeを展開し、暗号化されたアウトバウンド接続を確立していた。SoftEetherはオープンソースの正規VPNソフトであり、これもまた「正規ツールの悪用」の一例だ。難読化にはURLセーフなBase64（+//を-/_に置換）を用いるなど、通信を正規API呼び出しに見せかける工夫が徹底されていた。

どうやって見つかったのか

高度に擬態されたこの作戦は、ネットワーク通信の異常からではなくホスト上のプロセスの振る舞いから発見された。Mandiantは、Google Security Operations（SecOps）を通じて不審なプロセスツリーを検知した。具体的には、/var/tmp/配下の見慣れないバイナリがshを起動し、idコマンドを実行してuid=0(root)を確認する——という、攻撃者が侵入直後に権限を確かめる典型的な挙動だ。

ここに重要な教訓がある。C2通信を正規クラウドに擬態されるとネットワーク境界での検知は極めて難しい。だが、攻撃者がホスト上で行う「権限確認」「永続化設定」「不審なプロセス起動」といった挙動（behavior）は隠しきれない。境界防御に頼り切らず、エンドポイントでの振る舞い検知（EDR）を併用することが、この種の高度な脅威に対する突破口になる。

Salt Typhoon との違い

通信事業者を狙う中国系アクターとしては、米国の通信網を侵害した「Salt Typhoon」が広く知られている。しかしGoogleは、GRIDTIDE / UNC2814はSalt Typhoonとは重複しない別個の作戦であり、TTP（戦術・技術・手順）も標的とする国・組織も異なると評価している。つまり、通信インフラを狙う国家系の諜報活動が複数並行して進行している実態を示している。

日本企業への影響

GRIDTIDEが直接侵害したのは海外の通信事業者・政府機関だが、その手口と教訓は日本企業にそのまま当てはまる。

正規SaaSのC2悪用は業種を問わない：Google Sheetsに限らず、攻撃者はGitHub・Slack・Telegram・各種クラウドストレージをC2に転用する。Google Workspaceを使う日本企業にとって、「Googleドメインだから安全」という前提は崩れている。
通信・インフラ事業者は直接の標的たり得る：日本の通信キャリアやMVNO、データセンター事業者は、加入者データを抱える以上、国家系アクターの監視ニーズの対象になり得る。
サプライチェーン経由の波及：政府機関や重要インフラと取引のある日本企業は、踏み台や情報源として狙われる可能性がある。

国家系APTは金銭目的のランサムウェアと異なり、長期間にわたって静かに潜伏し情報を抜き続けるのが特徴だ。APT28やMuddyWaterの事例でも見たとおり、派手な被害が出ないぶん発見が遅れやすく、気づいたときには数年分のデータを抜かれていることもある。

今すぐ確認すべきポイント

1. 正規クラウドサービスへのアウトバウンド通信を可視化する

GRIDTIDEの教訓は「正規サービスへの通信＝安全ではない」という点に尽きる。Google API・GitHub・各種SaaSへのアウトバウンド通信を可視化し、次のような異常を検知できるようにする。

サーバー（特に業務ロジックを持たない基盤サーバー）からの予期しないクラウドAPIアクセス
業務時間外・一定間隔（ビーコン的）での定期的なAPI通信
通常使わないGoogle/SaaSアカウントを用いた認証

2. systemd の永続化を監査する

Linuxサーバーで不審なsystemdサービスが仕込まれていないかを確認する。xaptのように正規ツールを装う名前に注意したい。

# 有効化されている systemd サービスを一覧（見覚えのない項目を精査）
systemctl list-unit-files --type=service --state=enabled

# 最近作成・変更されたユニットファイルを確認
ls -lat /etc/systemd/system/*.service /usr/lib/systemd/system/*.service | head

# 怪しいサービスの実体（ExecStart のバイナリパス）を確認
systemctl cat <service-name>

3. 不審なプロセスと一時ディレクトリを確認する

GRIDTIDEは/var/tmp/や/usr/sbin/にバイナリを置いていた。書き込み可能なディレクトリから実行されるバイナリや、root権限で動く見慣れないプロセスを洗い出す。

# /tmp・/var/tmp から実行されているプロセスを確認
ls -la /var/tmp /tmp
ps -ef --forest

# 不審なアウトバウンド接続（VPNブリッジ等）を確認
ss -tunp | grep ESTAB

4. EDRによる「振る舞い検知」を併用する

ネットワーク境界での検知が効きにくいぶん、エンドポイント側で挙動を捉える層が決め手になる。侵入直後の権限確認（id・whoami）、永続化設定、不審な子プロセス生成といった攻撃者の振る舞いをEDRで検知・アラート化する。MITRE ATT&CKのTTPにマッピングして検知ルールの抜けを点検すると効果的だ。

5. 公開されたIOCで自組織を点検する

GoogleはGRIDTIDEのIOC（バイナリのハッシュ値、C2サーバーのIPアドレス、ドメイン、YARAルール等）を公開している。これらを自組織のSIEM・EDR・プロキシログに照合し、過去にさかのぼって痕跡がないかを確認する。万一ヒットした場合はインシデント対応手順に沿って封じ込めと証拠保全を進める。

参考情報

Google Cloud Threat Intelligence / Mandiant: Disrupting the GRIDTIDE Global Cyber Espionage Campaign
Google Threat Intelligence Group（GTIG）: UNC2814 に関する分析・IOC公開
Mandiant: 通信事業者を狙う国家支援アクターの脅威動向