Password theft gets most of the attention. What happens afterwards is easier to overlook. Once a user signs in, the browser usually receives a session cookie so that it does not have to repeat the full authentication process on every page. That convenience creates something else worth stealing.
- Fake addressthe target opens a relay site
- Real sign-inthe relay forwards the exchange
- MFA completedthe user finishes the process
- Session copiedthe cookie is replayed
What the intermediary changes
A conventional phishing page collects whatever the user types. An adversary-in-the-middle, or AiTM, site relays the exchange to the real service as it happens. The user sees a fake address, while the password and second factor complete a genuine authentication in the background. The intermediary can then capture the session cookie returned by the service.
Microsoft documented this route in July 2022 in a campaign that led to mailbox access and attempts to prepare fraud inside business conversations. The number of organisations targeted should not be read as a count of successful compromises. The report describes a campaign, not the complete incident record of one named victim.
MFA may work while the session is stolen
Saying that “MFA was broken” loses an important distinction. The real service may have checked both the password and the second factor correctly. The result of that check was then exposed as a reusable session.
Authentication methods do not all behave in the same way. A one-time code limits the time available for reuse, but it can still be relayed while valid. A WebAuthn key checks the origin and does not hand a fake page a reusable secret for the real service. This gives strong protection against copied login pages. It does not secure an already compromised browser or every action taken after sign-in.
A session is already permission to act
A session can allow someone to read mail, open files and perform operations without presenting the password again. Its lifetime, storage and revocation deserve the same attention as the first authentication.
A separate Microsoft report from June 2023 shows what can follow. After replaying stolen sessions, attackers took advantage of weak policies around MFA method changes, created mailbox rules and sent more than 16,000 phishing emails from compromised accounts. This was a different campaign from the 2022 case, but it makes the reach of one session easy to understand.
Changing an MFA method is itself a sensitive operation. Adding a sign-in or recovery method alters the conditions of future access. An ordinary browsing session should not silently become sufficient proof for that change.
A password reset may leave access behind
The first incident-response question should be simple: what was exposed? The answer determines whether the team needs to deal with a password, active sessions, newly added factors, delegated consent, mailbox rules or the endpoint itself.
Resetting the password can still be useful. It does not prove that every session and token has gone away. Revocation has to be checked on the relevant applications. Otherwise, the response team has run a command without knowing whether the attacker’s access has actually ended.
What I would look for in the logs
- a session used from an unusual context soon after authentication
- a new factor or recovery method
- mailbox rules, consent grants or exports that were not present before
- the time from the report to the first containment action, and then to verified loss of access
An IP address or location is not enough on its own. Legitimate users change networks, and attackers can choose nearby infrastructure. The sequence of events is often more informative than one isolated signal.