Lesson 92 — The Phishing Email Became an Identity Incident
The email looked suspicious.
The user clicked the link.
Then the identity alerts started.
The case had crossed a boundary.
One case can cross multiple security domains.
Follow the timeline from message delivery to user action, authentication and identity behaviour.
Case briefing
Investigation objective
Follow one case from suspicious email delivery through user interaction and into identity activity, then decide when the scope must expand beyond email telemetry.
Investigator's rule
Follow the evidence across services. Do not stop because the original alert belonged to email.
Stage 1 — establish the email timeline
| Evidence | Question |
|---|---|
| Sender and domain | Was the message expected and authentic? |
| Authentication results | Did SPF, DKIM or DMARC influence delivery? |
| URL or attachment | What action could the message cause? |
| Delivery time | When did exposure begin? |
| User interaction | Was the message opened or clicked? |
The click changes the investigation
Once the user interacts with the content, the investigation must ask what happened next rather than staying focused only on the email itself.
Email evidence gives you the starting point
The message tells you when and how the user may have been exposed. That timestamp becomes the anchor for identity and endpoint pivots.
Stage 2 — pivot immediately after the click
let User = "alex@contoso.com";
EntraIdSignInEvents
| where Timestamp > ago(2h)
| where AccountUpn =~ User
| project Timestamp,
AccountUpn,
IPAddress,
Country,
Application,
ErrorCode
| order by Timestamp ascLook for authentication close to the click
A new sign-in seconds or minutes after the phishing interaction may connect the email event to an identity event, especially when the source IP, location or application is unusual.
Timing is powerful correlation
One suspicious sign-in might have many explanations. One suspicious sign-in immediately after a phishing click deserves much closer attention.
Stage 3 — build the cross-service timeline
Correlate sequence, not just alerts
The strongest evidence may be the order of activity across multiple systems rather than any single alert in isolation.
Ask whether each event advances the attack
Delivery creates exposure. Click creates opportunity. Authentication may create access. Mailbox activity may show post-compromise action.
Stage 4 — assess the sign-in context
| Context | Why it matters |
|---|---|
| New IP address | May indicate unfamiliar access |
| Unexpected country | May conflict with known user activity |
| New application | Could show unusual access path |
| Successful authentication | Raises concern beyond failed attempts |
| MFA activity | Can reveal prompt abuse or user approval |
Do not treat geography as proof
VPNs, travel, mobile networks and cloud infrastructure can complicate location signals. Use location as context, not verdict.
Success changes urgency
A failed sign-in attempt is different from evidence that the account successfully accessed services after the phishing event.
Stage 5 — inspect MFA activity
MFA is part of the timeline
An MFA prompt may indicate an attacker attempting to complete authentication, but the outcome and surrounding sign-in activity determine its meaning.
Look beyond the prompt
Check whether access succeeded, whether a new authentication method appeared, whether session activity followed and whether the user confirms the action.
Stage 6 — inspect post-authentication behaviour
let User = "alex@contoso.com";
CloudAppEvents
| where Timestamp > ago(2h)
| where AccountId =~ User
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
RawEventData
| order by Timestamp ascAuthentication is not the final stage
If the account was accessed, determine what the session did next: mailbox rules, forwarding, file access, consent, privilege changes or other actions.
Post-authentication behaviour strengthens the case
A suspicious sign-in followed by unusual mailbox or cloud activity is a stronger compromise story than either event alone.
Stage 7 — decide whether the incident changed category
Category should follow scope
The original alert source should not restrict how you describe the incident once evidence shows compromise across another security domain.
Preserve the entry vector
Calling it an identity incident does not erase the phishing evidence. The email remains part of the causal timeline and may help identify other targeted users.
Stage 8 — expand the scope
| Scope question | Pivot |
|---|---|
| Was the same phishing message sent to others? | Search message or URL indicators |
| Did other users click? | Review user interaction telemetry |
| Did the same IP access other accounts? | Search sign-in activity by IP |
| Did the account access sensitive services? | Review cloud activity |
| Did endpoint activity follow? | Pivot to device telemetry |
One compromised account may not be the whole incident
The phishing campaign may involve multiple recipients, and the attacker infrastructure may have touched additional identities.
Scope before closure
Do not close the case simply because you understand what happened to the first user. Determine whether the activity is isolated or broader.
Stage 9 — decide on containment
Contain the identity, not only the email
Deleting the phishing message does not remove an attacker's authenticated access if the account or session has already been compromised.
Containment must follow scope
Actions should address the current attack state while preserving enough evidence to understand what happened and whether other users are affected.
Stage 10 — write the incident finding
Write the causal chain
A strong finding explains not just that multiple alerts occurred, but how the evidence links them into one coherent incident.
Separate fact from inference
Document what telemetry confirms and clearly identify conclusions that depend on correlation or user confirmation.
Lesson 92 key takeaways
- A phishing investigation may quickly become an identity investigation.
- The click timestamp is a critical pivot into other telemetry.
- Look for sign-in activity immediately after user interaction.
- Sequence across services can be more meaningful than individual alerts.
- Successful authentication raises urgency beyond failed attempts.
- MFA events need outcome and surrounding context.
- Post-authentication activity helps confirm whether access was used.
- Incident classification should follow the evidence and current scope.
- Preserve the phishing email as the likely entry vector.
- Search for additional recipients, identities and related infrastructure.
- Email containment alone is insufficient after identity compromise.
- Write the final finding as a causal timeline supported by evidence.
Module 10 — Complete SOC Investigation Scenarios
Lesson 92 followed a phishing case from email delivery into identity compromise. Lesson 93 continues the same investigative mindset when suspicious identity activity reaches an endpoint.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 10: Complete SOC Investigation Scenarios
How can a phishing email become an identity incident?
Lesson 92 of the Agent Foskett SOC Analyst Academy follows a phishing investigation from email delivery and user interaction into suspicious authentication, MFA activity and post-authentication behaviour.
Correlating email and identity security incidents
Learn how to build a cross-service timeline, pivot from a phishing click into sign-in telemetry, assess successful access, scope related activity and decide when the incident has expanded beyond email.
