Agent Foskett Academy • KQL Academy • Module 12 • Lesson 145 • Endpoint Investigation

Lesson 145 — The Process Connected to an External IP

Lesson 144 showed a suspicious file arriving only seconds before execution. Now the process does something that changes the investigation again: it makes an outbound network connection.

In this lesson we use DeviceNetworkEvents to connect network activity back to the process, preserve the remote IP, port, URL and protocol, and determine whether the destination appears elsewhere in the environment.

An external IP is not a verdict. The process, timing and surrounding evidence give the connection meaning.

Begin the Investigation Back to KQL Academy

Agent Foskett KQL Academy external IP network investigation

Your case file

The suspicious process on WS-FIN-042 establishes an outbound connection moments after execution.

✓ Find outbound connections

✓ Tie the connection to a process

✓ Preserve IP, port and URL evidence

✓ Pivot the destination across devices

Case briefing

CASE FILE Device: WS-FIN-042 01:22:18 — payload.dll created ↓ 01:22:19 — suspicious process activity ↓ 01:22:24 — outbound network connection Remote IP: 203.0.113.77 Remote port: 443 ↓ THE QUESTION Which process made the connection, what destination did it reach, and does the same infrastructure appear elsewhere?

Investigation objective

Use DeviceNetworkEvents to correlate outbound communication with the suspicious endpoint process, identify the destination and determine whether the same remote infrastructure is visible elsewhere in the Defender XDR estate.

Investigator's rule

An external connection is context, not proof of compromise. Legitimate software constantly communicates with public infrastructure. Preserve the process, time, destination, port and URL before deciding what the event means.

Stage 1 — inspect network activity around execution

Begin with the known device and narrow execution window. This keeps the hunt anchored to evidence already established in the previous lessons.

1234567891011

let TargetDevice = "WS-FIN-042";
let TargetTime = datetime(2026-08-18 01:22:19);
DeviceNetworkEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (TargetTime - 5m .. TargetTime + 10m)
| project Timestamp, DeviceName, ActionType,
          RemoteIP, RemotePort, RemoteUrl, Protocol,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessId
| order by Timestamp asc

RemoteIP is only one clue

Keep RemotePort, RemoteUrl, Protocol and ActionType with the IP address. The destination is easier to interpret when its network context is preserved.

Keep the initiating process

The initiating-process fields let us ask not merely whether the device connected, but which process was associated with the network event.

Stage 2 — tie the connection to the suspicious process

Use the process ID from the execution investigation together with device and time context. Process IDs can be reused, so the number alone is not a permanent identifier.

123456789101112

let TargetDevice = "WS-FIN-042";
let TargetProcessId = 6840;
let TargetTime = datetime(2026-08-18 01:22:19);
DeviceNetworkEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (TargetTime - 5m .. TargetTime + 15m)
| where InitiatingProcessId == TargetProcessId
| project Timestamp, RemoteIP, RemotePort,
          RemoteUrl, Protocol, ActionType,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Why time still matters

Device + PID + timestamp is much stronger than PID alone. Keep the correlation window narrow enough to remain tied to the known execution sequence.

What are we proving?

We are testing whether the network event is consistent with the suspicious process chain. We are not declaring the destination malicious merely because it is external.

Stage 3 — pivot on the remote IP

Treat the remote IP as a new investigative entity and ask how often Defender has observed connections to it across the estate.

123456789101112

let TargetIP = "203.0.113.77";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP == TargetIP
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Connections=count(),
            Devices=dcount(DeviceId),
            DeviceNames=make_set(DeviceName, 50),
            Processes=make_set(InitiatingProcessFileName, 50)
          by RemoteIP
| order by FirstSeen asc

Rare does not mean malicious

A destination seen on one endpoint can be interesting, but rarity alone is not a verdict. New cloud infrastructure and specialist services can also have low prevalence.

Common does not mean safe

Widespread infrastructure can also be abused. Ask which processes contacted it, from which devices, at what times and in what behavioural context.

Stage 4 — examine every connection to the destination

Preserve devices, URLs, ports, process names, command lines and accounts so the original event can be compared with other occurrences.

12345678910

let TargetIP = "203.0.113.77";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP == TargetIP
| project Timestamp, DeviceName, RemoteIP,
          RemotePort, RemoteUrl, Protocol,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessAccountName
| order by Timestamp asc

Look for repetition

Repeated connections from the same suspicious process, regular intervals or the same destination after similar execution chains can strengthen the investigation hypothesis.

Test legitimate explanations

If normal applications across many endpoints contact the same infrastructure, that can materially change the working theory. Hunting should challenge the hypothesis as well as support it.

Stage 5 — summarise the process network pattern

Group the narrow investigation window by initiating process to see which processes generated network activity and whether the suspicious process stands out.

1234567891011121314

let TargetDevice = "WS-FIN-042";
let StartTime = datetime(2026-08-18 01:22:00);
let EndTime = datetime(2026-08-18 01:25:00);
DeviceNetworkEvents
| where DeviceName =~ TargetDevice
| where Timestamp between (StartTime .. EndTime)
| summarize Connections=count(),
            RemoteIPs=make_set(RemoteIP, 100),
            RemoteUrls=make_set(RemoteUrl, 100),
            RemotePorts=make_set(RemotePort, 50)
          by InitiatingProcessFileName,
             InitiatingProcessId,
             bin(Timestamp, 30s)
| order by Timestamp asc

Network telemetry extends the process tree

The process tree told us what executed. File telemetry showed what arrived. Network telemetry now tells us where the activity communicated.

Do not lose the chain

The value is in correlation: browser → PowerShell → command shell → file → process → network destination.

Agent Foskett's network timeline

01:22:11 powershell.exe ↓ 01:22:16 cmd.exe ↓ 01:22:18 payload.dll created ↓ 01:22:19 suspicious execution ↓ 01:22:24 DeviceNetworkEvents 203.0.113.77 : 443 ↓ PROCESS CORRELATION same device + process context + narrow time window ↓ ESTATE PIVOT Who else contacted the destination? ↓ NEXT QUESTION What else happened after the connection?

The destination mattered because we could connect it back to the process that made the call.

Your evidence board

Evidence	What it supports	Weight
Network event immediately after suspicious execution	Supports a temporal relationship with the attack chain.	Strong context
Initiating process matches suspicious execution	Connects network telemetry to endpoint activity.	Strong
Remote IP and port preserved	Provides infrastructure pivots for further hunting.	Strong investigative value
Remote URL available	Can provide additional destination context.	Useful when populated
Destination appears on multiple devices	May indicate broader activity or legitimate shared infrastructure.	Requires validation
External IP alone	Does not prove malicious communication.	Insufficient alone

Write the finding like an investigator

Example: Microsoft Defender XDR network telemetry recorded an outbound connection from WS-FIN-042 shortly after the suspicious file and process activity identified earlier in the investigation. The event preserved the remote IP address, destination port and initiating-process context. Correlation by device, process ID and timestamp associated the connection with the suspicious execution chain. The destination was then hunted across the environment to determine prevalence and identify other processes or devices communicating with the same infrastructure. The connection strengthens the endpoint-compromise hypothesis but should be assessed with destination reputation and surrounding network behaviour.

Lesson 145 key takeaways

DeviceNetworkEvents provides endpoint network telemetry for advanced hunting.
Start with a known device and narrow time window.
Preserve RemoteIP, RemotePort, RemoteUrl, Protocol and ActionType.
Use initiating-process fields to connect network activity to execution.
Do not rely on a process ID without device and time context.
An external IP address is not proof of maliciousness.
Pivot suspicious destinations across the estate to understand prevalence.
Compare processes and devices associated with the destination.
Test legitimate explanations as well as the compromise hypothesis.
Correlated process, file and network evidence creates a stronger investigation story.

Module 12 — the attack chain continues

Lesson 144 connected the process chain to a newly created file. Lesson 145 now follows that execution into network telemetry and identifies the remote infrastructure it contacted. Next we continue deeper into the endpoint activity that followed.

Next: Lesson 146 — The Suspicious Process Created a Scheduled Task.

Continue your KQL investigation training

Module 12 follows endpoint evidence from suspicious execution through process relationships, files, network activity, persistence and spread.

KQL Academy Lesson 144 — The File Appeared Seconds Before It Executed Defender for Endpoint Academy Agent Foskett Academy

Related Agent Foskett Investigations

Continue with endpoint investigations where process and network telemetry reveal what suspicious code did after execution.

The Script Ran From AppData The Process Tree Told The Real Story KQL Threat Hunting Browse Agent Foskett Investigations

🔎 KQL Academy — Module 12: Advanced Endpoint Investigation

Following the attack chain from the first suspicious process to a defensible endpoint compromise assessment.

⬅ Previous lesson

Lesson 144 — The File Appeared Seconds Before It ExecutedCorrelate file creation with process execution and determine where the file came from.

✅ Current lesson

Lesson 145 — The Process Connected to an External IPCorrelate suspicious execution with outbound network activity and investigate the remote infrastructure.

Next lesson

Lesson 146 — The Suspicious Process Created a Scheduled TaskUse KQL to investigate persistence activity and connect a scheduled task back to the suspicious process chain.

Investigate external IP connections with KQL

Lesson 145 of the Agent Foskett KQL Academy uses Microsoft Defender XDR DeviceNetworkEvents to correlate suspicious endpoint execution with outbound network connections.

Correlate process and network telemetry in Microsoft Defender XDR

Learn how to preserve remote IP, port, URL and initiating-process evidence, pivot destinations across devices and turn endpoint network activity into a defensible investigation timeline.