NDRがコマンド＆コントロール通信をどのように検知するか

NDRによるコマンド＆コントロール（C2）トラフィックの検知方法 

C2トラフィックは、インターネットへのアウトバウンドトラフィックとして現れるほか、内部スキャン、ラテラルムーブメント、認証情報の悪用、ステージング、あるいはピアツーピア通信に関連している場合もあります。NDRはノースサウスおよびイーストウェストの経路にわたるトラフィックを継続的に監視するため、コマンド＆コントロール（C2）トラフィックを検知することができます。

効果的なNDRアプローチでは、通常、複数の検知手法を組み合わせています。 

1. ビーコン送信パターンの検出 

ビーコン送信は、典型的なC2行動の一つです。 

侵害されたホストは、指示を確認するために、数秒、数分、あるいは数時間おきに攻撃者のインフラに接続する場合があります。間隔が非常に規則的な場合もあれば、タイミングが分かりにくくなるよう、意図的にばらつきを持たせる場合もあります。 

NDRは、以下の点を監視することで、不審なビーコン送信を特定できます：  

• 同じホストからの繰り返されるアウトバウンド接続、 
• 定期的または準定期的な間隔での通信、 
• 少量ではあるが持続的なデータ転送、 
• めったにアクセスされない宛先への繰り返しの接続、 
• 営業時間外における異常な通信、 
• 一定期間にわたって同様のセッションサイズが維持されていること、 
• 数日間続く少量のトラフィック、 
• 資産の通常の役割と一致しない接続。 

単発の外部への接続だけでは、悪意のあるものとは見なされないかもしれません。しかし、あるワークステーションが2日間にわたり10分おきに未知の外部ドメインに接続している場合は別です。このようなパターンがあれば、アナリストは調査する価値のある手がかりを得ることができます。 

ここでネットワークセキュリティ監視が役立ちます。これにより、SOCは、そのホストにとってその接続が「正常」「まれ」「新規」、あるいは「不審」のいずれに該当するかを判断するのに十分な履歴情報を得ることができます。 

2. C2の指標に関するDNSの分析 

攻撃者がDNSを利用する理由は、DNSが広く許可されており、偽装しやすく、Webトラフィックに比べて監視が不十分な場合が多いためです。したがって、DNSはC2を検知する上で最も有用な場所の一つとなります。C2チャネルの中には、攻撃者のインフラを解決するためにのみDNSを利用するものがあれば、トンネリング、ステージング、またはコマンドのやり取りのために、より積極的にDNSを利用するものもあります。 

NDRは、以下を特定することで、DNSベースのC2トラフィックの検出を支援できます：  

• 異常なDNSクエリの量、 
• 長すぎる、またはエンコードされているように見えるサブドメイン、 
• めったにアクセスされないドメインへの繰り返しのクエリ、 
• NXDOMAINの発生頻度が高いこと、 
• 新たに確認されたドメイン、 
• 未承認のリゾルバーへのDNSリクエスト、 
• ドメイン生成アルゴリズムのパターン、 
• 不審なTTLの挙動、 
• DNSトンネリングの兆候、 
• これまで通信したことがないドメインを解決している内部システム。 

たとえば、通常は外部へのDNSリクエストをほとんど行わないサーバーが、突然、長くてランダムに見えるドメインの解決を開始した場合は、注意を払う必要があります。同様に、アルゴリズムで生成されたような多数のドメインに対して繰り返し解決に失敗するワークステーションについても、同様の対応が必要です。 

DNSだけではC2の存在を証明することはできません。しかし、多くの場合、脅威ハンターにとって、調査の糸口となる手がかりを提供してくれます。 

3. HTTP、HTTPS、およびTLSの動作の検査 

Webトラフィックは至る所に存在するため、多くのC2トラフィックがWebトラフィックの中に隠れています。 

攻撃者にとって、接続が完璧に見える必要はありません。ただ、すぐに注目を集めない程度に「目立たない」ように見えるだけで十分なのです。そのため、ネットワーク脅威の検知では、宛先IPアドレスだけでなく、それ以上の情報を検査する必要があります。 

NDRは、HTTP、HTTPS、およびTLSのメタデータを分析し、次のような兆候を検知することができます：  

• 珍しい、または不審なユーザーエージェント、 
• 異常なURI構造、 
• 不自然なHTTPメソッド、 
• 異常なヘッダーの組み合わせ、 
• 不審なGETおよびPOSTパターン、 
• 不自然なクライアント・サーバー間のバイト比率、 
• 信頼性の低いインフラへの繰り返しの接続、  
• TLS証明書の異常、 
• 自己署名証明書または新規発行された証明書、 
• SNIと証明書の詳細の不一致、 
• 異常なJA3またはJA4フィンガープリント、 
• プロトコルとポートの不一致、 
• セッション継続時間の異常。 

これは、ペイロードが暗号化されている場合に特に有用です。内容を復号しなくても、分析担当者はセッションの挙動を評価することができます。 

4. 正常なネットワーク動作の基準値の構築 

SOCが「正常な状態」を把握することで、C2通信の検知精度が向上します。 

珍しい接続がすべて悪意のあるものとは限りません。定期的な接続がすべてビーコン通信であるわけでもありません。新しいドメインがすべて不審であるわけでもありません。文脈が重要です。 

NDRソリューションは、行動分析を活用して、ユーザー、ホスト、サーバー、アプリケーション、ピアグループ、および宛先における現在のアクティビティを、通常のネットワーク動作と比較します。 

これにより、次のようなアクティビティを検知しやすくなります：  

• これまで通信したことがないインフラと通信しているワークステーション、 
• 通常とは異なる外部へのWebセッションを開始しているデータベースサーバー、 
• 予期せぬ外部接続を行っているドメインコントローラー、 
• 不審なログイン後に通常とは異なる宛先に接続しているユーザー端末、 
• 本来の役割とは異なるプロトコルを使用しているサーバー、 
• 突然、中継サーバーやプロキシのような動作を示す内部資産。 

ここで、高度な脅威検知の真価が発揮されます。SOCは単に「これは既知の悪意のあるものか？」と問うだけでなく、「この資産にとって、この時点、この環境下において、この挙動は正常か？」と問うのです。 

この区別が重要なのは、未知のC2インフラが、必ずしも脅威インテリジェンスフィードに即座に反映されるとは限らないからです。 

5. 脅威インテリジェンスとネットワーク上の証拠の関連付け  

脅威インテリジェンスは依然として重要です。既知の悪意のあるIPアドレス、ドメイン、URL、証明書、マルウェアのインフラストラクチャ、C2フレームワークのパターン、およびレピュテーションシグナルは、NDRソリューションがアクティブな脅威をより迅速に特定するのに役立ちます。  

しかし、脅威インテリジェンスだけを頼りにすべきではありません。攻撃者はインフラストラクチャを素早く入れ替えます。侵害されたサーバーを利用し、クラウド環境でC2をホストし、ツールをカスタマイズし、新規登録されたドメインを使用したり、正当なサービスに紛れ込んだりします。 

より強力なモデルは、多層的なものです：  

• シグネチャは既知のツールを検知するのに役立ち、 
• 脅威インテリジェンスは不審なインフラを特定するのに役立ち、 
• 行動分析は未知または改変された活動を検知するのに役立ち、 
• パケットやメタデータの証拠は、アナリストがアラートの妥当性を検証するのに役立ちます。 

6. パケットおよびメタデータ証拠を用いたアラートの検証 

アラートが発生したら、SOCは何が起きたのかを把握する必要があります。ホストは実際にC2インフラと通信したのか？データは転送されたのか？そのセッションにはファイルの移動が含まれていたのか？そのトラフィックは横方向の移動に関連していたのか？それはより大規模な攻撃経路の一部だったのか？ 

だからこそ、パケット証拠と強化されたメタデータは貴重なのです。成熟したNDRワークフローは、アナリストが以下の疑問に答えられるよう支援すべきです：  

• どのホストが接続を開始しましたか？ 
• どの宛先に接続しましたか？ 
• どのプロトコルとアプリケーションが使用されましたか？ 
• その活動はいつ始まったのか？ 
• そのホストはどのくらいの頻度で通信を行ったのか？ 
• どのくらいのデータが転送されたのか？ 
• DNSクエリは行われたか？ 
• セッションは暗号化されていたか？ 
• その前後に、関連する内部接続はあったか？ 
• 同じホストに、スキャン、認証試行、またはデータステージングの兆候は見られたか？ 
• その挙動は孤立したものか、それともより広範な脅威の検知および対応ワークフローの一部か？ 

SOCが確信を得る必要がある場合、パケットレベルの証拠は特に有用です。メタデータは、そのアクティビティの全体像を示すことができます。可能であれば、パケットの完全なキャプチャを行うことで、セッションを再現し、何が起こったかを確認するのに役立ちます。