How AI is powering business email compromise at scale

By: Jorn Pieterse

Business email compromise (BEC) remains one of the most damaging threats we respond to, and the tooling behind it is getting more complex by the day. On a recent investigation, we came across multiple suspicious domains that piqued our interest. These led us to two phishing kits we had not encountered before.

Both look, at a glance, like legitimate SaaS products. Both were clearly built with AI, down to the comments and code structure. And both automate the full path from a stolen login to a forged invoice.

Neither kit relies on a new technique. Device code abuse, token theft, Windows Hello persistence: all of it is documented, some of it by Microsoft’s own threat intelligence team. What has changed is who can run it and how many victims one operator can run it against at once. A single dashboard now does the work that used to require a skilled attacker’s full attention, all with the help of AI.

Here is what we found, in sum:

Two new Phishing-as-a-Service kits. Both present as legitimate SaaS products, complete with pricing pages, dashboards, and tiered operator accounts. Both are operator consoles for managing stolen Microsoft 365 identities at scale.

Vibe-coded with AI. Both kits show clear signs of AI-assisted development, down to the code structure and the tell-tale AI em dash left in the comments. This is how attackers now build faster, more capable tooling.

No new techniques but industrialised scale. Device code phishing, FOCI pivoting, PRT theft, Windows Hello (NGC) persistence, ESTS cookie generation, and CAP bypass are all publicly documented. What is new is that one operator can now run all of it against dozens of victims from a single dashboard.

AI-driven fraud was built in. One of the kits uses an AI pipeline to read harvested mailboxes and map an organisation’s payment flows, invoices, and outstanding balances.

Persistence that survives a password reset. By registering a synthetic Windows Hello key, the kits can retain access after a password change. One of the kits even displays a “password change survival rate” metric to operators.

Attacks from inside the real mailbox. Phishing emails are sent from the victim’s genuine Microsoft 365 account, so they pass SPF and DKIM and are nearly indistinguishable from legitimate internal mail.

This is the shift from one skilled attacker targeting one company to Phishing-as-a-Service, where the same capability is packaged, automated, and available to far less skilled operators.

These are the phishing kits we found

The first kit calls itself TokenVault // 2026. However, due to its Lovable vibecoded feeling, we have named it TokenLover. At first, it looked like a token management service. Its footer proudly states it is “Built on TokenTacticsV2.” It has a pricing page, a feature comparison table, and a live support dashboard. It looks, at first glance, like a legitimate SaaS product. It is not.

The other phishing kit we found calls itself Yakhub/Yaksha. When visiting the domain linked to the kit, we were greeted by a login screen and nothing more. However, this kit also has a very vibecoded feeling to the UI (more about that later ;)). And we wanted to keep the running theme in there, so we have dubbed it YaksaLover.

How we found the phishing kits

TokenLover first came onto our radar during an incident response case. Investigating a device code phishing incident, we traced the IP behind the initial sign-in and ran it through Shodan, which pointed us to a domain hosted on that same IP. The domain served up a page dressed as a legitimate Azure token management service: pricing tiers, marketing copy, the works. Then we lifted the hood.

Image 1. The TokenLover phishing kit pretends to be a legitimate service to throw defenders off guard

We identified YaksaLover in the exact same way as TokenLover. This phishing kit has a email client built in and is in some aspects more developed than TokenLover, but in some aspects very lacking. When visiting the URL of the kit, we encountered a login screen. But that login screen wouldn’t stop us from diving deeper, and diving deeper we did.

TokenVault/TokenLover

TokenLover is an operator console, the backend that an attacker uses to manage everything from setting up device code phishing campaigns and adding persistence to using AI to exfiltrate data. Think of it as a CRM for stolen Microsoft identities, with a campaign manager, an AI analyst, and a post-exploitation automation engine bolted on.

Image 2. A look at the TokenLover console

The operator panel supports multiple tiers of users: administrators who manage the platform, operators who run campaigns, and sub-operators (“subusers”) who are handed a scoped view of specific captured sessions. Subscription expiry, per-user feature flags, audit logging, and a duplicate-session security alert system are all present. This is professional tooling for a distributed team.

Image 3. The session management tab with AI functionality built in

Step 1: Device code phishing

The entry point is device code authentication abuse. The attacker triggers a legitimate Microsoft OAuth device code request and delivers the resulting user_code to the victim, typically by embedding it in a convincing lure or injecting it into an ongoing conversation. The victim visits the real microsoft.com/devicelogin, enters the code, and completes MFA on the real Microsoft website. Just as we have seen in device code phishing so many times before.

TokenLover initiates this flow against three distinct client configurations:

Office standard Office family scopes, granting access to mail, calendar, Teams, and OneDrive

Admin Full elevated Graph API permissions for directory-level access

Broker using client ID 29d9ed98-a469-4536-ade2-f981bc1d605e, the Microsoft Authentication Broker

That third variant is the one that matters most. The Broker client ID is not chosen arbitrarily, because it is the one that unlocks device registration in Entra ID, which, in turn, yields a Primary Refresh Token (PRT).

And a PRT is like gold for phishers: unlike the app-scoped access tokens the Office and Admin variants produce, it is a long-lived credential (valid for up to 90 days) tied to an attacker-registered device that Entra ID now trusts as a legitimate organisational asset, enabling silent single sign-on across Microsoft 365, survival of password resets and token revocation, and MFA-satisfied sessions the victim already completed on the attacker’s behalf.

It is the same client ID that Microsoft’s own Threat Intelligence team called out in their February 2025 Storm-2372 disclosure.

The moment a victim completes authentication, their user_code is automatically copied to the attacker’s clipboard and a polling loop starts against /api/v1/auth/device-code/poll.

Timing is everything here: device codes typically expire within about 15 minutes. The platform has to lure the victim and capture the resulting tokens inside that narrow window, hence the automation. When the poll returns success, the captured tokens land in the vault and the platform immediately runs the next step.

Image 4. Due to us not having an actual account, we can’t see the templates. You just have to imagine they are there. Or read the rest of the article to see the templates of YaksaLover ;).

Step 2: FOCI pivot to every Microsoft service

A single refresh token, when obtained via a FOCI-eligible client (FOCI, Family of Client IDs, is a group of first-party Microsoft apps that share refresh tokens that can be exchanged for access tokens scoped to any other Microsoft service in the same family). TokenLover calls /api/v1/auth/refresh/to-all to perform this exchange in bulk; Outlook, Graph API, Teams, SharePoint, OneDrive, and Azure Management simultaneously. All resulting tokens are stored and labelled by service.

This is not a novel technique. The TokenTacticsV2 module that the kit is built on has implemented FOCI pivoting since its earliest releases. What TokenLover adds is the operator UI and the automation that runs everything downstream without manual intervention.

Step 3: Windows Hello for business key injection

This is where the platform goes further than most published research or publicly known kits.

Every time a new token arrives in the vault, autoInjectNewTokens fires. This function silently executes a two-step pipeline against the victim’s Entra ID account:

1. Calls /api/winhello/generate-key to generate a fresh RSA-2048 key pair

1. Calls /api/winhello/{id}/inject-full with the victim’s UPN and tenant ID to register a synthetic Windows Hello for Business NGC (Next-Generation Credential) key against their account

Once this key is registered, the platform can mint new Primary Refresh Tokens using the injected key instead of the password. So a password reset alone won’t evict the attacker. It isn’t foolproof, though: it depends on the earlier device registration step having succeeded and on the tenant allowing device registration. And it can still be cut off by revoking the device identity or the key, or by a full session/token revocation, just not by a password change on its own.

The Admin panel makes no attempt to hide what this is for. It displays a metric called “password change survival rate” on the NGC Protection dashboard. The attacker can see, across their entire victim pool, what percentage of compromised accounts will survive a password reset. Bulk NGC registration is a one-click operation.

Image 5. The phishing kit admin panel

This technique was documented by Dirk-jan Mollema in October 2023. Its presence here, automated and integrated into the default capture flow, means victims who change their password after a device code phishing incident may not be fully remediated.

Step 4: ESTS cookie generation, browser-level access without MFA

PRT-equivalent tokens and NGC keys can be converted into browser-injectable JavaScript snippets, short console commands that, when pasted into DevTools on login.microsoftonline.com, plant ESTSAuthPersistent or ESTSAuth cookies and grant full browser access to the victim’s account without triggering MFA.

TokenLover offers five separate pathways for this conversion:

Stored PRT: /api/prt/{id}/cookie, x-ms-RefreshTokenCredential cookie

Broker session: /api/prt/session/{id}/sso-cookie, SSO cookie (JS snippet)

Bearer token: /api/v1/auth/token-to-ests, ESTS cookie (JS snippet)

NGC/WHfB key: /api/winhello/{id}/generate-ests-cookies, ESTS persistent cookie

Legacy OWA: /api/owa-bypass/convert-full, OWA-specific session cookie

The OWA bypass path is worth noting separately, it targets Outlook Web App’s legacy cookie authentication, specifically because some Conditional Access Policies that apply to OAuth flows do not apply to the OWA cookie path.

Step 5: Post-exploitation automation (GraphRunner)

A fifth section of the operator panel, the so called “Exploit Dashboard”, is fully present in the HTML but suppressed from the UI via v-if="false". It is either hidden from lower-tier subscribers or deliberately disabled for this deployment. Its code is complete and functional.

The Exploit Dashboard runs a four-phase automated pipeline against captured sessions using GraphRunner:

Recon: Enumerate directory users, groups, SharePoint sites, app registrations, Conditional Access Policies

Pillage: Extract keyword-matched emails, OneDrive files, Teams chats, shared mailbox contents, user attribute secrets

Persistence: Register OAuth apps with broad consent, invite guest users, inject into security groups, discover CAP bypass clients

Attack paths: Execute eight named adversarial paths automatically

The eight attack paths are hardcoded by name: Group PrivEsc, Dynamic Group abuse, Watering Hole, App Persistence, Guest + SharePoint access, Internal Phishing, Shared Mailbox access, and CAP Bypass. Each is a well-documented Azure AD post-exploitation technique. The platform runs the

[truncated for AI cost control]