Start by tracing the session ID back to the earliest login event, then inspect the originating IP, user agent, and authentication sequence. In AitM cases, the first login often comes from hosting infrastructure rather than a normal user location. Cross reference cloud logs with firewall, DNS, or EDR telemetry to confirm whether the account reached a phishing domain before the authenticated session began.
How to investigate the first successful login, not just the alert
When MFA appears to have succeeded, the key question is whether the session was actually established by the user or by a phishing proxy that relayed the exchange in real time. Investigators should reconstruct the authentication chain from the earliest event, then compare the origin, device, and sequence of actions against the user’s normal pattern. AitM campaigns often look clean at the MFA layer while the surrounding telemetry tells a different story.
The practical focus is on session establishment, not password validity. If the first authenticated event came from hosting infrastructure, an unfamiliar ASN, or a browser fingerprint that does not match the user’s usual device, that is evidence the attacker controlled the interaction path even though the MFA challenge itself was accepted. Correlating cloud sign-in logs with network, DNS, and endpoint telemetry helps prove whether the victim reached the phishing domain before the authenticated session began.
Useful supporting reference material includes CoPhish OAuth Token Theft via Copilot Studio for token-stealing phishing mechanics, and CISA cyber threat advisories for adversary tradecraft context.
What evidence distinguishes a relayed MFA success from a legitimate sign-in
Start by separating the authentication ceremony from the post-authentication session. In many AitM cases, the MFA prompt is genuine from the user’s point of view, but the proxy forwards the result to the attacker in time for the session cookie, token, or authorization code to be captured. That means the investigation should look for mismatches across IP reputation, geolocation, user agent, TLS fingerprint, and device posture, not just whether MFA was marked successful.
Session IDs, refresh tokens, and OAuth artifacts matter because they show whether the attacker only observed the login or actually obtained reusable access. If the account immediately starts a new session from a different location, or the token is used from infrastructure that never matched the victim’s endpoint, the compromise likely continued after the phishing page closed. This is where early telemetry is decisive: the first successful login event often tells you more than the later suspicious activity.
Good corroborating sources are NIST SP 800-63 Digital Identity Guidelines for phishing-resistant authentication concepts, and Ultimate Guide to NHIs for visibility and lifecycle issues around credential and token handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Phishing-Resistant Authentication — Phishing-Resistant Authentication | AitM phishing succeeds by relaying authentication despite MFA. |
| Recommendation — Adopt phishing-resistant authenticators to prevent real-time relay of login completion. | ||
| CIS Controls v8 | 5 — Account Management | Investigation turns on validating the account's login and session activity. |
| 8 — Audit Log Management | The answer relies on tracing the earliest login and correlating telemetry sources. | |
| Recommendation — Correlate account activity and revoke suspicious sessions immediately. Centralize and review sign-in, DNS, firewall, and endpoint logs for relay indicators. | ||
| MITRE ATT&CK | T1557 — Adversary-in-the-Middle | The question is specifically about attacker-in-the-middle phishing behavior. |
| Recommendation — Map observed login relay patterns to AitM techniques and hunt for proxy infrastructure. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Credential and Secret Exposure | Stolen sessions and tokens are the core abuse path in relayed phishing. |
| Recommendation — Treat exposed tokens and session material as compromise indicators requiring rapid invalidation. | ||
Practitioner Guidance
What to verify: Confirm the earliest successful authentication event, then validate whether the source IP, user agent, and device posture match the user’s historical baseline. If the login path includes a phishing domain, a proxy layer, or a jump from consumer hosting infrastructure, treat the MFA success as evidence of relay, not proof of legitimacy.
Decision rule: If the session token or OAuth artifact was issued after the victim visited a suspicious domain, prioritize token revocation, session invalidation, and account containment before spending time on password reset alone. Password resets do not neutralize a stolen session or replayed authorization artifact.
Practitioner takeaway: In AitM incidents, the decisive question is whether the attacker captured the authenticated session, not whether MFA technically completed, so the investigation must prove where the login originated and what token the attacker may have inherited.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of Adversary in the Middle phishing when MFA alone is no longer enough?
- How should security teams detect lateral movement when normal administrative authentication looks similar to attacker activity?
- Why are NHIs a critical concern for security teams?
- What steps should security teams take to prevent Shadow AI risks?
