UNC2814の全体像：2017年から続く中国系スパイグループの標的と活動規模

UNC2814の全体像：2017年から続く中国系スパイグループの標的と活動規模

UNC2814は、Googleの脅威インテリジェンスグループ（GTIG）およびMandiantが2017年から追跡を続けている、中国政府との関与が疑われるサイバースパイグループです。2026年2月にGoogleが公開した報告書では、このグループが42か国53組織への侵害を確認済みとして認定され、さらに20か国以上で感染の疑いが指摘されました。その規模と持続性から、近年でも有数の広域スパイキャンペーンとして世界のセキュリティコミュニティに衝撃を与えています。

UNCという命名規則が示す分類上の意味と、既知APTグループへの統合未完了の理由

Mandiantにおける「UNC」という接頭辞は、「Uncategorized（未分類）」を意味します。これは、当該グループの活動が既知のAPTクラスターと十分に一致する証拠が揃っていないため、正式な帰属先APTとして統合するに至っていないことを示す命名規則です。UNC2814の場合、中国政府との関与が強く疑われながらも、現時点では既存の中国系APTグループへの統合が行われていません。

この「未統合」状態が維持される背景には、アトリビューション（帰属特定）に必要な複数の要件が同時に満たされていないという事情があります。具体的には、インフラの重複・マルウェアコードの共通性・オペレーターの行動パターンの一致・被害者の重複といった要素が、既知グループとの間で十分に確認されていません。Googleの報告書でも、UNC2814はSalt Typhoonをはじめとする他の中国系グループとの重複がゼロであると明示されており、独立したクラスターとして扱うべき十分な根拠が示されています。セキュリティ担当者にとって重要なのは、「UNC」が「疑わしくない」という意味ではなく、「帰属が確定していない高脅威グループ」であることを正しく理解することです。

2017年から追跡されてきた活動履歴と、70か国超に及ぶ地理的拡大の推移

GTIGがUNC2814の追跡を開始したのは2017年であり、約9年にわたって活動を継続してきたことになります。この長期間の活動は、単発的なキャンペーンではなく、戦略的・持続的な情報収集活動であることを示す重要な指標です。2023年以降のアクティブなインフラに紐づくIoCが今回公開されましたが、SoftEther VPN Bridgeの設定メタデータの分析から、このグループが特定のインフラを2018年7月から継続使用していた可能性が指摘されています。

地理的な拡大という観点では、確認済みの42か国に加え、疑い事例を含めると70か国以上に活動範囲が及ぶとGoogleは評価しています。被害は4大陸にまたがり、アフリカ・アジア・南北アメリカに集中しています。これほどの地理的広がりを持つキャンペーンは、標的に対する明確な戦略的意図と、長期にわたるインフラ整備・オペレーター育成を前提とします。Googleが「近年最も広範かつ影響の大きいキャンペーンのひとつ」と評価した背景には、この規模と継続性があります。

通信事業者と政府機関に集中する標的選定の背景：PRC系スパイ活動との整合性

UNC2814が主要標的として選定してきたのは、通信事業者（テレコム）と政府機関です。この標的選定は、中国政府系のサイバースパイ活動が歴史的に示してきたパターンと高い整合性を持ちます。通信事業者への侵入は、通話データ記録（CDR）の窃取、SMSメッセージの傍受、さらには各国の合法的傍受（Lawful Intercept）システムへのアクセスを可能にします。これにより、特定個人の行動追跡や通信内容の把握が実現します。

政府機関を標的とすることも、外交・安全保障・政策立案に関わる機密情報の収集という観点で戦略的合理性があります。今回のキャンペーンでは、氏名・生年月日・出生地・電話番号・有権者ID・国民IDといったPIIを保持するエンドポイントにGRIDTIDEが展開されたことが確認されています。Googleは、このPII収集パターンが「関心のある人物の特定・追跡・監視」を目的とする諜報活動の典型的行動と一致すると評価しています。標的選定の一貫性こそ、UNC2814が国家支援型アクターである可能性を示す有力な状況証拠のひとつです。

アフリカ・アジア・南北アメリカを横断する被害分布と、地域ごとの侵害件数の差異

UNC2814の被害は4大陸に及んでいますが、その分布は均一ではありません。Googleの報告書はアフリカ・アジア・南北アメリカを主要な被害地域として挙げており、欧州での侵害は相対的に少ないとされています。アフリカ・アジアにおける通信インフラは、先進国と比較してセキュリティ成熟度のばらつきが大きく、パッチ適用やエッジシステムの管理が追いついていないケースも多いため、攻撃者にとって侵入難度が低い標的が存在しやすい環境です。

また、アフリカ・アジアの多くの国々では政府系通信事業者が通信インフラを運営しており、一度の侵害で政府・通信双方の情報へのアクセスが可能になるという構造的な脆弱性があります。南北アメリカについては、政治的・外交的観点で価値の高い標的が存在するため、高リスク国として位置づけられています。疑い事例を含めた70か国超という広がりは、地域を選ばずスケールアウトする能力をUNC2814が持つことを示しており、特定地域に限定した防御策では対応が不十分であることを示唆しています。

「最も広範かつ影響の大きいキャンペーン」とGoogleが評価した根拠となる3つの指標

Googleが今回のキャンペーンを「近年最も広範かつ影響の大きいもののひとつ」と位置づけた根拠は、主に3つの指標に集約されます。第一は規模の広大さです。確認済み42か国53組織という数字は、単一のキャンペーンとして異例の広がりであり、疑い事例まで含めれば70か国を超えます。第二は持続期間の長さです。少なくとも2017年から追跡され、一部インフラは2018年から継続使用されているという事実は、このグループが短期的な金銭目的ではなく、長期的な情報収集を目的とした組織的活動を行っていることを裏付けます。

第三は標的の戦略的重要性です。通信事業者と政府機関という、国家安全保障に直結するインフラへの集中的な侵害は、個人情報窃取や金銭目的のランサムウェアとは異なる次元の脅威を意味します。Googleは53組織すべてに対して正式な被害通知を行い、確認済みの侵害に対する対応支援を積極的に実施しています。この対応規模自体が、Googleが本キャンペーンをどれほど深刻に評価しているかを示しています。セキュリティ担当者は、この3つの指標を自組織のリスク評価に照らし合わせ、自社が潜在的な標的に含まれる可能性を検討する必要があります。

GRIDTIDEバックドアの技術構造：Google Sheets APIをC2チャネルに転用する攻撃の仕組み

GRIDTIDEは、UNC2814が今回のキャンペーンで展開した独自開発のバックドアです。最大の技術的特徴は、Google SheetsのAPIをコマンド&コントロール（C2）チャネルとして悪用する点にあります。セキュリティ製品が正規のGoogleサービスへのAPIトラフィックをブロックすることは困難であるため、このアプローチは検出回避において非常に高い効果を持ちます。以下では、その技術構造を詳細に解説します。

GRIDTIDEがC言語ベースで実装されている設計上の理由と、3つのコア機能の詳細

GRIDTIDEはC言語をベースに実装された高度なバックドアです。C言語が選択されている理由として、まずバイナリサイズの小ささと実行効率の高さが挙げられます。標的環境に長期間潜伏するバックドアにとって、フットプリントの小ささは検出を困難にする重要な要件です。また、C言語で書かれたコードは、OS標準のライブラリとの連携が容易であり、Linuxシステム上でのシステムコール呼び出しやプロセス制御において高い柔軟性を発揮します。

機能面では、Googleの公式技術分析が明示する3つのコア機能として、任意のシェルコマンド実行・ファイルのアップロード・ファイルのダウンロードが実装されています。これらはシンプルですが、攻撃者が一度侵入に成功すれば、その後の偵察・横移動・データ収集・追加ツールの展開に必要な最低限の操作がすべて可能になります。また、起動時にはGoogle Sheetsの先頭1000行（A〜Z列）をbatchClear APIで一括削除し、前セッションのコマンドやデータを消去してから通信を開始するという特徴的な動作も確認されています。

Google Sheetsのセル読み書きをコマンド伝達に使う双方向C2の動作フロー

GRIDTIDEのC2通信の核心は、Google Sheetsのスプレッドシートを「文書」としてではなく「通信チャネル」として扱う点にあります。セルごとに明確な役割が割り当てられており、攻撃者はA1セルにコマンドを書き込みます。インプラントはA1セルを1秒間隔でポーリングし、コマンドを検出すると即座に実行します。実行結果はS（Server）タイプのステータスメッセージとしてA1セルに返され、コマンド出力やファイルデータはA2以降の行にURLセーフBase64エンコードで格納されます。また、起動時にはV1セルに被害端末のユーザー名・ホスト名・OS情報・ローカルIPアドレス・タイムゾーンなどのフィンガープリント情報が書き込まれます。

ポーリング間隔については、コマンドが存在しない場合は1秒待機を繰り返し、120回試行しても新規コマンドがない場合は待機時間を5〜10分のランダムな間隔に自動切り替えします。これは攻撃者が非活動状態のときにネットワークノイズを低減するための実装です。すべてのトラフィックはHTTPS上のGoogle APIリクエストとして見えるため、企業ネットワークのファイアウォールやプロキシでの検出が非常に困難です。Googleの研究者は「攻撃者はシステムの弱点を突くのではなく、クラウドサービスが正常に機能することそのものを利用している」と表現しており、この戦術の巧妙さを端的に示しています。

AES-128 CBC方式による設定データ暗号化と、16バイト鍵ファイルの運用上の意味

GRIDTIDEは起動時に、ホスト上の別ファイルに保存された16バイトの暗号鍵を読み込みます。この鍵を使用してGoogle Driveの設定データをAES-128（Cipher Block Chaining：CBC）方式で復号します。設定データには、UNC2814が管理するGoogleスプレッドシートのIDと、そのシートにアクセスするためのGoogleサービスアカウントおよびプライベートキーが含まれています。

鍵ファイルをマルウェア本体とは別に保存するという設計は、静的解析による設定情報の即時特定を困難にするための意図的な実装です。バイナリを入手したとしても、対応する鍵ファイルがなければ設定データを復号できません。これは、フォレンジック調査やマルウェア解析において攻撃者の指揮系統を特定する難易度を高めます。一方、防御側にとっては、ホスト上に存在する不審な16バイトのバイナリファイルをハンティングすることが、GRIDTIDEの存在を検出する手がかりのひとつになり得ます。

Googleサービスアカウントを悪用したAPI認証の手口と、正規トラフィックへの偽装効果

GRIDTIDEは、攻撃者が管理するGoogleサービスアカウントを使用してGoogle Sheets APIに認証を行います。Googleサービスアカウントはクラウドアプリケーション開発において一般的に使用される認証メカニズムであり、それ自体は正規の機能です。攻撃者はこの正規機能を悪用することで、C2通信がAPIを通じた合法的なGoogleサービスへのアクセスとして見えるよう偽装しています。

この手口の検出が困難な理由は、Googleへの通信がHTTPSで保護されており内容の検査が難しいことに加え、企業のセキュリティポリシー上GoogleのAPIが許可リストに入っているケースが多いためです。Googleは今回の対応として、攻撃者が使用していたGoogleサービスアカウントとGoogle Workspaceを無効化し、該当するGoogle SheetsへのAPIアクセスを遮断しました。しかしこの種の手口は、攻撃者が別のクラウドサービスプロバイダや別のサービスアカウントに切り替えることで再現可能であるため、根本的な対策にはより深いクラウドトラフィック分析が必要です。

他のクラウドスプレッドシートへの転用可能性：GRIDTIDEが持つプラットフォーム非依存設計

Googleの技術分析レポートは、GRIDTIDEがGoogle Sheets以外のクラウドベーススプレッドシートサービスにも同様の手法で転用可能であることを明示しています。今回のサンプルはGoogle Sheets APIを利用していますが、マルウェアの設計思想はC2バックエンドとして機能するAPIエンドポイントに依存するものであり、特定サービスへの依存はコード修正によって容易に変更できます。

これが意味するのは、GoogleによるGRIDTIDEのC2インフラ破壊が即座に完全な無効化につながるわけではないという点です。UNC2814が今後活動を再開する際には、Microsoft OneDrive・Dropbox・Notion・Airtableといった他のSaaSプラットフォームをC2に転用した新バリアントを展開することが予測されます。防御側はGoogleへの通信に限らず、クラウドSaaSへの通信全般における異常パターンの検出を視野に入れる必要があります。特に、業務上の必要性が低いクラウドサービスへの定期的なAPIアクセスはアラートの対象として設定することが有効な対策となります。

42か国53組織への侵害実績：UNC2814が狙う通信・政府インフラと被害の実態

2026年2月18日時点でGTIGが確認した被害状況は、42か国53組織への侵害確定と20か国以上での感染疑いという規模に達していました。この数字は、UNC2814が長期間にわたってグローバル規模のオペレーションを維持していたことを示す客観的な証拠です。

確認済み53件・疑い事例20か国超という数字が持つ意味と、検出漏れリスクの推定

「確認済み53件」という数字は、Googleが積極的な調査と被害通知を実施した結果として得られた最低限の確定値です。疑い事例として挙げられている20か国以上は、完全な調査が完了していないか、アクセスが得られなかった組織が存在することを示唆しています。つまり、実際の被害範囲は公表数字を大きく上回る可能性があります。

検出漏れが生じやすい理由はいくつかあります。UNC2814がLotL（Living-off-the-Land）手法を多用し、既存の正規ツールをサイバー攻撃に転用することで独自ツールの展開を最小限に抑えていることが挙げられます。また、C2トラフィックがGoogle SheetsのAPIアクセスとして見えるため、ネットワーク上での異常検出が非常に困難です。多くの組織が自身の侵害に気づかないまま数年間にわたって監視され続けていた可能性があります。確認済み53件という数字を額面通りに受け取らず、「氷山の一角」として捉えることが適切なリスク評価につながります。

通信事業者を優先標的とする戦略的合理性：通話記録・SMS・合法傍受システムへの関心

UNC2814が通信事業者を優先的に標的とする理由は、テレコムインフラへのアクセスが持つ情報収集上の価値にあります。通話データ記録（CDR）には、誰がいつ誰と通話したかという通信メタデータが含まれており、特定人物の行動パターンや人間関係の把握に活用できます。SMSメッセージは暗号化されていない場合も多く、認証コードや個人間のやり取りを平文で入手できる可能性があります。

さらに深刻なのは、合法的傍受（Lawful Intercept）システムへのアクセスです。各国の通信事業者は法執行機関の要請に応じて通信内容を傍受・提供するシステムを保有していますが、このシステム自体に不正アクセスされると、実質的に国家レベルの監視能力を第三者が手に入れることになります。過去の中国系グループによるテレコム侵害事例（Salt Typhoonによる米国通信事業者への侵害など）でも、同様の能力の悪用が確認されています。UNC2814のテレコム集中標的戦略は、このような戦略的情報収集の観点から高い合理性を持っています。

PII（個人識別情報）を保持するエンドポイントへのGRIDTIDE展開と、収集データの種類

MandiantがUNC2814の調査で確認した重要な事実のひとつが、GRIDTIDEがPIIを含むエンドポイントに意図的に展開されていた点です。当該エンドポイントで確認されたデータ種別には、氏名・生年月日・出生地・電話番号・有権者ID番号・国民ID番号が含まれていました。これらは単なる個人情報ではなく、特定国の市民を一意に識別し追跡するために十分な情報セットを構成します。

Googleは、このPII標的パターンについて「通信分野のサイバースパイ活動と一致する行動であり、主に関心対象の人物を識別・追跡・監視するために活用される」と評価しています。また、過去の類似キャンペーンでは、こうした初期のデータ収集が通話記録の窃取・SMSメッセージの監視・合法的傍受能力の悪用へとエスカレートした事例が複数確認されています。GRIDTIDEが展開されたエンドポイントの種類と、そこに保存されていたデータの性質は、UNC2814が単なる知的財産窃取ではなく、人物レベルの諜報活動を目的としていたことを示す有力な証拠です。

データ持ち出しが直接観測されなかった理由と、過去の中国系侵害事例との類推による被害評価

Googleの報告書では「今回のキャンペーンにおいて、GTIGはUNC2814がデータを外部に持ち出したことを直接観測していない」と記述されています。この表現は慎重に読む必要があります。「直接観測されなかった」は「持ち出しが行われなかった」を意味しません。攻撃者が検出を避けるために慎重な方法で少量ずつデータを持ち出した場合、または調査開始前にすでに持ち出しが完了していた場合、観測の機会自体がなかった可能性があります。

過去の中国系スパイグループによるテレコム侵害事例との比較でいえば、類似した手口と標的を持つキャンペーンでは、CDRの大量窃取・平文SMSの傍受・合法的傍受システムの悪用が実際に発生しています。GTIGは「歴史的なPRC系諜報侵害では、通話データ記録・暗号化されていないSMSメッセージの窃取、および合法的傍受システムの侵害・悪用が発生している」と明示しており、被害評価を行う際には過去の類推に基づく最悪シナリオも考慮に入れることが適切だと示唆しています。被害通知を受けた組織は、直接の証拠がなくても広範囲な被害を前提としたインシデント対応を行うべきです。

被害通知を受けた53組織に対してGoogleが提供した対応支援の内容と範囲

Googleは今回の封じ込め作戦と並行して、侵害が確認された53組織すべてに対して正式な被害通知を実施しました。単なる通知にとどまらず、侵害が確認された組織に対しては積極的なインシデント対応支援も提供されています。この対応はMandiantのインシデントレスポンス能力を活用したものであり、ログ分析・フォレンジック調査・侵害範囲の特定・除去支援などが含まれます。

さらにGoogleは、2023年以降のUNC2814アクティブインフラに関連するIoC（Indicator of Compromise：侵害指標）を公開しました。これにより、被害通知を受けた組織以外でも、公開IoCを用いた自己調査が可能になっています。IoC公開という形での業界全体への貢献は、UNC2814に対する防御能力を広範に向上させる効果を持ちます。ただしIoCは時間の経過とともに陳腐化する可能性もあるため、公開後も継続的なアップデートと情報共有が重要です。被害を受けた可能性のある組織は、Googleの公開情報を起点として自社環境の独自調査を実施することが求められます。

初期侵入からPII窃取まで：LotLバイナリとSoftEther VPNによる長期潜伏戦術の全貌

UNC2814の攻撃チェーンは、初期侵入から長期潜伏・情報収集に至る一連のステップで構成されています。既存の正規ツールを最大限に活用し、独自ツールの使用を最小限に抑えることで、長期にわたる検出回避を実現しています。ここでは攻撃の全フェーズを順を追って解説します。

Webサーバー・エッジシステム攻略を起点とする初期アクセス手法と、未特定のベクター問題

UNC2814の初期アクセス方法として、Webサーバーやエッジシステムの脆弱性の悪用・侵害という歴史的なパターンが確認されています。しかし重要な点として、今回のキャンペーンにおける具体的な初期侵入ベクターは「調査中」のまま未特定です。これは、攻撃の痕跡が非常に丁寧に消去されていたか、ログの保存期間が侵害時点まで遡るには短かったか、あるいは複数の異なる手口が使われていたことを示唆します。

エッジシステム（VPNアプライアンス・ファイアウォール・ロードバランサーなど）の脆弱性悪用は、中国系APTグループが広く使用してきた初期侵入手口です。これらのシステムはインターネットに直接露出しており、パッチ適用の遅れやゼロデイ脆弱性が攻撃者の侵入口になりやすいという特性があります。初期侵入ベクターが特定できないという事実は、防御側にとって「どこから入られたか」を確定できないという困難を意味し、侵害範囲の全体像把握をさらに難しくします。この問題に対処するためには、エッジシステムのログを長期保存し、定期的な侵害評価（Compromise Assessment）を実施することが有効です。

SSHとサービスアカウントを使った横移動：既存インフラ悪用による検出回避の具体手順

初期侵入後、UNC2814は既存のサービスアカウントとSSHを使って内部ネットワークを横移動しました。この手法は「Living-off-the-Land（LotL）」戦術の典型例であり、組織内にすでに存在するツールと認証情報を使うことで、新規マルウェアの展開を最小限に抑えます。SIEMやEDRが「既知の悪意あるツール」を検出するシグネチャベースの手法では、この種の横移動を捕捉することが非常に困難です。

サービスアカウントを利用した横移動の特徴として、正規の管理者活動との区別が難しい点があります。特に、複数のシステムにわたるSSH接続が業務上一般的な環境では、この動作がアラートとして浮かび上がりにくくなります。防御側の観点では、サービスアカウントのSSH利用を通常業務上必要な範囲に限定し、通常とは異なる時間帯や接続元からのSSHアクセスを検出するベースラインベースのルールを整備することが有効な対策となります。加えて、最小権限の原則（Least Privilege）の徹底とサービスアカウントの定期的な棚卸しも重要です。

systemdサービス登録とnohupによる永続化：/etc/systemd/system/xapt.serviceの設置手順

UNC2814は標的環境への永続化（Persistence）を実現するため、Linuxのsystemdサービスとしてマルウェアを登録しました。具体的には、/etc/systemd/system/xapt.serviceにサービスユニットファイルを作成し、マルウェアのバイナリを/usr/sbin/xaptに配置しています。このサービスが有効化されると、システム再起動後も/usr/sbin/xaptから新たなインスタンスが自動的に起動します。

また、初回実行時にはnohup ./xaptというコマンドでGRIDTIDEを起動しています。nohupはターミナルセッションの終了後もプロセスを継続して実行させるUnixコマンドであり、セッション切断後も攻撃者の侵入ツールが動き続けることを保証します。これらの永続化手法はLinuxシステムに精通した攻撃者が使う一般的な手法ですが、標準的なシステム管理ディレクトリへの書き込みには通常root権限が必要です。この手法の検出には、systemdサービスの新規登録を監視するauditdルールの設定や、/usr/sbin/ディレクトリへの不審なファイル追加を検知するFIM（File Integrity Monitoring）の導入が有効です。

SoftEther VPN Bridgeの2018年から継続使用：中国系複数グループとの共通点と特異性

UNC2814はSoftEther VPN Bridgeを展開し、外部IPアドレスへの暗号化されたアウトバウンド通信路を確立していました。VPN設定のメタデータ分析から、このインフラが少なくとも2018年7月から継続使用されていたことが判明しています。SoftEther VPNは日本の筑波大学が開発したオープンソースのVPNソフトウェアであり、商用VPN製品と比べてファイアウォールを通過しやすい特性を持つため、中国系APTグループを含む複数の脅威アクターに悪用されてきた実績があります。

SoftEther VPNの使用が複数の中国系グループに共通するという事実は興味深い点ですが、これだけでUNC2814を特定グループと結びつけることはできません。UNC2814に固有の特異性として注目すべきは、同じVPNインフラを8年近く使い続けているという運用上の一貫性です。通常、長期オペレーションではインフラをローテーションすることがOPSEC（作戦セキュリティ）の基本ですが、この特定インフラの長期使用は、UNC2814が検出リスクよりも運用継続性を優先する判断をしていたか、または高いOPSEC意識を持ちつつも特定インフラへの依存度が高かったことを示しています。

LotLバイナリを中心とした偵察・権限昇格・バックドア展開の一連の攻撃チェーン

UNC2814の攻撃チェーンは、正規バイナリを最大限に活用したLotL戦術を軸に構成されています。偵察フェーズでは、sh -c id 2>&1というコマンドを実行してシステムのユーザー・グループIDを確認しており、root権限への昇格が成功したかどうかを確認する典型的な偵察手順を踏んでいます。この種の偵察は通常のシステム管理作業と見分けがつきにくく、文脈なしには悪意ある行動として検出が難しいという特性があります。

全体の攻撃チェーンを整理すると以下のような流れになります。まずエッジシステムやWebサーバーへの初期侵入を行い、次にSSHとサービスアカウントを使った横移動で内部ネットワークに展開します。その後、systemdサービス登録とnohupによる永続化を実施し、GRIDTIDEをnohup経由で起動してGoogle Sheets APIを通じたC2通信を確立します。さらにSoftEther VPN Bridgeを展開して外部との暗号化通信路を確保し、最終的にPIIを保持するエンドポイントへのアクセスと情報収集を行います。LotL手法を核とするこの攻撃チェーンは、各フェーズが単独では無害に見えるよう設計されており、一連の文脈を把握した全体的な監視なしには検出が極めて困難です。

Salt Typhoonとの明確な相違点：中国系APT群の中でUNC2814が持つ固有の位置づけ

2025年から2026年にかけて注目を集めたSalt Typhoonによる米国通信事業者への侵害事案と、UNC2814のキャンペーンは、いずれも通信インフラを標的とした中国系グループとして並べて論じられることがあります。しかしGoogleの報告書は、この2つのグループに重複はないと明確に述べています。以下では両者の違いと、UNC2814の独自の位置づけを整理します。

Salt Typhoonとの重複がゼロである根拠：標的・TTP・インフラ3軸での比較検証

GTIGは、UNC2814とSalt Typhoonの間に「観測された重複はない」と断言しています。この評価は、標的・TTP（戦術・技術・手順）・インフラの3軸にわたる比較分析に基づいています。標的の面では、両グループは異なる組織・地域を対象としており、同一組織への重複侵害は確認されていません。TTPの面では、C2チャネルの構成・マルウェアの種類・横移動の手法・永続化の方法においてそれぞれ異なるパターンを持ちます。

インフラの面でも、使用するドメイン・IPアドレス・クラウドリソースに重複は確認されていません。Salt Typhoonは主に米国の通信大手を標的とし、通話記録の傍受能力を特に重視したとされていますが、UNC2814はアフリカ・アジア・南北アメリカという異なる地域の組織に集中しています。この3軸での非重複という評価は、単なる推測ではなく、GTIGが長年蓄積してきた追跡データに基づくものであり、高い信頼性を持ちます。セキュリティ担当者がインテリジェンスを活用する際は、類似点があるからといってグループを同一視しないことが、正確なリスク評価の前提条件となります。

中国系スパイグループに共通するSoftEther VPN使用と、UNC2814固有の技術的差別化要素

SoftEther VPNの悪用は、UNC2814に限らず複数の中国系APTグループに共通して見られる手法です。このツールの特性として、OpenVPN・L2TP・EtherIP・L2TPv3・IPsecなど多数のVPNプロトコルに対応しており、ファイアウォールやDPI（Deep Packet Inspection）による検出が難しいという点が攻撃者にとって魅力的です。したがって、SoftEther VPNの使用だけを根拠にしてグループを特定することはできません。

UNC2814が他の中国系グループと異なる技術的差別化要素として注目すべきは、Google Sheets APIをC2チャネルとして使用するGRIDTIDEという独自バックドアの開発・展開です。この手口は、MicrosoftのOneDriveやTeamsをC2に悪用する他グループの手法と概念は類似していますが、Googleのエコシステムを活用する独自実装として区別されます。また、C言語ベースの軽量バックドアとAES-128 CBCによる設定データの暗号化という技術的詳細も、コードレベルでの識別指標となります。これらの差別化要素は、将来の亜種が登場した際の帰属特定においても参照点として機能します。

PRC系APTの中でUNC2814が「未統合（UNC）」のまま維持されている分析上の判断基準

MandiantがUNC（未分類）のラベルを維持し続けている理由を理解するためには、グループ統合の判断基準を把握する必要があります。Mandiantのアトリビューション方法論では、ツールセットの共通性・インフラの重複・被害者集合の重複・戦術・技術・手順の類似性・タイムゾーンや言語の特徴など、複数の独立した指標が一定閾値以上一致した場合に既知グループへの統合が行われます。

UNC2814の場合、中国政府との関与を示す状況証拠（PRC系の標的パターン・SoftEther VPNの使用・テレコム集中）は揃っているものの、既存の特定APTグループとの間で必要な技術的一致が確認されていません。この状態は「証拠が弱い」ことを示すのではなく、「独立したクラスターである」という分析判断を反映しています。UNCステータスは定期的に見直されており、今後の調査進展によって特定APTグループへの統合が行われる可能性は十分にあります。防御側はUNCステータスを「脅威レベルが低い」と誤解せず、「帰属が確定していない高度な国家支援グループ」として扱うことが重要です。

通信インフラ標的という共通点を持ちながら異なる手口をとる理由：組織別役割分担の仮説

Salt TyphoonとUNC2814が同じ通信インフラを標的としながら異なる手口・地域・被害者を持つという事実は、中国のサイバースパイ体制における組織的な役割分担という仮説を示唆しています。中国のサイバー諜報能力は、人民解放軍（PLA）・国家安全部（MSS）・民間のAPT-for-hireグループなど複数の主体によって担われていると言われており、各主体が異なる地域・分野・目的に特化した活動を行っている可能性があります。

この仮説が正しければ、UNC2814はアフリカ・アジア・南北アメリカの通信・政府インフラに特化したオペレーションを担当する組織に帰属し、Salt Typhoonとは別の指揮命令系統の下で動いていることになります。直接の証拠はないものの、この種の組織的役割分担は複数の独立したグループが同一分野で活動しながら重複を避けている説明として整合性があります。セキュリティ担当者の観点では、中国系の脅威は「一枚岩」ではなく複数の独立したグループによって構成されていることを前提とし、各グループの固有TTPに応じた個別の対策を講じる必要があります。

公開帰属が確定しない現状でセキュリティ担当者が意思決定すべき実務上の対処方針

帰属が確定していないという状況は、セキュリティ担当者の意思決定を複雑にします。しかし実務上は、帰属の確定を待って対策を行う必要はありません。公開されているIoC・TTP・マルウェアの特性に基づいた防御策は、帰属が未確定であっても十分に有効です。重要なのは「どの国のどの組織が攻撃しているか」よりも「どのような手口で攻撃されているか」であり、後者に基づいた防御がより実践的です。

実務上の対処方針として最優先すべきは、公開されたIoCをSIEMに投入し過去ログへの遡及検索を実施することです。次に、Google SheetsをはじめとするSaaSへのAPIアクセスパターンの異常検出ルールを整備し、systemdサービスの新規登録やLotLバイナリの不審な実行を検知する仕組みを強化します。組織が通信事業者または政府機関である場合は、UNC2814の標的プロファイルに完全に合致するため、特に高い優先度での対応が求められます。帰属の確定は脅威インテリジェンス分析上重要ですが、防御策の実施を待つ理由にはなりません。

Googleによる2026年2月の封じ込め作戦：インフラ破壊の具体的手順と達成した成果

2026年2月18日、GTIGとMandiantは業界パートナーと協調して、UNC2814のキャンペーンに対する大規模な封じ込め作戦を実施・公表しました。この作戦は、民間企業が主導するサイバースパイインフラの破壊事案として、その規模と方法論において注目に値します。

GTIGとMandiantが協調した作戦設計：民間脅威インテリジェンス主導の封じ込めモデル

今回の封じ込め作戦は、GTIGによる長期的な脅威追跡とMandiantのインシデントレスポンス活動が有機的に結びついた形で実現しました。MandiantがGoogle Security Operations（SecOps）を活用してグローバルな顧客ベースを継続的に監視する中で、CentOSサーバー上の不審な動作を検知するアラートが発端となりました。この検知が、UNC2814キャンペーン全体の解明につながる調査のきっかけとなったとされています。

民間企業主導による国家支援型脅威アクターのインフラ破壊という今回のモデルは、政府機関が主導してきた従来のアトリビューション・サンクション・起訴という対応枠組みとは異なるアプローチです。Googleはクラウドプロバイダーとしての地位を活かし、攻撃者が悪用していたGoogle Cloud上のリソースを直接制御・無効化できるという強みを持ちます。この種の民間主導封じ込め作戦が増加しているという傾向は、国家支援型サイバー脅威への対応において民間セクターが担う役割の拡大を示しています。

Googleクラウドプロジェクト全停止・ドメインシンクホール・APIアクセス遮断の3段階措置

今回の封じ込め作戦において、Googleが実施した具体的な措置は3つの柱で構成されています。第一は、攻撃者が管理していたすべてのGoogleクラウドプロジェクトの停止です。これにより、GRIDTIDEがC2チャネルとして利用していたGoogle Sheetsドキュメントへのアクセスが遮断されました。第二は、現在および過去のドメインのシンクホール化です。攻撃者が使用していたインフラに関連するドメインを攻撃者の制御から切り離し、侵害された環境からの接続先を研究者が管理するサーバーにリダイレクトすることで、残存するインプラントの活動を監視しつつ攻撃者との通信を遮断しました。

第三は、攻撃者が管理していたアカウントの無効化とGRIDTIDEが使用していたGoogle Sheets APIへのアクセス遮断です。これらの措置は組み合わせることで、インプラントの通信路・コマンド受信源・認証手段のすべてを同時に無効化するという効果を持ちます。単一の措置では攻撃者が代替手段に切り替えてしまう可能性がありますが、複数の経路を同時に閉じることで再確立のコストを最大化するという設計が見てとれます。

2023年以降のアクティブなインフラに紐づくIoCの公開：提供情報の種類と活用可能期間

Googleは封じ込め作戦の発表と同時に、UNC2814のアクティブなインフラに紐づくIoCを公開しました。公開されたIoCには、2023年以降に活動が確認されたインフラに関連する情報が含まれています。IoC（侵害指標）には一般的に、既知の悪意あるIPアドレス・ドメイン名・ファイルハッシュ（マルウェアバイナリの識別子）・ファイルパス・レジストリキーなどが含まれます。

IoC活用における重要な注意点として、公開後の有効期間の問題があります。攻撃者はインフラを更新することでIoCを無効化できるため、特にIPアドレスやドメインについては公開後比較的短期間で陳腐化する可能性があります。一方、マルウェアのハッシュや特徴的なファイルパス（/etc/systemd/system/xapt.service、/usr/sbin/xaptなど）は、攻撃者がコードを大幅に書き換えない限り有効性を維持します。防御側はIoCをSIEMに投入するだけでなく、TTP（戦術・技術・手順）レベルの理解に基づいたより堅牢な検出ロジックを構築することが長期的な防御効果を高めます。

封じ込めがUNC2814の再構築を「大幅に遅らせる」と判断された技術的・運用的な根拠

Googleは今回の封じ込め作戦について、「UNC2814のグローバルなフットプリントの再確立を大幅に遅らせる」と評価しています。この評価の根拠は2つの側面から説明できます。技術的な側面では、インフラのシンクホール化によって既存のインプラントがC2と通信できなくなり、データ収集と新規コマンドの受信がすべて停止します。既存の侵害環境は実質的に「切断」された状態となります。

運用的な側面では、このような広域インフラの構築には数年単位の時間と相当のリソースが必要です。70か国超の組織への侵入・インプラントの展開・C2インフラの整備は一朝一夕には行えません。Googleは「このような規模の侵害は、何年もの集中した努力の結果であり、容易に再確立できるものではない」と明記しています。ただし「大幅に遅らせる」という表現にある通り、永続的な無効化を約束するものではありません。UNC2814が新たなインフラ・ツール・C2プラットフォームを使って活動を再開することはGoogleも予測しており、継続的な監視と防御態勢の維持が不可欠です。

今後の再拡大リスクとGoogleが予測するUNC2814の次の動き：フットプリント再建の蓋然性

Googleの報告書は、UNC2814がフットプリント（侵害範囲）の再構築に向けて積極的に動くことを「予測」として明記しています。これは脅威アクターの行動パターンに関する合理的な推定です。国家支援型グループが長年かけて構築したオペレーション能力を、単一の封じ込め作戦によって完全に放棄することは考えにくく、特にUNC2814のような持続的・戦略的な活動を行うグループにとっては「再建」が当然の次の動きとなります。

再建の際には、これまで使用してきたGRIDTIDEのC2バックエンドをGoogle Sheets以外のクラウドサービスに変更したり、新たなマルウェアファミリーを開発したり、初期アクセス手法を変更するといった技術的な刷新が予想されます。また、SoftEther VPN Bridgeに代わる別のトンネリングツールへの切り替えも考えられます。防御側は、公開されたIoCの一致を確認するだけでなく、GRIDTIDEの行動的特徴（SaaSへの定期ポーリング・LotL手法による横移動・systemdサービスを悪用した永続化）に基づいた検出ロジックを維持することが、次のキャンペーンへの対応準備として重要です。

セキュリティ担当者が取るべき防御策：UNC2814検出・対応・IoC活用の実務ポイント

UNC2814の封じ込めが発表された今、セキュリティ担当者にとって最も重要なのは、自組織が過去または現在の被害対象である可能性を調査し、再発に備えた防御態勢を整えることです。以下では実務担当者が具体的に取るべき行動を解説します。

公開IoCの入手先と、SIEMへの投入・ハンティングルール整備の具体的な実施手順

UNC2814関連のIoCはGTIGおよびMandiantが公式ブログで公開しており、Google Cloud Blogの該当記事（「Disrupting the GRIDTIDE Global Cyber Espionage Campaign」）が一次情報源です。また、MISPやOpenCTIといった脅威インテリジェンスプラットフォームでも共有されている可能性があります。VirusTotal・AlienVault OTXといったコミュニティプラットフォームでも参照できることが多いため、複数ソースでの確認を推奨します。

SIEMへの投入手順については、まず公開されたIPアドレス・ドメイン・ファイルハッシュ・ファイルパスをCSVまたはSTIX形式で取得し、自組織のSIEMが対応するフォーマットに変換します。次に、直近30日以上の過去ログに対して遡及検索（Retrospective Search）を実施し、既存の侵害の痕跡がないかを確認します。ハンティングルールとしては、既知のファイルパス（/etc/systemd/system/xapt.service、/var/tmp/xapt、/usr/sbin/xapt）へのアクセスや作成を検知するルールが特に有効です。IoCの鮮度管理も重要であり、定期的な更新フローを組み込んだ運用設計が長期的な防御効果を維持します。

Google Sheets APIを経由するC2トラフィック検出に有効なログ監視とネットワーク分析の手法

GRIDTIDEが使用するGoogle Sheets API経由のC2トラフィックは、正規のGoogle APIアクセスと見分けがつかないという難しさがあります。しかし完全に検出不能というわけではなく、行動的な特徴に着目することで異常を検出できる可能性があります。まず注目すべきは、業務系端末ではなくサーバー（特にCentOSなどのLinuxサーバー）からGoogle Sheets APIへの定期的なリクエストが発生している場合です。GRIDTIDEはbatchClear・batchUpdate・valueRenderOption=FORMULAなどの特定APIエンドポイントを使用しており、これらがブラウザ以外のプロセスから呼び出されている場合は特に疑わしい兆候です。

Google Security Operationsを利用している場合、GTIGが公開している以下のUDMクエリが不審なGoogle Sheets API接続の検出に活用できます。

target.url = /sheets\.googleapis\.com/
( target.url = /batchClear/ OR target.url = /batchUpdate/ OR target.url = /valueRenderOption=FORMULA/ )
principal.process.file.full_path != /chrome|firefox|safari|msedge/

このクエリは、ブラウザ以外のプロセスがGRIDTIDEの使用するGoogle Sheets APIメソッドを呼び出している状況を検出するものです。あわせて、/var/tmp/配下の短いアルファベット小文字ファイル名（1〜10文字）からシェルが起動されるプロセスツリーの検出も有効です。これらの検出手法をシグネチャベースの検出と組み合わせることで、GRIDTIDEの初期展開を早期に発見できる可能性が高まります。

SoftEther VPN Bridgeの存在確認とsystemdサービス不審登録の検出コマンド例

Linux環境において、UNC2814が使用した永続化手法とVPNツールの存在を確認するためのコマンドを以下に示します。

• 不審なsystemdサービスの確認：systemctl list-units --type=service | grep -v "loaded active" または ls -la /etc/systemd/system/*.serviceで直近の追加ファイルを確認する
• xaptバイナリの存在確認：find / -name "xapt" 2>/dev/nullで全パスを探索する
• SoftEther VPN関連プロセスの確認：ps aux | grep -i softether または ps aux | grep -i vpnbridgeで稼働中のプロセスを確認する
• 不審なアウトバウンド接続の確認：ss -tnp | grep ESTABLISHEDで確立済みの外部TCP接続を確認する

これらのコマンドは定期的なヘルスチェックスクリプトに組み込み、結果を集中ログ管理システムに送信する運用が推奨されます。特に/var/tmp/や/usr/sbin/への不審なバイナリ配置は通常の運用では発生しないため、FIM（File Integrity Monitoring）ツールによるリアルタイム監視の対象として設定することが効果的です。

エッジシステム・Webサーバーのパッチ管理優先度：UNC2814初期アクセス手口を踏まえたリスク評価

UNC2814はWebサーバーやエッジシステムの脆弱性悪用を初期アクセス手口として使用してきた歴史があります。このことは、インターネットに直接露出しているシステムのパッチ管理が最優先の防御策であることを再確認させます。特にVPNアプライアンス・ファイアウォール・ロードバランサー・リバースプロキシといったエッジシステムは、侵入口として頻繁に狙われるにもかかわらず、パッチ適用が遅れがちな傾向があります。

リスク評価の観点では、インターネット向けシステムのパッチ適用を最高優先度に設定し、CVSS 9.0以上の脆弱性については24時間以内、7.0〜8.9については72時間以内のパッチ適用を目標とすることが推奨されます。また、エッジシステムは定期的な脆弱性スキャンの対象とし、公開後のパッチリリースから適用完了までのサイクルタイムをKPI（重要業績評価指標）として管理することが望ましいです。Webサーバーについては、WAF（Webアプリケーションファイアウォール）の導入とルールの定期的な更新も初期侵入リスク低減に効果的です。

通信事業者・政府機関が最優先で実施すべきPII保護とインシデント対応体制の整備要件

UNC2814の標的プロファイルに完全に合致する通信事業者と政府機関は、一般企業と比較して特に高い水準の防御態勢が求められます。PII保護の観点では、PIIを保持するデータベースやエンドポイントへのアクセス制御を最小権限の原則で整備し、不必要なアクセスを一切排除することが第一ステップです。次に、PIIを保持するシステムへのアクセスログを集中管理し、異常なアクセスパターン（時間外アクセス・大量データ参照・新規アカウントからのアクセスなど）を自動検知するルールを整備します。

インシデント対応体制の整備については、まずUNC2814のIoCと行動特徴をインシデントレスポンスプレイブックに組み込み、検知から初動対応までの時間短縮を図ることが重要です。通信事業者については特に、合法的傍受システムへのアクセス管理とログ監視を強化し、外部からの不正なアクセス試行を即時検知できる態勢を整えることが求められます。また、Googleが公開した被害通知プロセスに倣い、ISACや国内のサイバーセキュリティ機関（日本ではNISCなど）との情報共有体制を平時から確立しておくことが、今後の類似キャンペーンへの早期対応に直結します。