That ‘Allow Access’ Popup Can Hand Over Your Whole Inbox

Nobody stole a password. They just asked nicely.

Picture your office manager on a Tuesday morning. An email lands that looks like a shared document from a vendor you actually use. She clicks it. A real Microsoft sign-in page loads, correct URL and everything, and she signs in like she does forty times a week. Then a gray box appears asking her to let an app called ‘Secure Doc Viewer’ read her mail, read her files, and stay signed in on her behalf. She hits Accept, because that box shows up constantly and clicking it is how work gets done.

Done. The attacker now has a live connection into her mailbox and your SharePoint. They never learned her password. MFA never fired, because there was nothing for it to catch. And here’s the part that ruins people’s week: resetting her password does not kick them out. She didn’t hand over a key. She signed a permission slip, and that slip stays valid until somebody goes in and revokes it.

This is called consent phishing, or an illicit consent grant if you want the formal name. It’s been climbing for a couple of years now, mostly because the defenses we all spent the last five years pushing (MFA especially) sidestep it entirely.

Why this one gets past careful people

Most phishing training teaches your team to check the URL. Good advice. Completely useless here. The login page is genuinely Microsoft’s. The consent screen is genuinely Microsoft’s. The only fake part is the app name and the little logo next to it, and attackers pick names that sound like IT already installed them: Office365 Sync, Adobe Reader Cloud, Mail Backup Pro, PDF Secure Viewer.

A few other things stacked against you:

• Permission fatigue is real. Your team clicks Accept on app permissions on their phones every week. It’s muscle memory by now.
• The wording sounds harmless. ‘Maintain access to data you have given it access to’ does not read like ‘let a stranger in Belarus download your invoices,’ but that’s what it can mean.
• By default, regular users can approve apps themselves. In a lot of Microsoft 365 tenants nobody ever changed that setting, so any employee can grant a stranger’s app access to their own mailbox without an admin ever hearing about it.

What they actually do once they’re in

Not much, at first. That’s the point. A smart attacker sits quiet and reads. They search the mailbox for words like invoice, wire, deposit, ACH, and routing. They learn who your bookkeeper is, who your biggest client is, and how you word your emails.

Then, weeks later, a real payment thread gets hijacked. Your client gets a friendly note about updated banking details, sent from an account that has been in that conversation the whole time. Nobody catches it until the money is gone and the bank shrugs.

Other favorites: bulk downloading everything in OneDrive and SharePoint, blasting phishing emails to your entire contact list from your own domain (which torches your sending reputation), and quietly reselling the access to someone with bigger plans.

Check right now whether this already happened to you

Takes about ten minutes. Microsoft 365 first:

• Sign in to the Microsoft Entra admin center as a global admin, go to Enterprise applications, and set the filter to show all applications.
• Sort by creation date and look at anything you don’t recognize. Click into it, then Permissions, and see what it was granted. Mail.Read, Mail.ReadWrite, Files.Read.All and offline_access are the ones that should make your stomach drop.
• Anything you can’t explain, hit Delete on the app and revoke its permissions.
• Individual users can check themselves at myapplications.microsoft.com under App permissions.

Google Workspace users: myaccount.google.com, Security, then ‘Your connections to third-party apps and services.’ Same drill. If it has Gmail access and you don’t recognize it, cut it off.

How to shut the door for good

These are settings changes, not products you have to buy. An hour of work at most.

• Stop letting users consent to whatever they want. In Entra, under Enterprise applications, Consent and permissions, set user consent to ‘Allow user consent for apps from verified publishers, for selected permissions.’ That kills the sketchy no-name apps while letting the legitimate stuff through.
• Turn on the admin consent workflow. When somebody does need an app, they submit a request, you get an email, and you decide. Beats finding out six weeks later.
• Set an alert. Microsoft Purview has an alert policy for consent grants to applications. Point it at an inbox somebody actually reads.
• Review the app list quarterly. Put it on the calendar next to your backup restore test. Apps pile up, employees leave, permissions linger.

The version to tell your team on Monday

Skip the jargon. Say this: ‘If a website ever asks you to give an app permission to your email or our files, stop and send it to me first. Doesn’t matter how normal it looks. We approve apps, not you, and nobody’s going to be annoyed that you asked.’

That last part matters more than the rest. The reason these attacks work is that people are embarrassed to ask. Make asking free.

If you think it already happened

Move fast and in this order. Revoke the app’s permissions and delete the enterprise app. Revoke the user’s active sessions (a password reset alone doesn’t do this). Reset the password and re-register MFA. Then check that mailbox for inbox rules and forwarding, because attackers almost always leave one behind. Pull a message trace to see what got sent while they had access. If any of it touched banking details, call the bank and call your clients directly by phone.

We’re based here in South Florida and we run this exact review for businesses from Delray Beach up through West Palm Beach. If you’ve never looked at the app permissions in your Microsoft 365 tenant, there’s a decent chance something in there will surprise you. Reach out and we’ll take a look with you. Always happy to troubleshoot.