4,100 TXT Queries From a Finance Workstation

Three explanations compete: malicious DNS tunnelling or C2 beaconing, a legitimate SaaS agent, and a sanctioned security or monitoring tool.

Discriminators:

• Label entropy and structure. 32-48 character pseudo-random labels are characteristic of encoded payloads (base32/base64 chunks). Legitimate telemetry uses stable hostnames and identifiers. Decode a sample of labels - if they decode to structured or high-entropy binary, the benign explanation collapses.
• Record type. TXT is a preferred C2 and tunnelling channel because it carries payload both ways with fewer logging controls. A SaaS heartbeat using TXT at this volume would be unusual; corroborate against the vendor's documented endpoints.
• Timing regularity. A coefficient of variation of 0.03 over 4,100 intervals is machine-driven and near-perfectly periodic - consistent with an implant's sleep timer, and also consistent with an agent. Periodicity alone does not discriminate; it only tells you a program, not a human, is doing it.
• Payload asymmetry. Requests carrying tens of bytes of encoded data with 160-byte responses is consistent with exfiltration over DNS. The absence of proxy POSTs does not exonerate the host - it is exactly what DNS exfiltration is designed to avoid, so treat it as supporting evidence for tunnelling, not against it.
• User context and sensor gap. A user on leave for two weeks, plus an EDR check-in gap immediately preceding the traffic, is the strongest circumstantial combination in the scenario. Either can be innocent; together they shift the prior sharply.

Net assessment: probable DNS-based exfiltration or C2, with the CDN hosting explanation being plausible only if the exact endpoint is documented by the vendor.

Prioritise evidence that does not depend on the EDR sensor:

1. Scope the campaign in DNS. Count distinct internal clients querying sync-telemetry[.]net and its parent domain, and check for NXDOMAIN spikes to random labels from other hosts. This separates a single compromised workstation from an estate-wide beacon or a fast-flux DGA.
2. Decode and characterise. Pull 20 sample queries and attempt base32/base64 decoding; measure label entropy. Document whether the encoded content changes monotonically (streaming a file) or repeats (heartbeat).
3. Reconstruct host-to-user binding. Check DHCP and authentication logs to confirm 10.4.22.51 was assigned to that analyst and that the machine account and user logons in the window are consistent. If the user is on leave but interactive logons appear, the credential is in use.
4. Look for the loader. Pull Zeek conn and ssl for the host, Sysmon events that predate the sensor gap, Windows service installs (7045), scheduled task creation (4698), and proxy/DNS for any secondary destination. Attackers that disable a sensor usually leave a service or task behind.
5. Check exposure. Query whether the workstation talked to the same IP space as the CDN earlier, and whether the CDN IP hosts any other domains queried internally.

Do not wait for the EDR to come back. State in the ticket that telemetry is missing and that conclusions are drawn from network evidence, so the gap is documented rather than silently inherited by the next analyst.

Recommend network isolation of the host plus domain-level blocking, with memory preservation, and escalate to incident response rather than waiting for confirmation.

Reasoning:

• The host is asset priority=high, the traffic has been running for six hours at ~11 queries per minute, and the endpoint's own telemetry has been dark for the most critical period. Continued egress means continued data leaving, and the missing sensor means you cannot verify or stop the process locally.
• An analyst workstation should not be a DNS tunnel endpoint; even under the benign SaaS explanation, isolating a single high-priority workstation costs one user's afternoon and is trivially reversible. The asymmetry of cost is decisive.
• Isolate at the network layer (switch port or NAC quarantine) rather than relying on the EDR you cannot currently trust, and preserve memory before reimaging - the implant binary and its configuration are the evidence that tells you what was taken.

On the domain block:

• Block the domain and parent at the DNS resolver and proxy, but expect the adversary to rotate. Set an alert for the resolver's NXDOMAIN volume and for newly seen domains with similar label entropy, and watch the isolated host's attempted resolutions - a repeat attempt to a new domain from the same subnet is a strong confirmation of tunnelling and a lead to other infected hosts.
• Time-box the block review: if the vendor confirms the endpoint in writing, unblock with an allow-list entry and document the exception, because a permanently blocked legitimate SaaS endpoint generates its own persistent noise.