Why a Phishing Page Can Capture More Than a Password

An adversary-in-the-middle phishing site can relay a real sign-in and capture session material along the way. Reaching the expected work page afterward does not tell you whether that happened.

Investigators need to establish what happened after the sign-in: was session material captured, and did a later request succeed? MFA on the account and a visit to a suspicious page cannot settle either question.

How the campaign Microsoft investigated reached mailboxes

In July 2022, Microsoft reported an AiTM campaign that used phishing sites to capture credentials and session cookies. Investigators observed subsequent access to affected mailboxes and payment-fraud activity, including manipulation of inbox rules. Microsoft: cookie theft and business email compromise

Here, adversary-in-the-middle, abbreviated AiTM, means an attacker-controlled intermediary relays communication between the person and the service being impersonated. The person interacts with the attacker’s site while the intermediary communicates with the legitimate service. Microsoft’s reported flow used separate Transport Layer Security (TLS) encrypted connections on each side. A secure connection to the wrong destination does not establish that the destination is trustworthy. Microsoft: how AiTM phishing works

Why the sign-in can look convincing

A relayed interaction can display legitimate branding and respond to a user’s authentication steps. In the reported campaign, users could end up on a legitimate page after the phishing interaction. Reaching that page therefore did not establish that the preceding sign-in path was safe. Microsoft: campaign initial access

Employees should open the application through their usual entry point and report an unexpected sign-in request. Investigators need the original message and the sequence of pages visited, preserved through the incident process. A screenshot of the final legitimate page leaves out the part of the journey that matters.

That observation also changes assessment design. If a campaign only records page visits, it can measure exposure to the page. It cannot establish whether authentication completed, whether reusable material was captured, or whether a resource accepted later requests.

Which session are we talking about?

A session cookie is information a browser sends to a matching website so the site can associate requests with a session. Session identifiers deserve protection because a usable identifier can confer the authority of the session it represents. Their effective lifetime and validity depend on server-side session handling, not simply on whether the browser displays a cookie. OWASP: session management

An identity provider and an application can maintain separate sessions. The identity provider’s session supports sign-in interactions; the application’s session supports continued use of that application. An API access token is another credential with its own intended recipient. Our tokens and cookies explainer walks through those roles in a server-side portal.

Consider a web portal using OpenID Connect, a protocol through which an application learns the result of authentication at an identity provider. In its authorization-code flow, the application exchanges a returned code for tokens and validates the ID token. The ID token describes the authentication result for the client; it is not a universal browser-session cookie. OpenID Connect Core: authorization-code flow

That creates two different questions after suspected theft. Reuse of an identity-provider session may allow a later authentication interaction without repeating the original prompts, subject to the applicable requirements. Reuse of an application session asks that application to continue an existing session. To determine which occurred, inspect the accepting service and any intervening authentication. The generic phrase “cookie replay” cannot supply those missing facts. OpenID Connect Core: authenticating the end user, OWASP: session management

The figure separates a relayed authentication exchange from a later reuse attempt. Its final question belongs to the service accepting the captured material, which must be identified during investigation.

Relayed sign-in and separate reuse

1. User’s browser → Intermediary

   Sends authentication input to the attacker’s site; pages and responses travel back.

2. Intermediary ↔ Legitimate service

   Relays requests and service responses over a separate TLS connection. May capture usable session material.

3. Separate reuse attempt

   The attacker presents captured session material to an accepting service.

4. Operation outcome

   Which session was accepted? What result followed? Verify the protected operation separately.

Capture and reuse are not guaranteed. The legitimate service still applies authentication controls.

MFA methods have different properties

An MFA prompt asks for additional authentication evidence. That alone does not mean the method binds the authentication to the intended website. NIST describes phishing resistance in terms of preventing disclosure of valid authentication outputs to an impostor verifier. It identifies verifier-name binding as one approach, including WebAuthn-based mechanisms. Manually entered authentication outputs do not provide that property merely because they are a second factor. NIST: phishing resistance

This is why “AiTM bypasses all MFA” is a poor explanation. Ask which method the user actually performed, what the intended verifier was, and which policy required that method. Phishing-resistant authentication addresses the impersonated-verifier problem; it is not a promise that every session is immune to theft through every other mechanism.

Microsoft Entra authentication strengths let administrators specify permitted combinations of authentication methods for access to a resource. Microsoft supplies a phishing-resistant strength alongside other strengths. Check whether the policy requires that method for the users, resources, and conditions you are investigating. Making it available for enrollment is not enough. Microsoft: authentication strengths

Our MFA claim guide explains another boundary: a record indicating MFA was satisfied is not, by itself, proof that the current person operating a session is the intended employee.

Use four questions in the investigation

What interaction occurred? Retain the message, destination, affected account, and relevant time window. Distinguish a page load from a submitted authentication attempt. If the navigation path is unavailable, record the gap rather than reconstructing it from a familiar attack description.

What authentication and session events are supported? Ask the identity owner to interpret the available sign-in evidence in its documented context. Keep the application, resource, and identity separate. Our sign-in evidence guide provides a starting point for that review.

What operation did the application permit? Request the resource’s evidence for the action under investigation. A successful protected read supports a read-access conclusion. It does not establish modification, export, or access to every record. Name the account, operation, target, and result.

What did defenders observe and do? Separate a collected event from an alert, and an alert from analyst response. Record the observation window and the evidence available to each team. If no alert is found, check collection and review coverage before declaring the entire technique undetectable.

Verify fresh access during containment

After containment, check a fresh protected request. A browser can display previously loaded content even when the session no longer works. OWASP recommends preventing sensitive responses from being stored in caches, but investigators must check the actual behavior rather than assume that recommendation was implemented. OWASP: web content caching

If the request succeeds, establish whether new authentication preceded it. If it is denied, retain the result and ask the resource owner to interpret the denial. Neither outcome establishes what happened to every other session or resource.

What belongs in the incident record

For your next review, fill in these fields before choosing a headline for the finding:

• The starting message and verified destination sequence.
• The account, authentication method, and applicable policy.
• The session or credential type and accepting service, if established.
• The separately authorized protected operation and its result.
• The event, alert, and response evidence within the review window.
• The unresolved questions, receiving owner, and next verification step.

Do not place usable session secrets in the incident record. Retain references to securely handled evidence instead. OWASP recommends avoiding direct session identifiers in logs and using appropriate correlation techniques when needed. OWASP: logging session lifecycle

Finally, verify containment against the actual session types involved. Removing one credential or changing a password should not be treated as evidence that every application session ended. Use the identity containment review to identify the relevant objects and define a fresh protected request that can establish the intended result.