account takeoverATOinternal threatsemail security

Account Takeover: Detecting the Threat That's Already Inside Your Network

D
Datacove Team
Security Research
June 29, 2026
7 min read
Account Takeover: Detecting the Threat That's Already Inside Your Network

Most email security is built around a simple assumption: the threat is external, arriving from outside the organization. Account Takeover (ATO) breaks that assumption entirely. Once an attacker has valid credentials for a real employee account — obtained through a prior phishing attack, credential stuffing, or a leaked password reused across services — every email they send comes from a genuinely legitimate, authenticated identity. There's no spoofed domain, no failed authentication check, and often no external gateway that even sees the traffic, because the attacker is now operating from inside the organization's own infrastructure.

This piece looks at why ATO is structurally invisible to most perimeter-focused defenses, what detecting it actually requires, and how a compromised account typically gets used once an attacker has it.


Quick Summary

  • The core problem: ATO traffic originates from a genuine, authenticated account — there's no spoofing, no failed authentication, nothing for perimeter defenses to flag.
  • Why gateways miss it: most Secure Email Gateways only inspect traffic entering from outside the organization; internal-to-internal email never crosses that chokepoint.
  • What detection requires: continuous behavioral monitoring of account activity — login patterns, sending behavior, and email content — not just perimeter filtering.
  • The typical attack sequence: initial compromise, quiet reconnaissance, then a rapid pivot to fraud or lateral phishing before the account is recovered.

Why Account Takeover Is a Different Category of Threat

Nearly every other phishing category relies on some form of deception about identity — a spoofed domain, a lookalike sender, a manipulated display name. ATO requires none of that. The attacker isn't impersonating a trusted account; they are, for all practical purposes, that account. Every technical signal a defender might normally check — SPF, DKIM, DMARC, sender reputation — passes cleanly, because the email genuinely originates from where it claims to.

This is why ATO is frequently the most damaging outcome of an otherwise "ordinary" phishing attack. The initial credential-harvesting email might get caught by half the defenses on this list; if it doesn't, the compromised account it produces can bypass nearly all of them on the way back out.

The Perimeter Blind Spot

Traditional Secure Email Gateways are deployed to inspect traffic crossing an organization's perimeter — typically enforced by routing all inbound mail through the gateway via MX records. That architecture has an inherent blind spot: email sent from one internal account to another internal account never crosses that perimeter, because it never leaves the organization's own mail infrastructure in the first place.

Once an attacker controls a legitimate internal account, this blind spot becomes the primary vector for lateral movement. An email from a compromised account to a colleague, a finance team, or an executive assistant is internal traffic by definition — invisible to any security control that only inspects what enters from outside.

What a Compromised Account Actually Does

The period immediately after a successful account compromise typically follows a recognizable pattern, even though the specific details vary by attacker:

  • Quiet reconnaissance: the attacker reviews the mailbox — searching for financial processes, ongoing vendor relationships, and organizational relationships they can exploit — often without sending anything, to avoid alerting the legitimate account owner.
  • Mailbox rule manipulation: a common technique is creating an inbox rule that silently forwards or hides specific incoming replies, so the legitimate account owner never sees the responses to a fraudulent email the attacker sends in their name.
  • Lateral phishing: using the trusted account to email colleagues internally, often with a pretext designed to compromise a second account and expand the attacker's foothold.
  • Fraud execution: the endpoint of many ATO campaigns — a wire transfer redirect, a fraudulent invoice, or a request to change payment details — sent from an account the recipient has no reason to distrust.

Detecting Activity, Not Just Filtering Traffic

Because ATO doesn't produce anything a perimeter filter would flag, detection has to shift from inspecting traffic at a chokepoint to continuously monitoring account behavior itself. This includes login pattern analysis (a login from an unfamiliar location or device, especially in rapid succession with a legitimate login, is a classic indicator of credential compromise), mailbox rule monitoring (since the silent-forwarding-rule technique above is common enough to be a reliable signal on its own), and the same behavioral, baseline-driven content analysis used to detect BEC — evaluating whether outgoing messages are consistent with how this specific account normally communicates.

This is also where API-based integration with Microsoft 365 or Google Workspace matters directly: it's the mechanism that gives a detection platform visibility into account-level signals — login events, mailbox rule changes, internal send patterns — that a gateway sitting outside the mail platform simply cannot see.

Reducing the Window Between Compromise and Detection

The financial and reputational damage from ATO scales directly with how long a compromised account goes undetected. A fraud attempt caught within minutes of the account's first suspicious activity is a contained incident; the same account left unmonitored for days can be used to compromise multiple colleagues, exfiltrate sensitive data, and execute several fraud attempts before anyone notices.

This is the practical argument for continuous, automated monitoring over periodic manual review: the detection window needs to be measured in the same timescale attackers actually operate on, which is hours, not the days or weeks a manual audit cycle typically covers.


FAQ

Why don't SPF, DKIM, and DMARC catch Account Takeover?

Because a compromised account is genuinely authorized to send mail from its own domain — the email passes every authentication check because it's technically legitimate, even though the person actually sending it is not who the recipient believes.

How does an attacker typically compromise an account in the first place?

Common vectors include a prior successful phishing attack that harvested credentials, credential stuffing using passwords leaked from unrelated breaches, or exploiting a password reused across multiple services.

What is a mailbox forwarding rule attack?

A technique where an attacker creates a hidden inbox rule that automatically forwards or hides specific incoming emails — often used to intercept replies to a fraudulent message sent from the compromised account, without alerting its legitimate owner.

Why do Secure Email Gateways miss internal phishing from a compromised account?

Because gateways typically only inspect traffic crossing the organization's perimeter, based on MX record routing. Email sent between two internal accounts never crosses that chokepoint and goes entirely unmonitored by a gateway-only architecture.

What's the fastest way to detect a compromised account?

Continuous, automated monitoring of login patterns, mailbox rule changes, and outgoing message behavior — compared against an established baseline for that specific account — rather than periodic manual review.

Can ATO be prevented entirely, or only detected quickly?

Multi-factor authentication significantly reduces the initial compromise rate, but no control eliminates it entirely. The practical goal is minimizing the detection-to-response window once a compromise does occur, since damage scales with how long it goes unnoticed.


Key Takeaways

  • Account Takeover produces genuinely authenticated traffic — there's nothing for perimeter or authentication-based defenses to flag.
  • Gateway-only architectures miss internal (east-west) traffic entirely, which is exactly where compromised accounts operate.
  • Detection requires continuous account-behavior monitoring — login patterns, mailbox rules, and outgoing message analysis — not just traffic filtering.
  • Compromised accounts typically follow a recognizable pattern: quiet reconnaissance, rule manipulation, lateral phishing, then fraud execution.
  • Damage scales with detection time, making automated, continuous monitoring far more effective than periodic manual review.
Share this article