Anatomy of an Account Takeover
A compromised email account was used to trigger unauthorized money-transfer activity and plant a password-proof backdoor almost nobody knows to check. I caught it quickly, ran a full incident response, and locked down the persistence path. Here's what I learned — and a free tool to score your own security.
Privacy boundary: this public report intentionally excludes exact amounts, recipient names, bank details, case numbers, account identifiers, and private evidence files.
The attack
It started where most breaches actually start: reused and leaked passwords. A password I'd used in more than one place had turned up in a data breach. That single leaked credential was the key.
Once the account was compromised, three things turned a login into a serious incident:
1. They hid the evidence
They planted a mail filter that automatically deleted every incoming message from my money-transfer provider. So while the fraud alerts were firing, they were silently trashed before I ever saw them.
2. They planted a password-proof backdoor
This is the part that matters most. They authorized a malicious OAuth application — a "connected app" — with permission to send mail as me and read my files. OAuth tokens and passkeys survive a password change. You can reset your password ten times and the backdoor still works, because it never used your password in the first place. This was their real foothold.
3. Unauthorized transfers were attempted
Multiple unauthorized transfers were sent to an unfamiliar recipient account. I'm intentionally omitting the amount, recipient, bank, and case details here for privacy and incident hygiene.
The recovery path had to be audited too. A recovery email can become the skeleton key to everything else, so it was treated as part of the same incident response instead of an afterthought.
The incident response
I discovered it the morning the transfers appeared. From there it was a race on two clocks: lock the attacker out, and report the transactions before funds moved further.
- Killed the active sessions — changed the password and force-signed-out every session, including the foreign ones I didn't recognize.
- Hunted the persistence — the step most people skip. Changing your password is not enough. I went into the account's connected apps / OAuth grants, found the malicious app, and revoked it. Then I checked passkeys and found a rogue one that could log in without a password — removed it. That explained the reset attempts that kept coming after I'd changed the password.
- Removed the evidence-hiding filter so alerts could reach me again.
- Secured the recovery email the same way — new password, two-factor on, deep-checked for filters, forwarding, and backdoors of its own.
- Reported the fraud fast — froze the card, filed the dispute, and reported the unauthorized activity through the right provider and fraud channels while the recovery window was still open.
- Hardened everything — strongest available account protection on my email, app-based two-factor everywhere, and a password manager with a unique password per account.
- Checked the devices — full malware scan and a forensic look at laptop and phone; both clean. This came through leaked credentials, not malware on my machine.
Timeline
| Months before | A reused password leaks in a third-party breach |
| Days before | Suspicious foreign logins begin; a security alert fires |
| The night before | Unauthorized transfer activity appears |
| The morning of | I discover the fraud — incident response begins |
| Within hours | Sessions killed · backdoor revoked · fraud reported · accounts hardened |
| Same day | The provider resolves the reported security issue |
The hard lessons
One leaked password unlocks every account that shares it. A password manager with a unique password per site isn't optional — it's the single highest-leverage thing you can do.
OAuth "connected apps" and passkeys log in without your password and survive a reset. After any compromise you must manually audit and revoke connected apps, passkeys, and sessions. Almost nobody checks this — it was the attacker's real foothold.
It blocks a plain password login — but a stolen session cookie or an OAuth grant walks right past it. Layers matter.
A filter that quietly deletes alerts buys them days. If something feels off, check your filters and forwarding rules — not just your inbox.
Unauthorized transfers are more likely to be resolved if you report within hours. Know how to freeze your card and file a dispute before you need to.
It can reset everything else. If it has an old password and no two-factor, your "secure" main account is only as strong as that forgotten inbox.
Outcome
The attacker was locked out. The backdoors are gone. The financial exposure was resolved through the provider's security process. A later login attempt after the cleanup was blocked by two-factor — proof the hardening held. It was the worst day I've had with technology, and I came out of it knowing exactly how these attacks work from the inside.
Scan your email domain posture
Enter an email address or domain you own. The scanner checks public DNS records for MX, SPF, DMARC, DKIM selectors, MTA-STS, and TLS reporting. If you enter an email, only the domain is queried.
Email/domain scanner
Only scan domains you own or have permission to assess. This uses public DNS-over-HTTPS lookups through Cloudflare/Google resolvers; it does not collect passwords, read inboxes, or test login systems.
Scanner findings
Observed DNS records
Next layer: Gmail deep scan
The public scanner stays no-auth. A future private mode can use explicit Google OAuth to review settings that public DNS cannot see.
Hard boundary
This tool is for defensive self-assessment. It will not ask for passwords, bypass login, read message bodies, scan third-party accounts without permission, or store private incident evidence.
When deeper account scanning exists, it should be opt-in, least-privilege, auditable, token-minimized, and easy to disconnect.
Incident readiness scan
A guided, cross-device audit for the things attackers actually abuse after a compromise: account persistence, hidden email rules, browser access, mobile permissions, financial recovery, and developer secrets. It runs locally in your browser and works on desktop or phone.
Deep scan report
This is defensive self-assessment, not a penetration test. It does not access your device, read messages, or store answers.
Score your own account security
Tick the protections you already have. You'll get a security score and the single most important gap to close first — built straight from what saved me. Nothing is saved or uploaded.
Your protections
100% local — your answers never leave your browser. A deterministic checklist, not a model grade.
Your gaps & what to fix first
I build AI systems — security-first now, not by accident.
I'm Architect L., the engineer behind the Agent Reliability Arena. I build and harden AI chatbots, RAG apps, and agents — and after running a real incident response, security is part of how I build, not an afterthought. Same discipline either way: assume things fail, hunt the hidden failure mode, verify the fix.