Multi-Factor Authentication Did Not Stop This Attack From Reading Payroll Emails for Weeks

Arctic Wolf Labs has tracked one phishing campaign into hundreds of compromised organizations across the United States, Canada, and Europe this quarter. The victims are not careless. Most had multi-factor authentication turned on, the setting every security checklist tells a small business to enable first. It did not stop this attack, because the attack was never designed to guess a password. It was designed to sit in the middle of a real login and copy everything that passed through, including the one-time code.

The campaign, documented by Arctic Wolf Labs and reported on August 10, 2026, does not go after your bank account directly. It goes after the mailbox of whoever in your company runs payroll, approves invoices, or handles wire transfers, then reads that mailbox quietly for as long as it can get away with it. That is a different, slower kind of theft than most owners picture when they hear "phishing," and it is exactly why a lot of businesses running Microsoft 365 would not notice it happening.

How a code you typed yourself still gets stolen

The trick is called adversary-in-the-middle, or AitM. Instead of building a fake Microsoft login page and hoping you type your password into it, the attacker's page acts as a real-time proxy: it sits between you and the genuine Microsoft sign-in system, passing your username, password, and MFA code straight through. From your side, the login looks completely normal, because it is, right up until the proxy copies the session token that Microsoft hands back once you are authenticated. That token is what actually keeps you signed in. Whoever holds it does not need your password again.

The delivery is built to survive the filters most small businesses rely on. Arctic Wolf found the campaign starting with an ordinary voicemail notification email, then routing the click through Google Meet links, Google Ads redirects, and Amazon S3-hosted pages before it reaches the actual decoy. Each of those services is trusted by spam filters on its own, so the chain borrows their reputation instead of triggering it. Along the way, JavaScript on the decoy page quietly fingerprints the visitor's browser, operating system, screen size, timezone, and graphics hardware, information the attacker uses later to make follow-up sign-ins look like they are coming from the same device.

Why payroll and finance staff specifically

Once inside a mailbox, the attackers do not act like the smash-and-grab operators most training videos describe. Arctic Wolf's analysis shows them using the Microsoft Graph API, the same interface Microsoft's own apps use, to methodically enumerate which employees hold payroll, HR, finance, or administrative roles. From there they search and read messages about payments, invoices, and banking details rather than blasting spam from the compromised account. It is closer to corporate espionage than to typical email fraud, and it fits a pattern security teams call business email compromise: the payoff is not the mailbox itself, it is the financial workflow that runs through it.

That patience shows up again in how the sign-ins are managed. Malicious logins recur roughly every eight hours from a rotating set of IP addresses, but each rotation reuses the same session identifier, a detail that only makes sense if the access is centrally automated rather than one attacker manually logging back in. The eight-hour cadence also lines up with how long a typical Microsoft 365 session token stays valid before it needs to be refreshed.

Why the usual warning signs do not fire

Security tools are largely built to catch the mistakes attackers used to make: a new MFA method registered on the account, a suspicious inbox rule forwarding mail to an outside address, a login from a country the company has never done business with. Arctic Wolf notes this campaign deliberately avoids all three. No MFA changes, no inbox rules, and residential proxy services that make each malicious sign-in look like it is coming from an ordinary home internet connection in a plausible location, not a data center abroad. The result is a compromise that can sit undetected for weeks, which is long enough to learn a company's real invoice amounts, vendor names, and approval habits before ever attempting to redirect a payment.

This is also the part where "we already have MFA" stops being a reassuring answer. Standard MFA, a text message code, an authenticator app push, or a six-digit number, confirms that the person logging in has your phone at that moment. It says nothing about whether the page they typed the code into was Microsoft's or a proxy sitting in front of it. Against a real-time relay, the code does its job and gets stolen in the same second.

What actually stops an AitM attack

The fix is not more MFA, it is a different kind of MFA. Phishing-resistant methods such as Windows Hello for Business, FIDO2 security keys, or certificate-based authentication cryptographically bind the login to the real Microsoft domain. A proxy page cannot relay that exchange, because the browser itself refuses to complete it against the wrong site. For a 10 to 50 person company, rolling this out for the handful of people who touch payroll, invoicing, and banking, rather than the whole staff at once, closes most of the actual financial risk within a week.

Underneath that, Conditional Access policies that require a known, compliant device for anyone in a finance or HR role stop a stolen session token from being usable on the attacker's laptop even if the credential exchange succeeds. Session sign-in and risk alerts, tuned to flag the pattern this campaign relies on (repeated logins from new locations with an unchanged session ID) catch what MFA alone cannot. None of this is exotic. It is the same cloud security groundwork that stops most credential-based attacks, applied specifically to the people whose mailboxes are worth the most to steal.

If someone in finance already clicked a suspicious link

Do not wait for a wire transfer to go missing before treating this as urgent. Check the sign-in log for that account for logins from unfamiliar locations in the last 30 days, revoke all active sessions and refresh tokens so any stolen session token stops working immediately, and reset the password even though the attacker likely already has it, since a fresh credential invalidates anything cached for later reuse. Then look specifically for search activity inside the mailbox around invoices, banking details, or vendor payment information, not just for new inbox rules, since this campaign is built to skip the rule-based tells that most checklists still test for first.

A short checklist for the people who touch money

You do not need to overhaul every account in the company to close most of this risk. Start with the small list of people who can approve a payment, change bank details on file, or run payroll, and work through these five items for that group specifically:

First, move them off SMS and app-push MFA and onto a phishing-resistant method: a FIDO2 security key costs under thirty euros and takes a few minutes to register. Second, require a compliant, company-managed device for anyone signing into finance systems, so a stolen session token has nowhere to land even if a credential exchange briefly succeeds. Third, turn on sign-in risk alerts and actually route them to a person who checks them the same day, not a folder nobody opens. Fourth, agree a verbal or out-of-band confirmation step for any change to bank details or an unusually timed payment request, regardless of how legitimate the email looks, since a compromised mailbox produces emails that pass every visual check. Fifth, put a date on when you last reviewed who is even in that "can approve payments" group, because access that outlived the person's role is exactly what this kind of patient, months-long reconnaissance is built to find.

None of these five steps requires replacing Microsoft 365 or buying a separate security product. They are configuration changes inside the tenant you already pay for, which is also why they are so often skipped: nothing forces a business to do them, and the default settings were built for ease of sign-up, not for a targeted campaign reading a finance inbox for weeks at a time.

Quick answers

Does this mean MFA is not worth using?

No. MFA still stops the overwhelming majority of automated password-guessing and credential-stuffing attacks. It just is not enough on its own for the small number of accounts that handle money, which need the phishing-resistant methods described above.

How would we know if this had already happened to us?

Look for sign-ins to finance or HR accounts from IP addresses or countries the company has no reason to be in, recurring at a fixed interval, without any matching change to MFA methods or inbox rules. That absence of the usual red flags is itself the signal.

Is this specific to Microsoft 365, or does it affect Google Workspace too?

The technique works against any cloud email provider's standard login flow. This particular campaign is documented targeting Microsoft 365 tenants, which is also where most of the small businesses we work with keep their payroll and invoicing correspondence.