In September 2023, a member of the Scattered Spider threat group called MGM Resorts' IT helpdesk, spent approximately ten minutes on the phone impersonating an employee they'd identified on LinkedIn, and walked away with a privileged Okta account reset.

No malware. No exploit. No technical sophistication required. The helpdesk agent followed the standard identity verification process — asked security questions, heard convincing answers drawn from publicly available LinkedIn data, and reset the MFA for a high-value account. The attacker had Okta access to MGM's single sign-on environment before the call ended.

What followed was a ten-day operational catastrophe. Slot machines went offline. Hotel room keys stopped working. Reservation systems, the MGM app, and online booking all went dark. Staff processed check-ins manually. The total financial impact exceeded $100 million in Q3 2023 losses — $84 million in lost revenue and $10 million in one-time technology and legal costs. Personal data belonging to approximately 37 million customers was exposed. MGM settled a class-action lawsuit in 2025 for $45 million. Five members of Scattered Spider faced federal criminal charges. Arrests continued into April 2026.

The entry point was a phone call to the helpdesk. Not an email. Not a zero-day. A phone call, ten minutes long, exploiting a verification process that trusted a voice and a set of answers scraped from a social media profile.

MGM is the extreme end of the scale. But the mechanic — social engineering a reset pathway to gain account access, then operating from inside the legitimate account — is the same mechanic running against mid-market organizations every day at lower cost, lower visibility, and lower recovery probability.

Less than 8% of ATO-BEC incidents are discovered through technical controls. Most are uncovered through payment reconciliation or third-party notification — after the money has already moved. — Palo Alto Networks Unit 42

A Compromised Account Is Not a Phishing Email — It's a Platform

Account takeover BEC is structurally different from every other email attack category because the attacker does not need to impersonate anyone. They are the legitimate account.

Classic phishing attacks — even sophisticated spear-phishing or whaling campaigns — operate from the outside. The attacker sends from a domain they control, spoofed or lookalike, and hopes the recipient doesn't scrutinize too closely. In ATO-BEC, there is no external domain. No lookalike. No spoofed sender. The attacker sends from the real inbox, through the real mail server, authenticated to the real account. SPF passes. DKIM passes. DMARC passes. Every reputation signal in every gateway returns clean, because nothing about the sending infrastructure is compromised — only the account.

This is why ATO-BEC is categorically harder to detect than impersonation-based BEC, and why its trajectory in StrongestLayer's 2026 incident data is tagged at 3.4 and rising. The detection mechanisms most organizations have deployed were designed to evaluate whether a message came from a trustworthy source. In ATO-BEC, the source is genuinely trustworthy. The problem is that the person controlling it isn't.

The compromised account isn't just an access point. It's a platform — for research, for communication, for social engineering that carries the full credibility of a real established identity. Mimecast's 2026 threat intelligence noted that attackers increasingly fabricate full email chains between vendors and executives from within compromised accounts, creating documented conversation histories that never actually occurred, as supporting context for fraudulent requests. The inbox isn't the target. It's the weapon.

5 days median dwell time before first fraudulent action — attackers study your workflows before they move — Unit 42

The Kill Chain Has Six Stages — Detection Is Possible at Two of Them

ATO-BEC follows a consistent six-stage operational pattern. Technical detection is realistically available at stage one and stage three. After stage four, the fraud is already in progress.

1.  Initial Compromise

The attacker gains access to the inbox. Entry vectors include AiTM phishing capturing a live session token after MFA completes, credential stuffing using email-password combinations from prior breach dumps, spear-phishing that harvests credentials directly, helpdesk social engineering of the kind Scattered Spider used at MGM, or OAuth abuse granting persistent access without requiring a password. This is the first viable detection window — anomalous sign-in patterns, new device registration, sign-in from an unfamiliar geography. Most organizations catch this only if identity threat detection is actively deployed and configured to alert on these specific signals.

2.  Reconnaissance

The attacker reads. For five days on average. Inbox contents, sent items, calendar, contacts. They build an operational map — payment workflows, vendor relationships, approval chains, communication styles. No outbound email is sent. No file is downloaded. From a technical monitoring perspective, a human sitting in a compromised inbox reading email is nearly indistinguishable from the legitimate account owner doing the same thing.

3.  Infrastructure Setup

Forwarding rules. This is the second viable detection window — and according to LevelBlue SpiderLabs, it is the primary reconnaissance mechanism in ATO-BEC. The attacker creates inbox rules that silently forward copies of incoming mail to an external address, delete replies to fraudulent messages, or automatically mark specific emails as read. Alerting on inbox rule creation in near-real time is one of the highest-signal ATO detection controls available and remains underdeployed across most organizations.

4.  Execution

The fraudulent request goes out. Invoice change. Payroll diversion. Wire transfer instruction. Sent from the real account, to a real recipient who recognizes the real sender. Written in the account owner's documented communication style, referencing real organizational context gathered during reconnaissance, arriving at a moment in the workflow when such a request is plausible. The recipient has no technical signal to evaluate.

5.  Evasion

Replies questioning the request are deleted or suppressed by the inbox rules created in stage three. If the legitimate account owner opens the account during the fraud window, suspicious sent items may be deleted. The attacker manages the account actively — not just using it, but maintaining the illusion of normal operation.

6.  Exfiltration

The payment moves. The payroll diverts. The wire clears. Recovery probability drops sharply after 48 hours and approaches zero after 72. Discovery typically comes through the legitimate account owner noticing missing funds, a vendor calling about an unpaid invoice, or a bank flagging an unusual outbound transfer.

Forwarding Rules Are the Most Consistently Overlooked Signal in Email Security

An inbox rule that forwards mail to an external address or deletes specific incoming replies is not normal user behavior. It is the primary operational infrastructure of ATO-BEC.

LevelBlue SpiderLabs was direct about this in their 2025 BEC analysis: forwarding rules are the primary reconnaissance mechanism in account-takeover BEC. Microsoft's 2025 threat reporting explicitly ties ATO-BEC incidents to inbox-rule manipulation. And yet, in a significant proportion of investigated incidents, the forwarding rules had been present for days before any fraudulent request was made — undetected because nobody was watching for them.

Inbox rules operate in a part of the email environment that most security tooling doesn't monitor with the same rigor as inbound message content. Gateways evaluate what comes in. Rules govern what happens after. The creation of a new inbox rule — particularly one routing to an external domain the account owner has no prior correspondence with — is a high-signal indicator of compromise that requires no sophisticated detection model to identify. It requires an alert.

The operational implication: alert on inbox rule creation in near-real time, review existing rules monthly, and specifically flag any rule routing to an external domain not in the account owner's correspondence history. This single process control, per multiple incident response teams' published assessments, prevents a majority of successful ATO-BEC wire fraud by surfacing the compromise at stage three — before any fraudulent message has been sent.

Forwarding rules to external domains are the primary ATO-BEC reconnaissance mechanism. Alert on creation. Review existing rules monthly. This single control surfaces most compromises before the fraudulent request is sent.

 Payroll Diversion Is the Highest-Volume ATO-BEC Variant

Payroll diversion targets HR and payroll teams with fraudulent direct deposit change requests, exploiting a workflow that is routine, processed at predictable intervals, and handled by small teams with limited cross-referencing capability.

The attack pattern is consistent. The attacker, operating from a compromised employee or executive account, sends an email to HR or payroll requesting a change to direct deposit banking details. The pretext is plausible — a new bank account, a banking partner change, a system migration. The request arrives 5-10 days before the next pay cycle, providing the urgency of a time-sensitive administrative task without the alarm-triggering urgency of an immediate wire request.

The American Hospital Association documented this pattern in January 2024, issuing an alert about a validated IT helpdesk social engineering scheme targeting revenue cycle employees specifically. The mechanic was direct: attackers impersonated hospital employees to convince helpdesk staff to reset credentials and register new MFA devices. Once inside the account, they changed payment processor instructions and redirected funds to fraudulent accounts. The same pattern the Scattered Spider group used to enter MGM at the helpdesk level — applied to healthcare payment workflows at the account level.

The fraud is rarely discovered until the legitimate employee notices their pay didn't arrive. At that point, funds have cleared. Recovery depends entirely on whether the bank can initiate a SWIFT recall or ACH reversal before the receiving account is emptied — a window that closes quickly in environments where real-time payments are standard.

LevelBlue SpiderLabs observed attackers calling the payroll department before sending the fraudulent email — announcing the supposed change verbally first, then following up in writing, building credibility across two channels before the actual change request arrives. The phone call corroborates the email. The email follows up the phone call. Both are the attacker.

The defense is process-level: all direct deposit changes must be submitted through a self-service portal with MFA authentication, never via email request to HR. An email-based change request workflow is a structural vulnerability regardless of what security tools surround it, because the attack doesn't need to bypass any technical control — it just needs the HR team to process a request that arrived through the official channel.

The Attack Pivots Off Email Before Your Controls Can Act

A significant share of ATO-BEC incidents in 2026 pivot from the compromised email account to SMS, WhatsApp, or voice channels before the fraudulent request is made — specifically to move the conversation outside corporate email security's monitoring perimeter.

The 2026 BEC Phishing Report from the Cyber Strategy Institute documented this shift directly. An attacker using a compromised executive account initiates contact via email — establishing legitimacy — then continues the conversation through a messaging app or phone call. The email provides the cover. The off-channel conversation is where the fraudulent instruction is delivered.

This defeats the entire detection model of email-centric security. By the time a finance team member is on WhatsApp discussing an urgent wire with who they believe is their CFO, the compromised email account has served its purpose. No email containing the fraudulent instruction was ever sent. The gateway has nothing to evaluate.

Cross-channel fraud flows are one of the documented blind spots in most email security vendor reporting. Security teams see only email. They miss SMS, WhatsApp, and voice pivots that now drive a meaningful share of ATO-BEC outcomes. This is why the AI-powered phishing detection guide makes the point that defending against ATO-BEC requires more than evaluating what arrives in the inbox. It requires monitoring what happens to the account after the initial compromise — the rules created, the sessions opened, the behavioral deviations from the account owner's established pattern.

Standard Email Security Has No Detection Model for This Attack

Account takeover BEC generates no technical indicators that gateway-based detection was designed to catch.

No malicious link. No malicious attachment. No spoofed domain. No known threat signature. The email that initiates a successful ATO-BEC attack is, from every technical evaluation dimension, indistinguishable from a legitimate email sent by the legitimate account owner. It was sent from the legitimate account, authenticated by the legitimate mail server. The content is contextually appropriate because it was written with five days of research into the organization.

Rule-based detection has nothing to match against. Reputation systems have no signal to act on. Content scanning finds no payload. The sender verification layer that most email security tools treat as their primary defense mechanism returns a clean result — because the sender is genuine.

The only detection model that applies evaluates behavior rather than attributes. It asks whether the account is behaving the way this account has historically behaved — whether the message pattern, the recipients, the timing, the content type, and the organizational context of the request are consistent with established norms. Deviation from established behavioral patterns is the signal.

This is the detection layer TRACE provides. Not a content scan, but a continuous behavioral model of every account in the organization evaluated against every outbound message in real time. The same architecture that flags a vendor email compromise attempt by detecting a request that doesn't fit the established vendor relationship also flags an ATO-BEC attempt by detecting a message that doesn't fit the account owner's established communication pattern. The inbox rule creation alert. The anomalous recipient. The request type that's never come from this account before. How TRACE powers real-time email threat prevention covers the full architecture — the core is the same: detection that reasons about behavior, because attributes in ATO-BEC are clean by design.

< 8% of ATO-BEC incidents discovered by technical controls — over 92% found through reconciliation or third-party notification, after the loss — Unit 42

The Regulatory Landscape Is Catching Up

ATO-BEC is beginning to surface in regulatory frameworks as a named risk category — and the compliance gap for organizations without behavioral monitoring is widening.

Singapore's Shared Responsibility Framework, effective December 16, 2024, established formal liability for phishing scams that explicitly shifts responsibility to financial institutions when they fail to meet defined anti-scam duties. For financial institutions, this includes mandatory 12-hour cooling-off periods for high-risk activities — adding new payees, increasing transfer limits — and 24/7 real-time notification alerts for all transactions. The framework is Singapore-specific but represents the leading edge of a regulatory shift being watched closely across the Asia-Pacific region and beyond.

PCI DSS v4.0's mandatory anti-phishing controls under Requirement 5.4.1, effective April 2025, apply to any organization handling payment card data. Nacha's ACH rule changes, with Phase 1 obligations live since March 2026, introduce risk-based monitoring requirements for fraudulently initiated payment entries — the exact outcome a successful payroll diversion or wire fraud produces. The SEC's cybersecurity disclosure rule requires material incident disclosure within four business days of determining materiality. A fraudulent wire initiated from a compromised account can reach that threshold.

A fraudulent wire transfer initiated from a compromised account is, depending on industry and jurisdiction, simultaneously a notifiable incident, a reportable loss, and a compliance deficiency. Organizations building behavioral monitoring now are closing a technical gap and a regulatory gap in the same motion.

Mid-Market Organizations Are Primary Targets

ATO-BEC targeting is not skewed toward large enterprises. It skews toward organizations with real financial transaction volume and thin identity monitoring.

A 400-person professional services firm processes real wires, real payroll, and real vendor payments. Its executives have real inboxes with real authority. Its HR team processes real direct deposit change requests. Its helpdesk resets credentials for real employees. The attack surface is structurally identical to a 10,000-person enterprise — what's different is the monitoring layer. As documented in why mid-market organizations are caught in the security gap, most mid-market companies run Microsoft 365 with default configurations, have no dedicated identity threat detection, and don't alert on inbox rule creation. The 5-day dwell time exists in part because there's nothing watching.

63% of executives surveyed in 2026 reported experiencing compliance issues as a result of account takeover attacks. Takeover attempts rose 24% in a single year. The tools running these campaigns are automated, cheap, and not selective about company size. The helpdesk social engineering that worked against MGM's 75,000-employee organization works just as well against a 200-person firm — and the 200-person firm has no Okta administrator watching for anomalous privileged account resets.

Defense: Five Controls That Close the Actual Gap

Defending against ATO-BEC requires controls at the identity layer, the mailbox configuration layer, the workflow layer, the behavioral detection layer, and the response layer. No single layer is sufficient.

Identity Layer: Phishing-Resistant MFA on All High-Value Accounts

Software-based MFA is defeated by AiTM session hijacking and by helpdesk social engineering of the kind Scattered Spider used at MGM. FIDO2 security keys and passkeys are cryptographically bound to the legitimate domain and cannot be replayed through a proxy or reset by a social engineer who doesn't physically possess the key. Executives, finance staff, HR, and IT administrators should be migrated as a near-term operational priority. For accounts not yet migrated, conditional access policies requiring managed device compliance and flagging impossible-travel sign-ins provide meaningful friction without closing the gap entirely.

Helpdesk identity verification protocols deserve equal attention. The MGM breach was not a failure of MFA technology — the attacker social-engineered the reset process to bypass it. Requiring in-person or video-verified identity confirmation before any privileged account MFA reset closes this specific vector.

Mailbox Configuration Layer: Alert on Inbox Rule Creation

Create an automated alert that fires whenever a new inbox rule is created on any account — immediately, not in a daily digest. A secondary alert should fire whenever a rule routes to an external domain not in the account owner's existing correspondence. These two alerts cover the stage-three detection window in the ATO-BEC kill chain, which is the last practical intervention point before the fraudulent request is sent. Review all existing inbox rules quarterly and flag any routing to external domains for human review.

Workflow Layer: Remove Email as a Sufficient Channel for Financial Changes

Direct deposit changes submitted by email to HR. Vendor banking changes submitted by email to AP. Wire instructions submitted by email to finance. These are the three workflow vulnerabilities ATO-BEC consistently exploits. Removing email as a sufficient channel for any of these — requiring a self-service portal with MFA for direct deposit, callback verification for vendor banking changes, and dual approval for wires above defined thresholds — eliminates the execution pathway regardless of what detection controls exist around the inbox.

Behavioral Layer: Deploy Account-Level Monitoring That Detects Dwell

The 5-day dwell period is detectable if behavioral baselines are established and monitored at the account level. An account that begins receiving and reading emails in patterns inconsistent with the account owner's historical behavior — different hours, different devices, different reading patterns — is potentially compromised. An account that creates a new inbox rule on a Wednesday when the account owner has never created an inbox rule in three years is almost certainly compromised. The detection model that catches this is behavioral, not signature-based, and requires per-account baseline modeling rather than organizational-level thresholds.

Response Layer: Build a Specific ATO-BEC Incident Runbook

The standard identity incident response — reset the password — is insufficient. A complete response requires: password reset, active session revocation, review and removal of inbox rules created during the compromise window, audit of MFA methods registered to the account during the compromise window, review of all outbound emails sent from the account during the dwell period, and notification to any recipients of suspicious messages who may have already acted on a fraudulent request. Each step needs to be in the written runbook before the incident, because the window for meaningful remediation is measured in hours.

How to Tell If You've Already Been Compromised

Most ATO-BEC victims don't know they've been hit until a payment fails to arrive or a vendor calls. These five checks, run today, tell you whether an active compromise is underway.

The 5-day dwell time cuts both ways. It means the attacker has time to study your organization — but it also means you have time to find them before the fraudulent request goes out, if you know where to look.

Run these five checks immediately across all high-value accounts — executives, finance, HR, IT administrators, and any account with payment authorization.

• Pull all inbox rules created in the last 90 days that route to external domains. Any rule forwarding mail outside the organization that the account owner didn't knowingly create is a potential active compromise. Don't wait for an incident to discover this.
• Review sign-in logs for accounts that authenticated from new devices, new IP address ranges, or geographies inconsistent with the account owner's normal location in the last 30 days. An executive based in Chicago who shows a successful sign-in from Amsterdam at 3am is either traveling or compromised.
• Check sent items on high-value accounts for messages the account owner doesn't recognize. Ask them directly. This is uncomfortable but takes five minutes. An attacker operating from inside a real inbox for five days generates sent mail.
• Look for MFA method registrations that occurred outside normal business hours or from devices not recognized by the account owner. Scattered Spider's standard playbook includes registering an attacker-controlled MFA device after initial access — to maintain persistent access even if the original credentials are reset.
• Review any recently created vendor banking changes, direct deposit updates, or wire transfer instructions processed in the last 30-60 days against the out-of-band verification record. If a change was made and there's no record of a callback verification to a pre-registered number, treat it as potentially fraudulent until confirmed.

These checks take less time than a single incident response engagement. They should be on a monthly operational checklist, not a post-breach remediation list.

Pull inbox rules routing to external domains across all high-value accounts. If you find one you didn't create, you may have an active compromise. Revoke the session. Reset the credentials. Start the runbook.‍

Final Thoughts: Log In. Blend In. Act.

Scattered Spider needed ten minutes on the phone to enter MGM. They needed five days inside the network to understand it well enough to deploy ransomware across more than 100 ESXi hypervisors. The ten minutes is the attack. The five days is the strategy. The $100 million is the outcome.

Most ATO-BEC incidents don't end in ransomware. They end in a fraudulent wire that clears before anyone notices, or a payroll diversion that runs for a full pay cycle before the affected employee asks where their salary went, or a vendor invoice that's already been paid to the wrong account by the time the real vendor calls. The scale is smaller. The mechanics are identical.

Five days of dwell time is the attacker's competitive advantage. It exists specifically because most organizations are not watching the right things: the inbox rules, the session anomalies, the behavioral deviations from the account owner's established pattern. Closing that gap means deploying detection that reasons about account behavior, removing email as a sufficient channel for financial decisions, and maintaining a runbook that treats ATO-BEC as its own category with its own response requirements. The StrongestLayer email attack taxonomy tags account takeover BEC at trajectory 3.4 and rising. The five checks in Finding 11 take less time than reading this post. Run them today.

Frequently Asked Questions (FAQs)

Q1:  What is account takeover BEC?

Account takeover BEC occurs when an attacker gains access to a legitimate employee or executive email account and uses it to conduct business email compromise fraud — fraudulent wire transfers, invoice changes, payroll diversions — from inside the real inbox. Unlike classic BEC which impersonates someone from an external domain, ATO-BEC operates from the genuine authenticated account. SPF, DKIM, and DMARC all pass. There is no spoofed sender to flag. The only thing wrong is who controls the account.

Q2:  How did Scattered Spider breach MGM Resorts?

In September 2023, a Scattered Spider member called MGM Resorts' IT helpdesk, impersonated an employee identified via LinkedIn, and social-engineered a password and MFA reset for a privileged Okta account. The call lasted approximately ten minutes. From that single account reset, Scattered Spider gained access to MGM's single sign-on environment and spent two days moving laterally before deploying ransomware across more than 100 ESXi hypervisors. Total impact: $100 million in Q3 2023 losses, 37 million customers' data exposed, a $45 million class-action settlement in 2025, and five federal criminal charges filed.

Q3:  Why does it take so long to detect account takeover BEC?

The median dwell time between compromise and first fraudulent action is five days, per Palo Alto Networks Unit 42's incident response telemetry. During that window, the attacker does nothing detectable — they read emails, study workflows, map payment processes, and identify the right moment to act. Less than 8% of ATO-BEC incidents are discovered through technical controls. The majority surface through bank reconciliation or a vendor calling to ask about an unpaid invoice — after the money has already moved.

Q4:  What is an inbox forwarding rule and why do attackers create them?

Inbox forwarding rules silently copy incoming emails to an external address the attacker controls, allowing them to monitor responses to fraudulent requests without needing to stay logged into the compromised account. Attackers also create rules that automatically delete incoming replies to suspicious messages or mark certain emails as read — preventing the legitimate account owner from noticing unexpected responses in their inbox. LevelBlue SpiderLabs identifies forwarding rule creation as the primary reconnaissance mechanism in ATO-BEC. It is also the most consistently undermonitored signal across enterprise email environments.

Q5:  How does payroll diversion work in ATO-BEC?

The attacker, operating from a compromised employee or executive account, contacts HR or payroll requesting a change to direct deposit banking details. The pretext is routine — a new bank account, a banking partner change. The request arrives 5-10 days before the next pay cycle. Because the email comes from a recognized internal address and references normal administrative process, HR processes the change. The fraud is discovered when the legitimate employee notices their pay didn't arrive. By that point, funds have already cleared to an attacker-controlled account. LevelBlue documented attackers calling payroll before sending the fraudulent email — establishing credibility across two channels simultaneously.

Q6:  Why doesn't MFA stop account takeover BEC?

Two distinct pathways defeat MFA in ATO-BEC. First, AiTM session hijacking captures the live session token after MFA has already been completed — meaning MFA succeeded, but the proof was stolen in transit. Second, helpdesk social engineering of the kind Scattered Spider used at MGM bypasses MFA entirely by resetting it — the attacker convinces helpdesk staff to register a new MFA device on the target account, after which the attacker controls both the credentials and the authentication factor. FIDO2 security keys and passkeys resist both vectors, because the cryptographic handshake is domain-bound and cannot be proxied or helpdesk-reset without physical possession of the key.

Q7:  What is the cross-channel pivot tactic in ATO-BEC?

After using a compromised email account to establish initial contact with a finance team member, attackers increasingly move the conversation to WhatsApp, SMS, or voice before issuing the fraudulent payment instruction. This pivot moves the fraud outside the monitoring perimeter of corporate email security entirely. No email containing the fraudulent instruction is ever sent, so the email gateway has nothing to evaluate. The compromised email account served its purpose — establishing credibility — and the actual fraud instruction was delivered through a channel the security team can't see.

Q8:  How do I check if my organization has an active ATO-BEC compromise right now?

Five checks, run today across all high-value accounts. Pull all inbox rules created in the last 90 days routing to external domains. Review sign-in logs for authentications from new devices or unusual geographies in the last 30 days. Check sent items on executive, finance, and HR accounts for messages the account owner doesn't recognize — ask them directly. Look for MFA method registrations that occurred outside business hours or from unrecognized devices. Review any direct deposit changes or vendor banking updates made in the last 60 days against out-of-band verification records. If any of these reveal something the account owner didn't authorize, treat it as an active compromise and start the response runbook immediately.

Q9:  What regulations require ATO-BEC controls in 2026?

Several frameworks effective through 2025-2026 create compliance obligations that ATO-BEC directly implicates. PCI DSS v4.0 Requirement 5.4.1, mandatory since April 2025, requires anti-phishing controls for any organization handling payment card data. Nacha's ACH rule changes, effective March 2026, require risk-based monitoring for fraudulently initiated payment entries — the exact output of a successful payroll diversion or wire fraud. Singapore's Shared Responsibility Framework, effective December 2024, imposes formal anti-scam duties on financial institutions including cooling-off periods for high-risk account changes. The SEC's cybersecurity disclosure rule requires material incident notification within four business days of determining materiality — a threshold a fraudulent wire transfer can meet.

Q10:  What is the difference between ATO-BEC and vendor email compromise?

Both involve operating from inside a legitimate email account rather than an external impersonation. The difference is whose account. In ATO-BEC, the compromised account is internal — an employee or executive within the victim organization. The attacker uses internal authority to misdirect financial processes. In vendor email compromise, the compromised account is external — a vendor or supplier the victim organization pays. The attacker uses the trusted external relationship to insert a fraudulent payment instruction. Both defeat authentication-based detection for the same structural reason: the email is genuinely coming from a real, authenticated account. Detection requires behavioral reasoning, not signature matching.

Q11:  How does TRACE detect ATO-BEC during the dwell period?

TRACE builds per-account behavioral baselines — tracking message patterns, typical recipients, communication timing, content types, and organizational workflow context for every account. When an account deviates from its established baseline during what might be a dwell period — reading email at unusual hours, creating an inbox rule to an external domain, sending a message type that's never originated from this account before — TRACE flags it as an anomaly with a reasoning trace explaining which behavioral dimensions triggered concern. How TRACE powers real-time email threat prevention covers the full architecture. The core logic for ATO-BEC specifically: if the account is not behaving like the account owner, the detection fires before any fraudulent message is sent.

Q12:  What should an ATO-BEC incident response plan include?

Standard identity response — password reset — is insufficient for ATO-BEC. A complete runbook requires six steps in order: password reset, active session revocation (a stolen token remains valid after a password reset), review and removal of all inbox rules created during the compromise window, audit of MFA methods registered to the account during the compromise window, review of all outbound emails sent from the account during the dwell period for fraudulent instructions already delivered, and notification to any recipients of suspicious messages who may have already acted on a fraudulent request. Each step must be pre-documented in a written runbook. The remediation window is measured in hours, not days.

Q13:  How do I see this in action against my own environment?

Visit strongestlayer.com/demo to book a walkthrough. Our threat research team will run a real ATO-BEC attack scenario through TRACE's behavioral detection engine using your organization's actual communication baseline — and show you exactly which signals fire during the dwell period, before a fraudulent message is ever sent.

‍