AegisAI Perspectives · 010
Email account takeover is an attacker signing in to a real mailbox as its owner. The five-step chain, and the log or alert that records each step.
Email account takeover is an attacker signing in to a real mailbox with a stolen password or session token and acting as its owner. The FBI says one incident can include 50 or more transactions19.
The FBI names the goal: steal funds, redirect paychecks or otherwise affect the victim's money17. MITRE ATT&CK tracks the access as Valid Accounts: Cloud Accounts (T1078.004), used for initial access and persistence13. Mail sent from a taken-over account comes from the owner's real domain, so sender authentication (SPF, DKIM, DMARC) passes.
The chain has five stages: credential or token theft, first sign-in, persistence, reconnaissance, then a payment change request sent from the real mailbox.
The attacker needs a password or a live session, then makes that access last. Valid cloud accounts give adversaries both initial access and persistence, according to MITRE ATT&CK.
MITRE ATT&CK says cloud accounts are targeted through brute force, phishing or other means. The FBI lists weak passwords without multi-factor authentication as one way criminals get in18. An adversary in the middle (AiTM) page relays the real sign-in and keeps the session cookie the server issues after MFA completes.
MITRE ATT&CK says stolen session cookies often stay valid for an extended period, even when the web application is not in use16. For a session theft that starts after MFA clears, read how Mirage2FA steals Microsoft 365 sessions. For a device code route that never asks for the password, read how the Kali365 kit defeated MFA without breaking it.
The attacker signs in with the password or replays the token from their own infrastructure. Microsoft Entra ID Protection raises an anomalous token detection when a session or refresh token shows an unusual lifetime or is played from an unfamiliar location6.
Its password spray detection fires only after the attacker validates a password. It signals that the password was identified, not that resources were accessed7. Microsoft's impossible travel alert needs a learning period of seven days for a new user5, so a new account gives it no baseline in week one.
Next the attacker makes the access outlast a password reset. Microsoft describes the rules exploit in four moves: steal credentials, sign in, create a forwarding inbox rule, then send a trigger email the rule acts on4.
MITRE ATT&CK records forwarding rules as Email Collection (T1114.003) and points detection at New-InboxRule14. A second rule hides mail, which MITRE tracks as Email Hiding Rules (T1564.008)15. Microsoft lists rules that move messages to the Notes, Junk Email or RSS Subscriptions folders as a symptom of a compromised mailbox1.
Microsoft says app passwords are not revoked automatically when the password changes3. A new MFA method registered by the attacker gives a second way back in.
With rules in place, the attacker reads invoice and payroll threads to learn who pays whom and when each payment falls due. The forwarding rule copies new mail to an outside address, so the attacker collects mail without signing in again.
The attacker writes from the owner's account, often inside a live thread, and asks for a new bank account or a redirected paycheck. The hiding rule moves the replies, so the real owner never sees the recipient's questions. IC3 recorded 24,768 business email compromise complaints in 202521. That count covers all BEC, and account takeover is one route into it.
Open Microsoft Entra ID Protection and review the user's risk detections, such as anomalous token or password spray.
List every inbox rule on the mailbox. Entra ID Protection flags rules that delete or move messages or folders as possible hidden mail8.
Check forwarding. The Suspicious email forwarding activity alert fires on autoforwarding to a suspicious external account9.
Do not rely on the Creation of forwarding/redirect rule alert alone: it is Informational and sees only rules made in Outlook on the web or Exchange Online PowerShell.
In Google Workspace, confirm the user's filters and forwarding options are set as expected12.
Revoke active sessions, then reset the password. Microsoft says revoking sessions immediately invalidates access that uses the stolen credentials2.
Remove app passwords and review OAuth grants, because a password reset leaves app passwords in place. In Google Workspace, suspending the user resets sign-in cookies and OAuth tokens.
Remove MFA methods the user does not recognise and enrol security keys. Google recommends security keys over 2SV codes, and NIST SP 800-63B-4 says manually entered OTP codes are not phishing resistant22.
Turn on Token Protection in Conditional Access. It accepts only device bound session tokens, so a stolen token fails from another device, with enforcement on Exchange Online for supported native apps25.
Steps 6 and 7 go together. A reset without session revocation leaves a replayed token working, and a reset without app password removal leaves a second door open.
| Stage | What the attacker does | What a defender can see (log or alert) |
|---|---|---|
| Credential or token theft | Phishes the password or relays the sign-in to keep the session cookie | Password spray detection once a password is validated; nothing in mail logs |
| First sign-in | Signs in or replays the token from new infrastructure | Anomalous token detection; impossible travel alert after its learning period |
| Persistence | Creates forwarding and hiding inbox rules, keeps app passwords | Suspicious inbox manipulation rules detection; Creation of forwarding/redirect rule alert (Informational) |
| Reconnaissance | Reads invoice and payroll threads while a rule copies mail out | Suspicious email forwarding activity alert; Google Workspace filters and forwarding settings |
| Payment change | Asks for a new bank account from the real mailbox | Authentication passes; the request shows only in the finance workflow |
The last stage is the hardest to see in logs, because the message comes from the owner's own account. The evidence sits earlier: the anomalous token detection at stage 2 and the inbox manipulation rules detection at stage 3.
Illustrative example, figures are fictional. Day 1: the payroll manager at Fernbrook Dental enters her Microsoft 365 password on a fake sign-in page that relays to the real one, and the page keeps her session cookie. Day 1, 40 minutes later: the attacker replays the cookie from a hosting provider abroad. Day 2: a new inbox rule moves any message containing "bank" or "deposit" to the RSS Subscriptions folder. Day 6: the attacker reads three supplier invoice threads. Day 9: from her real mailbox, the attacker asks the bookkeeping firm to send a $27,400 payment to a new account. The bookkeeper calls the number on file, and the request is refused.
In that fictional case the anomalous token detection had its chance on day 1. The suspicious inbox manipulation rules detection had its chance on day 2. The call to a known number stopped the payment on day 9.
Email account takeover is an attacker using a stolen password or session token to sign in to a real mailbox as its owner. The attacker adds inbox rules to forward or hide mail, reads threads, then asks for a payment change from the real account. MITRE ATT&CK tracks the access as T1078.004.
Not every form. A relayed sign-in keeps the session cookie after MFA completes, and MITRE says stolen cookies often stay valid for an extended period. NIST SP 800-63B-4 says manually entered OTP codes are not phishing resistant. MITRE recommends FIDO keys that incorporate the login domain.
Phishing is one way in, alongside brute force. Takeover is the use of that access to sign in, add rules, then send mail as the owner. For a worked case, read how credential phishing led to a Microsoft 365 mailbox breach.
It forwards mail to an outside address, or moves and deletes messages so the owner misses them. Microsoft lists rules that move mail to Notes, Junk Email or RSS Subscriptions as a symptom. MITRE tracks these as T1114.003 and T1564.008.
No. Revoke active sessions too, which Microsoft says invalidates access using the stolen credentials. Remove app passwords, which a reset leaves in place. In Google Workspace, suspending the user resets sign-in cookies and OAuth tokens.
Revoke sessions and reset the password. Then remove inbox rules and forwarding, plus any MFA method the user does not recognise. In Google Workspace, suspend the user and check filters and forwarding. To cut triage time on the phishing email that started it, read how to reduce SOC time on phishing triage.
