The kit that reads the mailbox and swaps the bank details: TokenLover and YaksaLover

Nothing new, and that is exactly why it matters

The first thing that stands out in bulletin BL01/260731/CSIRT-ITA is a sentence that sounds reassuring and is not: the toolkits «are not associated with the exploitation of new zero-day vulnerabilities».

There is no flaw to fix. There is no patch to install. What the CSIRT describes is a product: two kits sold as a service — phishing as a service — that take known techniques, line them up, and put them within reach of people who could not run them otherwise. TokenLover, «previously known as TokenVault», and YaksaLover, «also known as Yakhub or Yaksha».

The criticality assigned by the CSIRT is medium (61.97). The listed topics are BEC, Business Email Compromise, PhishingAsAService.

The way in: a code they ask you to approve

The initial access vector is the OAuth Device Code Flow, the mechanism designed to let devices without a convenient keyboard authenticate — a smart TV, a meeting-room appliance. It works like this: the device shows a code, the user enters it on a Microsoft page from their own computer or phone, and authorises the session.

The attack consists of getting that code to the user with a credible pretext and persuading them to enter it. The CSIRT's sentence is the most important in the whole bulletin: «The presence of multi-factor authentication does not prevent the attack where it is the victim themselves who authorises the session associated with the device code».

There is nothing to break. MFA works perfectly: it asks for a confirmation and gets one. The confirmation is genuine; the request is what is false.

1. 01
   The code

   the attacker starts a device code flow and delivers the code to the victim
2. 02
   The approval

   the victim enters it on a legitimate Microsoft page and confirms with MFA
3. 03
   The token

   the attacker receives a valid session: they never saw the password

After the way in: staying, and understanding

Once the session is obtained, the kits do two things the bulletin describes precisely.

The first is to spread and stay. The CSIRT points to pivoting via FOCI tokens (Family of Client IDs) and the rotation and renewal of ESTS authentication cookies, with access to Exchange Online, Microsoft Graph and SharePoint. For persistence, a key associated with Windows Hello for Business — so-called NGC keys — is registered on the victim's account. The consequence, in the CSIRT's words: «changing the password alone may not be sufficient to interrupt the abusive access».

That this is a commercial objective rather than a side effect is proved by one detail: the kits' dashboards expose a dedicated metric, the «password change survival rate». Surviving a password change is a product feature, measured and shown to the customer.

The second thing is to work out where the money is. TokenLover, the CSIRT writes, has «a pipeline for the automated analysis of mailboxes, based on language models (LLM)». What it looks for, per the bulletin's own list: invoices awaiting payment, recurring suppliers and customers, bank details, deadlines and amounts, users who approve transactions, and the habits of the organisation's correspondence.

The leap from traditional phishing sits here. Historically the slow part of a business email fraud was human: somebody had to read months of correspondence, work out who pays whom, learn how emails are written in that organisation, pick the right moment. That was the bottleneck keeping victim counts low. A language model now does that work, in series, on every compromised mailbox.

The final fraud, and why technical controls miss it

The closing step is the substitution of bank details in invoices and correspondence, sent from the victim's legitimate Microsoft 365 mailbox.

Hence the CSIRT's warning about email authenticity checks: «controls based solely on SPF and DKIM may not be sufficient». That is correct and worth explaining. SPF and DKIM verify that a message really comes from the domain it claims and has not been altered in transit. Here both checks pass, because the email really does leave that domain, from that mailbox, with those keys. What changed is not the sender: it is who is using it.

An almost ironic detail closes the technical picture. The CSIRT notes signs of vibe coding in the kits: use of Vite, React and Supabase, and «recurring code patterns and comments attributable to automated programming assistance tools». The same tools that lower the barrier to entry for software development lower it here too.

The mitigations the CSIRT recommends

The bulletin lists concrete measures, and they are all configurations rather than purchases:

• disable the Device Code Flow where it is not needed — in most organisations it is not;
• if it is needed, restrict it with Conditional Access to specific devices, networks or user groups;
• monitor the registration of new Windows Hello or FIDO keys on accounts: this is the persistence signal described above, and it will appear in the logs as a legitimate operation;
• out-of-band verification for every change of bank details. This is the measure that stops the fraud even when everything else has gone wrong: a phone call to an already known number — not the one written in the email — before changing bank details in your records.

The last one is not a technical control, and that is exactly why it works. Whoever controls the victim's mailbox controls everything that passes through the mailbox. They do not control the phone number you already had on file.

What we do not know

The bulletin publishes no indicators of compromise, does not quantify how many Italian organisations have been hit, does not attribute the kits to an actor or a country, and gives no prices or subscription terms. The Italian angle comes from the prevalence of Microsoft 365 in the country's business fabric, not from a declared victim count. The technical sources cited by the CSIRT itself are research by Eye Security and an entry on mallory.ai: readers who want the technical detail will find the source material there.