How AI Industrialized Business Email Compromise

Business email compromise used to require patience, skill, and a specific target. An attacker would spend weeks mapping an organization, identifying who approved invoices, and crafting convincing lures. That model is still active. But it is no longer the only option.

In 2025 and 2026, threat intelligence teams started documenting something different: AI-powered phishing kits that automate the full attack chain, from stealing credentials to mapping payment workflows inside a compromised mailbox. The target does not need to be a Fortune 500. Any organization using Microsoft 365 is potentially in scope.

This is the industrialization of BEC. And it changes the role of email authentication fundamentally.

When your own tenant is the sending infrastructure, SPF and DKIM have nothing left to check. The only authentication signal that can catch this class of attack is one that tells you something unexpected is happening with your domain. That is where DMARC becomes irreplaceable, not as a blocking policy but as a monitoring signal.

The old model versus the new model

Traditional BEC worked like this: an attacker registered a lookalike domain, set up forwarding rules, and sent invoices from a domain that was almost right. DMARC policies at p=reject made this increasingly difficult. Organizations that monitored their DMARC aggregate reports could catch spoofing attempts before they succeeded.

The new model does not bother with lookalike domains. It compromises a real user account directly, usually through device code phishing, and then operates from inside that account. The emails pass SPF and DKIM because they are sent from an authorized Microsoft 365 account. They carry the same cryptographic authentication signature as a legitimate message from your finance team.

Only DMARC alignment can distinguish a legitimate internal message from one sent by an attacker who has compromised an account. But alignment alone is not enough. You need to be watching your DMARC reports and acting on what they show.

Inside an AI-powered phishing kit

In early 2026, researchers at Eye Security published an analysis of two phishing kits encountered during incident response. Both presented as legitimate SaaS products, complete with pricing pages, operator dashboards, and tiered subscription accounts. One called itself TokenVault. The other used the name Yaksha.

Neither kit introduced fundamentally new techniques. Everything in these tools has been documented individually: device code authentication abuse, Primary Refresh Token theft, Windows Hello persistence, FOCI pivoting. What changed was the packaging and the scale.

A single operator dashboard now manages the entire attack lifecycle. The AI component does the reconnaissance that used to require days of manual mailbox inspection. In at least one kit, the AI pipeline reads a victim's email automatically, maps payment approval workflows, identifies outstanding invoices, and prepares fraud scenarios tailored to that specific organization. This is the work that used to require a skilled attacker a full week. It now runs in minutes.

One feature in the TokenVault kit stands out: it displays a password change survival rate metric to operators. That is a confidence indicator. It tells operators how likely it is that a compromise will survive a victim password reset. The technique that makes this possible is Windows Hello key registration on the attacker-controlled device, which creates a secondary authentication factor that Entra ID trusts as a legitimate organizational asset.

Device code phishing and PRT theft

The entry point in both kits was device code authentication abuse. Here is the sequence:

1. The attacker triggers a Microsoft OAuth device code flow against a target account.
2. The target receives a user_code, typically delivered via a lure email or an injected message in an ongoing conversation.
3. The target visits the real microsoft.com/devicelogin, enters the code, and completes MFA on the legitimate Microsoft website.
4. The attacker's kit polls the token endpoint until the auth completes, then captures the resulting tokens.

The standard variant produces scoped access tokens tied to a specific application ID. These are useful but limited. The elevated variant uses a specific Microsoft Authentication Broker client ID that enables device registration in Entra ID. That registration yields a Primary Refresh Token.

A PRT is a long-lived credential, valid up to 90 days, tied to a device Entra ID trusts as a legitimate organizational asset. It enables silent single sign-on across Microsoft 365 and, critically, it survives password resets and MFA token revocation. The victim can change their password, revoke sessions, and re-enroll their authenticator. The attacker stays in.

Microsoft's own Threat Intelligence team documented this specific technique as Storm-2372 in February 2025. The approach has since been industrialized into commercial phishing kits.

Why password resets no longer help

Organizations that discover a compromised account often issue a password reset and call it contained. That response is insufficient against this class of attack.

The synthetic Windows Hello key registered during the device enrollment step survives password resets. Entra ID sees this key as a registered organizational device. It trusts it. The attacker retains access through a credential that a password change does not invalidate.

Proper containment requires revoking the registered device directly in Entra ID, reviewing and removing suspicious device registrations, and invalidating any Primary Refresh Tokens associated with those registrations. A password reset alone is a partial response to a full-device compromise.

Why SPF and DKIM cannot stop this

SPF checks whether the sending mail server is authorized for the From domain. DKIM verifies that the message was signed by the domain's private key. Neither check knows anything about who is authenticated on the other end of the Microsoft 365 session.

When an attacker sends email from a compromised Microsoft 365 account, they are sending from an authorized server and signing with the tenant's legitimate DKIM key. Both SPF and DKIM pass. The email arrives with the same authentication status as a message sent by a legitimate employee.

DMARC is the only built-in signal that can catch this. DMARC alignment requires the RFC5321.From domain to match the domain that passed SPF or DKIM. In a legitimate internal email, the From address is an organizational domain. In a compromised-account BEC email, the From address is also an organizational domain. DMARC alignment passes for the same reason SPF and DKIM pass.

This is where DMARC monitoring becomes important. DMARC aggregate reports tell you which domains are sending unauthenticated email. If you see a subdomain you do not recognize sending mail, that is a signal worth investigating. If you see sudden volume changes in your DMARC failure reports, that is also worth checking. But monitoring alone is not protection. You need the policy set correctly and you need to act on what you see.

What your monitoring should cover

AI-powered BEC kits have a specific operational pattern. They compromise a small number of accounts, map payment workflows, and then send targeted fraud emails to suppliers or internal finance contacts. They operate slowly and quietly. Speed is not their advantage. Patience is.

Your monitoring should cover several signals that this class of attack leaves behind:

Unexpected device registrations in Entra ID, particularly registrations from consumer Windows Hello keys or unfamiliar device IDs
Mailbox permissions granted to applications or service principals that were not part of a documented onboarding process
Mail forwarding rules created outside of standard IT provisioning
Sign-in activity from IP addresses that do not match your normal geographic or network footprint
Sudden increases in mail sent to external addresses from accounts that normally communicate internally

You can use DMARCFlow to monitor for From-domain anomalies. DMARCFlow tracks your DMARC aggregate reports and can alert on shifts in your authentication failure landscape. A new subdomain appearing in your DMARC reports, or a sudden change in the ratio of passing versus failing messages from a specific domain, can indicate a subdomain takeover that is part of a broader BEC chain. DMARC is not your primary defense against compromised-account attacks, but it is a useful early warning system for the infrastructure reconnaissance phase that often precedes them.

How to protect your organization

Protecting against AI-powered BEC requires addressing the authentication chain, not just the email channel.

Start with device code authentication policies. Microsoft allows organizations to disable or restrict device code flows for non-interactive sign-in scenarios. If your environment does not require device code authentication for legitimate workflows, block it at the Conditional Access level.

Review registered devices in Entra ID regularly. Look for registrations that show Windows Hello for Business or MDM enrollment that you did not provision. Remove anything that does not match your documented device management baseline.

Enforce MFA with phishing-resistant factors where possible. FIDO2 hardware keys, Windows Hello for Business with attestation, and certificate-based authentication are harder to steal via device code phishing than TOTP codes or push notifications.

Finally, treat your DMARC policy as a monitoring tool, not just a reject policy. Organizations that move to p=reject too early without understanding their legitimate mail flow will break internal mail or stop receiving important transactional messages. Start with p=quarantine, monitor for two to four weeks, then move to p=reject when your aggregate report shows no unexpected failures from legitimate senders.

Frequently asked questions

Can SPF and DKIM stop AI-powered BEC emails sent from a compromised account?

No. When an attacker sends from a legitimate, compromised Microsoft 365 account, the emails pass SPF and DKIM because they originate from an authorized Microsoft server and are signed with the tenant's valid DKIM key. Only DMARC alignment and proactive monitoring of mailbox-level anomalies can detect this class of attack.

What does a Primary Refresh Token (PRT) do, and why does it matter?

A PRT is a long-lived authentication artifact issued by Entra ID to registered devices. It enables silent single sign-on across Microsoft 365 services and can survive password resets. When an attacker registers a synthetic Windows Hello key and obtains a PRT, they have persistent access that a standard password reset does not revoke.

How do I contain a compromised account if password resets do not work?

Revoke all registered devices for the affected account in Entra ID, invalidate all Primary Refresh Tokens, review and remove any application permissions or mail forwarding rules added during the compromise window, and investigate whether the account was used to register additional attacker-controlled devices.

Is DMARC useful against AI-powered BEC if the emails are sent from inside the tenant?

DMARC alignment still passes for internal emails, so DMARC cannot distinguish a legitimate internal message from a compromised-account message using authentication alone. However, DMARC monitoring can catch subdomain takeovers and infrastructure anomalies that are part of the reconnaissance phase before an attack. Treat DMARC as an early warning system, not a primary defense against compromised-account BEC.

---

If you found this useful, subscribe to the DMARCFlow newsletter for practitioner-focused email security writing, delivered monthly.