Technique & Investigation of the Day · Educational, defensive guidance for authorized environments.
Why it matters
Long domain names, frequent requests and failed lookups can draw attention, but each can occur in normal software. A useful DNS hunt connects the request to its process, device role and surrounding activity instead of labeling unusual strings as a covert channel.
HACK INVASION / VISUAL FIELD NOTES
Unusual DNS activity
Explore the diagram
Unusual DNS activity: investigation path. State a bounded hypothesis; Query candidate patterns; Resolver or endpoint DNS logs with timestamps, query names, types and response status.; Test normal explanations; Escalate; assess containment impact; Improve coverage
Select the image to open it separately for closer reading.
Required telemetry and evidence
- Resolver or endpoint DNS logs with timestamps, query names, types and response status.
- Process creation and endpoint DNS telemetry with stable device/process identifiers where available.
- Proxy or network connection evidence and approved software inventory.
- Resolver coverage, collection filters, time synchronization and known encrypted-DNS visibility limits.
Before drawing conclusions, record collection scope, retention and any missing fields. Keep sensitive evidence in approved internal systems.
Step-by-step investigation
1. State a bounded hypothesis
Choose a device group and a behavior to investigate, such as repeated unusual queries from an unexpected process. Avoid a universal length threshold across servers, browsers and developer systems.
2. Check collection semantics
Determine whether the source records cached requests, failures and process attribution. Sysmon DNS events can record successful or failed process queries, including cached queries; do not assume resolver logs have identical semantics.
3. Query candidate patterns
Summarize query frequency, unique names, result status and time distribution. Retain representative records. Aggregation can conceal short bursts, and high uniqueness alone does not identify the content or purpose of a query.
4. Enrich with the process
Join on a supported stable process identifier and device, then review ancestry and the executable’s role. Time proximity alone is weaker evidence. Check whether a browser, security tool or approved agent explains the pattern.
5. Test normal explanations
Compare peers and version changes. Content-delivery, telemetry and service-discovery traffic can look machine-generated. Look for corroborating unexplained execution or network behavior before escalating.
6. Improve coverage
Document which request paths were visible. If encrypted DNS or unmanaged endpoints bypass the source, record the blind spot rather than treating no matches as a clean estate.
HACK INVASION / VISUAL FIELD NOTES
Unusual DNS activity
Explore the diagram
Unusual DNS activity: evidence checklist. Resolver or endpoint DNS logs with timestamps, query names, types and response status.; Process creation and endpoint DNS telemetry with stable device/process identifiers where available.; Proxy or network connection evidence and approved software inventory.; Resolver coverage, collection filters, time synchronization and known encrypted-DNS visibility limits.
Select the image to open it separately for closer reading.
Read-only investigation pseudocode
INPUT authorized DNS event export
GROUP by device, attributed process, domain suffix and time window
SUMMARIZE request count, unique names and response status
COMPARE with role-specific peers
REVIEW unusual groups with process and connection evidenceTest and adapt: this is illustrative pseudocode, not executable vendor syntax or a tested production detector. Validate field semantics, time boundaries and results in an authorized environment. It does not change systems.
Legitimate activity versus suspicious activity
An application update can introduce a new telemetry endpoint or a burst of failed service-discovery queries. Consistent behavior across approved peer devices supports that explanation. It does not automatically explain an unrelated process using the same domain suffix.
Tuning and false positives
Tune by software role, resolver source and expected query pattern. Keep exception owners and expiry dates. Avoid broad allowlisting of shared hosting domains or treating every newly seen domain as malicious.
Escalation, containment and documentation
Preserve candidate queries and correlated endpoint evidence internally. Escalate an unexplained behavior chain to the network/endpoint responder. Blocking a domain can disrupt shared services; validate impact and use the approved containment path.
Close with an evidence-based disposition: explained activity, supported escalation or unresolved visibility gap. Include identifiers, times, source coverage, competing explanations and the response owner.
MITRE ATT&CK context
DNS application-layer protocol use (T1071.004) applies when evidence supports adversary command-and-control over DNS. DNS anomalies alone do not justify that conclusion.
Key takeaways
- State a bounded hypothesis: define the question before broadening the search.
- Test normal explanations: corroborate the explanation with independent evidence.
- Keep the observed facts, assumptions and response decisions separate.
Related articles
- LOLBins threat hunting: process context and evidence correlation
- PSIRT preparation: communicating evidence and risk
- Explore the Knowledge Base
References
Original educational workflow and conceptual diagrams for Hack Invasion. Public documentation informs source-specific details; investigation decisions require local validation.
