MITRE ATT＆CKからセキュリティ対策を読み解く【第5回 C＆C（コマンド＆コントロール） 編】
前回までの活動は、フィッシングなどで外部から侵入した後、侵入先環境内にてマルウェアが単独で活動を行うパターンでした。
C&Cでは、マルウェアが外部の攻撃者と通信を行い、より高度な情報収集や攻撃につながって行きます。
目次
C&C とは
| Tactics（戦術） | 概要 |
|---|---|
| 初期アクセス（Initial Access） | ネットワークに侵入しようとしている。 |
| 実行（Execution） | 悪意のあるコードを実行しようとしている。 |
| 永続化（Persistence） | 不正アクセスする環境を確保しようとしている。 |
| 権限昇格（Privilege Escalation） | より高いレベルの権限を取得しようとしている。 |
| 防衛回避（Defense Evasion） | 検知されないようにしようとしている。 |
| 認証情報アクセス（Credential Access） | アカウント名とパスワードを盗もうとしている。 |
| 探索（Discovery） | アクセス先の環境を理解しようとしている。 |
| 水平展開（Lateral Movement） | アクセス先の環境を移動しようとしている。 |
| コマンドアンドコントロール（C＆C）（Command and Control） | 侵害されたシステムと通信して制御しようとしている。 |
| 収集（Collection） | 目標に関心のあるデータを収集しようとしている。 |
| 盗み出し（Exfiltration） | データを盗もうとしている。 |
| 打撃（Impact） | システムとデータを操作、中断、または破壊しようとしている。 |
C＆Cで行われる通信を「C＆C通信」、C＆Cの指令元となるサーバーを「C＆Cサーバー」と呼びます。
侵入先網内に広く水平展開（TA0008）した後、網内にC＆Cサーバーを設け、水平展開先と網内でC＆C通信をする場合もあります。
なお、「C＆C」を「C2」と表記することもあります。
C＆Cで使われる ATT＆CK Technique
侵入したマルウェアが、外部の攻撃者からの指令及び制御を受けるためには、なんらかの通信手段が必要です。
MITRE ATT＆CK では、C＆Cで使われるTechniqueとして、色々な通信手段が列挙されています。
本ブログではいつもはWindowsで使われるものに絞って紹介していますが、C＆Cについては通信Techniqueなので、プラットフォームに依存する部分はあまりありません。
以下のように、いくつかに分類できます。
通信経路、通信の確立に関するもの
| ATT＆CK テクニック | 解説 |
|---|---|
| 動的レゾリューション（T1568） |
接続するC＆Cサーバーのドメイン名、IPアドレスを動的に決める手法で、接続先が毎回異なります。 サーバー側と共有する特定のルール、例えば時刻や接続回数を使って導出します。 |
| プロキシ（T1090） |
C＆Cサーバーへの接続との間にプロキシを経由させ、C＆Cサーバーを特定しにくくします。 TOR（The Onion Router）のような匿名多段プロキシを利用する、侵入先網内にプロキシを設ける、CDN（Contents Delivery Network）を経由させる、などの手法があります。 |
| Webサービス（T1102） |
一般的なクラウドストレージや、SNSなどを通じてC＆C通信文の交換を行います。 C＆Cサーバーからの指令と、侵入先からの報告を別経路とする場合もあります。 |
| 複数ステージチャンネル（T1104） | 攻撃ステージ毎に異なるC＆Cサーバーと接続し、指示を得ます。 |
| フォールバックチャンネル（T1008） | C＆C通信チャンネルを複数用意しておき、一つが発見されたり、疎通しなくなったりした場合、別のチャンネルに切り替えます。 |
| トラフィック・シグナリング（T1205） | サーバーのC＆C機能を起動するため、トリガーとなる特定のパターンのパケットをあらかじめ送る手法。侵入先網内でのC＆C通信に使われることがあります。 |
| リムーバブルメディア経由のコミュニケーション（T1092） | ネットワーク的に隔離された機器にC＆Cコマンドを伝えるため、リムーバブルメディアに通信内容をコピーし、人の移動に依存して伝達する手法です。 |
通信プロトコルや偽装に関するもの
| ATT＆CK テクニック | 解説 |
|---|---|
| アプリケーション層プロトコル（T1701） | Web、メール、ftp、DNS、SSH、RDPなど、良く使われるプロトコルを利用、または偽装してC＆C通信を行います。 |
| 非アプリケーション層プロトコル（T1095） | ICMPなど、通常アプリケーション通信に利用されない下位層プロトコルを使ってC＆C通信を行います。 |
| プロトコルトンネリング（T1572） |
C＆C通信を他のプロトコル中にカプセル化し、隠ぺいします。 例えば、SSHプロトコルのポート転送の利用、HTTPS接続で双方向通信チャンネルを確立し、RDPプロトコルを通すなどです。 |
| 非標準ポート（T1571） |
標準的なプロトコルを使い、標準とは異なるポート番号を使って通信します。 例えば、SSHプロトコルをファイアウォール通過可能なポート番号（80、443、など）で行うなどです。 |
| データのエンコード（T1132） |
C＆C通信の内容に対して、特定のエンコード（BASE64、zipなど）を行います。 BASE64が良く使われ、そのエンコード、デコードでWindowsに備わっているcertutil.exeが利用されています。 |
| データの難読化（T1001） | 通信内容を把握させないため、意味のあるデータにゴミデータを混ぜ込んだり、通常の通信データ中にわからないようにC＆C通信を埋め込んだり、正常なプロトコルを偽装してC＆C通信を行います。 |
| 暗号化チャンネル（T1573） | C＆C通信を傍受されないように暗号化します。 |
利用方法、その他
| ATT＆CK テクニック | 解説 |
|---|---|
| リモートアクセスソフトウェア（T1219） |
リモート管理用のソフトウェアにより、端末を乗っ取って操作します。 （既にインストールされている場合、あるいはマルウェアによってインストールされた場合） |
| 内部へのツールの転送（T1105） |
さらなる攻撃を行うためのツールをC＆C通信チャンネルで転送します。 フィッシングからC＆C通信を確立し、侵入先のプラットフォームやネットワーク構成に従って、その後必要なツール類をダウンロードする場合もあります。 |
通信テクニックの一部を以下のように図示してみました。
このように、攻撃者側には様々な選択肢があることがわかります。
C＆C通信を検出する方法
C＆C通信は、見つからないように通常のWebアクセスなどを偽装して行われるため、日常のネットワーク活動に埋もれてしまい、検出が困難な場合が多いです。
まずマルウェア本体の通信を直接検知したいところですが、そのためにはエンドポイント端末中の通信ログを取得する必要があります。
Windowsでは、監査ログにてプロセスとログ、ファイアウォールのログを取得することになりますが、ファイアウォールの監査ログは量が膨大になり、多数の端末のログを保存・分析するのは大変です。
通信を行うのがマルウェア本体である場合は、通常見られないプロセスとして検知できる可能性がありますが、スクリプトを利用するマルウェアの場合は、ログを取得できたとしても、標準的なプロセスを通して実行されるため、検知が難しいかもしれません。
C＆C通信を行うマシン内のプロセスとしては、
- ペイロードとして送り込まれた通信プログラム
- ペイロードとして送り込まれたスクリプトを cscript.exeやOfficeソフトウェアなどから起動（ペイロードの起動には、システム中のプログラムの脆弱性によるDLLサイドローディングなどのパターンもあります）
- 侵入先環境にインストールされているプログラム（リモート管理ツールなど）を操る
などのパターンがあります。
C＆C通信に関して、端末外で取得できる情報としては、組織内のプロキシや、ルータ、ファイアウォール、UTM（Unified Threat Management）機器などで取得する通信フローの情報があります。
通信フローから不審な通信を検知するための観点は以下のようになります。
- いつもと異なる通信先との通信、特に国外であれば通常は通信しないような国のIPアドレスなど。
- 組織で契約していないクラウドサービスへのトラフィック
- DNSを引かない通信、あるいはドメイン名ではなくIPアドレスを直接指定したHTTPS通信
- 通常の通信パターンから外れる通信（例えば「受信量よりも送信量が多HTTP通信」、「定期・不定期な間隔を開けて行われる通信」、「断続的にデータが流れる通信」、「少量のトラフィックの長期間の継続」など）
まず、通信フローの情報を集めなければなりませんが、組織内の全通信フローの記録は膨大になります。
上記のような検出の観点をSIEMなどの検出ルールとして記述しても、元のデータ量が膨大になると、検出ルールを実行する負荷も大きくなってしまいます。
また、「いつもと異なる」「通常の通信パターンから外れる」というものを検出するには、「いつも」「通常」の状態を把握した上で、外れるものを検出ルール化して見つけなければなりませんが、これはとても難しそうです。
最近は、機械学習によるふるまい検知で、「いつも」と異なるもの（異常：アノマリ）を検知できるものが実用化されてきているので、そのようなシステムに期待するのもありです。
スレットハンティング
リアルタイムでの検知は難しいのですが、たとえ大量でもログが残っていれば、証跡・痕跡に基づいて元になる脅威を見つけ出す、スレットハンティングを行うことができます。
例えば、C＆C通信がUTMログで不正通信としてブロックされた場合、その通信元はどこかを探ります。
C＆C通信が行われているということは、既にこれまでに解説したフィッシング（T1566）などで侵入し、永続化（TA0003）、権限昇格（TA0004）、探索（TA0007）、水平展開（TA0008）などが行われている可能性があるので、それらの痕跡も追跡します。
- UTMのログには、C＆C通信を行っている内部のマシンのIPアドレスが記録されています。そのIPアドレスが、どのマシンに割り当たっているかを確認する必要があります。
- IPアドレスからマシンを特定する方法は、いくつか考えられます。
- UTMによっては、ログにWindowsマシン名を記録しているものがあり、マシン名から特定できる場合があります。
-
端末ログが記録されている場合、Filtering Platform の監査ログにIPアドレスが記録されているので、それと突き合せます。
あるいは端末ログを収集するサーバーに端末のIPアドレスが記録されていれば、そこから特定できます。 -
それらの記録がない場合、DHCPサーバーのIPアドレス払い出し状況から特定できます。
DHCPの場合はIPアドレスが変わり得ますが、ログが残っていれば当該時間帯でのMACアドレスとIPアドレスの対応関係から、MACアドレスを特定できます。
MACアドレスがわかれば、マシンの管理台帳からマシンを特定できます。
台帳がなければ、各マシンのMACアドレスを確認してまわる必要が出て来ます。 - 上の手がかりが何もなければ、各マシンのIPアドレスを確認してまわる必要があります。
-
マシンが特定できた後、マシン内にて、どのプロセスがC＆C通信を行ったのかを確認します。
それにはプロセス情報と、プロセスの通信情報がログに残っている必要があります。
Windowsなら、監査ログのプロセス記録（イベント番号4688）とFiltering Platformの記録（5156、5158など）、あるいはsysmonの記録（イベント番号1、3）です。 -
通信プロセスが特定できると、その起動exe名がわかります。
exeがペイロードでないか、あるいはコマンドラインで読み込んだファイルがペイロードでないか調べます。
DLLサイドローディングなどでペイロードを読み込ませている場合は、DLL読み込みのログ（sysmonイベント7）があれば検知できます。 -
さらにそのプロセスを起動した親プロセス、そのプロセスが起動した子プロセスを確認し、それらの活動を調べます。
もし権限昇格の痕跡が見つかった場合、より広い範囲に侵入されている可能性があるので、調査の範囲も広げる必要が出て来ます。 -
類似の痕跡がないか、他の端末の記録も含めて確認します。
痕跡が認められる場合、水平展開が行われた可能性が高くなります。
Filtering Platformの記録があれば、端末間の通信として記録されている可能性があります。
ファイルサーバを介した水平展開の可能性を調べるには、ファイルサーバのアクセスログを確認します。
C＆C通信限らず、なんらかのインシデントが検出されたとき、スレットハンティングを行って関連する痕跡・証跡を追跡していくことにより、インシデントの根本原因、どの程度深く・広く侵入されているか、を確認することができます。
そのためには、色々な機器のログ、特にエンドポイント端末のログを収集しておくことが重要です。
ログを収集して一括して検索できるシステム（ALogシリーズのような）があれば便利です。
リスク低減・防御
C＆C通信を行うTechniqueには、三つのパターンがありました。
これらを防御するには、以下を行う必要があります。
- 通信経路、通信の確立に関するもの： プロキシやFW、UTMにて許可リスト以外の通信をブロックする
- 通信プロトコルや偽装に関するもの： Deep Packet Inspectionを行い、プロトコルに準拠しない通信をブロックする
- 利用方法、その他： 組織内で利用しているリモート管理ツールの扱いを厳密にする。
まとめ
C＆C通信まで実行されるということは、それ以前にこれまでの連載のような攻撃者の行動が既に行われてしまっている可能性があるので、検出した場合はネットワークから切り離した上で、マルウェアの検知、スレットハンティングによる追跡などを行う必要があります。
その対応のコストは高くなるので、この段階に至る以前、前回まで解説した防御で防いでおきたいところです。
