Compromised Accounts
In February 2024, a finance worker at Arup’s Hong Kong office received an email requesting a “secret transaction.” He was suspicious — it looked like phishing. But then he was invited to a video call. On the screen were the CFO and several colleagues, all looking and sounding exactly like themselves. His suspicions evaporated. Over the following days, he made 15 wire transfers totaling $25.6 million to five bank accounts controlled by scammers.
Every face on that call was a deepfake. Every voice was AI-generated. The fraud wasn’t discovered until he followed up with Arup’s headquarters in London.
It happened again in March 2025. A finance worker at a Singapore multinational joined a Zoom call where every participant — face and voice — was AI-generated. Loss: $499,000.
These cases are extreme, but they illustrate a principle that applies far more broadly: when a message comes from an account you trust, your defenses drop. And attackers know it.
Why compromised accounts are the hardest phishing to catch
Everything you learned in Module 1 about checking domains and verifying senders falls apart when the attacker IS the real account. A compromised account means:
- Messages come from the real email address — 100% genuine sender
- The attacker has full access to message history, contacts, and current projects
- They can reply within existing conversations with full context
- Every technical authentication check passes — SPF, DKIM, and DMARC all show valid
There’s nothing to flag. The domain is correct. The sender is correct. The conversation history is real. The only thing that changed is the person behind the keyboard.
And it’s happening at massive scale: 99% of customer tenants monitored by Proofpoint were targeted for account takeover in 2024. Of those, 62% experienced at least one successful compromise — with an average of 12 compromised accounts per organization.
How accounts get compromised in the first place
You might assume that account takeover means someone guessed or stole a password. That’s increasingly not the case. The most common techniques now bypass passwords and multi-factor authentication entirely.
Adversary-in-the-Middle (AiTM) attacks
Microsoft reported a 146% rise in AiTM attacks in 2024. Here’s how they work:
- The victim clicks a phishing link that takes them to what looks like a normal login page
- Behind the scenes, the attacker has set up a reverse proxy — a relay sitting between the victim and the real login page
- The victim enters their username, password, and completes MFA normally
- The proxy intercepts everything, including the session cookie that proves the login was successful
- The attacker uses that stolen session cookie to access the account — no credentials or MFA needed again
The victim sees a normal login experience. They may even land on the real website afterward. But the attacker now has a valid session.
The numbers are striking: 65% of compromised accounts in Proofpoint’s data had MFA enabled. Obsidian Security found the number was 84%. Cisco Talos reported that half of all their 2024 incident responses involved MFA bypass attacks. MFA is still worth using — it stops many attacks — but it is not the impenetrable shield many believe it to be.
Infostealer malware
The other major path to account takeover is malware specifically designed to steal login sessions. SpyCloud recaptured 17.3 billion stolen session cookies from the dark web in 2024 alone. These cookies come from devices infected by malware that quietly exports browser sessions, saved passwords, and authentication tokens.
A stolen session cookie gives the attacker instant access. No password needed. No MFA prompt. They simply paste the cookie into their own browser and they’re logged in as you.
How attackers stay in after compromise
Getting into an account is only the first step. Sophisticated attackers immediately set up persistence — mechanisms that keep them connected even if the victim changes their password.
Email forwarding rules
Attackers create mail rules with minimal names — a single period (.), a semicolon (;), or a single letter — that automatically forward copies of emails containing keywords like “invoice,” “payroll,” “bank,” or “payment” to an external address. These rules run silently in the background.
The critical problem: email forwarding rules survive password resets. The victim changes their password, thinks they’re safe, and continues using their account — while copies of every sensitive email are still being forwarded to the attacker.
The FBI issued a specific warning about this in 2020: attackers were setting auto-forwarding rules on the web client while victims only monitored their desktop client’s rules. The forwarding went completely unnoticed.
OAuth token abuse
Attackers create or consent to malicious OAuth applications connected to the compromised account. These applications receive refresh tokens that can mint fresh access tokens without re-authentication.
Here’s the critical detail: password resets alone do NOT invalidate existing OAuth refresh tokens. An attacker who has established a malicious OAuth connection can continue accessing the account through that application indefinitely, even after the victim changes their password and resets MFA.
Removing the attacker requires specifically revoking all active OAuth grants and reviewing connected applications — steps that most password-reset procedures don’t include.
The only reliable defense
Everything above points to one uncomfortable conclusion: you cannot fully trust any digital account, no matter how legitimate it looks. The sender might be real. The account might be compromised. The face on the video call might be a deepfake.
For any request involving money, passwords, or sensitive data from any account — even your boss’s, even your best friend’s, even your own mother’s — verify through a different channel.
- Call the person at a number you already have
- Walk to their desk
- Message them through a completely different app
If the request is real, the 30-second call costs nothing and nobody minds. If the account was compromised, you just stopped an attack that could have cost thousands or millions.
The verification channel must be different from the channel the request arrived on. If the suspicious message came via email, don’t reply by email. If it came via Teams, don’t verify on Teams. The attacker controls that channel. Go outside of it.
The Rule: Verify the person, not the account. Call them.