I85PREP
⌘ K
Tech+ study materials
Tech+ study resources

MFA After the Invoice Rule

Tech+ · Put your knowledge to work in context.

All case studies

MFA After the Invoice Rule

A 60-person insurance brokerage runs a hybrid Microsoft 365 environment. The owner approved a multi-factor authentication project after a near-miss: a claims adjuster received a convincing message from a lookalike domain asking her to re-authenticate to view a shared claim. She entered her password before noticing the URL. The attacker then created an inbox rule that forwarded invoice threads to an outside address. IT has since reset her password. Licenses for MFA are already paid for all 60 users, but only 12 are enrolled. Two executives refuse to enroll, citing international travel. There is no Conditional Access policy, no alerting on new inbox rules, and no way for staff to report suspicious mail.

1. What was the attacker's objective, and which control would have broken the chain at each stage?

Read the worked answer

This is business email compromise, and the inbox rule is the tell - the objective was payment fraud, not data theft for its own sake.

The chain, stage by stage

  1. Delivery - a lookalike domain reached the inbox. Controls: DMARC enforcement on your own domain, external-sender banners, lookalike-domain monitoring, and mail filtering that flags first-contact external senders on financial threads.
  2. Credential capture - she typed her password into a clone page. Controls: MFA would have made the captured password nearly useless; a password manager keyed to the real domain would not have autofilled on the lookalike, which is itself a warning sign.
  3. Account access - the password alone was enough. Controls: Conditional Access blocking legacy authentication, geo/risk-based policies, and session controls would have interrupted a sign-in from a new location.
  4. Persistence - the inbox rule survived the password reset, because resetting a password does not revoke issued tokens or remove mailbox configuration. Controls: alerting on New-InboxRule, periodic review of mailbox rules, and revoking refresh tokens as part of any compromise response.
  5. Monetization - intercepted invoice threads get rewritten bank details or a fraudulent reply. Controls: out-of-band verification of bank-detail changes, and least privilege so a single mailbox cannot approve payments alone.

The key judgment: the password reset addressed stage 2 but left stage 4 running. Response is not complete until rules, delegates, OAuth consents, and active sessions are all checked.

2. How should the brokerage handle the two executives who refuse to enroll, given that the owner has approved the project?

Read the worked answer

Do not create a permanent blanket exemption. The attack succeeded against a claims adjuster; nothing about seniority reduces the risk, and executives are the highest-value impersonation target for wire fraud. An unenrolled executive mailbox is the path of least resistance for the next attacker.

What actually works:

  1. Remove the friction rather than the control. Most travel objections are about SMS or app prompts. Offer a hardware FIDO2 key on a lanyard, or the authenticator app with number matching and offline codes - both work without roaming data or a local SIM.
  2. Phase enforcement with Conditional Access. Roll out in groups (IT first, then the 12 already enrolled, then everyone) and set a hard deadline with a published date. Enforcement, not persuasion, is what changes behaviour.
  3. If an exception is genuinely required, make it narrow and documented: time-bound, compensating controls attached (compliant managed device, sign-in risk policy at its strictest, alerting on every sign-in, no legacy auth), and signed off by the owner as accepted risk. Exceptions expire and are reviewed.
  4. Protect the rollout itself with two break-glass accounts excluded from Conditional Access, using long unique credentials stored offline.

Framing for the meeting: the two executives should be told the exception means their mailbox can be used to defraud their own clients, and that the owner is accepting that liability in writing. That conversation usually ends the objection faster than a technical argument.

3. What would you check to determine whether the forwarding rule was the attacker's only foothold, and in what order?

Read the worked answer

Immediate containment (first, before investigation):

  1. Revoke the user's refresh tokens and all active sessions - a password reset alone leaves issued tokens valid.
  2. Disable the inbox rule and any forwarding (Set-Mailbox forwarding SMTP address, delegates, and send-as/send-on-behalf permissions).
  3. Re-enroll MFA with a fresh device before restoring access.

Then investigate, in this order:

  • Mailbox rules for all users, not just hers. Rules that forward externally, move to RSS/Archive/Conversation History, or delete on a keyword are classic persistence and are easy to hide.
  • Audit log for New-InboxRule, Set-Mailbox, Add-MailboxPermission, Set-ForwardingSMTPAddress, and the sign-in log for unfamiliar IPs, ASNs, countries, and any legacy-auth success.
  • OAuth application consents granted by the user - an illicit consent grant survives password changes and mailbox-rule removal.
  • Sent items and message traces on invoice threads, to establish whether any payment instruction was altered and to whom.
  • Delegate and shared-mailbox access changes made during the window.

Business follow-through: if any customer invoice thread was touched, that is a customer-facing and bank-facing event. Notify the affected clients, the payment processor, and the insurer directly by phone - not by email, which may still be under attacker observation.