Hackers Found a Way to Make MFA Work Against You

Accounting firms are getting hit by a Microsoft 365 trick where the login page is real, the MFA prompt is real, and the attacker still gets the keys.

Accounting firms spent the last few years doing the right things. They turned on MFA. They trained their staff. They told people not to click weird links. They tightened access controls. All smart moves.

But attackers found a gap. And the annoying part is that this one does not look like a normal phishing scam.

There is no fake Microsoft page. No weird login screen. No sketchy domain with extra letters in it. The employee goes to a real Microsoft page, enters a real code, approves real MFA, and the hacker still gets in.

That is the whole problem.

The attack is called device code phishing. It is starting to hit accounting and CPA firms because these firms are sitting on a bank vault made of PDFs: tax returns, payroll files, bank records, financial statements, client emails, Social Security numbers, and all the other stuff criminals love.

How the Attack Works

Microsoft built device code login for normal reasons. Some devices are painful to type on. Think conference room screens, smart TVs, and shared hardware. So instead of typing a password on the device, Microsoft gives the user a short code.

The user opens Microsoft on a phone or laptop, enters the code, approves the login, and the device gets access.

Good feature. Bad loophole.

Here is how attackers twist it. They start the login on their own device. Microsoft gives them a real device code. Then they email someone at the firm and dress it up as something boring and believable, like a tax document, client file, HR record, or shared engagement folder.

The employee follows the instructions. They land on Microsoft’s real login page. They enter the code. They approve MFA. And from their point of view, they did everything right.

They did not enter a password into a fake site. They did not ignore the MFA prompt. They did not miss the strange URL. There was no strange URL.

That is why this works.

The employee is not handing over a password. They are handing over a valid session token. That token can give the attacker access to Microsoft 365, including email, OneDrive, SharePoint, Teams, shared files, and sometimes any app connected to that Microsoft identity.

For a CPA firm, that can mean tax software, document systems, billing tools, and client portals.

Once the attacker is inside, the damage can get quiet fast. They can read old emails, search for client records, create forwarding rules, approve outside apps, and wait. A loud hack gets caught. A quiet one makes coffee in your kitchen.

LL

Ledger Lowdown

Get the most important accounting, tax, and finance news in a free daily email. Built for accountants, CPAs, and tax pros.

Subscribe free

Why the Old Training Misses This

Most firms trained people to spot fake pages, bad links, misspelled domains, urgent language, and weird attachments. That still matters. But it does not catch this attack because the page is real. The Microsoft domain is real. The MFA prompt is real.

So the training needs one new rule:

Do not enter a Microsoft code unless you started the login yourself.

That is it. Not because a client asked. Not because an email said “secure file.” Not because the page looks real. If the employee did not start the login, they should stop and report it.

What Firms Should Do Now

The first move is to block device code login. Most accounting firms do not need it. Microsoft Entra Conditional Access can stop device code authentication for users. Firms can test the policy in report-only mode first to see what breaks, but for most firms, nothing important should.

This feature was not built for tax teams moving K-1s around. It was built for devices that cannot handle normal login screens.

Next, audit connected apps. Attackers love persistence. They get in once and try to leave another door open. OAuth apps are one way they do it. Every third-party app connected to Microsoft 365 should be reviewed. If nobody knows what it is or why it has access, remove it.

Then check sign-in logs. Look for weird countries, odd devices, logins at strange hours, and partner accounts accessing files from places they have never been. A strange login is not a vibe. It is evidence.

Firms should also check forwarding rules. This is one of the oldest tricks in the book. An attacker gets into an inbox, creates a rule, and quietly forwards emails to an outside address. The user sees nothing. The firm feels normal. But sensitive client messages are leaking out the back door.

Partners should also review cyber insurance before anything happens. Some policies have specific wording around account takeover. Some have strict notification rules. Some care a lot about what controls were in place. That is boring until it becomes expensive.

What Clients Will Ask

Clients are getting sharper about security, especially financial services clients. If something goes wrong, they will want to know if their tax returns were exposed. They will ask about payroll data. They will ask whether documents were accessed or forwarded.

And somebody at the firm will be tempted to say, “We had MFA.”

That answer is not enough anymore.

MFA still matters. But MFA alone does not stop this attack. The better answer is simple: the firm blocked device code authentication, audited third-party access, reviewed sign-ins, checked forwarding rules, and trained staff not to enter codes they did not request.

That is the difference.

This attack works because it borrows trust. It uses Microsoft’s real login flow, Microsoft’s real MFA, and the employee’s real habits. That is why it slips through.

So treat it like a side door. Close it. Check if anyone used it. Then make sure nobody on the team opens it again.