ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • Network Telemetry • DNS • Process Analysis • KQL

The Device Had No Malware — But Its DNS Requests Told the Story

The device looked clean.

No obvious malware detection.
No suspicious executable sitting in quarantine.
No dramatic endpoint alert explaining what had happened.

It would have been easy to close the investigation.

Then Agent Foskett looked at the network activity.

The device kept reaching out to a domain nobody recognised.

Again.
And again.
And again.

The malware alert was missing. The network story wasn't.

Discuss Microsoft security Back to investigations
Agent Foskett investigating suspicious DNS-related network activity in Microsoft Defender XDR
The Network Still Had Evidence

A device does not need an active malware alert for its network behaviour to deserve investigation. Defender XDR can connect remote domains and IP addresses back to the processes that initiated the traffic.

✓ Build the device network timeline
✓ Identify the initiating process
✓ Scope the domain across the environment

No malware detection did not mean no suspicious activity

The first mistake would have been treating the absence of a malware alert as proof that the endpoint was clean. Detection telemetry and behavioural evidence answer different questions. Agent Foskett started with what the device had actually communicated with.
No obvious malware alertThere was no simple detection explaining the behaviour.
Repeated remote contactNetwork telemetry showed connections that still required explanation.
Process context availableThe network events could be pivoted back to the process responsible for the connection.

Build the device network timeline

DeviceNetworkEvents is the starting point. Review the remote URL, remote IP, port, protocol and initiating process together. Depending on the event and telemetry available, RemoteUrl can provide hostname or domain context associated with the connection; do not assume every row represents a raw DNS query.
device-network-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let Device = "LAPTOP-042";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| project Timestamp,
          ActionType,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          Protocol,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Which domains keep appearing?

Summarise remote URLs for the device. Frequency is not a maliciousness verdict — legitimate services can generate large numbers of connections — but repetition can reveal a pattern worth investigating when the destination is unexpected.
domain-frequency.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let Device = "LAPTOP-042";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where isnotempty(RemoteUrl)
| summarize Connections=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Processes=make_set(InitiatingProcessFileName, 20)
    by RemoteUrl
| order by Connections desc

Follow the suspicious domain back to the process

Once a domain becomes interesting, preserve the initiating process ID, command line and hash alongside the remote destination. This turns a network indicator into an endpoint investigation pivot.
suspicious-domain-process.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let Device = "LAPTOP-042";
let Domain = "example-suspicious-domain.test";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where RemoteUrl =~ Domain
| project Timestamp,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          InitiatingProcessFileName,
          InitiatingProcessId,
          InitiatingProcessCommandLine,
          InitiatingProcessSHA1
| order by Timestamp asc

The process mattered more than the domain alone

A domain can be suspicious, benign, shared, compromised or simply unfamiliar. The stronger question is: what process on this device contacted it, under which account, and how did that process start?
initiating-process-history.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let Device = "LAPTOP-042";
let ProcessIdToCheck = 6420;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where ProcessId == ProcessIdToCheck
| project Timestamp,
          FileName,
          FolderPath,
          SHA1,
          ProcessCommandLine,
          AccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Now scope the destination across the environment

Do not stop at the first endpoint. Search the same remote domain across Defender XDR network telemetry. One device may suggest an isolated event; several devices contacting the same unusual destination can materially change the incident scope.
domain-environment-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let Domain = "example-suspicious-domain.test";
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl =~ Domain
| summarize Connections=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Devices=dcount(DeviceName),
            Processes=make_set(InitiatingProcessFileName, 20)
    by RemoteUrl
| order by Connections desc

Rare does not mean malicious

Rarity is useful for hunting because it reduces noise, but it is only a prioritisation signal. This query surfaces remote URLs seen on very few devices so an analyst can investigate them — not automatically block them.
rare-remote-domains.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where isnotempty(RemoteUrl)
| summarize Connections=count(),
            Devices=dcount(DeviceName),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Processes=make_set(InitiatingProcessFileName, 20)
    by RemoteUrl
| where Devices <= 2
| order by Connections desc

DNS evidence needs careful wording

Defender XDR network telemetry can contain remote URL or hostname context associated with connections, but analysts should not describe every DeviceNetworkEvents row as a DNS lookup. If dedicated DNS telemetry is available elsewhere in the environment, correlate it. Otherwise describe exactly what Defender recorded: the destination and the process associated with the network event.
ObservedThe device communicated with or attempted to reach the recorded remote destination.
CorrelatedThe initiating process fields connect network behaviour with endpoint activity.
Do not overclaimA remote URL field alone does not prove every event was a raw DNS request or that the destination was malicious.

What the evidence can and cannot prove

Network telemetry can establish that a process generated activity toward a remote destination and can support a behavioural timeline. It does not automatically prove malware execution. Reputation, prevalence, process ancestry, file evidence, command lines and other endpoint activity should be used to reach a verdict.
ProvenThe recorded process-to-destination relationship exists in the telemetry.
CorrelateProcess history, file hashes, command lines and environment prevalence strengthen the story.
UnprovenNo malware alert does not prove the device is safe — and an unusual domain does not prove compromise.

Agent Foskett's investigation mindset

Do not ask only, “Did Defender detect malware?” Ask, “What did the device do?” Endpoint investigations become stronger when process, file and network evidence are treated as parts of the same timeline.
Follow behaviourA missing detection should not end an investigation when other telemetry remains suspicious.
Pivot to processThe initiating process can explain why the destination was contacted.
Scope broadlySearch the destination across the environment before deciding the incident is isolated.

Investigation findings

The important finding was not simply that an unfamiliar domain appeared in the telemetry. It was the repeatable relationship between the destination and the process initiating the network activity. That relationship gave the analyst a defensible pivot even though there was no obvious malware alert to start from.
The device was not silentNetwork telemetry preserved behaviour that the initial alert view did not explain.
The process provided contextNetwork evidence became more useful once tied back to endpoint execution.
The environment provided scopePrevalence showed whether the destination was isolated or widespread.

Related Agent Foskett investigations

Continue following endpoint and network evidence.
Defender Blocked the Malware — So Why Was the Device Still Talking to the Internet?Investigate network activity that continues after an apparent endpoint block. The Excel File Never Contained a Macro — It Still Started PowerShellFollow process and network evidence when the first theory is wrong. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
The malware alert was missing. The network story wasn't.
Follow the destination, identify the process and reconstruct what the device actually did.
Continue the Investigation

Final thought

Security investigations fail when “no detection” becomes “nothing happened.” A device can leave useful evidence in its network behaviour even when no obvious malware verdict exists. The job of the analyst is to connect that behaviour back to the process, establish context and decide what the evidence actually proves.
What destination appeared?Start with the network evidence.
What process contacted it?Pivot back into endpoint execution.
Where else did it happen?Scope the indicator across the environment.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Device Had No Malware — But Its DNS Requests Told the Story

This Agent Foskett investigation explores suspicious network and DNS-related endpoint evidence using Microsoft Defender XDR, DeviceNetworkEvents, DeviceProcessEvents, remote URLs, process IDs and KQL.

Microsoft Defender XDR Network Investigation

Learn how to investigate a device when no obvious malware detection exists but its network telemetry still contains unexplained remote destinations and process relationships.

DNS-Related Hunting And KQL

Remote domain evidence should be correlated with initiating processes, command lines, hashes and environment prevalence before reaching a security verdict.