Agent Foskett Case File • DNS Investigation • Defender for Endpoint • Microsoft Sentinel • KQL
The DNS Query Looked Harmless — Until We Decoded the Subdomain
A workstation made a DNS request that looked almost boring. The resolver answered. No browser download appeared, and nobody reported a problem.
Then Agent Foskett noticed the subdomain: a long, unfamiliar string that changed every few seconds.
“That,” he said, “is a lot of enthusiasm for a hostname.”
The question was no longer whether DNS worked. It was what the device was saying through DNS.
Case focus
Investigate unusually structured DNS queries, correlate device and process evidence, and distinguish a plausible tunnelling hypothesis from a proven data-loss event.
The request that did not look like an alert
The fictional SOC was reviewing routine endpoint activity when it found repeated lookups to a domain outside the organisation’s normal business services. The domain itself was unremarkable. Its subdomains were not: each request began with a different, high-variation label.
There were no obvious file-transfer alerts. But DNS can carry arbitrary data inside query names. That makes it useful for legitimate services and, in some circumstances, for covert signalling or exfiltration.
There were no obvious file-transfer alerts. But DNS can carry arbitrary data inside query names. That makes it useful for legitimate services and, in some circumstances, for covert signalling or exfiltration.
First question: was the pattern unusual?
Agent Foskett checked query frequency, label length, unique subdomains, destination domains, and whether the same pattern appeared on other devices. Long labels alone are not proof of malicious activity: CDNs, security products and telemetry systems can generate complex hostnames.
The important finding was the combination of a single device, repeated new subdomains and a destination not associated with approved services.
The important finding was the combination of a single device, repeated new subdomains and a destination not associated with approved services.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
// Microsoft Defender XDR advanced hunting: DNS-related network observations
// Availability of DNS-specific fields varies by event type and telemetry.
let Lookback = 2d;
DeviceNetworkEvents
| where Timestamp > ago(Lookback)
| where isnotempty(RemoteUrl)
| extend Host = tolower(tostring(RemoteUrl))
| where Host contains "example-investigation.test"
| project Timestamp, DeviceName, ActionType, RemoteUrl,
InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessAccountName, DeviceId
| order by Timestamp ascThe domain was the clue — the process was the lead
The analyst traced the lookups back to the originating endpoint and process. Was a browser resolving ordinary web services, or was a background process making DNS requests unrelated to its expected function? Agent Foskett checked the process tree, execution path, command line, signer information and nearby endpoint alerts.
“A suspicious domain is a clue,” he said. “A suspicious process talking to it is a much better conversation.”
“A suspicious domain is a clue,” he said. “A suspicious process talking to it is a much better conversation.”
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
// Correlate the suspicious process with nearby process activity
let Device = "EXAMPLE-WS-17";
let WindowStart = datetime(2026-10-14T01:00:00Z);
let WindowEnd = datetime(2026-10-14T02:00:00Z);
DeviceProcessEvents
| where Timestamp between (WindowStart .. WindowEnd)
| where DeviceName =~ Device
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
AccountName, SHA256
| order by Timestamp ascThen someone decoded the subdomain
In the illustrative evidence set, the team exported a sample of query names for offline analysis. One label appeared to use a URL-safe base64-like encoding scheme. After validating its character set and padding and decoding it in an isolated analysis environment, the recovered text resembled a small fragment of structured business data.
That result strengthened the hypothesis, but did not by itself prove successful exfiltration. The team still needed to establish who generated the data, what the resolver forwarded, whether the destination was attacker-controlled, and whether the content matched sensitive source records.
A label that merely looks encoded may be a random identifier, compressed content or something entirely benign. Decoding attempts should be treated as investigative tests, not automatic verdicts.
That result strengthened the hypothesis, but did not by itself prove successful exfiltration. The team still needed to establish who generated the data, what the resolver forwarded, whether the destination was attacker-controlled, and whether the content matched sensitive source records.
A label that merely looks encoded may be a random identifier, compressed content or something entirely benign. Decoding attempts should be treated as investigative tests, not automatic verdicts.
Look for the wider DNS pattern
Where DNS resolver logs are collected into Microsoft Sentinel, the team can measure the rate and diversity of requested names. The example below uses a DnsEvents table and a Name column as an illustrative schema; those names are not universal. Adapt the query to the DNS connector and fields deployed in your workspace.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
// Illustrative resolver-log schema; adapt table/field names to your connector.
DnsEvents
| where TimeGenerated > ago(24h)
| where isnotempty(Name)
| extend QueryName = tolower(tostring(Name))
| where QueryName endswith ".example-investigation.test"
| summarize QueryCount = count(), UniqueNames = dcount(QueryName),
ExampleNames = make_set(QueryName, 5)
by bin(TimeGenerated, 15m), ClientIP
| where QueryCount > 20 and UniqueNames > 15
| order by TimeGenerated ascReconstructing the investigation timeline
01:08 — First unusual lookupA workstation begins querying an unfamiliar domain.
01:16 — Pattern emergesMany distinct, long subdomains appear within minutes.
01:24 — Endpoint correlationThe queries are linked to a process requiring further review.
01:38 — Offline decodingA sample label yields text consistent with structured data.
01:51 — Scope reviewAnalysts compare resolver logs, device evidence and destination ownership.
02:10 — Response decisionThe team preserves evidence and determines containment based on corroborated risk.
What the evidence did — and did not — establish
The case showed repeated, unusual DNS lookups, a process worth investigating, and at least one label that decoded into meaningful content. It did not establish the full quantity of data transferred or prove that every query reached an external authoritative server. DNS caching, resolver behaviour and missing telemetry can all affect what the logs show.
The fictional team preserved endpoint and resolver evidence, investigated the process, reviewed the destination and restricted suspicious activity in line with its incident-response procedures. Any data-loss conclusion would require additional corroboration.
The fictional team preserved endpoint and resolver evidence, investigated the process, reviewed the destination and restricted suspicious activity in line with its incident-response procedures. Any data-loss conclusion would require additional corroboration.
Practical defensive lessons
- Collect DNS resolver logs where feasible, and understand what your endpoint telemetry does and does not capture.
- Baseline high-volume and high-uniqueness DNS behaviour before treating it as malicious.
- Correlate DNS activity with the originating process, identity, device and time window.
- Investigate encoded-looking labels carefully; decoding is a test, not proof of compromise.
- Confirm containment and document uncertainty rather than equating an alert with a complete investigation.
Final thought
Agent Foskett closed the DNS logs.
“The query looked harmless,” he said. “It was only when we read the address properly that it became interesting.”
He paused.
“I have had less complicated conversations with my router.”
The logs already knew. We just had to ask the right questions.
“The query looked harmless,” he said. “It was only when we read the address properly that it became interesting.”
He paused.
“I have had less complicated conversations with my router.”
The logs already knew. We just had to ask the right questions.
Related investigations
At 3:21 AM, Someone Changed the Retention PolicyA midnight Purview change raises questions about authorisation and evidence.Defender Detected the Threat — But the Response Action FailedDetection was successful. Containment needed verification.The AI Assistant Answered a Question Nobody Should Have AskedInvestigate untrusted document instructions and Copilot responses.
The investigation continues
Follow the next case file, explore earlier investigations or sharpen your KQL skills in the Agent Foskett Academy.
