DNS TXT Burst in the Finance Subnet
Over eight hours, a sensor records 14,600 DNS queries from 10.44.7.0/24 to ns1.telemetry-sync[.]net, an authoritative server registered 11 days ago. Of these, 11,300 are TXT queries with labels 45-63 characters, 78% unique; response payloads are 220-255 bytes. The same subnet also makes 400,000 normal queries to a major CDN. A junior analyst labels this DNS exfiltration and asks to block the domain. The DNS server logs show NXDOMAIN for 12% of TXT queries. There is no endpoint telemetry. The affected hosts are 18 Windows 10 workstations in a finance department. The firewall allows outbound UDP 53 only to the internal resolvers; the resolvers forward to the internet. The domain has no business relationship documented in the DNS inventory.
1. Which DNS features support exfiltration, and which observations argue against a simple blocking decision?
Read the worked answer
The supporting features are the high volume of TXT queries, long and mostly unique labels, a newly registered authoritative domain, small response payloads, and concentration in one finance subnet. Those are consistent with DNS tunneling, where data is encoded in labels and commands or acknowledgments return in TXT records. The counter-signals matter: 12% NXDOMAIN could indicate a DGA, failed tunnel sessions, or misconfiguration; there is no endpoint telemetry tying the queries to a process; and the subnet also generates a large volume of legitimate CDN DNS. Blocking only the domain may simply move the actor to another domain, and it may disrupt something undocumented. I would not accept the label on volume alone. I would first decode representative labels, compare query timing and entropy with the CDN baseline, and check whether any TXT response contains encoded content or commands. Blocking can follow confirmation or be paired with sinkholing and continued monitoring.
2. What additional packet or log evidence would you collect to confirm or refute the hypothesis, and what would each result mean?
Read the worked answer
I would collect full DNS packets at the internal resolver, including query and response, plus resolver query logs with client IP and timestamp. I would decode the label text as base32, base64, or hex and measure entropy and compression. If decoded labels contain structured data, file fragments, or commands, that strongly supports tunneling. If labels decode to random bytes and responses are empty or NXDOMAIN, I would consider DGA or failed beaconing rather than successful exfiltration. I would also collect proxy and firewall logs for the same hosts, EDR process and DNS telemetry if available, and NetFlow to see whether the 18 hosts have other periodic external connections. A response payload containing a command, or a label sequence reassembling a file, would change the incident from suspicion to confirmed exfiltration. Absence of endpoint or proxy corroboration would not disprove it, but it would limit attribution and scope.
3. If confirmed, how would you contain without tipping off the actor, and what IOCs would you publish?
Read the worked answer
I would avoid an immediate visible block of the domain at the perimeter. Instead, I would sinkhole the domain at the internal resolvers, preserve full query and response logging, and use the sinkhole to identify all clients and any encoded commands. I would isolate the 18 workstations only after collection, or stagger isolation to avoid a single obvious trigger, and coordinate with the business for finance operations. I would block the domain and authoritative IP at the resolver and proxy, but keep a controlled sinkhole for observation. Published IOCs should include the domain, authoritative server IP if known, the TXT query pattern, label length range, query cadence, and any decoded URI or command strings. I would also publish host-based indicators only after EDR confirmation, and include a caveat that the domain may be disposable. Finally, I would check DNS inventory and certificate transparency for sibling domains registered around the same date.