Catch DNS-tunneling exfiltration
A host is sneaking data out over DNS. Write a detection rule that flags the tunneling domain without firing on a busy CI box that legitimately makes lots of lookups. The trick is choosing what to group by.
Scenario
Something on the network is tunneling data out over DNS, encoding it into the subdomain of each
lookup. Your DNS query log shows one host firing off a burst of queries to random subdomains of
dataxfil.net. Write a detection that catches it.
The catch: a CI server (10.0.0.9) also makes a lot of DNS lookups, pulling packages from
GitHub, npm, PyPI, Docker, Ubuntu. A naive rule pages on it too. A good rule doesn't.
The log (excerpt)
10:00:00 named: query A 8f3a21bc.dataxfil.net from 10.0.0.50
10:00:01 named: query A c70b2f15.dataxfil.net from 10.0.0.50
... ~16 queries to random *.dataxfil.net subdomains in seconds, all from 10.0.0.50 ...
10:01:00 named: query A api.github.com from 10.0.0.9
10:01:03 named: query A registry.npmjs.org from 10.0.0.9
... the CI box queries many DIFFERENT domains, a few each ...
Your rule
Edit detection.yml (match / group_by / threshold / window_seconds). Available group_by
fields include src_ip and domain (the registered parent domain of the query).
How it's graded
We run your rule over the log and check it alerts on dataxfil.net and on nothing else. The
whole challenge turns on one decision: tunneling is high volume to one domain, so group by
domain, not by source; otherwise the busy CI host trips your alert.
Teaches: DNS-tunneling / exfiltration detection and the art of picking the right aggregation key.
What gets checked
Your solution is verified against each of these:
- The rule parses (match, group_by, threshold, window_seconds)
- The rule alerts on the tunneling domain
- The busy CI host's legitimate lookups don't trigger an alert
Solve it in your browser
No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.
Solve in browser →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.