I was asked to look at the email accounts of a small business after a run of financial fraud — accounts opened in the owner’s name, charges nobody recognized, the usual miserable identity-theft picture. The fraud was the loud part, and the loud part is rarely the interesting part. Underneath it was a mailbox backdoor built with real care to be invisible: designed so that if the owner ever went and looked at their own security settings, everything would appear perfectly normal.
Two artifacts made the case, and both were verified as not the owner’s the most direct way there is — I asked the people who use the account, and they’re non-technical enough that they don’t know what an app password is and looked at me like I’d grown a second head when I described the filters. That’s not an inference. That’s the account holders telling me, plainly, that they didn’t create these things and wouldn’t know how.
Identifying details are changed or withheld; the technical content is exactly as I found it.
Artifact one: an app password, which is a backdoor with a bow on it
An app password is a 16-character credential that Google (and others) let you generate for a legacy application that can’t do a modern login. Here’s why it’s the perfect persistence mechanism, and why finding one you didn’t create should make the back of your neck prickle:
- A human has to create it, deliberately. It cannot be minted by an app, an OAuth flow, or an API. The only way one comes into existence is a person signed into the account, on the app-passwords page, with 2-step verification already enabled, clicking generate and copying the string.
- It bypasses 2-step verification entirely. That’s the whole point of it. A client using an app password never sees an MFA prompt. So every bit of protection the owner thinks they get from 2FA — the app password walks straight around.
- It grants full IMAP/SMTP access to the entire mailbox. Read everything, send as them, forever, from anywhere.
- It doesn’t show up where anyone looks. It’s not in the list of signed-in devices you’d glance at. You have to go to a specific settings page you’ve probably never opened to even know it exists.
This account had one. It had been created a month and a half before I got there and was still in active use when I found it — I could see the fingerprint of a mail client that had connected to the mailbox over IMAP. Somebody who was not the owner had a full, 2FA-proof key to the mailbox, and had been quietly using it for six weeks. I revoked it during the session.
Artifact two: four filters that make the alarms disappear
The second artifact is the one that turns “someone has access” into “someone is running an operation.” Four mail filters, each keyed to a single keyword — the names of the specific payment and ticketing platforms that were being abused in the fraud — and each with the same action: mark as read, and delete.
The construction matters. Each filter matched on “has the words” with the sender, recipient, and subject fields left empty. That means the filter doesn’t just catch mail from the platform — it matches the keyword anywhere in the message, including the body. Any email that so much as mentions that payment platform gets silently marked read and thrown in the trash before a human ever sees it.
They worked. A genuine payment-failure alert from one of those platforms landed during the window I was investigating and went straight to trash, unread. That’s the entire design goal: the fraudulent charges generate alerts, and the alerts evaporate. The owner’s account settings look untouched — no forwarding, no obvious tampering — while every warning the platform tries to send gets intercepted at the mail layer and deleted. The victim’s own security page looks clean because the attack isn’t in the settings the victim knows to check. It’s in a filter they’ve never opened the filters page to see.
The detail that should genuinely worry you: persistence that beats a password reset
Here’s the part I want every incident responder and every “I think I got phished” reader to take away.
A sibling account in the same case had a different app password — one created years earlier. At some point the owner did exactly what everyone is told to do after a scare: they changed the password and turned on 2-step verification. A textbook lockdown. And that old app password survived both. Changing the account password did not revoke it. Turning on 2FA did not revoke it. Whoever held that app password kept full IMAP access to the mailbox for another month after the “lockdown” that felt complete.
This is the failure mode nobody warns you about. A password reset alone does not close an app-password backdoor, and neither does enabling 2FA. They feel like the whole job. They aren’t. If you are cleaning up a compromised mailbox, the mandatory steps are:
- Revoke every app password. This is the one people miss, and it’s the one that keeps the attacker in.
- Sign out of all sessions — a password change doesn’t necessarily kill live sessions.
- Audit filters and forwarding rules for exactly the suppression pattern above: a keyword auto-delete rule naming a payment platform, with no sender or subject constraint.
- Break recovery-address loops — in this case two accounts were each other’s recovery address, so compromising either one hands you the other, and back again.
Rotate the password and stop there, and you’ve locked the front door while leaving a key you don’t know about under the mat.
Tradecraft, and the discipline of not overclaiming
One more operational note worth having, because it’s a recurring tell: the fraud showed classic card-testing before monetization — a tiny, sub-$5 charge to an obscure foreign merchant months before the large losses. That’s someone validating a payment instrument works before spending real money against it. If you ever see a trivial charge to a merchant you’ve never heard of, it is not too small to care about; it’s the rehearsal.
And a note on honesty, because it’s the part of this work I care most about getting right. Two things in this case are verified: the backdoor exists (the app password and the filters are real, and the account holders confirmed they didn’t create them). Two things remain genuinely open, and I’m not going to dress them up as more than they are: I did not establish how the intruder first got in — the most likely candidate is a compromised endpoint I never got to forensically examine, which fits the profile of an infostealer — and I did not prove that the person who planted the mailbox backdoor is the same person behind the card fraud. Those are real open questions. They do not change the finding, which is that a mailbox had a deliberate, 2FA-proof backdoor and a notification-suppression system built into it. Keeping the verified thing and the open thing in separate boxes is the difference between an investigation and a story.
Go look at your own mail right now
This is the rare security post with a homework assignment you can do in two minutes. Open your email provider’s settings and look at two pages you’ve probably never visited: your app passwords (revoke any you don’t recognize, and any you’re not actively using) and your filters (look for anything that deletes or archives mail matching a keyword, especially a bank or payment-platform name). A backdoor that only quietly deletes mail is precisely the kind you’ll never notice on your own — because its entire job is to make sure nothing ever shows up to make you look.