DFIR Tools · Research · Blog

From Password Theft to Session Theft

The older phishing model was fairly easy to explain. A user received an email, clicked a link, landed on a fake login page, entered a username and password, and the attacker tried to use those credentials before the user or organization realized what happened. MFA made that attack harder because the password alone was no longer enough in many environments.

Attackers adjusted. Instead of only trying to steal the password, modern phishing campaigns often try to steal the authenticated session. That is a different problem. A user may type their password into what looks like a normal Microsoft sign-in page, complete MFA, and still have the resulting session stolen or abused.

That is the part defenders need to be careful with. A successful MFA result in Entra ID does not automatically mean the session is legitimate. It may only mean the user completed MFA at some point during the attack chain. The better question is what happened after that authentication completed. Did the session come from the user’s normal location, device, browser, ASN, and behavior pattern? Or did mailbox access, inbox rule creation, OAuth consent, or suspicious searches start a few minutes later from infrastructure the user has never used?

That distinction matters in Microsoft 365 investigations. If the investigation stops at “MFA was satisfied,” there is a real chance the actual compromise gets missed.

Session Cookies, Access Tokens, and Refresh Tokens

When a user signs in to Microsoft 365 or another cloud service, the service needs a way to remember that the user already authenticated. Otherwise, the user would have to sign in again every time Outlook refreshed, Teams loaded, or a SharePoint file opened.

That is where cookies and tokens come into play.

This is why I do not like treating token theft as a simple password problem. The password may have been captured, but the bigger issue may be the active session, refresh tokens, OAuth grants, mailbox persistence, or endpoint malware that allowed the session material to be stolen in the first place.

Adversary-in-the-Middle Phishing

Adversary-in-the-Middle phishing, usually shortened to AiTM, is one of the clearest examples of this. In a normal fake login page, the attacker collects whatever the victim types into the page. In an AiTM attack, the phishing server acts as a reverse proxy between the victim and the real service.

The victim clicks the link and sees what appears to be a Microsoft login. In the background, the attacker-controlled server is forwarding the traffic to the real Microsoft login page. The user enters credentials and completes MFA against the real service. From the user’s perspective, the login may look completely normal.

The problem is that the proxy is sitting in the middle of the authentication flow. When the real service returns session cookies or other authentication artifacts after successful login, the attacker-controlled infrastructure may capture them. At that point, the attacker may not need to know the user’s MFA method. The user already completed MFA, and the attacker is now trying to use the session material created from that login.

Frameworks such as Evilginx are commonly discussed here because they show how reverse-proxy phishing can be automated. The specific framework is not the main point. The point is that a user can authenticate to the real service, successfully complete MFA, and still have the session captured.

Once the attacker has a usable session cookie, they may import it into a browser session and access Outlook on the web, SharePoint, Teams, or other cloud applications. What happens next usually looks more like account takeover than basic phishing: mailbox reconnaissance, invoice searches, Teams review, inbox rule creation, external forwarding, suspicious sends, or attempts to create longer-term access through OAuth consent.

Device Code Phishing in Microsoft 365

Device code phishing is different, but it gets to the same general problem: a legitimate authentication workflow can be abused.

The OAuth device code flow exists for devices that do not have a normal browser or keyboard experience. A device shows a short code, the user goes to a Microsoft verification page, enters the code, signs in, and authorizes the device.

Attackers abuse that by generating a device code from their own system and tricking the user into entering it on Microsoft’s legitimate verification page. The lure may look like a document review, Teams meeting, voicemail, security check, or some other workflow the user is willing to follow.

This is why device code phishing can be frustrating from a user-awareness standpoint. The Microsoft page can be real. The login can be real. MFA can be real. The problem is that the user is authorizing a session or application flow the attacker initiated.

Browser Cookie Theft and Infostealers

Not every token theft event starts with an AiTM phishing site. Sometimes the cloud identity issue starts with endpoint compromise.

Commodity infostealers and other malware often target browser data because browser data is valuable. Cookies, saved credentials, autofill data, browser profiles, and local application data can all help an attacker. If the malware runs in the user context, it may try to collect browser cookie databases, browser profile folders, local tokens, or credentials stored across multiple browsers.

The initial lure may be a fake installer, fake browser update, malicious attachment, fake CAPTCHA, cracked software download, or some other payload. Once the malware executes, it can collect browser artifacts and send them to attacker infrastructure. The attacker then attempts to reuse those cookies or tokens against cloud services.

That changes the response. A password reset alone is not enough. Revoking sessions may not be enough if the endpoint is still compromised. The workstation, browser profile, persistence mechanisms, suspicious downloads, scheduled tasks, startup items, PowerShell activity, and outbound connections all need to be considered.

What I Would Look for in Microsoft 365

In Microsoft 365, these investigations usually require more than one evidence source. One log entry rarely tells the whole story. The better approach is to build a timeline across identity, mailbox, endpoint, and application activity.

Entra ID sign-in logs

Entra ID sign-in logs are usually one of the first pivots. I would look for unfamiliar IP addresses, impossible travel, new countries, unfamiliar ASNs, hosting providers, VPN or proxy infrastructure, TOR indicators, new user agents, abnormal client apps, and sign-ins that do not match the user’s normal baseline.

Example sign-in pattern:

User: xxxx1234@rivercitydigitalforensics.com
Result: Success
MFA requirement: Satisfied
IP address: 185.XXX.XXX.24
Location: Country not normally associated with the user
User agent: New browser / unfamiliar platform
Client app: Browser
Risk detail: Unfamiliar sign-in properties / atypical travel
Follow-on activity: Exchange Online mailbox access

The important part is not just that the sign-in succeeded. The important part is whether the session behavior makes sense for that user. Successful MFA followed by an unusual browser, new geography, suspicious mailbox access, or activity from a hosting provider should not be ignored simply because MFA shows as satisfied.

Mailbox activity

Mailbox auditing helps show what the attacker did after access was obtained. I would review message access, mailbox searches, folder access, inbox rule creation, forwarding changes, deletions, send activity, and access to sensitive conversations.

In business email compromise activity, common search terms often include invoice, payment, wire, ACH, bank, purchase order, payroll, tax, gift card, and similar financial terms.

Example mailbox activity sequence:

08:41 - Successful sign-in from unusual IP
08:43 - MailItemsAccessed events begin
08:47 - SearchQuery initiated for "invoice" and "wire"
08:52 - Inbox rule created to move replies to a hidden or rarely used folder
09:04 - External reply sent from the compromised mailbox

OAuth consent

OAuth consent activity is another area I would not skip. Attackers may try to maintain access by getting the user to grant permissions to an application. Depending on the permissions, that application may be able to read mail, access files, send mail, or keep access through offline permissions.

Review newly consented applications, unverified publishers, unusual application names, suspicious service principals, delegated permissions, and grants involving offline_access, Mail.Read, Mail.Send, Files.Read.All, or similar permissions. The timing matters too. Consent activity occurring right after suspicious sign-ins should get attention.

Impossible travel and user agents

Impossible travel is useful, but it is not enough by itself. Attackers know geography-based detections exist. They may use residential proxies, VPNs, or infrastructure near the victim to avoid obvious impossible-travel alerts.

User agent and ASN analysis can help fill that gap. A sudden change from a normal Windows Edge profile to a Linux Chrome user agent, automation-looking browser, mobile browser, or activity from a hosting provider may be meaningful when it lines up with mailbox activity or OAuth changes.

Short Incident Response Scenario

Detection Opportunities

Token theft detection works best when identity, endpoint, and cloud application telemetry are correlated. Some useful detection opportunities include:

• Successful MFA followed by abnormal access: Watch for MFA-satisfied sign-ins followed by unfamiliar IPs, new user agents, impossible travel, or mailbox activity that does not fit the user.
• Session reuse indicators: Look for activity from a new ASN, hosting provider, VPN, proxy, or geography that does not match the original authentication context.
• Device code flow abuse: Review device code authentication patterns, especially when the user did not initiate the workflow or the application context looks unusual.
• Suspicious OAuth consent: Alert on unverified publishers, high-risk permissions, offline access, and consent activity near suspicious sign-ins.
• Mailbox post-compromise behavior: Detect inbox rule creation, external forwarding, unusual search activity, mass message access, suspicious sends, or deletion activity.
• Endpoint browser theft: Alert on suspicious access to browser cookie stores, credential databases, browser profile directories, or archived browser data.
• Risky infrastructure: Enrich IP addresses with ASN, hosting provider, VPN, proxy, TOR, and residential proxy context where possible.

Practical Mitigation Recommendations

There is not one control that fixes this entire problem. The goal is to make token capture harder, make replay less useful, detect abnormal session behavior faster, and reduce the blast radius when compromise happens.

Use phishing-resistant authentication

FIDO2 security keys and properly implemented passkeys are stronger options because they are designed to resist phishing by binding authentication to the legitimate origin. For privileged users, administrators, finance staff, executives, and other high-risk users, phishing-resistant MFA should be prioritized.

Strengthen Conditional Access

Conditional Access should evaluate more than whether MFA happened. Device compliance, trusted locations, sign-in risk, user risk, application sensitivity, session controls, and authentication strength all matter. For sensitive applications, requiring compliant or hybrid joined devices can significantly reduce risk when it is operationally feasible.

Evaluate token protection

Token protection is intended to reduce replay risk by binding tokens to the device where they were issued. It may not fit every environment or every use case, but it is worth evaluating for high-value users and sensitive applications where licensing and platform support allow it.

Control OAuth consent

User consent should not be wide open in environments where sensitive data is stored. Require administrative approval for high-risk permissions, review enterprise applications, remove stale or suspicious service principals, and monitor delegated permissions.

Harden endpoints

Endpoint controls matter because infostealers can turn a workstation compromise into a cloud compromise. EDR, application control, browser hardening, least privilege, patching, attachment controls, and detection for suspicious browser data access all help.

Update user awareness

User awareness needs to go beyond “do not type your password into a suspicious website.” Users need to understand QR-code phishing, device code phishing, fake file shares, fake voicemail portals, MFA fatigue, fake CAPTCHA payloads, and the risk of entering codes they did not initiate.

Response Actions When Token Theft Is Suspected

When token theft is suspected, move quickly and treat it as more than a password issue. At minimum, defenders should consider the following:

• Revoke user sessions and refresh tokens.
• Reset the password if credential capture is possible.
• Review and remove malicious inbox rules and forwarding settings.
• Review OAuth consent grants and remove suspicious applications or permissions.
• Check Entra ID sign-in logs for related IPs, user agents, applications, and devices.
• Review mailbox audit logs for access, searches, sends, deletions, and rule creation.
• Examine the endpoint for infostealer activity, suspicious downloads, persistence, and browser data access.
• Scope by IP address, phishing URL, user agent, application ID, OAuth grant, sender, recipient, and message artifacts.
• Preserve logs before retention windows become a problem.

The main mistake I would avoid is calling this done after a password reset. If the session was stolen, the response has to address active sessions, refresh tokens, application grants, mailbox persistence, endpoint compromise, and the possibility that other users interacted with the same phishing infrastructure.

Key Takeaways

• Modern phishing increasingly targets sessions, not just passwords. A user can complete MFA successfully and still have the resulting session stolen.
• MFA is necessary, but it is not the whole answer. Traditional MFA needs to be paired with phishing-resistant authentication, Conditional Access, device trust, token protection, monitoring, and response discipline.
• Microsoft 365 investigations need multiple evidence sources. Entra ID sign-in logs, mailbox audit logs, OAuth consent events, endpoint telemetry, and IP enrichment all matter.
• Device code phishing can use a real Microsoft page. A legitimate login page can still be part of the attack if the user is authorizing an attacker-controlled session.
• Infostealers can turn endpoint compromise into cloud compromise. Browser cookie theft means identity response and endpoint response need to work together.
• Successful MFA should not end the investigation. The better question is whether the authenticated session behaved like the real user afterward.