hardPACKET ANALYSIS300 pts

Ghost Protocol

A network tap captured DNS traffic from a compromised workstation. The IDS flagged abnormally high response TTL values with no apparent cause. Something is hiding in the numbers.

— scenario

Incident report #2026-003

Alert triggered at 11:22 UTC by IDS rule DNS-UNUSUAL-TTL.
Source: 192.168.1.88 (WKSTN-DEV-12) — the same host from report #2026-002.
Duration: ~4 minutes.

DNS responses from an external authoritative nameserver for cmd.exfil.badactor.cc carry TTL values that are far outside the expected range for that domain. Other DNS traffic on the wire has normal TTL values (300–86400). The anomalous TTLs are all in the printable ASCII range (32–126).

The capture has been exported to JSON via tshark for your analysis. Identify the covert channel, extract the TTL values in the correct order, and decode the flag.

— challenge file

⬇capture.json18 KB

— write-up

The write-up explains DNS TTL covert channels, why they evade most detection systems, and how to extract data encoded in response TTL fields using tshark/jq.

reveal write-up (spoilers)

Step 1 — filter for the suspicious domain

The key field is dns.resp.name. Filter for records where it ends in exfil.badactor.cc:

jq '[.[] | select(.["dns.resp.name"] // "" | endswith("exfil.badactor.cc"))]' capture.json

This gives you 24 records. All other DNS traffic has normal TTL values (300–86400).

Step 2 — sort by frame.number

Sort to get chronological order and extract just the TTL field:

jq '[.[] | select(.["dns.resp.name"] // "" | endswith("exfil.badactor.cc"))] | sort_by(.["frame.number"]) | .[]["dns.resp.ttl"]' capture.json

Output (in order): 70 79 73 76 123 116 116 108 95 99 48 118 51 114 116 95 99 104 52 110 110 51 108 125

Step 3 — convert TTLs to ASCII

Each TTL value is the decimal ASCII code for one character of the flag:

python3 -c "print(''.join(chr(t) for t in [70,79,73,76,123,116,116,108,95,99,48,118,51,114,116,95,99,104,52,110,110,51,108,125]))"

Result: FOIL{ttl_c0v3rt_ch4nn3l}

Why this channel is hard to detect

DNS TTL values are set by the authoritative nameserver and are considered boring infrastructure metadata — most DLP and IDS tools don't alert on "unusual TTL" unless explicitly configured. Because the covert traffic looks like legitimate DNS responses (queries for a real domain, normal response sizes), it blends into the ambient noise.

The payload capacity is limited (one byte per query), so this technique suits slow, low-volume C2 commands or short flag/key exfiltration — exactly the kind of traffic that flies under volumetric anomaly detectors.

Detection signals: a single domain consistently returns TTLs in the 32–126 range; TTL values change on every response for the same domain; sequential frame numbers from a single source host querying the same SLD; cross-referencing with threat-intel feeds for the queried domain.