Lesson 78 — The IOC Changed — The Behaviour Didn't
Yesterday the SOC had an IP address, a domain and a file hash.
They searched for them. They found three devices. They blocked the infrastructure.
This morning the IP was different.
The domain was different.
The hash was different.
One analyst looked at the new evidence and said:
“None of yesterday's indicators match.”
Agent Foskett looked at the process timeline.
Browser → PowerShell → download → execution → external connection.
“The IOC changed. The behaviour didn't.”
Infrastructure changes. Techniques can persist.
Use IOCs when they are useful, then translate the case into behavioural questions that can survive tomorrow's new IP address, domain or hash.
Case briefing
Investigation objective
Take a hunt that began with specific indicators, identify the underlying behavioural relationships and create a more durable hunting approach that can still identify related activity when attacker infrastructure changes.
Investigator's rule
An IOC tells you what to look for now. Behaviour can tell you what to keep looking for next.
Stage 1 — understand what an IOC gives you
| Indicator | Useful for | Limitation |
|---|---|---|
| IP address | Rapidly finding known connections. | Infrastructure can be replaced, shared or reassigned. |
| Domain | Finding known network activity. | Domains can be rotated or abandoned. |
| File hash | Finding an exact known file. | A small file change creates a different hash. |
| URL | Finding access to a known resource. | Hosts, paths and parameters can change. |
IOCs are useful evidence
They are valuable for rapid scoping, blocking and enrichment. The weakness appears when the hunt assumes an attacker must keep using exactly the same indicator.
Indicator absence does not end the hunt
If today's IP does not match yesterday's IP, ask whether today's activity still follows the same suspicious sequence or achieves the same objective.
Stage 2 — scope the known indicator
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteIP == "198.51.100.24"
| project Timestamp, DeviceId, DeviceName,
InitiatingProcessFileName,
RemoteIP, RemotePort, RemoteUrl
| order by Timestamp ascStart specific
Known indicators can quickly identify directly related devices. Capture the process, account and timeline around those matches before moving to a broader behavioural hunt.
Ask what surrounded the IOC
The reusable evidence may be the parent-child process relationship, command pattern, execution location or sequence that led to the network connection.
Stage 3 — extract the behaviour
Separate behaviour from infrastructure
The destination is one part of the evidence. The execution chain describes how the activity unfolded and may remain observable after infrastructure rotates.
Do not become too broad
Behavioural hunting does not mean searching for every PowerShell event. Preserve meaningful relationships such as parent process, command context, timing and follow-on activity.
Stage 4 — hunt the durable process relationship
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
"msedge.exe", "chrome.exe", "firefox.exe"
)
| project Timestamp, DeviceId, DeviceName,
AccountName, FileName,
ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascThis survives an IP change
The query does not care whether the remote infrastructure is yesterday's or today's. It asks whether the suspicious browser-to-PowerShell relationship occurred elsewhere.
Context still decides
A behavioural match is a hunting candidate, not an automatic verdict. Review command lines, prevalence, user activity and surrounding events.
Stage 5 — the IOC rotates
The behavioural match creates a lead
FIN-WS-219 deserves deeper investigation even though none of the original indicators matched. The lead comes from similarity in the attack sequence.
Similarity is not attribution
Do not claim the same attacker solely because two devices show similar behaviour. Additional evidence must support any attribution conclusion.
Stage 6 — pivot into the new network activity
DeviceNetworkEvents
| where Timestamp between (
datetime(2026-09-05 09:35:00) ..
datetime(2026-09-05 09:50:00)
)
| where DeviceName =~ "FIN-WS-219"
| where InitiatingProcessFileName in~ (
"powershell.exe", "pwsh.exe"
)
| project Timestamp, DeviceId, DeviceName,
RemoteIP, RemotePort, RemoteUrl,
InitiatingProcessFileName
| order by Timestamp ascNew infrastructure becomes new evidence
Once behavioural hunting identifies a candidate, extract its new IPs, URLs and other observables and use them for additional scoping.
The workflow goes both ways
IOC → behaviour → new IOC → wider scope. Strong hunting combines specific indicators with durable behavioural reasoning.
Stage 7 — compare the cases
| Evidence | FIN-WS-204 | FIN-WS-219 |
|---|---|---|
| Original IP | Observed | No match |
| Original domain | Observed | No match |
| Original hash | Observed | No match |
| Browser → PowerShell | Observed | Observed |
| Download behaviour | Observed | Observed |
| User-profile execution | Observed | Observed |
| Follow-on network activity | Observed | Observed |
The stable evidence becomes visible
The exact infrastructure differs while several meaningful behavioural relationships remain consistent.
Investigate the differences too
Differences can reveal attacker adaptation, alternate tooling or unrelated benign activity. Do not ignore them because the pattern looks compelling.
Stage 8 — avoid two hunting failures
Durable does not mean vague
The hunt should be abstract enough to survive superficial attacker changes but specific enough to preserve the suspicious characteristics of the original case.
Expect tuning
As legitimate matches appear, refine the hypothesis with context. The goal is a useful hunting question, not a query engineered to return zero false positives.
Stage 9 — write the reusable hypothesis
Hypothesis first, KQL second
A clear hypothesis tells another analyst what behaviour is being tested and why. KQL implements the reasoning; it should not replace the reasoning.
Keep the original IOCs
They remain useful for historical searches, enrichment, blocking and future correlation. Behavioural hunting extends IOC hunting rather than replacing it.
Stage 10 — write the hunting finding
The balance matters
Specific indicators help the SOC move quickly. Behavioural hunting helps the SOC keep moving when those indicators stop matching.
The logs remembered the behaviour
The IP changed. The domain changed. The hash changed. But the process relationships still left a trail. Sometimes the most useful indicator is not a string — it is the story the telemetry tells.
Lesson 78 key takeaways
- IOCs remain valuable for rapid matching, scoping and blocking.
- Attackers can rotate IP addresses, domains, URLs and file hashes quickly.
- Extract behavioural relationships from known IOC matches.
- Parent-child process relationships can survive infrastructure changes.
- Keep behavioural hunts specific enough to remain useful.
- A behavioural match is a hunting lead, not automatic proof of compromise.
- Similar behaviour alone does not prove common attacker attribution.
- Use behavioural matches to discover new indicators.
- IOC and behavioural hunting should reinforce each other.
- Do not let a missing historical IOC terminate a reasonable hypothesis.
- Write the behavioural hypothesis separately from the query implementation.
- Preserve both the indicators and the durable behavioural story.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 78 built a hunt that survives changing attacker infrastructure. Lesson 79 asks what happens when the hypothesis is sound but the current telemetry cannot answer the question: the hunt needs another data source.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How do threat hunters keep hunting when an IOC changes?
Lesson 78 of the Agent Foskett SOC Analyst Academy teaches analysts how to translate IP addresses, domains, URLs and file hashes into more durable behavioural hunting hypotheses.
Behavioural threat hunting in Microsoft Defender XDR
Learn how to use Microsoft Defender XDR Advanced Hunting to identify process relationships, network pivots and execution sequences that can remain visible even when attacker infrastructure and exact indicators change.
