Lesson 14 — The Alert Had Already Been Seen Yesterday
The alert looked familiar. Same user. Same device. Same detection name.
A quick search showed why: another analyst had investigated almost the same alert yesterday
and closed it as expected administrative activity. It would be easy to copy yesterday's verdict
and clear today's alert.
That would also be a mistake.
We've seen this before
That can accelerate triage — but only after you establish whether today's activity actually matches yesterday's evidence.
Case briefing
Investigation objective
Use previous alerts and investigation history to accelerate triage while independently validating the evidence that matters today.
Investigator's rule
Reuse evidence, not conclusions. Previous investigations can tell you what to check first, but today's event still needs today's validation.
Stage 1 — determine what really matches
| Compare | Why it matters |
|---|---|
| Detection / alert type | Confirms whether the same analytic behaviour triggered again. |
| User | A different identity can completely change the interpretation. |
| Device | The same command on a different asset may carry different risk. |
| Process and parent process | Shows whether execution ancestry still matches the known activity. |
| Command line | Small argument changes can transform expected administration into suspicious execution. |
| Time / schedule | Expected activity may only be legitimate during a defined maintenance window. |
| Follow-on behaviour | New network, file or identity activity may invalidate yesterday's explanation. |
Familiarity can create bias
Once an analyst sees a previous benign closure, confirmation bias can take over. The investigation starts looking for reasons to agree rather than reasons the situation might have changed.
History can also save time
A well-documented previous investigation gives you known-good users, commands, schedules and process ancestry to compare against today's activity.
Stage 2 — measure recurrence with KQL
Before treating this as an isolated repeat, see how often the same behaviour has appeared on the device.
let TargetDevice = "ADM-WS-017";
DeviceProcessEvents
| where Timestamp > ago(14d)
| where DeviceName =~ TargetDevice
| where FileName =~ "powershell.exe"
| summarize
Executions=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by AccountName,
ProcessCommandLine,
InitiatingProcessFileName
| order by LastSeen desc
A stable pattern is useful context
If the same signed management process launches the same command every weekday at the same time, recurrence supports an expected operational explanation.
A changed pattern is more interesting
If today's command has new arguments, a different parent or an unusual user, the previous closure may no longer explain the event.
Stage 3 — compare yesterday with today
Compare the delta
When an alert recurs, ask one powerful question: what is different this time? The difference often determines whether history lowers or raises priority.
Repeated benign alerts can become risky
Attackers may abuse legitimate tools and familiar administrative patterns. A history of legitimate use does not permanently whitelist the behaviour.
Stage 4 — investigate the new network behaviour
The new external connection is the strongest difference, so pivot directly into the network evidence.
let TargetDevice = "ADM-WS-017";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where InitiatingProcessFileName =~ "powershell.exe"
| project Timestamp,
DeviceName,
RemoteIP,
RemoteUrl,
RemotePort,
InitiatingProcessAccountName,
InitiatingProcessCommandLine
| order by Timestamp desc
History changed the investigation path
Yesterday's case was still valuable. It gave you a baseline. Instead of re-investigating every known-good detail, you concentrated on the new behaviour.
Recurrence can raise priority
Repeated alerts can indicate unresolved root cause, persistent attacker activity, failed remediation or a detection that needs engineering attention.
Stage 5 — classify recurrence correctly
| Recurring pattern | Likely triage response |
|---|---|
| Same expected behaviour, same context | Validate quickly; consider tuning if operationally noisy. |
| Same alert, changed command or parent | Investigate the difference before reusing the previous verdict. |
| Same suspicious behaviour after remediation | Raise concern — containment or remediation may have failed. |
| Same indicator across additional devices | Reassess scope; the incident may be expanding. |
| Repeated benign closures without documented evidence | Do not trust the pattern blindly; establish a defensible baseline. |
Stage 6 — build a recurrence workflow
Stage 7 — write the triage finding
Lesson 14 key takeaways
- Previous alerts and incidents are valuable triage context.
- Never copy a previous verdict without comparing today's evidence.
- Reuse evidence and baselines rather than conclusions.
- Compare user, device, process ancestry, command line, timing and follow-on behaviour.
- Use KQL to measure how often the behaviour has occurred.
- Ask what changed between the previous event and the current event.
- Stable recurrence can support expected operational behaviour.
- Changed recurrence can expose attacker abuse of familiar tools or workflows.
- Repeated suspicious activity after remediation may indicate remediation failure.
- Good investigation notes make future triage faster and safer.
Module 2 — alert triage
You've now used recurrence and investigation history without allowing familiarity to replace validation. Next, Agent Foskett looks at how the function of an affected asset changes the potential impact of an alert.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 2: Alert Triage — Deciding What Matters First
Recurring SOC alerts and previous incident history
Lesson 14 of the Agent Foskett SOC Analyst Academy teaches analysts how to use recurring alerts, previous investigations and historical evidence during security alert triage.
KQL recurrence analysis for SOC investigations
Learn how to use Microsoft Defender XDR KQL to measure repeated process activity, compare current behaviour with previous events and identify material changes that require deeper investigation.
