A staff member opens a shared-document email, signs in and completes the authentication prompt. Everything looks normal. Later, someone else is reading their mailbox.
How does that happen if multi-factor authentication is enabled?
In my previous post, I covered how phone calls and malicious emails can lead to a breach. MFA is an important defence against those attacks, but the method used and what happens after sign-in both matter.
Here are three ways an attacker can still get access, and the practical steps a small business can take.
1. Someone approves the attacker's sign-in
An attacker with a stolen password may trigger authentication notifications until the account owner approves one. They might also call pretending to be IT support and say the approval is needed to fix a problem.
This is often called MFA fatigue or push bombing. The attacker is trying to turn an interruption into permission.
Number matching improves on a simple Approve button by requiring the user to enter a number displayed during sign-in. It helps reduce accidental approvals, but a convincing caller can still try to talk someone through the process. It is an improvement, rather than a phishing-resistant method. [1]
For staff: reject and report unexpected authentication requests. Contact IT using your normal support channel, even if the caller sounds convincing. Microsoft Authenticator can also support reporting suspicious prompts when the organisation has configured that feature. [2]
2. A phishing page relays the real sign-in
Some phishing pages do more than collect a password. They sit between the victim and the real service, relaying the sign-in process.
In an adversary-in-the-middle, or AiTM, attack:
- An email sends the employee to an attacker-controlled page.
- That page relays the employee's sign-in to the genuine service.
- The employee completes a phishable MFA challenge.
- The attacker captures the resulting session cookie.
The cookie represents an authenticated session. Where the service accepts its replay, the attacker can use it to access the account without completing a fresh MFA challenge. Microsoft has documented this technique being used to access mailboxes and support payment fraud. [3]
That is why “I completed MFA” does not prove the page was safe.
For staff: open an expected document through the service's known website or app where possible. Treat an unexpected sign-in request as a reason to stop and check.
3. The attacker steals an existing session
After signing in, you normally stay signed in for a while. Session cookies and tokens make that possible without asking for your password on every page.
Malware on a device can steal session material. Depending on the token and the service's protections, that material may allow an attacker to reuse access that has already been authenticated. [4]
This also explains why a password reset alone should not be treated as proof that an incident is contained. Revocation behaviour varies across token types and applications; some access can continue until a token expires or the application ends its own session. [5]
For businesses: protect the devices and browsers people use to access work accounts, and include session revocation in the incident response process.
What makes phishing-resistant MFA different?
Passkeys and FIDO2 security keys use cryptographic credentials tied to the legitimate service. A lookalike website cannot use the credential registered for the genuine website to complete its own sign-in. That binding is what makes these methods resistant to credential phishing. [6]
They address a weakness that codes and approval prompts leave open. They still depend on secure devices, sensible recovery procedures and appropriate account permissions.
For a small business, I would approach the rollout in this order:
- Check coverage. Confirm which accounts and services actually require MFA.
- Prioritise high-impact accounts. Start with administrators, then people who handle payments or sensitive information.
- Pilot phishing-resistant methods. Check device compatibility and recovery before expanding the rollout.
- Review fallback methods. A strong primary method provides less benefit if an attacker can choose a weaker alternative.
- Test access policies carefully. In Microsoft Entra, register suitable methods before enforcing a phishing-resistant authentication policy. Use report-only testing and plan emergency access to avoid locking administrators out. [7]
This is a suggested rollout sequence, rather than a complete configuration guide.
If someone has already approved a suspicious request
Report it immediately. Include the approximate time, the account involved and whether a link was opened, a password entered or software installed.
For the IT team, containment and investigation should include:
- Blocking the affected account where necessary and revoking sessions.
- Resetting compromised passwords from a trusted device.
- Reviewing sign-in activity, newly registered authentication methods and devices.
- Checking mailbox rules, forwarding and affected data.
- Investigating and remediating a suspected infected device before restoring access. [8]
Keep the reporting process straightforward. Staff need to know who to contact and that they should report uncertainty promptly.
MFA remains an important control. The useful next question is whether the business has chosen methods that resist phishing—and whether it can detect and contain access after a sign-in succeeds.
References
- CISA, Implementing Phishing-Resistant MFA.
- Microsoft Learn, Configure Microsoft Entra multifactor authentication: Report suspicious activity.
- Microsoft Security Blog, From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud.
- MITRE ATT&CK, Steal Web Session Cookie: T1539.
- Microsoft Learn, Understanding tokens in Microsoft Entra ID.
- FIDO Alliance, Passkeys: The Journey to Prevent Phishing, Part 1.
- Microsoft Learn, Require phishing-resistant multifactor authentication for administrators.
- Microsoft Learn, Token theft playbook.
Sources checked 24 October 2026.