Something feels off in your Google or Microsoft account. Maybe there's a sent email you don't remember writing, or a calendar invite that came from nowhere. The instinct is immediate and universal: change the password, do it again for good measure, and turn on two-factor authentication if it isn't on already.
For most account problems, that instinct is right. For one attack in particular, it may not cut off the attacker at all, because the attack was built so it never needed your password in the first place.
How Consent Phishing Works: The Login Screen Is Real, the App Is Not
The attack is called consent phishing. Microsoft's security documentation calls it an illicit consent grant. Instead of stealing a password, an attacker registers an application with Google or Microsoft (the technical term for this kind of sign-in permission is OAuth), the same way any legitimate software company would, and then sends you a link. Clicking it takes you to an authentic sign-in page, the real one, with the real domain in the address bar. There's no fake site to spot and no misspelled URL.
What's being requested is permission, not credentials. A screen appears with an app name, a short description, and the access it wants, such as reading your email, managing your files, or acting on your behalf, followed by a plain "Allow" or "Cancel." It looks exactly like the screens you've clicked through for legitimate reasons: connecting a bank feed, authorizing a receipt-capture app, linking a reporting tool to your accounting system. Nothing about the format separates a malicious request from a routine one. One more "Allow," and the app has what it asked for.
In the malicious version, what it asked for is standing access. Not a one-time look, but ongoing access to read and act on the account until someone revokes it.
Why a Password Reset May Not Touch This
Here's the part that trips people up. The access an app receives this way is a separate authorization held by the app itself, and in many cases it keeps working after the password changes. Microsoft's own guidance on illicit consent grants is blunt about it: normal remediation steps like resetting passwords or requiring multifactor authentication "aren't effective against this type of attack." Two-factor protects the sign-in step, and this attacker never needs to sign in again.
The details vary by provider, and it's worth being precise. Google, for example, does cut off an app's access to Gmail when you change your password, but that doesn't cover everything else the app may have been granted, like your files or calendar. So a reset might close one door and leave others open, and you won't be able to tell which from the settings screen where you changed it.
It helps to think of the app's access as a claim check rather than a key. A password is a key: change the lock and the old key stops working. An app authorization is a claim check handed out at the door, valid on its own no matter what happens to the lock afterward.
The distinction that matters: if an account was compromised through a malicious app, the password was never the problem. Changing it can feel decisive and still leave the app in place.
The Control That Actually Works: Revoking the App's Access
Once consent phishing has worked, the fix lives in one place: the settings that control third-party app access. Every major account provider keeps a list of the apps you've connected. In a Google Account, it's the linked apps page in your account settings, where you can see what each app can reach and select "Remove access." Microsoft accounts have an equivalent list of apps that can access your data, and for a Microsoft 365 business account, your administrator can remove an app for everyone in the organization. Your accounting system has one too, usually called connected apps or integrations.
That list is the actual point of control. Finding the entry you don't recognize and removing its access is what ends the app's ability to read or act on the account. Remove first and investigate second, not the other way around. Then change the password anyway, since it's still good hygiene and, in some cases, it closes part of the gap. While you're in the mailbox, check for forwarding rules or filters you didn't create, since that's a common way for someone with access to keep a quiet copy of your email.
Treat "Allow" Like Adding a New Vendor
The harder part isn't revoking access once you know to look. It's changing how the approvals happen in the first place. Treat "an app is requesting access to our email or books" as an approval event with the same weight as adding a new vendor's bank account. One specific person approves it, and the approval gets written down somewhere. Casual, unrecorded clicks are exactly how a business ends up with thirty connected apps nobody can account for five years later.
Why This Belongs in Your Books
This isn't only an IT question. A mailbox with silent, unauthorized read access is raw material for the kind of fraud that shows up directly in your general ledger. Someone reading your email can watch real vendor conversations happen, then time a fraudulent payment request to land right after a real one, using real names, real invoice numbers, and real context. That's the same mechanism behind a forged approval thread, only with far better material to work from.
The controls that catch payment fraud assume a clean starting point: real people approving real payments through channels a fraudster can't reach. A compromised mailbox quietly undermines that assumption well before any money moves, which is why it's worth catching early. It's also one more reason the person approving payments shouldn't be the only person who sees them, the core idea behind separating bookkeeping from bill-pay.
Make It a Routine, Not a One-Time Check
The good news is that this doesn't require new software or a security vendor. It takes a recurring reminder and about five minutes per account. Open the connected-apps list for your email, your accounting system, and anything else that touches money, and ask of each entry: did we choose to connect this, and do we still use it? Anything unrecognized gets removed. That one habit is the most reliable way to catch consent phishing that slipped through.
Month-end close is a natural anchor, since it's already a moment when someone is looking closely at your books. Adding "review connected apps" to that checklist costs almost nothing once it's a habit, and it means the review happens on schedule instead of only after something already feels wrong. Our free Bookkeeping Health Score is a quick way to see where the rest of your controls stand.
If your business sends ACH payments through its bank, this also fits neatly into the fraud-monitoring processes banks now expect from businesses that originate ACH. A connected-apps review is a small, concrete item to add: who checks it, how often, and what happens when something unfamiliar turns up. Writing that down isn't required by the rule, but it's the easiest way to show your bank you're doing it.
The Bottom Line
A password reset addresses the wrong layer of a consent phishing attack, because the access the attacker holds may never have depended on the password. Removing the app's access in your account settings is the control that actually works, and reviewing that list on a regular schedule catches the problem before it turns into an invoice fraud incident in your books.
If you think a payment has already gone out because of a compromised account, call your bank first, since speed matters for any chance of recovery, then report it to the FBI at ic3.gov.
At Salt & Sand Bookkeeping, reviewing who and what has access to your financial systems is part of how we think about clean books. Not just recording what happened, but building the controls that keep the wrong things from happening in the first place.
See how we approach clean, reviewed books: Our Bookkeeping Services
Questions about your books? Reach us at info@saltandsandbookkeeping.com or (619) 304-SALT (7258).
Not sure what's connected to your email and books? Let's take a look together.
Schedule a Free Consultation