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.

Campaigns leveraging EvilTokens have impacted organizations in various industries, including wholesale distribution, construction, financial services, real estate, higher education, and healthcare, with the highest concentrations of observed victim activity in the United States, Canada, the United Kingdom, Australia, India, and France. Working with partners, Microsoft’s Digital Crimes Unit (DCU) facilitated a coordinated disruption of infrastructure used to operate the EvilTokens service.

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.

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.

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.

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.

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.

The platform offers 44 different themes for customizing email templates and landing pages, including text and colors.

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”).

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.

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.

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:

• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• 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).
• Increase Advanced Phishing Threshold to 2 or 3.
• 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.
  • When a user is a high risk and Conditional Access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • 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.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• 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.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop the threat actor.
• 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.

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.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

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.

• Technique profile: Device code phishing
• Tool profile: EvilTokens
• Actor profile: Storm-2922

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.

EmailEvents
| where isnotempty(ThreatTypes) and DeliveryLocation in~ ("Inbox/folder","Junk folder")
| extend Name = tostring(split(SenderFromAddress, '@', 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, '@', 1)[0])
| extend Account_0_Name = Name
| extend Account_0_UPNSuffix = UPNSuffix
| extend IP_0_Address = SenderIPv4
| extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress

Microsoft Sentinel

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:

• Phishing link click observed in Network Traffic

References

• Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure Huntress

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Unmasking EvilTokens: Getting to the root of device code phishing appeared first on Microsoft Security Blog.

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.

Campaigns leveraging EvilTokens have impacted organizations in various industries, including wholesale distribution, construction, financial services, real estate, higher education, and healthcare, with the highest concentrations of observed victim activity in the United States, Canada, the United Kingdom, Australia, India, and France. Working with partners, Microsoft’s Digital Crimes Unit (DCU) facilitated a coordinated disruption of infrastructure used to operate the EvilTokens service.

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.

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.

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.

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.

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.

The platform offers 44 different themes for customizing email templates and landing pages, including text and colors.

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”).

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.

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.

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:

• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• 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).
• Increase Advanced Phishing Threshold to 2 or 3.
• 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.
  • When a user is a high risk and Conditional Access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • 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.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• 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.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop the threat actor.
• 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.

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.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

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.

• Technique profile: Device code phishing
• Tool profile: EvilTokens
• Actor profile: Storm-2922

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.

EmailEvents
| where isnotempty(ThreatTypes) and DeliveryLocation in~ ("Inbox/folder","Junk folder")
| extend Name = tostring(split(SenderFromAddress, '@', 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, '@', 1)[0])
| extend Account_0_Name = Name
| extend Account_0_UPNSuffix = UPNSuffix
| extend IP_0_Address = SenderIPv4
| extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress

Microsoft Sentinel

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:

• Phishing link click observed in Network Traffic

References

• Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure Huntress

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Unmasking EvilTokens: Getting to the root of device code phishing appeared first on Microsoft Security Blog.

MacSync Stealer is a macOS-focused information stealer that relies on changing infrastructure to deliver payloads, communicate with compromised devices, and exfiltrate data. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control (C2) replacement after public disclosure.

Microsoft Defender Experts expanded that view by correlating recurring endpoints and network behaviors across the activity. This behavior-led approach connected more than 30 domains and showed that the infrastructure supported more than C2 communication, extending into active collection, staging, and exfiltration. The findings demonstrate that although domains may rotate quickly, repeated execution patterns, request characteristics, staging behavior, and upload methods provide defenders with more durable opportunities to investigate MacSync Stealer activity. 

Activity overview 

Microsoft Defender Experts reviewed endpoint and network telemetry to determine which MacSync Stealer behaviors persisted as infrastructure changed. The investigation followed the activity from C2 communication through collection, staging, and exfiltration, using recurring technical traits to connect activity across rotating domains. Execution began from an interactive shell session consistent with ClickFix social engineering, where users are tricked into pasting or running commands in Terminal. The shell session used curl to retrieve attacker-controlled payload content, followed by script-driven execution and outbound communication. 

After execution, the malware communicated with attacker-controlled infrastructure using recurring URI paths, macOS User-Agent strings, API-key headers, and curl command-line options. These request traits became durable behavioral pivots because they remained consistent even as domains changed. The activity then progressed into collection behavior targeting macOS Keychain material, browser data, locally stored credentials, cloud and Secure Shell (SSH) credentials, and sensitive files from common user directories. 

The investigation also confirmed active data exfiltration, not just beaconing. Collected data was staged under temporary paths, compressed into an archive, split into chunks, and uploaded through HTTP PUT requests using curl with the –data-binary argument. Upload parameters such as upload_id, chunk_index, and total_chunks provided additional hunting opportunities that could be correlated with process, command-line, file, and network telemetry across the attack chain. 

Discovery of additional rotating infrastructure 

To identify related MacSync Stealer infrastructure, Microsoft Defender Experts required multiple endpoint and network behaviors to align before treating a domain as connected. Correlation focused on recurring traits across payload retrieval, C2 check-in, and exfiltration, including process ancestry, command-line patterns, request paths, headers, and upload parameters. Applying this standard linked more than 30 domains, making the domain count an outcome of the behavioral methodology rather than the primary finding. 

The strongest pivots combined network request shape with endpoint execution context. Related infrastructure shared recurring URI patterns such as /curl/, /dynamic?txd=, and /gate?buildtxd=; curl command lines using -k, -s, –max-time, and –data-binary; macOS User-Agent strings; API-key headers; and HTTP PUT uploads that included upload_id, chunk_index, and total_chunks parameters. RST Cloud used recurring URI patterns to surface eleven additional candidate domains and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment. Domains were treated as related when multiple behavioral traits aligned across process, command-line, and network telemetry, reducing reliance on any single domain indicator. 

This finding reinforces a practical defender lesson: rotating infrastructure can weaken static domain blocking and retrospective IOC matching, but repeated request patterns and process behaviors create durable hunting opportunities. Figure 1 shows representative defanged command-line patterns used as pivots across payload retrieval, C2 check-in, and chunked upload activity. 

Figure 1. Representative behavioral pivots associated with MacSync Stealer payload retrieval, C2 check-in, and chunked HTTP PUT exfiltration. 

The same behavioral patterns used to identify additional infrastructure also map to the broader end-to-end activity observed on affected macOS devices. 

Attack chain overview

The observed MacSync Stealer activity followed a fast, script-driven attack chain designed to execute quickly on macOS, collect high-value local data, stage the results, and exfiltrate the archive through rotating web infrastructure. This sequence matters because each phase produces telemetry that can be correlated across processes, command-line, file, and network events. Rather than relying on any individual domain, defenders can track the chain through recurring execution tools, URI paths, staging locations, and upload parameters. 

Figure 2. MacSync Stealer attack chain showing payload retrieval, AppleScript-assisted execution, collection, staging, chunked exfiltration, and cleanup mapped to behavioral hunting opportunities. 

Phase 1: Initial access and payload execution

Observed execution began from an interactive zsh terminal session, where curl retrieved payload content over a /curl/ path before the payload was decoded or unpacked using native utilities such as Base64 and gunzip. This phase is useful for hunting because the combination of user-facing shell activity, curl retrieval, and unpacking behavior is more durable than any single download domain. 

Phase 2: AppleScript-assisted execution

The payload used osascript to run AppleScript-assisted shell commands, blending macOS scripting with Unix command-line tooling. Observed activities included sh, cp, rm, curl, mkdir, and killall operations. This phase creates hunting value when osascript launches shell activity that quickly chains into network communication, staging, or cleanup behavior. 

Phase 3: Discovery and data collection

After execution, the malware collected host and user information, enumerated running processes and system details, and checked for cryptocurrency wallet applications, including Ledger and Trezor-related local artifacts. It then targeted macOS Keychain material, browser Safe Storage keys, browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, extension storage, Safari data, Apple Notes, SSH keys, AWS credentials, Kubernetes configurations, browser profiles, browsing history, and sensitive files from common user directories. The hunting value comes from correlating sensitive data access with the later staging and upload sequence. 

Phase 4: Data staging and compression

Collected data was staged under /tmp/sync* paths and compressed into /tmp/osalogging.zip before uploading. The archive was split into multiple chunks, creating a repeatable staging and transfer pattern that defenders can correlate with preceding collection behavior and subsequent outbound curl traffic. 

Phase 5: Exfiltration over rotating infrastructure

The staged archive was uploaded through rotating infrastructure using curl and HTTP PUT requests. Observed requests included –data-binary, API-key headers, macOS User-Agent string, upload_id values, chunk_index values, and total_chunks parameters. These upload traits confirmed active data exfiltration and provided durable hunting pivots even when domains rotated. 

Phase 6: Cleanup and evidence removal

After exfiltration, the malware removed temporary archives, staging folders, lock files, and other artifacts. Although this cleanup reduced on-disk evidence, the sequence of archive creation, chunked upload, and deletion can still provide a useful behavioral correlation for defenders. 

Mitigation and protection guidance

The attack chain findings point to three mitigation priorities.

1. Organizations should reduce the risk of user-initiated Terminal execution by educating users and using platform controls that interrupt suspicious paste-and-run workflows. Microsoft’s ClickFix reporting recommends educating users not to run commands from untrusted sources and monitoring suspicious Terminal or shell activity associated with these lures. 

2. Defenders should monitor post-execution behavior when initial prevention does not stop activity, including suspicious shell usage, AppleScript-assisted commands, curl-based payload retrieval, credential-store access, temporary staging paths, and archive creation.  

3. Detection should include exfiltration monitoring for HTTP PUT uploads, –data-binary usage, upload identifiers, chunk indexes, total chunk counts, and recurring /gate URI patterns that can reveal active data theft even when C2 domains rotate. 

In macOS 26.4 and later, Apple introduced protections designed to disrupt ClickFix-style attacks, including warnings that can block potentially malicious Terminal pastes and XProtect checks that can prevent detected malicious scripts from running.

When a user attempts to paste a potentially malicious command into Terminal, macOS displays a warning that blocks the paste and explains that scammers may use Terminal instructions to compromise the Mac or the user’s privacy. 

“Possible malware, Paste blocked” 

“Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.” 

Organizations can also follow these recommendations to mitigate threats associated with this threat: 

• Reduce Terminal execution risk. Educate users not to paste or run Terminal commands from untrusted websites, chat messages, apps, files, or phone-based instructions. 

• Monitor suspicious Terminal usage. Alert on unusual Terminal, zsh, or shell sessions that retrieve payloads, decode content, or execute commands shortly after user interaction. 

• Detect native tool abuse. Flag unusual sequences of macOS utilities such as curl, Base64, gunzip, osascript, cp, rm, mkdir, and killall. 

• Hunt for post-execution behavior. Correlate AppleScript-assisted shell activity, curl-based payload retrieval, credential-store access, temporary staging paths, archive creation, and cleanup behavior. 

• Protect credential stores. Detect unauthorized access to Keychain material, browser credential stores, SSH keys, cloud credentials, and sensitive files in common user directories. 

• Monitor data staging. Alert on sensitive artifact collection followed by compression, archive creation, or staging under temporary paths such as /tmp/sync*. 

• Monitor exfiltration patterns. Identify curl-based HTTP PUT uploads that use –data-binary, API-key headers, upload_id, chunk_index, total_chunks, or recurring /gate URI patterns. 

• Restrict suspicious outbound traffic. Block or investigate connections to suspicious, newly registered, or behaviorally related domains while continuing to hunt on request patterns that may persist after domains rotate. 

Microsoft also recommends the following mitigations to reduce the impact of this threat. 

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats. 

• Enable network protection and web protection to help prevent connections to malicious websites, phishing pages, and attacker-controlled infrastructure used for malware delivery, command-and-control communication, and data exfiltration. 

• Enable tamper protection to help prevent unauthorized changes to Microsoft Defender security settings and reduce the risk of attackers disabling or weakening endpoint protections. 

Microsoft Defender XDR detections 

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR 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. 

 Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat, malicious activity, infrastructure, 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 Defender XDR Threat analytics

From ClickFix to code signed: the quiet shift of MacSync Stealer malware. 

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. 

Advanced hunting queries

The following advanced hunting queries can help identify MacSync Stealer behaviors observed with this threat. Use these queries as starting points and tune the time range, device scope, and allowlists for your environment. 

Hunting objective: Identify rotating infrastructure by request shape

This query looks for curl-initiated network activity that matches recurring MacSync Stealer URI paths and upload parameters across domains. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where RemoteUrl has_any ("/curl/", "/dynamic?txd=", "/gate?buildtxd=", "upload_id=", "chunk_index=", "total_chunks=")

Hunting objective: Detect payload retrieval over /curl/ 

This query focuses on initial payload retrieval behavior where curl reaches a /curl/ path, helping identify delivery activity without relying on a specific domain. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where RemoteUrl has "/curl/" 

Hunting objective: Detect chunked exfiltration over curl HTTP PUT 

This query targets active exfiltration behavior by looking for curl HTTP PUT uploads that use –data-binary and chunked upload parameters. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary") 
| where RemoteUrl has_any ("upload_id=", "chunk_index=", "total_chunks=", "/gate?buildtxd=") 

Hunting objective: Find curl command lines with MacSync infrastructure traits 

This query searches endpoint process telemetry for curl command lines containing the headers, URI paths, and upload parameters used as durable behavioral pivots. 

DeviceProcessEvents 
| where FileName =~ "curl" 
| where ProcessCommandLine has_any ("api-key", "/curl/", "/dynamic", "/gate", "--data-binary", "upload_id=", "chunk_index=", "total_chunks=", "%{http_code}") 

Hunting objective: Identify AppleScript-launched shell activity 

This query looks for osascript activity that launches shell commands or native utilities commonly seen in the observed post-execution chain. 

DeviceProcessEvents 
| where FileName =~ "osascript" 
| where ProcessCommandLine has_any ("sh -c", "cp ", "rm ", "curl ", "mkdir ", "killall", "dscl") 

MITRE ATT&CK techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during the MacSync Stealer investigation. The mapping emphasizes the same behavioral pivots used throughout this blog, including shell and AppleScript-assisted execution, payload retrieval, credential and browser data theft, sensitive file collection, staging, chunked exfiltration, cleanup, and rotating infrastructure. 

Execution 

• T1059.004 Command and Scripting Interpreter: Unix Shell | An interactive zsh terminal session was used to run curl commands, decode or unpack payload content with base64 and gunzip, and execute shell commands. 

• T1105 Ingress Tool Transfer | curl downloaded payload content from attacker-controlled infrastructure using recurring payload retrieval paths. 

Discovery 

• T1082 System Information Discovery | The malware collected host and user information during environment discovery. 

• T1057 Process Discovery | The malware enumerated running processes and system configuration before continuing collection and credential-access activity. 

• T1518 Software Discovery | The malware checked for cryptocurrency wallet applications such as Ledger and Trezor. 

Credential Access 

• T1555.001 Credentials from Password Stores: Keychain | The malware created a temporary keychain-grabbing script, attempted to extract browser Safe Storage keys, and accessed or attempted to unlock the macOS Keychain. 

• T1555.003 Credentials from Password Stores: Credentials from Web Browsers | The malware collected browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, and extension storage from Chrome, Brave, Edge, Opera, Vivaldi, Arc, Chromium, and other browsers. 

Collection 

• T1005 Data from Local System | The malware searched Downloads, Documents, and Desktop and collected sensitive file types including PDF, DOCX, TXT, KEY, PEM, KDBX, OVPN, WALLET, and SEED files. 

• T1552.001 Unsecured Credentials: Credentials in Files | The malware harvested SSH keys, AWS credentials, Kubernetes configurations, browser profiles, Apple Notes, Safari data, and other locally stored secrets. 

• T1560.001 Archive Collected Data: Archive via Utility | Collected data was staged under /tmp/sync* and compressed into /tmp/osalogging.zip before upload. 

Command and Control 

• T1071.001 Application Layer Protocol: Web Protocols | C2 communication used web protocols with recurring paths such as /dynamic?txd= and /gate?buildtxd=, macOS User-Agent strings, API-key headers, and rotating domains. 

Exfiltration 

• T1041 Exfiltration Over C2 Channel | Collected data was uploaded to attacker-controlled infrastructure using recurring /gate URI patterns and chunked HTTP PUT requests. 

• T1020 Automated Exfiltration | The malware automated upload activity using curl with HTTP PUT, –data-binary, upload identifiers, chunk_index, and total_chunks parameters. 

• T1030 Data Transfer Size Limits | The archive was split into multiple chunks before upload, as shown by repeated chunk_index and total_chunks parameters in exfiltration requests. 

Defense Evasion 

• T1070.004 Indicator Removal: File Deletion | Temporary archives, staging folders, lock files, and other artifacts were removed after exfiltration. 

• T1140 Deobfuscate/Decode Files or Information | Payload content was decoded or unpacked using base64 and gunzip before execution. 

Behavioral Hunting Pivots 

The following command-line patterns, URL paths, and URL parameters were observed in activity consistent with MacSync Stealer. Use these durable behavioral pivots with process and network context to investigate related activity as infrastructure rotates; then use the point-in-time domain indicators in the IOC section to enrich and validate those findings. 

Indicators of compromise (IOC)

The following domain indicators were observed in activity consistent with MacSync Stealer. Treat them as point-in-time evidence: use them to enrich and validate matches from the behavioral pivots above, and correlate any hits with process and network context because related infrastructure may rotate quickly. 

References

References used for external context and related defensive guidance: 

• MacSync Stealer: C2 Infrastructure Rotation – RST Cloud. RST Cloud, May 8, 2026. 

• ClickFix campaign uses fake macOS utilities lures to deliver …. Microsoft, May 6, 2026. 

• Protecting against malware in macOS – Apple Support  December 19, 2024 

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

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.   

• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post Hunting MacSync Stealer infrastructure through behavioral pivots appeared first on Microsoft Security Blog.

MacSync Stealer is a macOS-focused information stealer that relies on changing infrastructure to deliver payloads, communicate with compromised devices, and exfiltrate data. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control (C2) replacement after public disclosure.

Microsoft Defender Experts expanded that view by correlating recurring endpoints and network behaviors across the activity. This behavior-led approach connected more than 30 domains and showed that the infrastructure supported more than C2 communication, extending into active collection, staging, and exfiltration. The findings demonstrate that although domains may rotate quickly, repeated execution patterns, request characteristics, staging behavior, and upload methods provide defenders with more durable opportunities to investigate MacSync Stealer activity. 

Activity overview 

Microsoft Defender Experts reviewed endpoint and network telemetry to determine which MacSync Stealer behaviors persisted as infrastructure changed. The investigation followed the activity from C2 communication through collection, staging, and exfiltration, using recurring technical traits to connect activity across rotating domains. Execution began from an interactive shell session consistent with ClickFix social engineering, where users are tricked into pasting or running commands in Terminal. The shell session used curl to retrieve attacker-controlled payload content, followed by script-driven execution and outbound communication. 

After execution, the malware communicated with attacker-controlled infrastructure using recurring URI paths, macOS User-Agent strings, API-key headers, and curl command-line options. These request traits became durable behavioral pivots because they remained consistent even as domains changed. The activity then progressed into collection behavior targeting macOS Keychain material, browser data, locally stored credentials, cloud and Secure Shell (SSH) credentials, and sensitive files from common user directories. 

The investigation also confirmed active data exfiltration, not just beaconing. Collected data was staged under temporary paths, compressed into an archive, split into chunks, and uploaded through HTTP PUT requests using curl with the –data-binary argument. Upload parameters such as upload_id, chunk_index, and total_chunks provided additional hunting opportunities that could be correlated with process, command-line, file, and network telemetry across the attack chain. 

Discovery of additional rotating infrastructure 

To identify related MacSync Stealer infrastructure, Microsoft Defender Experts required multiple endpoint and network behaviors to align before treating a domain as connected. Correlation focused on recurring traits across payload retrieval, C2 check-in, and exfiltration, including process ancestry, command-line patterns, request paths, headers, and upload parameters. Applying this standard linked more than 30 domains, making the domain count an outcome of the behavioral methodology rather than the primary finding. 

The strongest pivots combined network request shape with endpoint execution context. Related infrastructure shared recurring URI patterns such as /curl/, /dynamic?txd=, and /gate?buildtxd=; curl command lines using -k, -s, –max-time, and –data-binary; macOS User-Agent strings; API-key headers; and HTTP PUT uploads that included upload_id, chunk_index, and total_chunks parameters. RST Cloud used recurring URI patterns to surface eleven additional candidate domains and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment. Domains were treated as related when multiple behavioral traits aligned across process, command-line, and network telemetry, reducing reliance on any single domain indicator. 

This finding reinforces a practical defender lesson: rotating infrastructure can weaken static domain blocking and retrospective IOC matching, but repeated request patterns and process behaviors create durable hunting opportunities. Figure 1 shows representative defanged command-line patterns used as pivots across payload retrieval, C2 check-in, and chunked upload activity. 

Figure 1. Representative behavioral pivots associated with MacSync Stealer payload retrieval, C2 check-in, and chunked HTTP PUT exfiltration. 

The same behavioral patterns used to identify additional infrastructure also map to the broader end-to-end activity observed on affected macOS devices. 

Attack chain overview

The observed MacSync Stealer activity followed a fast, script-driven attack chain designed to execute quickly on macOS, collect high-value local data, stage the results, and exfiltrate the archive through rotating web infrastructure. This sequence matters because each phase produces telemetry that can be correlated across processes, command-line, file, and network events. Rather than relying on any individual domain, defenders can track the chain through recurring execution tools, URI paths, staging locations, and upload parameters. 

Figure 2. MacSync Stealer attack chain showing payload retrieval, AppleScript-assisted execution, collection, staging, chunked exfiltration, and cleanup mapped to behavioral hunting opportunities. 

Phase 1: Initial access and payload execution

Observed execution began from an interactive zsh terminal session, where curl retrieved payload content over a /curl/ path before the payload was decoded or unpacked using native utilities such as Base64 and gunzip. This phase is useful for hunting because the combination of user-facing shell activity, curl retrieval, and unpacking behavior is more durable than any single download domain. 

Phase 2: AppleScript-assisted execution

The payload used osascript to run AppleScript-assisted shell commands, blending macOS scripting with Unix command-line tooling. Observed activities included sh, cp, rm, curl, mkdir, and killall operations. This phase creates hunting value when osascript launches shell activity that quickly chains into network communication, staging, or cleanup behavior. 

Phase 3: Discovery and data collection

After execution, the malware collected host and user information, enumerated running processes and system details, and checked for cryptocurrency wallet applications, including Ledger and Trezor-related local artifacts. It then targeted macOS Keychain material, browser Safe Storage keys, browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, extension storage, Safari data, Apple Notes, SSH keys, AWS credentials, Kubernetes configurations, browser profiles, browsing history, and sensitive files from common user directories. The hunting value comes from correlating sensitive data access with the later staging and upload sequence. 

Phase 4: Data staging and compression

Collected data was staged under /tmp/sync* paths and compressed into /tmp/osalogging.zip before uploading. The archive was split into multiple chunks, creating a repeatable staging and transfer pattern that defenders can correlate with preceding collection behavior and subsequent outbound curl traffic. 

Phase 5: Exfiltration over rotating infrastructure

The staged archive was uploaded through rotating infrastructure using curl and HTTP PUT requests. Observed requests included –data-binary, API-key headers, macOS User-Agent string, upload_id values, chunk_index values, and total_chunks parameters. These upload traits confirmed active data exfiltration and provided durable hunting pivots even when domains rotated. 

Phase 6: Cleanup and evidence removal

After exfiltration, the malware removed temporary archives, staging folders, lock files, and other artifacts. Although this cleanup reduced on-disk evidence, the sequence of archive creation, chunked upload, and deletion can still provide a useful behavioral correlation for defenders. 

Mitigation and protection guidance

The attack chain findings point to three mitigation priorities.

1. Organizations should reduce the risk of user-initiated Terminal execution by educating users and using platform controls that interrupt suspicious paste-and-run workflows. Microsoft’s ClickFix reporting recommends educating users not to run commands from untrusted sources and monitoring suspicious Terminal or shell activity associated with these lures. 

2. Defenders should monitor post-execution behavior when initial prevention does not stop activity, including suspicious shell usage, AppleScript-assisted commands, curl-based payload retrieval, credential-store access, temporary staging paths, and archive creation.  

3. Detection should include exfiltration monitoring for HTTP PUT uploads, –data-binary usage, upload identifiers, chunk indexes, total chunk counts, and recurring /gate URI patterns that can reveal active data theft even when C2 domains rotate. 

In macOS 26.4 and later, Apple introduced protections designed to disrupt ClickFix-style attacks, including warnings that can block potentially malicious Terminal pastes and XProtect checks that can prevent detected malicious scripts from running.

When a user attempts to paste a potentially malicious command into Terminal, macOS displays a warning that blocks the paste and explains that scammers may use Terminal instructions to compromise the Mac or the user’s privacy. 

“Possible malware, Paste blocked” 

“Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.” 

Organizations can also follow these recommendations to mitigate threats associated with this threat: 

• Reduce Terminal execution risk. Educate users not to paste or run Terminal commands from untrusted websites, chat messages, apps, files, or phone-based instructions. 

• Monitor suspicious Terminal usage. Alert on unusual Terminal, zsh, or shell sessions that retrieve payloads, decode content, or execute commands shortly after user interaction. 

• Detect native tool abuse. Flag unusual sequences of macOS utilities such as curl, Base64, gunzip, osascript, cp, rm, mkdir, and killall. 

• Hunt for post-execution behavior. Correlate AppleScript-assisted shell activity, curl-based payload retrieval, credential-store access, temporary staging paths, archive creation, and cleanup behavior. 

• Protect credential stores. Detect unauthorized access to Keychain material, browser credential stores, SSH keys, cloud credentials, and sensitive files in common user directories. 

• Monitor data staging. Alert on sensitive artifact collection followed by compression, archive creation, or staging under temporary paths such as /tmp/sync*. 

• Monitor exfiltration patterns. Identify curl-based HTTP PUT uploads that use –data-binary, API-key headers, upload_id, chunk_index, total_chunks, or recurring /gate URI patterns. 

• Restrict suspicious outbound traffic. Block or investigate connections to suspicious, newly registered, or behaviorally related domains while continuing to hunt on request patterns that may persist after domains rotate. 

Microsoft also recommends the following mitigations to reduce the impact of this threat. 

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats. 

• Enable network protection and web protection to help prevent connections to malicious websites, phishing pages, and attacker-controlled infrastructure used for malware delivery, command-and-control communication, and data exfiltration. 

• Enable tamper protection to help prevent unauthorized changes to Microsoft Defender security settings and reduce the risk of attackers disabling or weakening endpoint protections. 

Microsoft Defender XDR detections 

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR 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. 

 Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat, malicious activity, infrastructure, 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 Defender XDR Threat analytics

From ClickFix to code signed: the quiet shift of MacSync Stealer malware. 

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. 

Advanced hunting queries

The following advanced hunting queries can help identify MacSync Stealer behaviors observed with this threat. Use these queries as starting points and tune the time range, device scope, and allowlists for your environment. 

Hunting objective: Identify rotating infrastructure by request shape

This query looks for curl-initiated network activity that matches recurring MacSync Stealer URI paths and upload parameters across domains. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where RemoteUrl has_any ("/curl/", "/dynamic?txd=", "/gate?buildtxd=", "upload_id=", "chunk_index=", "total_chunks=")

Hunting objective: Detect payload retrieval over /curl/ 

This query focuses on initial payload retrieval behavior where curl reaches a /curl/ path, helping identify delivery activity without relying on a specific domain. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where RemoteUrl has "/curl/" 

Hunting objective: Detect chunked exfiltration over curl HTTP PUT 

This query targets active exfiltration behavior by looking for curl HTTP PUT uploads that use –data-binary and chunked upload parameters. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary") 
| where RemoteUrl has_any ("upload_id=", "chunk_index=", "total_chunks=", "/gate?buildtxd=") 

Hunting objective: Find curl command lines with MacSync infrastructure traits 

This query searches endpoint process telemetry for curl command lines containing the headers, URI paths, and upload parameters used as durable behavioral pivots. 

DeviceProcessEvents 
| where FileName =~ "curl" 
| where ProcessCommandLine has_any ("api-key", "/curl/", "/dynamic", "/gate", "--data-binary", "upload_id=", "chunk_index=", "total_chunks=", "%{http_code}") 

Hunting objective: Identify AppleScript-launched shell activity 

This query looks for osascript activity that launches shell commands or native utilities commonly seen in the observed post-execution chain. 

DeviceProcessEvents 
| where FileName =~ "osascript" 
| where ProcessCommandLine has_any ("sh -c", "cp ", "rm ", "curl ", "mkdir ", "killall", "dscl") 

MITRE ATT&CK techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during the MacSync Stealer investigation. The mapping emphasizes the same behavioral pivots used throughout this blog, including shell and AppleScript-assisted execution, payload retrieval, credential and browser data theft, sensitive file collection, staging, chunked exfiltration, cleanup, and rotating infrastructure. 

Execution 

• T1059.004 Command and Scripting Interpreter: Unix Shell | An interactive zsh terminal session was used to run curl commands, decode or unpack payload content with base64 and gunzip, and execute shell commands. 

• T1105 Ingress Tool Transfer | curl downloaded payload content from attacker-controlled infrastructure using recurring payload retrieval paths. 

Discovery 

• T1082 System Information Discovery | The malware collected host and user information during environment discovery. 

• T1057 Process Discovery | The malware enumerated running processes and system configuration before continuing collection and credential-access activity. 

• T1518 Software Discovery | The malware checked for cryptocurrency wallet applications such as Ledger and Trezor. 

Credential Access 

• T1555.001 Credentials from Password Stores: Keychain | The malware created a temporary keychain-grabbing script, attempted to extract browser Safe Storage keys, and accessed or attempted to unlock the macOS Keychain. 

• T1555.003 Credentials from Password Stores: Credentials from Web Browsers | The malware collected browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, and extension storage from Chrome, Brave, Edge, Opera, Vivaldi, Arc, Chromium, and other browsers. 

Collection 

• T1005 Data from Local System | The malware searched Downloads, Documents, and Desktop and collected sensitive file types including PDF, DOCX, TXT, KEY, PEM, KDBX, OVPN, WALLET, and SEED files. 

• T1552.001 Unsecured Credentials: Credentials in Files | The malware harvested SSH keys, AWS credentials, Kubernetes configurations, browser profiles, Apple Notes, Safari data, and other locally stored secrets. 

• T1560.001 Archive Collected Data: Archive via Utility | Collected data was staged under /tmp/sync* and compressed into /tmp/osalogging.zip before upload. 

Command and Control 

• T1071.001 Application Layer Protocol: Web Protocols | C2 communication used web protocols with recurring paths such as /dynamic?txd= and /gate?buildtxd=, macOS User-Agent strings, API-key headers, and rotating domains. 

Exfiltration 

• T1041 Exfiltration Over C2 Channel | Collected data was uploaded to attacker-controlled infrastructure using recurring /gate URI patterns and chunked HTTP PUT requests. 

• T1020 Automated Exfiltration | The malware automated upload activity using curl with HTTP PUT, –data-binary, upload identifiers, chunk_index, and total_chunks parameters. 

• T1030 Data Transfer Size Limits | The archive was split into multiple chunks before upload, as shown by repeated chunk_index and total_chunks parameters in exfiltration requests. 

Defense Evasion 

• T1070.004 Indicator Removal: File Deletion | Temporary archives, staging folders, lock files, and other artifacts were removed after exfiltration. 

• T1140 Deobfuscate/Decode Files or Information | Payload content was decoded or unpacked using base64 and gunzip before execution. 

Behavioral Hunting Pivots 

The following command-line patterns, URL paths, and URL parameters were observed in activity consistent with MacSync Stealer. Use these durable behavioral pivots with process and network context to investigate related activity as infrastructure rotates; then use the point-in-time domain indicators in the IOC section to enrich and validate those findings. 

Indicators of compromise (IOC)

The following domain indicators were observed in activity consistent with MacSync Stealer. Treat them as point-in-time evidence: use them to enrich and validate matches from the behavioral pivots above, and correlate any hits with process and network context because related infrastructure may rotate quickly. 

References

References used for external context and related defensive guidance: 

• MacSync Stealer: C2 Infrastructure Rotation – RST Cloud. RST Cloud, May 8, 2026. 

• ClickFix campaign uses fake macOS utilities lures to deliver …. Microsoft, May 6, 2026. 

• Protecting against malware in macOS – Apple Support  December 19, 2024 

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

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.   

• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post Hunting MacSync Stealer infrastructure through behavioral pivots appeared first on Microsoft Security Blog.