Intermediate·350 points·1 solve
DNS Tunnelling Detection
Learn to find a covert channel that the standard domain-generation hunting technique cannot see. You will group resolver logs by parent domain, count distinct client hosts per domain, measure outbound payload from query-name length and inbound payload from answer size, and separate a real exfiltration channel from an approved security product whose traffic looks the same on every naive measure.
DNS leaves almost every network, which is why it is worth abusing. If an attacker controls the authoritative name server for a domain, then any lookup for a name under that domain reaches them: data can be written into the query name on the way out and into the answer on the way back. It is slow, it is completely reliable, and it looks like name resolution. The critical thing to understand before you start is that a channel like this DOES NOT FAIL. The attacker answers every query, so its failure rate is zero. The usual way to hunt algorithmically generated domains — ranking hosts by how often their lookups come back with no such name — will rank the compromised host among the healthiest in the estate. That is not a flaw in this data; it is the reason the earlier review closed the ticket. What identifies a channel instead is payload and direction. The query name carries data outbound, so names run far longer than anything a person types. The answer carries data inbound, and the record type is chosen for how many bytes it can return rather than for what it means. And it is normally one machine holding one conversation for hours, rather than an estate-wide pattern. Be careful with length alone: endpoint security products legitimately encode lookups into long labels, and one of them is deployed here. Evidence is in /var/log/soc: incident-brief.md, dns-queries.log, asset-inventory.csv, and dns-tunnelling-reference.md, which describes the log format and what is worth measuring.
Your tasks
1
Reproduce the review that closed the ticket
Before looking for anything new, run the technique the previous reviewer ran: for each host, what proportion of its lookups came back with no such name, and which hosts rank highest? Write down where the eventual culprit sits in that ranking. Understanding why this method reports the estate as healthy is the point of the exercise, not a detour — and one of the questions asks you for a figure that only makes sense once you have seen it.
2
Group by parent domain, not by name
Individual query names tell you nothing here because they are generated. Strip each name down to its registered parent domain and aggregate: how many queries went to each, and how many DISTINCT client machines sent them. Two domains will stand out for volume. They are not the same kind of thing, and the count of distinct clients is the first measure that separates them.
3
Check the approved-services list before accusing anything
asset-inventory.csv documents which external DNS destinations are approved for bulk automated querying, and explains why one of them produces long encoded labels by design. Identify that service and record it — one of the questions asks for it specifically, because being able to name the thing you correctly ruled out is part of the finding. Then confirm the other high-volume domain appears nowhere in that list.
4
Measure both directions
Outbound: look at the length of query names per domain and find the longest one sent to the suspicious domain. Inbound: the last field on every line is the size of the answer, and summing it per domain tells you how much data came BACK. Do both. A reputation lookup sends a little and receives almost nothing; a channel does substantial traffic in both directions. Also note which record type the suspicious domain uses and ask why that one was chosen — the answer is capacity, not meaning. Check whether that record type is rare in this log before you treat it as a signal on its own.
5
Scope it and report
Establish which single machine is responsible, when the conversation started, and how long it ran. Cross-check that host against asset-inventory.csv — which department it belongs to determines how serious this is, and the brief explains why. Then map the activity to the ATT&CK technique for using an ordinary application-layer protocol as a command-and-control channel. The volume figure you calculated is the number that goes into the regulatory report, so be certain of it.
Answer the questions
Start the lab, investigate the evidence in the terminal, and answer the questions here.