Lesson 13 — The IP Address Looked Malicious — Until We Checked the Context
The alert contained an external IP address with a poor reputation score. It appeared in threat intelligence feeds,
had been associated with suspicious activity, and immediately looked like the strongest clue in the case.
Then the analyst checked where the connection came from, who owned the address, and how it was being used.
The story changed.
The IP had a bad reputation
That made it worth checking. It did not make every connection to it malicious.
Case briefing
Investigation objective
Validate an IP indicator using connection, process, identity and organisational context before deciding whether the observed activity is malicious.
Investigator's rule
An indicator can be suspicious without the observed event being malicious. Context determines what the indicator means in this investigation.
Stage 1 — separate reputation from observation
| What you know | What you do not know yet |
|---|---|
| The remote IP has negative reputation | Whether this specific connection was malicious |
| The endpoint communicated with the IP | Which process initiated the connection |
| The IP has appeared in threat intelligence | Whether ownership or usage has changed |
| The alert fired at 14:12 | Whether the destination is common in your environment |
| A finance device was involved | Whether there was suspicious activity before or after the connection |
Threat intelligence has a shelf life
Infrastructure changes hands, cloud addresses are reassigned and shared services can host both legitimate and malicious activity. Reputation must be interpreted in time and context.
Ask what generated the traffic
A browser, security agent, updater and encoded PowerShell command contacting the same IP create very different investigative stories.
Stage 2 — find the initiating process with KQL
Use the IP as a pivot, but do not stop at the match. Retrieve the process and command-line context that produced the network event.
let SuspiciousIP = "203.0.113.74";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteIP == SuspiciousIP
| project Timestamp,
DeviceName,
RemoteIP,
RemotePort,
RemoteUrl,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
InitiatingProcessAccountName,
InitiatingProcessSHA1
| order by Timestamp desc
The process is part of the indicator
The remote IP tells you where traffic went. The initiating process tells you why the connection may have happened and what to investigate next.
One match is not prevalence
Before calling the destination attacker infrastructure, check whether the same address appears across many normal devices and applications.
Stage 3 — measure environmental prevalence
let SuspiciousIP = "203.0.113.74";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIP == SuspiciousIP
| summarize
Connections=count(),
Devices=dcount(DeviceName),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by InitiatingProcessFileName
| order by Connections desc
Prevalence does not automatically mean safe
A widely contacted destination may be legitimate shared infrastructure — or evidence of a widespread campaign. Use prevalence to generate the next question, not close the case.
Rare does not automatically mean malicious
A destination contacted by only one device may simply belong to a niche business service. Rarity is useful context, not proof.
Stage 4 — the context changes
A shared IP can have mixed history
An address may have appeared in malicious activity while also serving legitimate workloads. Shared hosting, cloud platforms and changing ownership make indicator context essential.
Document why the verdict changed
Do not write “false positive — safe IP.” Record that this observed connection was explained by approved software and supporting environmental evidence.
Stage 5 — know what would have changed the verdict again
| Evidence | Effect on triage |
|---|---|
| Encoded PowerShell initiated the connection | Priority rises sharply |
| Only one endpoint contacted the destination | Requires deeper validation |
| Connection followed a suspicious download | Supports malicious sequence |
| Approved security agent initiated it on hundreds of devices | Supports legitimate service explanation |
| Same IP appears in unusual sign-ins | Creates cross-domain correlation requiring investigation |
Stage 6 — build an indicator-validation workflow
Stage 7 — write the triage finding
Lesson 13 key takeaways
- Indicator reputation is a clue, not proof of malicious activity.
- Always distinguish what is known about an indicator from what happened in the specific event.
- Identify the process, user and device responsible for the observed connection.
- Use KQL to measure how common the destination is in your own environment.
- Threat intelligence can become stale as infrastructure ownership and usage change.
- Shared infrastructure can support both legitimate and malicious activity.
- High prevalence does not automatically mean benign.
- Low prevalence does not automatically mean malicious.
- Look for supporting behavioural evidence before reaching a verdict.
- Document why the specific event was judged benign or suspicious without making unsupported claims about the indicator itself.
Module 2 — alert triage
You've now added indicator validation to the triage workflow. Next, Agent Foskett looks at an alert that feels strangely familiar — because the SOC investigated the same thing yesterday.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 2: Alert Triage — Deciding What Matters First
How SOC analysts validate suspicious IP addresses
Lesson 13 of the Agent Foskett SOC Analyst Academy teaches analysts how to validate suspicious IP indicators using threat intelligence, process context, device prevalence and supporting security evidence.
Microsoft Defender XDR KQL IP investigation
Learn how to use DeviceNetworkEvents and KQL to pivot from an IP address to initiating processes, measure environmental prevalence and avoid treating reputation as proof of malicious activity.
