The Step After the PCAP

Platform: Metactf | Category: Network | Type: Challenge | Difficulty: Easy | OS: NA | Author: D3v0o0Nu11 | Date: 2026-04-05 | Status: Solved Techniques: fragment_reassembly, ioc_filtering, timeline_sorting

Summary

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.

Recon

Port scan

nmap -p- -sV -sC <TARGET> --min-rate 1000 -Pn

Enumeration highlights

• Event: metactf | ID: 20260405_metactf_the_step_after_the_pcap
• Tags: pcap, tls, log_analysis, ja3, timeline_reconstruction
• Indicators: same destination IP appears on every payload-bearing record, same JA3 hash repeats across the suspicious TLS flows, records contain fragments but the log explicitly warns timestamps are out of order
• Source: 20260405_metactf_the_step_after_the_pcap.md

Foothold

Vulnerability / Misconfiguration

1. Fragment_reassembly
2. Ioc_filtering
3. Timeline_sorting

<command>

Exploitation

• See original writeup content for detailed exploitation.

Privilege Escalation

Enumeration

sudo -l
find / -perm -4000 2>/dev/null
getcap -r / 2>/dev/null
cat /etc/crontab
ps aux

Exploitation

1. N/A for challenge-type writeup; see exploitation above.
2. Flag obtained via challenge solve.

<command>

Flags

Key Takeaways / Lessons

• fragment_reassembly
• ioc_filtering
• timeline_sorting
• Tags: pcap, tls, log_analysis, ja3, timeline_reconstruction

Original Writeup

<details><summary>Click to expand original content</summary>

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("------------------------------------------------------------")

rows = []
for block in blocks:
    ts = re.search(r"Timestamp: (.+?) UTC", block)
    dst = re.search(r"Dst IP: (.+)", block)
    ja3 = re.search(r"TLS JA3 Hash: (.+)", block)
    frag = re.search(r"Payload Fragment: (.+)", block)
    if not (ts and dst and ja3 and frag):
        continue
    frag = frag.group(1).strip()
    if frag == "-":
        continue
    rows.append(
        (
            datetime.strptime(ts.group(1).strip(), "%Y-%m-%d %H:%M:%S"),
            dst.group(1).strip(),
            ja3.group(1).strip(),
            frag,
        )
    )

suspicious = [r for r in rows if r[1] == "45.76.123.45" and r[2] == "d2b4c6a8f0e1d3c5b7a9f2e4d6c8b0a1"]
suspicious.sort(key=lambda r: r[0])

flag = "_".join(fragment for _, _, _, fragment in suspicious)
print(flag)

This yields:

REDACTED

</details>

---

Auto-tracked: saved to WriteUps; run /xesor-revise to fold lessons into XESXor_Methodology.md.

signed by XESXOR