The invoice that changed bank details

Attack chain

1. The administrator receives a targeted email with an e-signature lure.
2. The link opens an adversary-in-the-middle (AiTM) phishing proxy that shows a convincing Microsoft 365 login page.
3. She enters her password and approves a push prompt. The proxy relays this to the real Microsoft service, so the login is genuine.
4. The attacker steals the session cookie, not just the password, and replays it. The stolen session is already MFA-authenticated.
5. The attacker registers a new authenticator, creates an inbox rule to hide supplier mail, and studies the order thread.
6. The attacker sends a lookalike-domain invoice with a new IBAN. The administrator pays.

Why MFA failed Push-based MFA proves that someone approved a prompt, not that the user is on the real site. It is phishable, and session-token theft bypasses it. The control that resists this is phishing-resistant authentication such as FIDO2 security keys or passkeys with origin binding, plus conditional access and token protection. DMARC did not help because the lookalike domain could have its own valid SPF and DKIM; DMARC protects the exact domain, not every similar domain. The missing call-back procedure was the last line of defence.

Highest impact, lowest effort

• Out-of-band verification of any bank-detail change, using a phone number already on file, not the contact details in the email. This breaks the payment step even if the mailbox is compromised. It is cheap and fast to introduce.

High impact, medium effort

• Phishing-resistant MFA for finance and other high-risk users. FIDO2 keys or passkeys stop AiTM credential and session theft. Roll out to finance first, then administrators.
• Conditional access and token protection to limit session replay, plus alerting on new MFA method registration and suspicious inbox rules. These detect persistence that password reset would miss.

Lower priority in this specific case

• DMARC enforcement is still good hygiene but would not have stopped a lookalike domain with valid authentication.
• General awareness training helps, but the lure was convincing and the user did approve a real prompt. Training alone would not fix the missing callback or phishable MFA.

Prioritise by risk reduction per euro and by whether the control breaks the chain at a specific step. The callback and FIDO2 address different steps; together they are stronger than either alone. Avoid buying another simulation tool before fixing the payment process.

First 48 hours

1. Contain: revoke all sessions and refresh tokens, reset the password, remove the attacker's registered authenticator, disable malicious inbox rules, and block the lookalike domain.
2. Preserve evidence: export mailbox audit logs, message traces, sign-in logs and a copy of the phishing email before cleanup.
3. Recover funds: notify the bank's fraud team immediately and request a recall; notify the insurer and engage incident response.
4. Scope: check other finance accounts, other inbox rules, forwarders and data exfiltration. The attacker may have read more than one thread.
5. Notify: tell the supplier, review other payments, and assess whether personal data was accessed. If so, follow GDPR and contractual notification duties.

Why password reset alone fails The attacker still holds a valid session token and a registered MFA method. A password reset may not revoke sessions or remove the new authenticator. The inbox rule also remains and can hide further fraud. Response must revoke sessions, remove persistence and verify mailbox configuration. Communication should state known facts, the containment actions and a single contact point, without speculating about blame.