Phishing the Finance Director in 11 Minutes

Eleven minutes. One email. Complete access.

At 09:14 on a Tuesday morning, we sent a single email to the Finance Director of a FTSE 250 company. At 09:17, she opened it. At 09:18, she clicked the link. At 09:19, she entered her username and password into what she believed was a legitimate Microsoft 365 login page. At 09:19, her multi-factor authentication prompt appeared on her mobile phone, and she approved it. At 09:20, we had her authenticated session token. At 09:25, we were inside her mailbox, her OneDrive, her SharePoint, and her Teams — reading board papers, financial forecasts, and M&A correspondence that would not be public knowledge for another six weeks.

Eleven minutes from send to compromise. One email. One click. One MFA approval. And the multi-factor authentication that the organisation had deployed — the control they believed made phishing a solved problem — did not prevent a single step of it.

This is not a story about a careless user. The Finance Director was experienced, cautious, and had completed the organisation's annual security awareness training three months prior. This is a story about the gap between how organisations believe MFA works and how it actually works when confronted with modern adversary tradecraft.

The Engagement Brief

The client had engaged us to conduct a targeted phishing assessment against a defined set of senior executives. This was not a broad-based awareness exercise — it was a focused simulation of an advanced threat actor targeting high-value individuals within the organisation. The scope included the Chief Executive, the Chief Financial Officer (referred to here as the Finance Director), the Chief Operating Officer, and two Non-Executive Directors.

The rules of engagement permitted us to use any publicly available information to craft our pretexts. We were authorised to establish infrastructure, register domains, and deploy credential harvesting frameworks. We were authorised to use captured credentials and tokens to access the target's cloud environment and demonstrate impact. We were explicitly required to stop short of data exfiltration — we could evidence access to sensitive information but were not to download or copy it beyond what was necessary for proof of compromise.

The client's security team was aware that an assessment was taking place but did not know the timing, the targets, or the methods. This arrangement ensured that the engagement would test the organisation's detection and response capabilities in addition to its preventive controls.

Reconnaissance — Building the Pretext

A spear-phish succeeds or fails on the quality of its pretext. The pretext must be contextually relevant to the target, timely, and carry sufficient urgency or authority to prompt action without triggering suspicion. Crafting a convincing pretext requires reconnaissance — not technical scanning, but intelligence gathering about the target, their role, their professional context, and their current operational priorities.

We spent three days on reconnaissance before writing a single word of the phishing email. Our sources were entirely open — publicly available and requiring no special access or tools.

By the end of the reconnaissance phase, we had identified a pretext that was timely, authoritative, and directly relevant to the Finance Director's current responsibilities: a communication from the incoming external audit firm regarding the onboarding process for the upcoming audit cycle. The pretext leveraged information that was accurate but not widely publicised, creating a message that would appear both legitimate and expected.

Infrastructure — The Invisible Stage

Modern phishing infrastructure must be indistinguishable from the legitimate service it impersonates. This requires careful attention to domains, certificates, mail configuration, and the credential harvesting framework itself.

We registered a domain that closely resembled the incoming audit firm's legitimate domain — a homoglyph variation that would pass casual visual inspection. The domain was registered through a reputable registrar, aged for seventy-two hours to avoid newly-registered domain filters, and configured with full DNS records including SPF, DKIM, and DMARC to ensure our outbound email would pass authentication checks.

For the credential harvesting and token capture component, we deployed Evilginx — an adversary-in-the-middle (AitM) framework that acts as a transparent reverse proxy between the target and the legitimate Microsoft 365 login page. This distinction is critical: Evilginx does not present a fake login page. It proxies the real login page. The target interacts with genuine Microsoft infrastructure — they see the real login form, the real MFA prompt, and the real post-authentication landing page. The difference is that every request and response passes through our proxy, allowing us to capture the authenticated session token after the target completes the full authentication flow, including MFA.

The Email — Eleven Words That Mattered

The phishing email was deliberately understated. Research consistently demonstrates that the most effective spear-phishing messages are short, professional, and contextually appropriate. They do not shout. They do not use exclamation marks or urgent red text. They read like a legitimate business email because they are designed to be one.

The email appeared to originate from a named partner at the incoming audit firm — a real person whose name and title we had identified through the firm's public website. It referenced the audit transition, noted that the onboarding documentation pack had been prepared, and included a link to a 'secure document portal' where the Finance Director could review and acknowledge the engagement letter.

The link pointed to our Evilginx instance, served over HTTPS with a valid TLS certificate, on the homoglyph domain. The landing page was the real Microsoft 365 login — proxied transparently through our infrastructure.

The subject line was eleven words long. It referenced the company name and the phrase 'Audit Transition — Engagement Letter for Review'. It was mundane. It was expected. And it worked.

The Click — 09:17 to 09:20

The Finance Director opened the email at 09:17 — three minutes after delivery. She clicked the link at 09:18. Our Evilginx proxy served the real Microsoft 365 login page. She entered her email address. Microsoft's authentication flow confirmed the account existed and presented the password field. She entered her password.

At this point, Microsoft's conditional access policy triggered the MFA requirement. The Finance Director's authenticator app received a push notification on her mobile phone. She approved it. This is the moment that most organisations believe their security controls have succeeded — the user has completed multi-factor authentication, proving both knowledge (password) and possession (mobile device).

What happened next is the reason this article exists.

Microsoft's authentication server, having received valid credentials and a valid MFA approval, issued a session token — a set of cookies that represent the completed authentication event. This token was returned to the client — but the 'client' in this flow was our Evilginx proxy, not the Finance Director's browser directly. Evilginx captured the session token in transit, stored it, and simultaneously forwarded it to the Finance Director's browser, completing her login to what appeared to be a normal Microsoft 365 session.

From the Finance Director's perspective, nothing unusual had occurred. She had clicked a link, logged into Microsoft 365 as she did every day, approved her MFA prompt, and arrived at her familiar dashboard. She had no indication that her session token had been intercepted.

Token Replay — Becoming the Finance Director

With the captured session token, we no longer needed the Finance Director's password or her MFA device. The token is the authenticated session. It represents a completed authentication event — credentials verified, MFA satisfied, conditional access evaluated. Any system that receives this token will treat the bearer as the authenticated user.

We imported the captured session cookies into a browser on our assessment infrastructure. Before doing so, we needed to evaluate the organisation's conditional access policies to determine whether token replay would succeed or whether additional controls were in place.

Evaluating the Defences

Microsoft Entra ID (formerly Azure AD) conditional access policies can impose restrictions on authentication sessions based on various signals — device compliance, IP location, client application type, sign-in risk, and token binding. If properly configured, these policies can detect or prevent token replay attacks. We assessed each potential control.

The organisation had deployed MFA — and only MFA. None of the complementary conditional access controls that would detect or prevent token replay were in place. The captured token was valid from any IP address, on any device, in any location, for the default session lifetime of up to ninety days.

We imported the session cookies into our browser. Microsoft 365 accepted the token without challenge. We were logged in as the Finance Director.

Impact — What Eleven Minutes Buys You

Once authenticated as the Finance Director, we conducted a controlled assessment of the data and systems accessible from her account. We did not exfiltrate data — our scope required us to evidence access and document the sensitivity of accessible information without removing it from the environment.

The findings were substantial.

Persistence and Stealth

To demonstrate the persistence risk, we documented — without executing — the techniques an attacker would use to maintain long-term access to the compromised account. These included the creation of OAuth application consents that would grant persistent API access to the mailbox independently of the user's session token, the registration of an attacker-controlled device as an MFA method on the account, the creation of mail forwarding rules that silently copy incoming messages to an external address, and the creation of an application password that bypasses MFA entirely for legacy protocol access.

We documented these techniques in our report as demonstrated-but-not-executed findings, providing the client with a clear understanding of the post-compromise risk without introducing persistent backdoors into their environment.

We also assessed what the organisation would have seen from a detection perspective. The answer was: very little. The legitimate sign-in by the Finance Director was logged. Our token replay session — because it used a valid token with the correct user agent — appeared as a continuation of the same session. There was no failed authentication event. There was no MFA challenge to flag. There was no anomalous sign-in alert because Entra ID Protection's sign-in risk policies were not enabled.

The compromise was invisible to every detection mechanism the organisation had in place.

Why MFA Alone Is Not Enough

This engagement demonstrates a fundamental truth that the security industry has been slow to communicate clearly: multi-factor authentication prevents credential theft. It does not prevent session theft.

MFA ensures that an attacker who obtains a password alone cannot authenticate. This is valuable. It eliminates an entire class of attack — brute force, credential stuffing, password reuse, and basic phishing that captures only usernames and passwords. These attacks are common, and MFA stops them effectively.

But AitM phishing does not steal credentials in isolation. It proxies the entire authentication flow — credentials, MFA, and conditional access evaluation — and captures the output: a valid session token. The token is the product of successful authentication. It is proof that every security check has been passed. And once captured, it can be replayed from any device, at any location, for the duration of its validity.

The defences against AitM phishing exist. They are available today, within the same platforms most organisations already use. But they require deliberate configuration beyond simply enabling MFA.

The most effective defence is FIDO2 / Passkeys. FIDO2 authentication is bound to the origin domain — the browser verifies that the domain requesting authentication matches the domain the passkey was registered to. An Evilginx proxy on a homoglyph domain cannot satisfy this verification. The authentication simply fails. It is, at the time of writing, the only MFA method that is fundamentally resistant to AitM phishing at the protocol level.

From Inbox to Inside — Eleven Minutes

The MFA Complacency Problem

There is a dangerous narrative circulating in corporate security: 'We have MFA, so phishing is not a significant risk.' This narrative is repeated in board papers, in audit committee reports, and in risk registers across every sector. It is based on an understanding of phishing that is five years out of date.

The phishing attacks that MFA was designed to prevent — static credential harvesting on fake login pages — still exist and still account for the majority of phishing volume. MFA is effective against these attacks. But the threat landscape has evolved. AitM phishing frameworks are freely available as open-source tools. The infrastructure to deploy them costs less than a hundred pounds per month. The techniques are documented in blog posts, conference talks, and YouTube tutorials. This is no longer a nation-state capability. It is a commodity technique available to any motivated attacker.

The consequence of MFA complacency is that organisations stop investing in the complementary controls that make MFA effective against modern threats. They do not deploy FIDO2. They do not enable conditional access evaluation. They do not enforce device compliance. They do not reduce session lifetimes. They do not enable sign-in risk policies. They tick the 'MFA enabled' box on their compliance checklist and move on.

The Finance Director's MFA worked exactly as designed. She proved her identity with two factors. The system issued a token confirming her authentication. And we captured that token because nothing in the authentication chain verified that the relying party was legitimate or that the token could only be used by the device that requested it.

MFA is necessary. It is not sufficient. The gap between those two statements is where breaches happen.

Technique Mapping

Recommendations and Hardening

FIDO2 security keys are the single most effective control. They should be deployed immediately to all executive and high-privilege accounts, with a phased rollout to all staff to follow. FIDO2 eliminates the AitM phishing vector at the cryptographic level — the authentication is bound to the legitimate domain and cannot be proxied.

Continuous Access Evaluation and device compliance requirements address the token replay vector. Even if a token is captured, these controls ensure that it cannot be used from an unmanaged device or from a location that does not match the original authentication context.

Administrative role separation is essential. The Finance Director's account should never hold Exchange Administrator or SharePoint Administrator roles for daily use. These roles should be assigned to dedicated administrative accounts accessed through Privileged Identity Management with just-in-time activation, separate MFA, and a compliant device requirement.

The organisation's email filtering must be upgraded to detect the indicators of AitM phishing — including homoglyph domains, newly-registered domains, and URL patterns associated with known proxy frameworks. Modern email security platforms can evaluate link destinations at time of click, not just at time of delivery, providing an additional layer of detection.

This was not a user failure.

It is tempting — and common — to frame phishing compromises as user failures. The narrative is familiar: if only the user had been more careful, if only they had checked the URL, if only they had completed their training.

We reject this framing. The Finance Director received an email that was contextually relevant to a real business activity she was engaged in. It came from a domain that was visually near-identical to the legitimate sender's domain. It passed SPF, DKIM, and DMARC validation. The link led to a real Microsoft 365 login page with a valid TLS certificate. She authenticated using the process she follows every day. Her MFA prompt appeared as expected and she approved it. At no point did anything in the experience deviate from what a legitimate email and login flow would look like.

The failure was not human. The failure was systemic. The organisation had deployed a single preventive control — MFA — and had not implemented the complementary controls necessary to address the known limitations of that control. The email filter did not detect the threat. The conditional access policy did not prevent token replay. The session management did not limit the blast radius.

When a user cannot distinguish a legitimate interaction from a malicious one — because the malicious interaction is, by design, indistinguishable — the responsibility for defence lies with the technical controls, not with the individual.

MFA is the beginning, not the end.

We have had the same conversation with hundreds of organisations. It begins with confidence — 'We have MFA enabled across the board' — and it ends with the quiet realisation that MFA, as deployed, does not address the attack we have just demonstrated.

The path forward is not to abandon MFA. It is to recognise that MFA is one layer in a defence-in-depth architecture that must include phishing-resistant authentication methods, token binding, device compliance, session management, and real-time anomaly detection. Each of these controls exists today. Each is available within the platforms most organisations already pay for. The gap is not in technology. It is in configuration.

Eleven minutes. One email. One click. Complete access to board-level information that could move markets. The only thing standing between that outcome and a defended organisation was a set of conditional access policies that nobody had enabled.

Until next time — stay sharp, stay curious, and ask yourself: if your MFA was bypassed today, what else would stop the attacker?