変更要約: 初版
4.4pcap分析（ストリーム再構成と侵入の要素）
キャプチャしたpcapからTCPストリームを再構成して転送ファイルを抽出する手順（WiresharkのFollow TCP StreamやExport Objects）と、パケットデータから読み取る侵入の要素＝送信元/宛先アドレス・送信元/宛先ポート・プロトコル（5タプル）＋ペイロードを、被害ホストとC2/持ち出し先を特定するSOCの実作業として学びます。
アラートやフローが「怪しい」と教えてくれても、何が実際にやり取りされたのかはパケットの中身を見るまで確定しません。ネットワークを流れるTCPは細かなセグメントに分かれて到着するため、そのままでは意味を成しません。pcap分析の核心は、バラバラのセグメントを順序どおり再構成してアプリ層の会話（HTTPのGET応答、送られたファイル）を復元し、そこから誰が誰に何を送ったかを確定させることです。この節では、ストリーム再構成とファイル抽出の手順、そしてパケットから侵入の要素（5タプル＋ペイロード）を読み取り、被害ホストと攻撃者インフラを名指しする流れを学びます。
4.4.1ストリーム再構成とファイル抽出
- TCPはデータをセグメントに分割し、順序番号（
seq/ack）で並べ替えられる。WiresharkのFollow TCP Streamは同一コネクション（同じ5タプル）のセグメントをseq順に連結し、送受信を色分けしたアプリ層の生データ（HTTPリクエスト/レスポンス本文など）を復元する。まず「どのストリームか」をフィルタ（例tcp.stream eq 3）で絞るのが起点。 - 転送されたファイルの取り出しは、再構成したストリームのペイロードを保存するか、Wiresharkの
File > Export Objects > HTTP（またはSMB等）で応答本文をそのままファイルとして書き出す。抜き出した検体はハッシュ（例sha256）を計算してレピュテーション照合し、IOCとして登録する。これがpcapから「実際に落ちたマルウェア」を確定させる標準手順。
4.4.2侵入の要素（5タプル＋ペイロード）
- パケットから侵入を記述する基本要素は送信元アドレス・宛先アドレス・送信元ポート・宛先ポート・プロトコル（＝5タプル）とペイロード。5タプルで「どのホストがどのサービスと通信したか」の骨格が決まり、ペイロードで「何をした・何を送った」の中身が確定する。方向（内→外か外→内か）と併せて、被害ホスト・攻撃者・C2/持ち出し先を名指しできる。
- ポートと方向は役割を示唆する：内部ホストの高位の一時ポート（例
49xxx）が送信元で、外部のサーバポートが宛先なら、その内部ホストがクライアントとして外へ出ている。GET /payload.exeの応答でPEファイルが内部へ流れていればダウンロード＝被害側、内部から外部の一定宛先へ周期的に小さな通信が続けばC2ビーコン、大量データが外へ出れば持ち出し、と読み分ける。
「Follow TCP Stream＝同一5タプルのセグメントをseq順に再構成しアプリ層データを復元」「Export Objects＝HTTP等の応答本文をファイルとして書き出し→ハッシュでIOC化」「侵入の要素＝5タプル（src/dst addr・src/dst port・protocol）＋ペイロード」が頻出です。送信元が内部の高位ポート・宛先が外部サーバポートなら内部ホストがクライアント、という方向の読みも要点です。
IDSが「不審なEXEダウンロード」を1件アラートし、あなたは該当時刻のpcapを渡されました。まず膨大なパケットの中から対象を絞るため、アラートの5タプルでフィルタします（例 ip.addr 10.1.1.5 && tcp.port 80）。該当パケットで右クリックしFollow TCP Streamを実行すると、バラバラだったセグメントがseq順に連結され、GET /update/setup.exe HTTP/1.1（内部10.1.1.5:49770→外部203.0.113.9:80）というリクエストと、200 OK に続く応答本文にPE（MZで始まるバイナリ）が見えました。ここで5タプルと方向から、内部ホスト10.1.1.5がクライアントとして外部サーバから実行ファイルを取得した＝被害ホストであること、203.0.113.9が配布元インフラであることが確定します。次にFile > Export Objects > HTTPでsetup.exeをそのまま書き出し、sha256を計算してスレットインテルに照合、悪性と判明したのでハッシュ・URL・宛先IPをIOCとして登録します。ここで注意すべきは、フローやアラートだけでは「本当にファイルが落ちて実行され得たのか」までは確定しないという点です——NetFlowなら「10.1.1.5が203.0.113.9:80と数十KB通信した」までしか分からず、中身がEXEである確証も、検体そのものも得られません。だからこそ、5タプルで場所を特定し、ストリーム再構成で会話を復元し、Export Objectsで検体を抜き出す、というパケットに踏み込む手順が、被害の確定とIOC化に不可欠なのです。もしこの通信がHTTPSだったら応答本文は暗号化されて中身を取り出せないため、その場合はエンドポイント側の証跡（AVやプロセス記録）に切り替える、という判断もこの流れの延長で身につけます。
| 読み取る要素 | 見る場所 | 分かること | 次の一手 |
|---|---|---|---|
| 5タプル＋方向 | IP/TCP・UDPヘッダ | 被害ホスト・攻撃者・サービス | 該当ストリームに絞る |
| アプリ層の会話 | `Follow TCP Stream` | 要求/応答の中身（GET・本文） | 転送物を特定 |
| 転送ファイル | `Export Objects > HTTP` | 落ちた検体そのもの | ハッシュ算出→IOC照合 |
| 暗号化の壁 | HTTPS/TLSのペイロード | 中身は取り出せない（宛先/SNIのみ） | エンドポイント証跡へ切替 |
ひっかけ： 「NetFlowやアラートで宛先が分かるのだから、落ちたマルウェア検体もそこから取り出せる」は誤りです——検体そのものを抜き出すにはペイロードを含むフルパケットが要り、Follow TCP Streamでの再構成とExport Objectsでの書き出しが必要です。また「pcapがあればHTTPSの中身も必ず読める」も誤り＝TLSで暗号化された本文は（復号鍵が無い限り）取り出せず、その場合はエンドポイント側の証跡に切り替えます。
4.4.3この節のまとめ
- TCPはセグメントで届くため、
Follow TCP Stream（同一5タプルをseq順に再構成）でアプリ層の会話を復元してから中身を読む - 転送ファイルは
Export Objectsで書き出し、ハッシュを計算してIOC化する。5タプル＋ペイロード＋方向で被害ホストとC2/持ち出し先を名指しする - フロー/アラートだけでは中身を確定できない。HTTPSは本文が暗号化され取り出せないので、その場合はエンドポイント証跡に切り替える
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. IDSアラートに紐づくpcapを調べ、内部ホスト10.1.1.5がダウンロードした実行ファイルの検体そのものを取り出して悪性判定したい。Wiresharkでの最も適切な手順はどれか。
Q2. あるpcapで、内部ホスト10.1.1.5の一時ポート49770を送信元、外部203.0.113.9のポート80を宛先とするGET /setup.exe が観測され、応答本文にMZで始まるバイナリがあった。この通信の解釈として最も適切なものはどれか。
Q3. 疑わしい通信がHTTPS(TCP443)で、pcapを取得してFollow TCP Streamを実行したが、応答本文はランダムなバイト列で中身を読み取れなかった。この状況で次に取るべき最も適切な手段はどれか。