C2 とは?

C2（C&C、Command and Control）とは

C2 は「Command and Control」の略です。サイバーセキュリティでは、攻撃者が侵害したシステムを遠隔操作するために命令を送り、実行結果を受信する通信行為と、それに用いるチャネルやインフラ全般を意味します。攻撃者は、感染したシステムの環境を把握し、必要な機能を追加したり、社内ネットワークを探索したり、収集した情報を外部へ送信したりする際に C2 を利用します。感染システムは C2 インフラへ接続して命令を確認し、マルウェアは命令を実行した後、その結果を送信します。

MITRE ATT&CK は C2 を、攻撃者が侵害したシステムと通信し、指揮・制御を行うための戦術に分類しています。C2 通信には、アプリケーション層プロトコル、プロキシ、動的なアドレス解決、暗号化チャネル、Web サービスなど、さまざまな技術が使われます。そのため C2 は、特定のサーバーや 1 つのマルウェアを指す概念ではなく、攻撃者が侵害したシステムとの通信と制御に用いるチャネルや方式全般を意味します。

C2 の主な機能と役割

C2 は、侵入後に攻撃者がさまざまな攻撃活動を実行するために利用されます。攻撃者は C2 を使ってシステム情報を収集し、命令を実行するほか、追加のマルウェアを送信したり、ファイルを窃取したりします。セキュリティツールの無力化、社内システムへの移動、ランサムウェアの配布など、後続攻撃の指示も可能です。C2 を通じて侵害システムの状態と収集情報を確認し、状況に応じた新たな命令を送って攻撃を継続できるため、同じマルウェアに感染したシステムでも、C2 の接続状態とその後の命令によって、実際の攻撃行為や被害範囲が異なる場合があります。

攻撃の過程では、必要に応じて C2 チャネルを追加・変更することもあります。攻撃者は、感染直後に構築したチャネルとは別の通信経路を作成したり、既存の接続が遮断されると代替サーバーや別のプロトコルへ切り替えたりします。そのため、C2 通信を早期に検知して遮断することは、後続の命令伝達を阻止し、被害の拡大を抑えるうえで重要です。

C2 通信のプロセス

C2 通信の実装方式は攻撃ツールによって異なりますが、基本的な流れは共通しています。攻撃者は、フィッシング、脆弱性の悪用、流出したアカウント、サプライチェーン侵害などによってシステムへアクセスした後、マルウェアや遠隔操作ツールを実行し、外部の C2 インフラと通信する準備を整えます。最初に C2 へ接続する際、マルウェアから感染システムのホスト名、OS、ユーザーアカウント、IP アドレス、セキュリティ製品、実行権限などの環境情報が送信される場合もあります。攻撃者はこれを基に、感染システムの環境と状態を把握します。

登録を終えたマルウェアは、一定の間隔で C2 インフラへ接続し、新しい命令を確認します。これをビーコニング（beaconing）またはコールバックと呼びます。規則的な通信は検知されやすいため、攻撃者は接続間隔にランダムな変動値を加え、一定時間待機してから通信を開始したり、業務時間帯だけ接続したりするよう設定することがあります。

命令を受けたマルウェアは、プロセスやファイルの一覧取得、画面キャプチャ、コマンドシェルの実行、アカウント情報の収集、追加ファイルのダウンロードなどを行います。作業結果は、既存の C2 チャネルまたは別のチャネルから送信します。攻撃者は収集した情報を基に新たな命令を出せるため、マルウェアで事前に確認された機能だけから実際の攻撃範囲を把握するのは困難です。

攻撃の終了後も C2 通信が続く場合があります。確認されたマルウェアを削除しても、タスクスケジューラ、サービス、スタートアッププログラム、Web シェル、追加アカウントなどが残っていれば、攻撃者がそれらを利用して再び C2 へ接続する可能性があります。

C2 インフラの構成方式

C2 インフラは命令伝達の構造によって、中央集約型、多層・プロキシ型、P2P 型、Web サービス型、ハイブリッド型に分かれます。実際の攻撃では、メインチャネルと代替チャネルを分けたり、複数の構造を組み合わせて運用したりするケースが多くあります。

構造	動作方式	セキュリティ上の特徴
中央集約型	感染システムが 1 台または少数の C2 サーバーへ接続	サーバーとドメインを特定できれば、比較的迅速に遮断できます。アドレス変更やサーバーの切り替えに備える必要があります。
多層・プロキシ型	感染システムと実際の制御サーバーの間に、リダイレクター、プロキシ、中継サーバーを構築	外部へ公開されたサーバーを遮断しても運営インフラが残る場合があり、追跡が複雑です。
P2P 型	感染デバイス同士が命令や接続情報を伝達	単一サーバーに依存しないため、ネットワーク全体の無力化が困難です。
Web サービス型	クラウドストレージ、コードリポジトリ、ソーシャルメディアなどの正規サービスを介して命令やアドレスを伝達	正規の業務トラフィックに混在するため、サービス全体を遮断するのは困難です。
ハイブリッド型	複数方式の C2 インフラを併用	メインチャネルが遮断されても、別の経路から制御を復旧できます。

中央集約型は構造が単純で、運用しやすい方式です。感染システムは、あらかじめ設定されたドメインや IP アドレスへ接続して命令を取得します。この方式では、サーバーを特定して遮断または無力化すれば、感染システムとの通信を切断し、攻撃者による命令伝達と後続攻撃を阻止できます。このため攻撃者は、複数のドメインを用意してサーバーアドレスを素早く変更したり、多層・プロキシ型のように実際の C2 サーバーを中継サーバーの背後へ隠したりして、この弱点を補います。

P2P 構造では、感染デバイスがサーバーとクライアントの両方の役割を担い、ほかのデバイスへ命令を伝えます。役割が分散しているため、一部のデバイスを排除してもネットワークが維持される場合があります。攻撃者は、すべてのデバイスへ一貫した命令を迅速に配布し、通信状態を管理する必要があるため、中央集約型より運用と制御が複雑です。

Web サービス型は、正規サービスを C2 通信へ悪用する方式です。攻撃者は、公開された投稿やファイル、API などに暗号化した命令や C2 サーバーのアドレスを保存し、感染システムはその情報を取得して次の動作を実行します。正規サービスと同じインフラを使用するため、ドメインや IP アドレスだけで悪意のある通信を区別するのは困難です。サービス全体を遮断すると、正規の業務にも影響する可能性があります。そのため、接続したプロセスやアカウント、リクエスト内容、通信時刻など、周辺の振る舞いも併せて分析し、悪意の有無を判断しなければなりません。

C2 の通信方式

攻撃者は C2 通信を維持しながら検知を逃れるため、対象組織で日常的に使われ、外部通信が許可されているプロトコルを主に悪用します。代表的な方式が HTTP と HTTPS です。どちらも一般的に Web アクセスへ使われるため、C2 の命令や実行結果を Web のリクエストとレスポンスの形式でやり取りすると、正常なインターネット通信との区別が難しくなります。

HTTPS ベースの C2 通信は送信内容が暗号化されており、ネットワーク区間で命令やデータを直接確認するのが困難です。また、正常な Web 通信でも HTTPS を使用するため、暗号化の有無、有効な証明書、443 番ポートの使用だけでは、正常な通信と C2 通信を区別できません。そのため、通信先、接続プロセス、接続周期、転送量など、複数の情報を併せて分析する必要があります。

DNS も C2 チャネルとして使われます。感染システムが攻撃者のドメインのサブドメインへデータを含めて問い合わせたり、DNS レスポンスから短い命令を受け取ったりすることがあります。DNS はネットワーク運用に不可欠であり、小さなリクエストが継続的に発生するため、悪意のある通信を正常な問い合わせの中へ隠しやすくなります。

このほか、メール、ファイル転送プロトコル、メッセージングサービス、リモート管理ソフトウェア、独自の TCP・UDP プロトコルが使われる場合もあります。攻撃者は、組織のネットワークポリシーと検知環境を把握した後、正常な業務で頻繁に使われ、検知されにくいプロトコルやサービスを C2 通信に利用します。

通信方式	通信方法	主な検知項目
HTTP・HTTPS	Web のリクエストとレスポンスを利用して C2 の命令を伝え、実行結果を受信	プロキシログ、URL、ヘッダー、証明書、接続プロセス、反復周期
DNS	ドメインの問い合わせとレスポンスに命令またはデータを含める	長いサブドメイン、文字列の高いランダム性、過剰な TXT 問い合わせ、異常な問い合わせ量
クラウド・Web サービス	投稿、ファイル、API を命令の伝達手段として使用	許可されていないアプリケーションによる API 呼び出し、業務と無関係なサービスへの接続
独自プロトコル	特定のポートと独自のメッセージ形式を使用	非標準ポート、プロトコルの不一致、未知の外部接続先
リモート管理ツール	正規のリモートサポート機能を攻撃者が悪用	承認されていないインストール、異常なアカウント、通常とは異なる接続時間と接続先

C2 通信の隠蔽手法

攻撃者は C2 通信を一般的なネットワークトラフィックと簡単に区別できないよう、データ形式、通信周期、接続先アドレスなどをさまざまに変化させます。命令や実行結果を Base64 などでエンコードしたり、不要なデータを混ぜたり、正規プロトコルに似た形式へ偽装したりします。画像や文書内に情報を隠すステガノグラフィが使われる場合もあります。

通信周期を調整し、反復的な接続パターンを隠すこともあります。一定の間隔で C2 サーバーへ接続すると、ビーコン通信として検知される可能性が高まるため、攻撃者は接続間隔にランダムな変動値を加えるジッターを使用します。通信開始前に一定時間待機したり、特定の時間帯だけ接続したりするよう設定する場合もあります。1 回に送信するデータ量を減らし、長時間にわたって分割送信する方式も使われます。

C2 サーバーのアドレスを継続的に変更する方式もあります。ドメイン生成アルゴリズム（DGA）は、日付や特定の入力値を基に多数のドメインを生成し、攻撃者はその一部を実際の C2 通信に使用します。Fast Flux は、1 つのドメインへ紐づく IP アドレスを短い周期で変更し、C2 インフラの場所の追跡や遮断を困難にします。

正規のクラウドサービス、コンテンツデリバリーネットワーク（CDN）、Web サービスが C2 通信へ悪用される場合もあります。業務で使用する正規サービスと C2 トラフィックが同じドメインやインフラを利用する可能性があるため、IP アドレスやドメインのレピュテーション情報だけでは悪意のある通信かどうかを判断しにくくなります。サービス全体を遮断すると正規の業務にも影響するため、接続プロセス、アカウント、通信方式などの追加情報も併せて確認する必要があります。

C2 活動の主な検知ポイント

既知の悪意のある IP アドレスやドメインを遮断するだけでは C2 活動を阻止するのが難しいため、接続先情報だけでなく、ネットワーク通信とエンドポイントの活動を併せて確認しなければなりません。

反復的な外部通信

同じプロセスが特定の外部サーバーと継続的に少量のデータをやり取りしている場合や、複数のシステムが同じ接続先へ似た周期で接続している場合は、C2 のビーコン通信を疑う必要があります。ただし、ソフトウェアアップデートやシステム状態の確認機能も一定の周期で通信するため、反復的な接続だけで悪意があると断定してはなりません。

異常な DNS リクエスト

DNS ログでは、通常はアクセスしないドメイン、過度に長いサブドメイン、ランダム文字列に見える問い合わせ、特定の DNS レコードへ集中するリクエストなどを確認できます。1 台のシステムが短時間に、存在しない多数のドメインを繰り返し照会している場合は、DGA が使われている可能性も確認します。DNS リクエストを発生させたプロセス、プログラムのインストール時期、ユーザーの活動も併せて分析する必要があります。

エンドポイントの異常な活動

文書作成ソフトやスクリプトインタープリターが突然外部サーバーと通信した場合や、一時フォルダーから実行されたファイルがネットワーク接続を生成した場合は、追加の調査が必要です。新たに作成されたサービスやタスクスケジューラ、異常な PowerShell の実行なども主な確認対象です。プロセスの親子関係を分析すると、文書の実行後にスクリプトが動作し、外部の C2 サーバーへ接続する過程も把握できます。

プロキシとファイアウォールのログ

プロキシとファイアウォールのログでは、業務との関連が低い外部サーバーへの接続、最近作成されたドメイン、少量のデータを長時間やり取りするセッション、ポートと実際のプロトコルが一致しない通信などを確認できます。TLS 通信については、証明書情報、サーバー名、クライアントの特性、接続回数と周期などを併せて分析しなければなりません。

ログの相関分析

C2 を正確に検知するには、エンドポイント、DNS、プロキシ、ファイアウォールなど、複数領域のログを同じ時間帯を基準に分析する必要があります。単一のアラートだけを確認するのではなく、どのプロセスがどのアカウントで実行され、どの接続先とどのような方式で通信したかを関連付けて確認することで、実際の攻撃フローを把握できます。

C2 検知体制の設計

C2 を検知するには、まず社内システムの外部通信を追跡できる環境が必要です。ファイアウォールの許可・遮断記録だけでは、HTTPS 通信の詳細な振る舞いや、DNS リクエストを生成したプロセスまで把握するのが難しいため、エンドポイント情報とネットワークログを併せて分析できるようにしなければなりません。

正常な通信の基準は、システムの役割に応じて区別します。開発サーバーがコードリポジトリへ接続する場合と、財務システムが同じサービスへ接続する場合では、意味が異なる可能性があります。システムごとに通常利用する外部サービス、通信時間、データ転送量、許可されたアプリケーションなどを把握すれば、異常な C2 通信をより正確に区別できます。

脅威インテリジェンスは、すでに確認された C2 サーバーとドメインを迅速に特定するために利用できます。IP アドレスやドメインを自動的に遮断する前に、情報が確認された時点と信頼度、そのアドレスが複数のサービスで共同利用されているかなどを検討しなければなりません。過去に悪意のある活動へ使われた IP アドレスが後に正常なサービスへ割り当てられたり、1 つのクラウドアドレスを複数のサービスが共有したりする場合があるためです。

新たな C2 インフラは、通信の振る舞いを分析して検知する必要があります。反復的なコールバック、異常な DNS リクエスト、組織でほとんど利用しない外部接続先、業務と無関係なプロセスによるネットワーク接続などを併せて分析すると、個々の兆候だけを確認する場合より検知精度を高められます。ジッターが適用された C2 通信も、長期間の接続時刻、接続先、転送量を比較すれば、反復的な特徴が現れる場合があります。

検知ルールは、アラートを発生させるだけでなく、実際の調査につながるよう設計しなければなりません。分析担当者が元のログ、システム情報、ユーザー情報、プロセスの実行関係をすぐに確認できるよう構成します。侵害が確認された場合は、同じ接続先、ファイルハッシュ、証明書、プロセス、アカウントなどがほかのシステムでも見つかっていないか、直ちに検索できるようにする必要があります。

C2 が疑われる通信を発見した場合、何から始めるべきか

C2 通信が疑われる場合は、まず関連するシステムとアカウント、通信先、最初と最後の通信時刻を確認します。1 件のアラートだけで感染範囲を判断せず、同じ接続先や類似する通信の振る舞いがほかのシステムでも発生していないか調査しなければなりません。複数のシステムが同じ C2 インフラへ接続していた場合は、個々のシステムにとどまらず、組織内で感染が拡大している可能性も確認する必要があります。C2 通信が確認されたら、侵害の可能性が高いシステムをネットワークから隔離し、新たな命令の受信と内部への拡散を遮断します。ただし、システムの電源を直ちに切ると、メモリ内だけに存在するマルウェアや現在のネットワーク接続情報など、調査に必要なデータが失われる可能性があります。そのため、システムの重要度と攻撃の進行状況を考慮し、ネットワーク隔離、証拠収集、電源停止の順序を決めなければなりません。

確認された C2 ドメイン、IP アドレス、URL、証明書などの情報は、DNS セキュリティポリシー、ファイアウォール、プロキシ、エンドポイントセキュリティポリシーへ反映し、追加の通信を遮断します。正規のクラウドサービスや Web サービスが C2 へ悪用された場合は、サービス全体の遮断による業務への影響を確認しなければなりません。必要に応じて、URL、アプリケーション、アカウント、プロセスなどを基準に遮断範囲を細分化できます。

攻撃経路と被害範囲を把握するための証拠も確保します。実行中のプロセス、ネットワーク接続情報、DNS・プロキシ・ファイアウォールのログ、悪意のあるファイル、タスクスケジューラとサービス、ユーザーのログイン記録などを保存しなければなりません。このとき、C2 アドレスだけを遮断し、関連ファイルや実行記録を先に削除すると、初期侵入経路や攻撃者が実行した作業を確認しにくくなる可能性があります。

マルウェアを除去する際は、悪意のあるファイルだけでなく、タスクスケジューラ、サービス、レジストリ設定、Web シェル、追加で作成されたアカウントなど、攻撃者が再びアクセスするために利用できる要素も併せて確認します。アカウント情報が窃取された可能性がある場合は、パスワードを変更し、有効なセッションとトークンを失効させなければなりません。攻撃に悪用された脆弱性や誤った設定も併せて修正することで、再侵入の可能性を抑えられます。

復旧後も、既存の C2 サーバーとの通信が再び発生していないか確認する必要があります。以前とは異なる外部サーバーやプロトコルを利用して C2 通信を再開する可能性もあるため、一定期間、関連システムのネットワーク活動を集中的に確認します。インシデントの過程で確認された IP アドレス、ドメイン、ファイル、プロセス、通信パターンは、検知ルール、脅威ハンティングの条件、インシデント対応手順へ反映します。

C2 脅威を緩和するための運用原則

C2 のリスクを抑えるには、不要な外部通信を制限しなければなりません。サーバーと主要な業務システムでは、業務に必要な接続先とプロトコルだけに外部通信を許可するポリシーが有効です。インターネット接続が不要なシステムの外部通信を制限すれば、マルウェアが外部の C2 サーバーへ接続する可能性も低減できます。

DNS の利用環境も制御する必要があります。組織が承認した DNS サーバーを使用するよう設定し、DNS ログを一元的に収集すると、異常なドメイン照会を分析しやすくなります。エンドポイントが任意の外部 DNS サーバーや別の暗号化 DNS サービスを利用すると、DNS ベースの C2 通信を確認しにくくなる可能性があります。そのため、組織のセキュリティポリシーと業務環境に合った管理基準が必要です。

ネットワークを業務領域と資産の重要度に応じて分離すれば、感染システムからほかの社内システムへ攻撃が拡散する範囲を抑えられます。ユーザー領域、サーバー領域、重要情報システム、管理ネットワーク間の通信を業務に必要な範囲へ制限し、リモート管理ツールとスクリプト実行環境も、承認された管理者とシステムだけが利用できるよう制御しなければなりません。

OS とアプリケーションのセキュリティ更新、フィッシング対策、多要素認証、最小権限の適用、アプリケーション実行制御も、C2 接続が確立される前段階のリスク低減に重要です。ネットワーク侵入検知・防止システムは、既知のマルウェアの通信パターンやプロトコル特性の検知に利用できます。攻撃者はサーバーアドレスと通信形式を継続的に変更できるため、既知の侵害指標に基づく検知と振る舞いベースの検知を併用しなければなりません。

FAQ