Cisco 300-220 CBRTHD study materials
Cisco 300-220 CBRTHD study resources

High-Entropy TXT Queries from a Build Server Bypassing the Resolver

Cisco 300-220 CBRTHD · Put your knowledge to work in context.

All case studies

High-Entropy TXT Queries from a Build Server Bypassing the Resolver

During a routine PCAP review of the DMZ capture for Tuesday 02:00-03:00, an analyst sees 4,800 DNS queries from 203.0.113.45 to a single authoritative name server, ns1.syncmetrics-cdn[.]net. Subdomain labels are consistently 55-63 characters of base32-like text, for example k7x2... .syncmetrics-cdn[.]net, with query type TXT. Responses are small, 120-180 bytes, and every query carries a distinct label - no repeats. Query spacing averages 0.8 seconds with roughly 5 percent jitter. The resolving host is an internal Linux build server with no business need for external DNS beyond the corporate resolver, and these queries bypass that resolver entirely. Flow records show no large outbound HTTP or HTTPS transfers from the host, and the domain was registered 11 days ago with privacy-protected WHOIS. The build server is used by four engineers who share a single sudo-capable account.

1. Is this DNS tunneling or something benign? Lay out the evidence and the alternatives you must exclude.

Read the worked answer

The pattern is strong evidence of DNS tunneling, and the exfiltration conclusion rests on three independent facts lining up rather than on any single anomaly: near-maximum 63-character labels that are high entropy and never repeat, TXT record type (which allows larger responses than A), and direct-to-authoritative queries that bypass the corporate resolver and therefore both its logging and any response-policy blocking. Spacing at 0.8 seconds with 5 percent jitter looks like a purpose-built beacon trying to avoid rate-based detection rather than a human or a cron job. Alternatives must be excluded: a CDN or telemetry agent using hashed subdomains would normally use the resolver and reuse labels; a misconfigured monitoring agent would show a matching installed package and a process holding the socket; DNSSEC or antivirus lookups would traverse the resolver. Domain age of 11 days with privacy WHOIS weakens the benign hypothesis. Absence of large HTTP transfers is expected - DNS itself is the channel.

2. Estimate the exfiltrated volume and explain the method and its limits.

Read the worked answer

Method: queries x usable payload per query x encoding ratio. Take 4,800 queries. A 60-character base32 label carries 5 bits per character, so 300 bits, about 37 bytes; subtract label-structure overhead and assume roughly 30-37 bytes usable per query. 4,800 x 33 bytes is approximately 158 KB for the hour. Limits matter here: the count covers one hour only, so a sustained 24-hour run would be roughly 3.8 MB; TXT responses may carry inbound commands; some queries may be retries or padding; and base32 wastes 37.5 percent versus base64url, so an encoding change shifts the estimate. The defensible figure comes from decoding captured labels rather than estimating - strip the domain suffix, base32-decode, and measure. Use the estimate for severity triage and scoping, not for a breach-notification count. At about 160 KB per hour the volume is small, but persistence matters more than size.

3. What containment, hunting, and detection steps follow?

Read the worked answer

Contain the host first: isolate 203.0.113.45 at the switch port and through EDR network containment, but leave it powered for memory capture, because the malware process holds the encoding routine and the live socket. Sinkhole syncmetrics-cdn[.]net at the internal resolver and block the authoritative server IPs at the egress firewall, since the host bypasses the resolver and a resolver-only block would miss it. Then hunt: search all DNS logs for the domain string and for TXT queries with labels longer than 50 characters and high entropy; search flow records for any internal host sending directly to external port 53. Add detections for query-name length plus entropy, per-host query volume per hour, and internal-to-external port 53. Ensure the resolver logs query name, type, and client, and enable DNS logging on the firewall. Rotate credentials for the shared sudo account and determine how the host was compromised in the first place.