Skip to content
Level 2 · Easy · DNS tunnelling

DNS Tunnelling in a PCAP: Find and Decode Long Labels

The DNS resolver’s query volume for one workstation jumped this afternoon, and the security team captured a minute of traffic on the user subnet. Most of it is ordinary name lookups. Your job is to find out whether something is using DNS to carry data out.

The user subnet is 10.20.30.0/24 and every workstation uses the resolver at 10.20.30.53. Everything in this file is synthetic: documentation IP ranges, reserved .example names and a harmless made-up payload.

What you will find in the capture

  • Background noise: ARP and ordinary lookups from three workstations
  • One domain queried far more often than any other
  • Subdomains that look like encoded data rather than host names
Level 2 · Easy · DNS tunnelling · 110 packets

DNS Tunnelling in a PCAP: Find and Decode Long Labels

The DNS resolver’s query volume for one workstation jumped this afternoon, and the security team captured a minute of traffic on the user subnet. Most of it is ordinary name lookups. Your job is to find out whether something is using DNS to carry data out.

The user subnet is 10.20.30.0/24 and every workstation uses the resolver at 10.20.30.53. Everything in this file is synthetic: documentation IP ranges, reserved .example names and a harmless made-up payload.

You will practise

  • Filter DNS queries and compare names, lengths and volumes
  • Recognise encoded data in DNS labels
  • Tie a tunnel to the client that sends it
  • Decode a hex label back into the data it carries
  • Plan the response: contain the host, block the domain, look for the rest

8 questions. Each hint costs 25% of that question’s points; a wrong try costs a little. Your score is out of 100.

Loading the capture…

Loading…

Sample report · illustrative data

Sample result: Cleartext HTTP Login case

Example run of the starter case on a synthetic capture (documentation and private IP ranges, .example names, a made-up account).

Scoring

Score
82/100 (example)
Grade
B, solid analysis
Hints used
2 (example)
Time
6m 40s (example)

Findings in the example run

QuestionFilter that finds itRead
Where is the login submitted?http.request.method == "POST"One POST to the intranet over port 80
What crossed the wire?http.file_data contains "username="Username and password readable as typed
Did it work?http.response.code == 302Redirect plus a session cookie without Secure

Recommended next steps (example)

  • Serve the intranet over HTTPS only, with HSTS and Secure cookies
  • Reset the exposed password and end the account's sessions
  • Search wider captures for other cleartext logins

Made-up example data. Your own run uses your inputs. Downloads of the full report need Pro.

Downloads

Take the capture into Wireshark or your own tools, and keep the analyst report with the answer key.

13.5 kB · 110 packets · SHA-256 3e0d1f9100e80fa08de55fe7e68f8a7703e9583457a36e31bdb1e58f852cb673

Sample of the debrief

This capture shows a workstation using DNS to carry data: a steady stream of A queries for long, hex-encoded subdomains of one domain, each with a short answer. The data travels in the query names, so it passes through the normal resolver and most firewalls without a direct connection to the outside.

The full debrief, with next steps and the MITRE ATT&CK mapping, appears when you finish the case.

What you will learn

  • Filter DNS queries and compare names, lengths and volumes
  • Recognise encoded data in DNS labels
  • Tie a tunnel to the client that sends it
  • Decode a hex label back into the data it carries
  • Plan the response: contain the host, block the domain, look for the rest

Frequently asked questions

How do you detect DNS tunnelling in Wireshark?

Filter queries with dns.flags.response == 0 and look for one domain with many unique, long, random-looking subdomains from a single client. dns.qry.name contains "<domain>" then isolates them. Statistics > Resolved Addresses and DNS statistics help on bigger captures.

What does DNS tunnelling traffic look like?

Long labels made of hex, base32 or base64 characters, a new name in every query, a steady rate from one host, and usually short or unusual answers (A, TXT, NULL or CNAME). Normal lookups repeat a small set of short names.

How do you decode a DNS tunnel label?

Take the label before the parent domain and decode it with the encoding it uses: hex if it only has 0-9 and a-f, base32 if it uses a-z and 2-7. CyberChef’s From Hex and From Base32 work. Real tools often add sequence numbers or encryption first.

Why does DNS tunnelling get past firewalls?

The workstation never connects to the attacker. It asks the internal resolver, which forwards the query to the domain’s authoritative server on the attacker’s side. Most networks allow DNS to the resolver everywhere.

Is this real traffic?

No. PlayCISO generated it with its own script from a fixed seed: documentation IP ranges (RFC 5737), private RFC 1918 addresses, reserved .example names, locally administered MAC addresses and a placeholder payload.