Microsoft 365 Phishing Despite MFA: Session Hijacking

Microsoft 365 phishing involves more than poorly written emails and fake sign-in pages. Attacks can start from a compromised business account, lead to deceptively authentic or legitimate Microsoft pages and, despite MFA, end in a mailbox, SharePoint or Teams.

The 2026/1 semi-annual report from the Swiss Federal Office for Cyber Security concerns Swiss companies. Reports of compromised Microsoft 365 accounts increased in the first half of 2026. They were used for phishing and fraud. Attackers posed as IT help desks or executives and bypassed controls using session tokens, device code phishing or reverse proxies.

MFA remains essential. Not every method is phishing-resistant. An authenticated session can become the target of an attack. Microsoft 365 must be secured as an identity platform, not merely as an email service.

How Microsoft 365 phishing works despite MFA

After checking the password, second factor, device status and conditions, Entra ID issues tokens or session cookies. As with a visitor pass, their validity is then what matters most. If they fall into someone else’s hands, that person may not have to repeat the checks.

Token types in Microsoft Entra ID differ in purpose and lifetime. The key point is: A token that is stolen or released to an attacker can represent an authenticated session.

Adversary-in-the-Middle phishing with a reverse proxy

In Adversary-in-the-Middle (AiTM) attacks, the phishing infrastructure sits between the browser and Microsoft and relays the genuine sign-in in real time:

1. An email links to what appears to be a SharePoint document, voicemail, invoice or signature request.
2. The link routes the user to the Microsoft sign-in through the attacker’s reverse proxy.
3. The username, password and MFA response are forwarded to Microsoft.
4. Microsoft accepts the authenticated sign-in and establishes the session.
5. The proxy intercepts the session cookie or tokens. Access only ends when they expire, are revoked or are blocked.

MFA has not been cracked. The user authenticated a session that was being intercepted. TOTP codes and push approvals do not inherently prevent this relay. FIDO2 keys, Windows Hello for Business and correctly implemented passkeys, by contrast, bind the sign-in cryptographically to the legitimate service. Even they do not protect against malware on a signed-in device or every form of session theft.

Device code phishing through a genuine Microsoft page

The device code flow is intended for devices without a convenient input method. A conference-room device or command-line application displays a code that is confirmed through Microsoft on a second device.

Attackers initiate the flow themselves and send the code under a pretext. After the victim enters it on the genuine Microsoft page, the tokens are delivered to the attacker’s session. The domain and certificate are correct, but a third party’s sign-in is being authorised. Microsoft considers the flow high-risk and recommends blocking it when there is no documented need.

Email flooding, fake IT support and chain phishing

One attack chain starts with hundreds of newsletter, registration and notification emails. This creates stress and conceals genuine warnings. Someone posing as IT support then requests a Quick Assist session or another remote-support tool through Teams or by phone. This can be used to run commands, install malware, read browser data and steal credentials. The workstation, rather than the sign-in itself, is compromised.

After taking over the account, the attacker uses genuine correspondence, known suppliers and existing conversation threads for manipulated invoices, further phishing and new account takeovers. SPF, DKIM and DMARC are not enough when the message originates from the legitimate Microsoft 365 tenant.

What MFA achieves and where its limits lie

MFA prevents many account takeovers because a password alone is no longer sufficient. The methods differ:

• Password plus SMS, phone call or simple push approval: better than a password alone, but vulnerable to social engineering, SIM swapping, MFA fatigue and real-time phishing.
• TOTP or Authenticator with number matching: more robust against accidental approvals, but a code entered on an AiTM page can still be relayed immediately.
• Phishing-resistant authentication: FIDO2, Windows Hello for Business, certificate-based authentication and passkeys cryptographically verify the legitimate service and significantly reduce AiTM sign-ins.

Risks remain: an infected endpoint can read sessions, an OAuth application can gain persistent permissions, and a user can approve an unknown device code or remote-access request. Phishing-resistant MFA is central, but it is not a complete security strategy.

Hardening Microsoft Entra ID effectively

Conditional Access and Token Protection require suitable Entra licences, while device conditions require a managed device estate. Policies should first be tested in report-only mode with a pilot group.

Prioritise phishing-resistant sign-in

The initial rollout should include administrators, finance staff, executives and the help desk. Conditional Access authentication strengths can require Windows Hello for Business, FIDO2 keys, passkeys or certificate-based authentication for these groups.

This also requires a recovery process with at least two registered methods, tested replacement devices and separately monitored emergency accounts. A lost key must not cause either a prolonged outage or easily manipulated help-desk exceptions. Passkeys are also suitable for signing in to Sophos Central, although recovery and device changes must also be planned.

Review and, wherever possible, block device code flow

Usage can be inventoried in the Entra sign-in logs under Authentication protocol > Device code. Conference-room devices, legacy tools or command-line applications may depend on it. If there is no justified need, create a policy under Entra ID > Conditional Access > Policies:

1. Select regular users or groups.
2. Exclude emergency accounts and justified technical exceptions.
3. Under Target resources, select All resources wherever possible; use narrower targets only with justification.
4. Under Conditions > Authentication flows, enable Device code flow.
5. Under Grant, block access.
6. Start with Report-only, review the logs and only then enable the policy.

Exceptions should be narrowly scoped, documented and assigned to specific accounts or resources.

Tie access to managed devices

Conditional Access can require a compliant or Microsoft Entra joined device for sensitive applications. This makes token abuse from unknown devices more difficult, but affects BYOD, guests, mobile devices and specialist clients. The device estate, operating systems and applications must therefore be known. Stale records, weak enrolment or broad exceptions undermine the control.

Test Token Protection selectively

Token Protection cryptographically binds supported sign-in session tokens to the issuing device and makes replay on other systems more difficult. It requires Entra ID P1 and covers only certain platforms, applications and resources. On Windows, it primarily protects supported native Microsoft 365 applications. Apple devices require management and the Microsoft Enterprise SSO plug-in. Apple’s Mail and Calendar apps do not currently support Token Protection.

Start with a narrowly scoped deployment in report-only mode. Then review Token Protection Status Details, clients and resources in the sign-in logs. Enforce the policy only after compatibility has been confirmed. Assess browsers, legacy software and specialist devices separately.

Control Teams and remote support

Define which external domains or tenants may contact users through Teams and how external participants are identified. The following rules apply to support:

• Remote support starts only with a ticket or a verified callback to a known number.
• Unexpected Quick Assist sessions initiated through chats or phone calls are not accepted.
• Approved remote-support tools are documented and monitored.
• Unknown RMM tools are blocked or generate alerts through Application Control, AppLocker, Windows Defender Application Control or comparable controls.
• An unusual flood of email is reported to IT or Security rather than treated merely as spam.

Awareness training must reflect these processes. Sophos Phish Threat becomes more effective with clear reporting channels, Teams scenarios and a realistic help-desk runbook.

Evidence administrators should examine

A successful MFA event does not prove that a sign-in was legitimate. In an AiTM or device code attack, the factor may have been approved by the user. Identity, mailbox, endpoint and communications must be investigated together.

Microsoft Entra sign-in logs

The logs are available under Entra ID > Monitoring & health > Sign-in logs and can be read with the Reports Reader role or higher. Depending on the suspicion, the analysis should include interactive and non-interactive sign-ins, service principals and managed identities. Relevant indicators include:

• unknown or non-compliant devices, as well as unusual IP addresses, regions, applications and clients,
• Device code as the authentication protocol,
• new browser or device combinations following a normal sign-in,
• unusual access to Exchange Online, SharePoint or Microsoft Graph,
• the Conditional Access result, satisfied authentication requirements and
• successful access without expected user interaction through existing tokens.

No single signal is conclusive. A Swiss IP address may belong to a mobile network or VPN, while a foreign sign-in may be business-related. The combination of user, device, time, application and subsequent activity is what matters.

Exchange Online, audit and endpoint

After a takeover, attackers often search for invoices and conversation history. Check internal and external forwarding, visible and hidden inbox rules, delegations and Send As permissions, unusual search, read, download and sending activity, new OAuth consents and enterprise applications, changed authentication methods and every message sent during the relevant period.

Fake IT support leaves evidence on the endpoint: remote-support applications, downloads, PowerShell, MSHTA, scheduled tasks, browser access and suspicious processes. Email security, endpoint protection, and XDR or MDR can block and correlate these events, provided the data sources are licensed, integrated and monitored. The Sophos Fusion strategy supports this, but replaces neither Conditional Access nor the incident process.

Retention and detail levels for audit data depend on licensing and configuration. Both must be established in advance because logging enabled after an incident does not create historical data.

Response plan for a compromised Microsoft 365 account

Changing the password is not enough. Sessions, rogue MFA methods, OAuth consents and mailbox rules can remain active.

1. Use a clean administration device

If the endpoint may be compromised, change the password and perform administration from another device. Isolate the affected system without prematurely deleting evidence. Temporarily disabling the account may be appropriate during an active attack or when a privileged account is involved.

2. Revoke active sessions

Sessions can be revoked in the Entra admin centre or with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

Replace the User Principal Name as required. Depending on the application, token type and Continuous Access Evaluation, access may persist briefly. Verify the outcome in logs and applications.

3. Reset the password and clean up authentication

Change the password in the authoritative identity source. For synchronised or federated accounts, this is the local Active Directory or identity provider. Then review MFA methods, passkeys, phone numbers, devices and Temporary Access Passes, removing any unauthorised entries. If malware or remote access was involved, investigate the endpoint in parallel and rebuild it if necessary.

4. Review OAuth consents and roles

User consents, enterprise applications and suspicious service principals can enable persistent access. For privileged accounts, also review Entra, Azure and Microsoft 365 roles.

5. Review forwarding and inbox rules

Exchange Online PowerShell displays key mailbox settings:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Document and remove suspicious rules. Review delegations, Send As permissions and administrative transport rules separately.

6. Identify and notify subsequent victims

Message Trace and audit data reveal sent messages. Inform internal and external recipients before links, payments or further accounts are affected. If payment details were changed, contact the bank, accounting team and business partners through known channels. The article on immediate actions after phishing and hacking covers further steps.

7. Determine the cause and scope

Finally, determine whether AiTM, device code, approved MFA or remote support was involved; which SharePoint or OneDrive files were exfiltrated; whether further accounts, applications or devices were registered; and whether personal data or trade secrets were affected. Without root-cause analysis, the gap remains open.

Practical checklist for Microsoft 365 administrators

• Prioritise phishing-resistant sign-in for administrators, finance staff, executives and the help desk.
• Keep emergency accounts separate, monitored and regularly tested.
• Inventory device code usage, then block it or document justified exceptions.
• Test Conditional Access in report-only mode with a pilot group.
• Require managed devices for sensitive resources and deploy Token Protection only with compatible clients.
• Establish binding rules for external Teams communication, remote-support tools, help-desk callbacks and identity verification.
• Alert on email flooding, unusual sign-ins, OAuth consents and forwarding.
• Test session revocation, MFA cleanup, inbox rule review, sent-message tracing and endpoint isolation.
• Establish audit retention and responsibilities before an incident occurs.

My recommendation

MFA remains mandatory, but a password plus a push app does not adequately address modern attacks. Privileged and financially critical accounts should become phishing-resistant first. Device code controls, managed devices and Conditional Access follow. Token Protection needs a controlled rollout because of its limitations. In parallel, the help desk needs secure processes for unexpected Teams contacts.

What matters is the combination of strong identity, a trusted device, a controlled session, monitored communications and an incident plan that addresses active tokens and hidden persistence.

FAQ