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.

Microsoft Security Research has identified malicious cloud activity associated with JADEPUFFER, a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation. Our investigation found an extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration.

These findings expand the publicly documented activity associated with JADEPUFFER, tracked by Microsoft as Storm-3168, demonstrating an evolution in the threat actor’s cloud operations and providing the first detailed view into its Azure activity. We identified bulk destructive operations in a compromised Azure environment. The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections. Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.

This activity highlights a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale. As these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments. Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI.

Attack overview

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The other performed discovery, destructive operations, and credential collection.

Discovery before destruction

For the impacted tenant, in early June 2026, one of the compromised service principals enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes with 300+ successful read operations. This breadth of activity would give the threat actor visibility across the organization’s Azure environment.

About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.

16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.

70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.

A seven-minute destructive sequence

Less than one second after the unsuccessful ListKey operation against a non-existent storage account, the second compromised service principal began with its destructive activities. This compromised service principal then attempted 150+ destructive or credential collection related operations in 35 minutes.

The destructive sequence lasted for about 7 minutes. This involved 100+ storage account deletion attempts. Most Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. An Azure Key Vault, Function App, App service plan were also deleted, all of which belonged to the same resource group and appeared to support the Function app.

The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type.

Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.

Credential collection

About 30 minutes after the final destructive activity, the same service principal made an inventory request for Azure Storage Accounts and sent 30+ successful ListKeys requests, asking ARM to return each storage account’s access keys. These storage accounts included Azure Site Recovery related storage accounts.

Technical analysis

Possible initial access

• Credential exposure: While it is unclear how the service principal was initially compromised, its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated. We could not confirm whether this secret was used for the activity described here.
• Application Probing: Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers, against sensitive paths related to WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code) and other web-shell like paths. However, the App Service targets did not overlap with the affected Azure subscriptions, and we found no App Service to ARM (Azure Resource Manager) credential path for the impacted tenant.

Coordinated automation

The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.

We observed five unique tokens issued for the service principal used for destruction and credential collection – four tokens supported deletion, while the fifth token handled storage inventory and key retrieval. Two of the tokens used for deletion were active during the same 70 second period. While one of these tokens focused on Storage account deletion, the other focused on a mixture of Storage and SQL deletion.

While the Key Vault, Function App, and App Service plan associated with the same application were deleted, a similarly named storage account in the same resource group was spared and later targeted by the compromised service principal through a successful ListKeys operation.

The operations followed the identity’s existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions and the one additional successful key retrieval. Direct SQL DB Contributor access authorized the multiple SQL deletion attempts, which were ultimately unsuccessful because of the unsupported API version used for the Azure SQL Database resource type.

Destructive activity indicative of a ransomware-aligned objective

The threat actor deleted numerous Azure resources, while also targeting backup and recovery related resources such as Azure Site Recovery locks or Azure Storage Accounts which had terraform and backup themed names, potentially intending to impair the victim’s ability to recover from the destructive activity.

The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type. Although the database deletions were unsuccessful, their inclusion in the same destructive sequence provides additional insight into the intended scope of the activity.

The compromised service principal also made multiple attempts to retrieve storage account keys, which could provide access to sensitive data.

Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations.

However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the risk and impact of activity similar to that observed in this campaign:

• Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview.
• Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation.
• Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud.
• Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC.
• Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices.
• Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed.
• Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths.

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 cloud 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 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
• Microsoft User analysis
• 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 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.

• Microsoft Defender XDR Threat Analytics report on Storm-3168

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

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

• T1190 Exploit Public-Facing Application | Storm-3168 linked infrastructure repeatedly probed sensitive application paths on applications hosted in Azure App Service for potential exploitation.
• T1078.004 Valid Accounts: Cloud Accounts | Compromised service principals were used for Azure resource discovery and destruction.
• T1526 Cloud Service Discovery | The identities enumerated subscriptions, virtual machines, resource groups, Azure Storage, Web Apps, App Service plans, locks, and Recovery Services.
• T1485 Data Destruction | Azure Storage, Key Vault, Function App, and App Service plan resources were deleted. Azure SQL deletion was also attempted, extending the destructive objective toward databases.
• T1490 Inhibit System Recovery | Site Recovery disk locks and an Azure Backup protection lock were targeted for deletion

Indicators of compromise (IOC)

References

• JADEPUFFER: Agentic ransomware for automated database extortion by Sysdig

Learn More

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

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

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

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Storm-3168: Agentic-driven cloud attacks using compromised service principals 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.

AI agents are now running on employee devices, cloud platforms, and across developer workflows. Security teams need to see those agents, govern what they can reach, and contain them when something goes wrong. This month’s updates help you discover and control local AI agents, extend Zero Trust to agent traffic, and strengthen the security operations center (SOC) foundations that AI-era operations depend on.

Here’s what’s new:

Extend protection and support investigations with Microsoft Defender

Bring more context into email investigation and hunting with Microsoft Security Copilot

Available for organizations using both Microsoft Defender and Microsoft Security Copilot, a new email detonation summary delivers AI-generated explanations of URL and file sandboxing results, helping SOC teams investigate faster by reducing the manual effort required to correlate detonation evidence and contextual signals.

Protect sensitive data in motion with Microsoft Purview and Microsoft Entra

Stop sensitive data from reaching shadow AI over the network

Now generally available, Microsoft Purview and Microsoft Entra Global Secure Access bring data security to the network across human actions and on-behalf-of (OBO) agentic traffic. Context-aware Microsoft Purview classification and policies are enforced by Entra at the network layer. Organizations can discover sensitive files and text in real time and block them from being shared to risky destinations. For example, if an employee or OBO agent tries to upload a sensitive document to an unsanctioned AI tool, the policy can stop the transfer before the data leaves.

Protect, investigate, and clean up enterprise data with Microsoft Purview

Manage labeling at enterprise scale with less administrative overhead

Microsoft Purview auto-labeling helps organizations automatically apply data security controls to sensitive content at enterprise scale. New auto-labeling enhancements improve policy scale, admin experience, and reporting. Policies now support simulations of up to 20 million items and up to 50,000 sites through adaptive scopes. Administrators can edit a policy without re-running simulation. New audit insights and reporting show policy coverage and processing activity. Together, these enhancements help organizations scale auto-labeling across larger environments with less administrative effort.

Investigate content created in Copilot apps such as Microsoft Loop, Copilot pages through established compliance processes

Microsoft Purview eDiscovery now supports search, hold, review, and export content in user-owned SharePoint embedded containers, to help streamline eDiscovery processes for legal, regulatory, and internal investigations. Investigators can find content from AI-powered experiences, including Microsoft Loop, Copilot Pages, Copilot Notebooks, and applications, such as Outlook newsletters, mapped to a user without requesting the container URL from a SharePoint administrator. An optional HTML conversion produces a more readable version for downstream legal tools, improving the review and export experience for experts.

Archive and permanently remove inactive content to improve AI readiness

With Microsoft Purview Data Lifecycle Management, administrators can now archive inactive SharePoint content without archiving the entire site. Archived content remains subject to retention and legal hold policies, and remains discoverable for eDiscovery, while dropping out of Microsoft 365 Copilot indexing (until reactivated). Organizations can also use Priority Cleanup to permanently delete approved content, including stale Teams recordings and transcripts, so it is no longer discoverable in eDiscovery, SharePoint search, or Microsoft 365 Copilot. Together, these capabilities help organizations meet compliance regulations, including those in highly regulated industries.

Advanced endpoint management extends to GCC High and DoD with Microsoft Intune

Bring modern endpoint management to regulated environments

Microsoft Intune Enterprise Application Management, Microsoft Cloud PKI, and Intune Remote Help are coming to Government Community Cloud with High security needs (GCC High), with Enterprise Application Management also being offered to organizations of the Department of Defense (DoD). These capabilities help government and defense organizations simplify application management, modernize certificate lifecycle management, resolve device issues faster, and reduce total cost of ownership, all while operating within their accredited cloud environment.

Stay in the Loop

Microsoft Security continually ships meaningful innovations across our portfolio, as well as research-driven insights and reports for the security community. In the Loop posts are your reliable source of what’s new across Microsoft Security and what it means for your security strategy. Check back for the next drop.

And join us at Microsoft Ignite, from November 17 to 20, 2026, in San Francisco or online, to see Microsoft Security innovations in action and go hands-on with the team that built it.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post ​​​​​​​​What’s new in Microsoft Security: September 2026​​ appeared first on Microsoft Security Blog.

The physics of cybersecurity are changing. So must the security operations center (SOC).

Cyberattackers are using agents to automate execution at unprecedented scale. What once required entire teams now requires a single operator and an agent framework.

That shift has exposed a hard truth: security cannot operate at AI speed when protection and operations are built as separate systems. Every handoff, integration, and boundary slows defenders down. Agents inherit that complexity.

For agentic security to work, the industry needs a different model. It needs a modern cyber stack with the breadth to see across the environment and the depth to investigate and act. Security operations and native protection must function as one system. This is the integrated security operations center (ISOC).

Today we are announcing ISOC in Microsoft Defender: a foundation built for agentic security that brings leading solutions for security information and event management (SIEM) and threat protection together. It gives people and agents a shared foundation to see, understand, and act across the environment, without the complexity of operating separate systems.

Built for agentic security

In July 2026, we introduced the end-to-end cyber stack alongside Project Perception, with the focus of delivering the right models, a harness, and specialized agents to help defenders perceive, reason, and act at machine speed. But we are innovating at every layer of the stack, because intelligence and orchestration alone are not enough. Agents depend on the rest of the stack working as one.

They need signals and sensors that provide visibility, context that turns those signals into understanding, and actuators that translate decisions into protection. With ISOC, these layers work in unison, so agents can move beyond isolated tasks and help operate an agentic SOC.

Signals and sensors give the system awareness.

Context turns those signals into understanding.

Actuators turn insights into protective action.

ISOC brings these capabilities together as a foundation, so humans and agents can operate as one system, each contributing what they do best. Agents provide the speed and scale to execute continuously, while people set priorities, apply judgment, and define the outcomes that matter. Together, they empower defenders to keep pace with AI-powered threat actors and achieve better security outcomes.

Integrated protection loop

With ISOC enabling signals, context, and controls to work as one, it breaks the pattern of linear security workflows. The result is an integrated protection loop that continuously turns what defenders learn into stronger pre-breach protection.

Attack disruption in Microsoft Defender shows what this makes possible. Rich telemetry and controls enable the system to detect, predict, and adapt to an attacker while the attack is still unfolding. It disrupts threats in progress and anticipates where attackers may move next. It’s a protection loop that uses exposure insights to strengthen protection in near real-time with threat intelligence focusing the loop on the threats that matter most.

ISOC brings together the capabilities needed to make this loop native, eliminating the burden of assembling, tuning, and maintaining it yourself. And as protection advances, new capabilities can become part of that loop. The result is stronger protection and a different way of working, where practitioners spend less time chasing individual signals and more time applying judgment, setting priorities, and driving security outcomes.

Designed for the practitioner

For too long, practitioners have had to compensate for the boundaries in their security architecture, stitching together signals, rebuilding context, and moving between tools just to get the information and controls needed to act.

ISOC changes their starting point. The capabilities practitioners need to investigate, hunt, automate, manage incidents, understand threats, and take action are brought together and available by default. Instead of organizing their work around the boundaries between tools, teams can organize around the security outcome they are trying to achieve.

And that foundation gets more powerful as autonomy grows. The integrated protection loop can take on more of the continuous work of detecting and defending against threats, while agents help practitioners investigate, reason, and act using the same context and controls already available to them.

There’s no separate agentic layer to assemble or new operating model to stitch together. Practitioners can multiply their expertise where they already work, shifting more of their time from operating the security stack to directing the defense.

The path forward

Security has always been a race between attackers and defenders. AI changes the speed, scale, and economics of that race. The next SOC will not be defined by how many AI features it has, but by whether people and agents can perceive, reason, and act across an environment as one system.

Integrated security operations center (ISOC) in Microsoft Defender is available in preview today. Watch a recording of the full announcement or download the whitepaper: Agentic SOC: The new operating model for continuous defense.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Reimagining the SOC for the agentic era in Microsoft Defender 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.

AI has already made fundamental changes to the operating environment for cybersecurity. Cyberattackers are testing more paths, adapting their techniques, and moving across digital environments with greater speed and persistence. The weaknesses they exploit remain familiar: excessive permissions, unprotected authentication flows, unpatched systems, exposed execution paths, and gaps between controls. What has changed is how quickly these weaknesses can combine into attack paths that cross identities, endpoints, applications, networks, and AI systems. A single foothold can become a broader compromise, making it increasingly difficult for security teams to determine which risks matter most and where to act first as their organizations adopt AI.

We introduced Secure Now within Microsoft Security Exposure Management in May 2026 to help practitioners prioritize the action they need to take to be prepared for this shift. It provides actionable guidance for strengthening the foundational security needed for AI adoption, with recommendations focused on areas where autonomous attacks can create outsized exposure.

We continue to see evidence that AI is reshaping the threat landscape. These developments reinforce many of the foundational practices we use internally to secure Microsoft, while also expanding our understanding of where organizations need additional visibility, governance, and control. The examples in this blog illustrate how familiar weaknesses are evolving in the AI era and why continuous exposure reduction remains essential.

When AI agents test their boundaries

Recent frontier model-related agentic security disclosures offered early lessons in how autonomous agents may test the boundaries of their instructions and environments.

In an incident disclosed by OpenAI, agents moved beyond their intended isolation, exploited vulnerabilities in shared Hugging Face infrastructure, and reached production systems. In separate incidents disclosed by Anthropic, agents exploited familiar weaknesses, including SQL injection, exposed credentials, weak passwords, and a malicious PyPI package.

Our customers are asking us how they can reduce this risk by governing agent identities and tools, isolating execution, restricting outbound connectivity, monitoring behavior, and defending against increasingly autonomous external cyberthreats, so that an unexpected agent action or exposed weakness do not become a path across the enterprise.

Explore recommended controls for this attack path.

When trusted paths cross attack surfaces

Microsoft Threat Intelligence recently observed Storm-2945, a subcluster of Midnight Blizzard, manipulating DNS and HTTP traffic across hospitality networks in the CaptiveCrunch campaign. Travelers were redirected into two attack paths: device-code phishing through a legitimate Microsoft sign-in page, or fake software updates that delivered malware.

One network interaction could therefore become either cloud identity access or endpoint compromise. The malware could collect multiple categories of host intelligence, including credentials, session tokens, security configurations, and remote-access history.

Identity remains a leading attack surface, and protecting it requires securing the authentication flow as well as the credential. Security leaders can expand phishing-resistant authentication, block device-code flow where it is unnecessary, and constrain legitimate use through Conditional Access and sign-in risk policies. Endpoint protections can disrupt the parallel malware path.

Explore recommended controls for this attack path.

When cyberattackers exploit everyday operations

A third campaign began with attackers impersonating IT support through Microsoft Teams. After persuading a user to grant control through legitimate remote-support software, they used PowerShell to download a malicious Windows Installer (MSI) package, stage a portable Node.js runtime, and establish persistent command-and-control. From that endpoint, the operator mapped Active Directory and attempted to use WinRM to reach dozens of systems, including domain controllers and certificate authorities.

Each step relied on technology common in enterprise environments—a Teams conversation, remote-support software, Windows Installer, a legitimate runtime, and a native administrative protocol—enabling the cyberattacker to move laterally while blending with expected operations.

Security leaders can disrupt that path with phishing-resistant access controls, managed-device requirements, endpoint attack surface-reduction rules, and tighter restrictions on remote-support tools and WinRM.

Explore recommended controls for this attack path.

Security fundamentals work together

Cyberattackers are moving laterally across surfaces, and security fundamentals matter most at the intersections between them. Through the Secure Future Initiative, Microsoft is operationalizing security as a continuous discipline and applying and sharing lessons from strengthening our own environment. Guided by Zero Trust principles—verify explicitly, use least privilege, and assume breach—we will continue to make high-impact protections easier to adopt and enabled by default where appropriate.

Governed identities, well-defined permissions, protected data, and visibility into AI systems and agents provide resilience as organizations accelerate AI adoption. They also give AI-powered security the context and trusted mechanisms needed to help defenders prioritize risk and act faster. Strengthening these foundations reduces exposure today while preparing organizations for what comes next.

On Secure Now—within Microsoft Security Exposure Management—security leaders can now find information on recent threats paired with focused initiatives across security domains. This brings together guidance on recommended controls and enables customers to take relevant actions to continuously strengthen your posture.

Visit Secure Now to understand recent threats, identify areas of focus, and take action.

Learn more

Learn more about Microsoft Security Exposure Management.

FastTrack provides eligible customers with access to technical specialists as an included benefit at no additional cost to help strengthen foundational security controls, reduce exposure to cyberthreats, and prepare for broader AI adoption. Get started now.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post From guidance to action: Security fundamentals that materially reduce risk  appeared first on Microsoft Security Blog.

Every benchmark tells a story. The most valuable ones tell us where to improve next.

For five consecutive quarters Microsoft has published email security benchmarking reports to provide greater transparency into real-world protection outcomes. The results have shown strong Microsoft Defender performance across pre-delivery and post-delivery scenarios, while revealing where threats and defenses continue to evolve.

This quarter’s benchmark examines how continuous measurement informs protection across prevention, detection, and adaptation, and how those insights are helping improve customer outcomes.

Key takeaways

• Defender again missed the fewest high-severity threats among the solutions evaluated, about 55% fewer than the next-closest secure email gateway (SEG) vendor.
• Layered security adds the most value in promotional and bulk filtering and works; gains for spam and malicious email remain comparatively modest.

Benchmarking results for SEG vendors

In the latest quarterly SEG comparison from May 2026 through July 2026, Defender missed 221 high-severity threats per 1,000 protected users, 55.4% fewer than the next-closest SEG vendor. The benchmark measures missed threats instead of the total number of malicious emails that were caught and filtered, because catch totals can reflect differences in threat volume and exposure across vendor environments. By normalizing missed threats per 1,000 users we are able to provide a more consistent side-by-side comparison.

If you’ve read our previous blogs, you’ll see that missed threats have increased across multiple reporting periods, including for Microsoft. This aligns with broader trends we’re seeing as AI makes it easier for cyberattackers to gather public information, tailor messages, and create more convincing impersonation attempts. It reinforces the need for protection that continuously adapts.

Benchmarking results for ICES vendors

Effective email detection combines pre-delivery filtering with post-delivery detection and remediation. This benchmark helps customers evaluate where each layer contributes measurable value.

Similarly to previous quarters, integrated cloud email security (ICES) solutions continue adding the most value in promotional and bulk filtering. We saw an improvement in ICES vendor malicious catch at 0.30% versus 0.13% in the last quarter and spam catch going up to 0.52% versus 0.28% compared to last quarter.

Defender caught 92% of post-delivery malicious messages on average during the benchmark period, highlighting how the combination of pre-delivery and post-delivery remediation delivers strong results for customers.

At the same time it’s key to understand that Defender doesn’t treat post-delivery remediation as a point-in-time action after the email was first delivered to the inbox. Even after a message reaches the inbox, new threat intelligence can reveal risks that were not apparent at the time of delivery. Defender continuously reevaluates delivered messages and remediates threats as new indicators, campaign intelligence, and threat signals emerge.

How our benchmarking is helping shape product innovation

The value of benchmarking is what happens after measurement. Insights from customer feedback, threat telemetry, and benchmarking have informed recent Microsoft Defender investments:

• More control over promotional mail: Across multiple benchmarking periods, we observed that ICES solutions often delivered the greatest incremental benefit in filtering promotional and bulk email. The new Promotions folder in Outlook builds on these insights by helping users reduce inbox clutter while keeping legitimate marketing and bulk messages accessible.
• Redesigned machine learning and AI model stack: By analyzing and incorporating natural language processing signals, including message topic, alongside other AI detection signals, Defender can improve detection accuracy. During a consecutive four-week period, Microsoft research observed a roughly two-thirds reduction in false negatives and a nearly one-fifth reduction in false positives for Defender customers.
• Protection for people and AI: We built prompt injection protection to detect and isolate malicious AI instructions in email before delivery—helping protect not only people, but also Copilot, agents, and other AI systems that read and act on inbox content. This innovation demonstrates how we continue evolving our defenses to address the latest cyberattack techniques and stay ahead of emerging threats.

Looking ahead

Since July 2025, our goal has been to bring greater transparency to email security effectiveness. Today, we are using benchmarking to help customers understand how cyberthreats evolve, where defenses add value, and how protection improves over time.

Benchmarking is not simply about demonstrating effectiveness, it is about learning from real-world outcomes and translating those insights into stronger protection. As cyberattackers continue to innovate, we remain committed to sharing evidence, improving our technology, and helping customers stay ahead of emerging cyberthreats.

To explore the latest benchmarking data and learn more about how Defender and ICES partners work together, access the benchmarking site.

Learn more

Learn more about Microsoft Defender.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Improving email security outcomes with real-world Microsoft Defender insights appeared first on Microsoft Security Blog.

Threat actors are increasingly improving their tactics to make suspicious emails look like legitimate email notifications to potential victims, deploying techniques that impersonate internally sent emails from executive team members. While this technique is not new, the adoption of AI has enabled threat actors to improve their campaign templates and construct emails tailored to their recipients. Additionally, threat actors are incorporating multiple techniques within the same email to improve the overall narrative further.

In this blog, we will discuss a recent campaign observed using third-party email delivery infrastructure to send out over a million financial fraud scam emails that displayed multiple indicators consistent with the use of generative AI during email template creation. The threat actor impersonated CEOs of multiple target companies, attempting to convince accounts payable departments of the same companies to process an Automated Clearing House (ACH) payment of nearly $50,000. To add legitimacy, the actor included a forwarded email thread (and a fabricated invoice) between the impersonated CEO and ServiceNow (which was also being impersonated).

Attack chain overview

The campaign follows steps before and during the execution of the campaign: threat actors register impersonation domains, send executive-themed payment requests through trusted infrastructure, embed fabricated invoices and supporting conversations, and attempt to convince finance personnel to initiate ACH transfers.

Email Delivery

Between August 3 and 5, Microsoft detected a campaign consisting of more than a million emails targeting enterprise users. The attacker used multiple third-party email service accounts to send out the emails. A huge majority of these emails were sent to users in the United States (87.7% of the total campaign).

Unlike traditional invoice scams that rely on a single social engineering lure, this campaign layered executive impersonation, vendor branding, fabricated invoices, and supporting email conversations into a unified narrative intended to reduce recipient skepticism.

The threat actor impersonated executive team members (such as a CEO, CFO, President) of multiple targeted companies, attempting to convince accounts payable departments of the same companies to process an ACH payment of nearly $50,000. More specifically, the CEOs were impersonated in multiple places in the email such as in the sender display name, reply-to display name, and in the email signature. Email bodies contained a simple and direct “approval” of the “invoice below” as well as urged users to request a PDF version if they need it. Additionally, as mentioned earlier, the email signature contained certain details about the spoofed CEO such as name and email address.

Important note: Throughout this campaign, threat actors impersonated legitimate organizations using attacker-controlled infrastructure, fabricated communications, and lookalike domains. Microsoft found no evidence that the legitimate organizations referenced in the lures, including ServiceNow, were compromised or involved in the activity. Rather, the campaign relied on fraudulent domains and content designed to mimic trusted brands and individuals.

The threat actor did not stop there. To add further legitimacy, directly below the CEO signature, the actor included “forwarded” content , specifically a professional looking but fabricated “ServiceNow Platform — Annual Subscription” invoice. The extremely detailed invoice contains various ServiceNow branding and logos. It has basic invoice details such as invoice number, issue and due dates, currency, amount due, payment method, and itemized line items. The payment method instructed is a bank transfer to accounts controlled by the threat actor. Microsoft observed the use of multiple financial institutions across samples, indicating that payment destinations may vary between targets. Certain parts of the invoice are personalized to the recipient. Specifically, the “BILLED TO” section has the recipient company name and executive name.

The invoice shown below is a threat actor-created impersonation and was not issued by ServiceNow.

Finally, directly below the fake invoice, two more “forwarded” emails are included which are essentially a short conversation between the two spoofed executives (the targeted company executive, and ServiceNow President). The two executives are seen discussing the ServiceNow purchase, implementation and handling of the invoice.

From a defender point of view there are several indicators within the email indicating that the email and the “forwarded” thread are not genuine.

• “From” headers from the spoofed thread lack any data headers like actual forwarded emails.

• Suspicious language used in the spoofed thread such as “no need to copy me”.
• Suspicious language in headers i.e display name not matching sender address, subjects using financial lure keywords like ‘due bill’, ‘ACH Parment’ etc.
• Despite the sophistication of the generated content, several inconsistencies remained visible to defenders
• In real email threads, the previous threads are normally tabbed or otherwise visually grouped, while the previous threads in this example were left aligned.
• An additional inconsistency was observed where the targeted company’s CEO requested the recipient to send the invoice directly to victims and not CC the sender. However, in the most recent thread, the CEO stated that the invoice is approved and the invoice is sent from his address.

Domain registration

Before initiating the campaign, the threat actor registered several domains. A ‘ServiceNow’ lookalike domain service-nowinc[.]com was registered on July 31, shortly before the campaign activity was observed. This domain was used for the spoofed email address of ServiceNow President. It was also used in several places in the fabricated invoice such as in the contact email in case of any questions. The actor also registered another domain on the same day. The domain domainlify[.]net was used in the Reply-To email.

Generative AI usage

Microsoft observed several indicators consistent with AI-assisted template development. These included extensive HTML comments, structured section labeling, and highly uniform template construction. While these indicators suggest generative AI involvement, they do not independently establish the extent to which AI generated campaign content.

Examples:

Additionally, the use of ‘em dash’ (“—”) and banner ‘===========’ have also become other indicators associated with AI usage.

One possible indication of template-based generation is that invoice identifiers and narrative structure remained largely consistent across samples while organization-specific details changed between targets.

Mitigation and protection guidance

Microsoft provides layered protection against this type of executive-impersonation and invoice-fraud campaign. Properly configured email authentication, spoof protection, mail-flow connectors, and Microsoft Defender for Office 365 help identify and block suspicious messages before delivery; messages later determined to be malicious can be quarantined or removed through post-delivery remediation, including Zero-hour Auto Purge. Security teams can then use Microsoft Defender XDR and Security Copilot to investigate related alerts, affected users, and campaign indicators, coordinate response, and take remediation actions.

Together, these capabilities help reduce the likelihood that fraudulent payment requests reach finance personnel and support faster containment if a message is delivered.

To defend against social engineering campaigns involving executive impersonation, invoice fraud, and potentially AI-assisted content development, Microsoft recommends the following mitigations:

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.

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.

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.

These links provide information on how to properly configure mail flow with connectors:

• Manage mail flow using a third-party cloud service with Exchange Online
• Configure mail flow using connectors in Exchange Online
• Mail flow rules (transport rules) in Exchange Online
• Enhanced filtering for connectors in Exchange Online

These links provide information on configuring SPF, DKIM, and DMARC:

• Email authentication in cloud organizations
• Set up SPF to identify valid email sources for your custom cloud domains
• Set up DKIM to sign mail from your cloud domain

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.

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
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

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

Threat intelligence reports

Microsoft Defender XDR customers can use 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 the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

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

T1591 – Gather Victim Organization Information
Threat actors collect publicly available information about target organizations, executives, finance personnel, vendors, and business relationships to build convincing invoice-fraud narratives.

T1598 – Phishing for Information
Information gathered from victims and public sources is used to craft highly targeted business email compromise (BEC) lures.

Resource Development

T1583.001 – Acquire Infrastructure: Domains
Threat actors register domains that impersonate trusted organizations, vendors, or business partners.

T1585.002 – Establish Accounts: Email Accounts
Attacker-controlled email accounts are created to support impersonation and fraudulent communications.

T1583 – Acquire Infrastructure
Third-party email delivery infrastructure and supporting services are leveraged to distribute campaigns.

Initial Access

T1566 – Phishing
Targeted phishing emails are delivered to finance personnel using executive and vendor impersonation themes.

T1566.001 – Spearphishing Attachment
Fraudulent invoices or supporting documents are attached to phishing emails.

T1566.003 – Spearphishing via Service
Third-party email services are used to distribute phishing messages and improve legitimacy.

Defense evasion

T1036 – Masquerading
Attackers disguise emails, domains, invoices, and business correspondence as legitimate communications.

T1656 – Impersonation
Executives, vendors, and trusted business entities are impersonated to establish credibility and influence payment decisions.

Impact

T1657 – Financial Theft
Victims are deceived into transferring funds to attacker-controlled financial accounts through fraudulent invoice payment requests.

Indicators of compromise (IOC)

Learn More

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

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

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

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

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

• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.

The post Protecting organizations from AI-assisted executive impersonation and invoice fraud appeared first on Microsoft Security Blog.

Every wave of technology excitement creates a new opportunity for cyberattackers, and AI is no exception. Microsoft Threat Intelligence has published research showing a growing set of campaigns that impersonate popular AI platforms and tools, including ChatGPT, Microsoft Copilot, DeepSeek, and Claude.¹ The goal is to make phishing, search-driven malware campaigns, and malvertising—which is malicious advertising that uses online ads to lure users to harmful sites, downloads, or redirect chains—more convincing. A ChatGPT-themed phishing campaign sent up to 100,000 emails in a single day, tricking users into updating their ChatGPT Plus payment information and stealing personal and credit card data. These campaigns do not represent a compromise of the AI services being referenced. They represent something more familiar—cyberattackers doing what they have always done: borrowing trust. Right now, AI brands can carry significant trust and curiosity, making them attractive themes for cyberattackers to exploit.

Understanding why this trend matters and what it means for security teams is critical to shaping a modern protection strategy. The tactics are the same ones cyberattackers have always refined: urgency, curiosity, and impersonation of something familiar to lower a user’s guard. What has changed is the wrapper. A message about a new model release, a policy update from a familiar AI assistant, or a plugin that promises to make the workday easier is today’s version of the fake invoice or the shipping notification. AI-themed lures deserve attention not because they are a passing trend tied to one product cycle, but because AI remains a genuine source of excitement and urgency for employees and consumers alike, and cyberattackers are exploiting the human instinct to explore what is new, useful, or urgent.

The attack pattern is evolving

Microsoft’s research team recently observed several AI brand campaigns including:

• A ChatGPT-themed phishing kit built to harvest credit card data.
• A Claude-themed campaign that harvested credentials and access tokens through adversary-in-the-middle (AiTM) techniques.
• Malvertising for a fake AI Windows plugin that delivered the Vidar stealer.
• Fraudulent DeepSeek installers distributed through GitHub.

In one case, an initial access broker tracked as Storm-3075 used AI-themed malvertising to distribute payloads for multiple downstream actors, a sign of how quickly this tactic is being commoditized across the criminal ecosystem.

What ties these campaigns together is not sophistication in the traditional sense. It is patience and precision in exploiting a moment. Threat actors are capitalizing on anticipated launches and emerging trends, layering multi-stage redirection chains and disposable infrastructure to slip past both users and defenses. That has real implications for security leaders: it means these incidents cannot be evaluated one surface at a time. A single AI-themed lure can begin as an email, become a malicious link, trigger a suspicious download, and end as an identity or endpoint compromise. Organizations that assess each of those as an isolated event are always a step behind. Organizations that connect them see the full shape of the cyberattack, often early enough to stop it.

Turning AI lures into dead ends with Microsoft Defender

In practice, protection starts before the user ever engages with the lure. Microsoft Defender’s anti-phishing policies can help detect spoofing and impersonation attempts, including user and domain impersonation, first-contact messages, mailbox intelligence signals, and other suspicious sender characteristics. For an AI-themed lure, that might look like a fake “Copilot policy update,” a spoofed support notice, or a lookalike domain designed to make a credential collection page feel legitimate.

If the campaign relies on links, Defender’s Safe Links provides URL scanning and detonation during mail flow, plus time-of-click verification when a user selects a link in email, Microsoft Teams, or supported Microsoft 365 apps. That is important when cyberattackers use redirect chains, delayed activation, or links that appear benign at delivery but later resolve to phishing infrastructure, fake sign-in pages, or malicious downloads.

For campaigns that use fake installers, malicious downloads, or weaponized attachments, Safe Attachments adds another layer by detonating attachments in a virtual environment before delivery when policies are configured. For example, if a message promotes a “new AI plugin” but includes a harmful attachment, Safe Attachments can analyze the file for malware, ransomware, or phishing behavior before it reaches the user. If a cyberthreat is identified after delivery, Defender’s post-delivery filtering capabilities help remove malicious content from mailboxes and reduce the window of exposure.

Protect against multi-stage attacks with attack disruption

But AI-powered attacks don’t stop at email. Their objective is to gain the highest level of access possible, using compromised accounts as a foothold to move across identities, devices, and data. When a cyberattack moves beyond the inbox, Defender helps connect the evidence. Signals from email and collaboration tools, endpoints, identities, and software as a service (SaaS) apps are correlated into an attack story so analysts can see whether the same lure led to a clicked link, a downloaded payload, risky sign-in behavior, or endpoint activity.

As cyberattackers expand beyond email to gain broader access across the environment, Defender moves from detection to disruption. For multi-stage, multi-domain attacks like business email compromise or AiTM, Defender’s powerful, built-in response capability, attack disruption, will contain the compromised asset during the attack to prevent further lateral movement while security teams investigate and remediate. Attack disruption contains more than 81,000 compromised user accounts monthly and is now disrupting more than 45,000 AiTM attacks each month.

In a recent case study, Defender disrupted a business email compromise attack within four minutes of the initial activity (Figure 4). While response times may vary by scenario, this case shows the impact of attack disruption on a real cyberthreat. The cyberattacker used a convincing document-sharing lure to trick a user to start a legitimate Microsoft device code sign-in flow, which avoided traditional credential theft techniques. Defender recognized the resulting device code authentication and follow-on activity as suspicious, correlated signals across identity and email telemetry, and disrupted the attack within four minutes before the attacker could establish persistence, create inbox rules, or execute payroll fraud.

The takeaway

AI brands are the new bait, but the underlying lesson is bigger than any single campaign. As cyberattackers continue to exploit the momentum around AI, organizations should expect social engineering to become more targeted, more believable, and more difficult to evaluate in isolation.

The answer is not to treat every new lure as a brand-new category of risk. It is to build a protection model that makes trust harder to exploit across the full attack chain. Microsoft Defender helps organizations do that by connecting prevention, detection, investigation, and response across the attack path, so AI-themed lures are harder to deliver, harder to trust, and harder to turn into broader compromise.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹AI brands as bait: How threat actors are using the AI hype in social engineering, Microsoft Threat Intelligence. June 8, 2026.

The post Detect and disrupt AI-themed attacks with Microsoft Defender appeared first on Microsoft Security Blog.

Microsoft introduces the cloud web applications threat matrix, a MITRE ATT&CK-aligned framework that helps defenders understand, prioritize, and mitigate threats to cloud-hosted web apps and serverless platforms.

Cloud-hosted web applications and serverless platforms create attack paths that can cross application code, managed runtimes, workload identities, deployment pipelines, and connected cloud resources. Investigating the application and underlying cloud platform separately can leave gaps in how defenders understand those paths.

Microsoft developed the Cloud web applications threat matrix to organize relevant techniques using MITRE ATT&CK tactics. The matrix can help security teams assess visibility gaps, prioritize hardening, and plan investigations across cloud-native environments. This blog introduces the framework, examines selected techniques, and outlines defensive priorities for reducing exposure.

Overview

Cloud-hosted web applications and serverless platforms let teams deploy and scale application logic quickly, but they also create attack paths that cross application code, managed runtimes, identities, deployment pipelines, and connected cloud services. These paths can be difficult to detect when the application layer and underlying cloud platform are investigated separately.

To provide a clear and consistent view of the threat landscape affecting cloud hosted web applications and serverless environments, we organize techniques using the MITRE ATT&CK format. Building on Microsoft’s previously published threat matrices for Kubernetes and storage services, this matrix expands coverage for cloud web applications– applications that execute code in a managed environment, are often tightly integrated with other cloud resources, and are commonly exposed to the internet.

The attack techniques presented in this matrix are divided into the following tactics, aligned with the MITRE ATT&CK framework:

• Resource Development

• Initial Access

• Execution

• Persistence

• Privilege Escalation

• Defense Evasion

• Credential Access

• Discovery

• Lateral Movement

• Collection

• Impact

Technique Catalog

Below, we walk through each tactic and describe its techniques in more detail.

Resource Development

The resource development tactic consists of techniques that adversaries use to establish resources they can use to support operations. This may include acquiring infrastructure, developing capabilities, or compromising resources that can later be used during targeting.

Subdomain takeover

Deleting a cloud application or service without removing its associated DNS record pointed to a reusable provider endpoint can create a subdomain takeover risk. Depending on the provider’s behavior, service configuration, and naming constraints, a threat actor may be able to register a resource that claims the same address and intercept traffic intended for the original service, potentially serving malicious content or harvesting credentials.

Initial Access

The initial access tactic consists of techniques that are used for gaining access to cloud web applications and serverless environments. This access can be achieved through compromised credentials, vulnerable applications, misconfigured interfaces, or by exploiting connected resources.

Application vulnerability

Running a public-facing web application that hosts a vulnerable application can enable adversaries to access and execute code in the context of the web application, or to access internal resources and gain a foothold in the cloud environment. Such vulnerabilities could stem from the application’s own code, its underlying framework, or third-party libraries and dependencies it uses.

Code injection in connected repository

Threat actors may inject malicious code into source repositories that are linked to cloud web applications or serverless functions. If these repositories are automatically synced with production environments, the injected code executes under the legitimate workflows.

For example, if a threat actor gains commit permissions to a GitHub repository that is configured to deploy GCP Cloud Functions through Cloud Build triggers, their code may be deployed into the application through the legitimate pipeline.

Compromised image in registry

Some cloud web applications are deployed from a container image pulled from private or public registries. Threat actors who get access to a private registry can plant their own compromised images or update an existing image with malicious code, which will run the next time the web application pulls the container image.

Exposed/misconfigured admin interfaces

Some cloud-based web applications expose administrative interfaces for managing deployments, configurations, or runtime operations. If these interfaces are exposed to the internet or misconfigured, threat actors might be able to access them and view critical data, execute commands, or manipulate application behavior.

For example, if an Azure App Service exposes its Kudu interface to the internet, a threat actor with sufficient credentials could execute commands in the app’s environment.

Serverless trigger injection

In cases where the application executes backend workflows in response to event-driven triggers, an end user who can directly or indirectly influence those triggers may cause unintended activity within the application. By manipulating inputs such as crafted file uploads, queue messages, API calls, or other event sources, a threat actor can force serverless functions to run with their supplied data, which could lead to unintended code execution, data access, or further compromise.

For example, a threat actor might upload a modified image file containing a crafted payload through a legitimate web form. The image is then stored in an S3 bucket, which triggers an AWS Lambda function configured to process new uploads. If the function handles the file without proper validation, the threat actors payload could cause unintended behavior or even lead to remote code execution.

Using deployment credentials

In some cloud web applications, deployment credentials can grant management access beyond publishing new code. Adversaries who obtain such credentials might be able to use them to directly interact with the application without modifying its source code.

Azure App Service, compromised deployment credentials can allow access to deployment and SCM (Source code management) interfaces, which may enable file access, command execution, or application modification depending on the app configuration and credential scope.

Execution

The execution tactic consists of techniques that are used by threat actors to run their code inside cloud web applications and serverless environments.

Application exploit (remote code execution)

Deployed web applications that contain a remote code execution vulnerability, or a vulnerability that could eventually lead to code execution, can enable threat actors to run malicious code in the web application context. If the application has access to any additional resources, then the threat actor could access those as well.

Cloud native terminal

Some cloud platforms provide built-in administrative consoles or SSH-style terminals for running commands directly inside the application’s execution environment. Threat actors who gain access to the terminal may be able to extract data, edit the web app files and execute commands.

For example, Azure App Services expose a Kudu console that acts as a built-in terminal; if threat actors obtain deployment credentials, they can use it to browse files, execute commands, and tamper with application code.

Site extensions

Site extensions are an Azure App Services feature that allows users to install additional tools and utilities onto their web application. These extensions run within the context of the App Service and have the same permissions as the application itself – including requests data, file system access and environment variables. Site extensions are installed from a NuGet-based feed that allows third-party package submissions. If threat actors publish a malicious extension that resembles a legitimate package, or compromise an existing package, users who mistakes the package for a trusted extension may install it, allowing the threat actors code to run in the application context.

Persistence

The persistence tactic consists of techniques that are used by threat actors to maintain access to cloud web applications in case their initial foothold is lost.

Cron jobs

In cases where a cloud application uses scheduled or trigger-based tasks, a threat actor with the ability to create or modify such jobs can cause their malicious code to execute automatically. Because these jobs can run independently of normal request flows and often inherit the application’s privileges, control over a scheduled or event-triggered job allows persistent execution even if the main application code is updated.

For example, if a threat actor is able to create or modify a WebJob in Azure App Service, their code will periodically run on the web application, regardless of changes or updates to the application code itself.

Source code modification

A threat actor with access to a development environment may be able to modify the application’s source – which could reside in a git repository, a container image in a registry, or a deployment package in cloud storage. Because cloud web applications are typically deployed through automated pipelines, a single modification can propagate automatically into production, causing the threat actors code to run every time the application restarts. These changes become part of the application’s canonical source, meaning that even if the runtime environment is rebuilt or scaled, the tainted code is redeployed from the same trusted source, maintaining the threat actor access to the application.

Valid cloud accounts

Adversaries may gain access to cloud web applications and serverless environments by leveraging compromised valid cloud accounts. Using legitimate credentials allows threat actors to interact with such services without raising suspicion. This enables them to deploy or modify application code, configure triggers, and maintain control over workloads.

For example, a threat actor who compromises an Entra ID user with sufficient owner-level permissions on a subscription may be able to read or modify function app resources within that scope, subject to resource and policy controls.

Privilege Escalation

The privilege escalation tactic consists of techniques that are used by threat actors to get higher privileges in the environment than those they currently have. This can include accessing workload identity credentials or leveraging application permissions to access additional cloud resources.

Access cloud resources

Web apps deployed in the cloud often run with identities or service accounts that have permissions over additional cloud resources in the environment such as storage, databases and AI services. Additionally, some applications store connection strings or keys to cloud resources in the app configuration files or environment variables. Therefore, if threat actors compromise the application, they can often extract or leverage these credentials to access additional cloud resources.

Access workload identity credentials

Workload identities are identities that are managed by the cloud provider and can be allocated to cloud resources. The identity’s secret is fully managed by the cloud provider, which eliminates the need to manage the credentials. Web apps can use workload identities to perform actions on other cloud resources by querying Instance Metadata Service (IMDS) or similar endpoints. Threat actors who gain access to a web app can leverage their access to the IMDS endpoint to get the workload identity’s token. With a token, the threat actors can access cloud resources.

For example, in Azure App Services, the managed identity access token can be acquired through a local identity endpoint, which is defined in the environment variables (IDENTITY_ENDPOINT). If a threat actor is able to execute code on such an App Service instance, they would be able to query the endpoint and receive an access token to other Azure resources with the managed identity permissions.

Defense Evasion

The defense evasion tactic consists of techniques that are used by threat actors to avoid detection and hide their activity.

Development slots

Many cloud platforms and serverless environments support staging or preview environments (such as deployment slots in Azure App Services, aliases in AWS Lambda, or revision tags in GCP Cloud Run), which allow developers to test and stage new versions of their applications before swapping them into production. These environments can be swapped or promoted with minimal downtime. If a threat actor gains the ability to modify or promote a non-production environment, they may execute malicious code or gain insights into the application’s structure and behavior. In some cases, these staged environments are directly accessible without a swap, meaning a threat actor could execute code in a staging slot or alternate version and potentially evade detection, since the primary production deployment remains untouched.

For example, in Azure App Service, a threat actor who obtains permissions to manage a staging deployment slot could either swap it into production, thus pushing malicious code live, or exploit the slot’s separate URL to run the malicious app without modifying the production’s code.

Disable cloud logging

Threat actors with appropriate permissions may disable or alter cloud logging to hide their actions and avoid detection. This can include turning off diagnostic logging on a web application, deleting or modifying existing log data, changing log retention policies to accelerate log expiration, or redirecting log output. By suppressing logging, the threat actor reduces the visibility that defenders have into ongoing malicious activity, making it harder to detect the compromise, perform incident response, or reconstruct the attack timeline.

Credential Access

The credential access tactic consists of techniques that are used by threat actors to steal credentials. In cloud web application environments, this includes credentials of the running application, workload identities, secrets stored in configuration, or cloud credentials.

Brute force

Some web applications or interfaces may still use basic authentication, either for user access, administrative functions, or deployment interfaces. A threat actor could try to gain access by repeatedly attempting credential combinations, and upon finding valid credentials, use them to access and use the relevant privileges.

For example, Azure App Service exposes the Kudu management console (the SCM site) and FTP endpoints that support basic authentication. This includes user‑scoped deployment credentials, which are manually set by the user and shared across all App Services within a subscription that the user has access to. If a threat actor is able to successfully guess those credentials, they could gain deployment access to multiple applications in the subscription.

Cloud credentials in runtime environment

Some web applications store secrets such as keys, tokens, and connection strings in environment variables or configuration files. In cloud environments, those secrets are often used to access additional cloud services within the environment. If a threat actor gains access, even read-only, to the running application environment, they would be able to retrieve those credentials and use them to authenticate against those external cloud resources.

For example, an Azure Function configured to authenticate to Azure OpenAI with a resource key may store that key and the service endpoint in application settings exposed as environment variables. a threat actor who accesses those variables could use the key to make authorized data-plane API requests to the associated Azure OpenAI resource.

Discovery

The discovery tactic consists of techniques that are used by threat actors to explore the environment to which they gained access. This exploration helps the threat actors to perform lateral movement and gain access to additional resources.

Access to connected cloud storage

Cloud applications often use external storage services for hosting source code, configuration files or assets. Threat actors may exploit misconfigured or compromised read access to this storage to review the code and configuration to find vulnerabilities or sensitive information that could be exploited to take over the application.

For example, in GCP Cloud Run functions, the function code is saved into a bucket in the project. If a threat actor compromised a user with storage read access, they would be able to view the source code.

Cloud service discovery

Cloud‑hosted applications often contain configuration values or runtime information that reference other cloud services the application interacts with, such as service URLs, API endpoints, database connection strings, or resource identifiers. After gaining access to a web application, threat actors can discover additional cloud resources through environment variables, network connections or application code.

Instance metadata API

Cloud platforms expose metadata services that provide information about the running environment, such as instance details, network configuration, and identity credentials. In some cases, this service is available from within cloud web applications as well. Threat actors who gain access to such an application may query the metadata API service to get information about the underlying VM and the application environment.

Lateral Movement

The lateral movement tactic consists of techniques that are used by threat actors to move through the victim’s environment. In cloud web application environments, this includes gaining access to connected cloud resources, third-party services, or internal network resources.

Connector reuse

Cloud applications may use managed connectors or integration resources to interact with third-party services such as email providers, SaaS platforms, databases, or messaging systems. These connectors sometimes store authentication or authorization details – such as OAuth tokens and access keys, that are separate from the web application’s own identity and thus could be reused across multiple applications. A threat actor who compromises a user or identity with permissions over the connector resource can invoke those stored credentials to access the connected third-party services, enabling lateral movement beyond the cloud environment.

For example, in Azure Logic Apps, API connections are standalone resources that store authenticated sessions to external services, such as Office 365, Slack, or SQL databases. A threat actor with sufficient permissions on the resource group can create a new app that uses existing API connectors, triggering actions on the connected services using the stored credentials without needing to extract the underlying secrets.

Collection

The collection tactic consists of techniques that are used by threat actors to collect data from cloud web applications or connected resources.

Access application database

Many applications rely on a connected database to store application data, user information, configuration values, or state. The application often connects to the database by using the application’s cloud identity, or by using a hardcoded connection string. If a threat actor gains code execution abilities, they can interact with the database – query and extract data or modify entries. In cases where the database is accessible from the internet, threat actors may only need read permissions over the web app to access the database.

Event data capture

Cloud applications often generate logs that include diagnostic data, request metadata, or user input. Due to misconfigured logging levels or insufficient filtering, these logs may inadvertently contain sensitive information such as credentials, personally identifiable information (PII), or details about the application environment, including internal paths, dependency versions, and cloud resource names. This information could assist adversaries in furthering their attacks. Logs may be stored locally, streamed to external services, or accessed through debugging interfaces. Logs may be stored locally, streamed to external services, or accessed via debugging interfaces. If a threat actor gains access to the application or its logging infrastructure, they can collect this data to aid further exploitation or reconnaissance.

For example, AWS Lambda functions automatically send all standard output to CloudWatch Logs. If verbose or debug-level logging is misconfigured and left enabled in production, sensitive data may end up in the log group. A threat actor who gains read access to CloudWatch can then harvest this information.

Impact

The impact tactic consists of techniques that are used by threat actors to destroy, abuse, or disrupt the normal behavior of cloud web applications and their environments.

Data destruction

Threat actors who gain sufficient privileges within a cloud web application may delete or corrupt data stored in the app or in connected cloud resources such as databases and storage.

Data theft

If threat actors gain access to the application, its storage, or connected cloud resources, they may be able to retrieve data stored or processed by the application. This includes application content, user information, configuration files, or proprietary content.

Defacement

Adversaries may attempt to alter the web application’s content or appearance to damage reputation, intimidate victims or spread propaganda. This could be done through access to the application itself, to the source code or any assets it uses.

Denial of wallet

Cloud applications often scale dynamically based on demand, incurring costs for compute, storage, and data transfer. Threat actors may intentionally trigger operations that will cause those resources to scale out to impose financial damage. One such approach is to flood a web application with requests, similar to traditional denial-of-service (DoS) attacks. This will cause the application to allocate more resources, thus causing increased charges.

For example, a threat actor could repeatedly invoke a Cloud Function with high memory allocation, leading to inflated billing due to excessive execution time.

Resource hijacking

Threat actors may leverage the compute, network, or storage resources of the application for unauthorized purposes, such as cryptocurrency mining, mass scanning, or traffic proxying.

Mitigation and protection guidance

As organizations adopt cloud-native and serverless architectures, defending against these threats requires visibility across both application behavior and underlying cloud resources. The cloud web applications threat matrix is intended to support this by mapping techniques to attack stages, helping defenders identify where visibility exists and where gaps remain.

Mitigation strategies for individual techniques are detailed within the matrix. Across the matrix, recurring priorities include requiring multifactor authentication, applying least-privilege permissions to users and workloads, and restricting access to applications, deployment environments, and connected resources.

Organizations should also protect source repositories, build systems, and deployment pipelines from unauthorized changes, and install packages and extensions only from trusted sources. Reusable credentials should not be stored in source code or configuration files. Workload identities and secrets management solutions should be used where supported, while network access to sensitive services should be limited to authorized networks.

To support investigation, organizations should centralize security-relevant logs in protected locations and prevent unauthorized changes to logging configurations. Resource quotas, concurrency limits, cost guardrails, and spending alerts can help reduce the impact of resource hijacking and denial-of-wallet activity. Organizations should also maintain and test backup and recovery plans to prepare for destructive operations.

Microsoft Defender for Cloud and Microsoft Defender XDR can support investigation and response across many related signals, including cloud resource posture, workload activity, identity activity, and cross-domain incidents, depending on customer configuration and available telemetry.

References

• Threat Matrix for Cloud Web Applications

• MITRE ATT&CK®

• Threat Matrix for Kubernetes

• Threat Matrix for Storage Services

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.  

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

The post Threat matrix: Mapping threats across cloud web applications appeared first on Microsoft Security Blog.

Microsoft Security Research is tracking active cloud-based intrusions spanning multiple accounts in which unusual sign-ins were followed by threat actor-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through REST APIs. Microsoft Security Research assesses that this sequence is consistent with automated collection from compromised cloud identities using proxy-associated infrastructure, the activity has been observed since May 2026.

The activity begins with identity-focused social engineering and impersonation infrastructure, proceeds through authentication persistence and cloud reconnaissance, and is followed by targeted data access and activity consistent with data collection and potential exfiltration. Domains, IP addresses, and hosting providers can change quickly, but the recurring sequence of identity compromise, persistence, reconnaissance, content discovery, and exfiltration provides a more durable basis for investigation. Defenders should investigate this sequence across identity, Microsoft Graph, SharePoint, OneDrive, and Exchange signals, then revoke sessions and remove unauthorized authentication methods for confirmed compromises.

Attack chain overview

Step 1-2 : Initial access: Passkey and SSO lures

The attack often begins with a seemingly routine call or message on a user’s personal phone number from someone claiming to be from the organization’s IT helpdesk. The caller creates a sense of urgency, explaining that a passkey, multifactor authentication (MFA), or single sign-on (SSO) configuration must be updated immediately to avoid disruption. Employees are directed to a website that closely resembles a legitimate Microsoft sign-in experience and may receive the link through SMS messages sent directly to their personal mobile phones.

Despite the frequent use of passkey-themed lures, passkey enrollment is often not the actor’s true objective. Instead, the passkey narrative serves as a convincing pretext to guide victims through adversary-in-the-middle (AiTM) phishing or device-code authentication flows. In AiTM scenarios, the actor captures credentials and session tokens; in device code attacks, the victim unknowingly authorizes access on the actor’s behalf. This initial interaction may leave very little forensic evidence. If the victim opens the phishing link on a personal mobile device that is not onboarded to Microsoft Defender for Endpoint, the related activity may be absent from endpoint telemetry.

In many investigations, the employee’s recollection of a phone call or text message becomes the earliest and sometimes the only evidence explaining how the compromise began. As a result, investigators must often reconstruct the attack by connecting these reports with subsequent sign-ins, device code authentication events, token activity, and authentication method changes.

Reconnaissance on targeted organization

The actor appears to invest heavily in pre-attack research, likely gathering information about employees and organizational structure from public sources such as social networking and professional profiling platforms.

Reusable domains, personalized targeting

In a smaller number of cases, actors take advantage of already compromised accounts to expand their reach. Using a trusted employee identity, they send similar passkey-themed messages through Microsoft Teams, making the request appear legitimate and significantly increasing the likelihood of engagement. To support these operations, the actors rapidly deploy convincing phishing infrastructure built around themes such as passkeys, SSO enrollment, account activation, and identity verification.

A commonly observed technique involves registering generic domains and embedding the target organization’s name as a subdomain, creating URLs that appear familiar at first glance. Multiple domains may be created for the same organization, allowing the actor to rotate infrastructure as needed. These domains are often registered with Nicenic registrar (observed in previous extortion campaigns) and operational within hours, giving defenders little opportunity to identify and block the infrastructure before employees encounter it. Registration alone should not be interpreted as evidence of registrar involvement in the activity. For example, company-name.integratedsso[.]com and company-name.secure-passkey[.]com illustrate how the same company name can appear under different actor-controlled domains.

Together, the phone-based social engineering, personalized targeting, trusted internal messaging, and rapidly changing phishing infrastructure form the opening chapter of a highly coordinated intrusion designed to blend technical deception with human trust.

The actor creates domains following the pattern companyname[.]maliciousdomain[.]com to impersonate organization-specific authentication portals. Including the victim organization’s name in the URL helps establish credibility and can persuade users to proceed with authentication. Example: contoso[.]add-passkey[.]com.

Step 3-4 : User identity compromise

From one sign-in to broader application access

In one investigated attack sequence, the activity began with an anomalous sign-in to Microsoft OfficeHome application from an unmanaged device, possibly attacker-owned. Once MFA was completed, the actor began accessing identity portals such as My Sign-Ins and enterprise application stores such as My Apps. Sign-in artifacts, including user-agent patterns, indicated possible AiTM phishing.

Using the same session, the actor further accessed several management applications, including Microsoft Approval Management, which is used for identity and approval-related services. SharePoint Online and OneDrive were used to enumerate sensitive files, primarily through the Graph API. The investigation revealed that the actor’s sessions persisted for approximately one hour while enumerating sensitive files and internal applications.

Passkey lure leads to device code phishing

In another investigated attack sequence, the actor was observed using the device code flow to compromise the session token after the passkey lure. In device code phishing, the user is persuaded to enter a code on the legitimate Microsoft authentication page. This approval issues a token to an attacker-controlled client, which can then access permitted resources without stealing a browser cookie. Following the device code flow, the actor successfully replayed the compromised token, effectively bypassing MFA and conducting enumeration and further attack progression.

Reusing the same credentials after an earlier compromise

The third attack pattern involved the actor signing in with compromised credentials, with MFA approved using a previously registered PhoneAppOTP method. This suggests that the attacker had registered the authenticator app days before launching the campaign. Once the sign in was successful, the actor followed the same reconnaissance pattern observed in other attack sequences. This activity was primarily carried out using an automated system developed with Node.js and Microsoft Graph.

To illustrate how the activity unfolded over time, the following timeline summarizes the key events identified during the investigation.

Step 5 : New MFA device for persistence

Following initial access, the actor’s first objective was to transform a temporary compromise into a persistent foothold. Rather than relying solely on stolen credentials, the actor enrolled an MFA method under their control, typically by registering a new phone number, authenticator application, or software-based one-time password (OTP) token. This effectively inserted an actor-controlled factor into the victim’s identity, allowing future authentication challenges to be satisfied without the user’s involvement.

By registering an actor-controlled MFA method, the threat actor ensured that future authentication challenges could be satisfied using a factor they controlled. While MFA enrollment alone does not survive a complete credential and session reset, it provides a durable persistence mechanism when combined with stolen tokens, unrevoked sessions, or subsequent access to valid credentials. As a result, actors frequently establish MFA persistence early in the intrusion to increase the likelihood of maintaining long-term access to the compromised identity.

Phone or authenticator device addition

Detects a newly registered MFA device with a populated device token. The query compares the previous and updated authentication method values and returns newly added device records.

CloudAppEvents
 | where ActionType == "Update user."
 | where tostring(RawEventData.ResultStatus) == "Success"
 | where RawEventData has_any ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails")
 | extend AccountObjectId = extract(@"User_([a-f0-9\-]+)", 1, tostring(RawEventData.Target))
 | where isnotempty(AccountObjectId)
 | mvexpand ModifiedProp = RawEventData.ModifiedProperties
 | where tostring(ModifiedProp.Name) in ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails")
 | extend OldValue = tostring(ModifiedProp.OldValue),
          NewValue = tostring(ModifiedProp.NewValue)
 | extend OldDeviceCount = countof(OldValue, @"""Id"""),
          NewDeviceCount = countof(NewValue, @"""Id""")
 | where NewDeviceCount > OldDeviceCount

Software token addition

Below is a real-world example of attacker controlled Software token added to the user’s identity with Update user operation. This is added as a second NewValue entry containing the device name NO_DEVICE, device token NO_DEVICE_TOKEN, and the SoftwareTokenActivated device tag.

{
[EF1.1][KR1.2]   "Id": "[GUID_REDACTED]",
   "CreationTime": "2026-09-04T16:57:42.0000000Z",
   "OrganizationId": "[GUID_REDACTED]",
   "Operation": "Update user.",
   "RecordType": 8,
   "Workload": "AzureActiveDirectory",
   "ResultStatus": "Success",
   "UserKey": "Not Available",
   "UserId": "ServicePrincipal_[GUID_REDACTED]",
   "Version": 1,
   "UserType": 4,
   "ObjectId": "[EMAIL_REDACTED]",
   "ModifiedProperties": [
     {
       "Name": "StrongAuthenticationPhoneAppDetail",
       "OldValue": [
         {
           "DeviceName": "[DEVICE_NAME_REDACTED]",
           "DeviceToken": "[DEVICE_TOKEN_REDACTED]",
           "DeviceTag": "iOS",
           "PhoneAppVersion": "6.8.53",
           "OathTokenTimeDrift": 0,
           "DeviceId": "[GUID_REDACTED]",
           "Id": "[GUID_REDACTED]",
           "TimeInterval": 0,
           "AuthenticationType": 3,
           "NotificationType": 2,
           "LastAuthenticatedTimestamp": "2026-09-04T16:54:47.6425033Z",
           "AuthenticatorFlavor": "Authenticator",
           "HashFunction": null,
           "TenantDeviceId": null,
           "SecuredPartitionId": 20111,
           "SecuredKeyId": 7
         }
       ],
       "NewValue": [
         {
           "DeviceName": "[DEVICE_NAME_REDACTED]",
           "DeviceToken": "[DEVICE_TOKEN_REDACTED]",
           "DeviceTag": "iOS",
           "PhoneAppVersion": "6.8.53",
           "OathTokenTimeDrift": 0,
           "DeviceId": "[GUID_REDACTED]",
           "Id": "[GUID_REDACTED]",
           "TimeInterval": 0,
           "AuthenticationType": 3,
           "NotificationType": 2,
           "LastAuthenticatedTimestamp": "2026-09-04T16:54:47.6425033Z",
           "AuthenticatorFlavor": "Authenticator",
           "HashFunction": null,
           "TenantDeviceId": null,
           "SecuredPartitionId": 20111,
           "SecuredKeyId": 7
         },
         {
           "DeviceName": "NO_DEVICE",
           "DeviceToken": "NO_DEVICE_TOKEN",
           "DeviceTag": "SoftwareTokenActivated",
           "PhoneAppVersion": "NO_PHONE_APP_VERSION",
           "OathTokenTimeDrift": 0,
           "DeviceId": "[GUID_REDACTED]",
           "Id": "[GUID_REDACTED]",
           "TimeInterval": 0,
           "AuthenticationType": 2,
           "NotificationType": 1,
           "LastAuthenticatedTimestamp": "2026-09-04T16:57:42.4514487Z",
           "AuthenticatorFlavor": "Authenticator",
           "HashFunction": "hmacsha1",
           "TenantDeviceId": null,
           "SecuredPartitionId": 20111,
           "SecuredKeyId": 7
         }
       ]
     },
     {
       "Name": "Included Updated Properties",
       "OldValue": "",
       "NewValue": "StrongAuthenticationPhoneAppDetail"
     },
     {
       "Name": "TargetId.UserType",
       "OldValue": "",
       "NewValue": "Member"
     }
   ]
 }

Step 6 : Graph reconnaissance

Once MFA persistence was established, the actor initiated an extensive internal reconnaissance phase using Microsoft Graph to inventory users, groups, permissions, resources, and accessible content across the tenant with the compromised identity. The actor deliberately rotated infrastructure throughout the attack lifecycle, with separate IP addresses often used for authentication, reconnaissance, and exfiltration activities. As a result, piecing together the full intrusion required correlating activity across multiple stages rather than relying on individual network indicators.

The attack underscores a critical detection challenge: Microsoft Graph abuse rarely appears suspicious when viewed through a single API call. Requests to endpoints such as /users, /groups, or /sites are commonplace in enterprise environments. However, when the same identity, application, or access token systematically traverses multiple tenant resources, evaluates privilege and authentication settings, and subsequently accesses mail, files, attachments, or document content, those actions collectively form a clear reconnaissance-to-exfiltration chain. This attack serves as a strong example of why Graph activity must be assessed holistically, with emphasis on behavioral progression and cross-event correlation rather than individual API requests in isolation.

Graph reconnaissance pattern matrix initiated by the actor

Hunt for broad Graph reconnaissance in one session

Find identities or applications touching several reconnaissance categories from the same IP within 30 minutes.

let Lookback = 24h; [MI25.1][IM25.2]
GraphAPIAuditEvents 
| where Timestamp > ago(Lookback) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
        ActorId = coalesce(AccountObjectId,  
                           ServicePrincipalId, ApplicationId), 
        Path = tostring(split(tolower(RequestUri), "?")[0]) 
| extend ReconType = case( 
   Uri has "/organization" or Uri has "/subscribedskus", "Tenant", 
   Uri has "/users" or Uri has "/groups", "Directory", 
   Uri has "/directoryroles" or Uri has "/rolemanagement", "Privilege", 
   Uri has "/applications" or Uri has "/serviceprincipals" 
       or Uri has "/oauth2permissiongrants", "Application", 
   Uri has "/sites" or Uri has "/drive", "Repository", 
   Uri has "/messages" or Uri has "/mailfolders", "Mailbox", 
   "Other") 
| where ReconType != "Other" and isnotempty(ActorId) 
| summarize Requests=count(), Categories=dcount(ReconType), 
           DistinctPaths=dcount(Path), 
           ReconTypes=make_set(ReconType, 10), 
           SampleUris=make_set(RequestUri, 10) 
   by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) 
| where Requests >= 10 and Categories >= 3 and DistinctPaths >= 6 
| order by Categories desc, Requests desc

Hunt for privilege, MFA, application, and consent discovery

Highlight sensitive control-plane reconnaissance that can expose persistence or escalation opportunities.

GraphAPIAuditEvents 
| where Timestamp > ago(24h) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
         ActorId = coalesce(AccountObjectId,
                            ServicePrincipalId, ApplicationId) 
| where Uri has_any ("/directoryroles", "/rolemanagement", 
                     "/authentication/methods", "/applications", 
                     "/serviceprincipals", "/oauth2permissiongrants", 
                     "/approleassign") 
| summarize Requests=count(), DistinctPaths=dcount(tostring(split(Uri, "?")[0])), 
            ScopesSeen=make_set(Scopes, 10), 
            SampleUris=make_set(RequestUri, 12) 
    by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) 
| where Requests >= 4 and DistinctPaths >= 2 
| order by Requests desc

Hunt for SharePoint and OneDrive repository discovery

Detect search, child traversal, delta queries, and paging used to map file repositories.

GraphAPIAuditEvents 
| where Timestamp > ago(24h) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
         ActorId = coalesce(AccountObjectId,
                            ServicePrincipalId, ApplicationId), 
         Path = tostring(split(tolower(RequestUri), "?")[0]) 
| where Uri has_any ("/sites", "/drives", "/drive/") 
| where Uri has_any ("/search", "/children", "/delta", 
                     "$skiptoken", "%24skiptoken", "$top", "%24top") 
| summarize Requests=count(), DistinctPaths=dcount(Path), 
            SampleUris=make_set(RequestUri, 12) 
    by ActorId, IpAddress, ApplicationId, bin(Timestamp, 20m) 
| where Requests >= 8 and DistinctPaths >= 4 
| order by Requests desc

Hunt for mailbox and attachment reconnaissance

Find concentrated enumeration of messages, mail folders, and attachments.

GraphAPIAuditEvents 
| where Timestamp > ago(24h) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
         ActorId = coalesce(AccountObjectId, 
                            ServicePrincipalId, ApplicationId), 
         Path = tostring(split(tolower(RequestUri), "?")[0]) 
| where Uri has_any ("/messages", "/mailfolders", "/attachments") 
| summarize Requests=count(), 
            DistinctPaths=dcount(Path), 
            MessageRequests=countif(Uri has "/messages"), 
            AttachmentRequests=countif(Uri has "/attachments"), 
            TotalResponseBytes=sum(coalesce(ResponseSize, 0)), 
            SampleUris=make_set(RequestUri, 12) 
    by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) 
| where (Requests >= 8 and DistinctPaths >= 4) or AttachmentRequests >= 3 
| order by AttachmentRequests desc, Requests desc

Step 7-8 : High-volume cloud data collection and suspected exfiltration

Following reconnaissance, the actor transitioned into large-scale data collection across Microsoft 365 workloads using the compromised identities. Microsoft observed high-volume access and download activity targeting Microsoft SharePoint Online and Microsoft OneDrive for Business, with some intrusions extending into Microsoft Exchange Online through REST API-based access to email content. Across SharePoint and OneDrive, the activity generated significant volumes of FileAccessed and FileDownloaded events, indicating systematic retrieval of cloud-hosted documents and organizational data.

The activity frequently exhibited characteristics of automation rather than interactive user behavior. In several cases, Microsoft observed the python-httpx user agent associated with high-volume SharePoint and OneDrive access patterns. However, the user agent alone should not be treated as malicious. Instead, such activity should be evaluated in the broader context of data volume, affected identities, source infrastructure, prior reconnaissance activity, and evidence of identity compromise.

Unlike rapid smash-and-grab operations, data exfiltration was typically measured and sustained, often spanning several hours to multiple days depending on the volume of files and email content available to the compromised user. The actors generally maintained a controlled pace of collection, with fewer than 1,000 files or emails accessed within any one-hour period, likely helping the activity blend with normal enterprise usage while enabling the gradual extraction of large amounts of sensitive data over time.

Hunt for exfiltration through Exchange Online

Exfiltration of data through REST API using Microsoft Office or One Outlook Web

CloudAppEvents 
| where isempty(AccountObjectId) 
| where ApplicationId == '20893' 
| where AccountDisplayName in ("One Outlook Web", "9199bf20-a13f-4107-85dc-02114787ef48", "d3590ed6-52b3-4102-aeff-aad2292ab01c") 
| where isnotempty(IPAddress) 
| extend AccountObjectId = tostring(RawEventData.TokenObjectId) 
| summarize ExchangeRestEventCount=count() by IPAddress, AccountObjectId, bin(Timestamp,1h) 
| where ExchangeRestEventCount >= 500

Hunt for exfiltration through Microsoft SharePoint Online, OneDrive for Business

Exfiltration of data through python-httpx user agent

CloudAppEvents 
| where ApplicationId == "20892" or ApplicationId == "15600"
| where ActionType in ("FileDownloaded", "FileAccessed", "SyncDownloadedFull")
| where isnotempty(AccountObjectId) 
| where isnotempty(IPAddress) 
| where isnotempty(UserAgent) 
| where UncommonForUser has_any("ISP","UserAgent") 
| where UserAgent has 'python-httpx' 
| project Timestamp, AccountObjectId, IPAddress, ISP, UserAgent 
| summarize FilesAccessedLastWindow = count() by AccountObjectId, IPAddress, ISP, UserAgent, bin(Timestamp,2h) 
| where FilesAccessedLastWindow >=100

Hunt for anomalous high-volume exfiltration

Exfiltration of data through anonymous proxy

CloudAppEvents
| where ApplicationId in (20892, 20893, 15600)
| where ActionType in~ ("FileDownloaded", "FileAccessed", "FilePreviewed")
| where IsAnonymousProxy == true
| where UserAgent !has "ODMTADemand"
| extend FileSizeBytes = coalesce(tolong(RawEventData.FileSizeBytes), 0)
| summarize
    FileSizeBytes = sum(FileSizeBytes),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    EventCount = count(),
    ActionTypes = make_set(ActionType),
    Applications = make_set(Application)
    by AccountObjectId, IPAddress,
       TimeBucket = bin(Timestamp, 2h), UserAgent, ISP
| extend FileSizeGB =
    round(FileSizeBytes / 1024.0 / 1024.0 / 1024.0, 2)
| where FileSizeGB >= 5 or EventCount >= 1000
| order by EventCount desc

Attribution

Microsoft Threat Intelligence assesses that the initial access activity observed in this campaign is used by a range of threat actors, including Storm-3121, Storm-3032, and others. Storm-3121 conducts initial access activity leading to ShinyHunters and Falcon extortion. Storm-3032 represents a set of actors that splintered from the BlackFile group and now operate under the Helix extortion banner. That being said, Microsoft Defender has detection coverage for the known tactics, techniques and procedures from Storm-3121, Storm-3032 and other operators in the same ecosystem.

Mitigation and protection guidance

Microsoft recommends that organizations investigate identity and cloud-workload signals as a connected sequence, with priority given to unusual sign-ins followed bys authentication method enrollment, Microsoft Graph reconnaissance, token issuance, and abnormal SaaS download or mailbox activity.

Investigate

• Review newly registered authentication methods and devices for users with risky or unusual sign-ins and remove unauthorized methods after validating the user.
• Investigate high-volume or programmatic Microsoft Graph activity involving directory enumeration, role discovery, service principal discovery, SharePoint, OneDrive, or sensitivity-label discovery.
• Correlate SharePoint and OneDrive download anomalies, Exchange REST activity, and mailbox or attachment searches with identity and authentication events.

Contain and remediate

• Revoke active sessions and refresh tokens for confirmed compromised identities, reset credentials, remove attacker-registered authentication methods, remove attacker created mailbox rules, and require secure re-registration of authentication methods.

Reduce future risk

• Do not treat an IP or domain match as conclusive on its own. Validate workload behavior, affected identities, persistence events, and data access volume.
• Enforce phishing-resistant MFA (FIDO2/passkeys, Windows Hello for Business) via Conditional Access
• Enforce Conditional Access that requires a managed, compliant device for Exchange, SharePoint, and Graph-privileged apps
• Enforce strict conditional access controls for security info registration, including setting required sign-in frequency to always (require a new interactive auth), requiring managed devices and/or named locations, and requiring phish-resistant MFA as a required authentication strength, and in a separate policy blocking security info registration with a high sign-in risk condition
• Enforce risk-based access policies for risky sign-ins and risky users – remediate elevated risk with phishing-resistant MFA or secure password change, and block access at the highest risk levels.
• Train users against voice and email phishing that targets MFA and passkey enrollment. Provide a verified channel to report unsolicited authentication requests.
• Block the device code and authentication transfer flows via Conditional Access, except where an explicit business need exists.
• Restrict user consent for applications, require admin approval, and regularly review service principals holding high-privilege Graph permissions such as Mail.Read, Files.Read.All, and Directory.Read.All.
• Limit access from unmanaged devices to web-only sessions without download or sync, and disable anonymous sharing links in SharePoint and OneDrive.
• Enable Microsoft Graph activity logs and mailbox auditing, and alert on anomalous enumeration, authentication-method registration, and high-volume file or mail access.
• Educational training: Verify user identity through a rigorous process before performing any helpdesk-initiated credential or MFA reset, and alert on every such reset.

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 Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to investigate activity associated with this intrusion pattern:

• Incident investigation – Generates investigation summaries and helps analysts understand incidents involving compromised identities, suspicious sign-ins, persistence activity, and cloud-based data access.
• Microsoft User analysis – Analyses user accounts, sign-in activity, authentication events, risk indicators, and related identity signals that may help identify compromised accounts.

Customers can also use Microsoft Security Copilot together with Microsoft Threat Intelligence to investigate indicators, threat activity, and related intelligence associated with suspicious sign-ins, Microsoft Graph reconnaissance, and cloud data exfiltration activity.

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.

MITRE ATT&CK Techniques observed

Reconnaissance

• T1591 Gather Victim Org Information | Use of themed domains for credential phishing pages
• T1598.003 Phishing for Information: Spear-phishing Link | Use of spear-phishing emails with links to spoofed sign-in pages

Resource Development

• T1583.001 Acquire Infrastructure: Domains | Use of themed domains for credential phishing pages
• T1585.002 Establish Accounts: Email Accounts | Delivery infrastructure that is comprised of accounts from consumer email providers like Hotmail

Initial Access

• T1078.004 Valid Accounts: Cloud Accounts | The compromised cloud identity is used to authenticate to Microsoft cloud services.

Persistence

• T1556.006 Modify Authentication Process: Multi-Factor Authentication | After gaining account access, the threat actor registers a new authentication method, mobile device, or software-based OTP to establish persistent access to the compromised identity.

Discovery

• T1087.004 Account Discovery: Cloud Account | The threat actor uses Microsoft Graph to enumerate tenant users and identities, including information useful for identifying high-value identities and privileged accounts.
• T1069.003 Permission Groups Discovery: Cloud Groups | Microsoft Graph reconnaissance enumerates group memberships and directory roles, allowing the threat actor to understand privilege relationships and identify potentially valuable identities.

Collection

• T1530 Data from Cloud Storage | The actor searches and accesses SharePoint and OneDrive content and performs high-volume file access/download activity to collect targeted cloud-hosted information.
• T1114 Email Collection | Mailboxes, messages, and attachments are searched for material of interest and email is collected through REST APIs.
• T1213 Data from Information Repositories | The actor searches enterprise cloud repositories, including SharePoint content and other organizational cloud data, to identify information of value for collection.

Exfiltration

• T1567 Exfiltration Over Web Service | The campaign performs high-volume cloud data access and uses automated Python-based activity for rapid collection and exfiltration.

Advanced hunting queries

Additional advanced hunting query for Graph reconnaissance:

Hunt for automated pagination, delta, and search behavior

Identify actors walking large Graph result sets or repeatedly querying for data.

GraphAPIAuditEvents 
| where Timestamp > ago(24h) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
         ActorId = coalesce(AccountObjectId, 
                            ServicePrincipalId, ApplicationId), 
         Path = tostring(split(tolower(RequestUri), "?")[0]) 
| where Uri has_any ("$top", "%24top", "$skip", "%24skip", 
                     "$skiptoken", "%24skiptoken", "$count", 
                     "%24count", "/delta", "/search") 
| summarize AutomatedRequests=count(), DistinctPaths=dcount(Path), 
            SampleUris=make_set(RequestUri, 12) 
    by ActorId, IpAddress, ApplicationId, bin(Timestamp, 15m) 
| where AutomatedRequests >= 8 and DistinctPaths >= 4 
| order by AutomatedRequests desc

Hunt for reconnaissance progressing to content collection

Prioritize sessions where broad discovery and content retrieval occur together.

GraphAPIAuditEvents 
| where Timestamp > ago(24h) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
         ActorId = coalesce(AccountObjectId,
                            ServicePrincipalId, ApplicationId) 
| extend ActivityType = case( 
    Uri has "/content" or Uri has "/attachments", "ContentCollection", 
    Uri has "/users" or Uri has "/groups", "DirectoryRecon", 
    Uri has "/directoryroles" or Uri has "/rolemanagement" 
        or Uri has "/authentication/methods", "PrivilegeRecon", 
    Uri has "/applications" or Uri has "/serviceprincipals", "ApplicationRecon", 
    Uri has "/sites" or Uri has "/drives" or Uri has "/drive/", "RepositoryRecon", 
    Uri has "/messages" or Uri has "/mailfolders", "MailboxRecon", 
    "Other") 
| where ActivityType != "Other" 
| summarize DiscoveryFirst=minif(Timestamp, ActivityType != "ContentCollection"), 
            CollectionFirst=minif(Timestamp, ActivityType == "ContentCollection"), 
            DiscoveryCategories=dcountif(ActivityType, ActivityType != "ContentCollection"), 
            ContentRequests=countif(ActivityType == "ContentCollection"), 
            TotalResponseBytes=sum(coalesce(ResponseSize, 0)), 
            SampleUris=make_set(RequestUri, 15) 
    by ActorId, IpAddress, ApplicationId, bin(Timestamp, 1h) 
| where isnotnull(DiscoveryFirst) and isnotnull(CollectionFirst) 
| where CollectionFirst >= DiscoveryFirst 
    and DiscoveryCategories >= 2 and ContentRequests >= 1 
| order by CollectionFirst desc

Hunt for exfiltration through Microsoft Graph

Prioritize sessions where broad discovery and content retrieval occur together.

GraphAPIAuditEvents 
| where Timestamp > ago(24h) 
| where toint(ResponseStatusCode) between (200 .. 299) 
| extend Uri = tolower(RequestUri), 
         ActorId = coalesce(AccountObjectId, 
                            ServicePrincipalId, ApplicationId) 
| extend ActivityType = case( 
    Uri has "/content" or Uri has "/attachments", "ContentCollection", 
    Uri has "/users" or Uri has "/groups", "DirectoryRecon", 
    Uri has "/directoryroles" or Uri has "/rolemanagement" 
        or Uri has "/authentication/methods", "PrivilegeRecon", 
    Uri has "/applications" or Uri has "/serviceprincipals", "ApplicationRecon", 
    Uri has "/sites" or Uri has "/drives" or Uri has "/drive/", "RepositoryRecon", 
    Uri has "/messages" or Uri has "/mailfolders", "MailboxRecon", 
    "Other") 
| where ActivityType != "Other" 
| summarize DiscoveryFirst=minif(Timestamp, ActivityType != "ContentCollection"), 
            CollectionFirst=minif(Timestamp, ActivityType == "ContentCollection"), 
            DiscoveryCategories=dcountif(ActivityType, ActivityType != "ContentCollection"), 
            ContentRequests=countif(ActivityType == "ContentCollection"), 
            TotalResponseBytes=sum(coalesce(ResponseSize, 0)), 
            SampleUris=make_set(RequestUri, 15) 
    by ActorId, IpAddress, ApplicationId, bin(Timestamp, 1h) 
| where isnotnull(DiscoveryFirst) and isnotnull(CollectionFirst) 
| where CollectionFirst >= DiscoveryFirst 
    and DiscoveryCategories >= 2 and ContentRequests >= 1 
| order by CollectionFirst desc

Indicators of compromise (IOC)

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.  

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

The post Passkey-themed social engineering leads to identity and cloud compromise appeared first on Microsoft Security Blog.

Edge AI moves model execution, model IP, customer data, and system authority into infrastructure the customer owns and operates. That changes who must verify the stack before sensitive assets are released.

Edge AI includes AI systems where inference runs on or near the device, sensor, or other local environments where data is produced and acted on, rather than relying entirely on a centralized cloud service. It is chosen for cost, model selection, sovereignty, latency, and disconnected operation.

Edge AI changes the trust model for AI systems

In Cloud AI, separate companies own and attest the hardware, platform, and model weights. Edge AI deployments often place customers in control of more of the AI stack. This changes the security model because the customer is now responsible for establishing trust across the environment where the AI operates.

In Edge AI, attacks such as prompt injection, model tampering, or malicious firmware updates can occur in the same environment that stores the model, customer data, credentials, and access to physical systems. This shifts trust decisions that were previously handled by cloud providers to the customer. Both the model provider and the customer now share risk: the provider’s models run on customer-owned infrastructure, while the customer must protect the systems, data, and models operating in that environment.

What changes with Edge AI?

• Customers operate more of the AI stack.
• AI systems can be influenced by prompts, retrieval data, agent instructions, and runtime inputs.
• Models, credentials, and data can live in environments outside the provider’s direct control.
• Traditional software security controls alone are not enough.

What should organizations do?

• Verify runtimes using attestation.
• Verify AI artifacts using provenance.
• Constrain model actions through mediation.
• Bind and release sensitive assets only to trusted environments.

Our post on threat modeling for AI systems covers safety and security issues related to the underlying model. These concerns apply to Edge AI as well. Edge AI adds another question: before releasing weights, keys, or data, what evidence shows the runtime and loaded components can be trusted?

Why Edge AI increases exposure

An Edge AI deployment may include models, prompts, agents, retrieval data, policies, local data stores, and update mechanisms running on infrastructure outside the provider’s cloud environment.

This moves sensitive AI assets and decision logic into potentially hostile environments. Attackers may have physical access to devices, local access to model artifacts, opportunities to tamper with retrieval data or tool configurations, compromise model supply chain and more direct paths from model behavior to real-world consequences.

Disconnected Edge deployments cannot rely on live cloud detection, policy updates, or revocation. They must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should run only where hardware can protect assets and provide acceptable evidence. Otherwise, the operation should be deferred or revalidated.

Why AI changes the security problem

Unlike conventional software, AI models can be influenced by untrusted content while still using legitimate interfaces and credentials. This article focuses on the security response: architectures that constrain model actions and protect the model, credentials, and data around it.

Traditional software executes code developers ship. AI systems can change behavior based on prompts, retrieval data, agent instructions, and other runtime inputs. Protecting code alone is no longer sufficient; organizations must also establish trust in the data, context, and actions surrounding the model.

• Prompt injection can change model behavior. Assume prompt injection will occur, whether direct or indirect. Inputs can affect systems just like executable code because the context window itself acts as an instruction surface. Traditional controls such as signed binaries and code integrity checks were not designed to address this risk.
• Trusted data is not always safe data. Traditional vulnerability management does not map cleanly to “data as code,” such as a poisoned retrieval document. Origin signatures can prove where data came from, but they do not prove that the content is safe for an AI system to interpret.
• AI behavior is not fully deterministic. The same input may produce different outputs, and small context changes can significantly alter behavior. This limits the effectiveness of techniques such as signature detection and fuzzing. Grounding and tuning improve reliability, but they cannot enforce an acceptable risk boundary. At the authority boundaries it mediates, deterministic policy can still constrain actions when alignment, prompt-injection defenses, or content filters fail to stop an unsafe instruction.

Prompt injection, MCP, multi-agent systems, and computer-use agents on Edge expose different surfaces of these problems. Tool calls are delegated authority, agent output is untrusted input, and screen state is input, not authorization.

These characteristics mean organizations cannot rely on traditional software security controls alone. They also need to verify the environment where AI runs and constrain the actions an AI system is permitted to take.

Constrain model actions through deterministic mediation

Model output should recommend actions, not authorize them. A deterministic mediator outside the model enforces policy by allowlisting actions, scoping arguments, limiting frequency, and releasing credentials only when approved. The mediator is a logical boundary, not another model. It may be provided by the platform or integrated by the customer.

In this pattern, the mediator and its credentials are protected and attested. Mediation bounds what the model can do but does not guarantee that every permitted action is safe; high-consequence or irreversible actions require independent approval, an interlock, or fail-safe behavior.

Establish trust before releasing sensitive assets

Organizations must establish trust in the environment where AI runs and in the artifacts that shape AI behavior. Sensitive assets face two theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before release, the verifier asks two questions:

• Do I trust this runtime and the platform on which I am about to execute this workload?
• Do I trust these components, such as model weights, tool descriptors, agent definitions, and retrieval indexes, because I trust the system in which they were built and delivered?

Attestation answers the runtime question. Provenance answers the component question. Verifier policy requires both. Either question alone leaves a gap: an approved runtime can load a poisoned artifact, while a trusted artifact can run on a compromised platform. In this trust model, the build system that produced an artifact is treated as another runtime whose evidence is evaluated, and the chain continues until it reaches hardware the verifier accepts. Evidence comes from across the hardware, firmware, runtime, model, integration, and customer layers. It serves different relying parties: customers containing model behavior, publishers protecting model IP, and integrators validating the supply chain. The verifier combines that evidence to gate release.

Verify runtime before releasing sensitive assets

This pattern evaluates a runtime by whether it is measurable, can report its state, and matches an approved baseline before sensitive assets are released.

Confidential compute provides one way to do this. Without end-to-end confidential computing, a privileged host or unprotected accelerator path may be able to read or modify decrypted weights, credentials, and data. GPU/NPU drivers and DMA extend the trusted computing base beyond ordinary application-security visibility. Where confidential computing covers that path within the platform’s documented threat model, protected memory and hardware-rooted attestation can support release to an approved runtime. This is designed to protect assets from host access; it does not constrain a steered model’s actions through authorized interfaces. Those vectors need additional controls.

Because system state can change after deployment, release is treated as a renewable lease that expires when fresh evidence no longer matches the approved state. Physical controls address what measurement cannot see.

In this pattern, evidence gates scheduler placement, storage, identity, and credential release. Bind credentials to the approved runtime and action scope to reduce the risk that credential theft enables bulk exfiltration; otherwise, evidence does not enforce trust.

Verify artifacts that shape model behavior

Runtime trust proves only that the platform is acceptable; it does not prove that the artifacts loaded into it are trustworthy. A clean runtime can still execute a poisoned artifact.

That is why artifact trust has to be evaluated separately. Because these artifacts shape model behavior, accepting one into the system is more than data transfer. Creation, distribution, deployment, and use can each introduce a tampered artifact.

Model IP can extend beyond weights to provider-owned components that handle them; those components may warrant the same evidence-gated release.

In this pattern, approved components and updates enter through a trusted build environment; on-site changes appear as measurement drift rather than silently becoming a new baseline.

Each artifact should carry evidence of its origin, build pipeline, and input integrity. The verifier evaluates that evidence before accepting it. Provenance should chain to hardware and be produced inside a measured, policy-approved runtime. Signatures establish origin and integrity but may not show whether the producing runtime met verifier policy. Provenance helps responders reconstruct what happened: which model acted on which data, in what runtime, and under which policy.

Next steps

Bottom line: Edge AI changes the trust model for AI systems. Customers operate more of the stack, AI behavior is influenced by runtime inputs, and sensitive assets run in environments outside the provider’s direct control. Attestation, provenance, mediation, and evidence-based release help establish trust before models, data, and credentials are exposed.

Edge AI pushes security controls into devices, gateways, vehicles, factories, hospitals, retail spaces, and other customer environments.

For depth on the agent case, see our post on defense in depth for autonomous AI agents. Map sensitive assets, the runtimes and artifacts that can access them, and the party responsible for each release decision. Then define the evidence and policy required at every boundary. At the Edge, security should be architectural: anchored at hardware, enforced at every action.

The post How to secure edge AI in customer-owned environments appeared first on Microsoft Security Blog.

Microsoft researchers observed a high-volume phishing campaign using invisible Unicode tag characters, a technique popularized in AI prompt injection research as ASCII Smuggling. Instead of using these characters to hide instructions from people while exposing them to AI models, the attacker used them to split financial lure words such as ‘funding’ to prevent email filters from parsing them.

The finding emerged from Microsoft Defender for Office 365 prompt injection protection research, showing how AI-era evasion techniques can surface in traditional phishing campaigns. In Microsoft telemetry, hits on a hunting signature designed to detect ASCII-smuggling increased sharply beginning February 9, 2026, and remained elevated on weekdays for approximately three months. Microsoft Defender for Office 365 telemetry showed that the majority of messages were flagged by layered protections rather than by reliance on a single Unicode-specific signal.

What is ASCII smuggling?

“ASCII smuggling” refers to the use of invisible or non-rendering Unicode characters to hide content inside text that looks normal. The most abused range is the Unicode Tags block, U+E0000 to U+E007F. This block contains a shadow copy of the printable ASCII characters (for example, U+E0041 mirrors ‘A’, U+E0061 mirrors ‘a’). The block was originally intended for language tagging and is now largely deprecated.

The important property for an attacker is this: most of these code points are not rendered by typical fonts and user interfaces. A string can therefore carry a message that is not readable to a human but will be processed by any language model or other software that receives a copy of the email content.

Why the AI-security world made it famous

Over the past year, ASCII smuggling became a recurring technique in the prompt injection and cross-prompt injection (XPIA) literature. The attack pattern is straightforward:

1. An attacker hides instructions inside invisible tag characters embedded in a web page, document, email, or other content.
2. A human (and many user interfaces) sees nothing unusual.
3. An AI assistant that ingests the raw text does “see” the hidden characters, decodes them as text, and may be induced to follow threat actor-controlled instructions, potentially including data exposure or unauthorized actions depending on the assistant’s permissions and safeguards.

Because this technique cleanly demonstrates the gap between what the human sees and what the model reads, it appeared frequently in AI red-teaming write-ups, conference talks, and tooling throughout 2025. That attention put a spotlight on the U+E0000-U+E007F range.

Because tag characters are invisible to humans but exist at the text-processing level, the same property that makes them useful for smuggling instructions into a model also makes them useful for obfuscating keywords before a detector evaluates them. The intent is inverted, but the mechanism is similar and a user’s suspicions are not raised.

Writing a practical ASCII-smuggling signature

As part of work on Microsoft Defender for Office 365 prompt injection protection, we built hunting logic for email-borne XPIA and prompt obfuscation patterns: content that looks harmless to users but may carry hidden instructions for an AI system that ingests the raw message. The same hunt designed to identify prompt injection risk in email became the starting point for this phishing-evasion discovery.

One practical way to hunt for ASCII smuggling is to look for messages carrying characters from the Unicode tags block (U+E0000-U+E007F), the hallmark of attempts to hide instructions from, or for, an AI model. That broad signature is a useful starting point, but it needs enough Unicode context to avoid mistaking legitimate tag-character sequences for abuse.

The first version simply flagged any code point in that range, which proved too blunt. It kept firing on a small subset of perfectly legitimate messages – which, on inspection, all contained one of three subdivision flag emojis: the flags of England, Scotland, and Wales – because those emojis are encoded using tag characters.

After those exclusions, remaining hits were mostly benign artifacts from email-security gateways, mailbox providers, and security or AI researchers forwarding or testing messages that contained tag characters. This provided a good baseline where any spikes would indicate abuse of this technique by attackers.

Figure 1. The three subdivision flag emojis – England, Scotland, and Wales – that tripped the naive signature. Each is encoded as a sequence of invisible Unicode tag characters (U+E0000-U+E007F).

Figure 2. The Wales flag emoji pasted into the ASCII Smuggler tool from Embrace The Red. What renders as a single flag is actually a base flag code point (U+1F3F4) followed by an invisible tag-character sequence spelling gbwls (U+E0067 U+E0062 U+E0077 U+E006C U+E0073) and a terminating tag (U+E007F) – the same U+E0000-U+E007F range the signature watches for.

What we observed: ASCII smuggling repurposed for phishing

New activity emerges in telemetry

The tuned ASCII-smuggling signature began as an AI-security hunt for hidden prompt injection content in email. Instead, it surfaced finance-themed phishing messages using the same Unicode range for filter evasion.

On February 9, 2026, signature hits increased sharply. The following chart reflects Microsoft Defender for Office 365 telemetry for the hunting signature over the measured period:

The day before onset (February 8) the signature fired on roughly 21,000 messages; the next day it fired on more than 1.3 million. Most of the emails can be formed into a cluster of roughly 150 finance-themed sender domains.

Observed over three months with a weekly rhythm

Continuing to track the clustered sender domains forward in time, we measured messages matching the activity described every day. The high-volume phase persisted for roughly three months after February 9 and dropped sharply after May 15, 2026. These dates bound the observed use of the specific technique in our telemetry, not the broader campaign, which started earlier without it and continued without it.

Two characteristics stand out:

• A strict weekly cadence. The campaign ran hard on weekdays and went almost completely silent every weekend. Sundays’ volume collapsed to a near-zero and then back to full volume the next day. This on/off pattern is typical of scheduled bulk-sending infrastructure.
• A long, gradual decline. After an intense first phase, with weekday volumes of 1 to 2.37 million messages, peaking on February 26, the numbers stepped down slowly to roughly 80% less per weekday by late March. The high-volume usage of the technique dropped sharply after May 15, with lower residual activity through mid-June and occasional smaller spikes.

After identifying the activity through this technique-specific signal, we connected it to a broader ActiveCampaign-delivered SBA-themed phishing campaign that Fortra had documented earlier. That earlier reporting indicates the campaign predated the adoption of Unicode tag characters; our analysis focuses on the period and messages in which this method was present, not the full lifetime of the broader campaign.

Not instruction smuggling, but filter evasion

Observed obfuscation pattern

When we looked at a sampling of the flagged messages, the surprise was there were no smuggled instructions to an AI assistant. Instead, the invisible tag characters were inserted inside common financial keywords, splitting them apart so that a literal signature or keyword match would fail.

For example, a finance lure term that appeared normal to the recipient could be transmitted with an invisible tag character in the middle:

funding

became:

fun⟨U+E0020⟩ding

Here, ⟨U+E0020⟩ represents the invisible Unicode TAG SPACE inserted between letters. In the messages we examined, the campaign did not encode a hidden ASCII message in the tag block; it used a single invisible tag character as a separator sprinkled inside high-signal words. Strictly speaking, this is invisible-character insertion using a code point from the ASCII-smuggling tag block, rather than full message smuggling.

Why it can affect detection

To a recipient, and to parsing pipelines that drop or normalize these characters, the word still reads as funding. To a detector matching the literal string funding, or a regex that does not account for interleaved invisible code points, the byte sequence no longer contains the contiguous keyword. Whether real-world detectors behave that way depends on their normalization step, which is examined below.

The bigger prize for the attacker, though, is not preventing the literal string matches; it is the ML- and NLP-based models that increasingly drive modern spam and phishing classification. Unless a filtering system takes a picture of a message and does OCR extraction over the visual image, it may miss this type of attack. A standard email classifier may not reason over whole words exactly as a human sees them; for efficiency, they can first split text into tokens or sub-word pieces. A clean lure term such as funding may be represented as a familiar token or a familiar sequence of sub-tokens. Insert an invisible U+E0020 into the middle, however, and the tokenizer may no longer see that same familiar unit. It might split the text into fun, an unexpected tag character, and ding; it might emit rare or unknown sub-tokens; or, if normalization runs first, it simply removes the U+E0020 character, leaving funding.

Why it can help defenders

There is also a defensive opportunity. Since this kind of manipulation appears so seldom in normal traffic, its presence becomes a high-confidence signal. A technique meant to make messages look more benign to ML models can instead give defenders a low-false-positive indicator to detect on.

What is known and what is new

Inserting invisible or look-alike characters to break keyword and signature matching is a long-standing evasion technique used in spam and phishing: defenders have for years seen zero-width spaces (U+200B), zero-width non-joiners, the no-break space (U+00A0), soft hyphens, and homoglyph substitutions used to fracture words so naive string matchers fail.

What is new is the specific characters and scale of the campaign:

• The character choice. Instead of the usual zero-width space or NBSP, this campaign reached for the Unicode Tags block. That block went from forgotten to famous over the past year because of AI security research into ASCII smuggling and prompt injections.
• The scale and discipline. At its peak in Microsoft telemetry, the campaign generated multi-million message daily volume.
• A possible detection blind spot. Because the Unicode Tags block is less commonly abused than zero-width spaces or NBSP, defenders should verify that normalization and tokenization pipelines handle tag characters consistently.

Financially themed sending domains

The campaign ran on hundreds of disposable, finance-themed sender domains with lures that resembled business loan, line-of-credit, and advance-funding phishing patterns often associated with fraud or credential-harvesting funnels. This pattern accounted for roughly 96% of the volume flagged by the hunting signature. The signature also fired on other domains, but those were unrelated senders – chiefly email-security gateways and personal mailbox providers – not part of the campaign.

A partial sample of sender domains counts from February 9, 2026 alone illustrates both the naming pattern and the per-domain volume:

Table 1. Top 20 (by signature hits) of the 148 finance-themed campaign sender domains seen on February 9, 2026, illustrating the naming convention and per-domain volume.

Every domain is just a recombination of the same small vocabulary. The 20 domains above are built from only 28 word-tokens:

advance · boost · business · capital · catalyst · choice · digital · direct · elevate · express · finance · funding · growth · guardian · harbor · loan · loans · loc · online · our · pulse · rocket · rush · the · united · wave · way · your

Sent through a legitimate email-marketing platform

The finance-themed domains in Table 1 are the brand (header / P2) domains the recipient sees, but the actual mail was relayed through infrastructure associated with the legitimate email-marketing platform ActiveCampaign. The platform, which is used widely for marketing, rewrites every outbound link in the message body to route through its own click-tracking domains (acemlnd[.]com and activehosted[.]com), so the URLs the recipient clicks do not point at the brand domain at all – they look like:

hxxps://＜account-id＞.acemlnd[.]com/＜tracking-token＞
hxxps://＜brand-subdomain＞.activehosted[.]com/＜tracking-token＞

Most of the flagged messages carried links associated with the platform’s tracking domains rather than direct links that point directly to the sender-branded domains. The envelope (P1) senders were platform subdomains of the form em-<id>.<brand-domain>.

ActiveCampaign response

Before we published this information, we shared our findings with ActiveCampaign to help them with this abuse, and they wanted us to share the following statement on their work to detect it:

“We appreciate Microsoft’s research and welcome collaboration with the security community to combat this activity. We take abuse, fraud, and security extremely seriously. We tested the specific technique described in this research against our content-moderation systems: messages containing invisible Unicode characters receive the same moderation verdicts as their unobfuscated equivalents, and heavy use of the technique is itself treated as a suspicious signal. We continually invest in improving our detection and prevention capabilities, including expanding our use of AI and machine learning to identify abusive sending behavior earlier in the account lifecycle.” — ActiveCampaign spokesperson

As with any shared sending service, attacker abuse of customer accounts or workflows can complicate reputation-based filtering. By originating from a reputable marketing platform with established IP reputation and authentication, the activity may appear more similar to legitimate marketing traffic and can complicate reputation-based filtering.

Most observed volume also originated from cloud-hosting ranges consistent with the platform’s outbound infrastructure, with the vast majority coming froma single network block, 173.236.20[.]0/24. This indicator helped us cluster the campaign more precisely but note that this is a legitimate segment that belongs to the abused service, and not an IOC on its own.

Identifying the campaign

Content and infrastructure remained consistent for a long time span, providing an effective way to easily fingerprint this phase of the campaign:

• Unicode content (primary). Invisible Unicode tag characters in the range U+E0000-U+E007F – specifically U+E0020 – spliced inside keywords. Legitimate mail rarely ever carries these code points: the one routine exception, the England/Scotland/Wales flag emojis, is easily excluded.
• Lure and brand pattern. Sender (header / P2) domains assembled from a small finance vocabulary – capital, fund/funding, loan, loc, lend, finance, business, express, growth, solutions, choice, hedge, pillar – recombined into fresh, disposable domains and rotated.
• Envelope (P1) pattern. The bulk of mail is relayed through a single email-marketing platform, recognizable by envelope shape rather than any one name:
  • per-account subdomains shaped em-<digits>.<brand-domain> (regex em-\d+\.), where a small set of reused account numbers fans out across hundreds of brand domains; and
  • the platform’s shared sending pool, shaped acems<N>[.]com and emsd<N>[.]com (e.g. emsd4[.]com, s9.acems10[.]com). Across the measured activity, ~98.5% of messages matched this envelope pattern, and ~99.8% matched the envelope pattern or the platform’s tracking-URL pattern (below).
• Tracking-URL pattern. Click/tracking links on the platform’s domains activehosted[.]com and acemlnd[.]com.
• Sending-origin pattern. The bulk of daily volume – about 92% across two measured weeks – originated from a single /24 network block, 173.236.20[.]0/24.

For a high-precision rule, look for the Unicode content pattern combined with the finance-brand pattern, using the sender infrastructure patterns as corroboration.

However, this is just a phase in a long-running broader campaign, that keeps adapting and evolving. The campaign was observed months earlier following a different set of behaviors and continued even after the usage of the specific technique was dropped. During these shifts in behavior, one signature may no longer describe the campaign, while another still matches.

Is there a detection gap?

The potential gap for mail-defense pipelines is whether Unicode tag characters are normalized or flagged before content detections run. In Defender, our filter stack can take a picture of message contents, extract visible text through OCR, and run analysis over that extracted text to avoid these types of tricks. Implementations vary, so defenders should test how these characters are handled in their own pipelines. For MDO protection, over 99% of messages were flagged by layers that did not depend on catching the tag characters directly, including sender, IP, URL and domain reputations, ML spam/phishing classification, brand-impersonation detection, authentication checks and more.

Emerging techniques don’t stay in one domain

ASCII smuggling earned its reputation as an AI attack, hiding instructions from people while leaving them visible to models. This campaign shows the same technique being repurposed for a different objective: obscuring phishing content from detection systems while remaining readable to the intended target.

The broader lesson is that security techniques rarely stay confined to a single domain. As AI-era attack methods become better understood, threat actors may adapt them for use in more traditional threats such as phishing and spam. This case illustrates how techniques that emerge in AI security research can quickly cross over into established attack ecosystems, reinforcing the need for defenders to view emerging threats through a cross-domain lens.

Mitigation and protection guidance

The core defensive principle is simple: normalize before you match. Any content that will be evaluated by keyword, signature, or regex logic should first have invisible and non-rendering Unicode code points stripped or folded, so that splicing them into a word no longer defeats the match.

Recommended controls

• Strip or normalize Unicode tag characters (U+E0000-U+E007F) – and other zero-width / invisible code points – from email subject and body text before applying spam and phishing content signatures.
• Treat the presence of tag-block characters as a strong anomaly signal. Outside known legitimate tag-sequence uses such as certain subdivision flag emojis, these code points are rare in ordinary mail and can be a high-value anomaly signal.
• Look for the behavioral fingerprint. The observed activity had a distinctive shape: bulk volume from churning, finance-themed disposable domains, on a strict weekday-on / weekend-off schedule. A sudden spike of tag-block characters concentrated on finance-themed senders, switching on and off weekly, is a high-confidence campaign indicator.
• Apply the same normalization upstream of AI ingestion. The same control that defeats this evasion also reduces XPIA / ASCII-smuggling exposure for AI assistants that ingest email content.

Microsoft protections

Microsoft Defender for Office 365 has heuristic detections in place to flag these the tactics employed in this type of campaign. The detection that first surfaced the spike continues to flag messages carrying Unicode tag-block characters, and the financially themed sending domains are being tracked and blocked as they rotate. Microsoft uses layered email protections, including standard and OCR content analysis, sender and domain reputation, URL detonation and reputation, bulk-mail detection, and anti-phishing models, to reduce reliance on any single signal that an attacker can try to evade.

Microsoft Defender for Office 365 prompt injection protection further helps protect against emails that contain prompt injection attempts, including cases where invisible characters are used to hide instructions from users while exposing them to AI systems. The same normalization and detection principles that reduce ASCII-smuggling-based prompt injection risk also help blunt this email-borne reuse of the technique for phishing evasion. Investments in AI security and traditional email security increasingly reinforce one another.

Coverage depends on product licensing, configuration, and telemetry.

Advanced hunting

These queries run against the EmailEvents Advanced Hunting table (and EmailUrlInfo for URL joins). They hunt the campaign by its infrastructure fingerprint – the finance-vocabulary brand senders and the marketing-platform envelope shape – rather than by the invisible tag characters, as the mail body is not exposed through the table’s columns. These queries are starting points and may require environment-specific tuning. The proactive defense is implemented with multiple layers of the enterprise mail-filtering pipeline.

1. Infrastructure pattern – finance-vocabulary senders relayed with the campaign’s envelope shape. Combines the brand-domain pattern (a header sender built from three or more adjacent finance/brand keywords, e.g. digital+capital+boost) with the envelope (MAIL FROM) shape em-<digits> / acems<digits> / emsd<digits> – the durable fingerprint that held across the entire period we measured.

// Finance/brand vocabulary the operator recombines into disposable domains.
let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
// Header sender domain made of 3 or more adjacent finance/brand tokens.
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
// Envelope (MAIL FROM) shape: em-[digits] | acems[digits] | emsd[digits].
| where SenderMailFromDomain matches regex @"(?i)(em-|acems|emsd)\d"
| sort by Timestamp desc

For extra corroboration you can scope to the single dominant /24 that carried the bulk of this campaign’s volume, 173.236.20[.]0/24, by adding | where ipv4_is_in_range(SenderIPv4, “173.236.20.0/24”). Like the tracking URLs, that network block is shared platform space (it also carries unrelated legitimate newsletters), so use it to scope, never as a standalone filter.

2. Pivot on the platform tracking URLs. Start from the click/tracking links and join back to the mail events. Useful for scoping, but treat it as corroboration, not a verdict: the tracking domains activehosted[.]com and acemlnd[.]com are shared by every legitimate customer of the same marketing platform, so the URL on its own is not a malicious indicator. The finance-brand filter is what keeps this on the campaign; drop it only if you deliberately want a wider search.

let kwds = @"(capital|fund|hedge|express|solutions|choice|lend|growth|loan|loc|finance|business|pillar|advance|boost|catalyst|digital|direct|elevate|guardian|harbor|online|pulse|rocket|rush|united|wave|way|surge|swift|elite)";
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where SenderFromDomain matches regex strcat("(?i)", kwds, kwds, kwds)
| join kind=inner (
    EmailUrlInfo
    | where Timestamp > ago(30d)
    | where UrlDomain endswith "activehosted.com" or UrlDomain endswith "acemlnd.com"
    | distinct NetworkMessageId
  ) on NetworkMessageId 
| sort by Timestamp desc

3. Filter for prompt injection detection in emails

The feature used in the query below is available for Microsoft Defender for Office 365 Plan 2 or Microsoft 365 E5 customers.

EmailEvents
| where DetectionMethods has "Prompt Injection Protection"

MITRE ATT&CK techniques observed

This campaign exhibits the following MITRE ATT&CK® techniques. The table includes MITRE ATT&CK for phishing/evasion behavior and MITRE ATLAS for the AI-security technique class related to prompt obfuscation.

Indicators and hunting pivots

References

• Unicode Standard Annex #45 – Tags (U+E0000-U+E007F) – the deprecated Unicode tags block abused for ASCII smuggling
• ASCII Smuggler Tool: Crafting Invisible Text and Decoding Hidden Codes | Embrace The Red – public write-up showing how Unicode tag characters can hide text from users while remaining present to language models
• LLM Prompt Obfuscation | MITRE ATLAS™ – the AI-security technique class this evasion crossed over from
• Attackers exploit ActiveCampaign to deliver thousands of AI-generated SBA phish | Fortra – earlier reporting on the broader ActiveCampaign-delivered SBA-themed phishing campaign, before the Unicode tag-character evolution examined here

Learn More

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

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

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

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

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

• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog

The post ASCII smuggling crosses over from AI prompt injection to phishing evasion appeared first on Microsoft Security Blog.

Microsoft Threat Intelligence has observed a human-operated intrusion campaign that abuses Microsoft Teams external collaboration to impersonate IT or helpdesk personnel and socially engineer users into granting an interactive remote session. Once remote control is established via RMM tools, the threat actor uses PowerShell to download and silently install a malicious MSI package, which in turn stages a portable Node.js runtime and an obfuscated JavaScript implant that provides persistent command execution and command and control (C2).

Unlike commodity phishing that ends with an infostealer, this campaign follows a full hands-on-keyboard playbook. After the implant is deployed, the threat actor performs extensive host and Active Directory reconnaissance, periodically captures screenshots of the victim’s desktop, executes follow-on payloads through trusted Windows binaries, and pivots across the enterprise over Windows Remote Management (WinRM) toward high-value assets such as domain controllers. The intrusion relies heavily on legitimate tooling, including Microsoft Teams, remote support software, Windows Installer, Node.js, and native administrative protocols, allowing the activity to blend into expected enterprise operations at nearly every stage.

This intrusion pattern is especially high-impact because it hands an external operator credential-backed, interactive access to internal infrastructure. The reconnaissance and lateral movement patterns observed: domain enumeration, server discovery, and WinRM pivoting toward identity systems, are consistent with intrusion activity that can precede data theft, extortion, ransomware deployment, or other follow-on objectives, in which threat actors map the environment, escalate privileges, disable security controls, exfiltrate business-relevant data, and ultimately deploy ransomware across the organization.

In this blog, we share our analysis of this attack chain, from initial Microsoft Teams contact through internal lateral movement, along with mitigation and hunting guidance to help defenders detect and disrupt this user-initiated access pathway before it escalates into broader compromise.

Risk to enterprise environments

By abusing enterprise collaboration workflows instead of traditional email-based phishing, the threat actor initiates contact through Microsoft Teams in a way that appears consistent with routine IT support. Microsoft Teams applies multiple security controls at the point of first external contact, including external tenant labeling, Accept/Block prompts, message previews, and phishing indicators, but this attack chain depends on convincing the user to bypass those warnings and voluntarily grant remote access through legitimate support tools.

An approved external Teams interaction, followed by a remote session, can enable the threat actor to:

• Establish interactive, credential-backed system access through a legitimate remote support tool.
• Execute threat actor-controlled code (MSI loader and Node.js implant) using trusted installers and runtimes.
• Map the host and Active Directory environment through automated discovery
• Move laterally toward high-value infrastructure using WinRM.
• Capture on-screen activity and create opportunities for follow-on data access or other post-compromise actions.

Attack chain overview

The campaign follows a multi-stage attack chain that progresses from social engineering through payload delivery, execution, reconnaissance, and ultimately lateral movement:

1. Initial access via Teams (T1566.003): A threat actor operating from an external tenant initiates a Teams chat or call while impersonating IT/helpdesk staff and coaxes the user into handing over their device, for example, approving a “request control” prompt during a Teams screen-share, or opening Quick Assist and reading back the connection code.
2. Remote session and MSI delivery: During the remote session, the threat actor runs PowerShell to download a malicious MSI from cloud storage and installs it silently with msiexec.

3. Node.js runtime and implant staging: The MSI installs a script-based loader and a separate encrypted implant file under LocalAppData. If Node.js is not already available, the bootstrap downloads the legitimate portable Node.js runtime from the official distribution. The loader decrypts the implant at runtime, either in memory or into a temporary JavaScript file.
4. Script-based bootstrap and Node.js execution:The MSI launches hidden bootstrap code through trusted Windows script hosts, including PowerShell, cmd.exe, and WScript. The bootstrap obtains a portable Node.js runtime and uses it to decrypt and execute the JavaScript implant from a user-writable directory.
5. Command-and-control and operator tasking:The implant uses randomized HTTPS polling to receive JavaScript tasks from its C2 server. Observed operator-issued tasking performed host reconnaissance, security-product and virtualization discovery, and periodic desktop screen capture.
6. Domain discovery: The operator enumerates domain accounts, servers, and users through native tools and Active Directory Service Interfaces (ADSI) queries.
7. Follow-on payload execution: Additional payloads are executed through rundll32 loading threat actor-supplied DLLs.
8. Lateral movement via WinRM:Operator-issued tasking executed through the Node.js backdoor initiates WinRM connections over TCP port 5985 to domain-joined systems, including domain controllers and certificate authorities.

Stage 1: Initial contact via Teams (T1566.003 Spearphishing via Service)

The intrusion begins with abuse of external collaboration features in Microsoft Teams, where a threat actor operating from a separate tenant initiates contact while impersonating internal IT or helpdesk personnel. This activity does not stem from a weakness in Microsoft Teams or its built-in protections; instead, the threat actor abuses legitimate collaboration features by persuading the user to override clearly presented security warnings, highlighting the broader challenge of defending against social engineering rather than technical exploitation.

Because interaction occurs within an enterprise collaboration platform rather than through traditional email, it could bypass the initial skepticism associated with unsolicited external communication. The lure varies, for example “Microsoft Security Update,” “Spam Filter Update,” “Account Verification,” or tasks required to stop deactivation of an account, but the objective is consistent: convince the user to ignore external-contact flags, launch a remote management session, and accept elevation. Voice phishing (vishing) is sometimes layered to increase trust or compliance, or so malicious instructions or URLs never enter the chat logs.

With user consent obtained through social engineering, the threat actor gains interactive control of the device using a remote support tool. From the user’s perspective, they are guided to open the remote-assistance application, enter a short key, and follow prompts to grant access.

The urgency and interactivity are the signal: a remote-assist process tree followed immediately by cmd.exe or PowerShell on the same desktop. In vishing scenarios, the threat actor might talk the victim through the process to prevent logging of malicious instructions.

Stage 2: Remote session and malicious MSI delivery

Immediately after establishing control, the threat actor uses PowerShell within the remote session to download a malicious MSI package from threat actor-controlled cloud storage and installs it silently. The installer is disguised with benign, update-themed names such as “devfix” or “Hotfix,” reinforcing the helpdesk pretext.

The payload is hosted on a widely used cloud storage platform, allowing the download to blend in with legitimate traffic and benefit from a trusted domain reputation. The /qn switch suppresses all installer UI so the victim sees no indication that software is being installed.

Stage 3: MSI staging and Node.js runtime acquisition

Upon installation, the MSI retrieves a portable Node.js runtime directly from the official Node.js distribution and extracts it into a randomly named directory under the user’s local application data. Downloading a legitimate, signed runtime from a trusted source lets the threat actor run a full JavaScript execution environment without deploying custom binaries that might attract scrutiny.

The MSI installs a script-based loader and a separate encrypted implant file in the current user’s LocalAppData directory. The encrypted implant is packaged within the MSI rather than downloaded separately. At runtime, the loader decrypts the JavaScript implant either in memory or into a temporary JavaScript file. This separation of a legitimate runtime from the malicious script allows the initial backdoor to execute as interpreted JavaScript while additional native payloads can be delivered later through operator tasking.

Stage 4: Script-based bootstrap and encrypted implant execution

The MSI schedules a deferred, asynchronous custom action immediately after installing its files. The action starts hidden bootstrap code through PowerShell, cmd.exe, or WScript and then launches Node.js from LocalAppData. The loader decrypts a separate high-entropy data file and executes the resulting JavaScript either through standard input or by loading a temporary JavaScript file.

Endpoint activity shows Node.js, or a renamed copy whose original file metadata identifies it as Node.js, executing a staged script loader from LocalAppData. The loaders and encrypted payload files use nonstandard extensions such as .tmp, .ini, .dat, .bin, or .cfg. After decrypting the payload, the loader either provides JavaScript to Node.js through standard input or writes a temporary .js file and loads it into the running Node process.

By using a signed Node.js runtime, including renamed copies of the runtime, to execute nonstandard-extension loaders or JavaScript supplied through standard input, the threat actor can evade controls focused only on unsigned executables and conventional script extensions.

Stage 5: Per-user persistence

The analyzed MSI packages established per-user persistence using update-themed entries. Observed installers created either an HKEY_CURRENT_USER Run value or a shortcut in the current user’s Startup folder. Both mechanisms used the name EdgeUpdate and launched a Node.js loader from LocalAppData when the user signed in.

The Startup-folder implementation launched WScript with the staged JScript wrapper, portable Node.js runtime, and nonstandard-extension loader. The Run-key implementation invoked the portable Node.js runtime directly.

Stage 6: Command-and-control and operator tasking

Once running, the implant establishes communication with its C2 server and begins receiving JavaScript tasking. Observed threat actor issued tasks launched short-lived cmd.exe and PowerShell processes to perform a burst of host reconnaissance, hardware and locale details, installed antivirus products, and disk information.

The querying of the display adapter name and installed antivirus is characteristic of sandbox and defense evasion checks. Generic virtual display adapters and analysis tooling are common tells of an automated analysis environment.

The recovered implant communicates through randomized HTTPS long-polling requests. Responses from the C2 server are treated as JavaScript source and executed dynamically with access to Node.js module loading, process execution, environment variables, buffers, and the file system.

Through JavaScript tasking delivered by the C2 server, operators repeatedly captured the victim’s screen, resized the image, encoded it as Base64, and wrote it to a temporary file before exfiltration. Screenshots are captured at varying scale factors to balance image quality against transfer size.

Dormant blockchain-based C2 discovery

The analyzed implants also contained dormant logic capable of querying an Ethereum smart contract for an updated C2 URL. This functionality was disabled in the recovered builds, which instead used a hard-coded fallback server. The contract stores only a URL string and does not contain or execute the malware payload.

Stage 7: Domain discovery and reconnaissance

With a foothold validated, the operator uses C2-delivered tasking to expand reconnaissance into Active Directory. Native commands enumerate specific domain accounts, while ADSI searches identify domain-joined servers and collect user description attributes, which can contain operational notes, privileged-account context, or other sensitive information.

An ADSI-based sweep enumerates Windows Server computer objects, resolves their addresses, and probes each for administrative reachability, effectively building a live map of high-value targets:

A second ADSI query enumerates all user objects and their description attributes:

The use of randomized sleep jitter and CIM-based reachability checks indicates a deliberate, operator-driven effort to enumerate the domain quietly rather than through noisy, high-volume scanning.

Stage 8: Follow-on payload execution

Using commands delivered through the Node.js backdoor, the operator executes additional payloads through rundll32.exe, loading threat actor-supplied DLLs by invoking exported functions with a token argument. Using rundll32 to execute malicious DLL exports is a well-established defense-evasion and proxy-execution technique.

The DLLs are given short, innocuous names and are invoked with an exported function (open) and a per-execution token, consistent with modular loaders that gate execution behind a runtime-supplied key.

Stage 9: Lateral movement via WinRM toward high-value assets

Following local execution and discovery, operator-issued tasking executed through the Node.js backdoor initiated internal remote-management connections over WinRM on TCP port 5985 to a large set of domain-joined systems. The target list spans dozens of hosts across multiple regions and roles, including file servers, database and application servers, and, critically, domain controllers and certificate authorities.

The use of WinRM from a non-administrative application context strongly suggests credential-backed lateral movement directed by an external operator. Targeting identity-centric infrastructure, domain controllers and certificate authorities, at this stage reflects a shift from initial foothold toward broader enterprise control, and is a hallmark of intrusions that precede large-scale data theft or ransomware deployment.

Mitigation and response recommendations

This campaign relies less on platform exploitation and more on persuading users to initiate trusted remote-access workflows within legitimate collaboration tools. Organizations should treat any unsolicited external support contact as inherently suspicious and implement layered defenses across the identity, endpoint, and collaboration layers.

• Reinforce user education. Establish internal helpdesk authentication phrases and train employees to recognize external-tenant indicators and to never grant remote access or run commands provided by an unsolicited contact.
• Verify unsolicited support contact. Treat any unsolicited external Microsoft Teams chat or call claiming to be IT or helpdesk as suspicious, and verify the request through a known internal channel before granting remote access. Restrict Teams external access to trusted domains only.

• Harden Microsoft Teams and email against social engineering. Use Microsoft Defender for Office 365 with Safe Links and Zero-hour auto purge (ZAP) so malicious messages and URLs are neutralized at time of click and removed after delivery.
• Microsoft Teams: Apply the Security best practices for Microsoft Teams, revisit your external collaboration policies, and make sure users see clear external sender notifications when engaging with cross-tenant contacts. Require device- or identity-based access checks before any remote support session is granted.
• Enforce phishing-resistant access controls. Require MFA and compliant or managed devices through Microsoft Entra Conditional Access to limit the value of credential-backed remote sessions established through social engineering.
• Deploy attack surface reduction rules. Enable ASR rules that block executable content from email and scripting interpreters, process creation from PowerShell/WScript/cmd, and execution of downloaded content to disrupt MSI- and script-based staging.
• Restrict administrative protocols. Limit WinRM (TCP 5985) to authorized management workstations and alert on WinRM initiated from user-context or non-administrative processes.
• Turn on network and web protection. Enable network protection and web protection in Microsoft Defender for Endpoint to block connections to threat actor infrastructure and cloud-hosted staging endpoints used for payload delivery and C2.
• Enable cloud-delivered protection. Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving threat actor tooling; cloud-based machine learning helps detect and block newly observed threats.
• Control remote support tooling. Limit or monitor remote monitoring and management (RMM) and interactive remote-support software, and control which remote-assistance tools are permitted in the environment.
• Investigate and rotate credentials. Organizations that find indicators of this campaign should assume the operator obtained network-level access through the compromised host and prioritize credential rotation for any credentials accessible from the affected machine, including domain admin accounts if the host was domain-joined.

Microsoft Defender XDR detections

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps. The representative alerts below can surface activity associated with this campaign. Alert titles are illustrative and may vary by environment and product version.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate investigation and response tasks related to this threat. Useful promptbooks for this activity include Incident investigation, Microsoft User analysis, Threat actor profile, Threat intelligence 360 report, and Vulnerability impact assessment. Some promptbooks require access to Microsoft Defender XDR, Microsoft Sentinel, or related Microsoft security plugins.

For this campaign, Security Copilot can help analysts summarize affected devices where Node.js or a renamed Node.js runtime executed a staged loader from a user-writable path, reconstruct the Teams-to-remote-session-to-MSI delivery chain, and build containment and credential-rotation plans for affected domain-joined endpoints.

Threat intelligence reports

Microsoft customers can use Microsoft Defender XDR Threat Analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this campaign.

For campaign-specific intelligence, see Threat Analytics: Teams-based helpdesk impersonation delivers MSI loader and Node.js implant for hands-on-keyboard intrusion (View report). These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in their environments.

Advanced hunting queries

Microsoft Defender XDR customers can run the following advanced hunting queries to locate related activity. Tune time windows, tool lists, and filters for your environment.

External Teams activity

Sender, Recipient, and ThreadId can be used for pivoting other useful information. CloudAppEvents is useful for searching first contact information.

CloudAppEvents
| where Timestamp > ago(7d)
// optional time filters between ([_startTime] .. [_endTime])
| where Application == "Microsoft Teams"
| where ActionType == "ChatCreated"
| where IsExternalUser == true
| extend ThreadCreatorUpn = tostring(RawEventData.Members[0].UPN)
    ,ThreadCreatorDisplayName = tostring(RawEventData.Members[0].DisplayName)
    ,ThreadCreatorOrganizationId = tostring(RawEventData.Members[0].OrganizationId)
    ,TRecipient1Upn = tostring(RawEventData.Members[1].UPN)
    ,Recipient1DisplayName = tostring(RawEventData.Members[1].DisplayName)
    ,Recipient1OrganizationId = tostring(RawEventData.Members[1].OrganizationId)
    ,Recipient2Upn = tostring(RawEventData.Members[2].UPN)
    ,Recipient2DisplayName = tostring(RawEventData.Members[2].DisplayName)
    ,Recipient2OrganizationId = tostring(RawEventData.Members[2].OrganizationId)
    ,ThreadId = tostring(RawEventData.ChatThreadId)
| summarize by ThreadCreatorUpn, ThreadCreatorDisplayName, ThreadCreatorOrganizationId,
    TRecipient1Upn, Recipient1DisplayName, Recipient1OrganizationId,
    Recipient2Upn, Recipient2DisplayName, Recipient2OrganizationId,
    ThreadId, tostring(IsExternalUser), tostring(IsImpersonated)

MessageEvents, CallActivityEvents, MessageUrlInfo, and others can be searched alone or in a union to correlate threads with messages and calls.

let _threadIds = pack_array(
      "19:[thread]",
      "19:[thread]",
      "19:[thread]");
union
    MessageEvents,
    CallActivityEvents,
    MessageUrlInfo
    | where ThreadId in (_threadIds)
       or TeamsMessageId has_any (_threadIds)
    | sort by ThreadId, TeamsMessageId asc

PowerShell writing an MSI to a user-writable path

DeviceFileEvents 
| where Timestamp > ago(7d) 
| where InitiatingProcessParentFileName =~ "explorer.exe" 
| where InitiatingProcessFileName =~ "powershell.exe" 
| where FileName endswith ".msi" 
 where
    FolderPath contains @"\Downloads\"
    or FolderPath contains @"\AppData\"
    or FolderPath contains @"\Temp\"

node.exe executing a staged payload from user-writable paths

DeviceProcessEvents 
| where Timestamp > ago(7d) 
| where FileName =~ "node.exe" 
| where ProcessCommandLine has @"\AppData\Local\" and ProcessCommandLine !contains ".js" 
| where InitiatingProcessFileName =~ "wscript.exe" 
| where InitiatingProcessCommandLine has_all (@"\AppData\Local\", "node.exe", ".js") 

Screen capture via hidden PowerShell writing Base64 to a temp file

DeviceProcessEvents 
| where Timestamp > ago(7d) 
| where InitiatingProcessParentFileName =~ "node.exe" or InitiatingProcessFileName =~ "node.exe" 
| where FileName in~ ("powershell.exe", "cmd.exe") 
| where ProcessCommandLine has_all ("CopyFromScreen", "ToBase64String", "System.Drawing.Bitmap", "System.Drawing", "WriteAllText") 
| project Timestamp, DeviceName, AccountName, ProcessCommandLine 
| order by Timestamp desc 

WinRM lateral movement from a non-administrative process

DeviceNetworkEvents 
| where Timestamp > ago(7d) 
| where InitiatingProcessFileName =~ "powershell.exe" 
| where InitiatingProcessCommandLine endswith "-NoLogo -NoProfile -ExecutionPolicy Bypass" 
| where RemoteUrl endswith ":5985/wsman" 

MITRE ATT&CK Techniques observed

The following table maps the observed activity to MITRE ATT&CK techniques:

Indicators of Compromise (IOCs)

The following indicator types were observed in this campaign. Environment-specific values (paths, hostnames, and account names) have been generalized; defenders should hunt for the corresponding behaviors and patterns in their own telemetry.

File indicators

Payload delivery infrastructure

Command-and-control infrastructure

Learn more

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

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

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

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

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

The post Impersonating IT support: how threat actors turn a remote session into enterprise-wide access appeared first on Microsoft Security Blog.

Microsoft Defender Experts is tracking an active malware campaign that uses counterfeit software-download websites to impersonate trusted vendors and distribute malicious installers. The campaign has targeted users looking to download popular software and has resulted in compromises across multiple organizations and industries, primarily affecting China-based operations of multinational organizations and Chinese-speaking users. Microsoft has observed victims across healthcare, manufacturing, gaming, technology, logistics, government, and education sectors.

Once executed, the malicious installers deploy malware that establishes persistence, attempts to weaken security protections, and communicates with attacker-controlled infrastructure. Microsoft assesses with moderate confidence that this activity is consistent with the publicly reported Silver Fox (also known as Yinhu, 银狐) fake software campaign but has not attributed it to a nation-state actor. Microsoft Defender detected and disrupted activity across multiple stages of the attack, including automated containment through attack disruption. Organizations should prioritize preventing downloads from untrusted software sources and ensure protections such as SmartScreen, network protection, tamper protection, and Microsoft Defender XDR are enabled to help identify, block, and respond to related activity.

Attack chain overview

The campaign follows a consistent attack chain from a spoofed vendor download page to a self-protecting, persistent implant. The stages below trace that chain — initial access, delivery, execution, persistence, privilege escalation, defense evasion, and command and control.

Campaign scope and targeting

Microsoft observed affected devices predominantly associated with China-based operations and Chinese-speaking users, consistent with the Chinese-language lure content and the .com.cn and .hl.cn infrastructure. Confirmed activity spans medical devices and healthcare, manufacturing, gaming, technology, logistics, government, and higher education across multiple organizations and industries.

Initial access: spoofed software-download sites

The entry point is a fraudulent software-download website that spoofs a legitimate vendor. In one case, endpoint telemetry captured a device navigating to the fake Razer page pc-razerzone[.]com[.]cn and downloading app_setup.6653004.zip from the delivery host gehie246[.]com/712down; two content-distinct copies of the same-named archive were written within roughly 69 seconds — a direct observation of server-side payload regeneration.

Across the estate, FileOriginReferrerUrl telemetry ties each downloaded archive to the impersonation page that served it and to rotating delivery hosts (yimxg25tiy[.]com/73inst, cc8ttkv35b[.]com/7qinst, n7b8t85zsg[.]com/ins711) and a suspected attacker-controlled Alibaba Cloud Object Storage Service (OSS) bucket. The lure domains predominantly use .com.cn, .hl.cn, and .cn and embed the impersonated brand name.

Delivery: a dynamically generated installer archive

The following examples illustrate how look-alike domains routed users to the same delivery infrastructure while preserving brand-specific lure pages.

When the user selects the download control, Microsoft Edge retrieves a malicious installer archive from a small set of dedicated delivery domains.

pc-razerzone[.]com[.]cn  (spoofed Razer download site)   →   www[.]gehie246[.]com/712down   →   app_setup.6653004.zip   →   stage-one loader

A defining characteristic is that the archive keeps the same filename while its hash changes on every download — a strong indicator the payload is generated server-side, per request. Microsoft observed families of same-named archives (app_setup.*, zinst.*, zintall.*, intsoft.*, innstll.*) whose contents differ across downloads while the delivery URL stays constant; the full validated hash set is in the indicators of compromise below.

kaspersky-lab[.]hl[.]cn     →   hxxp://www.gehie246[.]com/712down
pc-razerzone[.]com[.]cn     →   hxxp://www.gehie246[.]com/712down
calibre-ebook[.]com[.]cn    →   hxxp://www.gehie246[.]com/712down

Brand-impersonation infrastructure

The campaign runs a large, uniform set of vendor look-alike pages on .com.cn and .hl.cn domains, each cloning the real product’s branding and presenting a prominent “Download now” button. All funnel to the same delivery and payload infrastructure.

Although these domains impersonate unrelated vendors, they are not independently hosted. Infrastructure enrichment, corroborated by Microsoft telemetry where the two overlap, resolves them into two groupings. Six domains resolve within AS132839, spread across four unrelated netblocks and three registered country codes, and share a common pair of nameservers. Two further domains resolve within AS8796 in a single /21, using a different nameserver pair. One additional domain is served through a content delivery network (CDN), concealing its origin. Because hosting and Domain Name System (DNS) are frequently bundled by the same reseller, these are best read as two consistent procurement channels rather than two independent corroborating signals.

The practical implication for defenders is that netblock- and geography-based grouping will miss these relationships, while Autonomous System Number (ASN)-level analysis surfaces them.The autonomous system remains constant even where the address space and registered country vary. These are shared commercial hosting and DNS providers carrying substantial unrelated tenancy, so the ASN and nameserver should be treated as hunting pivots, not blocklist entries.

The following capture shows a representative impersonation page served by the campaign. The pages are high-fidelity clones of a legitimate vendor’s site with a prominent download call-to-action.

Execution: a wrapped installer drops a randomized stage-one payload

The wrapper installer creates a randomized executable path while reusing stable payload content, making names unreliable but behavior and hashes useful for detection.

Opening the archive yields a wrapper installer whose name follows a generated pattern (for example, a_instapp83353001.exe or ainst8663586104.exe).

Executing the wrapper creates and launches a stage-one payload at a randomized path under a world-writable or system location; the directory and file names are randomized, but the payload content is stable. The same stage-one 256-bit Secure Hash Algorithm (SHA-256) (676a2a7b94ca…) was observed under many names and paths.

C:\Users\Public\sE94yD\aLcUaw.exe        (SHA-256 676a2a7b94ca…  stage-one)
C:\Users\Public\nvdPX5\2b3L5i.exe        (SHA-256 676a2a7b94ca…  stage-one)
C:\Program Files (x86)\i3LH90\ErNGxW.exe (SHA-256 6d6ba2bc9ad4…  later-stage)
C:\Program Files (x86)\Q8Maj\7EIr6VA.exe (SHA-256 6d6ba2bc9ad4…  later-stage)
C:\ProgramData\zsMmvukD\beuv4Mie.exe     (SHA-256 c6100166e2d3…  persistent)

The end-to-end chain is visible as a parent-to-child process tree: msedge.exe writes the archive, an archiving tool (7zFM.exe, 360zip.exe, or WinRAR.exe) extracts it, the bundled wrapper runs, and the wrapper launches the randomized stage-one payload.

msedge.exe                               downloads app_setup.6653004.zip
  └─ 7zFM.exe / 360zip.exe / WinRAR.exe  (user opens the downloaded archive)
       └─ a_instapp83353001.exe           (wrapper installer bundled in the archive)
            └─ C:\Users\Public\yZ6A88\9bEELI.exe  (stage-one payload, randomized)

Payloads are masqueraded; Microsoft confirmed the masquerade through file metadata on the later-stage payload (SHA-256 6d6ba2bc…), staged at C:\Program Files (x86)\<random>\. The binary’s version resource declares CompanyName: “Speech Processing Solutions GmbH”, FileDescription: “Philips Speech Driver Client Configuration”, OriginalFileName: PhilipsSpeechDriverConfiguration.exe, and ProductVersion: 4.7.471.07,while executing from a randomized directory under a randomized file name. The same resource retains an unfilled build-template placeholder, ProductName: “TODO: <Product name>”, indicating the version information was fabricated for the payload rather than inherited from genuine vendor software. Microsoft also observed svchost.exe executing from a non-system path (D:\hellothere\svchost.exe) rather than C:\Windows\System32.

FileName                                      XPSPLOG.dll
FolderPath                                    C:\Program Files (x86)\72q1o6\XPSPLOG.dll
InitiatingProcessFileName                     40gK5T.exe
InitiatingProcessFolderPath                   C:\Program Files (x86)\72q1o6\40gK5T.exe
InitiatingProcessSHA256                       6d6ba2bc9ad414837826f7278bc3e0116f1aeda02d0c2284ed65819f5d9180a8
InitiatingProcessCommandLine                  "40gK5T.exe"
 
InitiatingProcessVersionInfoCompanyName       Speech Processing Solutions GmbH
InitiatingProcessVersionInfoFileDescription   Philips Speech Driver Client Configuration
InitiatingProcessVersionInfoOriginalFileName  PhilipsSpeechDriverConfiguration.exe
InitiatingProcessVersionInfoProductVersion    4.7.471.07
InitiatingProcessVersionInfoProductName       TODO: 
 
InitiatingProcessParentFileName               svchost.exe

A payload staged under C:\ProgramData\<random>\ (SHA-256 c6100166…) carries the version metadata of the Indigo Rose TrueUpdate Client (OriginalFileName: tu_rt.exe, ProductVersion: 3.8.0.0) and exhibits that product’s runtime behavior, writing _ir_tu2_temp_* artifacts to the user’s temp directory on each execution. Dropped by the later-stage payload and launched repeatedly by the Task Scheduler service, it connects to an attacker-controlled Alibaba Cloud OSS bucket over Transport Layer Security (TLS) and writes a further payload to a second randomized C:\ProgramData\ directory — a legitimate update mechanism repurposed for payload delivery.

00:24:43  ErNGxW.exe (6d6ba2bc…) creates C:\ProgramData\zsMmvukD\beuv4Mie.exe (c6100166…)
00:24:43  beuv4Mie.exe executes   ← parent: svchost.exe -k netsvcs -p -s Schedule
00:24:44  beuv4Mie.exe → ConnectionSuccess | upitem.oss-cn-hangzhou.aliyuncs.com | 443
00:24:44  beuv4Mie.exe creates C:\ProgramData\uwMUCYBN\SaYC4Mga.exe (f33d160d…)
02:12:22  beuv4Mie.exe creates …\Temp\_ir_tu2_temp_4      ← TrueUpdate runtime artifact
02:44:20  beuv4Mie.exe re-executes (scheduled task) → _ir_tu2_temp_5
02:59:00  … _temp_6    03:15:54 … _temp_7    08:02:52 … _temp_8
08:32:20  … _temp_9    08:38:51 … _temp_11

Alternate execution vector: Windows Installer (msiexec)

In parallel with the wrapped-installer chain, Microsoft observed a second execution vector that uses the Windows Installer service. The installer performs its intended function; what the campaign gains is execution under a signed, trusted Windows component. The extracted installer invokes msiexec.exe in embedded mode, which writes and launches a randomized executable into a world-writable C:\Users\Public\<random>\ directory, the same masquerade pattern as the wrapper chain, but delivered through msiexec.exe.

msiexec.exe -Embedding .exe   (payload, randomized path/name)
\ E Global\MSI0000
  └─ C:\Users\Public\

The behavior is consistent and repeated: more than twenty distinct payload names were written this way, spawned by a range of parents including msedge.exe, explorer.exe, and svchost.exe.

Persistence and recurring execution: disguised scheduled tasks

Persistence and recurring execution are achieved through scheduled tasks whose display names imitate routine IT or productivity jobs (for example “Deadline Mission Target” and “Hierarchy Tools Smooth Inventory”), each launching a specific payload staged under C:\ProgramData\.

Each task launches a specific payload:

The persistent payloads are staged in locations such as C:\ProgramData\7fYptijy.exe, C:\ProgramData\zsMmvukD\beuv4Mie.exe, and C:\ProgramData\uwMUCYBN\SaYC4Mga.exe. Because the payloads are launched by the Task Scheduler service (parented to svchost.exe -k netsvcs -p -s Schedule) and multiple staggered tasks run per device, affected hosts exhibit a characteristic ~60-second re-execution cadence.

Privilege escalation: SYSTEM scheduled task and process injection

To perform privileged actions such as writing Microsoft Defender exclusions, the malware creates a short-lived scheduled task that runs as SYSTEM (SCHTASKS /Create … /RL HIGHEST /RU “SYSTEM”), executes the privileged action, then immediately runs and deletes the task

SCHTASKS /Create /F /TN "Task1" /SC ONCE /ST 00:00 /RL HIGHEST /RU "SYSTEM"
  /TR "cmd.exe /c reg add \"HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\"
       /v \"C:\Program Files (x86)\NPq6k16Om\" /t REG_DWORD /d 0 /f"
SCHTASKS /Run /TN "Task1"    &    SCHTASKS /Delete /TN "Task1" /F

The /RL HIGHEST /RU “SYSTEM” combination elevates the exclusion write to SYSTEM, and the create-run-delete sequence minimizes the footprint of the helper task. Process injection was also observed. A persistent campaign payload (SHA-256 1bd3662d…), launched from C:\ProgramData\ by the Task Scheduler service, created a remote thread in a legitimate user application moments after that application started — executing payload code inside the context of a trusted process. Microsoft Defender detected the activity as A process was injected with potentially malicious code.

ActionType                       CreateRemoteThreadApiCall
InitiatingProcessFileName        .exe" -autorun
ProcessCreationTime              2026-07-13 02:44:37.568
AdditionalFields                 {"IntegrityLevel":8192}
.exe      (target process)
ProcessCommandLine               ".exe"
InitiatingProcessCreationTime    2026-07-13 02:44:20.887
InitiatingProcessParentFileName  svchost.exe
FileName                         .exe
InitiatingProcessSHA256          1bd3662d784840e410d2d3c0a1040277f7f549089447359f01e05c2559cb1f17
InitiatingProcessCommandLine     ".exe
InitiatingProcessFolderPath      C:\ProgramData\

The sequence below shows a single execution cycle end to end: the Task Scheduler service launches the payload, the payload immediately attempts command-and-control on two non-standard ports — both blocked at the host firewall — and, seventeen seconds later, injects into a user application within milliseconds of that application starting.

02:44:20.887   PROC     .exe → target application   
.exe started            parent: svchost.exe (Task Scheduler)
02:44:21.971   NETWORK  outbound to 47.239.232[.]245:8050    → FirewallOutboundConnectionBlocked
02:44:24.860   NETWORK  outbound to 47.243.218[.]255:28300   → FirewallOutboundConnectionBlocked
02:44:37.568   PROC     target application starts (-autorun)
02:44:37.604   INJECT   CreateRemoteThreadApiCall  

Defense evasion: disabling host protections

Follow-on payloads take a layered approach to weakening the host. They add sweeping Microsoft Defender path exclusions via PowerShell (Add-MpPreference -ExclusionPath) and the SYSTEM scheduled-task registry write;

powershell.exe Add-MpPreference -ExclusionPath 'C:\ProgramData','C:\Users','C:\Program Files (x86)','C:\' -Force
powershell.exe -c if (Get-Process -Name HAhahahah) {} else {
  Add-MpPreference -ExclusionPath $env:localappdata,'C:\','C:\ProgramData',
   'C:\ProgramData\7b3St9HS','C:\ProgramData\7b3St9HS\27s7ihjC.exe' -ExclusionExtension '.dat' -Force }

delete volume shadow copies (vssadmin delete shadows /all /quiet) to inhibit recovery;

cmd.exe /c vssadmin delete shadows /all /quiet

harden payload directories with icacls so standard users cannot remove the files;

icacls "C:\Program Files (x86)\NPq6k16Om\xo7Tj9xQ.exe" /grant:r Administrators:(OI)(CI)F /grant:r SYSTEM:(OI)(CI)F

and neutralize Windows Update by stopping and disabling wuauserv, UsoSvc, uhssvc, and WaaSMedicSvc, renaming update dynamic-link libraries (DLLs), and deleting the SoftwareDistribution cache.

for %i in (wuauserv UsoSvc uhssvc WaaSMedicSvc) do (
   net stop %i & sc config %i start= disabled & sc failure %i reset= 0 actions= "" )
for %i in (WaaSMedicSvc wuaueng) do ( takeown /f C:\Windows\System32\%i.dll &
   icacls …\%i.dll /grant *S-1-1-0:F & rename …\%i.dll %i_BAK.dll &
   icacls …\%i_BAK.dll /setowner "NT SERVICE\TrustedInstaller" & icacls …\%i_BAK.dll /remove *S-1-1-0 )
reg add "HKLM\…\Services\WaaSMedicSvc" /v Start /t REG_DWORD /d 4 /f
reg add "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f
erase /f /s /q c:\windows\softwaredistribution\*.*  &  rmdir /s /q c:\windows\softwaredistribution
powershell -Command Get-ScheduledTask -TaskPath '\Microsoft\Windows\WindowsUpdate\*' | Disable-ScheduledTask

A malicious Windows Defender Application Control policy was written to the code-integrity store on multiple devices; Microsoft Defender Antivirus detected the tamper behavior as Behavior:Win32/MpTamperGpDisableAVFriendly.A.

Command and control (C2)

A later-stage networking payload establishes command-and-control over application-layer protocols on non-standard ports — observed ports include 5090, 7031, 7032, 7088–7090, 8050, 28290, and 28300.

C2 endpoints comprise a set of six-character [.]net domains (iualef, oijfwe, euioxu, czijbh, wfmwsj, tbdqxq) and IP-and-port endpoints; a primary hub was observed on 202.95.14[.]237 (AS152194, CTG Server Limited). Payloads were observed beaconing to these endpoints with both successful and failed callbacks; the dedicated [.]net and IP-and-port C2 was intermittently unreachable while the same payloads still completed TLS connections to cloud object storage, consistent with a dedicated C2 tier that was often down while cloud-hosted staging remained live.

Detection and disruption

In observed environments, Microsoft Defender surfaced alerts across multiple stages and, where criteria were met, Attack Disruption engaged to contain affected devices and accounts.

Representative alerts include Modification attempt in Microsoft Defender Antivirus exclusion list, Compromised device (attack disruption), A process was injected with potentially malicious code, Potential C2 connection behavior, Suspicious Task Scheduler activity, and Compromised account conducting hands-on-keyboard attack. The campaign is not purely automated. In a subset of environments, the automated execution was accompanied by interactive, hands-on-keyboard activity, which attack disruption engaged to contain.

Microsoft Defender also blocked the attempted Server Message Block (SMB) lateral movement to additional hosts (Lateral movement using SMB remote file access blocked on multiple devices) and detected the C2 connection behavior; the campaign’s C2 endpoints are included in the blocked indicator set.

Attack disruption contained the device and account; full eradication of persistence still required responder action.

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.

Campaign-specific recommendations

• Enforce Tamper Protection. It blocks exclusion and registry writes to Microsoft Defender even when the payload runs as SYSTEM — directly countering the throwaway SYSTEM scheduled-task technique this campaign relies on.
• Hunt behavior, not file names. File names and hashes rotate on every download; pivot on the C:\Users\Public\<random>\<random>.exe and C:\Program Files (x86)\<random>\<random>.exe drop pattern, the Philips-Speech masquerade, and the stable stage-one and networking payload hashes.
• Alert on the tamper sequence. A SYSTEM scheduled task writing HKLM\…\Windows Defender\Exclusions\Paths then self-deleting, vssadmin delete shadows /all /quiet, and disabling wuauserv, UsoSvc, WaaSMedicSvc and uhssvc are high-fidelity signals.
• Treat look-alike download archives as malicious in web and mail flow. Block ZIPs named app_setup.*, zinst.*, zintall.*, intsoft.*, and innstll.* served from *.com.cn or *.hl.cn brand-look-alike domains and the /712down, /73inst, /7qinst, and /ins711 delivery endpoints.
• Correlate download referrers. Use FileOriginUrl and FileOriginReferrerUrl to catch landing-page to delivery-host pairs even after individual domains rotate, and block the C2 IP:port set and .net C2 domains.

Microsoft Defender XDR hardening recommendations

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 execution of potentially obfuscated scripts 
• Block use of copied or impersonated system tools 
• Use advanced protection against ransomware 

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 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
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

These promptbooks can help analysts summarize affected entities, review alert timelines, and pivot on the IOCs included in this blog. Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft Defender XDR customers can use 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 the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Advanced hunting

Microsoft Defender XDR and Microsoft Sentinel customers can run the following queries. . The behavior-based queries continue to work even as filenames, hashes, and domains rotate.

Campaign payloads and loaders Surfaces execution or creation of the campaign’s stable stage-one, later-stage, persistent, networking, and loader binaries by SHA-256.

let campaignSha256 = dynamic([
  "676a2a7b94ca2f8ec76352ee656e4d075bb342bd7ad6efbc7c19c060001eace7", // stage-one
  "6d6ba2bc9ad414837826f7278bc3e0116f1aeda02d0c2284ed65819f5d9180a8", // later-stage
  "c4100ad39d8db98f063feb6c3b6c8e9a9f9d9bf25a1e0233f43b058ff8a7dbdf", // networking
  "1bd3662d784840e410d2d3c0a1040277f7f549089447359f01e05c2559cb1f17", // persistent
  "c6100166e2d3b40388980f7674712ef39e937ac04925ca5d370415399ed73faf", // TrueUpdate loader
  "f33d160d757e4b39019fdef21cf90cafb501b800ca0d4039366bc30856e3d81b", // persistent/networking
  "e4fe2dee8f0bb132fa15fc686d1f93df39530a2d3a8d3a1f3a605a057c04e7b3"  // supporting DLL
]);
union
  (DeviceProcessEvents | where SHA256 in (campaignSha256)),
  (DeviceFileEvents    | where SHA256 in (campaignSha256))
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Randomized payload drop pattern Finds executables dropped into randomized folders under world-writable or system locations — the campaign’s stable staging behavior regardless of filename.

DeviceProcessEvents
| where FolderPath matches regex @"(?i)^C:\\(Users\\Public|ProgramData|Program Files \(x86\))\\[A-Za-z0-9]{4,10}\\[A-Za-z0-9]{4,10}\.exe$"
| where InitiatingProcessFileName in~ ("msiexec.exe","explorer.exe","svchost.exe","cmd.exe","7zFM.exe","360zip.exe","WinRAR.exe")
| project Timestamp, DeviceName, AccountName, FolderPath, FileName, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Microsoft Defender exclusion tampering Detects the SYSTEM scheduled-task and PowerShell routines that write sweeping Microsoft Defender path exclusions.

DeviceProcessEvents
| where ProcessCommandLine has @"Windows Defender\Exclusions\Paths"
     or ProcessCommandLine has "Add-MpPreference -ExclusionPath"
     or (ProcessCommandLine has "SCHTASKS" and ProcessCommandLine has "SYSTEM" and ProcessCommandLine has "Exclusions")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

Recovery inhibition and Windows Update neutralization Surfaces shadow-copy deletion and the routine that stops, disables, or renames Windows Update service components.

DeviceProcessEvents
| where ProcessCommandLine has "vssadmin delete shadows"
     or (ProcessCommandLine has_all ("sc","config","disabled") and ProcessCommandLine has_any ("wuauserv","UsoSvc","uhssvc","WaaSMedicSvc"))
     or ProcessCommandLine has "NoAutoUpdate"
     or (ProcessCommandLine has "rename" and ProcessCommandLine has_any ("wuaueng","WaaSMedicSvc"))
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
| order by Timestamp desc

Windows Installer (msiexec) embedded-mode execution Catches the parallel delivery vector where msiexec launches a randomized payload from a world-writable path.

DeviceProcessEvents
| where InitiatingProcessFileName =~ "msiexec.exe"
| where InitiatingProcessCommandLine has "-Embedding" and InitiatingProcessCommandLine has @"Global\MSI0000"
| where FolderPath has @"C:\Users\Public\"
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessCommandLine
| order by Timestamp desc

Disguised scheduled-task execution Flags payloads relaunched by the Task Scheduler service from user-writable directories (the ~60-second re-execution loop).

DeviceProcessEvents
| where InitiatingProcessCommandLine has "netsvcs" and InitiatingProcessCommandLine has "Schedule"
| where FolderPath matches regex @"(?i)^C:\\(Users\\Public|ProgramData|Program Files \(x86\))\\"
| where FileName endswith ".exe"
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessFileName
| order by Timestamp desc

Command-and-control connections Matches callbacks to the campaign’s C2 IP:port set and six-character .net C2 domains.

let c2ip    = dynamic(["202.95.14.237","47.239.232.245","161.248.87.157","103.156.25.35","103.183.3.162","43.99.100.248","47.239.175.163","47.86.205.97","47.243.218.255"]);
let c2ports = dynamic([5090,7031,7032,7088,7089,7090,8050,28290,28300]);
let c2dom   = dynamic(["iualef.net","euioxu.net","czijbh.net","wfmwsj.net","tbdqxq.net","oijfwe.net"]);
DeviceNetworkEvents
| where (RemoteIP in (c2ip) and RemotePort in (c2ports)) or (RemoteUrl has_any (c2dom))
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessSHA256, RemoteIP, RemotePort, RemoteUrl, ActionType
| order by Timestamp desc

Malicious delivery domains and download endpoints Identifies connections to the dedicated delivery domains and the /712down, /73inst, /7qinst, /ins711 download paths.

let deliveryHosts = dynamic(["gehie246.com","yimxg25tiy.com","cc8ttkv35b.com","n7b8t85zsg.com","bxfh.tzcdq.cn","tmsq.tzcdq.cn","mebx78e02.com","qwjre1487.com"]);
DeviceNetworkEvents
| where RemoteUrl has_any (deliveryHosts) or RemoteUrl has_any ("/712down","/73inst","/7qinst","/ins711")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, ActionType
| order by Timestamp desc

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.

Indicators of compromise (IOC)

References

Prior reporting and OSINT sources — Silver Fox (also known as Yinhu, 银狐)

• TweetFeed community indicator feed — weekly IOC export
• AlienVault OTX pulse — campaign delivery infrastructure and C2 indicators
• MalwareBazaar — campaign payload sample (aea879a0…)
• MalwareBazaar — campaign payload sample (6dacf281…)
• LGSRC public indicator repository

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.  

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

The post Counterfeit installers to system compromise: Tracking a deceptive software download campaign appeared first on Microsoft Security Blog.

Cybersecurity incidents can unfold in hours, but response plans often fail at the point of execution: ownership is unclear, investigation findings is difficult to access, and critical decisions are delayed. That is why incident response cannot be something your organization figures out in real time.

The Detection and Response Team (DART) – the Microsoft team that delivers Defender Experts Cybersecurity Incident Response – has supported organizations across 54 countries and regions through some of their most challenging security moments; and while we sincerely hope you never need to call us in the middle of a live incident, we do want to help you prepare for that possibility before it becomes real.

That’s exactly what the Cybersecurity Incident Response Readiness Workshop is designed to do.

What is the Cybersecurity Incident Response Readiness Workshop?

The Cybersecurity Incident Response Workshop is a collaborative, scenario driven workshop designed to evaluate your organization’s incident response (IR) plan against realistic, real-world security events, guided by DART researchers.

Rather than reviewing your plan in isolation, we work through simulated incidents together. Participants navigate realistic attack scenarios, present investigation findings, discuss decisions, and receive direct feedback from responders with extensive experience handling complex incidents worldwide.

What makes DART’s approach different?

DART’s approach combines active participation with lessons drawn from frontline incident response. Instead of reviewing a plan as a static document, the Cybersecurity Incident Response Workshop exercises how people, processes, and technology work together under pressure. Participants practice detection, containment, and response decisions while DART security researchers provide feedback grounded in real-world incident experience.

The workshop creates a controlled environment for teams to test how they detect, investigate, contain, and communicate during an incident. DART security researchers examine how people, processes, and technology work together across identity, endpoint, cloud, and communications, including whether the organization’s tools, logs, and telemetry support timely decisions against real threat actor behaviors.

Additionally, the workshop includes threat hunting exercises that let incident response teams investigate realistic scenarios with urgency but without the pressure of a live incident. This hands-on practice strengthens technical judgment and helps teams coordinate their response more effectively.

Why organizations run this workshop

The goal is not to pass or fail. It’s to discover how well your organization can make and execute critical response decisions under pressure, and where preparation today can prevent delay during a real incident.

During the Workshop, organizations are able to:

• Compare and contrast their incident response plan with insights drawn from DART’s experience across thousands of real‑world cases.
• Exercise response processes using real-world scenarios to identify strengths and improvement opportunities, including processes, threat hunting techniques, and the use of cybersecurity technologies.
• Identify potential gaps in both tools and procedures before a threat actor finds them.

In short: it’s a chance to see what holds up under pressure, where coordination or visibility begins to bend, and what your organization should reinforce before a threat actor puts the response plan to the test.

Our approach: How we assess your maturity

The workshop blends structured analysis with hands-on knowledge transfer, creating an experience that is both evaluative and practical.

The assessment examines how your organization’s people, processes, and technology support incident response across identity, endpoint, cloud, and communications. It also evaluates whether available tools and telemetry provide the visibility needed to respond to real threat actor tactics.

Additional knowledge transfer is delivered through interactive exercises led by DART, encouraging cross-team collaboration while sharing proven detection and containment practices drawn from real incidents.

What organizations walk away with

By the end of the workshop, organizations leave with a clearer view of how their incident response capability performs today and where focused improvements can strengthen readiness. You’ll take away:

• Clear identification of strengths and opportunities in IR preparation and execution.
• Insight into how tools, techniques, and available data perform during an incident.
• A summary of findings and prioritized recommendations to help strengthen incident response readiness and guide next steps.

Scope and structure

The engagement begins by aligning on objectives, participants, logistics, and expected outcomes so the scenarios and discussions can be tailored to the organization’s needs

The workshop spans 2 or 3 days, including:

• Kick off and introductions to understand who the audience is and what they hope to gain from the workshop; this helps us tailor our delivery approach for each unique organization
• Knowledge-transfer sessions
• Scenarios and guided discussions assessing current capabilities
• Closeout and recommended next steps

Practice before it matters

If your incident response plan lives mostly on paper, or if it’s never been exercised with the people who will use it, the Cybersecurity Incident Response Workshop provides a safe, structured way to change that. When a real incident happens, you don’t want your first conversation about roles, investigation findings, or decision-making to happen in the middle of a crisis.

Don’t wait for a live incident to test your response plan, if you have an established Unified Enterprise agreement with Microsoft, reach out to your Customer Success Account Manager (CSAM) to schedule a Cybersecurity Incident Response Workshop and give your teams the opportunity to practice before it matters most.

Learn more

• To learn more about DART capabilities, please visit our website, or contact your Microsoft Customer Success Account Manager or Premier Support contact.
• 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 Cybersecurity IR Workshop: The workshop you shouldn’t miss appeared first on Microsoft Security Blog.

Microsoft Threat Intelligence has observed a TerminalFix campaign, a variant of ClickFix, targeting organizations across multiple industries. The campaign uses compromised websites to display a fake Cloudflare CAPTCHA verification overlay that tricks users into copying and executing a malicious PowerShell command. While traditional ClickFix campaigns direct victims to the Windows Run dialog, TerminalFix campaigns apply the same technique but direct users to Windows Terminal or PowerShell instead, increasing the likelihood that complex, multi-line scripts execute successfully. Unlike earlier ClickFix variants that typically deliver a single infostealer, this TerminalFix campaign deploys a sophisticated multi-stage attack chain that combines DLL sideloading, steganographic payload extraction, extensive Active Directory reconnaissance, and a custom reverse-tunnel implant – giving the attacker persistent, network-level proxy access through the compromised host.

Once executed, the PowerShell command masquerades as a Cloudflare verification process while downloading a ZIP archive containing a legitimate binary (LockScreenContentServer.exe) and a malicious DLL (dui70.dll) used for sideloading. The sideloaded DLL drives an elaborate second stage: downloading payloads concealed inside PNG images using steganography, establishing dual persistence through Registry Run keys and scheduled tasks, conducting thorough domain reconnaissance—including domain trust enumeration, domain admin discovery, Active Directory user description harvesting, and targeted server ping sweeps—and ultimately deploying a Python-based reverse-tunnel C2 implant that tunnels arbitrary TCP traffic back through an encrypted WebSocket channel to attacker infrastructure.

This type of intrusion is particularly dangerous because it provides attackers with direct access to an organization’s internal network through the reverse tunnel. The observed reconnaissance and reverse-tunnel capability could enable an attacker to identify and reach additional systems from a compromised host. Microsoft did not observe the downstream actions described below in the analyzed chain. Organizations should treat affected devices as potential network pivot points and investigate for lateral movement and credential exposure. In the hands-on-keyboard phase that typically follows, attackers leverage this access to escalate privileges, disable security controls, exfiltrate sensitive data, and deploy ransomware across the organization. The combination of stealth techniques (DLL sideloading, steganography, hidden folders) and persistent network access make this TerminalFix campaign a serious threat to enterprise environments.

In this blog, we share our detailed analysis of the TerminalFix attack chain – from initial compromise through network tunneling—along with indicators of compromise, detection details, and hunting guidance to help defenders identify and respond to this threat.

Attack chain overview

The TerminalFix campaign follows a multi-stage attack chain that progresses from social engineering through payload delivery, persistence, reconnaissance, and ultimately network tunneling:

1. Initial access via compromised website – A compromised website displays a fake Cloudflare Turnstile CAPTCHA verification overlay. The user is instructed to copy and paste a “verification” command.

2. PowerShell execution – The pasted command runs a disguised PowerShell script that downloads a ZIP archive from attacker infrastructure, extracts it to C:\ProgramData, and silently launches a batch file.

3. DLL sideloading — The batch file executes LockScreenContentServer.exe, a signed legitimate binary, which automatically loads the co-located malicious dui70.dll.

4. Steganographic payload retrieval – The sideloaded DLL executes PowerShell that downloads PNG images from attacker domains, extracts embedded executables and DLL fragments hidden within pixel data, and reassembles them on disk.

5. Persistence – The malware establishes persistence through both HKCU\…\Run registry keys and scheduled tasks that re-execute LockScreenContentServer.exe every 60 minutes.

6. Reconnaissance – Extensive domain discovery is performed: domain trust enumeration, domain admin group membership, Active Directory computer and user enumeration, targeted server pinging, and system information collection in both English and Spanish locales.

7. Command execution loop – A persistent PowerShell file-watch loop monitors a text file for new commands, executes them via Invoke-Expression, and writes results to an output file-, creating a primitive but effective asynchronous command shell.

8. Reverse tunnel deployment – A Python runtime and a custom client.py tunneling implant are downloaded and launched via pythonw.exe with no visible window, establishing a reverse WebSocket tunnel to gitnow[.]dev:443 that gives the attacker full SOCKS-style TCP proxy access through the victim’s network.

Attack chain

1. Initial access: Fake CAPTCHA and the TerminalFix lure

The attack begins when a user visits a compromised website that displays a fake Cloudflare Turnstile verification overlay. The original page is briefly displayed before being replaced by a convincing Cloudflare Turnstile verification overlay. This overlay spoofs the Cloudflare CAPTCHA interface, complete with the Cloudflare logo, “Verify you are human” checkbox, and a spinner animation, tricking users into believing they must complete a verification step to access the site.

When the user interacts with the fake verification prompt, a malicious PowerShell command is silently copied to their clipboard. The on-screen instructions then guide the user to open Windows Terminal or PowerShell and paste the command. The command is carefully crafted to appear legitimate by printing reassuring Cloudflare-themed status messages in color-coded terminal output:

The command performs the following actions:

• Clears the terminal and prints a fake “Starting Cloudflare verification…” message in cyan color formatted
• Downloads a ZIP archive from the attacker’s infrastructure using a custom User-Agent header
• Extracts the archive to C:\ProgramData\f47f2a8c21c9df4e
• Launches a batch file (1.bat) that executes LockScreenContentServer.exe silently in the background
• Prints a convincing “I am not a robot – Cloudflare ID: f47f2a8c21c9df4e” confirmation message in green text

2. Payload delivery: DLL sideloading via LockScreenContentServer.exe

The downloaded ZIP archive (SHA-256: 18c2090e8a0ae0568af9b87e59eaf8270f23d2909600ed9db91a9444fd8b278f) contains two files:

LockScreenContentServer.exe is a legitimate, signed binary that has a static import dependency on dui70.dll, the Windows DirectUI Engine.

Here is the example view of LockScreenContentServer application importing dui70.dll function:

The attacker abuses this dependency by dropping a malicious dui70.dll alongside the executable. Because the Windows loader resolves the application directory before the System32 directory, the planted DLL is loaded in place of the legitimate one, a technique known as DLL sideloading (T1574.001). Execution therefore begins inside a trusted, signed process, allowing the attacker to inherit its reputation and evade controls that key on process identity.

The malicious dui70.dll embeds a heavily obfuscated payload in its resource section. On load, the DLL’s initialization path retrieves this resource, decodes it entirely in memory, and transfers execution to it, staging the next phase of the infection without ever writing the decoded payload to disk (Figures 5 and 6).

3. Second-stage delivery: Steganography and image-based payload extraction

Once sideloaded, the malicious DLL launches an elaborate PowerShell script that retrieves additional payloads concealed within PNG image files, a technique known as steganography. The script downloads three images from attacker-controlled domains, extracts binary data encoded in pixel values, and reassembles the components on disk.

Content domains

The script uses a failover mechanism across two domains:

Steganographic extraction

The Extract-RawFileFromImage function reads each pixel’s RGBA channels and reconstructs an embedded binary. The first 8 bytes encode the payload length as a 64-bit integer, and the remaining bytes contain the file data:

The script downloads three images via POST requests to the content domains, extracts the executable from the first image, extracts two halves of the DLL from the second and third images, and concatenates the DLL fragments:

Encoding payload data in PNG files can make file type and content inspection more difficult. Splitting the DLL across two images further obscures the complete payload in transit, the payloads aren’t recognizable as executables in transit, and splitting the DLL across two images further complicates detection. After extraction, the source images are deleted to reduce forensic artifacts.

4. Persistence mechanisms

The TerminalFix campaign establishes redundant persistence through two independent mechanisms, ensuring the payload survives reboots and re-executes on a recurring schedule. The dropped batch script takes the payload path as a command-line argument, validates that the file exists, and then configures both mechanisms under the same masquerading name LockScreenContentServer_MuODG5yBM chosen to blend in with the legitimate Windows Lock Screen component abused earlier in the chain.

Registry Run key

The malware creates a Run key entry with a randomized service-like name:

Scheduled task

A scheduled task ensures the malware re-executes every 60 minutes:

Folder hiding

The malware directory is hidden using system and hidden file attributes:

5. Reconnaissance and domain discovery

After establishing persistence, the sideloaded malware conducts extensive reconnaissance of the victim’s environment. This activity is consistent with a hands-on-keyboard operator or an automated pre-assessment script designed to evaluate whether the compromised host is a valuable target – particularly whether it is domain-joined and near high-value infrastructure.

System information collection

The attacker collects system metadata and the script includes English, Spanish, and German locale variants, indicating an attempt to operate across systems configured in multiple languages:

Active Directory enumeration

The malware performs domain trust discovery, domain admin enumeration, and Active Directory user and computer searches:

Infrastructure probing

The malware systematically pings named servers to map the internal network topology:

The observed names correspond to common infrastructure roles, including domain controllers, databases, backup, gateways, and mail systems. This probing could help an attacker identify accessible target systems for follow-on activity.

6. Asynchronous command execution loop

The malware deploys a persistent PowerShell file-watch loop that creates an asynchronous command-and-control channel through the local filesystem. This mechanism monitors a “watch” file for changes, executes its contents via Invoke-Expression, and writes results to an output file:

This loop provides the attacker with a way to execute arbitrary PowerShell commands by writing them to the watched text file. The output is captured to a separate file, which the attacker can read back through the reverse tunnel. This decoupled execution model allows the attacker to issue commands asynchronously and retrieve results at their convenience.

7. Reverse tunnel deployment: The custom Python-based tunneling implant

The most significant post-compromise capability observed is the deployment of a custom Python-based reverse-tunnel implant. The attacker brings their own interpreter: an unmodified, signed embeddable Python runtime pulled directly from the official python.org distribution. The malicious logic lives entirely in the accompanying client.py, giving the operator a portable, cross-version-tolerant execution environment that inherits the trust of a legitimate open-source runtime.

The deployment is orchestrated in PowerShell. It removes any prior install directory, extracts the implant kit, downloads the embeddable Python 3.14.5 archive over TLS 1.2, unpacks it into the same directory, and launches the tunnel with no visible window via pythonw.exe:

Tunneling implant analysis

The client.py script is a compact but full-featured reverse tunnel. It dials outbound to the C2 over TLS/443, upgrades the session to a WebSocket, and uses that channel to relay arbitrary TCP connections on behalf of the operator. On the wire, the traffic is indistinguishable from an ordinary encrypted web session to a single destination

The tunnel carries a lightweight custom protocol with eight message types spanning implant identification, connection setup, data relay, keepalive, and remote termination:

Turning the victim into a network pivot: The implant’s SOCKS5-style address parsing enables the C2 server to reach any host visible from the victim’s network. Combined with the reconnaissance data gathered earlier (domain controllers, SQL servers, backup servers, gateway), this turns the compromised machine into a full network pivot point:

The choice to launch with pythonw.exe (no visible window Python interpreter) means no console window is visible to the user. Combined with DEBUG = False by default and all logging going to stderr, the implant operates completely silently.

Mitigation and protection guidance

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

• Restrict PowerShell and Run dialog execution – Use AppLocker, Application Control for Windows, or Group Policy to restrict PowerShell execution for standard users.
• Consider blocking or auditing the Windows Run dialog (Win+R) where it is not required for daily work.
• Monitor for DLL sideloading indicators — Alert on LockScreenContentServer.exe executing from non-standard paths (anything other than C:\Windows\SystemApps). Use the LockScreenContentServer.exe sideloading from non-standard paths advanced hunting query provided below to identify this activity across your environment.
• Educate users about ClickFix tactics – Train employees to recognize fake CAPTCHA verification pages that instruct them to paste commands into Terminal or the Run dialog.
• Investigate affected hosts thoroughly – Organizations that find indicators of this campaign should assume the attacker has network-level access through the compromised host. Credential rotation should be prioritized for any credentials accessible from the affected machine, including domain admin accounts if the host was domain-joined.
• Check your Microsoft 365 email filtering settings to ensure spoofed emails, spam, and emails with malware are blocked. Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links on click and delete sent mail in response to newly acquired threat intelligence. Turn on safe attachments policies to check attachments to inbound email.
• Consider using enterprise-managed browsers, which provide multiple security features including security update requirements and data compliance policies.
• Block web pages from automatically running Flash plugins.
• Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based threats.
• 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 cloud-delivered protection in Microsoft Defender Antivirus, or the equivalent for your antivirus product, to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants.
• Enable PowerShell script block logging to detect and analyze obfuscated or encoded commands, providing visibility into malicious script execution that might otherwise evade traditional logging.
• Enforce use of PowerShell Constrained Language Mode where possible, in addition to use of execution policies such as setting AllSigned or RemoteSigned to help reduce the risk of malicious execution by ensuring only trusted, signed scripts are executed, adding a layer of control.
• Use Group Policy to deploy hardening configurations throughout your environment, if certain features are not necessary:
  • Create an App Control policy that prohibits the launch of native Windows binaries from Run. This can be accomplished by defining a rule based on the specific process that is launching binaries like PowerShell.
  • Configure Windows Terminal access and settings to warn users when the text they’re pasting contains multiple lines.
• Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against PowerShell techniques used by threat actors:
  • Block execution of potentially obfuscated scripts
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block JavaScript or VBScript from launching downloaded executable content

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 Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate investigation and response tasks related to this threat. Useful promptbooks for this activity include Incident investigation, Microsoft User analysis, Threat actor profile, Threat Intelligence 360 report based on MDTI intelligence, and Vulnerability impact assessment. Some promptbooks require access to Microsoft Defender XDR, Microsoft Sentinel, or related Microsoft security plugins.

For this campaign, Security Copilot can help analysts summarize affected devices running LockScreenContentServer.exe from non-standard locations, trace the PowerShell steganography extraction chain, and build containment and credential rotation plans for affected domain-joined endpoints.

Threat intelligence reports

Microsoft customers can use Microsoft Defender XDR Threat analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this compromise. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in customer environments.

Advanced hunting queries

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

ClickFix PowerShell execution which executes payload

DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where FileName =~ "cmd.exe" and ProcessCommandLine has_all (@"\ProgramData\", "1.bat", "LockScreenContentServer.exe")

LockScreenContentServer.exe sideloading from non-standard paths

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "LockScreenContentServer.exe"
| where FileName =~ "dui70.dll"
| extend path = tostring(parse_path(FolderPath).DirectoryPath)
| where path =~ InitiatingProcessFolderPath
| where not(path has_any (@"\Windows\System32", @"\Windows\SysWOW64", @"\winsxs\", @"\program files", @"\Windows Defender\", @"\Microsoft Security Client\", @"\Program Files\Windows", @"\Program Files\Microsoft", @"\ProgramData\Microsoft\", @"\Microsoft\Windows", @"\amd64_windows-defender-service", @"\Microsoft Defender for Endpoint\"))

Custom reverse tunnel implant execution

DeviceProcessEvents
| where FileName in~ ("pythonw.exe", "python.exe")
| where ProcessCommandLine has_all ("client.py", "--server", "--uuid", “cert.pem”, “gitnow.dev”)

Outbound connections to known C2 domains

DeviceNetworkEvents
| where RemoteUrl has_any ("gitnow.dev", "bestsocialmedianewspapper.com",
                            "offlineupdater.com")
| project Timestamp, DeviceName, RemoteUrl, RemotePort,
          InitiatingProcessFileName

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

Initial Access

• T1189 Drive-by Compromise | A compromised website delivers a fake CAPTCHA overlay.

Execution

• T1059.001 Command and Scripting Interpreter: PowerShell | A malicious PowerShell command is pasted by the user into Terminal.
• T1204.002 User Execution: Malicious File | The user pastes and executes a clipboard-hijacked command.

Persistence

• T1547.001 Boot or Logon Autostart Execution: Registry Run Keys | An HKCU Run key is set to execute LockScreenContentServer.exe.
• T1053.005 Scheduled Task/Job: Scheduled Task | A scheduled task is created to execute every 60 minutes.

Defense Evasion

• T1574.002 Hijack Execution Flow: DLL Side-Loading | Malicious dui70.dll is side-loaded by the legitimate LockScreenContentServer.exe.
• T1027.003 Obfuscated Files or Information: Steganography | Payloads are hidden in PNG image RGBA pixel data.
• T1564.001 Hide Artifacts: Hidden Files and Directories | The attrib +h +s command is applied to the payload directory.
• T1036.005 Masquerading: Match Legitimate Name or Location | The DLL is named dui70.dll to match the legitimate Microsoft DUI framework.

Discovery

• T1018 Remote System Discovery | An ADSI query identifies Windows Server computers and performs a ping sweep.
• T1069.002 Permission Groups Discovery: Domain Groups | The net group “domain admins” /domain command is used for enumeration.
• T1482 Domain Trust Discovery | nltest /domain_trusts and /dclist: are used for domain enumeration.
• T1087.002 Account Discovery: Domain Account | An ADSI searcher enumerates user descriptions.
• T1082 System Information Discovery | systeminfo is used with multilingual findstr filters.

Command and Control

• T1572 Protocol Tunneling | A reverse WebSocket tunnel communicates over TLS with gitnow[.]dev:443.
• T1071.001 Application Layer Protocol: Web Protocols | Command-and-control communication occurs over HTTPS/WebSocket.
• T1105 Ingress Tool Transfer | A Python runtime and implant kit are downloaded and extracted.

Indicators of Compromise (IOCs)

File indicators

Network indicators

Learn more

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

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

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

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

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

The post TerminalFix campaign deploys a reverse tunnel through multistage intrusion 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.

Every organization needs security that protects end to end with the speed and scale of AI. Microsoft’s vision is simple: security should be ambient and autonomous, just like the AI it protects.

As organizations scale AI and expand across environments, security teams need protection that covers every surface. This month’s updates help security and IT teams secure their AI environments, use AI to defend at speed and scale, and strengthen the foundations that AI-powered operations depend on. Here’s what’s new:

Project Perception brings agentic defense to security operations

Project Perception, newly announced, is a coordinated system of specialized agents, cybersecurity-focused models, and enterprise-wide signals that transform how security operates. The agents work as a team: red team agents expose weaknesses, blue team agents investigate cyberthreats, and green agents harden what’s found. These multi-agent autonomous workflows work as a team to operate in continuous loops to execute end-to-end security workflows.

Microsoft Defender secures the full AI attack surface, from inbox to cloud

Expanded Microsoft Defender protections are designed to reduce risks associated with day-to-day AI interactions, from email inboxes to cloud agent environments. New prompt injection protection in Microsoft Defender, now in preview, identifies and isolates emails containing malicious AI instructions before delivery, reducing the risk of prompt injection attacks reaching the inbox. Unified Defender posture and runtime protection for cloud agents in Microsoft Agent 365 consolidates security posture assessment and runtime protection for Microsoft Foundry, Microsoft Copilot Studio, and third party-managed agents, helping teams reduce AI-specific risk across the agent estate.

Accelerate detection, prioritization, and response with AI embedded in SecOps workflows

Security teams can accelerate detection, prioritization, and response to cyberthreats with AI embedded directly into security operations (SecOps) workflows through Microsoft Defender. Threat intelligence enhancements, including Microsoft Defender Threat Intelligence convergence and an enhanced Threat Intelligence Agent, bring more out-of-the-box intelligence and automation into the unified SecOps workflow, so teams can move from summary to action.

Strengthen the cloud, code, and identity foundations AI depends on

Microsoft Defender is strengthening the foundational protections that AI-era operations depend on across cloud, code, and identity. Cloud Security Posture Management extends coverage to serverless containers, giving teams visibility and continuous posture assessment across containerized workloads running on Azure Container Apps, Azure Container Instances, and Amazon Web Services Elastic Container Service (AWS ECS) on Fargate. New interconnected experiences between Defender and Microsoft Entra empower the security operations center (SOC) to disable compromised identities directly using a role-based access control (RBAC) mode that maintains least privilege. Microsoft Defender Experts services are also expanding: Microsoft Defender Experts Threat Intelligence delivers human-led, curated insight into the cyberthreats most relevant to each organization, and Microsoft Defender Experts MDR extends expert-run detection and response beyond the Microsoft estate into third-party and multicloud signals through Microsoft Sentinel.

Microsoft Entra strengthens identity across the AI-powered enterprise

Strengthen identity foundations for AI-powered operations

New capabilities in Microsoft Entra are designed to strengthen the identity foundations that AI-powered operations depend on. Tenant governance helps organizations discover, manage, and govern tenants across their environment with centralized policies and cross-tenant delegated administration. Microsoft Entra ID is making passkeys the default authentication experience, which helps reduce reliance on SMS and voice, strengthens phishing-resistant security, and makes for an easier transition away from Microsoft-provided telecom delivery, which will retire in 2027. Through new interconnected Entra and Defender experiences, identity and access management and SOC teams share user experience, RBAC, and agentic workflows that eliminate product seams so identity and security operations can work together.

Protect sensitive data in motion across software as a service (SaaS) and AI apps with Microsoft Purview and Microsoft Entra

Microsoft Purview now integrates with Microsoft Entra Internet Access to extend data security to the network layer, enabling real-time protection of sensitive data shared with unmanaged cloud and AI apps over the network. For example, when an employee attempts to upload sensitive customer data or proprietary information, including text and files, into shadow AI apps, sharing is detected and blocked before the data is leaked from the organization. Organizations now have a unified Microsoft solution to gain visibility into where organizational data is shared externally, to detect and block sensitive data in transit, and to enable consistent data protection across their environment without relying on third-party solutions.

Microsoft Purview strengthens data security, compliance, and investigation for AI

A new Microsoft Purview Data Loss Prevention (DLP) for Microsoft 365 Copilot protection, available in preview, now gives data security teams greater control over how Copilot leverages email content, given external sources can introduce sensitive, third-party, or unvetted information that organizations may not want to rely on. Now admins can exclude emails from external senders from being referenced, summarized, or used as grounding data for Copilot. For example, with this DLP policy in place, an employee working with an external collaborator can still rely on Copilot to leverage internal insights, while external conversations are automatically excluded from Copilot-generated responses. With the native integration between Microsoft Purview and Microsoft 365 Copilot, organizations can extend controls to AI interactions with minimal additional configuration, resulting in a more predictable and policy-aligned AI environment.

A new centralized Microsoft Purview Insider Risk Management alert experience simplifies the prioritization of the most pressing data risks by bringing agentic alert triage, enriched user details, and expanded analysis capabilities (such as notes infused on the Insider Risk Management case) into a single view. Helping power this experience, the Data Security Triage Agent includes an advanced AI reasoning layer, now generally available, that performs deeper, multi-step analysis across user, device, and data activity signals to surface the incidents most likely to require investigation while reducing noise. Analysts can filter across classic and Data Security Triage Agent attributes on a single page, preview agent summaries and user details without switching views, and document findings while the system automatically records status changes and escalations to maintain a clear investigation history. Together, the Insider Risk Management alert experience and Data Security Triage Agent help security teams investigate faster and with greater confidence.

Advanced endpoint management now broadly available

As of July 1, 2026, the capabilities of the Microsoft Intune Suite are included in Microsoft 365 E5, with select capabilities also available in Microsoft 365 E3, bringing advanced endpoint management to more organizations without added cost. IT and security teams can now apply advanced endpoint management capabilities to reduce standing admin rights, modernize certificate management, resolve issues quickly, streamline app delivery, and bring AI into workflows with Microsoft Security Copilot in Intune. Together, these capabilities strengthen the endpoint foundations that AI-powered operations depend on. See everything that’s now included in your plan and how to start putting it to work.

Stay In the Loop

Microsoft Security is focused on delivering innovations across our portfolio, along with research-driven insights and reports for the security community. In the Loop posts are your reliable source of what’s new across Microsoft Security and what it means for your security strategy. Check back for the next drop.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post ​​​​What’s new in Microsoft Security: July 2026 appeared first on Microsoft Security Blog.