All Posts
Threat Research

Email Security Threats in 2026: BEC, AiTM, and Zero-Day Phishing Explained

The 2026 email threat landscape: BEC, vendor email compromise, AiTM session theft, and zero-day phishing, the attacker tooling behind them, and why legacy filters miss them.
Written by
AegisAI Threat Intelligence
Published on
September 9, 2026

Last updated: September 8, 2026

The email threat landscape in 2026 is dominated by attacks that carry no malware: business email compromise (BEC), vendor email compromise (VEC), adversary-in-the-middle (AiTM) credential theft, zero-day social engineering written to look like routine business mail, and a growing share of all of it sent from hijacked real accounts. They work because they exploit trust, context, and legitimate infrastructure instead of files, links, or exploit code. Stopping them takes a system that reasons about intent, not a filter that checks a message against a list of known-bad indicators.

This piece maps the landscape end to end: the attack categories, the tooling behind them, why static defenses miss them, and what a detection stack has to do differently.

What does the email threat landscape include in 2026?

Most conversations about email threats collapse into "phishing", which hides how far the categories have diverged. Each has its own mechanism and needs its own detection approach.

Threat category Core mechanism Why signature-based tools miss it
Credential phishing Fake login pages harvest usernames and passwords No malicious payload; pages sit on legitimate cloud hosting
Adversary-in-the-middle (AiTM) A reverse-proxy kit captures the session token after MFA completes Bypasses MFA; the traffic looks like a normal login
Business email compromise (BEC) Impersonation of an executive, vendor, or HR to trigger a payment or data disclosure No link, no attachment, no signature to match
Vendor email compromise (VEC) A real vendor mailbox is compromised and used to hijack a live invoice thread Sender domain, DKIM, and thread history are all legitimate
Compromised-accounts A hijacked mailbox sends the next wave of lures to its own contact list, so every victim becomes a sender Real account, real domain, authentication passes; there is no sender reputation to block
Zero-day phishing New infrastructure and content with no reputation history Threat feeds and blocklists are always one victim behind
Malware delivery An attachment or link installs a payload Still exists, but a shrinking share of high-impact incidents as a first stage

The highest-damage categories, BEC, VEC, AiTM, and zero-day, leave almost nothing for a rules engine to grab. Attackers adapted to the last generation of controls on purpose. The FBI's Internet Crime Complaint Center put BEC losses at $2.77 billion in 2024, more than any category except investment fraud, from attacks that in most cases carried no malware at all.

Why are these attacks invisible to traditional email filters?

Secure email gateways (SEGs) and rule-based systems were built to answer one question: does this message contain a known-bad artifact? A malicious URL, a flagged attachment hash, a domain on a blocklist, a spoofed header that fails SPF or DKIM.

BEC, VEC, and AiTM attacks are built to answer "no" to all of those. The email comes from a real account, on real infrastructure, with valid authentication records, referencing a real project or invoice. The only thing wrong with it is what it asks the recipient to do, and catching that requires understanding context, not scanning content.

Our own telemetry shows how wide the gap is. In State of the AI Threat in Email: 2025, drawn from more than 20,000 phishing emails in production environments, 50.3% of AI-generated phishing got past the built-in Gmail and Microsoft filters, against 28.5% of human-written phishing. Of the AI-written spear phishing that got through, 72.6% passed DMARC. Authentication verifies infrastructure, not intent.

Business email compromise (BEC) is a targeted social engineering attack in which the adversary impersonates a trusted party, an executive, vendor, or internal team, to get someone to move money, change payment details, or share sensitive data. There is usually no malware and no link. The message is the attack.

Adversary-in-the-middle (AiTM) phishing is a credential attack in which the attacker sits between the victim and a real login page using a reverse-proxy kit. The victim authenticates, including completing MFA, and the attacker captures the resulting session token and replays it to enter the account directly. No password is needed afterward, and MFA stopped nothing.

Zero-day phishing is any attack that uses infrastructure, domains, or content with no prior history in threat intelligence feeds. Reputation and blocklist systems match against known-bad indicators, so a new campaign is invisible to them until someone else gets hit and reports it.

Why hijacked accounts are becoming the delivery vector

The biggest change in the landscape is where the mail comes from. A growing share of phishing now originates from real, compromised accounts rather than attacker-registered domains, which removes the one signal every legacy control depends on: a sender with a bad or unknown reputation.

Our TIDALGUEST teardown from June 2026 shows the mechanic at scale. Each victim who entered credentials on the fake invitation page handed the operator a working inbox. Within hours, the same lure went out from that inbox to its full contact list, from a known address, with SPF, DKIM, and DMARC all passing. Every enterprise URL scanner in the dataset rewrote the link and delivered the message. Roughly a third of the organizations we monitor received at least one campaign email, and each new compromise turned another contact list into the next sending pool. MITRE tracks the technique as internal spearphishing (T1534) and valid cloud accounts (T1078.004).

The same pattern sits underneath vendor email compromise and most modern BEC. The attacker is not pretending to be a trusted sender. The attacker is the trusted sender, replying inside a real thread from a real mailbox. Per-message inspection cannot see anything wrong, because nothing in the individual message is wrong. The signal is the pattern across messages: a known contact suddenly writing to an undisclosed recipient list, an invitation-themed lure hitting many recipients at once, a supplier changing bank details in the fourth reply of a thread that had been routine.

What tools do attackers use in BEC and account takeover?

Three toolsets show up in nearly every serious BEC or account-takeover campaign. The mechanics matter more than the category names.

Impersonation infrastructure

  • Domain and email spoofing. Missing or misconfigured SPF, DKIM, or DMARC lets the attacker forge a sender identity outright.
  • Lookalike domains. A single swapped character or homoglyph, such as "rnicrosoft.com", that passes a quick visual check.
  • Thread hijacking. Once a mailbox is compromised, the attacker replies inside a real, ongoing conversation and inherits all of its legitimacy.
  • LLM-generated messages. Generative AI produces clean, context-appropriate text with the right tone of urgency and authority, removing the broken-English tells that used to flag phishing. In our 2025 data, 22% of observed phishing volume was AI-generated, and 62.9% of that was targeted spear phishing.
  • Voice cloning for vishing. Some campaigns pair the email with an AI-generated phone call to add pressure and cross-channel credibility.

Credential theft kits

  • Phishing-as-a-service kits that clone Microsoft 365, Google Workspace, and Okta login pages, sold or rented on underground forums.
  • AiTM reverse-proxy kits, the more consequential evolution of the above. They sit between the victim and the real identity provider and forward traffic in both directions, so the login succeeds while the attacker captures the session cookie. This is why "we have MFA" is no longer a complete answer to credential risk.
  • Credential aggregation platforms that combine breach dumps and infostealer logs into verified username and password lists, so the attacker can skip phishing entirely for some targets.

Account compromise and persistence tools

  • Automated credential-stuffing frameworks that test large username and password sets against login endpoints.
  • MFA fatigue and fake-IT social engineering to get a target to approve a push notification or hand over a one-time code.
  • Malicious OAuth app grants. After one successful login, the attacker authorizes a third-party application with mail read and send scopes. That grant survives a password reset and rarely appears in a standard mailbox audit, because no forwarding rule was ever created. Most BEC write-ups skip it, and it is one reason unsanctioned app discovery and email security belong in the same conversation.

Persistent access is what turns a single phishing click into a multi-week fraud operation. Attackers use the dwell time to study invoicing cycles, approval chains, and writing style before sending the fraudulent request.

How should security teams detect these attacks?

Detection has to move from "does this match a known bad pattern" to "does this request make sense given who is asking, what they are asking for, and how." The signals worth reasoning over:

  • Sender relationship. Is this a first-time sender claiming an established relationship?
  • Domain and infrastructure age. New domain, new sending infrastructure, high-authority request.
  • Language and intent. Urgency, secrecy, a request to bypass normal process, a tone that does not fit the claimed sender or the thread.
  • Thread and workflow consistency. Did this reply land in a thread it does not belong in, or change payment details mid-conversation?
  • Cross-message pattern. The same lure from one sender to many recipients, or a known contact mailing an undisclosed list. Invisible to a rule that looks at one message at a time.
  • Identity signals. New sign-in location or device, new mail forwarding rule, new OAuth app grant, impossible-travel logins.

Layered controls still matter and should stay in place:

  1. SPF, DKIM, and DMARC to block direct spoofing. Necessary, and useless against lookalike domains or compromised legitimate accounts.
  2. Phishing-resistant MFA (FIDO2 and passkeys) to cut credential-based takeover. AiTM kits can still capture session tokens after MFA on weaker implementations.
  3. Dual authorization for wire transfers and out-of-band verification for any change to banking details. A business-process control that stops the fraud even when the email is convincing.
  4. Identity and mailbox monitoring for new forwarding rules, new OAuth grants, and anomalous logins.
  5. Email detection that reasons about intent and relationship rather than matching indicators.

What should you do after a suspected BEC or phishing incident?

  1. Isolate the account: force a password reset and revoke active sessions immediately.
  2. Audit OAuth app grants and mail forwarding and redirect rules on the affected mailbox, not only the inbox rules a user can see.
  3. Review sign-in logs for anomalous locations, devices, or impossible-travel patterns.
  4. Trace the thread. Identify every recipient who saw the fraudulent message and whether anyone acted on it: a payment, a credential entry, a data share.
  5. If a payment went out, contact the receiving bank immediately to request a recall. Time is the biggest factor in fund recovery.
  6. Extend the investigation to any vendor or partner mailbox referenced in the thread. VEC attacks often originate outside your own tenant.
  7. Update detection logic and staff awareness with the specific pattern used. Attackers return to a target that responded, even partially.

Where does AegisAI fit?

Most of the attacks above are defined by what they lack: no malware, no bad link, no signature. That is the category traditional filters were never built to catch, and the one AegisAI's agents are built for. Instead of matching a message against rules or reputation lists, the agents reason about the sender relationship, the request, and the language of each message the way an analyst would, from the first day of deployment, and remove what they find before users see or click it.

  • Deployment is API-based for Microsoft 365 and Google Workspace, with no MX record change and no mail-flow disruption. Setup takes minutes.
  • Detections are explainable. Every flagged message ships with the reasoning behind it, not a black-box score, so analysts can verify the call instead of guessing.
  • VIP and role-based threat visibility shows which roles attackers are hitting: finance, executives, anyone with approval authority.
  • Customers see 90% fewer false positives than legacy filters, which matters because alert fatigue is how real BEC attempts get lost in the noise.

To see how the agents reason about a real message in your own environment, book a demo.

Frequently asked questions

What is the biggest email threat facing businesses today? Business email compromise and vendor email compromise cause the largest direct financial losses because they target payment workflows directly and need no malware to succeed. AiTM and zero-day credential attacks are the fastest-growing technical category because they defeat MFA and threat-feed-based detection.

How is BEC different from phishing? Phishing generally relies on a malicious link or attachment to deliver a payload or harvest credentials. BEC relies on impersonation and social engineering alone. The email itself is the attack, with no technical artifact to detect.

Can MFA fully stop email account takeover? No. Standard MFA stops basic credential stuffing, but AiTM reverse-proxy kits capture session tokens after a legitimate MFA completion and reuse them. Phishing-resistant MFA (FIDO2 and passkeys) closes much of this gap and should be paired with monitoring, not treated as a complete answer.

What is a zero-day phishing attack? An attack using domains, infrastructure, or content with no history in threat intelligence feeds. Reputation-based tools match known-bad indicators, so zero-day campaigns are invisible to them until after the first wave of victims.

How do I detect a compromised OAuth app or malicious forwarding rule? Audit third-party app grants and mail rules directly in the Microsoft 365 or Google Workspace admin console on a recurring schedule, not only after an incident. Attacker access often survives a password reset because the OAuth grant or forwarding rule was never removed.

Why do phishing emails from a known contact get through? Because the account is real. When an attacker hijacks a mailbox, the next wave of lures comes from a legitimate address with valid authentication, so reputation checks and blocklists have nothing to act on. TIDALGUEST spread this way, with each stolen inbox mailing its own contact list. Catching it requires correlating across messages, not inspecting each one alone.

Why do secure email gateways miss BEC? SEGs match messages against signatures, known-bad URLs, and domain reputation. BEC messages have none of those. They come from real accounts or convincing lookalikes with clean language, so a rules engine has nothing to flag.

Don’t Miss the Next Big Threat
Subscribe today to receive updates on the newest cyberattacks, product innovations, and best practices for protecting your organization.

Subscribe

Success! We’ll be in touch soon.
Something went wrong while submitting.
Related topic articles
Read All Articles
A legitimate supplier invoice collects three weak risk signals, new domain, urgent tone, locked PDF, whose score crosses the filter threshold and gets quarantined. A dashed path shows an agent reading the whole message and delivering it.
Technical Guides
Why Email Security False Positives Happen and How to Fix the Root Cause
Why signal-stacking email filters block legitimate mail, how to measure precision, recall and false-positive rate, and how reasoning-based detection cuts both error types at once.
Why Email Security False Positives Happen and How to Fix the Root Cause
One threat corpus fans out to three vendor gates tested at the same time. Outcomes are scored on the right: two threats removed, one reached the user.
Technical Guides
How to Evaluate Email Security Vendors: A Practical Framework for Security Leaders
A buyer's framework for evaluating email security vendors: detection testing, false-positive verification, architecture, explainability, total cost, and a POV checklist.
How to Evaluate Email Security Vendors: A Practical Framework for Security Leaders
Two mail paths compared. A gateway sits in the delivery path where MX records point and mail queues. An API platform sits beside the path, reading after delivery and retracting in seconds.
Technical Guides
How to Evaluate API Based Email Security: MX Records, Mail Flow, and SIEM
A practical framework for evaluating API based email security: what to ask about MX record changes, mail flow impact, and SIEM and fraud tool integration.
How to Evaluate API Based Email Security: MX Records, Mail Flow, and SIEM