networkfreeeasy

The Step After the PCAP

metactf

Task: a shuffled network flow log hides the flag across sparse TLS payload fragments mixed into noisy traffic. Solution: keep only non-dash payload records sharing the same destination IP and JA3 fingerprint, then sort them by timestamp and join the fragments.

$ ls tags/ techniques/
ioc_filteringtimeline_sortingfragment_reassembly

The Step After the PCAP — MetaCTF

Description

PCAP analyzed: compromised_host_traffic_20260405.pcap

Notable IOC: Repeated TLS JA3 hash observed in multiple flows to the same IP address. The times seem to be out of order.

English summary: the provided flow report contains lots of noise, but a small subset of TLS records includes payload fragments that must be reconstructed into the final value.

Analysis

The useful records are the ones where Payload Fragment is not -. Those records all point to destination IP 45.76.123.45 and share JA3 d2b4c6a8f0e1d3c5b7a9f2e4d6c8b0a1, which cleanly separates the exfiltration channel from the background traffic.

The second hint is the log header: the records are not listed chronologically. That means the fragment order in the file is wrong, so the suspicious subset must be sorted by Timestamp before concatenation.

Solution

  1. Parse the flow report.
  2. Keep only entries where Payload Fragment is not -.
  3. Notice every surviving record has the same destination IP and JA3, confirming they belong to one stream.
  4. Sort those records by timestamp.
  5. Join the fragments with underscores preserved.
#!/usr/bin/env python3 import re from datetime import datetime text = open("network_forensics.log", "r", encoding="utf-8").read() blocks = text.split("------------------------------------------------------------") ...
🔒

Permission denied (requires auth)

Sign in to read this free writeup

This writeup is free — just sign in with GitHub to read it.

$ssh [email protected]