As early as September 2026, Storm-0940, a China-state aligned actor, used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries. Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours. Microsoft assesses that Storm-0940 was responsible for the recently disclosed ConnectWise supply chain compromise of a multi-tenant application.

This activity demonstrates how threat actors are integrating agentic AI into existing offensive security workflows and allows them to scale their operations exponentially. Agents are not constrained by factors affecting humans – they can work around the clock, on weekends, and on holidays and attempt multiple breach paths simultaneously enabling significantly reduced time from selecting a target to achieving objectives, increasing the speed and impact of complex attacks like supply chain compromises.

Storm-0940’s use of ARTEX accelerated the speed of compromised application abuse to authenticate to Microsoft 365 customer environments through applications that had already been granted access. This allowed the threat actor to operate without requiring an interactive user sign-in. In multiple affected environments, Microsoft observed AI-accelerated follow-on activity through Microsoft Graph, including reconnaissance, application credential changes, and attempts to modify privileges that could enable expanded or persistent access. The activity conducted by the threat actor through the usage of ARTEX framework did not result from a compromise of or a vulnerability in Microsoft corporate systems, products, or services.

Although Microsoft identified Storm-0940-initiated authentication and follow-on activity in multiple customer environments, the presence of an affected application or successful threat actor authentication does not necessarily indicate that customer data was accessed or exfiltrated. Microsoft Defender XDR provides detections and hunting queries for suspicious Microsoft Graph activity and activity associated with known threat infrastructure. Customers should review service principal sign-ins, investigate unexpected application credential or privilege changes, and follow ConnectWise’s published containment guidance while preserving relevant evidence for investigation. For a full list of detections please see the detections section.

What’s happening

Storm-0940 is a China-state aligned actor (with no known industry aliases) that has been active since 2021 and targets organizations across multiple industries for data theft. The actor has historically gained initial access using password spraying and exploitation of internet-facing applications, before using compromised accounts to move through targeted environments. In cloud environments, the actor has also established persistence by adding credentials to existing OAuth applications, allowing continued access to Microsoft 365 resources. The actor has used these applications to access and exfiltrate email and other data through Microsoft Graph.

As early as September 2026, Storm-0940 used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries. These include aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, technology, and think tanks and non-profits. During the ConnectWise supply chain compromise, Storm-0940 used ARTEX to accelerate scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims.

Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours. When automated with AI, these activities generate a large volume of traffic and log data that may generate alerts. However, the speed of the activity allows very little time for Defenders to respond to those alerts and remediate the actor’s access in a coordinated fashion. Storm-0940’s activity illustrates how a threat actor with a broad target set can use an agentic AI tool and privileged authentication material to quickly attempt to compromise many organizations. While the majority of the targeting wasn’t successful, Storm-0940 achieved privileged cloud persistence at many organizations in a brief time.

What is ARTEX?

ARTEX is an open-source penetration testing framework that can use any AI model to automate a variety of offensive security workflows. The ARTEX framework is a multi-agent LLM system written in GO with a Next.js frontend. While the UI and generated output default to English, the framework can be switched to Korean, Mandarin, Spanish, or Japanese. ARTEX is a system of LLM-driven agents that run an autonomous penetration test from reconnaissance through data exfiltration with little needed human interaction. The agents then accumulate the discovered assets and vulnerabilities into a graph during the penetration test. In October 2026, public reporting noted that the ARTEX framework was being used by threat actors, such as the personal data breaches targeting Korean financial institutions. Microsoft Threat Intelligence has identified threat actors across multiple geographic regions leveraging the ARTEX framework.

ConnectWise published an initial advisory on October 16, 2026, and subsequently expanded its disclosures and containment guidance. The advisory details ConnectWise’s investigation of attempted unauthorized access associated with Cloud Backup. Following the unauthorized access, Storm-0940 used ARTEX to attempt to sign-in to more than 2,250 tenants. While OAuth application abuse is a typical part of Storm-0940’s toolset, in this case the actor used ARTEX to accelerate the activity to machine speed.

Password Spraying

Between October 10 and 14, 2026, Storm-0940 infrastructure at 144.172.64[.]99 conducted an automated cross-tenant password-spray campaign targeting 327 accounts across eight organizations to gain access to Microsoft 365 and Exchange Online. During this large campaign, Microsoft telemetry captured 151,000+ failed logon events, with activity peaking on October 11 at 2,900 failures per minute and concentrating more than 111,000 failures into a single day. The campaign blended broad, low-rate account spraying with sustained, high-volume authentication attempts against selected identities; 48 accounts received more than 1,000 failures, and lockout responses represented nearly 98% of all activity. Despite the scale, no successful authentication, token issuance, Graph call, or directory change was observed.

Downstream customer access

On October 15, immediately after this notable activity, public reports of the compromise of the popular cloud backup application ConnectWise started to surface with direct references to indicators of compromise matching the same network range observed for the earlier password-spray campaign (144.172.64.x). An advisory from the affected cloud backup vendor posted on October 16 shared later additional indicators with one IP address matching exactly the 144.172.64[.]99 infrastructure responsible for the earlier password-spray campaign.

Additionally, after acquiring control of the identities of multiple ConnectWise cloud applications, the AI agents operating on behalf of the threat actor continued to use the same IP range to authenticate to customer environments using the illicit access acquired through these stolen app credentials, effectively taking advantage of the already established trust by these apps within a tenant. In some of these environments, the AI agents (on behalf of the threat actor) progressed beyond authentication to Microsoft Graph and directory operations, including reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups, and privileged roles. Microsoft identified multiple customer environments with evidence of follow-on activity, highlighting how a compromised third-party application with high privileges could provide access beyond its originally intended purpose.

The application credential modification made by Storm-0940’s associated agents in the targeted victims’ environments can lead to persistence through other identities, credentials, and cloud services. These changes can remain active as a backdoor even after the original compromised application is mediated. Organizations should examine service principal sign-ins alongside subsequent Microsoft Graph activity, directory changes, and resource access, correlating suspicious events with authorized administrative activity. The presence of an affected application, or even successful authentication, does not necessarily indicate unauthorized data access or data exfiltration.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

Immediate actions

• Keep affected ConnectWise application connections disabled until ConnectWise provides formal restoration instructions.
• Do not delete enterprise applications as the first response. Preserve configuration and evidence before making irreversible changes.
• Inventory all four application IDs listed in this profile and record the local service-principal Object ID in each tenant.
• Review every Microsoft 365 tenant where the affected applications are currently or were previously installed or authorized, even if the integration is no longer in use. Search by application ID rather than display name.
• Preserve available Microsoft Entra sign-in and audit records, Microsoft Purview Audit records, SIEM data, and previously configured Microsoft Graph telemetry. Do not delay urgent containment while waiting for exports.
• Review activity starting from at least October 15, 2026. Where records are available, extend service-principal sign-in review to October 1 and investigate earlier related activity, including failed authentications and volume anomalies.
• Review successful and failed service-principal sign-ins separately. Investigate unfamiliar sources and activity outside expected vendor infrastructure; do not limit review to the published IPs.
• Review Microsoft Entra audit records for application or service-principal credential additions; new applications, service principals, or owners; app-role assignments and consent grants; privileged role assignments; and changes to users, groups, authentication methods, or Conditional Access. On confirmed suspicious activity, revoke unnecessary permissions and rotate credentials.
• Review Microsoft 365 audit records to look for reconnaissance activities like listing directories, permissions, and approvals coming from unusual IPs.
• Review Microsoft 365 audit records for unusual mail or file access, downloads, forwarding, inbox or transport rules, delegated mailbox permissions, and related resource activity.
• Preserve evidence, then have an appropriately authorized responder remove confirmed unauthorized credentials, grants, owners, assignments, and identities.

Additional recommendations

• Threat actor misuse of AI accelerates risk across enterprise environments by amplifying existing threats such as exploitation of vulnerabilities, phishing, malware threats, and insider activity. To help organizations stay ahead of AI-enabled threat activity, Microsoft has introduced the Security Dashboard for AI. The dashboard provides users with a unified view of AI security posture by aggregating security, identity, and data risk across Microsoft Defender, Microsoft Entra, and Microsoft Purview. This allows organizations to understand what AI assets exist in their environment, recognize emerging risk patterns, and prioritize governance and security across AI agents, applications, and platforms. To learn more about the Microsoft Security Dashboard for AI see: Assess your organization’s AI risk with Microsoft Security Dashboard for AI (Preview).
• Enable threat protection for AI services in Microsoft Defender for Cloud to identify threats to generative AI applications in real time and for assistance in responding to security issues.
• Apply least privilege to multi-tenant application permissions and consent grants.
• Monitor credential additions, privilege assignments, and anomalous app-only activity, especially to applications with high privileged permissions and scopes.
• Verify that vendor credential rotation and any tenant-level remediation eliminated remaining unauthorized access.

Assess the operational effect on backup and restore workflows and follow current ConnectWise restoration guidance.

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.

Microsoft Defender for Cloud Apps detections

Microsoft Defender for Cloud (Microsoft Defender for Key Vault)

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR Threat analytics

Activity Profile: AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise

Indicators of compromise (IOC)

Advanced hunting

NOTE: The following sample queries let you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential indicators related to this campaign 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.

Microsoft Defender XDR advanced hunting

1- OAuthAppInfo → Is the affected app present, enabled, and what permissions does it hold?

Start with OAuthAppInfo to determine whether any of the affected ConnectWise applications are present in the tenant and understand the access they have been granted. The query identifies the application and its tenant-specific service principal, whether it is enabled, its privilege level, consent information, and the individual permissions assigned to it.

This establishes the customer’s potential exposure and gives investigators the ServicePrincipalId needed for further hunting. A match does not mean the application was abused, only that it is present and potentially had access, so the next step is to determine whether the service principal was actually used. Run query

let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
OAuthAppInfo
| where OAuthAppId in (ConnectWiseApps)
| mv-expand Permission = Permissions
| extend
    PermissionName = tostring(Permission.PermissionName),
    TargetApp = tostring(Permission.TargetAppDisplayName),
    TargetAppId = tostring(Permission.TargetAppId),
    PermissionType = tostring(Permission.PermissionType),
    PermissionPrivilegeLevel = tostring(Permission.PrivilegeLevel),
    UsageStatus = tostring(Permission.UsageStatus)
| project
    AppName,
    OAuthAppId,
    ServicePrincipalId,
    AppStatus,
    PrivilegeLevel,
    IsAdminConsented,
    PermissionName,
    PermissionType,
    PermissionPrivilegeLevel,
    TargetApp,
    TargetAppId,
    UsageStatus
| order by AppName asc, PermissionPrivilegeLevel desc

2 – EntraIdSpnSignInEvents + GraphAPIAuditEvents → Did the service principal authenticate, and what Microsoft Graph activity followed?

Use this query to investigate service-principal sign-ins and Microsoft Graph API activity associated with the identified ConnectWise applications and suspicious IP addresses, starting October 13, 2026.

The query combines both event types into a chronological view, helping defenders identify suspicious authentication and related Graph operations, including potential credential changes, privilege modifications, and unusual resource access. Remove the IP filter for broader hunting. Results require further correlation, as authentication alone does not establish compromise. Run query

let Apps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "0de14c77-b9b0-4137-9360-34878a929827"   
]);
let IPs = dynamic(["144.172.64.60", "144.172.64.99", "144.172.64.128"]);
union kind=outer
    (EntraIdSpnSignInEvents
     | extend EventType = "Sign-in"),
    (GraphAPIAuditEvents
     | extend EventType = "Graph API", IPAddress = IpAddress)
| where Timestamp >= datetime(2026-10-13)
| where ApplicationId in (Apps)
| where IPAddress in (IPs) // Comment out for broader hunting
| project-away IpAddress
| order by Timestamp asc

3 – Bulk Key Vault secret reads by a single identity across multiple vaults

Run query

CloudKeyVaultEvents
| where Timestamp > ago(14d)
| where ActivityName == "SecretGet" and HttpStatusCode == 200
| summarize SecretGets = count(), VaultCount = dcount(AzureResourceId),
   IPs = make_set(IPAddress, 20)
   by bin(Timestamp, 15m), AccountObjectId, AccountTenantId
| where SecretGets >= 20 and VaultCount >= 3

4 – Key Vault, Storage and ARM activity from the IOC IPs

Run query

let IPs = dynamic(["144.172.64.128","144.172.64.60","144.172.64.99"]);
union
 (CloudKeyVaultEvents | where IPAddress in (IPs) | extend Source = "KeyVault", Operation = ActivityName),
 (CloudStorageAggregatedEvents | where IPAddress in (IPs) | extend Source = "Storage", Operation = tostring(OperationNamesList)),
 (CloudAuditEvents | where IPAddress in (IPs) | extend Source = "ARM", Operation = OperationName)
| where Timestamp > ago(30d)
| project Timestamp, Source, IPAddress, Operation, AzureResourceId
| order by Timestamp asc

Sentinel hunting queries

1-SigninLogs → Did a service principal authenticate, from where, and against what resource?

Use SigninLogs to determine whether an affected application identity actually authenticated. This moves the investigation from potential exposure to observed authentication, allowing defenders to examine the application and service principal alongside the source IP address, geographic information, authentication result, and resource being accessed. Investigators should evaluate these sign-ins against the application’s expected activity and look for unusual source infrastructure, resources, or authentication patterns before pivoting into subsequent Graph activity. Run query

let IPIndicators = dynamic([
    "144.172.64.60",  // IP Indicator
    "144.172.64.99",  // IP Indicator
    "144.172.64.128"  // IP Indicator
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
SigninLogs
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
//| where IPAddress in (IPIndicators) // Comment out to review all activity from these applications
| project
    TimeGenerated,
    AppId,
    ServicePrincipalName,
    ResourceDisplayName,
    ResourceId,
    IPAddress,
    CorrelationId
| order by TimeGenerated asc

2 – MicrosoftGraphActivityLogs → What observable Graph API activity followed?

Use MicrosoftGraphActivityLogs to investigate observable Microsoft Graph activity following authentication. This query allows defenders to pivot on the affected ApplicationId or tenant-specific ServicePrincipalId and examine details such as the request URI, HTTP method, response status, scopes, source IP address, and target workload. This helps establish what Graph activity occurred after the service principal authenticated and provides additional context around the resources the application attempted to access.

Importantly, the absence of results should not be treated as confirmation that no access occurred; Graph API telemetry should be considered alongside the application permissions and service principal authentication activity identified in the previous hunting steps. Run query

let IPIndicators = dynamic([
    "144.172.64.60",  // IP Indicator
    "144.172.64.99",  // IP Indicator
    "144.172.64.128"  // IP Indicator
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
MicrosoftGraphActivityLogs 
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
| where IPAddress in (IPIndicators) // Comment out to review all Graph activity from these applications
| project
    TimeGenerated,
    AppId,
    IPAddress,
    RequestMethod,
    RequestUri,
    ResponseStatusCode,
    Scopes,
    ClientRequestId,
    OperationId,
    RequestId
| order by TimeGenerated asc

MITRE ATT&CK Techniques observed

This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Reconnaissance

• T1595 Active Scanning | Scanning cloud resources to identify targets for compromise.

Initial Access

• T1078.004 Valid Accounts: Cloud Accounts | Using compromised cloud accounts to obtain access.
• T1195 Supply Chain Compromise | Compromising a multi-tenant OAuth application to access downstream customer environments.
• T1199 Trusted Relationship | Access to customer environments through a compromised, trusted third-party application

Privilege Escalation

• T1098.003 Account Manipulation: Additional Cloud Roles | Addition of privileged cloud role assignments, including self assignment of global admin from one of the ConnectWise Management Application.
• T1098.001 Account Manipulation: Additional Cloud Credentials | Addition or modification of application credentials.

Credential Access

• T1528 Steal Application Access Token | Compromising OAuth application authentication material.
• T1555.006 Cloud Secrets Management Stores | Bulk secret reads from Azure Key Vaults

Discovery

• T1087.004 Account Discovery: Cloud Account | Identifying privileged cloud accounts for further targeting.
• T1580 Cloud Infrastructure Discovery | Mapping cloud infrastructure for further targeting.

References

• ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks. Huntress
• ConnectWise Trust Center – Cloud Backup advisories. ConnectWise (accessed 2026-10-19).
• ConnectWise Cloud Backup technical investigation and remediation guide. ConnectWise (accessed 2026-10-19).

Learn more

• For guidance on investigating and responding to compromised applications, see Compromised and malicious applications investigation.
• Learn how to investigate app-only authentication with Service principal sign-in logs.
• Review application credentials, permissions, role assignments, and configuration changes in Microsoft Entra security operations for applications.
• Learn how to proactively investigate threats with Advanced hunting in Microsoft Defender XDR.
• Explore the OAuthAppInfo and GraphAPIAuditEvents advanced hunting tables.
• Learn how to find Microsoft 365 activity with Search the audit log.
• Review guidance for reducing excessive application permissions in Secure applications using least privilege.
• 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 AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise appeared first on Microsoft Security Blog.

Over the past year, Microsoft uncovered a Chinese-language cybercriminal ecosystem, an interconnected network of phishing kit operators, developers, and an illicit marketplace selling tools and infrastructure for large-scale phishing, enabling cybercriminal operations worldwide.

Threat actors purchased and used these tools and infrastructure, including phishing kits and access to compromised or fraudulent Microsoft or Google cloud environments and related credentials, to target organizations across the healthcare, financial services, wholesale distribution, and information technology (IT) sectors in Japan, the United States, Australia, and India. In collaboration with law enforcement agencies and other partners worldwide, Microsoft’s Digital Crimes Unit (DCU) facilitated a disruption of the ecosystem’s primary developers and infrastructure.

Microsoft’s research into one phishing kit unraveled a larger ecosystem, including the phishing kit developers, an infrastructure dealer, and the threat actors who buy from both. In this blog, we examine several phishing kits marketed and sold through YAM Store, an underground marketplace tracked by Microsoft as Storm-3119. We share our analysis of the technical aspects of this Chinese-language phishing kit ecosystem, the shared infrastructure, provisioning methods, and downstream activity by threat actors using these tools.

Uncovering the shadow world of a phishing kit ecosystem

Microsoft, alongside industry partner Resecurity, identified three phishing kits sold through the YAM Store that make up this Chinese-language cybercriminal network: CoGUI (also known as NX or FA), Haozi (also known as Phoenix), and Iron Man System. Microsoft tracks the cluster of activity and the developers behind all three phishing kits as Storm-2990. Since January 2026, the threat actors behind these kits have been responsible for facilitating the sending of over one billion phishing emails and SMS messages to over 75 thousand organizations worldwide.

Microsoft assesses with high confidence that these phishing kits were developed by Chinese-speaking threat actors, and, despite their distinct branding and separate Telegram-based sales channels, exhibit highly similar capabilities and functionality. The phishing kits provide phishing templates impersonating legitimate brands and organizations (including government, financial, and logistics) worldwide, and enable criminal actors to facilitate high-volume phishing and credential stealing operations. The similarity in their infrastructure and overlap in activity suggest either shared development origins, code reuse, or close collaboration among their developers.

These phishing kits have been advertised through YAM Store, first CoGUI and Haozi, followed by Iron Man System starting in June 2026. YAM Store and affiliated phishing kit companies accepted payments through cryptocurrency, including USDT and Ethereum, adding another layer to conceal illicit activity. The scale and proliferation of this ecosystem demonstrate how readily available criminal infrastructure can lower the barrier to entry, enabling less skilled cybercriminals to target organizations at scale and contribute to fraud losses.

By mapping the relationship between YAM Store and these phishing kits, we provide insight into the commercial infrastructure that supports modern phishing operations.

Storm-3119: YAM Store, the power broker

YAM Store is an initial access broker (IAB) that sells infrastructure using compromised or fraudulently obtained environments in providers like Microsoft and Google. The marketplace offers a variety of infrastructure based on age, subscription type, and environment types such as education (.edu) or non-profit (.org).

The YAM Store marketplace provides cybercriminals with a platform to purchase fraudulently acquired Microsoft and Google domains associated with legitimate, expired, or previously used organization numbers, allowing actors to use seemingly legitimate infrastructure and obtain workspaces at relatively low cost. Storm-3119 uses automation to identify expired environment or organization names and leverages legitimate customer information associated with them to help circumvent existing detections.

Anatomy of YAM Store operations: How Storm-3119 acquires, controls, and monetizes infrastructure

During this investigation, Microsoft uncovered a five-stage attack pipeline often used in Storm-3119’s operations. YAM Store functions as an access broker, an intermediary that hijacks Microsoft 365 and Azure for Education tenants and resells the stolen accounts, licenses, and storage as a service to downstream operations, including the phishing kits tracked as Storm-2990. The pipeline below describes the supply side of that business: how the actor acquires, controls, and monetizes compromised environments.

Stage 1 – Reconnaissance: Storm-3119 conducts automated reconnaissance of target environments. The actor uses Flask, a lightweight Python web framework, to covertly identify and profile cloud-enabled organizations. The tooling is designed to discover Microsoft 365 tenants, assess enrollment opportunities, gather licensing and Azure cloud information, and perform these activities anonymously through Tor infrastructure.

Stage 2 – Environment takeover and app-only admin panels: Once a viable environment is identified, the threat actor centralizes associated information in an actor-controlled platform used to administer compromised Microsoft 365 environments. This platform is a separate set of administrative panels (implemented in PHP, Java/Spring, and Cloudflare Workers) that lets the operator maintain, monetize, and expand access using stolen application credentials. Leveraging the compromised environment’s client secret through an application-only authentication flow, the panel performs full directory control: it resets passwords silently (without forcing a change at next sign-in), assigns education licenses, and grants privileged attributes that the actor can later monetize. Because this access is application-level rather than tied to a single user session, the resulting persistence is more durable, more scalable, and harder to detect.

Stage 3 – Storage and resource abuse: With the stolen privileged credentials, the threat actor signs in to a compromised Global Administrator account and self-provisions the PnP Management Shell service principal, which represents the actor’s application inside the compromised tenant. Through this service principal, the threat actor grants themselves broad Microsoft Graph permissions, including read and write access to directory data and AppCatalog.ReadWrite.All, along with full control over the SharePoint API. The actor then abuses the compromised tenant’s SharePoint and OneDrive as bulk hosting and converts the hijacked storage into a sellable product.

Stage 4 – Phishing and DNS infrastructure support: The threat actor maintains dedicated infrastructure to support and manage phishing operations on behalf of their customers. A custom DNS management platform enables centralized control of phishing domains, SSL certificates, and domain-routing configurations through Cloudflare.

Stage 5 – Storefront and monetization: Storm-3119 resells the hijacked accounts, licenses, and storage through an automated storefront, operating as the access broker that supplies these resources to downstream operations. Payment is accepted through Alipay, WeChat Pay, and USDT (TRC20), and the storefront supports a sub-reseller tier. Telegram is used for order notifications and buyer contact rather than as the primary sales channel.

In addition to targeting existing tenants, Storm-3119 also separately creates fraudulent organizations and supporting web presence to establish tenants on Microsoft’s platform, likely using AI-generated content and forged documentation to make the fabricated entities appear legitimate. In one case, the actor created an environment, likely using AI, named “Jewish Choice” under the guise of a nonprofit organization and associated it with jewishchoice[.]org, a domain registered only within the past several months that did not appear to represent a legitimate organization. This activity indicates that Storm-3119 likely established the website and associated domain to lend credibility to the fabricated nonprofit identity and facilitate tenant creation.

Storm-2990: The Iron Man System phishing kit

YAM Store sells its illicitly acquired infrastructure, as well as the prominent phishing kits tracked as Storm-2990, to other threat actors. The platforms are commercially licensed phishing-as-a-service (PaaS) products. They are designed to impersonate organizations across several industry verticals to steal information, including sign-in credentials (usernames, passwords) and financial data (credit card information), used to gain access to network environments.

Iron Man System’s customers purchase a subscription that provides access to the kit’s license server, with the domain hard-coded into the kit. This restriction adds a layer of obfuscation by limiting site access to paying customers. The kits allow attackers to steal money by abusing the stolen credit card information.

The Iron Man System phishing kit contains over 2,335 templates tailored to over 139 countries including Australia, Japan, India, and the United States, with the United States accounting for the most phishing templates. The phishing lures used by Iron Man System mimic various trusted brands and organizations, such as local government including authorities associated with traffic and parking fees, law enforcement, healthcare, finance, transportation, and retail. These lures are designed to trick targets into providing sensitive information. Most phishing lures used in the United States are transportation or government-related.

The phishing kits are capable of the following advanced evasion techniques to varying degrees:

• Geofencing, a technique used to restrict access to configured countries only, so only users from specific countries can access the phishing content from their web browser
• Fake CAPTCHA gates, used to prevent or block automated browsing from threat research tools by making the user click a box or execute an action
• IP address block list and allow list, used to block or allow IP addresses to prevent threat researcher interaction
• Anti-detection configuration related tosettings to evade security researcher detection
• Telegram bot configuration,including bot tokens and chat IDs for real-time phishing that enables credential exfiltration. It allows the kit operator to receive automatic notifications on their Telegram account when a target takes action on a phishing lure, including entering credentials, credit card data submission, and verification codes.

After the target provides the sensitive information (sign-in details, credit card info), the phishing kit collects it using a WebSocket, offering customers real-time victim interaction through Telegram notifications during credential harvesting. This confirms that the kit supports live, interactive phishing where the operator monitors each victim’s progress and manually controls what the victim sees next, a hallmark of sophisticated PaaS platforms. The attacker then harvests the information to use in follow-on fraudulent financial activities.

The Iron Man System phishing kit panel is predominately hosted on China-based hosting providers, with a smaller number of panels found on hosting providers in other countries. The fully featured, multi-tenant phishing kit uses the GoFrame application development framework, an open-source Go framework with roots in the Chinese developer ecosystem.

Downstream activity from Storm-2990 phishing kits

Microsoft observed downstream activity by threat actors using infrastructure affiliated with the Storm-2990 phishing kits. In analyzed cases, the actors used similar common phishing techniques, such as urgency in the message and attaching malicious links that redirect to actor-controlled infrastructure that allows these downstream threat actors to perform the following activities:

• Credential stealing: The actors use phishing pages that impersonate legitimate services to trick targets into providing credentials or other authentication information, enabling downstream actors to access compromised accounts.
• Device code phishing: In some cases, the actors abuse the device code authentication flow to trick victims into authenticating to legitimate applications, allowing downstream actors to obtain authentication tokens and access compromised accounts.
• Financial fraud: The end goal for the downstream actors is to use stolen payment data to make fraudulent purchases of high-end goods or fraudulent transactions on legitimate financial platforms.

The threat actors using the phishing kits conduct phishing campaigns at scale whether it is a missing toll payment or a traffic citation. The following screenshots show email or SMS phishing lures used in Storm-2990 phishing kits.

Mitigation and protection guidance

This interconnected network of Chinese-language phishing kit operators and developers operates as an enabling ecosystem, providing infrastructure and services that facilitate criminal activity rather than functioning as a standalone malware tool. Microsoft assesses that the ecosystem is not limited to the abuse of Microsoft services and extends to other providers.

While Microsoft notes that the identified organizations impacted by attacks stemming from Storm-3119 or Storm-2990 operations include financial, healthcare, and IT companies, the activity conducted by threat actors using these tools are common attacks that could affect any organization.

Most of the activity that stems from this phishing kit ecosystem consists of social engineering, phishing operations, and account and storage takeovers. Microsoft recommends the following to mitigate the impact of Storm-3119 and Storm-2990-related threats.

• In nearly all the cases observed by Microsoft, the phishing lures used by the Storm-2990 operators followed prescriptive scam red flags, including urgency, time-sensitive tasks such as clicking a provided link with official branding. Users should verify with the purported sender of the message or email, even when the task involves signing in to a known, secure account not provided by the link or calling the purported organization or company directly.
• Educate users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing emails and watering holes, and reporting reconnaissance attempts and other suspicious activities.
• 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.
• Review our recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Configure the Microsoft Defender for Office 365 Safe Links policy to apply to internal recipients.

Hardening credentials and cloud identities is also necessary to defend against phishing attacks, which seek to gain valid credentials and access tokens. As an initial step, use passwordless solutions like passkeys and implement multifactor authentication (MFA) throughout your environment:

• Invoke the principles of least privilege and Zero Trust to significantly slow down threat actors who might have been able to gain initial access and buy time for defenders to respond. Since Storm-3119 operators have been observed obtaining Global Administrator access, implementing these principles can help lock down Global Administrator roles and who has access to specific resources.
• Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with Conditional Access policies, where sign-in requests are evaluated using additional identity-driven signals.
• Conditional Access policies can also be scoped to strengthen privileged accounts with phishing-resistant MFA.
• Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

The coverage below applies to the downstream activity detected by Microsoft that was identified using Storm-2990 infrastructure.

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

• Threat Overview Profile: Evolving phishing threats

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 the activity discussed in this blog.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find generic activity that may have some overlap with Storm-2990-related activity. Note that these queries are not specific to Storm-2990:

Hunt for suspicious device code authentication

The following query identifies risky sign-ins using the device-code authentication flow that could indicate device-code phishing and subsequent unauthorized account access.

EntraIdSignInEvents
| where Timestamp > ago(30d)
| where AuthenticationProtocol =~ "deviceCode"
| where RiskLevelDuringSignIn in~ ("medium", "high")
or RiskLevelAggregated in~ ("medium", "high")
or RiskEventTypes_V2 != "[]"
| project Timestamp, AccountUpn, IPAddress, Country, Application, ResourceDisplayName,
AuthenticationProtocol, RiskLevelDuringSignIn, RiskLevelAggregated,
RiskEventTypes_V2, SessionId
| order by Timestamp desc

Hunt for potentially compromised accounts using multiple risk signals

The following query identifies accounts exhibiting risky authentication activity across multiple IP addresses or countries that may indicate credential compromise following phishing.

EntraIdSignInEvents
| where Timestamp > ago(30d)
| where RiskLevelDuringSignIn in~ ("medium", "high")
    or RiskLevelAggregated in~ ("medium", "high")
    or RiskEventTypes_V2 != "[]"
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            IPAddresses = make_set(IPAddress, 20), Countries = make_set(Country, 20),
            Applications = make_set(Application, 20), RiskEvents = make_set(RiskEventTypes_V2, 20),
            SignInCount = count() by AccountUpn
| where array_length(IPAddresses) > 1 or array_length(Countries) > 1
| order by LastSeen desc

Hunt for phishing clicks followed by Defender alerts

The following query correlates email URL clicks with subsequent Defender alerts for the same user to identify potential phishing-related account compromise.

let Lookback = 30d;
let PhishClicks =
    UrlClickEvents
    | where Timestamp > ago(Lookback)
    | project ClickTime = Timestamp, AccountUpn, Url, ClickAction = ActionType;
let IdentityAlerts =
    AlertEvidence
    | where Timestamp > ago(Lookback)
    | where EntityType =~ "User"
    | project AlertTime = Timestamp, AccountUpn, AlertId, Title, Severity, DetectionSource;
PhishClicks
| join kind=inner IdentityAlerts on AccountUpn
| where AlertTime between (ClickTime .. ClickTime + 24h)
| project ClickTime, AlertTime, AccountUpn, Url, ClickAction, AlertId, Title, Severity, DetectionSource
| order by ClickTime desc

Hunt for phishing URL clicks followed by suspicious sign-ins

The following query identifies users who clicked URLs in email and subsequently generated risky sign-in activity, which may help identify credential compromise following phishing.

let Lookback = 30d;
let PhishClicks =
    UrlClickEvents
    | where Timestamp > ago(Lookback)
    | where ActionType in~ ("ClickAllowed", "ClickBlocked")
    | project ClickTime = Timestamp, AccountUpn, Url, Workload, ClickAction = ActionType;
let SuspiciousSignins =
    EntraIdSignInEvents
    | where Timestamp > ago(Lookback)
    | where RiskLevelDuringSignIn =~ "high"
        or RiskLevelAggregated =~ "high"
        or RiskEventTypes_V2 != "[]"
    | project SignInTime = Timestamp, AccountUpn, IPAddress, Country, Application,
              RiskLevelDuringSignIn, RiskLevelAggregated, RiskEventTypes_V2;
PhishClicks
| join kind=inner SuspiciousSignins on AccountUpn
| where SignInTime between (ClickTime .. ClickTime + 24h)
| project ClickTime, SignInTime, AccountUpn, Url, IPAddress, Country, Application,
          RiskLevelDuringSignIn, RiskEventTypes_V2
| order by ClickTime desc

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious activity mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

• Possible phishing with clicked/selected link and network session
• Threat Intelligence URL match with UrlClickEvents
• Correlate unfamiliar sign-in properties and atypical travel alerts
• Possible AiTM phishing attempt against Microsoft Entra ID
• Business email compromise – Mailbox rule

References

• CoGUI Phish Kit Targets Japan with Millions of Messages | Proofpoint US
• IronToll: Global Government-Impersonation PhaaS | PhishEye

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 The hidden network: Inside the phishing infrastructure ecosystem powering global cybercrime appeared first on Microsoft Security Blog.

Activity associated with Storm-2570, a ransomware affiliate linked to multiple ransomware payloads, illustrates how tracking and responding to ransomware attacks by payload alone can obscure the affiliates carrying out intrusions and the recurring behaviors that defenders can use to detect and disrupt them. Microsoft Threat Intelligence has observed Storm-2570 using consistent post-compromise tools and techniques across deployments involving Qilin, DragonForce, Anubis, and BERT ransomware. Across multiple investigations, Storm-2570 has maintained largely uniform tradecraft, infrastructure overlaps, and repeated use of the same remote access and cloud exfiltration tooling despite operating across multiple ransomware ecosystems.

These findings reinforce the value of examining threat actor behavior across the attack chain rather than treating each ransomware payload as an isolated activity set. Recurring remote access, credential access, lateral movement, security tampering, and data exfiltration activity can help defenders connect related intrusions and respond before ransomware deployment, even when the final payload changes.

In this blog post, we delve into the attack techniques attributed to Storm-2570. While Storm-2570’s methodology aligns with the tactics, techniques, and procedures (TTPs) of many tracked ransomware actors, analysis of their post-compromise tactics provides essential insights into how organizations can harden and defend against ransomware threat actors, informing opportunities to disrupt attackers even if they have gained initial access to a network. At the end of this blog, we also provide a comprehensive recommendation section with detection details.

Who is Storm-2570?

Storm-2570 is a ransomware affiliate that Microsoft Threat Intelligence has tracked since April 2025. We assess that Storm-2570 has operated across multiple ransomware as a service (RaaS) ecosystems, including Qilin, DragonForce, Anubis, and BERT.

To date, Microsoft Threat Intelligence has observed Storm-2570 in multiple investigated intrusions affecting organizations in United States, Canada, United Kingdom, Spain, Netherlands, and Puerto Rico, including healthcare and public health, education, government agencies and services, financial services, energy, consumer retail, Information technology (IT), food and agriculture, consumer services, commercial facilities, non-government organization (NGO), chemicals, critical manufacturing, and transportation.

Unlike actors that consistently support a single ransomware operation, Storm-2570 appears to be a cross-ecosystem threat actor that works with multiple ransomware groups and shifts between operations as opportunities arise, giving the threat actor the flexibility to use and deploy multiple families and improve opportunities for payouts. As a result, organizations could encounter the same actor, tools, and intrusion methods despite different ransomware payloads being deployed.

Storm-2570 attack chain: From initial foothold to impact

While the method through which Storm-2570 gains initial access remains unconfirmed, observed intrusion chains indicate subsequent use of remote management tooling and hands-on-keyboard activity to progress toward credential access, lateral movement, exfiltration, and ransomware deployment.

Across incidents, Microsoft has observed the use of commodity tools in the pre-ransom attack stage even when the ransomware payload changed. These tools include:

• Remote monitoring and management (RMM) tools, including Atera, MeshAgent, ScreenConnect, Splashtop, Remotely_Agent, and NinjaRMM
• Discovery and lateral movement tools, including NetScan, Nmap, PsExec, Impacket, NetExec, and Remote Desktop Protocol (RDP) batch scripts
• Data collection and exfiltration tools, including s5cmd and Rclone

These tools enable remote administration, command execution, persistence, and tunneling or proxy access.

Frequent use of remote management tooling across the attack chain

MeshAgent, a remote device management software, stands out as one of Storm-2570’s most frequently observed remote access and execution tools across multiple intrusions. Rather than appearing as a one-off utility, MeshAgent repeatedly shows up at key points in Storm-2570 attack chains, often after the actor has gained access and is preparing to expand control, run commands, deploy additional tooling, or move toward ransomware impact. In several cases, Storm-2570 used MeshAgent along with MeshCentral as an operational bridge between initial hands-on-keyboard activity and later-stage actions, such as account manipulation, discovery, credential access, security tampering, and ransomware deployment.

Many intrusions tracked by Microsoft have shown Storm-2570 tailoring MeshAgent deployments to the compromised environment. The actor renames MeshAgent-related binaries or services with victim-themed names, likely to make the tool appear more legitimate in the environment. For example, Storm-2570 renames the variant of the meshagent64 RMM tool to include the name of the compromised organization, such as meshagent64-[organization name].exe and uses Base64-encoding to obfuscate the commands being executed. In one such intrusion, MeshAgent was used alongside NinjaRMM before the activity progressed to ntdsutil for credential dumping, network scanning, and Qilin deployment.

Storm-2570 uses a diverse set of remote access tools rather than relying on a single capability. The threat actor rotates among commercially available RMM platforms, remote desktop components, and tunneling utilities, often deploying multiple tools during the same intrusion. For example, Storm-2570 uses Atera to install agents and execute interactive commands, while ngrok and Cloudflared.exe expose RDP services or establish persistent outbound tunnels. Storm-2570 uses AteraAgent to issue commands and to further download and install Splashtop Streamer in compromised environments. Splashtop appears to be the interactive remote control component delivered through Atera, giving the threat actor hands-on keyboard access. The actor also uses tools such as ScreenConnect for command execution and account or domain reconnaissance and installs Remotely_Agent as a persistent remote management service.

Use of tunneling utilities for persistent remote access

Storm-2570 also pairs remote access tooling with tunneling utilities such as Cloudflared.exe to create resilient outbound access paths. In one intrusion, Storm-2570 installed MeshAgent and later created a persistent Cloudflare Tunnel service on the victim host. The tunnel was configured to run automatically as a service under LocalSystem, allowing the threat actor to maintain an encrypted outbound channel from inside the network. This type of tunnel can help bypass inbound firewall restrictions and provide covert remote access for follow-on activity.

Discovery and credential access

Post-compromise, Storm-2570 routinely conducts internal network discovery using tools such as NetScan, SoftPerfect Network Scanner Portable, and Nmap, alongside native discovery commands and file-searching activity. These activities are used to identify reachable hosts and services, map internal networks and remote systems, and locate systems, network shares, and files that may facilitate data collection, credential access, or encryption operations.

For credential access and harvesting, Storm-2570 uses tools like Mimikatz, LaZagne, and pypykatz. Storm-2570 also uses ntdsutil in intrusions for NTDS.dit credential dumping, a credential theft technique against Active Directory domain credentials. The ntdsutil command usage pattern is consistent with creating an Install From Media (IFM) copy of Active Directory database material. In an intrusion context, attackers can use this to obtain NTDS.dit and related registry hives for offline extraction of password hashes and credential material.

The command uses the legitimate Windows ntdsutil.exe to activate the NTDS Active Directory instance and create a full IFM backup in C:\Windows\Temp\<XXXXXXXXX>.

Storm-2570 uses this command to dump or stage Active Directory database NTDS.dit and supporting registry hive material, then copy it off-host and potentially extract domain credential hashes offline, indicating that the actor has high-privilege access to a victim’s domain controller:

Defense evasion

After acquiring privileged credentials, Storm-2570 uses defense evasion tactics preceding ransomware deployment, including antivirus tampering and the modification of Microsoft Defender settings and Defender exclusions. In multiple observed intrusions, Storm-2570 disabled real-time monitoring, added Defender exclusions for C:\PerfLogs to weaken endpoint detections, and modified registry values under Microsoft Defender service keys to further impair protections.

These tactics are consistent across Storm-2570 ransomware intrusions involving Qilin, DragonForce, and Anubis deployment, including cases where the actor used registry changes to alter DisableAntiSpyware, DisableRealtimeMonitoring, and WinDefend service behavior.

Lateral movement and deployment preparation

Storm-2570 moves into lateral movement and deployment preparation phase typically by using a mix of legitimate administrative tooling, offensive frameworks, and remote execution utilities.

Across multiple investigated intrusions, Storm-2570 was observed leveraging PsExec, Impacket, NetExec, RDP batch scripts, and admin shares to reach additional systems, execute commands remotely, and stage tooling across the environment. The actor uses these capabilities to facilitate data exfiltration and prepare victim networks for ransomware deployment. These tools frequently appear alongside earlier discovery activity, credential access, and remote access tooling such as MeshAgent, and often precede the use of s5cmd for exfiltration or ransomware payload execution.

PsExec is one of the most consistent lateral movement and deployment tools used by Storm-2570. The actor frequently uses PsExec, sometimes with host lists such as @ip.txt, to move laterally and install renamed MeshAgent binaries across compromised environments. Storm-2570 utilizes MeshAgent during the lateral movement phase in several intrusions as a remote access tool deployed onto newly compromised systems.

The following are examples of PsExec commands with host lists @ip.txt:

Storm-2570 also uses RDP and RDP-enabling scripts as part of this phase. If RDP is not allowed in the environment, Storm-2570 needs admin privileges to modify the policy and enable it. In several intrusions, rdp.bat script appeared with PsExec, including cases where PsExec ran rdp.bat across hosts using @ip.txt.

The RDP batch script (rdp.bat) enables inbound Remote Desktop access by modifying Terminal Server settings and adding a firewall rule to allow TCP port 3389, as observed in the command below:

Additionally, the threat actor uses ngrok to expose TCP 3389 (default port for RDP), after which PsExec-related activity and security tampering appears. These examples show Storm-2570 combining RDP access, tunneling, and remote execution to sustain hands-on-keyboard control and reach additional systems.

Storm-2570’s use of Impacket and NetExec over Server Message Block (SMB) further supports their lateral movement pattern. Impacket is a collection of open-source Python classes designed for working with network protocols, and is popular with adversaries due to its ease of use and wide range of capabilities. Microsoft Defender for Endpoint has a dedicated attack surface reduction rule to defend against lateral movement techniques used by Impacket; protecting lateral movement pathways can also mitigate Impacket.

The following NetExec SMB command is used to conduct credential theft and reconnaissance against internal Windows hosts:

Data collection and exfiltration

Storm-2570 frequently performs data theft using cloud and file-transfer utilities that are capable of moving large volumes of data quickly from compromised environments to a remote attacker-owned cloud resource. Microsoft has observed Storm-2570 using s5cmd or Rclone to stage and exfiltrate data, often after the actor has already completed discovery, credential access, lateral movement, and remote access setup. Tools like Rclone provide data synchronization capabilities, moving newly created or updated files to cloud resources in real-time to enable continuous exfiltration throughout all stages of the attack without needing attacker interaction.

Most commonly, Storm-2570 relies on s5cmd, a command-line utility designed for managing Amazon S3 and compatible object storage services, for S3-based exfiltration. In multiple intrusions, the actor staged s5cmd.exe alongside a credentials file and used it to copy documents, spreadsheets, images, databases, mail-related files, archives, and other business-relevant file types to S3 buckets. Storm-2570 identifies high-value drives and network shares, stages s5cmd.exe and a credentials file, and then executes run copy (cp) operations with extension filters to transfer selected data to attacker-controlled S3 buckets. To interact with the destination S3 bucket, s5cmd requires credentials for authentication and the credentials file stores the AWS access keys for authentication to the S3 bucket.

The following is an example of s5cmd data exfiltration command lines:

Overall, Storm-2570’s exfiltration tradecraft shows a strong preference for tools that blend into legitimate administrative or cloud-transfer workflows, allowing double-extortion operations: first collecting sensitive data through cloud-transfer tooling, then deploying ransomware.

What Storm-2570 activity means for defenders

Storm-2570 illustrates common human-operated ransomware attacks and how modern ransomware affiliates increasingly operate independently of a single ransomware brand. Ransomware affiliates’ use of common tools, intrusion methods, and operational patterns remain remarkably consistent. Although Storm-2570’s techniques are not novel, recognizing the patterns used by ransomware affiliates can be important for defenders to know to improve prevention, detection, and incident response.

Mitigation and protection guidance

To defend against Storm-2570 TTPs and similar activity, Microsoft recommends the following mitigation measures:

• Follow the defending against ransomware guidance in Microsoft’s ransomware as a service blog post which details how to build credential hygiene as well as how to limit lateral movement using the principle of least privilege.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in Troubleshooting mode to turn off Tamper Protection temporarily without impacting the wider organizational security policy.
• For approved RMM systems used in your environment, enforce security settings where possible to implement MFA. If an unapproved RMM installation is discovered in your network, reset passwords for accounts used to install the RMM services. If a System-level account was used to install the software, further investigation may be warranted.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block execution of potentially obfuscated scripts
  • Block Webshell creation for Servers
  • Block process creations originating from PSExec and WMI commands (Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.)
  • Block use of copied or impersonated system tools
  • Use advanced protection against ransomware

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor Profile: Storm-2570
• Tool Profile: Qilin ransomware
• Tool Profile: Anubis ransomware
• Tool Profile: DragonForce ransomware

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can run the following advanced hunting queries to find related activity in their networks:

Hunt for PsExec-based remote execution and deployment

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("psexec.exe", "psexec64.exe")
    or ProcessCommandLine has_any ("psexec.exe", "psexec64.exe")
| where ProcessCommandLine has_any ("@ip.txt", "-accepteula", "\\")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          SHA256, DeviceId, ReportId
| order by Timestamp desc

Hunt for renamed MeshAgent binaries and services

let MeshAgentTerms = dynamic(["meshagent", "meshagent64", "meshcentral"]);
union isfuzzy=true
(
    DeviceProcessEvents
    | where Timestamp > ago(30d)
    | where FileName has_any (MeshAgentTerms)
        or ProcessCommandLine has_any (MeshAgentTerms)
        or InitiatingProcessCommandLine has_any (MeshAgentTerms)
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath,
              ProcessCommandLine, InitiatingProcessFileName,
              InitiatingProcessCommandLine, SHA256,
              RegistryKey="", RegistryValueName="", SourceTable="DeviceProcessEvents"
),
(
    DeviceFileEvents
    | where Timestamp > ago(30d)
    | where FileName has_any (MeshAgentTerms)
        or FolderPath has_any (MeshAgentTerms)
        or InitiatingProcessCommandLine has_any (MeshAgentTerms)
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath,
              ProcessCommandLine="", InitiatingProcessFileName,
              InitiatingProcessCommandLine, SHA256,
              RegistryKey="", RegistryValueName="", SourceTable="DeviceFileEvents"
),
(
    DeviceRegistryEvents
    | where Timestamp > ago(30d)
    | where RegistryKey has_any (MeshAgentTerms)
        or RegistryValueName has_any (MeshAgentTerms)
        or RegistryValueData has_any (MeshAgentTerms)
        or InitiatingProcessCommandLine has_any (MeshAgentTerms)
    | project Timestamp, DeviceName, ActionType, FileName="", FolderPath="",
              ProcessCommandLine="", InitiatingProcessFileName,
              InitiatingProcessCommandLine, SHA256="",
              RegistryKey, RegistryValueName, SourceTable="DeviceRegistryEvents"
)
| order by Timestamp desc

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 Beyond the ransomware: Tracking Storm-2570’s consistent tradecraft across deployments appeared first on Microsoft Security Blog.

Since January 2026, Microsoft has observed Russian state threat actor Star Blizzard evolve their detection evasion capabilities through large-scale phishing campaigns, the use of accounts on compromised websites, and a novel malware delivery technique that Microsoft tracks as “RedFlick”. These changes represent a notable shift in the actor’s operational tradecraft and support ongoing cyberespionage activity targeting Ukrainian individuals and institutions as well as international non-government organizations (NGOs), Western think tanks, governments, and other organizations associated with international policy—particularly those with a nexus in supporting Ukraine.

As part of this evolution, Star Blizzard adopted RedFlick, a malware delivery technique that helps evade detection by initiating a set of scheduled tasks to deploy the actor’s custom backdoor, CosmicPulse. This technique is a notable departure from the actor’s previous use of ClickFix-based infection chains which required victims to complete multiple actions before CosmicPulse could be installed. By contrast, the RedFlick infection flow only requires a single user interaction, reducing friction in the compromise process. Combined with the actor’s shift toward large-scale phishing operations during the same period, these changes likely improve Star Blizzard’s ability to reach more targets, evade detection, and increase the likelihood of successful compromise.

This blog provides updated technical analysis of Star Blizzard’s tactics, techniques, and procedures (TTPs) observed throughout 2026, building on our 2025 and 2023 blogs. It details the actor’s evolving phishing, persistence, and malware delivery techniques, and provides recommendations, indicators of compromise (IOCs), detections, and hunting guidance to help organizations identify and defend against RedFlick-related activity. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with recommendations and mitigations to secure their accounts.

Star Blizzard TTPs observed in 2026

Star Blizzard is attributed by the United States Cybersecurity and Infrastructure Agency (CISA) as subordinate to the Russian Federal Security Service Centre (FSB) Centre 18. Star Blizzard periodically overhauls their TTPs to avoid detection, often in response to public exposure of the actor’s campaigns that have involved targeted social engineering through messaging apps and credential theft. Since Google Threat Intelligence Group published its report on Star Blizzard’s COLDCOPY malware in October 2025, Microsoft observed the actor refine their initial access and evasive techniques to include:

• Moving away from targeted spear phishing to large-scale initial contact phishing campaigns
• Using compromised websites to create accounts to send phishing emails
• Updating malware deployment to facilitate the installation of a CosmicPulse downloader

As of the writing of this blog, the RedFlick campaigns have targeted Ukrainian individuals and institutions, as well as international NGOs, think tanks, governments, and financial institutions that have supported Ukraine politically or financially. Microsoft has observed this activity affect over 100 organizations primarily in the United States and United Kingdom, consistent with Star Blizzard’s longstanding targeting priorities.

Microsoft continues to observe some previously reported Star Blizzard phishing techniques throughout 2026; however, the TTPs discussed in this blog have been associated primarily with the actor’s new larger-scale phishing campaigns.

Larger-scale initial contact phishing

Microsoft previously reported on Star Blizzard’s spear-phishing campaigns observed during 2023-2024. During these operations, the actor continued to rely on their conventional TTPs such as initiating email contact with targets before sending a follow-up containing a malicious link, to actor-controlled/compromised infrastructure purposed for credential theft, while impersonating known political or diplomatic figures to lure victims into responding.

In 2026, Microsoft observed Star Blizzard shift from exclusively targeted spear-phishing operations to also conducting larger-scale phishing campaigns. The larger-scale phishing operations were observed at a scale not previously seen from the actor, ranging from tens to hundreds of email messages per campaign. This change likely reflects the actor’s adoption of a mass-mailing phishing platform to automate campaign execution and increase the likelihood of successful compromises by significantly expanding the initial targeting pool. The progression of these campaigns is summarized in the following timeline, including examples of Star Blizzard’s phishing subject lines, targeting details, and the malware delivery methods observed across each campaign:

• January
  • “Повідомлення про результати податкової перевірки” (Notice of tax audit results) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• February
  • “списання з Вашого рахунку за оплату штрафу” (Debiting from your account for payment of a fine) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• March
  • “Invitation to an IISS [Private Roundtable/Closed-Door Discussion] on European Security” – Initial contact campaign targeting government officials, security researchers, academia, media, and NGOs. Respondents received a RedFlick lure attachment.
  • “Invitation to a Closed CES Roundtable Discussion” – Initial contact campaign targeting US and Europe technology-sector organizations. Respondents received a RedFlick lure attachment.
  • “Atlantic Council Closed-Door Strategic Discussion” – Initial contact campaign targeting government officials, foreign policy practitioners, security researchers, academia, media, and NGOs. Respondents received a link to DarkSword iOS backdoor installation.
• April
  • “Closed-Door Online Session on Global Capital Allocation & M&A” – Initial contact campaign targeting international financial organizations and researchers. Respondents received a RedFlick lure attachment.
• May
  • “Future of Peace Operations Forum – A Closed Strategic Dialogue” – Initial contact campaign targeting diplomatic and multilateral organizations. Respondents received a RedFlick lure attachment.
  • “Future of Liberty Forum” – Initial contact campaign targeting employees of a US-based think tank. Respondents received a RedFlick lure attachment.
• June
  • “Invitation to the MAMA Summit on the Current Situation Surrounding the Ukrainian Crisis” – Initial contact campaign targeting incumbent/former diplomatic staff. Respondents received a RedFlick lure attachment.
  • “Invitation to the Chatham House London Conference 2026 – 9 July 2026” – Initial contact campaign targeting think tanks, NGOs, and national parliamentary. Respondents received a RedFlick lure attachment.
• July
  • “Thought you might find this USUBC roundtable of interest” – Initial contact campaign targeting think tanks, NGOs, and Ukraine civil society. Respondents received a RedFlick lure attachment.
  • “Інформація щодо тимчасового відключення водопостачання” (Information about temporary water supply shutdown) – Targeted Kyiv-based hotels with an attached RedFlick lure.
• August
  • “Payment Advice Note from 06.08.2026” – Targeted employees of an international financial organization with an attached RedFlick lure.

Once a recipient responds to the initial phishing email, Star Blizzard typically sends a follow-up message containing a password-protected RAR or ZIP archive. The archive contains files that initiate the RedFlick infection flow. The password is included as an image in the follow-up email shown in Figure 1, along with additional examples of Star Blizzard follow-up emails below:

Since January 2026, Microsoft observed at least 13 distinct large-scale phishing campaigns targeting primarily NGOs, think tanks, and government organizations worldwide. The earliest campaigns, observed between January and February, targeted unspecified users of the Ukraine email provider Ukr.net. These emails impersonated Ukrainian authorities and were themed as notifications of a tax audit or outstanding fine.

Beginning in March 2026, Star Blizzard expanded targeting outside of Ukraine. Subsequent campaigns frequently used lures themed as invitations to conferences or events purportedly organized by a reputable think tank or NGO. Microsoft also observed the actor target multiple individuals within the same organization, with phishing emails often crafted to appear as internal communications originating from the targeted organization itself. The actor’s shift from Ukraine-focused operations to global targets could indicate Star Blizzard initially targeted Ukraine to test their new capabilities.

The large-scale campaigns have demonstrated capabilities previously unassociated with Star Blizzard. For example, a campaign observed in mid-August 2026 employed steganography to conceal identifiers. Throughout 2026, Star Blizzard has also continued to develop additional operational capabilities. Notably, ProofPoint reported in March that the actor had targeted vulnerable Apple iOS devices to deploy the DarkSword backdoor.

Creating accounts on compromised websites

Since March 2026, Star Blizzard has made another notable change to their TTPs to support the higher-volume phishing operations, using accounts created on compromised websites to send phishing emails to targets. This change coincided with the actor’s shift to larger-scale phishing campaigns and has been observed almost exclusively in support of these operations. Previously, the actor would create accounts on free email services (predominantly using Protonmail and Microsoft consumer accounts) to impersonate an individual that would be well known to the prospective target, whether it was a political figure, academic, or former diplomat. In the large-scale campaigns, Star Blizzard has used accounts created on websites hosted on CPanel and WordPress, using the same account name across multiple website domains. Microsoft Threat Intelligence assesses with high confidence that these websites have been compromised by Star Blizzard for this purpose.

Updating malware delivery and installation TTPs

Between January and August 2026, Microsoft observed multiple waves of Star Blizzard phishing campaigns alongside notable changes in the actor’s initial access TTPs, particularly the use of RedFlick scheduled tasks. During this period, Microsoft observed three significant shifts in the threat actor’s delivery techniques.

From ClickFix to VHDX

In mid-January 2026, Microsoft observed the use of a malicious Virtual Hard Disk v2 (VHDX), delivered through a phishing email containing a password-protected ZIP file. The VHDX file ships a malicious LNK file disguised as a PDF document, alongside a hidden directory containing a BAT script and a legitimate decoy PDF.

When the victim opens the LNK file, conhost.exe is launched in a hidden window and cmd.exe is subsequently spawned to execute the embedded BAT script:

The BAT file opens the decoy PDF and invokes SSH.exe with PermitLocalCommand enabled, ultimately downloading and executing a remotely hosted MSI installer:

In multiple campaigns, Microsoft observed an MSI installer creating a scheduled task that uses control.exe to download and execute a remotely hosted CosmicPulse downloader masquerading as a Control Panel applet (CPL). Unlike earlier campaigns that relied on ClickFix lures and user interaction, this approach relies on compiling the CosmicPulse downloader as a Control Panel applet DLL.

The shift from interactive user execution to remote execution and masquerading as a CPL item highlights an evolution in both persistence and defense evasion techniques.

CosmicPulse downloader

The Control Panel applet DLL is a downloader with the sole purpose of downloading and installing a version of CosmicPulse, a malicious Python backdoor, on the target device. The downloader is also known publically as NOROBOT or BAITSWITCH.

Similar to previous versions, this downloader downloads, persists, and executes a version of CosmicPulse on the infected device. Upon execution, it downloads two ZIP files and stores them on disk. It then writes an encrypted AES key to the HKEY_CURRENT_USER\Software\Classes\.mollis registry key. One ZIP file contains a Python 3.8 64-bit package and a Python file that serves as the CosmicPulse bootstrapper. The bootstrapper reads the encrypted key from the registry, recovers it using an embedded key in AES-ECB mode, and then uses the recovered key to decode the CosmicPulse payload (also known as YESROBOT) contained in the second ZIP file. The below image shows the process of the CosmicPulse installation.

Since January 2026, Microsoft has observed the CosmicPulse backdoor going through various little changes to circumvent existing signatures. However, the capabilities and purpose of this backdoor remain the same as described in previous articles.

Persistence through multiple scheduled tasks

In April 2026, Microsoft observed Star Blizzard changing persistence tactics to include RedFlick scheduled tasks. Whereas a malicious MSI file installed a single scheduled task in January—by April, the actor’s MSI installer created three scheduled tasks masquerading as legitimate network components, each with their own purpose. The TTPs have overlaps with the spear-phishing campaigns reported by the Digital Security Lab Ukraine (DLUA) in June 2026. In at least one incident, Microsoft has observed either the first or third task deploying an instance of CosmicPulse on the infected machine.

Task 1 – Registration beaconing and dynamic DLL execution task

The first task masquerades as a legitimate Internet Quality Test Connection task. The scheduled command serves two purposes. First, it sends a UTF-16 and Base64-encoded string containing the network or computer name and the username of the infected device to the C2 server. Thereby, it exfiltrates basic information about the infected host.

Second, an attacker-controlled DLL can be executed remotely through invoking Control_RunDLL from Shell32.dll. Microsoft was unable to obtain a variant of this payload. The task uses a WebDAV UNC path to access the remote payload, allowing the resource to be retrieved over HTTP rather than through a conventional SMB network share.

Task 2 – Supporting task

The second installed task, named Network Configuration Manager, supports the WebDAV-based execution used by the other tasks. The invoked command causes Windows to treat the UNC-style path as a WebDAV resource and process it through the WebDAV redirector and associated WebClient functionality.

Through WebDAV, Windows applications can interact with a remote web resource as though it is a file or folder path while the underlying communication is performed using HTTP/HTTPS rather than conventional SMB. The task therefore prepares the WebDAV client functionality required by the other scheduled tasks.

Task 3 – CosmicPulse downloader execution

The third installed task, named System Health Monitor, uses control.exe to access a remote path hosted on the hardcoded C2 server and execute the next stage.

Hiding payloads in PDF files

In July 2026, Microsoft observed another change in Star Blizzard’s delivery techniques, this time involving a multistage execution chain.

The phishing email contains a password-protected RAR archive nested inside a ZIP file. After the archive is opened, it exposes an LNK file.

When executed, the LNK file uses conhost.exe and curl to download a PDF from an actor-controlled server:

After downloading the PDF, the command runs a second PowerShell payload. This payload searches the PDF for the magic header cAB, extracts the subsequent 208 bytes of Base64-encoded data, and executes the decoded command through PowerShell. The resulting conhost command, shown below, attempts to download and install another MSI file:

As in previous campaigns, the Python installer contains obfuscated PowerShell code. When executed, the code attempts to create two additional scheduled tasks. The first scheduled task again serves as a helper task, consistent with the supporting tasks observed in previous campaigns. The second scheduled task attempts to download and execute a CPL applet again.

Star Blizzard’s shift from ClickFix-based delivery chains to VHDX files, expanded use of scheduled tasks for persistence, and concealment of payloads within PDF files demonstrate the actor’s continued ability to adapt their delivery methods in response to evolving defenses. The actor’s recent use of PDFs to conceal payloads further illustrates efforts to bypass layered defenses through increasingly complex execution chains. Taken together, these changes demonstrate Star Blizzard’s continued efforts to streamline malware deployment, reduce required user interaction, and improve operational scalability while maintaining its longstanding espionage objectives.

Defending against Star Blizzard and RedFlick-related activity

Microsoft Threat Intelligence advises organizations that are most likely at risk—primarily those in government, NGOs, or think tanks adjacent to Ukraine policy or support—to implement the following recommendations to mitigate against Star Blizzard activity.

Protecting against Star Blizzard phishing

As previously reported, Star Blizzard’s success relies on sophisticated, targeted phishing lures that trick users into engaging with the actor by impersonating trusted contacts. While Star Blizzard has changed their overall TTPs, the actor continues to employ the same phishing patterns against users:

• Star Blizzard continues to impersonate trusted contacts that users or organizations would expect an email from. Star Blizzard also continues using email from free providers such as Proton @proton[.]me, particularly in Evilginx spear-phishing operations observed throughout 2026. However, despite the actor’s recent shift toward leveraging compromised legitimate websites that impersonate real individuals associated with a target’s organization, users can still remain vigilant for other Star Blizzard TTPs, several of which have been observed in previous campaigns:
  • Star Blizzard continues to make initial contact with a target by sending an email, usually without an attachment.
  • If a user engages, Star Blizzard will follow up with an email with an attachment. In this particular campaign, it has been an archive file such as a RAR or ZIP.
  • The email sender contains names of actual persons and organizations they belong to—however, the organization is not within the root or registered domain itself but in the username or local part of the email address. This should draw a red flag to the email’s authenticity. When in doubt, directly contact the person you think sent the email using a previously established and trusted contact method such as known email address or phone number.
  • The emails in these RedFlick campaigns are often sent in bulk.
• To best mitigate against this activity, Microsoft suggests the following policies to strengthen network environments against Star Blizzard phishing operations:
  • Using phishing resistant authentication methods.
  • Lockdown account access using Conditional Access policies.
  • Use advanced anti-phishing solutions like Microsoft Defender for Office 365 that monitor and scan incoming emails and visited websites.
  • Turn on Safe Links and Safe Attachments for Office 365.

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

• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.
• 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.
• Configure investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable Conditional Access policies. Conditional Access policies evaluate sign-in requests using additional identity driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Implement continuous access evaluation.
• Turn on Microsoft Defender Antivirus real-time protection.
• Continuously monitor suspicious or anomalous activities. Investigate sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services).
• Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Use the Attack Simulator in Microsoft Defender for Office 365 to organize realistic, yet safe, simulated phishing and password attack campaigns in your organization by training end users against clicking URLs in unsolicited messages and disclosing their credentials. Training should include checking for poor spelling and grammar in phishing emails or the application’s consent screen as well as spoofed app names, logos, and domain URLs appearing to originate from legitimate applications or companies. Note that Attack Simulator testing only supports phishing emails containing links at this time.
• Microsoft Defender customers can turn on attack surface reduction rules to prevent common attack techniques:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts
• Utilize Windows Firewall, Windows Firewall with Advanced Security, or an enterprise firewall/filtering solution to help prevent or restrict outbound SSH connection attempts to external or public networks that are not essential for business.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor profile: Star Blizzard
• Tool profile: CosmicPulse
• Activity profile: New Star Blizzard spearphishing campaign targets WhatsApp accounts
• Threat overview: Evolving phishing threats

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Conhost.exe invokes curl

The following query will detect the use of conhost.exe to launch curl to download a decoy PDF from an actor-controlled server, which Star Blizzard used in July 2026. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "conhost.exe"
| where ProcessCommandLine has "curl"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName, DeviceId, ProcessId, ProcessUniqueId, InitiatingProcessUniqueId

Invoke SSH to launch local command line

The following query will detect the invocation of SSH to initiate a local command prompt, which Star Blizzard used in January 2026 to download and execute a remotely hosted MSI installer. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "ssh.exe"
| where ProcessCommandLine has "PermitLocalCommand=yes"
| where ProcessCommandLine has "LocalCommand=cmd.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, ProcessId, InitiatingProcessId, ReportId

Persistence through scheduled tasks

The following query will detect Star Blizzard’s uniquely named scheduled tasks that attempt to masquerade as legitimately-named tasks, used for persistence by Star Blizzard in April 2026.

union isfuzzy=true
(
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields
, RegistryKey = tostring(dynamic(null)), RegistryValueName = tostring(dynamic(null))
, SourceTable = "DeviceProcessEvents"
, ProcessId, AccountName, AccountDomain, AccountSid
)
,
(
DeviceEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields, RegistryKey, RegistryValueName
, SourceTable = "DeviceEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)
,
(
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueData has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or InitiatingProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType
, ProcessCommandLine = InitiatingProcessCommandLine, AdditionalFields = ""
, RegistryKey, RegistryValueName
, SourceTable = "DeviceRegistryEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect network IP and domain indicators of compromise using ASIM

The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser.

let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
    by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and file hash indicators of compromise using ASIM

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser.

let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr)
    or DstDomain has_any (ioc_domains)
    or Url has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
    by SrcIpAddr, DstIpAddr, DstDomain, Url, Dvc, EventProduct, EventVendor

Indicators of compromise

References

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-341a
• https://www.zscaler.com/blogs/security-research/coldriver-updates-arsenal-baitswitch-and-simplefix
• https://dslua.org/publications/spearphishing-via-fake-urc-2026-invitations-targets-ukrainian-csos/
• https://cloud.google.com/blog/topics/threat-intelligence/new-malware-russia-coldriver
• https://x.com/threatinsight/status/2037560142880006266

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 Star Blizzard refines phishing and malware delivery with the RedFlick technique 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.

Microsoft Threat Intelligence has identified NeedyMantis, a modular post-compromise malware family observed in a limited number of targeted operations affecting telecommunications organizations, universities, medical nonprofits, intergovernmental organizations, and government contractors. Based on observed activity, NeedyMantis is typically deployed after a threat actor has already established access to a target environment, indicating that the malware is used to maintain long-term access and support follow-on operations.

NeedyMantis activity dates back to at least October 2025. We discovered the malware family while analyzing and pivoting from research and indicators of compromise associated with the DAEMON Tools supply chain compromise, which Kaspersky previously reported on as part of its investigation into the campaign. Observed activity involving NeedyMantis has thus far aligned with activity that Microsoft associates with threat actors operating from China, although Microsoft has not determined whether all observed activity is attributable to the same operator.

While NeedyMantis employs techniques commonly used by modern malware, its architecture combines multiple loaders, custom encrypted file archives, a custom executable file format, and modular components that enable operators to evade analysis and extend functionality through additional modules. These characteristics, combined with its use in targeted intrusions, make NeedyMantis a useful case study for understanding how threat actors establish and maintain long-term access within victim environments.

In this blog, we analyze the NeedyMantis malware framework. We examine its packaging and deployment, custom archive format, loader architecture, command-and-control (C2) communications, and modular design. We also provide indicators of compromise (IOCs), Microsoft Defender detections, and mitigation guidance to help organizations defend against this threat and related activity.

Observed operators and targeting

At the time of writing, Microsoft has observed at least one threat actor using NeedyMantis malware: Storm-3069. Storm-3069 is Microsoft Threat Intelligence’s designator for activity associated with the DAEMON Tools supply chain compromise. While Microsoft assesses the activity originates from China, it has not attributed Storm-3069 to a Chinese nation-state actor. Microsoft identified NeedyMantis through follow-on analysis of indicators associated with Kaspersky’s investigation of the DAEMON Tools compromise.

Microsoft has observed additional NeedyMantis activity beyond Storm-3069’s activity in the DAEMON Tools campaign, indicating that the malware might be used by more than one operator. Observed activity involving NeedyMantis has thus far aligned with activity Microsoft associates with threat actors operating from China, such as targeting that aligns with Chinese interests and the use of selective deployment.

NeedyMantis has been observed in intrusions affecting telecommunications organizations, universities, intergovernmental organizations, medical nonprofits, and government contractors. Combined with the malware’s limited observed deployment and alignment with activity Microsoft associates with China-based threat actors, this victimology suggests NeedyMantis is deployed selectively rather than broadly. However, Microsoft has not determined whether all observed activity is attributable to the same threat actor or whether multiple actors have access to the malware.

Malware packaging and distribution

As previously mentioned, observed activity suggests that the malware is typically deployed after a threat actor has established access to a target environment. As a result, the methods used to gain access before NeedyMantis is deployed may vary across intrusions.

NeedyMantis is composed of multiple components written in C++ and x64 shellcode. The malware starts with a first-stage loader and a file archive. The loader and archive have been found packaged alongside legitimate software, with the first-stage loader–masquerading as a required DLL—being loaded through DLL sideloading.

Some of the open-source, software abused by the malware include: Poedit (translation), curl (data transfer), Vim (text editor), and TightVNC (remote access). Microsoft has also observed NeedyMantis masquerading as Microsoft Office, Broadcom, Intel, and NVIDIA DLL components. The following is a list of some of the DLL path names used by the malware:

• %ProgramFiles%\Poedit\WinSparkle.dll
• %ProgramData%\USOShared\libcurl.dll
• %ProgramData%\VIM\vim64.dll
• %ProgramData%\TightVNC\VIM\vim64.dll
• %ProgramData%\office\dbghelp.dll
• %ProgramData%\broadcom\dbghelp.dll
• %ProgramData%\Intel\jli.dll
• %ProgramFiles%\modifiable\nvml.dll
• %ProgramData%\ics\nvml.dll

The malware’s file archive is named the same as the loader DLL without the extension, for example WinSparkle or libcurl.

In one observed incident, an operator used the Impacket toolkit during hands-on-keyboard activity to copy the legitimate software, malicious DLL, and file archive from a network share and execute it on a targeted device. This activity occurred after the actor had already obtained access to the environment and illustrates one method by which NeedyMantis can be introduced during an intrusion post-compromise.

NeedyMantis is observed during the post-compromise stage of an intrusion after an actor has established access to the target environment. While one known user of the malware, Storm-3069, has been associated with supply chain compromises, Microsoft has not observed NeedyMantis itself being distributed through a supply chain compromise. However, supply chain activity remains one possible means by which an actor could gain the access necessary to deploy the malware.

NeedyMantis architecture and capabilities

First-stage loader

NeedyMantis’ first-stage loader is DLL sideloaded and launched when the legitimate software it is packaged with is run. Its only task is to extract the second-stage loader from its file archive and continue execution there.

In the analyzed sample, the loader DLL was named WinSparkle.dll (SHA-256: e842dd7642c8e04b5ec20b6393848a9c904e4832930950c16664fe7800ba382e) and its file archive was named WinSparkle (SHA-256: 9cb68f986043a576e19d32184c583b7d8f571c7219d8dc0065dced1c13f077ef). NeedyMantis spoofed and replaced the WinSparkle software update component of the Poedit translation software.

The loader employs common anti-analysis techniques to hinder analysis, like obfuscating most of its important strings.

This technique is known as obfuscated stack strings because each piece of the string is built up one at a time on the function’s stack. Once built up, it is deobfuscated using various mathematical operations. Most of the obfuscated strings in this loader are Windows DLL and API names. These deobfuscated strings are used to resolve Windows APIs dynamically at runtime.

In addition to obfuscated strings, a lot of the code’s constant values are stored obfuscated as well.

Finally, the loader has two anti-debugger methods: one based on ProcessDebugFlags and the other using ThreadHideFromDebugger.

As noted above, the loader’s main objective is to extract the next stage from its file archive and launch it. In the analyzed sample, the next stage was named encryptbase64.ps1.

Custom file archives

NeedyMantis’ file archives are in an encrypted and compressed custom file format. To get access to the files, the outer layer of the archive is XOR-decoded and RtlDecompressBuffer decompressed. Once decompressed, there are individual file entries. In each file entry, the file’s name is XOR-decoded and its contents are RtlDecompressBuffer decompressed.

The file format’s offsets, XOR keys, and values change from sample to sample.

This archive contains the following 11 files:

• 7-zip.chm – Legitimate component of 7-Zip
• 7-zip.dll – Legitimate component of 7-Zip
• 7-zip32.dll – Legitimate component of 7-Zip
• 7z.exe – Legitimate component of 7-Zip
• Disk2vhd.dll – Legitimate Sysinternals component Disk2vhd
• main.dll – Legitimate Sysinternals component Ctrl2Cap
• kernel32.dll – Legitimate kernel32.dll
• encryptbase64.ps1 – Second-stage loader
• dnsapi.dll – Not a dnsapi.dll, but contains the malware’s configuration
• ws2_32.dll – Not a ws2_32.dll, but contains a WebSockets based communications DLL
• msvcrt140.dll – Not a msvcrt140.dll, but contains shellcode to load module DLLs and resolve exports

While this archive contains several legitimate software components, the malware’s functionality is implemented by the remaining files, discussed below.

Other analyzed NeedyMantis file archives have contained different file names and components. An older version of the malware, for example, used a libcurl (SHA-256: c82520eb03c084226be4eafbff46f56dca0aa8804a2a7f23a085a96afe71ef77) file archive, and it contained only four files:

• 300.c – Malware’s configuration
• 300.s – WebSockets-based communications DLL
• is – Persistence module using Windows Services
• m.l – Main component

Second-stage loader

In the analyzed sample, encryptbase64.ps1 was the second-stage loader. Despite its .ps1 PowerShell extension, the file contains x64 shellcode. Its purpose is to decode and decompress an embedded binary which is NeedyMantis’ main component.

This loader also has some anti-analysis functionality that differs from stage one. For string decoding, it locates two encoded blocks of data and XOR keys at calculated offsets and then decodes them. The first block, most relevantly, contains a few Windows DLL and API names that are resolved dynamically. The second block, shown below, contains a list of Windows DLL names and Windows API hash values:

The component uses a rotate right (ROR) based algorithm with a configurable rotation value (the analyzed sample used value 11) to resolve these Windows API hashes. Figure 5 shows a snippet of Python code reproducing the algorithm:

This second-stage loader’s objective is to extract embedded data, XOR-decode it, and then RtlDecompressBuffer decompress it. The location of the encoded data and XOR key are at calculated offsets, which change from sample to sample.

Once decoded the resulting data is a DLL that has been formatted using a custom executable file format. It is a minimized version of a PE file.

Main component

NeedyMantis’ main component orchestrates C2 communications and handles additional downloaded modules.

It creates a mutex named <username>-<process name>, such as Contoso-Poedit.exe. Like in the first-stage loader, most of the main component’s strings and constant values are stored as obfuscated stack strings.

Configuration

The malware’s configuration was stored in a dnsapi.dll file from the custom file archive. This file name spoofs a Windows networking library. In the sample analyzed, the file contains a 3448-byte binary structure. The structure includes the following fields:

• 0x00: Unknown (config contained “300”, but components also reference “400”)
• 0x1c: Communication component name (ws2_32.dll)
• 0x128: C2 port (443)
• 0x12c: C2 host (corp.tripswithengine[.]com)
• 0x334: C2 URI (/library/zip/)
• 0x53C: WinHttpOpen AccessType (0)
• 0x954: Proxy username (not set)
• 0xB5C: Proxy password (not set)
• 0xD64: Sleep time related (300)
• 0xD68: Sleep time related (300)

Communications DLL

As referenced in the configuration, NeedyMantis makes use of a communication component called ws2_32.dll. This component is also stored in the custom file archive. Like the config file, the file name spoofs a Windows networking library.

This communications DLL has one export named SystemInfo. As shown below in Figure 7, SystemInfo exposes 10 functions for the main component to initiate and maintain a WebSockets connection with the C2:

The library uses WinINet APIs for WebSockets. It also has a hard-coded user-agent of firefox/21.0.

We have also spotted a second version of the communications DLL in a file archive. It implements the same communications API but uses Libwebsockets (LWS) instead of WinINet.

Command and control

The initial C2 beacon is an HTTPS GET request, similar to Figure 8 below:

The Set-Cookie header contains system information. The header value can be Base64-decoded and RtlDecompressBuffer decompressed. Once decompressed it contains a JSON object. The key values are:

• c – Computer name
• u – Username
• o – Base64-encoded data, once decoded it contains line separated “
  • f – Files in ProgramFiles directory
  • pa – Parent process
  • p – Process name
  ” entries:
  • p – Process list

The connection is then converted to WebSockets and a binary C2 protocol is continued. The binary protocol is separated into a header and optional data components. The 44-byte header includes the following fields:

• 0x00: 16-byte XOR key
• 0x10: Uncompressed data length
• 0x14: Compressed data length
• 0x18: Command number
• 0x28: Data length
• 0x2c: Optional data

A 16-byte random XOR key is generated and the header is XOR-encoded, starting at offset 0x18. If there is any data, it is compressed with RtlCompressBuffer and optionally encrypted with RC4.

The initial messages of the binary protocol are a key exchange with the C2 server. The protocol is performed as such:

• 32-bytes are received from the C2 server, but then ignored
• A 1024-byte random buffer is created
• The first 32-bytes of this random buffer are used as the RC4 key for further communications
• A 256-byte buffer is created that starts with google.com followed by random bytes
• The 256-byte buffer is RC4 encrypted
• A random length between 292 and 1282 is picked
• The C2 protocol message data is structured as such:
  • 0x00: The random length
  • 0x04: RC4 encrypted google.com buffer
  • 0x104: The random 1024-byte buffer used to create the RC4 key (at least 32 bytes of it)
• This message data is compressed, but not RC4 encrypted
• A random command number between 1 and 45 is chosen
• The C2 server uses the buffer at offset 0x104 to recreate the RC4 key and presumably checks the RC4 encrypted google.com buffer
• The server sends back the random command number as an acknowledgement

Commands

The main component only has a handful of commands. Commands sent to the C2 include:

• 1110 – Sends computer name and username
• 1112 – Sends a hard-coded identifier (like 20001)
• 1150 – Keep alive

Commands received from the C2 include:

• 1020 – Load module
• 1030 – Unload module
• 1050 / 1150 – Dispatch data to module
• 1070 – Turn off active flags

The main component’s load, unload, and data dispatch commands show that NeedyMantis can extend its functionality through additional modules, but the capabilities of those modules remain unconfirmed.

Mitigation and protection guidance

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

• Look for outbound connections in network egress traffic to corp.tripswithengine[.]com.
• Turn on cloud-delivered protection and block at first sight to rapidly identify and block new and unknown malware variants.
• Run Endpoint Detection and Response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.    
• Enable network protection in Microsoft Defender for Endpoint.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts

You can assess how an attack surface reduction rule might impact your network by opening the security recommendation for that rule in threat and vulnerability management. In the recommendation details pane, check the user impact to determine what percentage of your devices can accept a new policy enabling the rule in blocking mode without adverse impact to user productivity.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Tool profile: NeedyMantis
• Actor profile: Storm-3069
• Tool profile: Impacket

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 malware and associated activity.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

NeedyMantis masquerading as software

A listing of legitimate, unmodified application folders, along with malicious replacement DLL filenames sideloaded by NeedyMantis.

DeviceFileEvents
| where Timestamp > ago(7d)
| where (
    (FolderPath matches regex @"^[A-Za-z]:\\Program Files\\Poedit" and FileName == "WinSparkle.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\Program Files \(x86\)\\Poedit" and FileName == "WinSparkle.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\USOShared" and FileName == "libcurl.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\VIM" and FileName == "vim64.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\TightVNC\\VIM" and FileName == "vim64.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\office" and FileName == "dbghelp.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\broadcom" and FileName == "dbghelp.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\Intel" and FileName == "jli.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\Program Files\\modifiable" and FileName == "nvml.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\Program Files \(x86\)\\modifiable" and FileName == "nvml.dll")
    or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\ics" and FileName == "nvml.dll")
)
| project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, FileName,
          SHA1, SHA256, MD5,
          InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid,
          InitiatingProcessAccountUpn,
          InitiatingProcessMD5, InitiatingProcessSHA1, InitiatingProcessSHA256,
          InitiatingProcessFolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine,
          InitiatingProcessCreationTime,
          ReportId, TenantId

NeedyMantis C2

This query identifies connectivity to the NeedyMantis command and control site for this activity.

search in (DeviceNetworkEvents, EmailUrlInfo, UrlClickEvents, DeviceEvents, DeviceFileEvents, DeviceProcessEvents)
  "corp.tripswithengine.com"
| where Timestamp > ago(7d)
| extend SourceTable = $table
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountName,
          InitiatingProcessAccountUpn,
          AccountName,
          AccountUpn,
          RemoteIP,
          LocalIP,
          IPAddress,
          RemoteUrl,
          Url,
          UrlDomain,
          FileOriginUrl,
          FileOriginReferrerUrl,
          FileOriginIP,
          ProcessCommandLine,
          InitiatingProcessCommandLine,
          InitiatingProcessFileName,
          FileName,
          FolderPath,
          NetworkMessageId,
          SourceTable

NeedyMantis communications DLL hard-coded user-agent

Identify connectivity utilizing the NeedyMantis hard-coded user-agent.

search in (DeviceNetworkEvents, DeviceEvents, UrlClickEvents, EmailUrlInfo)
  "Firefox/21.0"
| where Timestamp > ago(7d)
| extend SourceTable = $table
| project Timestamp,
          DeviceName = iff(isnull(DeviceName), "", DeviceName),
          AccountUpn = coalesce(InitiatingProcessAccountUpn, AccountUpn, ""),
          AccountName = coalesce(InitiatingProcessAccountName, AccountName, ""),
          RemoteIP = coalesce(RemoteIP, IPAddress, ""),
          Url = coalesce(RemoteUrl, Url, ""),
          UserAgent = AdditionalFields,
          SourceTable

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

NeedyMantis C2

This query identifies connectivity to the NeedyMantis command and control site for this activity.

search in (CommonSecurityLog, SecurityEvent, AzureDiagnostics)
  "corp.tripswithengine.com"
| where TimeGenerated > ago(7d)
| project TimeGenerated,
          DeviceName,
          Computer,
          SourceIP,
          SourcePort,
          SourceUserName,
          DestinationIP,
          DestinationPort,
          DestinationHostName,
          DestinationDnsDomain,
          RequestURL,
          ProcessName,
          DestinationUserName,
          SourceHostName,
          Message,
          $table

NeedyMantis communications DLL hard-code user-agent

Identify connectivity utilizing the NeedyMantis hard-code user-agent.

CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestClientApplication contains "Firefox/21.0" or Message contains "Firefox/21.0"
| project TimeGenerated, DeviceName, SourceUserName, SourceIP, DestinationIP, RequestURL, RequestClientApplication

Indicators of compromise

References

• https://securelist.com/tr/daemon-tools-backdoor/119654/
• https://winsparkle.org/
• https://poedit.com/

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 NeedyMantis: Unpacking a post-compromise malware family used in targeted operations appeared first on Microsoft Security Blog.

Activity associated with Storm-2570, a ransomware affiliate linked to multiple ransomware payloads, illustrates how tracking and responding to ransomware attacks by payload alone can obscure the affiliates carrying out intrusions and the recurring behaviors that defenders can use to detect and disrupt them. Microsoft Threat Intelligence has observed Storm-2570 using consistent post-compromise tools and techniques across deployments involving Qilin, DragonForce, Anubis, and BERT ransomware. Across multiple investigations, Storm-2570 has maintained largely uniform tradecraft, infrastructure overlaps, and repeated use of the same remote access and cloud exfiltration tooling despite operating across multiple ransomware ecosystems.

These findings reinforce the value of examining threat actor behavior across the attack chain rather than treating each ransomware payload as an isolated activity set. Recurring remote access, credential access, lateral movement, security tampering, and data exfiltration activity can help defenders connect related intrusions and respond before ransomware deployment, even when the final payload changes.

In this blog post, we delve into the attack techniques attributed to Storm-2570. While Storm-2570’s methodology aligns with the tactics, techniques, and procedures (TTPs) of many tracked ransomware actors, analysis of their post-compromise tactics provides essential insights into how organizations can harden and defend against ransomware threat actors, informing opportunities to disrupt attackers even if they have gained initial access to a network. At the end of this blog, we also provide a comprehensive recommendation section with detection details.

Who is Storm-2570?

Storm-2570 is a ransomware affiliate that Microsoft Threat Intelligence has tracked since April 2025. We assess that Storm-2570 has operated across multiple ransomware as a service (RaaS) ecosystems, including Qilin, DragonForce, Anubis, and BERT.

To date, Microsoft Threat Intelligence has observed Storm-2570 in multiple investigated intrusions affecting organizations in United States, Canada, United Kingdom, Spain, Netherlands, and Puerto Rico, including healthcare and public health, education, government agencies and services, financial services, energy, consumer retail, Information technology (IT), food and agriculture, consumer services, commercial facilities, non-government organization (NGO), chemicals, critical manufacturing, and transportation.

Unlike actors that consistently support a single ransomware operation, Storm-2570 appears to be a cross-ecosystem threat actor that works with multiple ransomware groups and shifts between operations as opportunities arise, giving the threat actor the flexibility to use and deploy multiple families and improve opportunities for payouts. As a result, organizations could encounter the same actor, tools, and intrusion methods despite different ransomware payloads being deployed.

Storm-2570 attack chain: From initial foothold to impact

While the method through which Storm-2570 gains initial access remains unconfirmed, observed intrusion chains indicate subsequent use of remote management tooling and hands-on-keyboard activity to progress toward credential access, lateral movement, exfiltration, and ransomware deployment.

Across incidents, Microsoft has observed the use of commodity tools in the pre-ransom attack stage even when the ransomware payload changed. These tools include:

• Remote monitoring and management (RMM) tools, including Atera, MeshAgent, ScreenConnect, Splashtop, Remotely_Agent, and NinjaRMM
• Discovery and lateral movement tools, including NetScan, Nmap, PsExec, Impacket, NetExec, and Remote Desktop Protocol (RDP) batch scripts
• Data collection and exfiltration tools, including s5cmd and Rclone

These tools enable remote administration, command execution, persistence, and tunneling or proxy access.

Frequent use of remote management tooling across the attack chain

MeshAgent, a remote device management software, stands out as one of Storm-2570’s most frequently observed remote access and execution tools across multiple intrusions. Rather than appearing as a one-off utility, MeshAgent repeatedly shows up at key points in Storm-2570 attack chains, often after the actor has gained access and is preparing to expand control, run commands, deploy additional tooling, or move toward ransomware impact. In several cases, Storm-2570 used MeshAgent along with MeshCentral as an operational bridge between initial hands-on-keyboard activity and later-stage actions, such as account manipulation, discovery, credential access, security tampering, and ransomware deployment.

Many intrusions tracked by Microsoft have shown Storm-2570 tailoring MeshAgent deployments to the compromised environment. The actor renames MeshAgent-related binaries or services with victim-themed names, likely to make the tool appear more legitimate in the environment. For example, Storm-2570 renames the variant of the meshagent64 RMM tool to include the name of the compromised organization, such as meshagent64-[organization name].exe and uses Base64-encoding to obfuscate the commands being executed. In one such intrusion, MeshAgent was used alongside NinjaRMM before the activity progressed to ntdsutil for credential dumping, network scanning, and Qilin deployment.

Storm-2570 uses a diverse set of remote access tools rather than relying on a single capability. The threat actor rotates among commercially available RMM platforms, remote desktop components, and tunneling utilities, often deploying multiple tools during the same intrusion. For example, Storm-2570 uses Atera to install agents and execute interactive commands, while ngrok and Cloudflared.exe expose RDP services or establish persistent outbound tunnels. Storm-2570 uses AteraAgent to issue commands and to further download and install Splashtop Streamer in compromised environments. Splashtop appears to be the interactive remote control component delivered through Atera, giving the threat actor hands-on keyboard access. The actor also uses tools such as ScreenConnect for command execution and account or domain reconnaissance and installs Remotely_Agent as a persistent remote management service.

Use of tunneling utilities for persistent remote access

Storm-2570 also pairs remote access tooling with tunneling utilities such as Cloudflared.exe to create resilient outbound access paths. In one intrusion, Storm-2570 installed MeshAgent and later created a persistent Cloudflare Tunnel service on the victim host. The tunnel was configured to run automatically as a service under LocalSystem, allowing the threat actor to maintain an encrypted outbound channel from inside the network. This type of tunnel can help bypass inbound firewall restrictions and provide covert remote access for follow-on activity.

Discovery and credential access

Post-compromise, Storm-2570 routinely conducts internal network discovery using tools such as NetScan, SoftPerfect Network Scanner Portable, and Nmap, alongside native discovery commands and file-searching activity. These activities are used to identify reachable hosts and services, map internal networks and remote systems, and locate systems, network shares, and files that may facilitate data collection, credential access, or encryption operations.

For credential access and harvesting, Storm-2570 uses tools like Mimikatz, LaZagne, and pypykatz. Storm-2570 also uses ntdsutil in intrusions for NTDS.dit credential dumping, a credential theft technique against Active Directory domain credentials. The ntdsutil command usage pattern is consistent with creating an Install From Media (IFM) copy of Active Directory database material. In an intrusion context, attackers can use this to obtain NTDS.dit and related registry hives for offline extraction of password hashes and credential material.

The command uses the legitimate Windows ntdsutil.exe to activate the NTDS Active Directory instance and create a full IFM backup in C:\Windows\Temp\<XXXXXXXXX>.

Storm-2570 uses this command to dump or stage Active Directory database NTDS.dit and supporting registry hive material, then copy it off-host and potentially extract domain credential hashes offline, indicating that the actor has high-privilege access to a victim’s domain controller:

Defense evasion

After acquiring privileged credentials, Storm-2570 uses defense evasion tactics preceding ransomware deployment, including antivirus tampering and the modification of Microsoft Defender settings and Defender exclusions. In multiple observed intrusions, Storm-2570 disabled real-time monitoring, added Defender exclusions for C:\PerfLogs to weaken endpoint detections, and modified registry values under Microsoft Defender service keys to further impair protections.

These tactics are consistent across Storm-2570 ransomware intrusions involving Qilin, DragonForce, and Anubis deployment, including cases where the actor used registry changes to alter DisableAntiSpyware, DisableRealtimeMonitoring, and WinDefend service behavior.

Lateral movement and deployment preparation

Storm-2570 moves into lateral movement and deployment preparation phase typically by using a mix of legitimate administrative tooling, offensive frameworks, and remote execution utilities.

Across multiple investigated intrusions, Storm-2570 was observed leveraging PsExec, Impacket, NetExec, RDP batch scripts, and admin shares to reach additional systems, execute commands remotely, and stage tooling across the environment. The actor uses these capabilities to facilitate data exfiltration and prepare victim networks for ransomware deployment. These tools frequently appear alongside earlier discovery activity, credential access, and remote access tooling such as MeshAgent, and often precede the use of s5cmd for exfiltration or ransomware payload execution.

PsExec is one of the most consistent lateral movement and deployment tools used by Storm-2570. The actor frequently uses PsExec, sometimes with host lists such as @ip.txt, to move laterally and install renamed MeshAgent binaries across compromised environments. Storm-2570 utilizes MeshAgent during the lateral movement phase in several intrusions as a remote access tool deployed onto newly compromised systems.

The following are examples of PsExec commands with host lists @ip.txt:

Storm-2570 also uses RDP and RDP-enabling scripts as part of this phase. If RDP is not allowed in the environment, Storm-2570 needs admin privileges to modify the policy and enable it. In several intrusions, rdp.bat script appeared with PsExec, including cases where PsExec ran rdp.bat across hosts using @ip.txt.

The RDP batch script (rdp.bat) enables inbound Remote Desktop access by modifying Terminal Server settings and adding a firewall rule to allow TCP port 3389, as observed in the command below:

Additionally, the threat actor uses ngrok to expose TCP 3389 (default port for RDP), after which PsExec-related activity and security tampering appears. These examples show Storm-2570 combining RDP access, tunneling, and remote execution to sustain hands-on-keyboard control and reach additional systems.

Storm-2570’s use of Impacket and NetExec over Server Message Block (SMB) further supports their lateral movement pattern. Impacket is a collection of open-source Python classes designed for working with network protocols, and is popular with adversaries due to its ease of use and wide range of capabilities. Microsoft Defender for Endpoint has a dedicated attack surface reduction rule to defend against lateral movement techniques used by Impacket; protecting lateral movement pathways can also mitigate Impacket.

The following NetExec SMB command is used to conduct credential theft and reconnaissance against internal Windows hosts:

Data collection and exfiltration

Storm-2570 frequently performs data theft using cloud and file-transfer utilities that are capable of moving large volumes of data quickly from compromised environments to a remote attacker-owned cloud resource. Microsoft has observed Storm-2570 using s5cmd or Rclone to stage and exfiltrate data, often after the actor has already completed discovery, credential access, lateral movement, and remote access setup. Tools like Rclone provide data synchronization capabilities, moving newly created or updated files to cloud resources in real-time to enable continuous exfiltration throughout all stages of the attack without needing attacker interaction.

Most commonly, Storm-2570 relies on s5cmd, a command-line utility designed for managing Amazon S3 and compatible object storage services, for S3-based exfiltration. In multiple intrusions, the actor staged s5cmd.exe alongside a credentials file and used it to copy documents, spreadsheets, images, databases, mail-related files, archives, and other business-relevant file types to S3 buckets. Storm-2570 identifies high-value drives and network shares, stages s5cmd.exe and a credentials file, and then executes run copy (cp) operations with extension filters to transfer selected data to attacker-controlled S3 buckets. To interact with the destination S3 bucket, s5cmd requires credentials for authentication and the credentials file stores the AWS access keys for authentication to the S3 bucket.

The following is an example of s5cmd data exfiltration command lines:

Overall, Storm-2570’s exfiltration tradecraft shows a strong preference for tools that blend into legitimate administrative or cloud-transfer workflows, allowing double-extortion operations: first collecting sensitive data through cloud-transfer tooling, then deploying ransomware.

What Storm-2570 activity means for defenders

Storm-2570 illustrates common human-operated ransomware attacks and how modern ransomware affiliates increasingly operate independently of a single ransomware brand. Ransomware affiliates’ use of common tools, intrusion methods, and operational patterns remain remarkably consistent. Although Storm-2570’s techniques are not novel, recognizing the patterns used by ransomware affiliates can be important for defenders to know to improve prevention, detection, and incident response.

Mitigation and protection guidance

To defend against Storm-2570 TTPs and similar activity, Microsoft recommends the following mitigation measures:

• Follow the defending against ransomware guidance in Microsoft’s ransomware as a service blog post which details how to build credential hygiene as well as how to limit lateral movement using the principle of least privilege.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in Troubleshooting mode to turn off Tamper Protection temporarily without impacting the wider organizational security policy.
• For approved RMM systems used in your environment, enforce security settings where possible to implement MFA. If an unapproved RMM installation is discovered in your network, reset passwords for accounts used to install the RMM services. If a System-level account was used to install the software, further investigation may be warranted.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block execution of potentially obfuscated scripts
  • Block Webshell creation for Servers
  • Block process creations originating from PSExec and WMI commands (Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.)
  • Block use of copied or impersonated system tools
  • Use advanced protection against ransomware

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor Profile: Storm-2570
• Tool Profile: Qilin ransomware
• Tool Profile: Anubis ransomware
• Tool Profile: DragonForce ransomware

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can run the following advanced hunting queries to find related activity in their networks:

Hunt for PsExec-based remote execution and deployment

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("psexec.exe", "psexec64.exe")
    or ProcessCommandLine has_any ("psexec.exe", "psexec64.exe")
| where ProcessCommandLine has_any ("@ip.txt", "-accepteula", "\\")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          SHA256, DeviceId, ReportId
| order by Timestamp desc

Hunt for renamed MeshAgent binaries and services

let MeshAgentTerms = dynamic(["meshagent", "meshagent64", "meshcentral"]);
union isfuzzy=true
(
    DeviceProcessEvents
    | where Timestamp > ago(30d)
    | where FileName has_any (MeshAgentTerms)
        or ProcessCommandLine has_any (MeshAgentTerms)
        or InitiatingProcessCommandLine has_any (MeshAgentTerms)
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath,
              ProcessCommandLine, InitiatingProcessFileName,
              InitiatingProcessCommandLine, SHA256,
              RegistryKey="", RegistryValueName="", SourceTable="DeviceProcessEvents"
),
(
    DeviceFileEvents
    | where Timestamp > ago(30d)
    | where FileName has_any (MeshAgentTerms)
        or FolderPath has_any (MeshAgentTerms)
        or InitiatingProcessCommandLine has_any (MeshAgentTerms)
    | project Timestamp, DeviceName, ActionType, FileName, FolderPath,
              ProcessCommandLine="", InitiatingProcessFileName,
              InitiatingProcessCommandLine, SHA256,
              RegistryKey="", RegistryValueName="", SourceTable="DeviceFileEvents"
),
(
    DeviceRegistryEvents
    | where Timestamp > ago(30d)
    | where RegistryKey has_any (MeshAgentTerms)
        or RegistryValueName has_any (MeshAgentTerms)
        or RegistryValueData has_any (MeshAgentTerms)
        or InitiatingProcessCommandLine has_any (MeshAgentTerms)
    | project Timestamp, DeviceName, ActionType, FileName="", FolderPath="",
              ProcessCommandLine="", InitiatingProcessFileName,
              InitiatingProcessCommandLine, SHA256="",
              RegistryKey, RegistryValueName, SourceTable="DeviceRegistryEvents"
)
| order by Timestamp desc

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 Beyond the ransomware: Tracking Storm-2570’s consistent tradecraft across deployments 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.

Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945, a sub-cluster of Midnight Blizzard, conducting widespread but targeted traffic manipulation attacks involving hospitality sector networks served by captive portals worldwide. Despite some tactic, technique, and procedure (TTP) similarities to the Forest Blizzard DNS hijacking operation that we publicly disclosed in April 2026, we attribute this campaign, which we call CaptiveCrunch, to Storm-2945. As reported by ReliaQuest on July 23, a portion of this activity leverages doppelganger domains mimicking Microsoft online services to conduct follow-on adversary-in-the-middle (AitM) phishing operations that abuse the device code authentication flow in Microsoft Entra ID. Microsoft Threat Intelligence has also identified active traffic manipulation attacks leading to the delivery of malware on impacted systems. Microsoft has observed Storm-2945 leveraging AI to support a significant portion of these operations.

Today, we are sharing our findings on these ongoing intrusions to raise awareness of this threat and enable customers to protect their devices, especially while traveling. We provide our assessment of Storm-2945’s relationship to Midnight Blizzard and analysis of the CaptiveCrunch campaign, detailing the malware and tradecraft used in these operations. We also provide mitigation, detection, and hunting guidance to help organizations identify and defend against Storm-2945 and related activity.

Microsoft Threat Intelligence would like to thank our partners at Anthropic and OpenAI for their collaboration and support during this investigation.

The CaptiveCrunch campaign

Since February 2026, Storm-2945 has conducted AI-augmented operations including targeted device code and OAuth code phishing campaigns leading to Entra device registration and subsequent data collection from Microsoft 365. Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945 manipulating DNS and HTTP traffic from networks served by captive portals to redirect user traffic through actor-controlled infrastructure. Although our investigation into the initial compromise vector for the captive portal networks is ongoing, we have observed notable commonalities in the equipment and management systems used across multiple affected networks. These similarities suggest that the activity might not be limited to isolated compromises of individual venues and could reflect access to shared services within portions of the captive portal ecosystem.

As part of the CaptiveCrunch campaign, Storm-2945 has leveraged their AitM position to redirect users through actor-controlled phishing infrastructure and has also delivered malware purporting to be browser or operating system updates in response to automated connectivity checks issued by users’ browsers. Multiple variants have been delivered, including fully-featured Windows remote access trojans (RAT) in compiled Golang, with functionality to conduct system enumeration, collect files and keystrokes, steal credentials and session tokens, conduct audio and video surveillance, monitor for removable media, and provide the threat actor a remote shell on infected systems.  

The threat actor infrastructure leverages a variety of ClickFix techniques to elicit the user into downloading and executing the malware:

In addition to variants of malware targeting Windows systems, Microsoft Threat Intelligence is also aware of indications that the threat actor might be targeting Android devices with similar techniques as the ClickFix landings also include instructions for Android devices to download and install an APK file.

To date, Microsoft has identified widespread compromise of Wi-Fi networks at hospitality-related organizations and other networks serviced by captive portal equipment in several countries. ReliaQuest has identified this activity not only at hotels, but also conference centers and other shared venues, and assesses that the goal of this activity is to access the accounts of corporate travelers.

Storm-2945 and Midnight Blizzard

Microsoft Threat Intelligence assesses that Storm-2945 is an operational sub-cluster of Midnight Blizzard based on distinctive technical and operational overlaps. These include technical similarities to Storm-2372, a Midnight Blizzard initial access operations sub-cluster, also notable for their device code and OAuth code phishing operations tracked throughout 2025, Microsoft Graph-based email exfiltration, social engineering delivered via commercial messaging apps, and significant similarities in victimology.

Midnight Blizzard is a Russia-based threat actor attributed by the US and UK governments to the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs), and information technology (IT) service providers, primarily in the US and Europe. Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. Their focus is to collect intelligence through longstanding and dedicated espionage in support of Russian foreign policy interests.

Midnight Blizzard operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection. They utilize diverse initial access methods, and Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection.

CaptiveCrunch tradecraft and tooling

CornFlake: Remote access and infostealer implant

CornFlake is a full-featured Windows RAT written in Go that serves as Storm-2945’s primary persistent implant. Microsoft has observed the threat actor rapidly iterating on this malware layer, which features customizable capabilities from the social engineering user interface and data collection capabilities to anti-detection and evasion techniques.

On initial execution, CornFlake operates in dropper mode: it displays a convincing fake progress window designed to occupy the victim’s attention while the binary copies itself to %APPDATA%\svchost32\svchost32.exe and establishes persistence.

Fake window options configurable by the threat actor at build time:

• winupdate — A Windows Update screen displaying “Working on updates… Don’t turn off your computer”
• defender — A Windows Security virus scan
• directx — A DirectX End-User Runtime Web Installer
• vcredist — A Microsoft Visual C++ 2015-2022 Redistributable installer
• sysopt — A disk optimization utility
• netfix — A Windows Network Diagnostics tool
• browser — A browser update prompt
• pdfview — A document viewer installer

CornFlake registers as a Windows service named svchost32 with the display name “Cloud Sync Service” and description “Synchronizes files with the cloud storage provider”, deliberately mimicking the legitimate svchost.exe process. It establishes redundant persistence mechanisms: Windows service registrations, Registry Run keys, named scheduled tasks, and a persistence watchdog routine that runs continuously to restore any persistence mechanism that is removed by defenders or endpoint protection.

For command and control (C2), CornFlake performs an Elliptic Curve Diffie-Hellman (ECDH) P-256 ephemeral key exchange with the C2 server, derives a session key via SHA-256, and communicates over a custom JSON protocol framed within the encrypted channel. This provides an encrypted channel to the C2 server, with each C2 session using a unique ephemeral key, making decryption of captured traffic impossible without the session-specific private key. The runtime configuration file sync.dat supports hot reconfiguration of C2 servers, watched directories, file targeting patterns, and Transport Layer Security (TLS) settings without requiring redeployment.

Once established on a victim system, CornFlake provides the operator with a comprehensive collection toolkit, gated by configuration flags that allow selective activation post-deployment:

CornFlake also exposes a localhost HTTP API server (/upload, /reload, /status) that transforms the RAT into a modular platform: companion or next-stage payloads such as ChocoShell could task file exfiltration, trigger configuration hot reloads or check C2 connectivity using the pre-established secure C2 channel for communication.

ChocoShell: PowerShell infostealer

ChocoShell is the campaign’s Powershell-based infostealer, delivered and executed entirely in-memory. Its primary objective is the high-volume theft of browser session cookies, saved passwords, Microsoft 365 Single Sign-On (SSO) tokens, and Wi-Fi credentials from compromised systems. Where CornFlake provides the operator with a persistent, long-running foothold on the device, ChocoShell is designed to extract the most operationally valuable credentials, giving the operator access to victim cloud environments.

The ChocoShell script was authored with full developer comments that reveal the operator’s intent behind each code decision, including explicit references to Microsoft detection signatures and the reasoning behind specific evasion choices. The consistent coding standard and descriptive commentary suggest the author might have leveraged AI-assisted code generation.

Defense evasion. Upon execution, ChocoShell beacons to a hardcoded C2 server at 213.145.86[.]112 and implements several evasion techniques in sequence. It disables the Antimalware Scan Interface (AMSI) via .NET reflection to prevent ScriptBlock scanning and evades Microsoft behavioral detection that triggers on suspicious PowerShell web request cmdlets. A timing-based sandbox detection check is also employed as a virtual machine (VM) detection mechanism, silently exiting without performing any collection if detected.

C2 communication. ChocoShell communicates with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel. Additional tooling is fetched from /cdn/chunks/polyfill-7e2b.min.js, disguised as a JavaScript polyfill file. This downloaded module is Base64-decoded and executed in memory via [ScriptBlock]::Create(), providing browser encryption key extraction capabilities, SYSTEM token impersonation, and Defender signature locking. Exfiltrated data is sent by POST to /t/event as GZip-compressed, Base64-wrapped JSON.

Privilege escalation. ChocoShell requires administrative privileges for its most impactful capabilities: SYSTEM token impersonation for Chrome ABE decryption, Volume Shadow Copy Service (VSS) shadow copy creation, Defender signature locking. It implements three silent UAC bypass techniques with ordered fallback:

1. SilentCleanup task hijack: Writes a malicious command to HKCU\Environment\windir, then triggers the built-in SilentCleanup scheduled task, which resolves %windir% from the user’s environment, executing the threat actor’s command at elevated privilege. The registry value is cleaned up after two seconds to avoid cloud detection.
2. wsreset.exe COM hijack: Creates a COM handler key in HKCU\Software\Classes and launches the auto-elevating Windows Store reset tool.
3. sdclt.exe folder hijack: Hijacks HKCU\Software\Classes\Folder\shell\open\command and launches the Windows Backup utility with the /KickOffElev flag.

If none of the silent bypasses succeed (for example, the user is not a local administrator), ChocoShell falls back to a visible UAC prompt via Start-Process -Verb RunAs. Notably, the script also contains a variant designed to execute within the WinGet Desired State Configuration (DSC) host process (ConfigurationRemotingServer), suggesting an attack vector through malicious WinGet DSC configuration used in Windows machine provisioning.

Credential and session theft. Once running with elevated permissions, ChocoShell locks Defender signature updates and systematically harvests data from multiple sources. For Chromium-based browsers (Chrome, Edge, Brave, Opera, Opera GX, Vivaldi), it extracts the master encryption key from the browser’s Local State file, handling both the modern ABE scheme (Chrome v127+) and the legacy data protection API (DPAPI)-only scheme. ABE decryption requires SYSTEM-level DPAPI access, which the malware obtains by impersonating a SYSTEM process token borrowed from winlogon.exe, wininit.exe, or services.exe. Locked browser SQLite databases are accessed through three strategies: shared file access, Volume Shadow Service snapshots, and direct copy as a fallback.

As a parallel collection path, ChocoShell launches Chrome, Edge, and Brave with the –remote-debugging-port flag and issues Network.getAllCookies through the Chrome DevTools Protocol (CDP). This completely bypasses ABE, enabling the browser to perform its own internal decryption and returns plaintext cookie values. To handle privilege issues (SYSTEM-launched browsers inherit the wrong token), the malware creates transient scheduled tasks with TASK_LOGON_INTERACTIVE_TOKEN to launch the browser under the signed-in user’s session. After extraction, the browser is stopped and relaunched with –restore-last-session to avoid alerting the user.

For Firefox family browsers (Firefox, Waterfox, LibreWolf, Floorp, Zen), the malware copies unencrypted cookies.sqlite databases from each profile. Additionally, ChocoShell collects Microsoft 365 and Azure Active Directory (AD) access tokens, refresh tokens, and Web Account Manager (WAM) tokens from .tbres files in the Token Broker cache. Collection of these tokens represents a significant threat to enterprise environments, as threat actors could replay SSO sessions without browser cookies. Additionally, Wi-Fi credentials are harvested via netsh wlan show profile with key=clear.

Exfiltration and cleanup. All collected data is aggregated into a JSON structure, GZip-compressed, Base64-encoded, and sent by POST to the C2’s /t/event endpoint. After exfiltration, all collected data variables are nulled, garbage collection is forced, VSS shadow copies are deleted via Windows Management Instrumentation (WMI), temporary elevation scripts are removed, and all UAC bypass registry keys (already cleaned during escalation) are verified removed.

FruitStone: Operator C2 panel

FruitStone is the web-based C2 panel that Storm-2945 operators use to manage the entire CaptiveCrunch campaign infrastructure. Implemented as a single-page application (HTML and JavaScript) serving as the front-end of the C2 server with all functionality exposed without authentication, FruitStone provides a centralized dashboard for managing compromised endpoints, building and deploying new campaign payloads, and reviewing all collected data (such as screenshots, keystrokes, browser credentials).

Operational cover. The panel is branded as “CloudSync Console” with a footer reading “Acuity Systems, Inc. — Cloud Infrastructure Portal v3.2.1,” designed to appear as legitimate enterprise cloud management software if the panel URL is discovered by defenders or hosting providers. This masquerading extends to the CornFlake agent’s service name (Cloud Sync Service) and description (“Synchronizes files with the cloud storage provider”), creating a consistent cover story across the toolchain.

Session management and multi-operator support. FruitStone uses JSON Web Token (JWT)-based authentication, session revocation, and rate limiting with IP blocking to prevent brute force attacks against the panel sign in. Multiple operators could be provisioned with individual accounts, and all active sessions are visible with IP address, user-agent, and creation time to enable operational security awareness across the operators.

Agent management. The panel displays all registered CornFlake agents in a dashboard with real-time status updates via Server-Sent Events (SSE). Each agent card shows comprehensive system information including hostname, username, OS version, CPU, RAM, disk usage, screen resolution, timezone, domain membership, and camera/microphone presence, all collected during the CornFlake posture sweep. Agents are grouped by country and subnet, with geographic distribution visualized on a map.

Operators could interact with individual agents through:

• Remote shell — Interactive cmd.exe or PowerShell command execution with command history
• File system browser — Live directory traversal and arbitrary file download from compromised hosts
• Collection tasking — On-demand screenshot, process list, keylog buffer flush, clipboard dump, security posture survey, ChromeKatz cookie/password extraction, camera capture, and audio recording
• Configuration push — Live runtime reconfiguration of C2 servers, watch paths, and C2 beacon timing
• Agent update — In-place implant update by pushing a new CornFlake build to a running agent
• Agent kill — Remote termination of the CornFlake implant

Campaign builder. A step-by-step wizard enables operators to configure and build new CornFlake payloads directly from the panel:

1. Identity — Campaign ID, C2 host and port, HTTP base URL, executable file name (svchost32.exe by default), and dropper type (C dropper at ~19 KB, Go stub at ~8 MB, or standalone self-installer)

2. Capabilities — Toggle individual collection modules: screenshots, process enumeration, keylogging, clipboard monitoring, posture survey, file exfiltration, and ChromeKatz browser credential theft

3. File Paths — Configure targeted directories and file extensions by category (documents, archives, images, code, data, emails, encryption keys)

4. Evasion — Enable garble symbol randomization (for GoLang payloads), XOR string encoding, GZip upload compression, and debug mode

Infrastructure management. FruitStone provides management interfaces for three layers of supporting infrastructure:

• Proxy relays — Multi-proxy C2 relay architecture with TLS certificate tracking (fingerprint, expiry), health checks, connection counts, bytes forwarded, and rotation capabilities that push updated server lists to all online agents
• Beacon profiles — Configurable timing profiles controlling agent sleep intervals, reconnection delays, TLS Server Name Indication (SNI) spoofing (like teams.microsoft.com), and DNS fallback domains
• Staging servers — External payload hosting infrastructure with push-to-deploy, file listing, and health monitoring

Device code abuse for cloud access

Since July 16, Microsoft has observed a portion of CaptiveCrunch landing pages redirecting users to device code authentication flow experiences. In these cases, users served these landings might be instructed to enter a device code into a legitimate Microsoft sign-in page, a technique commonly referred to as device code phishing.

Device code authentication is a legitimate OAuth workflow designed for devices that cannot support a traditional sign-in experience. However, threat actors could abuse this flow by initiating an authentication request on behalf of a user then convincing the user to enter an actor-controlled device code into a legitimate Microsoft authentication page. When successful, the victim authenticates the threat actor’s session rather than their own.

This activity is consistent with previously reported device code phishing operations conducted by Midnight Blizzard since August 2024. The observed technique does not appear fundamentally novel; however, integrating device code phishing into captive portal and traffic manipulation operations might increase the likelihood that users perceive the authentication request as legitimate. For additional details on Midnight Blizzard-related device code phishing techniques, see: Storm-2372 conducts device code phishing campaign. To understand other threat actors’ use of device code phishing and associated mitigations, see Inside an AI‑enabled device code phishing campaign.

How to protect against CaptiveCrunch activity

Minimize trust in hospitality and guest networks

When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy.

• Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi‑Fi whenever practical.
  • For enterprise-managed devices, organizations can choose to prevent Wi-Fi connections to networks that have not been provisioned via Mobile Device Management (MDM). See: https://learn.microsoft.com/windows/client-management/mdm/policy-csp-wifi#allowmanualwificonfiguration
• Consider using enterprise-managed travel routers or hotspot devices that establish encrypted tunnels back to trusted corporate infrastructure before accessing sensitive resources.
• Avoid downloading software updates, certificates, browser updates, network troubleshooting tools, or security utilities presented through captive portals or other unexpected web prompts.
• Verify update requests through trusted operating system mechanisms rather than pop-up messages or website prompts.

Strengthen identity and access controls

Organizations should assume that public and hospitality network infrastructure might not be trustworthy and should adopt controls that limit exposure to traffic manipulation, credential theft, and device code phishing.

• Educate users to recognize ClickFix-style prompts, fake verification checks, and paste-and-run instructions as malicious, especially when they invoke command interpreters or script hosts such as cmd.exe, PowerShell, rundll32.exe, or mshta.exe.
• Use passwordless solutions like passkeys and implement multifactor authentication (MFA).
  • Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
  • Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.
• 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.
• 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 MFA.
  • 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. 
• Use a Security Service Edge (SSE) solution like Global Secure Access to secure access to any app or resource using network, identity, and endpoint access controls.

Reduce exposure during captive portal registration

Organizations should review what information employees provide to hospitality providers when connecting to guest networks.

• Do not reuse corporate credentials on hotel, conference, or guest-network registration pages.
• Where possible, organizations should evaluate whether venue-provided wireless is required for corporate events and conferences.
• Organizations should minimize unnecessary disclosure of employee identities, organizational affiliations, and travel details when booking accommodations or registering for guest network access, consistent with corporate policy and applicable local requirements.

Microsoft Defender detections and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Defender for Endpoint detects Storm-2945 activity under the detection Suspicious activity linked to a Russian state-sponsored threat actor has been detected. However, these alerts might be triggered by unrelated threat actor activity. The following chart lists Microsoft Defender detections specific to the TTPs utilized by Storm-2945 in this attack.

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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor profile: Midnight Blizzard

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Detect file creation after Wi-Fi connectivity test on devices

The following query checks for a file creation on a device within two minutes of the device performing built‑in Network Connectivity Status Indicator (NCSI) test, which occurs when network connectivity is established to a Wi-Fi network with a captive portal. This activity might indicate an attacker’s initial access file presence on a device.

Please note that not all files discovered through this query might be malicious or related to this threat activity.

let ncsi_endpoints = dynamic(["msftconnecttest.com","edge-http.microsoft.com","msftncsi.com","captive.apple.com","clients1.google.com",
    "clients3.google.com","clients4.google.com","clients6.google.com","connectivitycheck.gstatic.com","connectivitycheck.android.com",
    "android.clients.google.com","www.gstatic.com","detectportal.firefox.com","detectportal.brave-http-only.com","cloudflareportal.com",
    "cloudflarecp.com","cloudflareok.com","connectivity-check.warp-svc","connectivity.cloudflareclient.com","spectrum.s3.amazonaws.com",
    "nmcheck.gnome.org"]);
let NCSIEvents = DeviceNetworkEvents
    | where Timestamp > ago(7d)
    | where RemoteUrl has_any (ncsi_endpoints)
    | project NCSI_Timestamp = Timestamp, DeviceId, DeviceName, RemoteUrl, NCSI_ReportId = ReportId, NCSI_InitiatingProcessFileName = InitiatingProcessFileName, NCSI_InitiatingProcessCommandLine = InitiatingProcessCommandLine, NCSI_AccountName = InitiatingProcessAccountName;
let FileDownloadEvents = DeviceFileEvents
    | where Timestamp > ago(7d)
    | where ActionType == "FileCreated"
    | where FileName has_any (".exe",".msi",".zip",".rar",".7z")
    | project Download_Timestamp = Timestamp, DeviceId, FileName, FolderPath, Download_ReportId = ReportId, Download_InitiatingProcessFileName = InitiatingProcessFileName, Download_InitiatingProcessCommandLine = InitiatingProcessCommandLine, Download_AccountName = InitiatingProcessAccountName;
NCSIEvents
| join kind=inner (
    FileDownloadEvents
) on DeviceId
| where Download_Timestamp >= NCSI_Timestamp and Download_Timestamp 

Detect connectivity to Storm-2945 infrastructure

The following query checks for connectivity to Storm-2945 infrastructure observed in this attack activity.

let target_domains = dynamic(["ms365-device.com", "ms365-live.com", "m365-owa.com", "owa-ms365.com"]);
let target_ips = dynamic(["31.57.243.154", "38.146.28.75", "38.146.28.132", "104.194.159.150", "107.189.26.194", "213.145.86.112"]);
DeviceNetworkEvents
| where RemoteUrl has_any(target_domains) or RemoteIP in (target_ips)
| project
    Timestamp,
    DeviceName,
    DeviceId,
    RemoteUrl,
    RemoteIP,
    LocalIP,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    AccountName = InitiatingProcessAccountName,
    ReportId

Detect CornFlake RAT presence on affected systems

The following query checks for the presence of the CornFlake RAT binary.

DeviceProcessEvents
| where FolderPath == "%APPDATA%\\svchost32\\svchost32.exe"
   or FolderPath endswith @"\svchost32\svchost32.exe"
| project Timestamp, DeviceName, DeviceId, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName, ReportId

Detect CornFlake RAT Windows service registration

The following query checks for the CornFlake RAT Windows service registration.

DeviceRegistryEvents
| where RegistryKey has @"\SYSTEM\CurrentControlSet\Services\svchost32"
| where ActionType == "RegistryValueSet"
| where (RegistryValueName == "DisplayName" and RegistryValueData == "Cloud Sync Service")
    or (RegistryValueName == "Description" and RegistryValueData == "Synchronizes files with the cloud storage provider")
| project
    Timestamp,
    DeviceName,
    DeviceId,
    RegistryKey,
    RegistryValueName,
    RegistryValueData,
    ActionType,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessAccountName,
    ReportId

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect network IP and domain indicators of compromise using ASIM

The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser:

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["213.145.86.112"]);
let ioc_domains = dynamic(["213.145.86.112/t/pixel.gif", "213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "213.145.86.112/t/event"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect web sessions IP and file hash indicators of compromise using ASIM

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser:

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["213.145.86.112"]);
let ioc_sha_hashes =dynamic([“918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593”, “be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42c”]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect domain and URL indicators of compromise using ASIM

The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:

// file hash list - imFileEvent
// Domain list - _Im_WebSession
let ioc_domains = dynamic(["https://213.145.86.112/t/pixel.gif", "https://213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "https://213.145.86.112/t/event"]);
_Im_WebSession (url_has_any = ioc_domains)

ChocoShell C2 communications

The following query detects ChocoShell communications with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel.

let lookback = 30d;
let ioc_url_artifacts = dynamic(["/t/pixel.gif?m="]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstDomain  in (ioc_url_artifacts)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Indicators of compromise

References

• https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/
• https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication

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 CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft appeared first on Microsoft Security Blog.

The second quarter of 2026 (April–June) was largely defined by the continuing downstream effects following Microsoft’s Digital Crimes Unit-led disruption efforts against the Tycoon2FA phishing-as-a-service (PhaaS) platform in March. Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs. Despite ongoing efforts to rebuild operations, Tycoon2FA did not recover its previous scale or influence during Q2, and no single service emerged to replace the platform at comparable scale.

These trends reflect both the measurable impact that disruption operations can have on phishing ecosystems and the adaptability of threat actors as they diversify delivery channels. At the same time, Microsoft Threat Intelligence observed continued growth in Teams-based social engineering, particularly voice phishing (vishing), with weekly malicious call attempts reaching nearly ten times the mid-2025 baseline by the end of the quarter. This activity illustrates how threat actors continue to expand beyond email into trusted workplace communication platforms where communications may appear more trustworthy to users.

Microsoft detected approximately 7.6 billion email-based phishing threats throughout the quarter, with monthly volumes declining modestly from 2.7 billion in April to 2.4 billion in June. Credential phishing remained the dominant objective behind malicious payloads, while business email compromise (BEC) activity largely returned to historical norms after a brief, anomalous surge in April. Notable campaigns observed during the quarter also demonstrated how threat actors combine automation, trusted services, and multi-stage delivery chains to scale operations. These campaigns ranged from an automated BEC campaign that reached more than 67,000 users across 42,000 organizations in under three hours, to a multi-stage phishing campaign that used nested EML files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

This blog provides a view of email threat activity across the second quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code and CAPTCHA-gated phishing activity, malicious payload trends, BEC activity, the growth of Teams-based threats, and notable campaigns observed during the quarter. We also provide recommendations and Microsoft Defender detections to help organizations identify and mitigate evolving threats while prioritizing defensive measures.

Tycoon2FA Q2 disruption impact

The disruption operation that Microsoft’s Digital Crimes Unit launched against Tycoon2FA infrastructure in early March continued to produce measurable results throughout Q2 2026. After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year. For reference, the average monthly volume of phishing messages linked to Tycoon2FA during the second half of 2025 was 15.1 million. By the end of Q2, volumes were running at roughly 8% of that baseline, representing a 92% total decline since the disruption operation began.

Tycoon2FA’s influence across two primary phishing tactics, QR code lures and CAPTCHA-gated landing pages, also continued to decline throughout the quarter:

• CAPTCHA-gated phishing: Tycoon2FA’s share of CAPTCHA-gated phishing sites fell from 41% in March to 16% in April and 12% by June, down from a peak of 76% in December 2025.
• QR code phishing: The share of QR code campaigns redirecting to Tycoon2FA domains decreased from 20% in March to 17% in April and 14% by June, down from a peak of 33% in November 2025.

These declines indicate that the platform’s customer base has not migrated to replacement infrastructure at anything close to the scale they previously operated.

After being forced off Cloudflare, which had provided anti-analysis protection that made Tycoon2FA pages harder to scan and take down, the service continued to rely on infrastructure hosted on the .RU top-level domain (TLD), a shift that began in late March. More than 40% of newly observed Tycoon2FA domains used .RU registrations throughout Q2. While this reflects an ongoing effort to find replacement hosting, Tycoon2FA’s role in the phishing ecosystem has nonetheless been significantly diminished and the pace of recovery has been slow.

QR code phishing attacks

After peaking at 18.7 million attacks in March, the highest monthly volume in at least a year, QR code phishing declined for three consecutive months in Q2. Volume fell 7% in April to 17.4 million, then dropped more sharply in May (-38%) and June (-22%), closing the quarter at 8.3 million attacks. By June, QR code phishing had returned to levels last seen in mid-2025.

The delivery methods used in QR code attacks shifted notably during Q2. PDF attachments remained the dominant vehicle throughout, but their dominance weakened after April:

• PDF attachments peaked at 79% of QR code attacks in April before falling to 59% in May and 58% in June. By raw volume, malicious PDFs containing QR codes dropped more than 60% between April and June.
• DOC/DOCX attachments moved in the opposite direction, increasing 30% in May to account for 38% of QR code payloads, the highest share since December 2025. By June, DOC/DOCX payloads reached 40% of QR code attacks. This swap between PDF and DOC/DOCX dominance is a pattern that has recurred throughout the past year, as operators appear to rotate between delivery formats.
• Email-embedded QR codes, which had surged 336% in March and accounted for 5% of QR code attacks, effectively disappeared in Q2. This delivery method dropped to near-zero across all three months, leaving QR code phishing almost entirely an attachment-based tactic.

CAPTCHA-gated phishing tactics

After accumulating to nearly 12 million attacks in March, the highest monthly volume observed over the past year, CAPTCHA-gated phishing declined sharply throughout Q2. Volume fell 32% in April to 8.2 million, then dropped another 65% in May and 24% in June, closing the quarter at just 2.2 million attacks. Since the March peak, CAPTCHA-gated phishing has fallen more than 81%, reaching its lowest monthly volume in more than a year.

The rapid rotation of delivery methods that characterized Q1 continued into Q2, with no single payload type maintaining the top position for more than one or two months:

• PDF attachments surged to 63% of CAPTCHA-gated attacks in April, the highest single-payload share observed in the past year, after more than quadrupling in March. This dominance was short-lived, however. PDF volumes dropped 69% in May and another 70% in June, falling to just 22% of attacks by the end of the quarter.
• HTML attachments, which had been a major delivery vector through January (37% of attacks), declined sharply during Q2. After declining to 8% in April, HTML payloads fell to just 3% in May before recovering slightly to 5% in June, their lowest sustained share in at least a year.
• SVG files reached their lowest observed volume in April (5% of attacks) before rebounding to 12% in May and 26% in June. While still well below the levels seen when Tycoon2FA actively used SVG files, this gradual recovery bears monitoring.
• Email-embedded URLs reclaimed the top position in June for the first time since December 2025, accounting for 30% of CAPTCHA-gated attacks. This was more a function of every other delivery method declining in raw volume than a resurgence in URL-based delivery. The actual volume of URL-delivered CAPTCHA-gated phish in June was still far lower than most months over the past year.
• DOC/DOCX files declined from their March spike, falling steadily from 15% to 10% of attacks over the quarter.

Tycoon2FA’s continued decline was a significant factor in the overall volume reduction. The platform’s share of CAPTCHA-gated phishing fell from 41% in March to 16% in April, 18% in May, and 12% by June, down from a peak of 76% in December 2025. No single service has emerged to fill the gap at comparable scale, contributing to the sustained decline in CAPTCHA-gated phishing activity overall.

Malicious payloads

Credential phishing continued to dominate the malicious payload landscape throughout Q2, accounting for 94–96% of all payload-based attacks each month. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery represented just 4–6% of payloads, consistent with its long-term decline.

HTML and PDF attachments remained the two most common malicious payload types across the quarter, together accounting for roughly 60–70% of all payload-based attacks each month:

• HTML attachments held the top position across all three months at 35–41% of attacks. After peaking in April, HTML payload volume declined 33% in May and another 17% in June.
• PDF attachments consistently ranked second at 24–31% of attacks. PDF volume was relatively stable in April before declining 41% in May and 4% in June.
• SVG files continued the decline that has tracked closely with Tycoon2FA’s diminishing activity. After peaking at 23% of malicious payloads in July 2025, SVG’s share fell to around 7% by Q2, consistent with SVG’s historical role as a preferred Tycoon2FA payload format.
• DOC/DOCX and ZIP/GZIP files oscillated without a clear directional trend. DOC/DOCX increased 26% in May before falling 17% in June, while ZIP/GZIP attachments declined 48% in April, rebounded 27% in May, then dropped 40% in June.
• ICS files (calendar invitations), while still a small share of overall payload volume (roughly 4%), nearly quadrupled in June (+277%). These attacks take advantage of the fact that calendar invitations are processed differently than standard email attachments and can inject malicious links into a user’s calendar without requiring an explicit open-and-click interaction.
• EXE files continued to decline, falling to their lowest monthly volume in June, reflecting the broader shift away from traditional malware delivery via email attachments.

Business email compromise

April 2026 produced the most anomalous BEC data point in more than a year: nearly 9 million attacks, a 121% increase from March and more than double any previous month. The spike was short-lived as volume fell 62% in May to 3.4 million and settled at 3.9 million in June, both figures consistent with the monthly baseline that had held throughout the prior year. The April surge appeared to be driven by a small number of high-volume campaigns rather than a fundamental escalation in BEC activity.

The composition of BEC attacks remained consistent throughout Q2. Generic outreach messages (like “Are you at your desk?”) accounted for 87–92% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 3–8%. This pattern underscores that BEC operators overwhelmingly favor establishing conversational rapport with targets before making fraudulent requests, rather than leading with direct financial asks.

Within the smaller subset of explicit financial requests, the most notable trend was the near-disappearance of fake invoice payment requests:

• Invoice payment requests fell 67% in May and another 77% in June, reaching their lowest volume in more than a year. By June, invoice-themed BEC accounted for less than 0.4% of all attacks, down from around 3.6% in March.
• Payroll update requests declined moderately across the quarter, from roughly 4% of attacks in March to 2.3% by June.
• Gift card requests remained at roughly 1–4% of attacks, with no clear directional trend.

Microsoft Teams threats

While email remains the dominant initial access vector, threat actors increasingly abused Microsoft Teams during Q2 to deliver social engineering, phishing, and malware payloads. Unlike email, Teams traffic typically bypasses secure email gateways and benefits from the perceived legitimacy of a colleague-initiated chat, which can make lures particularly effective in this environment.

Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June. Financial and executive impersonation has remained largely absent from Teams-based attacks over the past several months.

The dominant lure theme remained technical support impersonation, with attackers posing as an employee’s information technology (IT) help desk, typically warning of an impending account lockout. However, the way attackers presented themselves continued to evolve:

• Display names shifted away from IT- or help desk-branded identities. For the second consecutive month, more than half (52%) of Teams-based phishing attacks in June used generic display names rather than obvious IT support impersonation.
• Attacker email addresses associated with these chats moved away from support-themed domains toward software-as-a-service (SaaS) terminology, scan/update language, and infrastructure keywords. This shift may align with the broader rise of ClickFix-style attacks adopting update-fix and similar themes.

Vishing through Teams showed the steepest growth of any threat category tracked in this report during Q2. Average weekly malicious call attempts rose 31% from April to May and another 27% into June, with the final two weeks of June recording the two highest weekly volumes on record. Since the beginning of 2026, weekly vishing attempts have increased roughly 80% and now run at nearly ten times the mid-2025 baseline. Attackers time these calls deliberately when targets are most likely to be online and active, with the heaviest activity falling between 14:00 and 20:00 UTC, Monday through Friday, with near-zero weekend activity. Notably, a growing share of these calls go unanswered, end quickly, or are rejected outright, partly reflecting Microsoft’s ongoing efforts to harden the Teams attack surface and improve protections against social engineering abuse.

Notable phishing campaigns

The following campaigns were observed during the quarter and highlight notable credential phishing, BEC, and malware delivery activity. For analysis of a separate code of conduct-themed credential phishing campaign observed in April of Q2, see Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise.

Automated BEC campaign scales aging report and payroll diversion lures

On June 1, 2026, Microsoft Defender Research observed a high-volume BEC campaign that used automation to operate at scale. Over a send window of under three hours (14:08–16:52 UTC), the actor reached more than 67,000 users across more than 42,000 organizations, almost exclusively in the United States. Targeting spanned a broad range of industries rather than a single vertical, most notably retail and consumer goods (17%), technology and software (15%), and financial services (14%). The campaign ran two lures in succession from shared infrastructure: arequest impersonating sales executives to obtain aging report data and customer contact details, and a payroll diversion pretext impersonating the CEO or President to redirect salary payments to attacker-controlled bank accounts.

Delivery was fully scripted. The messages were generated programmatically using Python’s email.mime library, identifiable from its default MIME boundary format (===============[integer]==), and dispatched through the Amazon Simple Email Service (SES) API rather than a manual webmail interface, as indicated by the SES Feedback-ID and Message-ID formats. This allowed the actor to iterate through a recipient list and inject per-message variables (like spoofed executive display names, recipient addresses, and unique tracking identifiers) at volume. Messages were sent from a DomainKeys Identified Mail (DKIM)-configured Slovak domain (ecajovna[.]sk) through SES, so they passed Sender Policy Framework (SPF) and achieved DKIM alignment. Neither lure contained a malicious link or attachment; both relied on eliciting a reply to attacker-controlled mailboxes that mimicked legitimate providers (ilyff[.]com, j-gmails[.]com, x2mails[.]com).

Automation also extended to targeting and follow-up. The actor addressed generic role-based mailboxes (like “ar”, “accountsreceivable”, “hr”, “payroll”) rather than named individuals, reducing per-target effort. Each message embedded a 1×1 open-tracking pixel served from an Amazon SES engagement subdomain, with per-message identifiers that let the actor confirm which recipients opened the email and prioritize follow-up against those targets. The combination of scripted message generation, API-based bulk delivery, role-based targeting, and automated engagement tracking allowed a single actor to run a personalized, financially motivated BEC operation at a scale not practical to execute manually.

Staff update campaign with nested EML file and calendar invitation leads to BAT file dropper

Between June 14–15, 2026, Microsoft Defender Research observed a phishing campaign targeting more than 107,000 users across nearly 19,000 organizations, almost exclusively in the United States. The campaign targeted a broad range of industries rather than a single vertical, most notably financial services (17%), technology and software (14%), and retail and consumer goods (14%). Emails impersonated an internal “Internal Affairs – Financials & Staff Updates” function at the recipient’s own organization, with the display name and subject line both opening with the recipient’s organization name and closing with constant trailing text. The messages were sent from a Postfix host on 9i6pokerdepot[.]com routed through Barracuda’s outbound mail service, and DKIM passed cleanly for the sending domain.

The visible email body contained minimal content. One line told the reader to download the attached file for the meeting summary, followed by a confidentiality notice. Each message carried two attachments: a nested EML posing as a Teams archive recording, and an ICS calendar invite addressed to placeholder administrative accounts at the recipient’s domain. The nested EML’s file name retained an unfilled template token ( {{DATE2}} ), indicating a per-recipient templating tool.

When opened, the EML displayed a voicemail notification with a single action button. That button pointed to Microsoft’s OAuth sign-in endpoint at login.microsoftonline[.]com, with parameters that asked for a silent sign-in attempt against an Entra application that the attacker had registered as multi-tenant.

Because no active sign-in session could satisfy the silent request, Microsoft’s authentication service redirected the recipient to the destination the attacker had pre-registered on the application. That destination was a path on clickup-attachments[.]com, ClickUp’s public attachment host, and served a Windows batch file named Financial_report.bat. Because the link routed through Microsoft authentication infrastructure, both recipients and URL scanners saw a login.microsoftonline[.]com link.

The batch file ran a hidden PowerShell command that pulled installer.exe from pixeldrain[.]com, saved it under the user’s Temp directory, ran it with a silent flag, and deleted the dropper on exit. Rather than stealing credentials, the campaign ultimately resulted in silent malware execution on the user’s Windows device.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Defender for Endpoint

The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.

• Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site

Microsoft Defender for Office 365

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Activity Profile: Email threat landscape, June 2026
• Activity Profile: Email threat landscape, May 2026
• Activity Profile: Email threat landscape, April 2026
• Tool Profile: Tycoon2FA
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business Email Compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise (IOCs)

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 Email threat landscape: Q2 2026 trends and insights appeared first on Microsoft Security Blog.

As threat actors operationalize AI to accelerate attacks, they are also leveraging the wider global interest around AI itself as a social engineering lure. In recent months, Microsoft Threat Intelligence has observed a growing number of campaigns that impersonate the branding of popular AI platforms such as ChatGPT, Microsoft Copilot, DeepSeek, and Anthropic’s Claude as lures. These campaigns, which don’t represent compromise of services, span phishing, malvertising, and search engine optimization (SEO)-driven attacks that ultimately lead to credential theft, financial fraud, or malware infection.

Threat actors are quick to capitalize on highly anticipated launches or emerging trends, leveraging trusted branding and exploiting user curiosity to improve the success rates of their campaigns. Despite the AI-themed lures, however, these campaigns combine longstanding tactics, such as urgency-driven messaging, abuse of trusted services, and multi-stage redirection chains that require user interaction to evade detection.

While traditional lures like invoices, payment notifications, or delivery alerts remain effective and continue to be widely used, AI-themed lures reflect a shift in social engineering that is likely to persist as a long-term tactic used by threat actors, from cybercriminal groups to nation states. Notably, Microsoft Threat Intelligence has observed the initial access broker Storm-3075 employing AI-themed malvertising to deliver payloads, including malware signed by the malware-signing-as-a-service (MSaaS) offering attributed to the financially motivated threat actor Fox Tempest, on behalf of multiple downstream actors.

This blog details several of the campaigns observed by Microsoft Threat Intelligence in the past few months that used AI brands and references as lures, and provides guidance to help users and organizations detect, mitigate, and respond to these threats. Importantly, Microsoft believes that the activity noted in this blog is purely abuse of AI brand names as lures, not reflecting a compromise of any referenced vendor. As threat actors scale their operations with AI, organizations should leverage AI-powered security capabilities to enhance visibility, automate detection, and accelerate response across email, identity, and endpoint surfaces.

ChatGPT-themed lure leads to phishing kit collecting credit card data

On May 5, 2026, Microsoft detected a ChatGPT-themed phishing attack that delivered malicious URLs leading to phishing pages that collected credit card and personal information such as names and addresses. This phishing activity, which consisted of 4,500 emails sent to targets in South Africa (97%), was part of a broader campaign using similar themes and infrastructure. We also observed this campaign delivering as much as 100,000 emails on a single day to targets in Switzerland, Austria, and South Africa affecting a broad range of industries, including higher education and professional services.

The emails used the sender display name ChatGPT and the subject “To ensure your ChatGPT Plus continues to work – please update your payment method”. The emails posed as an urgent request to update the ChatGPT Plus subscription payment method. They warned the recipient that if a new payment method was not provided within seven days, the account would be downgraded to a free plan. A ChatGPT logo was prominently displayed at the top of the email body.

The phishing email contained a clickable Update payment method button, which did not directly send users to the attacker-controlled site. Instead, users were redirected through a series of legitimate and abused redirector hops. This is a common technique used by threat actors to exploit the reputation of trusted domains and bypass email filters, evade detection, and track victim engagement.

Targets were first directed to grupoconstat[.]bitrix24[.]com[.]br (a legitimate customer relationship management (CRM) service), which redirected to awstrack[.]me (an Amazon domain used for tracking email opens and clicks), which in turn redirected to a Rebrandly URL (a legitimate but often abused URL shortener service). Targets were finally sent to a likely legitimate but compromised domain legendarytrendsbay[.]shop where the threat actor had placed the phishing page in the /ChatGPT/ folder.

The landing page did not immediately display the phishing content. It first required visitors to pass a custom CAPTCHA, which was a simple Update payment button. If they clicked this button, users were sent to the next page where personal information, including first name, last name, and address was collected. The final page then collected the name, credit card number, expiration date, and card verification code.

Claude-themed phishing campaign collected credentials and access tokens

From April 20 to 22, 2026, Microsoft observed a phishing campaign impersonating Anthropic-branded services to target users with account-related lures tied to the Claude AI platform. The campaign sent phishing emails to targets across more than 2,000 organizations, primarily in the United States (62%), the United Kingdom (18%), and India (9%). While this campaign impacted a broad range of industries, it was most notably focused on information technology (56%), other business entities (21%), and financial services (8%).

The campaign used enforcement-themed messaging claiming that the recipient’s account was in violation of acceptable use policies and required immediate action. The emails impersonated Anthropic’s popular AI service Claude using the display names Anthropic Teams and Anthropic PBC, masquerading as legitimate account-related communications. Subject lines followed a consistent structure of “Claude Appeal Request” combined with date elements.

The email body was delivered as HTML and included Anthropic and Claude branding. The message informed recipients that their account was violating “AUP (Account Usage Policy)” and that Anthropic had “initiated an appeal procedure”. The message instructed recipients to review the attached material to access their appeal and indicated that Claude features would be limited pending review.

The email attachment was a PDF named Fill and Sign Claude Appeal Form.pdf, which was designed to resemble an official process tied to Claude account enforcement. The document presented an appeal workflow, prompting users to copy an appeal ID and click the “Claude Appeal” link, which initiated the credential harvesting process.

When clicked, the link embedded in the PDF directed users to an attacker-controlled domain, dash.awaydouble[.]org. The initial landing page displayed a Cloudflare verification prompt, presented as confirming the user was arriving from a “legitimate session”. This step likely served as a gating mechanism to impede automated analysis and sandbox detonation.

Users who completed the verification were redirected to another Claude-themed landing page hosted on servicing.pureplantcravings[.]com. This page was named “Account Appeal Notice” and contained “Account Security & Compliance” message informing users that their account had been flagged for repeated violations of usage policies. The page provided a reference date and a one-time access code, prompting users to copy the code and continue.

Clicking “Continue” redirected users to the final page, which was not available at the time of analysis. Source code revealed conditional redirect logic that routed users to one of two final landing pages, depending on whether the site was accessed through mobile device or a desktop system.

While the final redirect destination was no longer active at the time of analysis, infrastructure overlap, including shared intermediate domains and consistent redirect logic, strongly suggested that users were ultimately presented with a Microsoft sign-in experience. This final stage is consistent with adversary-in-the-middle (AiTM) tactics designed to intercept authentication tokens and facilitate account compromise.

“Awesome AI Windows Plugin” malvertising deploys Vidar stealer

Since at least early 2026, Microsoft Threat Intelligence has observed malvertising campaigns that use AI-themed terms such as “Awesome AI Windows Plugin” and “Flux Pro AI” in social engineering lures in malicious popups, in malware executable names, and GitHub repository and folder names throughout the attack chain. These campaigns are notable for their scale and velocity, moving from launch to mass impact within hours and infecting tens to hundreds of thousands of endpoints. The malware delivered in these campaigns is frequently code-signed, lending an additional layer of perceived trust to both the operating system and the user.

Microsoft attributes this malvertising activity to an initial access broker and malware distributor tracked as Storm-3075. We assess that Storm-3075 delivers final payloads on behalf of multiple downstream actors. While the example campaign described in this section delivered Vidar Stealer, we have also observed this campaign distributing Lumma Stealer, Hijack Loader, and Oyster.

On March 13, 2026, a single campaign run targeted over 66,000 devices. Microsoft has revoked the related signing certificate and GitHub has taken down the associated repository, helping to prevent tens of thousands of additional infections. Given the nature of the attack source, majority of impacted devices were likely consumer rather than enterprise endpoints. Telemetry showed global distribution, with the top affected countries being Japan, South Africa, the United States, and France.

Analysis of the redirection chain determined that the attack likely originated from free movie streaming sites. Infections on such sites typically begin when users interact with embedded movie players or click popups. Malvertising embedded in such sites can redirect users to a range of unwanted content, including malware. In this campaign, users were redirected to a page advertising a download for an “Awesome AI Windows plugin”, a fictitious product name. The plugin purported to help users watch free, high-quality videos, a lure aligned with the context of users already streaming free or pirated content.

Clicking the download button retrieved an executable named ProFluxeFlowAi-win-Setup.exe, which the user then had to manually launch. The file name mimicked a legitimate product with a similar name, Flux Pro AI, which supports text, image, and video creation. This lure reinforced the perceived legitimacy of the executable within the streaming of free movies context. The executable itself was hosted on GitHub in a repository named shippingtechnologymovie under a folder named AI-techVideos, both tailored to the AI video helper narrative.

The malware executable was signed with a fraudulently obtained Microsoft-issued code-signing certificate obtained through Artifact Signing (certificate thumbprint: 4f5c5b3ef45cfff7721754487a86aeff9a2e6e32). Microsoft attributes the signing service used by the threat actor to Fox Tempest, a financially motivated threat actor operating a malware-signing-as-a-service (MSaaS) offering used by other threat actors. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), in partnership with Resecurity, facilitated a disruption of Fox Tempest infrastructure and access model.   

Signing malware through such a service is expensive; however, for a threat actor targeting tens or hundreds of thousands of infections, the cost can be justified by the additional level of trust signed binaries imply to both the operating system and the user. Signed malware also tends to exhibit lower detection rates early in the infection lifecycle, extending the window of effective distribution.

Another notable feature of the malware is that, immediately after launch, it displays a window with a “Continue” checkmark and does not proceed until the box is clicked. This extra user interaction step is uncommon. We assess that this technique is intended to hide the malicious functionality from sandboxes and automated analysis environments that cannot dynamically perform the click. Until the user clicks “Continue,” the malware performs no suspicious activity on the operating system. This technique is functionally analogous to the CAPTCHAs frequently seen in phishing attacks.

Once the user clicks “Continue”, the executable drops and runs a malicious Python-based downloader. Both the Python interpreter and the downloader script are saved in the \AppData\Local\ folder as pythonw.exe and LICENSE.txt, respectively. The malicious script runs shellcode that loads the next-stage malware from the command-and-control (C2) domain brokeapt[.]com. The final payload observed in this campaign was Vidar infostealer.

Fake DeepSeek V4 installers on GitHub delivered Vidar Stealer

In April 2026, Microsoft identified a social engineering campaignsocial-engineering campaign that leveraged interest in the newly released DeepSeek V4 by impersonating it through a fraudulent GitHub repository and organization. The campaign abused GitHub’s release-asset infrastructure to deliver information-stealing malware such as Vidar stealer. Search engines increased the exposure of the malicious repository, exacerbated by the fact that DeepSeek did not publish an official V4 repository on GitHub.

Our investigation shows the DeepSeek lure is one identity in a broader rotating brand-abuse ecosystem that recycles whichever AI tool is trending into a fresh malware download experience. After discovering this activity, Microsoft shared the details with GitHub, and GitHub has since taken down the malicious organization, repository, and operator account.

On April 24, 2026, within hours of DeepSeek officially previewing its new V4 frontier model, a threat actor initiated the attack chain that can be summarized as:

1. Resource development on GitHub, all within roughly 45 minutes: A new GitHub organization (DeepSeek-V4), a single repository (deepseek-V4), and a release tag (deepseek-V4). The repository was decorated with stolen DeepSeek branding, real benchmark data, and SEO-optimized topics.
2. Search-driven discovery: Users found the repository through GitHub repository search, search engines, social sharing, and AI-assisted search results pointing to the lure page. The repository’s llms.txt and topic taxonomy were designed to be discovered by both classical search engines and large-language-model-powered search; observed top-rank results on search engines are consistent with that design, though we did not observe paid advertising and therefore do not assess this as malvertising.
3. Archive download from GitHub’s release-asset CDN: The release page hosted two archives, deepseek-v4-pro_x64.7z and deepseek-v4-flash_x64.7z.
4. User extraction: Users needed to extract the executable from the archive using common Windows archive tools.
5. Payload execution: The archives contained a heavyweight Win32 PE that masqueraded as the DeepSeek installer. At least one confirmed victim endpoint revealed the extracted payload landed at: C:\Users\<user>\Downloads\Programs\IA DeepSeek-V4\deepseek-v4-flash_x64.exe.
6. Active payload rotation: The threat actor actively rotated archive content while preserving file names and the release page. We observed at least three distinct archive hash generations in three days.

Microsoft Defender telemetry observed the first victim download approximately four hours later. The threat actor’s operational tempo on April 24, 2026, is consistent with a prepared, rehearsed workflow. The repository was designed to be convincing at a glance. It accumulated 91 stars and 27 forks within four days, though the proportion of organic versus inflated engagement is not independently confirmed. The attacker invested in several credibility-building elements:

• Stolen branding: The repository’s README and assets folder embedded the legitimate DeepSeek whale logo, copied from the real deepseek-ai/DeepSeek-V2 repository.
• Real benchmark data as lure: The release notes displayed authentic DeepSeek V4 benchmark scores against Claude Opus 4.6, GPT-5.4, and Gemini 3.1 Pro, copied from the official release announcement.
• Action-oriented SEO topics: The repository was tagged with deepseek-v4, deepseek-v4-download, deepseek-v4-downloader, deepseek-v4-install, and deepseek-v4-installer, which are queries users are expected to use when intent-shopping for an installer.
• LLM-aware discoverability: A top-level llms.txt file repeated the same SEO copy in a format aimed at AI-assisted search engines.

On closer inspection, the staging gives the operation away: the repository contained only a README, LICENSE, llms.txt, and stub assets/ and inference/ directories with no real model code; all nine commits were made in a single burst on April 24, 2026 by a single author; the README claimed an MIT license while repository metadata specified Apache 2.0.

Once the lure was live, search engines increased the exposure of the malicious repository. We tested the queries an interested user would naturally try when looking for DeepSeek V4 on GitHub or the open web. In a snapshot captured on April 28, 2026, the results were as follows (search results are volatile and may differ at the time of reading):

The 7z archives hosted on GitHub contained a loader executable such as SHA-256: 5455341ed1bbe75a664fca2dd0794c508e1874f75360253a7ff5bc119bc92d80. The loader was observed downloading and installing Vidar stealer and potentially additional malware.

Lastly, Microsoft observed that the DeepSeek-themed payloads share infrastructure with a much larger rotating fake-AI / fake-tool ecosystem. The same shared loader hash (SHA-256 5455341…) appeared under file names impersonating GPT-5.5, Claude Code, Kimi, Seedance, Gemma, GrokCLI, Manus AI, FraudGPT, and others (see table below). Public research from Trend Micro, Zscaler ThreatLabz, and Huntress describe the same broader ecosystem, with TradeAI.exe, OpenClaw_x64.7z, WormGPT_x64.7z, and DeepSeekAI_agent_x64.7z appearing as sibling lures and the downstream payload set documented as Vidar plus GhostSocks.

Mitigation and protection guidance

To defend against social engineering campaigns that leverage AI brands as lures, Microsoft recommends the following mitigation measures:

• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices in all locations at all times.
• Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
• Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Enable Zero-hour auto purge (ZAP) in 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.
• Configure Microsoft Defender for Office 365 Safe Links to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow and time-of-click verification of URLs and links in email messages, other Microsoft Office applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Threat overview profile: Evolving phishing threats

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise

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 AI brands as bait: How threat actors are using the AI hype in social engineering appeared first on Microsoft Security Blog.

Ransomware that combines robust encryption with rapid lateral movement significantly increases the risk and impact of an attack. The Gentlemen ransomware is a ransomware-as-a-service (RaaS) threat that is distinguished by its ability to pair its strong per-file encryption with an aggressive self-propagation capability designed to enable broad network compromise. In addition to using per-file ephemeral Curve25519 keys with XChaCha20 stream cipher, The Gentlemen ransomware attempts to spread across an environment using series of simultaneous, distinct lateral movement methods, increasing the likelihood of widespread impact once initial access is achieved.

Microsoft Threat Intelligence tracks the operators behind the ransomware as Storm-2697, a financially motivated threat actor that manages the RaaS platform known as “The Gentlemen” while affiliates carry out attacks. Emerging around mid-2025, The Gentlemen initially started as a closed ransomware group then began offering its RaaS to affiliates in September 2025. More recently, The Gentlemen operators established an official partnership with BreachForums, a popular cybercriminal marketplace, to recruit affiliates including penetration testers and initial access brokers. Given that The Gentlemen is already a widely adopted RaaS platform, this partnership may lead to increased activity as the program becomes accessible to a broader pool of threat actors.

The operators behind the ransomware use double extortion tactics, encrypting data while also exfiltrating sensitive information to pressure victims through the threat of public release if the ransom is not paid. The ransomware is written in Go and obfuscated with Garble to target the Windows environment. Microsoft has observed The Gentlemen ransomware impacting organizations across education, transportation, healthcare, and financial industries in North America, South America, Europe, Africa, and Asia.

In this blog, we present a detailed analysis of the Gentlemen ransomware encryptor, including its execution flow, defense evasion behaviors, encryption design, and lateral movement techniques. This research is intended to provide defenders, incident responders, and the broader security community with a better understanding of how the threat operates, from initial argument parsing and defense evasion, through its file encryption internals, to the full lateral movement that enables it to propagate across the network. We also provide mitigation guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help organizations defend against this threat and similar ransomware activity.

Pre-encryption

Command-line argument processing

The ransomware operator can control The Gentlemen encryptor through command-line arguments. A password is required for execution, and optional arguments allow the operator to specify encryption scope, speed, lateral movement, and post-encryption behaviors.

The binary accepts the following arguments:

The --full command-line argument appears to be the intended mode of operation for comprehensive file encryption on the infected device. When this argument is provided, the malware spawns two child processes of itself: one appended with the argument --system to encrypt local volumes under a SYSTEM-privileged scheduled task, and one appended with the argument --shares to encrypt network shares. This separation ensures that the malware can reach both local drives (which might require SYSTEM privileges) and mapped network shares (which are only visible in the user’s session).

The speed arguments (--fast, --superfast, --ultrafast) are mutually exclusive and control how much of each large file is encrypted. When no speed flag is specified, the default per-chunk percentage is 9%. These flags only affect files that are larger than 1 MB, and small files are fully encrypted regardless of the speed setting.

Usage prompt

When the encryptor is executed with no command-line argument, the malware prints a branded usage banner to the console.

It first executes the following PowerShell commands to render a console header:

This is followed by a detailed usage prompt provided by the malware author that documents all available flags with descriptions and examples:

It is worth noting that the file size percentages listed in the usage prompt refer to the total file encryption amount. Internally, the malware encrypts three separate chunks, and the per-chunk percentage used in the code is: fast=3%, superfast=1%, ultrafast=0.3%, default=9%.

Password check

Before executing its primary functionality, the malware validates the --password argument against a hardcoded value embedded within the binary. For the sample analyzed in this blog, the expected password is “9VoAvR7G”. If the provided password does not match, the malware outputs bad args and terminates execution.

This password check is a simple operator authentication mechanism, with each build containing a unique embedded password. Its purpose is to restrict execution to authorized operators and reduce the risk of accidental or unauthorized detonation if the binary is recovered or intercepted. However, because this validation relies on a static comparison, it can be easily identified and bypassed through static analysis techniques.

System encryption: Privilege escalation

When the --system argument is provided (either directly or via the --full argument), the malware creates a scheduled task to re-execute itself as SYSTEM. If a delay value is also specified through the --T argument, the scheduled execution time is adjusted accordingly.

To relaunch itself as SYSTEM, it issues the following sequence of commands:

The malware can only perform this task if it’s executed from an account with administrator privilege. It first deletes any existing task named gentlemen_system to avoid conflicts, creates a new one-time task that runs its binary under the SYSTEM account, and finally triggers that task.

This sequence ensures a clean state by first removing any existing task with the same name (gentlemen_system), creating a new scheduled task that executes the ransomware binary with SYSTEM-level privileges before finally triggering its immediate execution.

When running within this scheduled task context, the malware sets the environment variable LOCKER_BACKGROUND=1. This variable functions as an internal execution flag, indicating that the process is operating as a background encryption worker with elevated privileges, rather than as the original operator-invoked instance.

Defense evasion

Before starting file encryption, the malware executes a sequence of commands to disable defensive controls and remove potential forensic artifacts.

Disable Microsoft Defender

The PowerShell commands disable Microsoft Defender real-time monitoring to remove active protection on the infected device. The malware then adds its own executable to the Defender exclusion list to avoid detection. Finally, it excludes the entire C:\ volume from scanning, reducing the likelihood of subsequent detection during file encryption.

Delete shadow copies and event logs

To further impede recovery efforts, the malware deletes all Volume Shadow Copies using both vssadmin and wmic (Windows Management Instrumentation command-line utility). It then clears the System, Application, and Security event logs using wevtutil to remove key audit trails.

Delete forensics artifacts

These commands remove a variety of forensic artifacts, including prefetch files that track program execution, Defender diagnostic and support logs, and Remote Desktop Protocol (RDP) logs.

Additionally, the malware manually deletes PowerShell command history across all user profiles by removing the following file:

This action eliminates evidence of previously executed PowerShell commands, further reducing the visibility of execution history and threat actor activity.

Process and service termination

Process termination

The malware stops a list of running processes using the command:

The table below summarizes the different categories and processes being targeted:

Service termination

In addition to terminating processes, the malware disables and stops a list of Windows services using the commands:

The table below summarizes the different categories and services being targeted:

Terminating these processes and services serves two primary objectives:

• File access and encryption reliability: Many targeted processes/services, such as databases, Office applications, and backup agents, maintain active file locks. By forcibly terminating these processes, the ransomware ensures that locked files become accessible for encryption.
• Defense and recovery disruption: By stopping backup services, endpoint protection agents, and remote access tools, the malware reduces the likelihood of real-time detection and data restoration from backups.

Collectively, these behaviors maximize encryption coverage while hindering the environment’s ability to detect, respond to, or recover from the attack.

Persistence

The encryptor can establish persistence for itself through two mechanisms: scheduled tasks and registry keys.

Scheduled tasks persistence

For establishing persistence with scheduled tasks, the malware executes the following sequence of commands:

These commands first remove any pre-existing tasks with the same names, then create two persistence mechanisms that execute automatically at system startup. The UpdateSystem task launches the payload in the SYSTEM security context, while the UpdateUser task launches it in the currently signed-in user’s context. This design increases the likelihood that the ransomware will run after reboot regardless of privilege level or sign-in state.

Registry keys persistence

For establishing persistence with the registry, the malware executes the following sequence of commands:

The GupdateS value under HKEY_LOCAL_MACHINE (HKLM) provides device-wide persistence that allows the malware to run at startup for all users, while the GupdateU value under HKEY_CURRENT_USER (HKCU) provides user-scoped persistence within the current profile. By writing to both registry hives, the malware establishes redundant autorun paths across both system-level and user-level execution contexts.

Together, the scheduled tasks and Run key modifications create layered persistence, ensuring that the encryptor is re-executed after a reboot in both privileged and user-context scenarios.

Network share traversal

When the command-line argument --shares is provided, the malware initiates network share discovery and enumeration. It begins by probing all drive letters A through Z to identify mapped network drives using the following commands:

This sequence discovers any drives that are already mapped in the current user’s session, which are then added to the encryption target list.

To further enhance visibility into the network environment, the malware enables multiple Windows network discovery services and their associated firewall rules using the following commands:

The services enabled as part of this process include:

• Function Discovery Resource Publication (fdrespub): Publishes the host’s resources to the network, allowing other systems to detect it.
• Function Discovery Provider Host (fdPHost): Hosts provider components responsible for discovering network resources.
• Simple Service Discovery Protocol (SSDP) Discovery (SSDPSRV): Enables discovery of Universal Plug and Play (UPnP) devices.
• UPnP Device Host (upnphost): Supports the hosting and management of UPnP devices.

Finally, the malware reinforces this configuration by enabling the Network Discovery firewall rule group. This redundancy ensures that firewall restrictions do not limit its network visibility, further maximizing the number of reachable targets for encryption and propagation.

Volume and directory traversal

To enumerate all available volumes on the system, the malware executes the following PowerShell command sequence:

This command queries Windows Management Instrumentation (WMI) for all mounted volumes with drive letter paths and attempts to enumerate Cluster Shared Volumes (CSVs).

Additionally, the malware performs a secondary enumeration routine by iterating through drive letters A through Z while verifying their existence on disk. This brute-force method ensures broader coverage by identifying volumes that might not be retrieved through WMI queries to maximize visibility into all potential encryption targets.

Directory exclusion list

To maintain system stability and avoid disrupting critical operating system components, the malware excludes a predefined set of directories from traversal and encryption. These directories include core Windows system paths, application directories, and locations commonly associated with security and system management:

Extension exclusion list

The ransomware also excludes a set of file extensions associated with system-critical binaries, configuration files, and executable content:

By avoiding executable files, libraries, scripts, and other system-relevant formats, the malware preserves the integrity of the operating environment. This selective encryption model is a common ransomware design pattern, ensuring that the system remains operational enough for the victim to receive instructions and facilitate ransom payment.

File name exclusion list

The specific file names below are also excluded:

The inclusion of README-GENTLEMEN.txt, the ransomware’s ransom note, prevents it from being encrypted during execution. This ensures that the ransom instructions remain accessible to the victim, which is critical for the operator’s monetization workflow.

Ransom note

During directory traversal, the malware drops a ransom note named README-GENTLEMEN.txt in each scanned directory to provide victim-facing instructions.

The note contains identifiers assigned to the victim, communication channels, and guidance on how to initiate contact with the operators.

File encryption

File ownership

Before encrypting a file, the ransomware modifies the file ownership and access control settings to ensure it has unrestricted write access to the target. This is achieved through the following sequence of commands:

The takeown command recursively transfers ownership of the specified file or directory to the executing user, overriding existing ownership constraints. The icacls command then grants full control permissions to the Everyone security identifier (SID S-1-1-0), applying inheritance flags to propagate these permissions to all child objects. Finally, the attrib command removes the read-only attributes.

Cryptographic scheme

The Gentlemen ransomware implements a hybrid cryptographic design that combines Curve25519 elliptic-curve cryptography with the XChaCha20 stream cipher to achieve efficient and secure per-file encryption.

For each file, the malware performs the following sequence of operations:

1. Generates a unique ephemeral Curve25519 key pair, consisting of a randomly generated private key and its corresponding public key
2. Computes the Elliptic-curve Diffie–Hellman (ECDH) shared secret between the ephemeral private key and the operator’s embedded public key
3. Uses the resulting shared secret as the XChaCha20 key, and derives the nonce from the first 24 bytes of the ephemeral public key
4. Encrypts the file contents using XChaCha20 with this key and nonce combination
5. Appends the Base64-encoded ephemeral public key to the file footer to enable subsequent key reconstruction during decryption

In this sample, the operator’s public key is hard-coded within the binary as a Base64-encoded value:

This design ensures that each file is encrypted with a distinct key and nonce derived from a per-file ephemeral key exchange, eliminating any possibility of key or nonce reuse across files.

During decryption, the decryptor can use the operator’s Curve25519 private key together with the stored ephemeral public key to reconstruct the ECDH shared secret and recover the XChaCha20 key. The nonce is deterministically reconstructed by extracting the first 24 bytes of the recovered ephemeral public key, making separate nonce storage unnecessary.

Overall, this approach provides strong cryptographic isolation between encrypted files while maintaining operational simplicity and efficiency for the threat actor during both encryption and decryption.

Size-based encryption

The malware uses different encryption strategies based on file size:

Small files that are less than 1MB in size are fully encrypted. This ensures that documents, configuration files, and other small but critical data are completely corrupted. For larger files such as databases, virtual disk images, archives, full encryption would be time-consuming. Instead, the malware encrypts three data chunks distributed across the file, which is sufficient to corrupt the file structure while dramatically reducing encryption time.

After encryption, each affected file is renamed with the appended extension .umc16h. This extension serves as a quick indicator of files already encrypted by the ransomware.

Large file chunking logic

For files larger than 1 MB, the malware performs partial encryption by dividing the file into three non-contiguous chunks distributed across its contents:

The first chunk begins at the start of the file, the second is positioned near the midpoint, and the third is located toward the end. This distribution ensures that even limited encryption is sufficient to corrupt the file structure while minimizing processing time.

Each chunk is encrypted in 64 KB (0x10000) blocks using XChaCha20. To maintain cryptographic separation between chunks, the malware modifies the nonce on a per-chunk basis. Specifically, the last byte of the 24-byte XChaCha20 nonce is XOR-ed with the chunk index (0, 1, or 2), and a new cipher instance is initialized for each chunk using the modified nonce. As a result, chunk 0 uses the original nonce, while subsequent chunks use deterministically altered variants.

Although all chunks for a given file share the same derived encryption key, this nonce mutation ensures that each chunk is processed under a unique keystream, preventing keystream reuse across different regions of the file.

The encryption percentage for each file is determined by the provided speed command-line arguments:

File footer

After encrypting each file, the malware appends a structured footer containing metadata required for identification and decryption. The footer format differs slightly depending on whether the file was fully or partially encrypted.

Small file encryption (files ≤ 1 MB):

Large file encryption (files > 1 MB):

The footer serves three primary functions:

1. Key and nonce reconstruction: The Base64-encoded ephemeral public key, located after --eph--, allows the decryptor to recompute both the XChaCha20 key (using ECDH shared secret) and the nonce (first 24 bytes of the ephemeral public key).
2. Identification: The GENTLEMEN marker, located after --marker--, serves as a unique identifier, allowing encryptors/decryptors to quickly determine that the file has been encrypted by The Gentlemen ransomware.
3. Decryption mode: The optional speed flag marker (only present on large files) tells the decryptor which chunking percentage was used.

Notably, the speed marker is only present for large-file encryption. Files that are ≤ 1 MB do not include a speed marker, and its absence signals that the file was fully encrypted. This implicit encoding in the footer allows the decryptor to distinguish between full and partial encryption modes without requiring additional metadata fields.

Post-encryption

Wallpaper setup

If the --silent argument is not provided, the malware drops the following bitmap image file to %TEMP%\gentlemen.bmp and sets it as the system’s desktop wallpaper.

This behavior serves as an immediate visual indicator of compromise, signaling to the victim that encryption has completed.

Self-propagation

The self-propagation module is the more distinctive component of The Gentlemen ransomware. When enabled with the --spread argument, it turns the malware from a single-host encryptor into a self-propagating worm that attempts to deploy its encryptor to every reachable system on the network.

The --spread argument accepts either explicit credentials in domain/user:password format for authenticated lateral movement, or an empty string to reuse the current session’s authentication token.

Placeholder legend

The executed commands in this section use the following placeholders:

Phase 1: Local staging setup

The malware prepares the infected host to act as a distribution point for its binary by executing the following command sequence:

The commands copy the malware executable into C:\Temp, creates a hidden Server Message Block (SMB) share named share$ pointing to that directory, and modifies registry settings to allow anonymous access. With this setup, other systems on the network can retrieve the payload from \\<self>\share$, even when valid credentials are not available.

Phase 2: PsExec drop

The malware binary carries an embedded copy of PsExec and drops it to C:\Temp\psexec.exe on the infected device.

If the embedded PsExec payload cannot be extracted successfully, the malware falls back to downloading PsExec directly from Microsoft’s Sysinternals Live service using the following PowerShell command:

Phase 3: Network enumeration

After dropping PsExec, the malware attempts to enumerate and discover remote systems on the network, including workstations, servers, and domain controllers. Each discovered host becomes a candidate target for propagation.

Phase 4: PowerShell defense evasion blob

Before attempting to run the payload on a remote system, the malware executes the following PowerShell command on the remote target to weaken local defenses and make payload execution more reliable:

This command disables Microsoft Defender real-time monitoring, adds broad Defender exclusions, turns off Windows Firewall across all profiles, shares local drives, grants permissive New Technology File System (NTFS) access, enables SMB1, and loosens anonymous-access restrictions through Local Security Authority (LSA) registry settings. Together, these changes make the remote system significantly more exposed and ready for the payload deployment step.

Phase 5: Payload deployment

For each discovered remote host, the malware attempts a series of independent lateral movement techniques to execute its payload. Notably, these techniques are executed without dependency on prior success, and each method is attempted regardless of whether earlier attempts fail. This execution model of The Gentlemen’s propagation logic can significantly increase the likelihood that at least one execution path succeeds even in secured environments.

5.1: Remote file copy

The malware first stages its payload on the remote system by copying the encryptor binary over the administrative C$ share:

This operation ensures a local copy of the payload is available on the target host, allowing subsequent execution methods to reference a path that does not depend on network shares.

5.2: PsExec-based execution

If PsExec is successfully dropped or downloaded, the malware leverages it to perform a multi-stage execution sequence on the remote host.

First, the malware executes the PowerShell defense evasion payload to weaken host protections:

After a delay to allow defenses to be disabled, the malware executes the payload from the locally staged path C:\Temp under SYSTEM privileges:

After another sleep period, the malware executes the final command to run the payload with the –h flag for elevated token and –c -f to copy and force execution:

5.3: WMIC process creation

The malware uses WMI via wmic.exe to create remote processes:

The first command executes the defense evasion blob, the second runs the payload from the infected host’s SMB share, and the third runs the pre-staged copy from the target’s local C:\Temp directory.

5.4: Scheduled tasks (user)

The malware creates three scheduled tasks under the target user’s context, each running two minutes after the time when they are created:

The scheduled task DefU is set to run the defense evasion blob, UpdateGU executes the payload from the infected host’s SMB share, and UpdateGU2runs the pre-staged copy from the target’s local C:\Temp directory.

5.5: Scheduled tasks (system)

The same three tasks are repeated, running under the SYSTEM account:

By attempting both user-context and SYSTEM-context task creation, the ransomware can improve its chance of propagation across environments with different permission boundaries.

5.6: Service-based execution

The malware executes the following command sequence to create three Windows services on the target host:

Similar to the scheduled tasks, the service DefSvc is set to run the defense evasion blob, UpdateSvc executes the payload from the infected host’s SMB share, and UpdateSvc2 runs the pre-staged copy from the target’s local C:\Temp directory. These services run as SYSTEM by default, which provides another high-privilege execution path for the ransomware payload on the remote system.

5.7: Payload deployment: PowerShell remoting

Using PowerShell remoting, the malware executes commands directly on the target using Invoke-Command:

This method leverages Windows Remote Management (WinRM), providing an alternative execution channel when PsExec or WMIC are unavailable or blocked.

5.8: PowerShell WMI execution

Finally, the malware uses the PowerShell WMI class interface directly to create remote processes with the following command sequence.

This provides functionality equivalent to wmic.exe, but through a different execution path. As a result, it might succeed in environments where the WMIC binary is restricted but WMI access remains available.

Self-propagation summary

Across all techniques, the malware attempts 21 remote execution operations per target host, spanning multiple APIs, privilege levels, and execution contexts. Each method attempts to launch the payload from:

• The infected host’s SMB share: \\<self>\share$\<payload_name>
• The target host’s locally staged path: C:\Temp\<payload_name>

This redundancy is central to The Gentlemen’s propagation strategy. In secured environments where most lateral movement techniques are mitigated, a single successful execution on a single additional host is sufficient to continue the propagation.

Free space wipe

If the --wipe argument is provided, The Gentlemen ransomware performs an additional post-encryption routine to eliminate recoverable artifacts from disk.

The malware first enumerates all available volume paths on the system. For each volume, it creates a temporary file named wipefile.tmp at the root directory and determines the amount of available free space. It then writes random data to this file in 64 MB blocks until the volume is completely filled. Once the disk space has been exhausted, the temporary file is deleted.

This process effectively overwrites all unallocated disk space with random data, preventing forensic tools from recovering remnants of previously deleted files. This includes cached or temporary versions of original unencrypted data that might still reside on disk. When combined with earlier actions such as Volume Shadow Copy deletion, this behavior reduces the likelihood of data recovery without access to the threat actor’s decryption key.

Self-delete

If the --keep flag is not provided, the malware attempts to remove its executable from disk after completing encryption.

Since a running process cannot directly delete its own binary, the ransomware generates and executes a temporary batch script at <malware_path>.batwith the following contents:

The batch script introduces a short delay by sending three Internet Control Message Protocol (ICMP) echo requests to the local host, pausing execution long enough for the main malware process to terminate. After this delay, the script deletes the original ransomware executable before removing itself. This mechanism helps reduce on-disk artifacts and hinders post-incident forensic analysis by eliminating the ransomware binary from the compromised system.

Defending against The Gentlemen ransomware

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

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants. 
• Turn on tamper protection features to prevent threat actors from stopping security services. In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy. 
• Enable controlled folder access. Controlled folder access helps protect your valuable data from malicious apps and threats, such as ransomware. Controlled folder access works by only allowing trusted apps to access protected folders. Protected folders are specified when controlled folder access is configured. Apps that aren’t included in the trusted apps list are prevented from making any changes to files inside protected folders. 
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. 
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume. 
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully. 
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:  
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block process creations originating from PSExec and WMI commands if you’re managing your devices with Intune or another MDM solution. This rule is incompatible with management through Microsoft Endpoint Configuration Manager. 
  • Use advanced protection against ransomware

Microsoft Defender detections and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Ransom:Win64/Gentlemen

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware-linked threat actor detected
• Ransomware behavior detected in the file system
• Possible ransomware activity
• File backups were deleted
• Potential human-operated malicious activity
• Possible data exfiltration
• Suspicious wallpaper change

The following alerts might indicate threat activity associated with The Gentlemen ransomware if Defender for Endpoint is set to block mode.

• ‘Gentlemen’ ransomware was detected
• ‘Gentlemen’ ransomware was prevented

Microsoft Defender for Cloud Apps

The following alert might indicate threat activity associated with this threat. This alert, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware activity

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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Tool profile: Gentlemen ransomware
• Threat overview profile: Human-operated ransomware

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Known The Gentlemen ransomware files

Search for the file hashes associated with The Gentlemen ransomware activity identified in this report. 

let fileHashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
union
(
   DeviceFileEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceFileEvents"
),
(
   DeviceEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = 
SHA256, SourceTable = "DeviceEvents"
),
(
   DeviceImageLoadEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceImageLoadEvents"
),
(
   DeviceProcessEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceProcessEvents"
)
| order by Timestamp desc

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect web sessions IP and file hash indicators of compromise using Advanced Security Information Model (ASIM)

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser:

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic([]);
let ioc_sha_hashes =dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect files hashes indicators of compromise using ASIM

The following query checks IP addresses and file hash IOCs across data sources supported by ASIM file event parser:

// file hash list - imFileEvent
let ioc_sha_hashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
imFileEvent
| where SrcFileSHA256 in (ioc_sha_hashes) or
TargetFileSHA256 in (ioc_sha_hashes)
| extend AccountName = tostring(split(User, @'')[1]), 
  AccountNTDomain = tostring(split(User, @'')[0])
| extend AlgorithmType = "SHA256"

Indicators of compromise

Acknowledgements

• License to Encrypt: The “Gentlemen” Make Their Move. Cybereason (accessed 2026-02-06)
• Unmasking The Gentlemen Ransomware: Tactics, Techniques, and Procedures Revealed. TrendMicro (accessed 2026-02-06)

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 The Gentlemen ransomware: Dissecting a self-propagating Go encryptor appeared first on Microsoft Security Blog.

Fox Tempest is a financially motivated threat actor that operates a malware-signing-as-a-service (MSaaS)  used by other cybercriminals to more effectively distribute malicious code, including ransomware. The threat actor abuses Microsoft Artifact Signing to generate short-lived, fraudulent code-signing certificates to appear legitimately signed, allowing malware to evade security controls.

Fox Tempest has created over a thousand certificates and established hundreds of Azure tenants and subscriptions to support its operations. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), with support from industry partner Resecurity, disrupted Fox Tempest’s MSaaS offering, targeting the infrastructure and access model that enables its broader criminal use.

Microsoft Threat Intelligence observed Fox Tempest’s operations enabling the deployment of Rhysida ransomware by threat actors such as Vanilla Tempest, as well as the distribution of other malware families including Oyster, Lumma Stealer, and Vidar. The consistency, scale, and downstream impact of the resulting attack activity demonstrate that Fox Tempest is a vital operator within the broader cybercrime ecosystem.

In this blog, we examine how Fox Tempest’s MSaaS operation functioned and how it enabled the delivery of trusted, signed malware across the cybercrime ecosystem. We also provide Microsoft Defender detections, indicators of compromise (IOCs), and mitigation recommendations to help organizations identify and disrupt similar activity.

Fox Tempest’s role and impact

Fox Tempest doesn’t directly target victims but instead provides supporting services that enable ransomware operations by other threat actors. Microsoft Threat Intelligence has tracked Fox Tempest since September 2025. Microsoft Threat Intelligence has linked the actor to various ransomware groups including Vanilla Tempest, Storm-0501, Storm-2561, and Storm-0249, who have all leveraged Fox Tempest-signed malware in active intrusions. Malware delivery in these attacks have included use of legitimate purchased advertisements, malvertising, and SEO poisoning.

Cryptocurrency analysis associated with Fox Tempest has identified clear links tying the actor to ransomware affiliates responsible for delivering several prominent ransomware families, including INC, Qilin, Akira, and others, with observed proceeds in the millions. Based on the scale of the MSaaS offering, Microsoft Threat Intelligence assesses that Fox Tempest is a well-resourced group handling infrastructure creation, customer relations, and financial transactions.

The downstream impact of these operations has resulted in attacks against a broad range of industry sectors, including healthcare, education, government, and financial services, impacting organizations globally including, but not limited to the United States, France, India, and China.

Fox Tempest’s malware signing as a service infrastructure

Fox Tempest’s MSaaS capability was available through the website signspace[.]cloud, a now defunct service that was disrupted by DCU, which enabled other threat actors to fraudulently obtain short-lived Microsoft-issued certificates that were valid for only 72 hours, obtained through Artifact Signing (previously named Azure Trusted Signing). This use of short-life certificates from a trusted source allowed malware and ransomware to masquerade as legitimate software (like AnyDesk, Teams, Putty, and Webex) to bypass security controls, significantly increasing the likelihood of execution and successful delivery. Fox Tempest offered this MSaaS capability to the ransomware ecosystem since at least May 2025.

To obtain legitimate signed certificates through Artifact Signing, the requestor must pass detailed identify validation processes in keeping with industry standard verifiable credentials (VC), which suggests the threat actor very likely used stolen identities based in the United States and Canada to masquerade as a legitimate entity and obtain the necessary digital credentials for signing. The SignSpace website was built on Artifact Signing and enabled secure file signing through an admin panel and user page, leveraging Azure subscriptions, certificates, and a structured database for managing users and files. A GitHub repository, called code‑signing‑service, included configuration files and technical details that directly linked it to the infrastructure behind signspace[.]cloud.

The signspace[.]cloud service has two unique modeling groupings: the admin and the customers. The admin is responsible for maintaining the tooling, account creation, and infrastructure, while the customers provide files to be fraudulently code signed. Customers who accessed the service could upload malicious files to be signed using Fox Tempest-controlled certificates.

Below are examples of the signspace[.]cloud portal as seen by Fox Tempest’s customers:

In February 2026, Microsoft Threat Intelligence observed a notable shift in Fox Tempest’s operational infrastructure. Fox Tempest transitioned to providing customers with pre-configured virtual machines (VMs) hosted on US-based virtual private server provider Cloudzy’s infrastructure, allowing threat actors to upload their malicious files directly to Fox Tempest‑controlled environments and receive signed binaries in return. This infrastructure evolution reduced friction for customers, improved operational security for Fox Tempest, and further streamlined the delivery of malicious but trusted, signed malware at scale. Microsoft’s Digital Crimes Unit (DCU) disrupted this infrastructure and continues to partner with Cloudzy to identify and disrupt related infrastructure.

Below is an example of the Fox Tempest-provided VM environment as seen by customers:

Inside the VM, Fox Tempest provided files that are used to sign code:

• The first file, metadata.json, was a configuration file that pointed to an Azure‑hosted endpoint which also included the signing account and certificate profile.
• The second file, test.js, is an example of a file provided by Fox Tempest that had been digitally signed to demonstrate their signing capabilities to customers.
• The third file, PS code sample.txt, contains the PowerShell script they used to sign customer‑submitted files using certificates under Fox Tempest control.

Threat actors using Fox Tempest’s MSaaS offering paid thousands of dollars to get their malicious code signed, as shown below with the Google Form detailing the service’s pricing model. Actors filled out the form before being added to a queue to submit payment and gain access to a VM. The form (written in both English and Russian) asks the user to choose a selected plan from a price list of $5000 USD, $7500 USD, or $9000 USD, with a mention that higher paying plans receive priority in the queue sequence.

Fox Tempest engaged directly with customers using a Telegram channel, EV Certs for Sale by SamCodeSign under the user account arbadakarba2000. All signing activity occurred using a Fox Tempest-provided email address associated with a very small number of IP addresses.

Case study: Fox Tempest enables Vanilla Tempest attacks

Vanilla Tempest began using Fox Tempest’s MSaaS service as early as June 2025. Through this service, Vanilla Tempest uploaded malicious payloads such as trojanized Microsoft Teams installers, which Fox Tempest would fraudulently signed to appear legitimate. Vanilla Tempest would then distribute these signed binaries through legitimately purchased advertisements that redirected users searching for Microsoft Teams to attacker‑controlled advertisements and fraudulent download pages.

Victims were presented with a malicious MSTeamsSetup.exe in place of the legitimate client, reflecting a broader pattern of Vanilla Tempest frequently abusing trusted software brands to lure victims and establish initial access. Execution of the counterfeit installer resulted in the deployment of the Oyster backdoor (also known as Broomstick), a modular, multistage implant that establishes persistent remote access, initiates command‑and‑control (C2) communications, collects host‑level information, and enables the delivery of additional payloads. By masquerading as a widely deployed enterprise collaboration tool hiding behind a fraudulently signed binary, Vanilla Tempest’s Oyster payload was likely able to evade casual detection and blend into normal enterprise activity. In some observed cases, Vanilla Tempest also deployed Rhysida ransomware within victim environments using the same process.

Defending against Fox Tempest-enabled attacks

To defend against Fox Tempest tactics, techniques, and procedures (TTPs) and similar activity, Microsoft recommends the following mitigation measures:

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations.
• 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 huge majority of new and unknown variants.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• 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.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO. 
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in troubleshooting mode to turn off tamper protection temporarily without impacting the wider organizational security policy.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:
  • Use advanced protection against ransomware

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Actor profile: Fox Tempest
• Actor profile: Vanilla Tempest
• Threat Overview profile: Human-operated ransomware
• Activity profile: Vanilla Tempest leverages fake Microsoft Teams setup to deliver Oyster backdoor

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise

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 Exposing Fox Tempest: A malware-signing service operation appeared first on Microsoft Security Blog.

Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations. Over time, Kazuar has expanded from a relatively traditional backdoor into a highly modular peer-to-peer (P2P) botnet ecosystem designed to enable persistent, covert access to target environments.

This upgrade aligns with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence collection. The threat actor has historically targeted organizations in the government and diplomatic sector in Europe and Central Asia, as well as systems in Ukraine previously compromised by Aqua Blizzard, very likely for the purpose of obtaining information supporting Russia’s foreign policy and military objectives.

While many threat actors rely on increasing usage of native tools (living-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and stealth directly into their tooling. By separating responsibilities across Kernel, Bridge, and Worker modules and restricting external communications to a single elected leader, Kazuar reduces its observable footprint. It also maintains flexible tasking, data staging, and multiple fallback channels for command and control (C2). Understanding this architecture helps defenders move beyond single sample analysis and instead focus on the behaviors that keep the botnet operational: leader election, inter-process communication (IPC) message routing, working directory staging, and periodic exfiltration.

Kazuar’s capabilities and tradecraft have been widely documented by the security research community, and prior reporting, including Unit 42’s write-up and a recent deep dive into its loader capabilities, remains relevant today. This blog is an in-depth analysis of Kazuar’s progression from a single, monolithic framework into a modular bot ecosystem composed of three distinct module types, each with clearly defined roles. Together, these components distribute functionality across the P2P botnet, enabling flexible configuration, lower observability, and broad tasking while minimizing opportunities for detection.

Delivery

Kazuar is delivered through multiple dropper variants. In one observed method, the Pelmeni dropper embeds the encrypted second-stage payload directly within the dropper as an encrypted byte array. The payload is often bound to the target environment (for example, encrypted using the target hostname) so it only decrypts and executes on the intended host.

In another method, the dropper deploys a small .NET loader alongside the final payload. The dropper then invokes the loader (often configured as a COM object) and supplies the decrypted payload, allowing it to load and execute the Kazuar modules.

Module types

There are three distinct types of modules: Kernel, Bridge, and Worker. The next sections explain the functionality contained in each type and how they interact with each other.

This diagram shows the general interactions between a set of modules on a single host. Each infected host needs to have all three modules to create the full P2P network:

Note: We use ALL CAPS when referencing identifiers taken verbatim from the malware (for example, internal module and thread names, message types, configuration keys, or mode/flag values). 

Type: Kernel

The Kernel module serves as the central coordinator for the botnet. It issues tasks to Worker modules, manages communication with the Bridge module, and maintains logs of actions and collected data. Early in execution, the Kernel module performs extensive anti-analysis and sandbox checks. These behaviors are well documented in the Unit 42 write-up and include standard checks such as:

• Checking for running processes containing analysis tools
• Checking for canary files on the desktop
• Checking the loaded process for sandbox-related DLLs

Module configuration

Once these checks are passed, the Kernel module sets up the environment based on numerous configuration options. Previous versions of Kazuar have used separate files containing the configuration information, but these are now embedded in the samples and have significantly increased the number of configurations available to the malware family. 

The configuration set can vary across 150 different configuration types, C2 communication infrastructures, or tasking options generally defined by eight functional categories. Any operational configuration in use can be updated at any time from the C2 server. The following table contains some examples and descriptions of the categories.

This configuration exposes three internal communication mechanisms:

• Window Messaging
• Mailslot
• Named pipes

There are also three different communication protocols for external communication:

• Exchange Web Services (EWS)
• HTTP
• WebSockets (WSS)

They typically contain redundant or fallback communications to maintain access in the event of the failure of a single point of contact.

Leadership election

One of the methods that Kazuar uses to limit external communication is to use a single Kernel leader per botnet. In this architecture, the Kernel leader is the one elected Kernel module that communicates with the Bridge module on behalf of the other Kernel modules, reducing visibility by avoiding large volumes of external traffic from multiple infected hosts.

There are several conditions that determine whether a new leader needs to be elected among participating Kernel modules:

1. There currently is no leader.
2. The leader announces it is shutting down.
3. The leader announces it is logging off.
4. If an election does not result in a leader due to an error, a new election will be called.

Elections occur over Mailslot, and the leader is elected based on the amount of work (length of time the Kernel module has been running) divided by interrupts (reboots, logoffs, process terminated). Once a leader is elected, it announces itself as the leader and tells all other Kernel modules to set SILENT.

Only the elected leader is not SILENT, which allows the leader Kernel module to log activity and request tasks through the Bridge module. Client Kernel modules still participate in internal IPC (for elections, status, and delegated work), but they don’t independently request tasks from the Bridge module. Before entering SILENT mode, each client Kernel module sends a CLIENT announcement, which causes the leader to add it to the maintained agent list.

With the hierarchy established, the work can be done. Several threads and communication types are initialized to perform the work and communicate between modules.

REMO thread

The REMO thread sets up a named pipe channel between Kernel modules so the leader can exchange messages with other Kernels. By default, the pipe name is the MD5 hash of pipename-kernel-<Bot version>, which results in a pipe path such as \\.\pipe\82760B84F1D703D596C79B88BA4FAC1E. The name could be modified through additional strings passed into the name-building function, but this pattern is the default. This channel lets the leader target specific client Kernel modules when delegating work.

Messages over this pipe are AES-encrypted and begin with a PING/PONG handshake. After that, the leader could:

• Request another Kernel module’s logs
• Assign tasks to a client Kernel module

Because only the Kernel leader is allowed to request tasks through the Bridge module, it distributes work to the other Kernel clients over named pipes. If the leader receives a task destined for a different bot, it forwards the task to the appropriate client Kernel module through this channel.

MSGW thread

For Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:

• Window Messaging [default selection]
  • Registers a hidden window
• Mailslot
  • Registers a Mailslot

Based on its initial configuration, Kazuar selects one of these communication types to listen for incoming communication, with the default being Windows Messaging.

Window Messaging setup

This technique involves creating a hidden window and registering a ClassName and WindProc. The ClassName is simply the module name (for example, Bridge), and the WindProc is the general-purpose message handler.

This allows other processes to look up the window by ClassName and use several different APIs to send a message to that window. When the window receives a message, the WindProc is executed to parse it and carry out the requested action.

Mailslot setup

The Mailslot name is derived by hashing the string “mailslot-” plus the module name (Bridge/Kernel/Worker). The configuration can optionally append an additional identifier (empty by default), which allows deployments to create distinct Mailslot namespaces when needed.

The string is hashed and used as the name to create the Mailslot: \\.\mailslot\<generated hash>.

A thread is created that checks every three seconds for new messages using the API GetMailslotInfo, and when it finds one, it parses the incoming message.

Message types

Regardless of what message delivery system is selected, the message is parsed by the same handler function. For the Kernel module, this message parsing function has numerous expected communication messages, since it controls all the modules execution flows.

The following message table describes the incoming and outgoing messages for the Kernel, what actions precipitate a message, and what the Kernel does when it receives each message:

SEND thread

The configuration specifies an external communication method from the available communication modes

• HTTP [default selection]
• Web Socket Server (WSS)
• Exchange Web Server (EWS)

These configurations can be changed at any point when the C2 sends a new configuration, or a change communication task is issued to it. It also contains a heartbeat timer that is defined in the configuration for the SEND actions to occur with the default timer being every hour. There are also working timers that can install a blackout period on communications to blend in with the target environment.

Note: Only the elected Kernel leader can perform the following actions:

• If the Kernel has task results 
  • Read in the task file
  • Send SEND message to Bridge with the task result file
• Get new tasks from Bridge
  • Send CHECK message to Bridge

Table 2 describes what the Kernel expects in return for these messages. The messages are sent asynchronously and recorded as tasks by the Kernel.

There is also a failsafe communication method that allows the Kernel to directly contact the remote C2 if the Kernel is unable to communicate with the Bridge module. Essentially, if all communication attempts fail and a certain amount of time has elapsed, the Kernel module requests tasks directly from the remote C2.

SOLV thread

This thread executes when the heartbeat timer expires to handle any tasks that the Kernel is tracking. This thread performs several functions related to the current task list:

• Loop through the list of current tasks
  • Check if aborted flag is true
    • Issue TaskKill message to the worker (Window Messaging)
    • Remove task from task list
  • Check if task has exceeded the configured max working time for task
    • Issue TaskKill message to the worker (Window Messaging)
    • Set aborted flag for task to true
    • Remove task from task list
• Read in all task files from the working directory
  • If the task is new
    • Add task to task list

Type: Bridge

The Bridge module provides the botnet’s external communications layer, acting as the proxy between the leader Kernel module and the C2 server regardless of the transport method selected. Since each Kernel module has its own Worker and Bridge module, if a new leader is elected, then that new leader Kernel module uses its Bridge module for communication. It typically has the same default configuration as the Kernel module but does contain a few different operations that set up the initial infection.

The Bridge module initializes its core object with basic metadata and instantiates two supporting components that provide the module’s primary functionality:

• Server Communication module
• Task Handling module

The module registers handlers for two system-level events. These handlers define how the module should respond when specific system events occur:

• SystemEvents.SessionEnded
• SystemEvents.PowerModeChanged

When an event is triggered, the corresponding handler function is invoked, allowing the module to determine the appropriate action for that event. Events are typically ignored unless they require explicit handling.

The module only terminates when the system is shutting down; all other events do not affect its lifetime. Based on its initial configuration, which should match the Kernel module configuration, it selects either Mailslot or Windows Messaging as the IPC mechanism used for communication between modules. Once the setup steps is completed, the module is ready to proxy communication between the leader Kernel module and the C2 server.

Type: Worker

The initial Worker configuration mirrors the structure of other module configurations and follows the same overall layout. Based on its initial configuration, the Worker module selects either Mailslot or Windows Messaging as the IPC mechanism used to communicate between modules. The default configuration for this botnet uses Windows Messaging; further details on the window setup are described below.

During initialization, the Worker configuration instantiates several objects responsible for the module’s primary functionality. Each object is executed within its own named thread. These components include:

• Task Solver
  • Handles task tracking
• Peep
  • Hooks windows events
  • Has a max number of windows to hook set by the configuration
• Keylogger
• Filesystem
  • GINFO – Gather system info
  • GFIL – Gather file listings
    • Recent files
    • Desktop
    • Malware working directory
  • GHOO – Window information
  • GMAP – Gather MAPI info
    • Email information

Data collected by these components is aggregated, encrypted, and written to the malware’s working directory, where it is staged for subsequent exfiltration to the C2 server.

Botnet operations

With the botnet setup complete, configurations instantiated, and a leader elected, Kazuar transitions into its steady state operational phase. In this state, the elected Kernel leader centrally coordinates tasking and data collection across participating modules while maintaining a deliberately low observable footprint. Worker modules execute tasks asynchronously based on configuration and assignments received from the Kernel, collecting system, file, window, and user activity data according to defined schedules and limits.

Module-to-module messaging

When one module needs to communicate with another, all required information is assembled into a structured message packet. Multiple packet formats are defined, with the specific format determined by the message type and intended action.

These message packets are constructed using Google Protocol Buffers (Protobuf), which provides a structured, schema‑based format similar in concept to JSON. Using Protobuf allows the malware to efficiently serialize, transmit, and parse messages through standard library functions.

Messages destined for the Bridge module include additional fields that describe how the request should be forwarded to the remote C2 infrastructure. These fields specify transport level details, including the external communication mechanism to be used.

The TransportType field can specify one of three supported communication methods. The default transport is typically HTTP, using the C2 URLs in the default configuration.

When sending a message, the dispatch function examines the contents of the message packet to determine the appropriate delivery mechanism, resolves the corresponding Mailslot name or window class identifier, and routes the packet to the intended module.

For example, if the TransportType is set to EWS, the packet is delivered to the Bridge module, which then uses its Exchange communication component to encapsulate the data and deliver it to the remote C2 server via email.

Messages originate from the Kernel leader, except for a couple of worker tasks that send messages to the Kernel module based on their configuration.

Working directory

Kazuar uses a dedicated working directory as a centralized on‑disk staging area to support its internal operations across modules. This directory is defined through configuration and is consistently referenced using fully qualified paths to avoid ambiguity across execution contexts. Within the working directory, Kazuar organizes data by function, isolating tasking, collection output, logs, and configuration material into distinct locations. This design allows the malware to decouple task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure. Collected artifacts are typically written incrementally, encrypted before staging, and retained locally until explicitly forwarded to the C2 infrastructure through the Bridge module.

Within this working directory, Kazuar maintains separate storage locations for the following functional data types:

• Peeps
• Autos
• Files
• Hashes
• Result files
• Task files
• Config files
• Common wordlist
• Common exe
• Logs
• Keylogger

This structured use of the filesystem enables Kazuar to operate modularly, maintain persistence state across leadership changes or reboots, and blend malicious activity into routine file system usage.

Module tasks

The list of commands available for the Worker modules to perform is extensive and has many features, from arbitrary command/script execution to preformatted forensic data collection functions, as described in the Unit 42 blog.

The Kernel module task handler has a few additional functions that handle commands issued from the leader Kernel module.

System info gathering

System info gathering is often enabled by default in the configuration. This causes an initial collection of system information when the agent starts up. This task collects an extensive amount of information about the system and its user.

Screenshots are also taken through various methods and saved for exfiltration both automatically through the configuration or when a task is issued.

Who is Secret Blizzard?

The United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to Center 16 of Russia’s Federal Security Service (FSB), which is one of Russia’s Signals Intelligence and Computer Network Operations (CNO) services responsible for intercepting and decrypting electronic data as well as the technical penetration of foreign intelligence targets. Secret Blizzard overlaps with activity tracked by other security vendors as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, WRAITH, and ATG26.

Secret Blizzard is known for targeting a wide array of verticals, but most prominently ministries of foreign affairs, embassies, government offices, defense departments, and defense-related companies worldwide. Secret Blizzard focuses on gaining long-term access to systems for intelligence collection using extensive resources such as multiple backdoors, including some with peer-to-peer functionality and C2 communication channels. During intrusions, the threat actor collects and exfiltrates documents, PDFs, and email content. In general, Secret Blizzard seeks out information of political importance with a particular interest in advanced research that might impact international political issues.

Mitigation and protection guidance

To harden networks against the Secret Blizzard activity listed above, defenders can implement the following:

Strengthen Microsoft Defender for Endpoint configuration

• Microsoft Defender XDR customers can implement attack surface reduction rules to harden an environment against techniques used by threat actors.
  • Block execution of potentially obfuscated scripts.
  • Block process creations originating from PSExec and WMI commands
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block abuse of exploited vulnerable signed drivers.
• Enable network protection in Microsoft Defender for Endpoint.
• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.

Strengthen Microsoft Defender Antivirus configuration

• Turn on PUA protection in block mode in Microsoft Defender Antivirus.
• Turn on  cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Strengthen operating environment configuration

• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Implement PowerShell execution policies to control conditions under which PowerShell can load configuration files and run scripts.
• Turn on and monitor PowerShell module and script block logging.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor profile: Secret Blizzard

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Indicators of compromise

References

• Over the Kazuar’s Nest: Cracking Down on a Freshly Hatched Backdoor Used by Pensive Ursa (Aka Turla)
• 🇷🇺 COMmand & Evade: Turla’s Kazuar v3 Loader
• Russia’s FSB malign activity: factsheet
• Hunting Russian Intelligence “Snake” Malware

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 Kazuar: Anatomy of a nation-state botnet appeared first on Microsoft Security Blog.

Phishing campaigns continue to improve sophistication and refinement in blending social engineering, delivery and hosting infrastructure, and authentication abuse to remain effective against evolving security controls. A large-scale credential theft campaign observed by Microsoft Defender Research exemplifies this trend, using code of conduct-themed lures, a multi-step attack chain, and legitimate email services to distribute fully authenticated messages from attacker-controlled domains.

The campaign targeted tens of thousands of users, primarily in the United States, and directed them through several stages of CAPTCHA and intermediate staging pages designed to reinforce legitimacy while filtering out automated defenses. The lures in this campaign used polished, enterprise-style HTML templates with structured layouts and preemptive authenticity statements, making them appear more credible than typical phishing emails and increasing their plausibility as legitimate internal communications. Because the messages contained concerning accusations and repeated time-bound action prompts, the campaign created a sense of urgency and pressure to act.  

The attack chain ultimately led to a legitimate sign-in experience that was part of an adversary‑in‑the‑middle (AiTM) phishing flow, which allowed the attackers to proxy the authentication session and capture authentication tokens that could provide immediate account access. Unlike traditional credential harvesting, AiTM attacks intercept authentication traffic in real time, bypassing non-phishing-resistant multifactor authentication (MFA).

In this blog, we’re sharing our analysis of this campaign’s lures, infrastructure, and techniques. Organizations can defend against financial fraud initiated through phishing emails by educating users about phishing lures, investing in advanced anti-phishing solutions like Microsoft Defender for Office 365 and configuring essential email security settings, and encouraging users to employ web browsers that support SmartScreen. Organizations can also enable network protection, which lets Windows use SmartScreen as a host-based web proxy.

Multi-step social engineering campaign leading to credential theft

Between April 14 and 16, 2026, the Microsoft Defender Research team observed a series of sophisticated phishing campaigns targeting more than 35,000 users across over 13,000 organizations in 26 countries, with majority of targets located in the United States (92%). The campaign did not focus on a single vertical but instead impacted a broad range of industries, most notably Healthcare & life sciences (19%), Financial services (18%), Professional services (11%), and Technology & software (11%). Messages were distributed in multiple distinct waves between 06:51 UTC on April 14 and 03:54 UTC on April 16. 

Emails in this campaign posed as internal compliance or regulatory communications, using display names such as “Internal Regulatory COC”, “Workforce Communications”, and “Team Conduct Report”. Subject lines included “Internal case log issued under conduct policy” and “Reminder: employer opened a non-compliance case log”.

Message bodies claimed that a “code of conduct review” had been initiated, referenced organization-specific names embedded within the text, and instructed recipients to “open the personalized attachment” to review case materials. At the top of each message, a notice stated that the message had been “issued through an authorized internal channel” and that links and attachments had been “reviewed and approved for secure access”, reinforcing the email’s purported legitimacy. To further support the confidentiality of the supposed review, the end of each message contained a green banner stating that the contents had been encrypted using Paubox, a legitimate service associated with HIPAA-compliant communications.

Analysis of the sending infrastructure indicated that the campaign emails were sent using a legitime email delivery service, likely originating from a cloud-hosted Windows virtual machine. The messages were sent from multiple sender addresses using domains that are likely attacker-controlled.

Each campaign email included a PDF attachment with filenames such as Awareness Case Log File – Tuesday 14th, April 2026.pdf and Disciplinary Action – Employee Device Handling Case.pdf. The attachment provided additional context about the supposed conduct review, including a summary of the review process and instructions for accessing supporting documentation. Recipients were directed to click a “Review Case Materials” link within the PDF, which initiated the credential harvesting flow.

When clicked, users were initially directed to one of two attacker-controlled domains (for example, acceptable-use-policy-calendly[.]de or compliance-protectionoutlook[.]de). These landing pages displayed a Cloudflare CAPTCHA, presented as a mechanism to validate that the user was coming “from a valid session”. This CAPTCHA likely served as a gating mechanism to impede automated analysis and sandbox detonation. 

After completing the CAPTCHA, users were redirected to an intermediate site designed to prepare them for the final stage of the attack. This page informed users that the requested documentation was encrypted and required account authentication. While this stage of the attack has several hallmarks of device code phishing, we were only able to confirm the AITM portion of the attack chain.

After clicking the provided “Review & Sign” button, users were presented with a sign-in prompt requesting their email address.

After submission, users were required to complete a second CAPTCHA involving image selection.

Once these steps were completed, users were shown a message indicating that verification was successful and that their “case” was being prepared.

Following these steps, users were redirected to a third site hosting the final stage of the attack. Analysis of the underlying code indicates that the final destination varied depending on whether the user accessed the workflow from a mobile device or a desktop system.

On the final page, users were informed that all materials related to their code of conduct review had been “securely logged”, “time-stamped”, and “maintained within the organization’s centralized compliance tracking system”. They were then prompted to schedule a time to discuss the case, which required signing in to their account.

Selecting the “Sign in with Microsoft” option redirected users to a Microsoft authentication page, initiating an AiTM session hijacking flow designed to capture authentication tokens and compromise user accounts.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for multifactor authentication (MFA). Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Threat overview profile: Adversary-in-the-middle credential phishing
• Threat overview profile: Evolving phishing threats

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Campaign emails by sender address

The following query identifies emails associated with this campaign using a message’s sending email address.

EmailEvents
| where SenderMailFromAddress in (" cocpostmaster@cocinternal.com "," nationaladmin@gadellinet.com ","
nationalintegrity@harteprn.com”,” m365premiumcommunications@cocinternal.com”,” documentviewer@na.businesshellosign.de”)

Indicators of compromise

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 Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise appeared first on Microsoft Security Blog.

During the first quarter of 2026 (January-March), Microsoft Threat Intelligence detected approximately 8.3 billion email-based phishing threats, with monthly volumes declining slightly from 2.9 billion in January to 2.6 billion in March. By the end of the quarter, QR code phishing emerged as the fastest-growing attack vector, more than doubling over the period, while CAPTCHA-gated phishing evolved rapidly across payload types. Overall, 78% of email threats were link-based, while malicious payloads accounted for 19% of attacks in January—boosted by large HTML and ZIP campaigns—before settling at 13% in both February and March. Credential phishing remained the dominant objective behind malicious payloads throughout the quarter. This shift toward link-based delivery, combined with the payload trends, suggests that threat actors increasingly preferred hosted credential phishing infrastructure over locally-rendered payloads as the quarter progressed.

This blog provides a view of email threat activity across the first quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code phishing, CAPTCHA evasion tactics, malicious payloads, and BEC activity, analyze how disruption efforts and infrastructure changes influenced threat actor operations, and provide recommendations and Microsoft Defender detections to help mitigate these threats. By bringing these trends together, this blog can help defenders understand how email-based attacks are evolving and where to focus detection, mitigation, and user protection strategies.

Tycoon2FA disruption impact

Since its emergence in August 2023, Tycoon2FA has rapidly become one of the most widespread PhaaS platforms, leveraging adversary-in-the-middle (AiTM) techniques to attempt to defeat non-phishing-resistant multifactor authentication (MFA) defenses. The group behind the PhaaS platform (tracked by Microsoft Threat Intelligence as Storm-1747) leases malicious infrastructure and sells phishing kits that impersonate various enterprise application sign-in pages and incorporate evasion tactics, such as fake CAPTCHA pages.

The quarter began with Tycoon2FA in a period of reduced activity. January volumes represented a 54% decline from December 2025, marking the second consecutive month of sharp decreases. While post-holiday seasonal effects may have contributed to this decrease in volume, some of the reduction might also have been the result of Microsoft’s Digital Crimes Unit disruption of RedVDS, a service used by many Tycoon2FA customers to distribute malicious email campaigns.

After surging 44% in February, phishing attacks pointing to Tycoon2FA fell 15% in March driven largely by the effects of a coordinated disruption operation. In early March 2026, Microsoft’s Digital Crimes Unit, in coordination with Europol and industry partners, took action to disrupt Tycoon2FA’s infrastructure and operations, significantly impairing the platform’s hosting capabilities. While Tycoon2FA-linked messages continued to circulate after the disruption, almost one-third of March’s total volume was concentrated in a three-day period early in the month; daily volumes for the remainder of March were notably lower than historical averages, and targets’ ability to reach active phishing pages was substantially reduced.

Tycoon2FA’s infrastructure composition evolved multiple times during the first three months of 2026. In January, Tycoon2FA domains started shifting toward newer generic top-level domains (TLDs) such as .DIGITAL, .BUSINESS, .CONTRACTORS, .CEO, and .COMPANY, moving away from previous commonly used TLDs or second-level domains like .SA.COM, .RU, and .ES. This trend became even more well-established in February. Following the March disruption, however, Microsoft Threat Intelligence observed a notable increase in Tycoon2FA domains with .RU registrations, with more than 41% of all Tycoon2FA domains using a .RU TLD since the last week of March.

Additionally, toward the end of March, we saw Tycoon2FA moving away from Cloudflare as a hosting service and now hosts most of its domains across a variety of alternative platforms, suggesting the group is attempting to find replacement services that offer comparable anti-analysis protections.  

QR code phishing attacks

In recent years, QR codes have rapidly emerged as a preferred tool among phishing threat actors seeking to bypass traditional email defenses. By embedding malicious URLs within image-based QR codes in the body of an email or within the contents of an attachment, threat actors attempt to exploit the limitations of text-based scanning engines and redirect victims to phishing sites on unmanaged mobile devices.

The most significant shift in Q1 2026 was the rapid escalation of QR code phishing, with attack volumes increasing from 7.6 million in January to 18.7 million in March, a 146% increase over the quarter. After an initial 35% decline in January (continuing a late-2025 downtrend), volumes reversed course dramatically, growing 59% in February and another 55% in March. By the end of the quarter, QR code phishing had reached its highest monthly volume in at least a year.

PDF attachments were the dominant delivery method throughout the quarter, growing from 65% of QR code attacks in January to 70% in March. While the overall volume of DOC/DOCX payloads containing malicious QR codes steadily increased each month, their share of overall delivery payloads decreased from 31% in January to 24% in March. A notable late-quarter development was the emergence of QR codes embedded directly in email bodies, which surged 336% in March. While still a small share of total volume (5%), this approach eliminates the need for an attachment altogether and highlights a shift in threat actor delivery methods that defenders should continue to monitor.

CAPTCHA tactics

Threat actors use CAPTCHA pages to delay detection and increase user interaction. These pages function as a visual decoy, giving the appearance of a legitimate security check while concealing a transition to malicious content. By forcing users to engage with the CAPTCHA before accessing the payload, threat actors reduce the likelihood of automated scanning tools identifying the threat and increase the chances of successful credential harvesting or malware delivery. Additionally, fake CAPTCHAs are used in ClickFix attacks to trick users into copying and executing malicious commands under the guise of human verification, allowing malware to bypass conventional security controls.

After declining in both January (-45%) and February (-8%), CAPTCHA-gated phishing volumes exploded in March, more than doubling (+125%) to 11.9 million attacks, the highest volume observed over the last year.

The most notable aspect of Q1 CAPTCHA trends was the rapid rotation of delivery methods, as threat actors appeared to actively experiment with which payload formats most effectively evade email defenses:

• HTML attachments started the year as the most common method to deliver CAPTCHA-gated phishing (37% in January), but dropped 34% in February, hitting its lowest monthly volume since August 2025. Although their volume more than doubled in March, hitting an annual monthly high, HTML files were still only the second-most common delivery method to close the quarter.

• SVG files, which had seen consecutive months of decreasing volumes, grew by 49% in February at the same time nearly every other delivery payload type decreased. Because of this, it was the most common delivery method for the month, which had not happened since November 2025. This one-month spike reversed itself in March, however, and the number of SVG files delivering CAPTCHA-gated phish fell by 57%, accounting for just 7% of delivery payloads.
• PDF files saw a meteoric rise in volume during the first quarter of the year. After seeing steady month-over-month declines since July 2025, and hitting an annual monthly low point in January 2026, the number of PDF attachments leading to CAPTCHA-gated phishing sites more than quadrupled in March (+356%). Not only did it retake its spot as the most common delivery method for these attacks since last July, but it eclipsed its annual high by more than 37%.
• DOC/DOCX files, which didn’t make up more than 9% of CAPTCHA-gated phishing payloads over the previous nine months, increased almost five times (+373%) in March to account for 15% of payloads.
• Email-embedded URLs, which had once delivered more than half of CAPTCHA-gated phish at the end of August 2025, hit an eight-month low after falling 85% between December and February. While their volume nearly doubled in March, they remained well below late-2025 levels.

Another notable shift in CAPTCHA-gated phishing attacks was the erosion of Tycoon2FA’s impact on the landscape. At the end of 2025, more than three-quarters of CAPTCHA-gated phishing sites were hosted on Tycoon2FA infrastructure. This share decreased significantly over the course of the first three months of 2026, falling to just 41% in March. This broadening of CAPTCHA-gated phishing sites being used by an increasing number of threat actors and phishing kits, combined with the overall surge in volume, indicates that this technique is becoming a more entrenched component of the phishing playbook rather than a specialty of a small number of tools.

Three-day campaign delivers CAPTCHA-gated phishing content using malicious SVG attachments

Between February 23 and February 25, 2026, a large, sustained campaign sent more than 1.2 million messages to users at more than 53,000 organizations in 23 countries. Messages in the campaign included a number of different themes, including an important 401K update, a credit hold warning, a question about a received payment, a payment request for a past due invoice, and a voice message notification.

Many of the messages contained a fake confidentiality disclaimer to enhance the credibility of the messages and provide a proactive excuse about why a recipient may have mistakenly received an email that may not be applicable to them.

Attached to each message was an SVG file that was named to appropriately match the theme of the email. All the file names included a Base64-encoded version of the recipient’s email address. Example of file names used in the campaign include the following:

• <Recipient Email Domain>_statements_inv_<Base64-encoded Email Address>.svg
• 401K_copy_<Recipient Name>_<Base64-encoded Email Address>_241.svg
• Check_2408_Payment_Copy_<Recipient First Name>_<Base64-encoded Email Address>_241.svg
• INV#_1709612175_<Base64-encoded Email Address>.svg
• Listen_(<Base64-encoded Email Address>).svg
• PLAY_AUDIO_MESSAGE__<Recipient Name>_<Base64-encoded Email Address>_241.svg

If an attached SVG file was opened, the user’s browser would open locally and fetch content from one of the three following hostnames:

• bouleversement.niovapahrm[.]com
• haematogenesis.hvishay[.]com
• ubiquitarianism.drilto[.]com

Initially, the user would be shown a “security check” CAPTCHA. Once the CAPTCHA had been successfully completed, the user would then be shown a fake sign-in page used to compromise their account credentials.

Malicious payloads

Credential phishing tightened its grip on the malicious payload landscape across Q1, growing from 89% of all payload-based attacks in January to 95% in February before settling at 94% in March. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery continued its long-term decline, representing just 5–6% of payloads by the end of the quarter.

The most striking payload trend was the volatility across file types, driven by large campaigns that created dramatic week-to-week swings:

• HTML attachments started Q1 as the leading file type (37% of payloads in January), fell to an annual low in February (-57%), then nearly tripled in March (+175%). This volatility was largely campaign-driven, with concentrated activity in the first half of January and the third week of March.
• Malicious PDFs followed a steady upward trajectory, increasing 38% in February and another 50% in March to reach their highest monthly volume in over a year. By March, PDFs accounted for 29% of payloads, up from 19% in January.
• ZIP/GZIP attachments were similarly volatile by nearly doubling in January (+94%), dropping 38% in February, then surging 79% in March. Threat actors commonly use ZIP files to circumvent Mark of the Web (MOTW) protections.
• SVG files emerged briefly in February as a notable delivery method (with a 50% volume increase) before declining 32% in March, mirroring the pattern seen in CAPTCHA-gated phishing.

Large-scale HTML phishing campaign hosts content on multiple PhaaS infrastructures

On March 17, 2026, Microsoft Threat Intelligence observed a massive phishing campaign that drove a significant surge in malicious HTML attachments during the month. The campaign involved more than 1.5 million confirmed malicious messages sent to over 179,000 organizations across 43 countries, accounting for approximately 7% of all malicious HTML attachments observed in March.

All messages in this campaign were likely sent using the same tool or service, which exhibited several distinct and highly consistent characteristics. Most notably, sender addresses across the campaign featured excessively long, keyword‑stuffed usernames that embedded URLs, tracking identifiers, and service references. These usernames were crafted to resemble legitimate transactional, billing, or document‑related notification senders. Examples of observed sender usernames include:

• eReceipt_Payment_Alert_Noreply-/m939k6d7.r.us-west-2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29-ab5789bd-1426-4800-ae7d-877ea7f61d24-000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-qq8m2tzd
• Center-=AAP1eU7NKykAABXNznVa8w___listenerId=AAP1eU7NKykAABXNznVa8w___aw_0_device.player_name=Chrome___aw_0_ivt.result=unknown___cbs=9901711___aw_0_azn.zposition=%5B%22undefined%22%5D___us_privacy=___aw_0_app.name=Second+Screen___externalClickUrl=otdk-takaki-h
• DocExchange_Noreply-m939k6d7.r.us_west_2.awstrack.me/L0/%2F%2Fspectrumbusiness.net%2Fbilling%2F/2/010101989f2c1f29ab5789bd14264800ae7d877ea7f61d24000000/LHnBIXX0VmCLVoXwNWtt23hGCdc=439/us02web.zoom.nl/j/81163775943?pwd=bLoo4JaWavsiTAuLWNoRsmbmALwjLB.1-angie

The emails themselves contained little to no message body content. While subject lines varied, they consistently impersonated routine business and workflow notifications, including payment and remittance alerts (for example, Automated Clearing House (ACH), Electronic Funds Transfer (EFT), wire), invoice or aging statements, and e‑signature or document delivery requests. These subjects relied on urgency, approval language, and transactional framing to prompt recipients to review, sign, or access an attached document.

Each message included an HTML attachment with a file name aligned to the email’s theme. When opened, the HTML file launched locally on the recipient’s device and immediately redirected the user to an initial external staging page. This page performed basic screening and then redirected the user to a secondary landing page hosting the phishing content. On the final landing page, users were presented with a CAPTCHA challenge before being directed to a fraudulent sign‑in page designed to harvest account credentials.

Interestingly, although messages in this campaign shared common tooling, structure, and delivery characteristics, the infrastructure hosting the final phishing payload was linked to multiple different PhaaS providers. Most observed phishing endpoints were associated with Tycoon2FA, while additional activity was linked to Kratos (formerly Sneaky2FA) and EvilTokens infrastructure.

Business email compromise

Microsoft defines business email compromise (BEC) as a text-based attack targeting enterprise users that impersonates a trusted entity for the purpose of persuading a recipient into initiating a fraudulent financial transaction or sending the threat actor sensitive documents. These attacks fluctuated across Q1, totaling approximately 10.7 million attacks: rising 24% in January, dipping 8% in February, then surging 26% in March.

The composition of BEC attacks remained consistent throughout Q1. Generic outreach messages (like “Are you at your desk?”) accounted for 82–84% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 9–10%. This pattern underscores that BEC operators overwhelmingly favor establishing a conversational rapport before making fraudulent requests, rather than leading with direct financial asks.

Within the smaller subset of explicit financial requests, two sub-categories showed notable movement. Payroll update requests grew 15% in February, reaching their highest volume in eight months, potentially reflecting tax season-related social engineering. Gift card requests fell 37% in February to their lowest level since July before rebounding sharply in March (+108%), though they still represented less than 3% of overall BEC messages. These fluctuations suggest that BEC operators adjust their specific financial pretexts seasonally while maintaining a consistent overall approach.

Defending against email threats

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

• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft Defender for Endpoint

The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.

• Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site

Microsoft Defender for Office 365

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Activity Profile: Email threat landscape, March 2026
• Activity Profile: Email threat landscape, February 2026
• Activity Profile: Email threat landscape, January 2026
• Tool Profile: Tycoon2FA
• Actor Profile: Storm-1747
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business Email Compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

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 Email threat landscape: Q1 2026 trends and insights appeared first on Microsoft Security Blog.

The shift to remote and hybrid work since the pandemic expanded global hiring and accelerated digital onboarding, increasing reliance on online identity verification and remote access. Threat actors such as Jasper Sleet, a North Korea-aligned threat actor, exploit this model by posing as legitimate hires using stolen or fabricated identities and AI-assisted deception to gain trusted access, generate revenue, and in some cases enable data theft, extortion, or follow-on compromise.

In the initial job-discovery phase, these fraudulent applicants posing as remote IT workers systematically survey organization career sites and external hiring portals to identify active technical roles and recruitment workflows. A previously published Microsoft Threat Intelligence blog highlights how these actors use generative AI at scale to analyze job postings and extract role‑specific language, required skills, certifications, and tooling expectations. They then use those insights to construct tailored fake digital personas and submit highly convincing job applications, increasing their likelihood of passing screening and entering legitimate hiring pipelines, and even onboarding once hired into the targeted roles successfully.

Organizations using common and widely adopted human resources (HR) software as a service (SaaS) platforms like Workday often expose their job postings through external career sites for applicants to submit job applications. These job listing sites are often targeted by this threat actor to find open job roles. While this activity might be hard to detect from usual job hunting behavior, knowing the threat actor’s interests and objectives to infiltrate into the target organization might present an opportunity for defenders to look for anomalous patterns in a hiring candidate’s behaviors by leveraging the access to the right telemetry and available threat actor intelligence being published.

While these activities could happen on any HR SaaS platform, this blog focuses on Workday as an example due to its widespread adoption and rich event logs, which are useful for hunting and detection, that are available to customers. The discussion highlights how customers using Microsoft Defender for Cloud Apps can monitor and detect fraudulent remote IT worker activity in pre-recruitment and post-recruitment phases, offering guidance on threat hunting and relevant threat detection strategies to help security and HR teams surface suspicious candidates early and detect risky onboarding activity after hire.

Attack chain overview

In the observed campaigns, the threat actors leverage routine HR workflows like external-facing career sites with open job postings to help with their job search and application process. Once they’re successfully contacted, interviewed, and hired, they complete typical new-hire onboarding formalities like setting up payroll accounts, which are also through the HR SaaS platform like Workday.

Activities in pre-recruitment phase

In the pre-recruitment phase, Microsoft has observed Jasper Sleet accessing Workday Recruiting Web Service endpoints exposed through external career sites from known actor infrastructure and email accounts, indicating a discovery phase of open roles and recruitment workflows.

Workday lets organizations use internal, non-public APIs such as Recruiting Web Service to allow programmatic access to apply for jobs in these organizations. These APIs are used to connect to external career sites involved in talent management and applicant tracking systems and allow applicants to browse and apply for open job roles. To access these APIs, an organization has to allow setting up of OAuth clients and associated OAuth tokens, and expose the APIs so that the organization’s external career sites can use them.

Microsoft has observed API call events coming from known Jasper Sleet infrastructure in Workday telemetry to hrrecruiting/* API endpoints. These events access information about job postings, applications, and related questionnaires, and to submit job applications and questionnaires.

Some common API calls being made by the threat actor’s activity when using the Workday portal include the following:

• hrrecruiting/accounts/*
• hrrecruiting/jobApplicationPackages/*
• hrrecruiting/validateJobApplication/*
• hrrecruiting/resumes/*

It’s important to note here that these API calls could also be made by legitimate job applicants. However, Microsoft has observed the Jasper Sleet threat actor using multiple external accounts suspiciously to access the same set of API calls in a consistent, repeating pattern, as shown in Figure 2, indicating a possible job discovery phase activity on open job roles and following up on job applications submitted. This anomaly sets the threat actor behavior apart from legitimate job applicants.

Defender for Cloud Apps’ Workday connector enables organizations to view and track API activity to their /hrrecruiting endpoints. The connector also lets them identify external accounts and their corresponding infrastructure metadata. Organizations can match this information against any available threat intelligence feeds on Jasper Sleet so they can identify fraudulent applications early in the recruiting process.

Activities in recruiting phase

In the recruiting phase, signals outside of Workday could help with investigation of threat actor behavior. The threat actor communicates with the target organization’s hiring team using emails and meeting conferencing platforms like Microsoft Teams, Zoom, or Cisco Webex for scheduling interviews. Using advanced hunting tables in Microsoft Defender, organizations can track suspicious communications (for example, email and Teams messages with external accounts originating from suspicious IP addresses or email addresses that could possibly be associated with the threat actor) and raise a red flag early in the hiring process. Additionally, organizations that use Zoom or Cisco Webex must leverage Defender for Cloud Apps’ Zoom or Cisco Webex connectors to detect malicious external accounts in the interviewing process.

Organizations can also leverage Defender for Cloud Apps’ DocuSign connector, which enables them to monitor activity related to hiring documentation, like offer letter signing from suspicious external sources.

Activities in post-recruitment phase

When Jasper Sleet is hired for a role in the organization, a legitimate account is created and assigned to them as part of the onboarding process. In organizations that use HR workflows in Workday for onboarding new hires, we’ve observed sign-ins to the newly created Workday profile and setting up of payroll details originating from known Jasper Sleet infrastructure.

The threat actor now has legitimate access to organization data, and they can access internal SaaS applications like Teams, SharePoint, OneDrive, and Exchange Online. Hence, it’s important to investigate any alerts associated with new hire accounts, especially alerts that are related to access to organization data from different locations and anonymous proxies performing search and downloads on Microsoft 365 suite or other third-party SaaS applications. Microsoft has observed a spike in impossible travel alerts for such new hires, indicating suspicious remote IT worker behavior in the initial months of onboarding.

Mitigation and protection guidance

Microsoft recommends leveraging access to telemetry coming from multiple data sources and monitoring behavioral anomalies in hiring candidates as part of background verification in HR recruitment processes. Organizations can also leverage threat intelligence as an aid, when available, to strengthen confidence in these anomalies.

These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR. 

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

Enable connectors in Microsoft Defender for Cloud Apps to gain visibility and track activity from external user accounts associated with fraudulent candidates. Investigate events of both external users and newly hired internal users originating from malicious infrastructure. For more information, see the following articles in Microsoft Learn:

• How Defender for Cloud Apps helps protect your Workday environment
• How Defender for Cloud Apps helps protect your DocuSign environment
• How Defender for Cloud Apps helps protect your Cisco Webex environment
• Connect Zoom to Microsoft Defender for Cloud Apps (Preview)

Educate users on social engineering. Train employees to recognize suspicious behaviors during hiring process and in new hires. For more information on the threat actor behavior, read this blog: Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations

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 Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor profile: Jasper Sleet

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR customers can run the following queries to find related activity to any suspicious indicators in their networks:

Access to Workday Recruiting Web Service API by external users

let api_endpoint_regex = 'hrrecruiting/*';
CloudAppEvents
| where Application == 'Workday'
| where IsExternalUser
| where ActionType matches regex api_endpoint_regex
| where IPAddress in () or AccountId in ();
| summarize make_set(ActionType) by AccountId, IPAddress, bin(Timestamp, 1d)

Emails and Teams communications related to interviews

//Email communications

EmailEvents 
| where SenderMailFromAddress == "" or RecipientEmailAddress == ""
| where Subject has "Interview"
| project Timestamp, SenderMailFromAddress, SenderDisplayName, SenderIPv4, SenderIPv6, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation

EmailEvents 
| where SenderIPv4 == "" or SenderIPv6 == ""
| where Subject has "Interview"
| project Timestamp, SenderMailFromAddress, SenderDisplayName, SenderIPv4, SenderIPv6, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation

//Microsoft Teams communications

CloudAppEvents
| where Application == "Microsoft Teams"
| where IsExternalUser
| where AccountId == "" or AccountDisplayName == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

CloudAppEvents
| where Application == "Microsoft Teams"
| where IsExternalUser
| where IPAddress == "" 
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

//Zoom or Cisco Webex communication events after enabling the Microsoft Defender for Cloud apps connectors

CloudAppEvents
| where Application == "Zoom"
| where IsExternalUser
| where IPAddress == "" 
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

CloudAppEvents
| where Application == "Cisco Webex"
| where IsExternalUser
| where IPAddress == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)

Hiring phase involving accessing and signing of agreements through DocuSign

CloudAppEvents
| where Application == "DocuSign"
| where IsExternalUser
| where ActionType == "ENVELOPE SIGNED"
| where IPAddress in ("") or AccountId == ""

New hire onboarding and payroll activities originating from known Jasper Sleet infrastructure

CloudAppEvents
| where Application == "Workday"
| where AccountId == ""
| where ActionType has_any ("Add", "Change", "Assign", "Create", "Modify") and ActionType has_any ("Account", "Bank", "Payment", "Tax")
| where IPAddress in ("")
| summarize make_set(ActionType) by IPAddress, bin(Timestamp, 1d)

References

• Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations | Microsoft Security Blog
• AI as tradecraft: How threat actors operationalize AI | Microsoft Security Blog

This research is provided by Microsoft Defender Security Research with contributions from  members of Microsoft Threat Intelligence.

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.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 

The post Detection strategies across cloud and identities against infiltrating IT workers appeared first on Microsoft Security Blog.

Executive summary

Microsoft Threat Intelligence uncovered a macOS‑focused cyber campaign by the North Korean threat actor Sapphire Sleet that relies on social engineering rather than software vulnerabilities. By impersonating a legitimate software update, threat actors tricked users into manually running malicious files, allowing them to steal passwords, cryptocurrency assets, and personal data while avoiding built‑in macOS security checks. This activity highlights how convincing user prompts and trusted system tools can be abused, and why awareness and layered security defenses remain critical.

Microsoft Threat Intelligence identified a campaign by North Korean state actor Sapphire Sleet demonstrating new combinations of macOS-focused execution patterns and techniques, enabling the threat actor to compromise systems through social engineering rather than software exploitation. In this campaign, Sapphire Sleet takes advantage of user‑initiated execution to establish persistence, harvest credentials, and exfiltrate sensitive data while operating outside traditional macOS security enforcement boundaries. While the techniques themselves are not novel, this analysis highlights execution patterns and combinations that Microsoft has not previously observed for this threat actor, including how Sapphire Sleet orchestrates these techniques together and uses AppleScript as a dedicated, late‑stage credential‑harvesting component integrated with decoy update workflows.

After discovering the threat, Microsoft shared details of this activity with Apple as part of our responsible disclosure process. Apple has since implemented updates to help detect and block infrastructure and malware associated with this campaign. We thank the Apple security team for their collaboration in addressing this activity and encourage macOS users to keep their devices up to date with the latest security protections.

This activity demonstrates how threat actors continue to rely on user interaction and trusted system utilities to bypass macOS platform security protections, rather than exploiting traditional software vulnerabilities. By persuading users to manually execute AppleScript or Terminal‑based commands, Sapphire Sleet shifts execution into a user‑initiated context, allowing the activity to proceed outside of macOS protections such as Transparency, Consent, and Control (TCC), Gatekeeper, quarantine enforcement, and notarization checks. Sapphire Sleet achieves a highly reliable infection chain that lowers operational friction and increases the likelihood of successful compromise—posing an elevated risk to organizations and individuals involved in cryptocurrency, digital assets, finance, and similar high‑value targets that Sapphire Sleet is known to target.

In this blog, we examine the macOS‑specific attack chain observed in recent Sapphire Sleet intrusions, from initial access using malicious .scpt files through multi-stage payload delivery, credential harvesting using fake system dialogs, manipulation of the macOS TCC database, persistence using launch daemons, and large-scale data exfiltration. We also provide actionable guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help defenders identify similar threats and strengthen macOS security posture.

Sapphire Sleet’s campaign lifecycle

Initial access and social engineering

Sapphire Sleet is a North Korean state actor active since at least March 2020 that primarily targets the finance sector, including cryptocurrency, venture capital, and blockchain organizations. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.

Sapphire Sleet operates a well‑documented social engineering playbook in which the threat actor creates fake recruiter profiles on social media and professional networking platforms, engages targets in conversations about job opportunities, schedules a technical interview, and directs targets to install malicious software, which is typically disguised as a video conferencing tool or software developer kit (SDK) update.

In this observed activity, the target was directed to download a file called Zoom SDK Update.scpt—a compiled AppleScript that opens in macOS Script Editor by default. Script Editor is a trusted first-party Apple application capable of executing arbitrary shell commands using the do shell script AppleScript command.

Lure file and Script Editor execution

The malicious Zoom SDK Update.scpt file is crafted to appear as a legitimate Zoom SDK update when opened in the macOS Script Editor app, beginning with a large decoy comment block that mimics benign upgrade instructions and gives the impression of a routine software update. To conceal its true behavior, the script inserts thousands of blank lines immediately after this visible content, pushing the malicious logic far below the scrollable view of the Script Editor window and reducing the likelihood that a user will notice it.

Hidden beneath this decoy, the script first launches a harmless looking command that invokes the legitimate macOS softwareupdate binary with an invalid parameter, an action that performs no real update but launches a trusted Apple‑signed process to reinforce the appearance of legitimacy. Following this, the script executes its malicious payload by using curl to retrieve threat actor‑controlled content and immediately passes the returned data to osascript for execution using the run script result instruction. Because the content fetched by curl is itself a new AppleScript, it is launched directly within the Script Editor context, initiating a payload delivery in which additional stages are dynamically downloaded and executed.

Execution and payload delivery

Cascading curl-to-osascript execution

When the user opens the Zoom SDK Update.scpt file, macOS launches the file in Script Editor, allowing Sapphire Sleet to transition from a single lure file to a multi-stage, dynamically fetched payload chain. From this single process, the entire attack unfolds through a cascading chain of curl commands, each fetching and executing progressively more complex AppleScript payloads. Each stage uses a distinct user-agent string as a campaign tracking identifier.

The main payload fetched by the mac-cur1 user agent is the attack orchestrator. Once executed within the Script Editor, it performs immediate reconnaissance, then kicks off parallel operations using additional curl commands with different user-agent strings.

Note the URL path difference: mac-cur1 through mac-cur3 fetch from /version/ (AppleScript payloads piped directly to osascript for execution), while mac-cur4 and mac-cur5 fetch from /status/ (ZIP archives containing compiled macOS .app bundles).

The following table summarizes the curl chain used in this campaign.

Reconnaissance and C2 registration

After execution, the malware next identifies and registers the compromised device with Sapphire Sleet infrastructure. The malware starts by collecting basic system details such as the current user, host name, system time, and operating system install date. This information is used to uniquely identify the compromised device and track subsequent activity.

The malware then registers the compromised system with its command‑and‑control (C2) infrastructure. The mid value represents the device’s universally unique identifier (UUID), the did serves as a campaign‑level tracking identifier, and the user field combines the system host name with the device serial number to uniquely label the targeted user.

Host monitoring component: com.apple.cli

The first binary deployed is a host monitoring component called com.apple.cli—a ~5 MB Mach-O binary disguised with an Apple-style naming convention.

The mac-cur1 payload spawns an osascript that downloads and launches com.apple.cli:

The host monitoring component repeatedly executes a series of system commands to collect environment and runtime information, including the macOS version (sw_vers), the current system time (date -u), and the underlying hardware model (sysctl hw.model). It then runs ps aux in a tight loop to capture a full, real‑time list of running processes.

During execution, com.apple.cli performs host reconnaissance while maintaining repeated outbound connectivity to the threat actor‑controlled C2 endpoint 83.136.208[.]246:6783. The observed sequencing of reconnaissance activity and network communication is consistent with staging for later operational activity, including privilege escalation, and exfiltration.

In parallel with deploying com.apple.cli, the mac-cur1 orchestrator also deploys a second component, the services backdoor, as part of the same execution flow; its role in persistence and follow‑on activity is described later in this blog.

Credential access

Credential harvester: systemupdate.app

After performing reconnaissance, the mac-cur1 orchestrator begins parallel operations. During the mac‑cur2 stage of execution (independent from the mac-cur1 stage), Sapphire Sleet delivers an AppleScript payload that is executed through osascript. This stage is responsible for deploying the credential harvesting component of the attack.

Before proceeding, the script checks for the presence of a file named .zoom.log on the system. This file acts as an infection marker, allowing Sapphire Sleet to determine whether the device has already been compromised. If the marker exists, deployment is skipped to avoid redundant execution across sessions.

If the infection marker is not found, the script downloads a compressed archive through the mac-cur4 user agent that contains a malicious macOS application named (systemupdate.app), which masquerades as the legitimate system update utility by the same name. The archive is extracted to a temporary location, and the application is launched immediately.

When systemupdate.app launches, the user is presented with a native macOS password dialog that is visually indistinguishable from a legitimate system prompt. The dialog claims that the user’s password is required to complete a software update, prompting the user to enter their credentials.

After the user enters their password, the malware performs two sequential actions to ensure the credential is usable and immediately captured. First, the binary validates the entered password against the local macOS authentication database using directory services, confirming that the credential is correct and not mistyped. Once validation succeeds, the verified password is immediately exfiltrated to threat actor‑controlled infrastructure using the Telegram Bot API, delivering the stolen credential directly to Sapphire Sleet.

Decoy completion prompt: softwareupdate.app

After credential harvesting is completed using systemupdate.app, Sapphire Sleet deploys a second malicious application named softwareupdate.app, whose sole purpose is to reinforce the illusion of a legitimate update workflow. This application is delivered during a later stage of the attack using the mac‑cur5 user‑agent. Unlike systemupdate.app, softwareupdate.app does not attempt to collect credentials. Instead, it displays a convincing “system update complete” dialog to the user, signaling that the supposed Zoom SDK update has finished successfully. This final step closes the social engineering loop: the user initiated a Zoom‑themed update, was prompted to enter their password, and is now reassured that the process completed as expected, reducing the likelihood of suspicion or further investigation.

Persistence

Primary backdoor and persistence installer: services binary

The services backdoor is a key operational component in this attack, acting as the primary backdoor and persistence installer. It provides an interactive command execution channel, establishes persistence using a launch daemon, and deploys two additional backdoors. The services backdoor is deployed through a dedicated AppleScript executed as part of the initial mac‑cur1 payload that also deployed com.apple.cli, although the additional backdoors deployed by services are executed at a later stage.

During deployment, the services backdoor binary is first downloaded using a hidden file name (.services) to reduce visibility, then copied to its final location before the temporary file is removed. As part of installation, the malware creates a file named auth.db under ~/Library/Application Support/Authorization/, which stores the path to the deployed services backdoor and serves as a persistent installation marker. Any execution or runtime errors encountered during this process are written to /tmp/lg4err, leaving behind an additional forensic artifact that can aid post‑compromise investigation.

Unlike com.apple.cli, the services backdoor uses interactive zsh shells (/bin/zsh -i) to execute privileged operations. The -i flag creates an interactive terminal context, which is required for sudo commands that expect interactive input.

Additional backdoors: icloudz and com.google.chromes.updaters

Of the additional backdoors deployed by services, the icloudz backdoor is a renamed copy of the previously deployed services backdoor and shares the same SHA‑256 hash, indicating identical underlying code. Despite this, it is executed using a different and more evasive technique. Although icloudz shares the same binary as .services, it operates as a reflective code loader—it uses the macOS NSCreateObjectFileImageFromMemory API to load additional payloads received from its C2 infrastructure directly into memory, rather than writing them to disk and executing them conventionally.

The icloudz backdoor is stored at ~/Library/Application Support/iCloud/icloudz, a location and naming choice intended to resemble legitimate iCloud‑related artifacts. Once loaded into memory, two distinct execution waves are observed. Each wave independently initializes a consistent sequence of system commands: existing caffeinate processes are stopped, caffeinate is relaunched using nohup to prevent the system from sleeping, basic system information is collected using sw_vers and sysctl -n hw.model, and an interactive /bin/zsh -i shell is spawned. This repeated initialization suggests that the component is designed to re‑establish execution context reliably across runs.

From within the interactive zsh shell, icloudz deploys an additional (tertiary) backdoor, com.google.chromes.updaters, to disk at ~/Library/Google/com.google.chromes.updaters. The selected directory and file name closely resemble legitimate Google application data, helping the file blend into the user’s Home directory and reducing the likelihood of casual inspection. File permissions are adjusted; ownership is set to allow execution with elevated privileges, and the com.google.chromes.updaters binary is launched using sudo.

To ensure continued execution across reboots, a launch daemon configuration file named com.google.webkit.service.plist is installed under /Library/LaunchDaemons. This configuration causes icloudz to launch automatically at system startup, even if no user is signed in. The naming convention deliberately mimics legitimate Apple and Google system services, further reducing the chance of detection.

The com.google.chromes.updaters backdoor is the final and largest component deployed in this attack chain, with a size of approximately 7.2 MB. Once running, it establishes outbound communication with threat actor‑controlled infrastructure, connecting to the domain check02id[.]com over port 5202. The process then enters a precise 60‑second beaconing loop. During each cycle, it executes minimal commands such as whoami to confirm the execution context and sw_vers -productVersion to report the operating system version. This lightweight heartbeat confirms the process remains active, is running with elevated privileges, and is ready to receive further instructions.

Privilege escalation

TCC bypass: Granting AppleEvents permissions

Before large‑scale data access and exfiltration can proceed, Sapphire Sleet must bypass macOS TCC protections. TCC enforces user consent for sensitive inter‑process interactions, including AppleEvents, the mechanism required for osascript to communicate with Finder and perform file-level operations. The mac-cur3 stage silently grants itself these permissions by directly manipulating the user-level TCC database through the following sequence.

The user-level TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) is itself TCC-protected—processes without Full Disk Access (FDA) cannot read or modify it. Sapphire Sleet circumvents this by directing Finder, which holds FDA by default on macOS,  to rename the com.apple.TCC folder. Once renamed, the TCC database file can be copied to a staging location by a process without FDA.

Sapphire Sleet then uses sqlite3 to inject a new entry into the database’s access table. This entry grants /usr/bin/osascript permission to send AppleEvents to com.apple.finder and includes valid code-signing requirement (csreq) blobs for both binaries, binding the grant to Apple-signed executables. The authorization value is set to allowed (auth_value=2) with a user-set reason (auth_reason=3), ensuring no user prompt is triggered. The modified database is then copied back into the renamed folder, and Finder restores the folder to its original name. Staging files are deleted to reduce forensic traces.

Collection and exfiltration

With TCC bypassed, credentials stolen, and backdoors deployed, Sapphire Sleet launches the next phase of attack: a 575-line AppleScript payload that systematically collects, stages, compresses, and exfiltrates seven categories of data.

Exfiltration architecture

Every upload follows a consistent pattern and is executed using nohup, which allows the command to continue running in the background even if the initiating process or Terminal session exits. This ensures that data exfiltration can complete reliably without requiring the threat actor to maintain an active session on the system.

The auth header provides the upload authorization token, and the mid header ties the upload to the compromised device’s UUID.

Data collected during exfiltration

• Host and system reconnaissance: Before bulk data collection begins, the script records basic system identity and hardware information. This includes the current username, system host name, macOS version, and CPU model. These values are appended to a per‑host log file and provide Sapphire Sleet with environmental context, hardware fingerprinting, and confirmation of the target system’s characteristics. This reconnaissance data is later uploaded to track progress and correlate subsequent exfiltration stages to a specific device.
• Installed applications and runtime verification: The script enumerates installed applications and shared directories to build an inventory of the system’s software environment. It also captures a live process listing filtered for threat actor‑deployed components, allowing Sapphire Sleet to verify that earlier payloads are still running as expected. These checks help confirm successful execution and persistence before proceeding further.
• Messaging session data (Telegram): Telegram Desktop session data is collected by copying the application’s data directories, including cryptographic key material and session mapping files. These artifacts are sufficient to recreate the user’s Telegram session on another system without requiring reauthentication. A second collection pass targets the Telegram App Group container to capture the complete local data set associated with the application.
• Browser data and extension storage: For Chromium‑based browsers, including Chrome, Brave, and Arc, the script copies browser profiles and associated databases. This includes saved credentials, cookies, autofill data, browsing history, bookmarks, and extension‑specific storage. Particular focus is placed on IndexedDB entries associated with cryptocurrency wallet extensions, where wallet keys and transaction data are stored. Only IndexedDB entries matching a targeted set of wallet extension identifiers are collected, reflecting a deliberate and selective approach.
• macOS keychain: The user’s sign-in keychain database is bundled alongside browser data. Although the keychain is encrypted, Sapphire Sleet has already captured the user’s password earlier in the attack chain, enabling offline decryption of stored secrets once exfiltrated.
• Cryptocurrency desktop wallets: The script copies the full application support directories for popular cryptocurrency desktop wallets, including Ledger Live and Exodus. These directories contain wallet configuration files and key material required to access stored cryptocurrency assets, making them high‑value targets for exfiltration.
• SSH keys and shell history: SSH key directories and shell history files are collected to enable potential lateral movement and intelligence gathering. SSH keys may provide access to additional systems, while shell history can reveal infrastructure details, previously accessed hosts, and operational habits of the targeted user.
• Apple Notes: The Apple Notes database is copied from its application container and staged for upload. Notes frequently contain sensitive information such as passwords, internal documentation, infrastructure details, or meeting notes, making them a valuable secondary data source.
• System logs and failed access attempts: System log files are uploaded directly without compression. These logs provide additional hardware and execution context and include progress markers that indicate which exfiltration stages have completed. Failed collection attempts—such as access to password manager containers that are not present on the system—are also recorded and uploaded, allowing Sapphire Sleet to understand which targets were unavailable on the compromised host.

Exfiltration summary

All uploads use the upload authorization token fwyan48umt1vimwqcqvhdd9u72a7qysi and the machine identifier 82cf5d92-87b5-4144-9a4e-6b58b714d599.

Defending against Sapphire Sleet intrusion activity

As part of a coordinated response to this activity, Apple has implemented platform-level protections to help detect and block infrastructure and malware associated with this campaign. Apple has deployed Apple Safe Browsing protections in Safari to detect and block malicious infrastructure associated with this campaign. Users browsing with Safari benefit from these protections by default. Apple has also deployed XProtect signatures to detect and block the malware families associated with this campaign—macOS devices receive these signature updates automatically.

Microsoft recommends the following mitigation steps to defend against this activity and reduce the impact of this threat:

• Educate users about social engineering threats originating from social media and external platforms, particularly unsolicited outreach requesting software downloads, virtual meeting tool installations, or execution of terminal commands. Users should never run scripts or commands shared through messages, calls, or chats without prior approval from their IT or security teams.
• Block or restrict the execution of .scpt (compiled AppleScript) files and unsigned Mach-O binaries downloaded from the internet. Where feasible, enforce policies that prevent osascript from executing scripts sourced from external locations.
• Always inspect and verify files downloaded from external sources, including compiled AppleScript (.scpt) files. These files can execute arbitrary shell commands via macOS Script Editor—a trusted first-party Apple application—making them an effective and stealthy initial access vector.
• Limit or audit the use of curl piped to interpreters (such as curl | osascript, curl | sh, curl | bash). Social engineering campaigns by Sapphire Sleet rely on cascading curl-to-interpreter chains to avoid writing payloads to disk. Organizations should monitor for and restrict piped execution patterns originating from non-standard user-agent strings.
• Exercise caution when copying and pasting sensitive data such as wallet addresses or credentials from the clipboard. Always verify that the pasted content matches the intended source to avoid falling victim to clipboard hijacking or data tampering attacks.
• Monitor for unauthorized modifications to the macOS TCC database. This campaign manipulates TCC.db to grant AppleEvents permissions to osascript without user consent—a prerequisite for the large-scale data exfiltration phase. Look for processes copying, modifying, or overwriting ~/Library/Application Support/com.apple.TCC/TCC.db.
• Audit LaunchDaemon and LaunchAgent installations. This campaign installs a persistent launch daemon (com.google.webkit.service.plist) that masquerades as a legitimate Google or Apple service. Monitor /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for unexpected plist files, particularly those with com.google.* or com.apple.* naming conventions not belonging to genuine vendor software.
• Protect cryptocurrency wallets and browser credential stores. This campaign targets nine specific crypto wallet extensions (Sui, Phantom, TronLink, Coinbase, OKX, Solflare, Rabby, Backpack) plus Bitwarden, and exfiltrates browser sign-in data, cookies, and keychain databases. Organizations handling digital assets should enforce hardware wallet policies and rotate browser-stored credentials regularly.
• Encourage users to use web browsers that support Microsoft Defender SmartScreen like Microsoft Edge—available on macOS and various platforms—which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.

Microsoft Defender for Endpoint customers can also apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:

• Use Microsoft Defender for Endpoint on Mac, which detects, stops, and quarantines the malware discussed in this blog.
• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
• Turn on network protection to block connections to malicious domains and IP addresses.

Microsoft Defender detection and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Actor Profile: Sapphire Sleet

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Suspicious osascript execution with curl piping

Search for curl commands piping output directly to osascript, a core technique in this Sapphire Sleet campaign’s cascading payload delivery chain.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "osascript" or InitiatingProcessFileName == "osascript"
 | where ProcessCommandLine has "curl" and ProcessCommandLine has_any ("osascript", "| sh", "| bash")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName

Suspicious curl activity with campaign user-agent strings

Search for curl commands using user-agent strings matching the Sapphire Sleet campaign tracking identifiers (mac-cur1 through mac-cur5, audio, beacon).

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "curl" or ProcessCommandLine has "curl"
 | where ProcessCommandLine has_any ("mac-cur1", "mac-cur2", "mac-cur3", "mac-cur4", "mac-cur5", "-A audio", "-A beacon")
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect connectivity with known C2 infrastructure

Search for network connections to the Sapphire Sleet C2 domains and IP addresses used in this campaign.

let c2_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let c2_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has_any (c2_domains) or RemoteIP in (c2_ips)
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

TCC database manipulation detection

Search for processes that copy, modify, or overwrite the macOS TCC database, a key defense evasion technique used by this campaign to grant unauthorized AppleEvents permissions.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath has "com.apple.TCC" and FileName == "TCC.db"
 | where ActionType in ("FileCreated", "FileModified", "FileRenamed")
 | project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

Suspicious LaunchDaemon creation masquerading as legitimate services

Search for LaunchDaemon plist files created in /Library/LaunchDaemons that masquerade as Google or Apple services, matching the persistence technique used by the services/icloudz backdoor.

DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FolderPath startswith "/Library/LaunchDaemons/"
 | where FileName startswith "com.google." or FileName startswith "com.apple."
 | where ActionType == "FileCreated"
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256

Malicious binary execution from suspicious paths

Search for execution of binaries from paths commonly used by Sapphire Sleet, including hidden Library directories, /private/tmp/, and user-specific Application Support folders.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FolderPath has_any (
     "Library/Services/services",
     "Application Support/iCloud/icloudz",
     "Library/Google/com.google.chromes.updaters",
     "/private/tmp/SystemUpdate/",
     "/private/tmp/SoftwareUpdate/",
     "com.apple.cli"
 )
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, ProcessCommandLine, AccountName, SHA256

Credential harvesting using dscl authentication check

Search for dscl -authonly commands used by the fake password dialog (systemupdate.app) to validate stolen credentials before exfiltration.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where FileName == "dscl" or ProcessCommandLine has "dscl"
 | where ProcessCommandLine has "-authonly"
 | project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Telegram Bot API exfiltration detection

Search for network connections to Telegram Bot API endpoints, used by this campaign to exfiltrate stolen credentials.

DeviceNetworkEvents
 | where Timestamp > ago(30d)
 | where RemoteUrl has "api.telegram.org" and RemoteUrl has "/bot"
 | project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine

Reflective code loading using NSCreateObjectFileImageFromMemory

Search for evidence of reflective Mach-O loading, the technique used by the icloudz backdoor to execute code in memory.

DeviceEvents
 | where Timestamp > ago(30d)
 | where ActionType has "NSCreateObjectFileImageFromMemory"
     or AdditionalFields has "NSCreateObjectFileImageFromMemory"
 | project Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName, AdditionalFields

Suspicious caffeinate and sleep prevention activity

Search for caffeinate process stop-and-restart patterns used by the services and icloudz backdoors to prevent the system from sleeping during backdoor operations.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where ProcessCommandLine has "caffeinate"
 | where InitiatingProcessCommandLine has_any ("icloudz", "services", "chromes.updaters", "zsh -i")
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Detect known malicious file hashes

Search for the specific malicious file hashes associated with this Sapphire Sleet campaign across file events.

let malicious_hashes = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 DeviceFileEvents
 | where Timestamp > ago(30d)
 | where SHA256 in (malicious_hashes)
 | project Timestamp, DeviceId, DeviceName, FileName, FolderPath, SHA256, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine

Data staging and exfiltration activity

Search for ZIP archive creation in /tmp/ directories followed by curl uploads matching the staging-and-exfiltration pattern used for browser data, crypto wallets, Telegram sessions, SSH keys, and Apple Notes.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where (ProcessCommandLine has "zip" and ProcessCommandLine has "/tmp/")
     or (ProcessCommandLine has "curl" and ProcessCommandLine has_any ("tapp_", "ext_", "ldg_", "exds_", "hs_", "nt_", "lg_"))
 | project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Script Editor launching suspicious child processes

Search for Script Editor (the default handler for .scpt files) spawning curl, osascript, or shell commands—the initial execution vector in this campaign.

DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where InitiatingProcessFileName == "Script Editor" or InitiatingProcessCommandLine has "Script Editor"
 | where FileName has_any ("curl", "osascript", "sh", "bash", "zsh")
 | project Timestamp, DeviceId, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect network indicators of compromise

The following query checks for connections to the Sapphire Sleet C2 domains and IP addresses across network session data:

let lookback = 30d;
 let ioc_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
 let ioc_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
 DeviceNetworkEvents
 | where TimeGenerated > ago(lookback)
 | where RemoteUrl has_any (ioc_domains) or RemoteIP in (ioc_ips)
 | summarize EventCount=count() by DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName

Detect file hash indicators of compromise

The following query searches for the known malicious file hashes associated with this campaign across file, process, and security event data:

let selectedTimestamp = datetime(2026-01-01T00:00:00.0000000Z);
 let FileSHA256 = dynamic([
     "2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
     "05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
     "5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
     "5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
     "95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
     "8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
     "a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
 ]);
 search in (AlertEvidence, DeviceEvents, DeviceFileEvents, DeviceImageLoadEvents, DeviceProcessEvents, DeviceNetworkEvents, SecurityEvent, ThreatIntelligenceIndicator)
 TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d))
 and (SHA256 in (FileSHA256) or InitiatingProcessSHA256 in (FileSHA256))

Detect Microsoft Defender Antivirus detections related to Sapphire Sleet

The following query searches for Defender Antivirus alerts for the specific malware families used in this campaign and joins with device information for enriched context:

let SapphireSleet_threats = dynamic([
     "Trojan:MacOS/NukeSped.D",
     "Trojan:MacOS/PassStealer.D",
     "Trojan:MacOS/SuspMalScript.C",
     "Trojan:MacOS/SuspInfostealExec.C"
 ]);
 SecurityAlert
 | where ProviderName == "MDATP"
 | extend ThreatName = tostring(parse_json(ExtendedProperties).ThreatName)
 | extend ThreatFamilyName = tostring(parse_json(ExtendedProperties).ThreatFamilyName)
 | where ThreatName in~ (SapphireSleet_threats) or ThreatFamilyName in~ (SapphireSleet_threats)
 | extend CompromisedEntity = tolower(CompromisedEntity)
 | join kind=inner (
     DeviceInfo
     | extend DeviceName = tolower(DeviceName)
 ) on $left.CompromisedEntity == $right.DeviceName
 | summarize arg_max(TimeGenerated, *) by DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, tostring(LoggedOnUsers), DeviceId, TenantId, CompromisedEntity, ProductName, Entities
 | extend HostName = tostring(split(CompromisedEntity, ".")[0]), DomainIndex = toint(indexof(CompromisedEntity, '.'))
 | extend HostNameDomain = iff(DomainIndex != -1, substring(CompromisedEntity, DomainIndex + 1), CompromisedEntity)
 | project-away DomainIndex
 | project TimeGenerated, DisplayName, ThreatName, ThreatFamilyName, PublicIP, AlertSeverity, Description, LoggedOnUsers, DeviceId, TenantId, CompromisedEntity, ProductName, Entities, HostName, HostNameDomain

Indicators of compromise

Malicious file hashes

Domains and IP addresses

Acknowledgments

Existing blogs with similar behavior tracked:

• https://cloud.google.com/blog/topics/threat-intelligence/unc1069-targets-cryptocurrency-ai-social-engineering
• https://www.huntress.com/blog/inside-bluenoroff-web3-intrusion-analysis
• https://securelist.com/bluenoroff-apt-campaigns-ghostcall-and-ghosthie/117842/
• https://x.com/malwrhunterteam/status/2008831892616081508
• https://x.com/patrickwardle/status/2009008936771543341?s=46

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 Dissecting Sapphire Sleet’s macOS intrusion from lure to compromise appeared first on Microsoft Security Blog.

In mid-January 2026, Microsoft Defender Experts identified a credential theft campaign that uses fake virtual private network (VPN) clients distributed through search engine optimization (SEO) poisoning. The campaign redirects users searching for legitimate enterprise software to malicious ZIP files on attacker-controlled websites to deploy digitally signed trojans that masquerade as trusted VPN clients while harvesting VPN credentials. Microsoft Threat Intelligence attributes this activity to the cybercriminal threat actor Storm-2561.

Active since May 2025, Storm-2561 is known for distributing malware through SEO poisoning and impersonating popular software vendors. The techniques they used in this campaign highlight how threat actors continue to exploit trusted platforms and software branding to avoid user suspicion and steal sensitive information. By targeting users who are actively searching for enterprise VPN software, attackers take advantage of both user urgency and implicit trust in search engine rankings. The malicious ZIP files that contain fake installer files are hosted on GitHub repositories, which have since been taken down. Additionally, the trojans are digitally signed by a legitimate certificate that has since been revoked.

In this blog, we share our in-depth analysis of the tactics, techniques, and procedures (TTPs) and indicators of compromise in this Storm-2561 campaign, highlighting the social engineering techniques that the threat actor used to improve perceived legitimacy, avoid suspicion, and evade detection. We also share protection and mitigation recommendations, as well as Microsoft Defender detection and hunting guidance.

From search to stolen credentials: Storm-2561 attack chain

In this campaign, users searching for legitimate VPN software are redirected from search results to spoofed websites that closely mimic trusted VPN products but instead deploy malware designed to harvest credentials and VPN data. When users click to download the software, they are redirected to a malicious GitHub repository (no longer available) that hosts the fake VPN client for direct download.

The GitHub repo hosts a ZIP file containing a Microsoft Windows Installer (MSI) installer file that mimics a legitimate VPN software and side-loads malicious dynamic link library (DLL) files during installation. The fake VPN software enables credential collection and exfiltration while appearing like a benign VPN client application.

This campaign exhibits characteristics consistent with financially motivated cybercrime operations employed by Storm-2561. The malicious components are digitally signed by “Taiyuan Lihua Near Information Technology Co., Ltd.”

Initial access and execution

The initial access vector relies on abusing SEO to push malicious websites to the top of search results for queries such as “Pulse VPN download” or “Pulse Secure client,” but Microsoft has observed spoofing of various VPN software brands and has observed the GitHub link at the following two domains: vpn-fortinet[.]com and ivanti-vpn[.]org.

Once the user lands on the malicious website and clicks to download the software, the malware is delivered through a ZIP download hosted at hxxps[:]//github[.]com/latestver/vpn/releases/download/vpn-client2/VPN-CLIENT.zip. At the time of this report, this repository is no longer active.

When the user launches the malicious MSI masquerading as a legitimate Pulse Secure VPN installer embedded within the downloaded ZIP file, the MSI file installs Pulse.exe along with malicious DLL files to a directory structure that closely resembles a real Pulse Secure installation path: %CommonFiles%\Pulse Secure. This installation path blends in with legitimate VPN software to appear trustworthy and avoid raising user suspicion.

Alongside the primary application, the installer drops malicious DLLs, dwmapi.dll and inspector.dll, into the Pulse Secure directory. The dwmapi.dll file is an in-memory loader that drops and launches an embedded shellcode payload that loads and launches the inspector.dll file, a variant of the infostealer Hyrax. The Hyrax infostealer extracts URI and VPN sign-in credentials before exfiltrating them to attacker-controlled command-and-control (C2) infrastructure.

Code signing abuse

The MSI file and the malicious DLLs are signed with a valid digital certificate, which is now revoked, from Taiyuan Lihua Near Information Technology Co., Ltd. This abuse of code signing serves multiple purposes:

• Bypasses default Windows security warnings for unsigned code
• Might bypass application whitelisting policies that trust signed binaries
• Reduces security tool alerts focused on unsigned malware
• Provides false legitimacy to the installation process

Microsoft identified several other files signed with the same certificates. These files also masqueraded as VPN software. These IOCs are included in the below.

Credential theft

The fake VPN client presents a graphical user interface that closely mimics the legitimate VPN client, prompting the user to enter their credentials. Rather than establishing a VPN connection, the application captures the credentials entered and exfiltrates them to attacker-controlled C2 infrastructure (194.76.226[.]93:8080). This approach relies on visual deception and immediate user interaction, allowing attackers to harvest credentials as soon as the target attempts to sign in. The credential theft operation follows the below structured sequence:

• UI presentation: A fake VPN sign-in dialog is displayed to the user, closely resembling the legitimate Pulse Secure client.
• Error display: After credentials are submitted, a fake error message is shown to the user.
• Redirection: The user is instructed to download and install the legitimate Pulse Secure VPN client.
• Access to stored VPN data: The inspector.dll component accesses stored VPN configuration data from C:\ProgramData\Pulse Secure\ConnectionStore\connectionstore.dat.
• Data exfiltration: Stolen credentials and VPN configuration data are transmitted to attacker-controlled infrastructure.

Persistence

To maintain access, the MSI malware establishes persistence during installation through the Windows RunOnce registry key, adding the Pulse.exe malware to run when the device reboots.

Defense evasion

One of the most sophisticated aspects of this campaign is the post-credential theft redirection strategy. After successfully capturing user credentials, the malicious application conducts the following actions:

• Displays a convincing error message indicating installation failure
• Provides instructions to download the legitimate Pulse VPN client from official sources
• In certain instances, opens the user’s browser to the legitimate VPN website

If users successfully install and use legitimate VPN software afterward, and the VPN connection works as expected, there are no indications of compromise to the end user. Users are likely to attribute the initial installation failure to technical issues, not malware.

Defending against credential theft campaigns

Microsoft 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 huge majority of new and unknown variants. 
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. 
• Enable network protection in Microsoft Defender for Endpoint. 
• Turn on web protection in Microsoft Defender for Endpoint. 
• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware. 
• Enforce multifactor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times. 
• Remind employees that enterprise or workplace credentials should not be stored in browsers or password vaults secured with personal credentials. Organizations can turn off password syncing in browser on managed devices using Group Policy. 
• Turn on the following attack surface reduction rule to block or audit activity associated with this threat:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 

Microsoft Defender detection and hunting guidance

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Microsoft 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 threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor Profile: Storm-2561
• Activity Profile: Storm-2561 uses SEO poisoning to distribute fake VPN clients for credential theft

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Files signed by Taiyuan Lihua Near Information Technology Co., Ltd.

Look for files signed with Taiyuan Lihua Near Information Technology Co., Ltd. signer.

let a = DeviceFileCertificateInfo
| where Signer == "Taiyuan Lihua Near Information Technology Co., Ltd."
| distinct SHA1;
DeviceProcessEvents
| where SHA1 in(a)

Identify suspicious DLLs in Pulse Secure folder

Identify launching of malicious DLL files in folders masquerading as Pulse Secure.

DeviceImageLoadEvents
| where FolderPath contains "Pulse Secure" and FolderPath contains "Program Files" and (FolderPath contains "\\JUNS\\" or FolderPath contains "\\JAMUI\\")
| where FileName has_any("inspector.dll","dwmapi.dll")

Indicators of compromise