ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft Defender XDR • DeviceNetworkEvents

The Device Was Talking To Something It Shouldn't

The email arrived on Monday.

No alert. No incident. No reason to investigate.

It sat quietly in the inbox for three days.

Then somebody clicked the link.

The delivery was not the problem. The click was.

This Agent Foskett investigation explores how defenders can use Microsoft Defender XDR, EmailEvents, UrlClickEvents, NetworkMessageId and KQL to investigate suspicious links long after the original email was delivered.

Discuss network investigations Back to Investigation Hub
Agent Foskett investigates suspicious outbound network traffic in Microsoft Defender XDR
Briefing summary

A healthy-looking endpoint can still be reaching out to suspicious infrastructure. DeviceNetworkEvents helps defenders see where a device connected, which process made the connection and when it happened.

Find suspicious outbound traffic
Correlate connections with processes
Pivot to endpoint activity
🚨 A quiet outbound connection can turn a healthy-looking device into a live investigation.
The endpoint may look healthy, but repeated connections to unknown infrastructure can reveal the activity that alerts missed.
Book a security review →

Why outbound network traffic matters

Security teams often focus on malware alerts, but suspicious communication can be visible before a traditional detection fires. DeviceNetworkEvents can reveal where a device is connecting and which process is responsible.
The endpoint may look healthyA device can pass basic health checks while still communicating with an unusual IP address, domain or port.
The connection changes the storyOnce a device talks to unknown infrastructure, the investigation moves from alert review into process behaviour, destination analysis and timeline reconstruction.
The timeline proves the patternDeviceNetworkEvents and DeviceProcessEvents together can show when the connection happened, which device made it and which process was involved.

First hunt: find unusual outbound connections

Start with DeviceNetworkEvents. This shows outbound connection activity, including device name, process name, remote IP, remote port and protocol.
find-unusual-outbound-connections.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
DeviceNetworkEvents
| where Timestamp > ago(7d)
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          RemoteIP,
          RemotePort,
          Protocol,
          ActionType
| order by Timestamp desc
What to reviewLook at the device, process name, remote IP, remote port, protocol and action type. Unknown destinations or odd ports deserve attention.
Why it mattersSuspicious communication may be missed if the investigation only focuses on antivirus alerts or device health status.
Best next pivotUse the initiating process fields to connect network activity back to process execution, command lines and parent process behaviour.

Second hunt: identify the process behind the connection

The process behind the connection matters. A normal browser connection tells one story. PowerShell, rundll32, mshta or an unusual executable may tell another.
network-connection-process-context.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
DeviceNetworkEvents
| where Timestamp > ago(7d)
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessParentFileName,
          RemoteIP,
          RemotePort,
          Protocol,
          ActionType
| order by Timestamp desc

When outbound traffic deserves deeper investigation

Not every outbound connection is malicious. The investigator mindset is to determine whether the destination, process, timing and device behaviour fit normal business activity.
Suspicious destination contextReview whether the remote IP or domain is expected, recently seen, rare in the environment or associated with unusual ports.
Unusual connection timingConnections outside business hours, at regular beaconing intervals or immediately after suspicious process execution may change the investigation priority.
Post-connection behaviourCheck for process creation, file writes, downloads, persistence activity, additional destinations or lateral movement after the connection.

Third hunt: find devices communicating with the same IP address

One device talking to an unusual address may be interesting. Multiple devices talking to the same unknown address may indicate broader exposure.
devices-communicating-with-same-ip.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
DeviceNetworkEvents
| where Timestamp > ago(30d)
| summarize Connections = count(),
            Devices = dcount(DeviceName),
            Processes = make_set(InitiatingProcessFileName, 10)
    by RemoteIP, RemotePort
| where Devices > 1 or Connections > 20
| order by Connections desc

Fourth hunt: connect network activity to process execution

Once a suspicious connection is found, the next question is what process created it and what else happened around the same time.
network-to-process-execution.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
let SuspiciousConnections = DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe", "rundll32.exe", "mshta.exe", "wscript.exe")
| project ConnectionTime = Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort;
SuspiciousConnections
| join kind=leftouter (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | project ProcessTime = Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName
) on DeviceName
| where ProcessTime between ((ConnectionTime - 10m) .. (ConnectionTime + 10m))
| order by ConnectionTime desc

What DeviceNetworkEvents telemetry can prove

DeviceNetworkEvents does not prove compromise by itself. It proves communication. When that communication connects to suspicious processes, rare destinations or post-connection activity, the evidence becomes much stronger.
The device communicatedThe connection confirms that the device reached out to a destination and records when that activity occurred.
The timeline formedThe investigation can be rebuilt by lining up process execution, outbound connections, file activity and user activity.
The process pivot is availableInitiating process fields can connect the network connection back to the executable, command line and parent process chain.

The Agent Foskett investigator mindset

Do not stop because the device looks healthy. Do not stop because no malware was detected. Follow the outbound connection and rebuild the timeline from process to network to endpoint activity.
Ask why the device connectedWas the destination expected, was the process normal, and did the connection match normal behaviour for that device?
Follow the connectionUse DeviceNetworkEvents, DeviceProcessEvents, DeviceFileEvents and identity telemetry together instead of treating them as separate logs.
Correlate weak signalsA strange process, rare destination, odd port and repeated connection pattern together can explain what no single alert could.

How GEMXIT approaches DeviceNetworkEvents investigations

GEMXIT helps organisations use Microsoft Defender XDR telemetry to move beyond simple endpoint health checks and understand what devices are communicating with across the network.
We review network visibilityWe help check whether DeviceNetworkEvents, DeviceProcessEvents and endpoint telemetry are available and useful for investigations.
We build hunting logicWe help connect DeviceNetworkEvents, DeviceProcessEvents, DeviceFileEvents, identity telemetry and Microsoft Defender XDR signals into practical KQL workflows.
We improve response readinessWe help teams understand when to isolate devices, block destinations, review process chains, collect evidence and investigate related endpoints.
The endpoint looked healthy. The network traffic disagreed.
GEMXIT helps organisations investigate Microsoft Defender XDR DeviceNetworkEvents, outbound communications, process pivots, device behaviour and KQL hunting workflows.
Contact GEMXIT

Final thought

The endpoint looked healthy.

The antivirus never complained.

The dashboard stayed green.

But the device kept talking.

Every connection left a trail.

Every process left evidence.

The device was talking to something it shouldn't.
At GEMXITWe help organisations investigate Microsoft Defender XDR, Microsoft Sentinel, endpoint telemetry, DeviceNetworkEvents, process behaviour and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Did antivirus detect anything?”

It is: “What did the device connect to, and which process made it happen?”

Continue the investigation with The Process Tree Told The Real Story, Rundll32 Looked Legitimate, The Process Was Signed By Microsoft, The PowerShell Never Triggered An Alert, KQL Threat Hunting, Microsoft Defender KQL Threat Hunting Complete Guide, Microsoft Defender and the GEMXIT Security Review.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The Device Was Talking To Something It Shouldn't

This Agent Foskett investigation explains how Microsoft Defender XDR, DeviceNetworkEvents, DeviceProcessEvents, remote IP analysis and KQL can reveal suspicious outbound communication from endpoints.

Microsoft Defender XDR DeviceNetworkEvents investigation

GEMXIT helps organisations investigate endpoint network telemetry, remote IP addresses, unusual ports, process behaviour and suspicious outbound connections in Microsoft Defender Advanced Hunting.

DeviceNetworkEvents and DeviceProcessEvents threat hunting

DeviceNetworkEvents can help defenders connect outbound communication to process execution, command line evidence, suspicious destinations and endpoint investigation workflows in Microsoft Defender XDR.