Investigating Suspicious DNS Beaconing

What to compare

• Domain rarity.
• Query frequency.
• Record type.
• Subdomain length and structure.
• Process making the request.
• Destination after resolution.
• Connection timing.

Beaconing concept

Workflow

• Establish baseline.
• Identify deviations.
• Correlate DNS with process and network data.
• Check asset role and software ownership.
• Document why the pattern is unusual.

Common mistakes

• Calling every rare domain malicious.
• Ignoring scheduled jobs.
• Using one indicator without correlation.

Daily quiz hook

A host contacts the same destination every minute. What additional evidence would increase confidence that the behavior is suspicious?

Quiz flow: introduce this topic briefly on social media, ask the question, reveal the answer, then send learners here for the detailed investigation.

Fictional evidence set

Endpoint WS-042 belongs to the Finance group. Resolver and endpoint timestamps are UTC.

2026-10-20T10:14:00Z WS-042 A cdn-sync.example.test answer=192.0.2.44
2026-10-20T10:15:01Z WS-042 A cdn-sync.example.test answer=192.0.2.44
2026-10-20T10:16:02Z WS-042 A cdn-sync.example.test answer=192.0.2.44
2026-10-20T10:17:03Z WS-042 A cdn-sync.example.test answer=192.0.2.44
2026-10-20T10:14:02Z WS-042 process=sync-helper.exe pid=4812 parent=explorer.exe
2026-10-20T10:14:04Z WS-042 outbound=tcp/443 dst=192.0.2.44 bytes_out=842 bytes_in=1210

The example.test hostname and documentation-only IP are placeholders. They cannot direct learners to a real service.

How to investigate this pattern

1. Validate timing. Queries are about 61 seconds apart during this four-minute sample. This supports periodic behavior in the observed window; it does not show how long the activity has continued.
2. Review DNS context. Check first-seen time, prevalence across endpoints, record type, response, TTL, related names and resolver behavior. A stable answer can be normal.
3. Pivot to endpoint telemetry. Verify the process full path, signer, hash, installation source, file creation time, parent process and prevalence. A process name alone is easy to imitate.
4. Correlate network events. A TLS connection starts seconds after resolution. Review timing, duration, byte counts, proxy records and whether other processes or hosts use the destination. Encrypted payload may not be visible.
5. Establish business context. Check approved software inventory, change records, deployment tools and vendor documentation. Compare a healthy peer with the same role and operating system.
6. Record confidence and gaps. The correlation justifies more investigation, but does not confirm command-and-control or compromise without provenance, prevalence and destination context.

Indicators, evidence and conclusions

Suspicious indicators include a rare domain, regular timing, an unexpected process, an unusual parent-child relationship, or a destination not seen elsewhere. They raise a hypothesis and need corroboration.

Stronger corroboration could include an unapproved binary with an unexpected signer, trusted internal malware evidence, related persistence or execution events, a consistent multi-source timeline, or a contextualized threat-intelligence match.

Confirmed compromise is an incident conclusion supported by your organization’s evidence and criteria. Periodic DNS alone is not enough. Preserve evidence and explain the confidence rationale.

Rule out normal activity and data issues

• Check timestamp accuracy, timezone and collection delay; clock skew can distort the sequence.
• Compare with software updates, endpoint management, backup, telemetry, VPN and scheduled jobs.
• Account for NAT, shared resolvers, proxies and DNS caching.
• Compare the same domain and process against equivalent healthy endpoints.
• Do not use a reputation score as a substitute for evidence and business context.

Defensive response

For low confidence, collect additional resolver and endpoint evidence, verify ownership and tune only after understanding expected behavior. If corroboration indicates active harm, follow the organization’s incident-response process: preserve relevant logs, notify the response lead, isolate a host when justified, block confirmed infrastructure through approved controls, and monitor for related activity. Document approval and business impact.

Afterward, record the timeline, assets, sources, confidence, containment and recovery actions, and telemetry gaps. Improve the detection with multiple signals and documented exceptions for known-good software.

MITRE ATT&CK context

DNS can be used as an application-layer protocol for command and control (MITRE ATT&CK T1071.004). Map a technique only when observed behavior supports it; seeing a DNS query is not sufficient by itself.

Practice and review

Question: Which additional artifact would most improve confidence here, and how would it distinguish a legitimate scheduled client from unauthorized activity?

Continue with the DNS investigation guide or practice correlation in the fictional Mission Simulator. The simulator uses controlled synthetic scenarios and does not contact external targets.