Lesson 35 — The Process Connected to an External IP
The file had appeared.
Seven seconds later, it executed.
Eight seconds after that, the new process opened an outbound connection to an external IP address.
The destination alone did not prove compromise. External connections happen constantly on normal endpoints.
Agent Foskett needed to answer a more useful question:
Did this network connection belong to the same suspicious execution chain?
The IP address was only the beginning
Determine which process initiated the connection, when it happened, where it went and whether the destination fits the established attack chain.
Case briefing
Investigation objective
Identify the process responsible for the connection, preserve the destination details, correlate network activity with execution and determine whether the same destination appears elsewhere in the environment.
Investigator's rule
Do not investigate an IP address without its process context. The same destination can mean very different things depending on what connected to it and why.
Stage 1 — preserve the network evidence
| Field | Why it matters |
|---|---|
| RemoteIP | Provides a destination pivot for hunting across the environment. |
| RemoteUrl | May provide hostname or domain context beyond the raw IP address. |
| RemotePort | Shows the destination service port, but does not prove the application protocol. |
| Protocol | Provides transport context for the connection. |
| InitiatingProcessFileName | Connects the network event back to endpoint execution. |
| Timestamp | Places the connection into the attack timeline. |
Port 443 does not mean safe
Legitimate and malicious traffic can both use common ports. Treat the port as context and continue investigating the initiating process and destination.
Do not overstate RemoteUrl
When hostname information is available, preserve it. When it is not, record the IP address without inventing a domain relationship that telemetry has not established.
Stage 2 — retrieve the process network activity
let TargetDevice = "WS-FIN-044";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where InitiatingProcessFileName =~ "update-check.exe"
| project Timestamp,
ActionType,
RemoteUrl,
RemoteIP,
RemotePort,
Protocol,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
InitiatingProcessSHA1
| order by Timestamp asc
Start with the known process
The investigation already established update-check.exe as suspicious. Using that process as the starting point reduces unrelated network noise.
Preserve the process hash
The initiating-process hash provides another way to connect the network event to the exact executable observed in the previous lesson.
Stage 3 — place the connection into the timeline
Timing strengthens correlation
A connection occurring seconds after process execution is more relevant than an unrelated connection hours later, especially when the network event identifies the same initiating process.
Correlation is not causation by timestamp alone
The timing matters because it is combined with process identity and device context. Do not join unrelated events simply because they occurred close together.
Stage 4 — hunt the destination across the environment
let TargetIP = "203.0.113.77";
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteIP == TargetIP
| summarize
Connections=count(),
Devices=dcount(DeviceName),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by RemoteIP
| order by LastSeen desc
Prevalence changes the question
If hundreds of managed devices contact the destination through known business software, the context differs from a destination seen once from one suspicious process.
Rare does not automatically mean malicious
Low prevalence raises investigative interest. It does not replace validation of ownership, business purpose and surrounding behaviour.
Stage 5 — find every process that contacted the IP
let TargetIP = "203.0.113.77";
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteIP == TargetIP
| project Timestamp,
DeviceName,
AccountName,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
InitiatingProcessSHA1,
RemoteIP,
RemotePort
| order by Timestamp desc
Look for repetition
If the same unusual executable contacts the destination on multiple endpoints, the scope of the incident may be larger than the original device.
Look for legitimate explanations too
If only approved software contacts the destination elsewhere, investigate whether the suspicious process could be interacting with legitimate infrastructure.
Stage 6 — reconnect network activity to process ancestry
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ "WS-FIN-044"
| where FileName =~ "update-check.exe"
| project Timestamp,
AccountName,
FileName,
FolderPath,
SHA1,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asc
The network event is not isolated
The process was created by suspicious PowerShell activity, appeared only seconds before execution and then initiated the outbound connection. Those facts belong in one investigation story.
Keep the chain evidence-led
Record only relationships established by telemetry. If the destination's purpose remains unknown, say that rather than labelling it command-and-control without evidence.
Stage 7 — test the destination context
| Possible explanation | What to validate |
|---|---|
| Known business service | Ownership, approved application use, expected processes and broad organisational prevalence. |
| Content delivery or cloud infrastructure | Hostname context, expected application behaviour and other legitimate connections. |
| New or uncommon external service | First-seen timing, process context, destination ownership and business justification. |
| Malicious infrastructure | Threat intelligence, suspicious process ancestry, related endpoints and follow-on activity. |
Threat intelligence supports the investigation
Reputation and threat-intelligence results can strengthen or weaken a hypothesis, but they should be combined with the endpoint evidence rather than used as the sole verdict.
A clean reputation result is not an acquittal
New infrastructure may have little or no reputation history. Continue evaluating the process chain and destination behaviour even when no known threat classification exists.
Stage 8 — make the SOC decision
Write the investigation finding
Lesson 35 key takeaways
- Investigate external destinations together with the initiating process.
- Preserve RemoteIP, RemoteUrl, RemotePort, protocol and exact timestamps.
- Common ports such as 443 do not make a connection benign.
- Correlate network activity with the process execution timeline.
- Use process hashes to strengthen event correlation.
- Hunt destination prevalence across the environment.
- Identify every process and device contacting the same destination.
- Use threat intelligence as supporting context rather than the sole verdict.
- Do not label unknown traffic command-and-control without evidence.
- Build the SOC finding from the complete process, file and network chain.
Module 4 — Endpoint Incidents: Following the Attack Chain
Lesson 35 connects suspicious execution to outbound network activity. Next, Agent Foskett investigates whether the compromised process created a mechanism designed to survive beyond the current session.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 4: Endpoint Incidents: Following the Attack Chain
How to investigate suspicious outbound connections in Microsoft Defender XDR
Lesson 35 of the Agent Foskett SOC Analyst Academy teaches analysts how to use DeviceNetworkEvents to connect outbound network activity with suspicious endpoint process execution, preserve destination evidence and hunt IP prevalence across devices.
KQL network investigation for SOC analysts
Learn how to correlate DeviceNetworkEvents with DeviceProcessEvents, investigate initiating processes, external IP addresses, remote ports, destination prevalence and threat context during endpoint compromise analysis.
