Lesson 46 — The User Entered Their Credentials
The phishing investigation had already confirmed the click.
Then the user added one sentence that changed the incident again:
“Yes... I typed my email address and password into the page.”
Agent Foskett no longer had only an email incident.
The SOC now had to assume the credentials may have been exposed and determine whether somebody tried to use them.
The investigation had crossed from email telemetry into identity telemetry.
The credentials were entered
The analyst must now correlate the phishing timeline with sign-ins, MFA activity, sessions and other identity changes.
Case briefing
Investigation objective
Move from confirmed credential exposure into identity investigation, correlate post-phishing sign-ins with the known timeline and determine whether the exposed credentials were used successfully.
Investigator's rule
Credential exposure and account compromise are not identical findings. Treat the credentials as exposed, then use identity evidence to determine whether unauthorised access occurred.
Stage 1 — establish the exposure window
Do not start with geography alone
A strange country can be useful context, but VPNs, mobile networks and cloud infrastructure can make location misleading. Start with the complete sign-in record.
Preserve the user's normal context
Known device, usual IP ranges, applications and authentication patterns help distinguish normal activity from the events that follow credential exposure.
Stage 2 — review the user's sign-ins
let ExposureTime = datetime(2026-09-01 10:09:06);
SigninLogs
| where TimeGenerated between (ExposureTime - 30m .. ExposureTime + 6h)
| where UserPrincipalName =~ "alex@contoso.com"
| project TimeGenerated,
UserPrincipalName,
AppDisplayName,
IPAddress,
Location,
ResultType,
ResultDescription,
ConditionalAccessStatus
| order by TimeGenerated asc
Look at failures and successes
A failed attempt can show that someone tried the exposed credentials. A successful sign-in changes the investigation again and requires deeper review of authentication and session evidence.
Timing is powerful evidence
An unfamiliar sign-in attempt minutes after credential entry is more meaningful when it is correlated with the known phishing timeline rather than viewed as an isolated event.
Stage 3 — compare the sequence
Correlation changes confidence
No single timestamp proves attacker activity by itself. The combination of phishing interaction, unfamiliar infrastructure and immediate authentication attempts builds a much stronger story.
Do not stop at ResultType
A successful sign-in is the beginning of another evidence path. Determine how authentication was completed and what the resulting identity did.
Stage 4 — inspect authentication details
SigninLogs
| where TimeGenerated > ago(1d)
| where UserPrincipalName =~ "alex@contoso.com"
| project TimeGenerated,
IPAddress,
AppDisplayName,
AuthenticationRequirement,
AuthenticationDetails,
ConditionalAccessStatus,
ResultType,
ResultDescription
| order by TimeGenerated asc
Was MFA involved?
Review the authentication requirement and details. If MFA was required, determine whether the sign-in failed, was satisfied or requires further investigation.
Password theft may not be the whole story
If the attacker also obtained an MFA approval, token or session, simply changing the password may not explain or contain every part of the incident.
Stage 5 — compare suspicious IP activity
let SuspiciousIP = "203.0.113.77";
SigninLogs
| where TimeGenerated > ago(7d)
| where IPAddress == SuspiciousIP
| summarize
Attempts = count(),
Users = dcount(UserPrincipalName),
Applications = make_set(AppDisplayName, 20)
by IPAddress
| order by Attempts desc
Was only one account touched?
If the same infrastructure attempted authentication against multiple users, the incident may be broader than the original phishing recipient.
Scope before you close
A credential-phishing campaign may target many people even when only one user reports the message. Reuse attacker infrastructure as a pivot where appropriate.
Stage 6 — look beyond authentication
| Evidence | Question for the SOC |
|---|---|
| Successful unfamiliar sign-in | Was this genuinely the user or unauthorised access? |
| MFA activity | Was an MFA challenge approved, denied or otherwise satisfied? |
| New authentication method | Did the account's authentication configuration change? |
| Mailbox rule / forwarding | Did the account establish persistence or data redirection? |
| OAuth consent | Was access granted to an application? |
| Session activity | Did access continue after password remediation? |
The password is only one control
Once identity compromise is suspected, investigate the account as a collection of credentials, authentication methods, sessions, permissions and cloud activity.
Response and investigation happen together
When exposure is confirmed, the SOC may need to trigger containment while continuing to determine impact. Preserve the timeline so response actions do not erase the story.
Stage 7 — distinguish the possible findings
Stage 8 — build the complete timeline
Stage 9 — write the investigation finding
Lesson 46 key takeaways
- Confirmed credential entry should immediately expand a phishing investigation into identity telemetry.
- Credential exposure does not by itself prove account compromise.
- Use the phishing timeline to anchor sign-in investigation.
- Review both failed and successful authentication attempts.
- Compare IP address, application, timing and the user's normal context.
- Inspect MFA and authentication details rather than relying only on success or failure.
- A successful unfamiliar sign-in requires post-authentication investigation.
- Scope suspicious infrastructure across other users where appropriate.
- Password remediation alone may not address sessions, authentication methods or permissions.
- Write findings that clearly separate exposure, attempted use and confirmed or suspected access.
Module 5 — Email & Phishing: From Message to Compromise
Lesson 46 moved the phishing investigation into identity response. Lesson 47 returns to the mailbox, where a newly created inbox rule may reveal what happened after access was gained.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 5: Email & Phishing: From Message to Compromise
Investigate phishing credential theft with Microsoft Defender XDR and Entra sign-in logs
Lesson 46 of the Agent Foskett SOC Analyst Academy teaches analysts how to move from a confirmed phishing credential entry event into identity investigation using sign-in, MFA, IP address and post-authentication evidence.
From phishing email to identity compromise investigation
Learn how to correlate the phishing timeline with SigninLogs, distinguish credential exposure from attempted or successful unauthorised access, scope suspicious infrastructure and build a defensible SOC finding.
