Microsoft has identified an active supply chain attack targeting the @antv node package manager (npm) package ecosystem. A threat actor compromised an @antv maintainer account and published malicious versions of widely used data-visualization packages, resulting in cascading downstream impact.
The compromise propagated through dependency chains into libraries like echarts-for-react (which has more than 1 million weekly downloads), expanding the blast radius into CI/CD pipelines and cloud workloads across the ecosystem. The malicious payload—a ~499 KB obfuscated JavaScript file—runs silently during npm install and is purpose-built to steal credentials from GitHub Actions environments.
Key capabilities observed in the payload include multi-platform credential theft (GitHub, Amazon Web Services, HashiCorp Vault, npm, Kubernetes, 1Password), GitHub Action Runner process memory scraping, privilege escalation, dual-channel data exfiltration, and Supply chain Levels for Software Artifacts (SLSA) provenance forgery. These capabilities suggest a deliberate effort to evade analysis and an apparent focus on CI/CD environments.
The authors of the antv account have also since confirmed in a ticket on the repo that the situation is now resolved.
Attack chain overview
Figure 1. @antv npm supply chain attack flow.
The @antv organization maintains charting libraries (G2, G6) embedded across dashboards and applications. The attack proceeds through:
Maintainer account compromise and publication of malicious @antv package versions
Downstream dependency amplification (echarts-for-react, size-sensor, and others)
Automatic payload execution through a preinstall hook during npm install
Execution chain: node → shell → bun → payload (Bun runtime installed if absent)
Technical analysis
The payload replaces the legitimate index.js with a single-line obfuscated script.
Obfuscation
Layer 1: 1,732 Base64-encoded strings in a rotated array, decoded through lookup function with the shuffle key 0xa31de
Layer 2: Critical strings such as command-and-control (C2) domain and env var names are encrypted with a custom PBKDF2 and SHA-256 cipher, which is decrypted at runtime.
Environment gating: The payload exits immediately if it’s not running on GitHub Actions on Linux
Branch avoidance: Skips the main, master, dependabot/, renovate/, and gh-pages when using Git API exfiltration
// Layer 1: 1,732 strings in rotated array with base64 decode
(function(_0x44be0e, _0x3ff020){
// Array shuffle IIFE with key 0xa31de
_0x335af4['push'](_0x335af4['shift']());
})(_0x71ec, 0xa31de));
// Layer 2: PBKDF2+SHA256 runtime decryption for critical strings
var e6 = "a8269c01069452afb8a54de904e6419578d155fdbdb9e566bab8576a4266b61e";
var t6 = "7f44e4ba6f6a71bd0f789e7f83bd3104";
var u5 = new du(e6, t6); // PBKDF2 cipher instance
globalThis["f2959c600"] = function(s) { return u5.decode(s); };
// Environment gate - exits if not GitHub Actions on Linux
this['isGitHubActions'] = process.env[f2959c600('68zz23c6NGR9...')] === 'true';
this['isLinuxRunner'] = process.env[f2959c600('NhUrwwYEwYIJ...')] === 'Linux';
Credential theft
The payload targets secrets across six platforms:
GitHub: Extracts GITHUB_TOKEN, scans for Personal Access Tokens (gh[op]_) and installation tokens (ghs_), validates through /user API, and enumerates repo and org secrets.
Amazon Web Services(AWS): Queries Instance Metadata Service (169.254.169[.]254), Elastic Container Service metadata (169.254.170[.]2), reads .aws/ files, harvests env vars, and then calls SecretsManager across all regions.
HashiCorp Vault: Searches 12+ token paths (/var/run/secrets/vault/token, ~/.vault-token, and others) and connects to a local Vault at 127.0.0[.]1:8200.
npm: Validates tokens using /-/whoami, exchanges OpenID Connect (OIDC) tokens for publish access, and enumerates packages
Kubernetes: Reads service account tokens and enumerates namespace secrets
1Password: Interacts with command-line interface (CLI) and attempts master password extraction with two-factor authentication (2FA) bypass
// Injects passwordless sudo via /etc/sudoers.d bind mount at /mnt
echo 'runner ALL=(ALL) NOPASSWD:ALL' >
&& chmod 0440 /mnt/runner
// DNS manipulation
sudo sh -c "echo '127.0.0.1 ' >> /etc/hosts"
// Validates sudo access before operations
sudo -n true
Exfiltration
Dual-channel exfiltration:
Primary: HTTPS to encrypted C2 domain (port 443) with DNS pre-check and health probe
Fallback: Git Data API — Creates blobs, trees, or commits in victim repositories on non-protected branches
Tertiary: Creates public repos under victim accounts with reversed description (“niagA oG eW ereH :duluH-iahS”); more than 2,200 of these repos have been observed as of this writing
SLSA provenance forgery erodes trust in supply chain attestation frameworks
How GitHub took action to prevent further harm
Upon learning of the attack, GitHub acted immediately to limit further damage. It removed 640 malicious packages and invalidated 61,274 npm granular access tokens with write permissions and 2FA bypass, preventing leaked tokens from being used in this or similar attacks. GitHub also published advisories relevant to this malware campaign in the GitHub Advisory Database and alerted the community through Dependabot alerts and npm audit. It continues to monitor for additional affected packages and remove them as needed.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat:
Review dependency trees for direct or transitive usage of affected @antv/ packages.
Identify systems that installed or built affected package versions during the suspected exposure window.
Pin known-good package versions where possible and avoid automatic dependency upgrades until validation is complete.
Disable pre- and post-installation script execution by ensuring you run npm install with --ignore-scripts.
While GitHub team has already invalidated all the npm tokens that had write access and 2FA bypass, Microsoft Defender still recommends rotating credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
Rotate credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed in affected build or developer environments.
Audit organization and personal GitHub accounts for public repositories with the description “niagA oG eW ereH :duluH-iahS” or other unexpected repositories created during the exposure window, and revoke any GitHub tokens that might have been implicated.
Audit CI/CD logs for unexpected outbound network connections, script execution, or suspicious package lifecycle activity.
Review npm package lockfiles, build logs, and artifact provenance for evidence of compromised package versions.
Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments.
Use Microsoft Defender Vulnerability Management to search for antv packages across your estate.
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.
Tactic
Observed activity
Microsoft Defender coverage
Execution
Suspicious script execution during npm install or package lifecycle activity
Microsoft Defender for Endpoint – Suspicious usage of Bun runtime – Suspicious Installation of Bun runtime – Suspicious Node.js process behavior
Credential Access
Potential harvesting of environment variables, tokens, or developer secrets
Microsoft Defender for Endpoint – Credential access attempt – Suspicious cloud credential access by npm-cached binary – Kubernetes secrets enumeration indicative of credential access
Microsoft Defender for Cloud Sha1-Hulud Campaign Detected: Possible command injection to exfiltrate credentials
Command and Control
Potential outbound connections from build systems or developer machines
Microsoft Defender for Endpoint Connection to a custom network indicator
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate incident response or investigation tasks related to this threat, including:
Incident investigation
Microsoft user analysis
Threat Intelligence 360 report based on MDTI article
Vulnerability or supply chain impact assessment
Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.
The following sample queries let you search for a week’s worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days.
Hunt for suspicious npm lifecycle script execution
This query searches for Node.js and npm activity involving install lifecycle behavior and relevant package references.
Hunt for potential compromise of through malicious npm packages
DeviceProcessEvents
| where Timestamp > ago(2d)
| where FileName in ("bun", "bun.exe")
| where ProcessCommandLine has "run index.js"
Hunt for affected dependencies in your software inventory
DeviceTvmSoftwareInventory
| where SoftwareName has "antv" or SoftwareVendor has "antv"
| project DeviceName, OSPlatform, SoftwareVendor, SoftwareName, SoftwareVersion
Hunt for suspicious outbound connection from python backdoor
DeviceNetworkEvents
| where Timestamp > ago(2d)
| where InitiatingProcessFileName startswith "python"
| where InitiatingProcessCommandLine has "/cat.py"
Hunt for suspicious outbound activity from Node.js processes
Searches for network connections initiated by Node.js or npm processes that reference package-related paths or commands.
DeviceNetworkEvents
| where Timestamp > ago(2d)
| where RemoteUrl has "t.m-kosche.com"
Shai-Hulud npm supply-chain indicator observed inside a Kubernetes container
CloudProcessEvents
| where ProcessCommandLine has_any ("IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner", "niagA oG eW ereH", ":duluH-iahS", "t.m-kosche.com", "7cb42f57561c321ecb09b4552802ae0ac55b3a7a", "@antv/setup")
| project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName
Indicators of Compromise (IOC)
Indicator
Type
Description
@antv – whole account
Package scope
All packages maintained by the antv account were compromised.
As per the latest statement from the account author’s this situation is now resolved.
echarts-for-react
Package name
One of the major downstream packages impacted by the antv compromise. As per the latest statement from the repository author’s this situation is now resolved
This research is provided by Microsoft Defender Security Research with contributions from Rahul Mohandas, Sumith Maniath, Ahmed Saleem Kasmani, Arvind Gowda, Sagar Patil, and members of Microsoft Threat Intelligence.
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.
Logs and telemetry are the foundation of modern cybersecurity. They enable threat detection, incident response, forensic investigation, and compliance across endpoints, networks, and cloud environments. Yet, despite their importance, high‑quality security attack logs are notoriously difficult to collect, especially at scale.
Real‑world security telemetry is often composed of repeated benign activity occurring across environments and with very rare malicious activity. Gathering, labeling, and maintaining datasets with real attack logs is costly and operationally challenging. It requires not only labeling malicious activities, but also fully reconstructing attack scenarios. These challenges significantly slow detection engineering and limit the quality of both the rule-based detection authoring and anomaly-detection approaches.
In this post, we explore a different path: using AI to generate realistic, high‑fidelity synthetic security attack logs. By translating attacker behaviors, expressed as tactics, techniques, and procedures (TTPs)—directly into structured telemetry, we aim to accelerate detection development while preserving realism and security.
Why is this work important for Microsoft Defender customers?
For Microsoft Defender customers, this work is crucial because it directly addresses the challenge of obtaining high-quality, realistic security attack logs needed for effective threat detection and response. By leveraging AI-driven synthetic log generation, organizations can accelerate the development of detection rules and AI-based automation approaches, while ensuring privacy and reducing operational overhead. Synthetic logs enable customers to simulate a broader range of attack scenarios—including rare and emerging threats—without exposing sensitive data or relying on costly lab-based simulations. Ultimately, this approach enhances the agility and effectiveness of Microsoft Defender detection and response capabilities, helping customers stay ahead of evolving cyber threats.
Why Synthetic Security Logs in addition to Lab Simulations?
Synthetic data has been widely adopted in various fields as a privacy-conscious substitute for real data, and it offers even greater advantages in cybersecurity. It enables the creation of safe, shareable datasets that avoid exposure of sensitive customer information, allows simulation of rare or emerging attacks that are challenging to observe in real environments, accelerates the process of detection engineering and testing, and supports reproducible experiments for benchmarking and evaluation.
While synthetic logs are not a replacement for all lab-based validation, they can complement lab simulations by speeding up early-stage detection design, testing, and coverage expansion. Traditionally, generating realistic attack telemetry requires executing real attacks in controlled lab environments. While accurate, this approach is slow, labor‑intensive, and difficult to scale. It also limits agility for the security teams responsible for defending our systems and delays the rollout of new threat detections into production. This blog examines whether AI-assisted synthetic log generation can provide similar fidelity, without the operational overhead of lab‑based attack execution.
Core Idea: From TTPs to Logs
Attackers can abuse TTP through various actions that exploit different processes. At a high level, the proposed workflow consumes “TTP + Action” as input and produces structured security logs as output.
Input: High‑level attacker TTPs from the MITRE ATT&CK framework [1], a widely used knowledge base of adversary tactics and techniques, and concrete attacker actions. See the example below.
Tactic
Technique
Action
Stealth
T1202 – Indirect Command Execution
The attackers executed forfiles and obfuscated their actions using variable expansion of %PROGRAMFILES and hex characters (for example, 0x5d). They obfuscated the use of echo, open, read, find, and exec to extract file contents, then passed the output to a Python interpreter for execution.
Output: Realistic log entries with correctly populated fields such as “Command Line”, “Process Name”, “Parent Process Name”, and other relevant telemetry fields.
Goal: The goal is not to reproduce logs verbatim, but to generate realistic, semantically correct logs that would accurately trigger detections, mirroring real attacker behavior.
Approaches for Synthetic Attack Log Generation
We explore three increasingly sophisticated techniques for generating logs.
Prompt‑Engineered Generation: Our baseline approach uses a series of carefully designed expert‑crafted prompts. The workflow comprises a structured, multi‑stage dialogue:
Prompting: The model is given a detailed attack scenario and context.
Iterative Generation: Logs are generated across multiple turns to maintain coherence.
Evaluation: An independent large language model (LLM)-as-a-Judge assesses realism and consistency.
As depicted in the following image, the prompts explicitly instruct the model to reason like a cybersecurity researcher, leverage MITRE ATT&CK knowledge, and produce coherent attack narratives.
Diagram that shows a three-stage AI agent pipeline: prompting for attack scenarios, iterative generation of logs, and LLM-as-a-Judge evaluation.
Agentic Workflow-based Generation: While the first approach works well in simpler cases, it struggles with complex, multi‑stage scenarios. To address these limitations, we introduced an agentic workflow using three specialized agents focused on different tasks:
Generator Agent: Produces an initial set of logs based on the input.
Evaluator Agent: Reviews logs and provides structured feedback.
Improver Agent: Suggests targeted refinements based on feedback.
As depicted in the image below, these agents collaborate in an iterative loop (generate, evaluate, improve), allowing the system to correct errors, fill gaps, and refine details over multiple turns. This collaborative process significantly improves log completeness and fidelity, especially for complex attack chains.
Diagram that shows a cyclical agentic workflow where generator, evaluator, and improver agents collaborate to produce synthetic telemetry logs.
Multi-Turn Reinforcement Learning with Verifiable Rewards: While the synthetic logs generated by the agentic workflow are often semantically correct, preserving key properties like parent‑child process relationships and event ordering, they still differ noticeably from real event logs, especially in process paths, command‑line arguments, service names and so on. This limits the usage of these logs to test detection efficacy; effective detection engineering requires reliably distinguishing benign activity from malicious behavior. To address this challenge, we conduct experiments using Reinforcement Learning with Verifiable Rewards (RLVR). Instead of rigid rewards used by the evaluator agent in the previous agentic workflow approach, we use partial rewards to learn the policies as follows:
We use an LLM‑as‑a‑Judge as follows to compare the synthesized data against ground‑truth logs.
The model only awards partial rewards based on semantic alignment and imposes a penalty if the generated string is not an exact match of the ground-truth logs, producing a more context-aware and flexible reward signal to guide the learning process.
The judge also produces reasoning, making evaluations transparent, and auditable.
Diagram that shows the LLM-as-a-Judge evaluation comparing generated logs to ground truth, issuing rewards or penalties to drive policy updates.
While this direction of research shows a lot of promise, it is heavily dependent on the amount of labeled training data. To address this limitation, we applied data augmentations, including:
Paraphrasing attack narratives while preserving technical intent
This allowed us to scale from hundreds to thousands of training examples.
Evaluation Datasets
To ensure our approach generalizes across environments and attack types, we evaluated it on three complementary datasets:
Goal‑Driven (GD) Campaigns: These are tightly scoped datasets produced by repeatable attack simulations conducted by our threat researchers. GDs are built around a specific security objective (e.g., detecting credential dumping on Windows servers). They provide clean ground truth and well‑defined attacker actions. We used a total of 10 different GD executions to evaluate our approaches.
Security Datasets Project: An open‑source initiative [2] that provides malicious and benign datasets from multiple platforms, enabling broader evaluation and generalizability across different environments.
ATLASv2 Dataset: The ATLASv2 dataset [3] is comprised of Windows Security Auditing logs, Sysmon logs, Firefox logs, and Domain Name System (DNS) telemetry. These logs are generated across two Windows VMs by executing 10 multi‑stage attack scenarios and introducing realistic noise and cross‑host behaviors. We limited the evaluation of synthetic attack logs to malicious activity during the attack windows.
Note: The external datasets from the Security Datasets Project and ATLASv2 are used strictly for research and validation of our log generation methods. These datasets are not used in the development, training, or deployment of any commercial products.
Evaluation
Methodology: We evaluated the prompt engineering and agentic workflow approach on the three datasets across multiple reasoning and non‑reasoning models, using recall as our primary metric. Recall measures the model’s ability to generate semantically relevant log instances (true positives) expected for a given attack scenario. Our LLM‑as‑a‑Judge performs flexible matching, focusing on:
New process name
Parent process name
Command line semantics
For example, a synthetic log containing “forfiles.exe” can successfully match a ground‑truth entry with the full path “D:\Windows\System32\forfiles.exe”.
Key Results: The results in experimental evaluation demonstrate that prompt-only approaches establish a baseline but show inconsistent performance. The agentic workflows deliver dramatic recall improvements across all datasets. Reasoning models, combined with agentic refinement, achieve the highest fidelity.
Finally, our experiments training reinforcement learning approaches conclude that while it shows a significant promise, a substantial amount of labeled data will be required for the agent to learn effective policies to make the synthetic data identical to benign logs.
Table 1 and Table 2 report the performance of the prompt-based and agentic workflow-based approaches, respectively. For reasoning models (o1, o3 and o3-mini), we report the recall values using a Medium reasoning effort. Overall, agentic collaboration emerges as the most effective technique for high‑quality synthetic attack logs generation.
Table 1: Recall values for prompt-based log generation.Table 2: Recall values for agentic workflow-based log generation.
Across the evaluation datasets we used, AI‑driven synthetic log generation shows strong potential to produce semantically meaningful logs from TTPs and attacker actions. It can capture multi‑event sequences, preserve parent‑child process relationships, and generate realistic command lines.
This capability can accelerate detection engineering by reducing dependence on costly lab setups and enabling rapid experimentation, without sacrificing realism or safety. Our early experiments with reinforcement learning with verifiable rewards also look promising and could improve verbatim alignment when sufficient training data is available.
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.
Microsoft Threat Intelligence recently uncovered a methodical, sophisticated, and multi-layered attack, where a threat actor we track as Storm-2949 launched a relentless campaign with a singular focus: to exfiltrate as much sensitive data from a target organization’s high-value assets as possible. The attack exfiltrated data from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments, where the organization’s production application ecosystem resides.
What began as a targeted identity compromise rapidly evolved into a full-spectrum assault on the organization’s cloud infrastructure. The attack spanned various Azure resources, with emphasis on software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS) layers.
Storm-2949 didn’t rely on traditional malware and other on-premises tactics, techniques, and procedures (TTPs). Instead, they leveraged legitimate cloud and Azure management features to gain control-plane and data-plane access, which they then used to execute code remotely on VMs, and access sensitive cloud resources such as Key Vaults and storage accounts, among others. These activities allowed them to move laterally across cloud and endpoint environments while blending into expected administrative behavior.
As organizations continue to adopt cloud infrastructure at scale, threat actors are increasingly targeting identity and control plane access rather than individual devices. When cloud identities are compromised, legitimate administrative features can be used to achieve outcomes similar to traditional lateral movement, often with fewer indicators of compromise. Behavior-based detections across endpoints, cloud environments, and identities—such as those provided by Microsoft Defender—can help teams identify and correlate these activities.
In this blog, we unpack the full attack chain from initial access to cloud and endpoint takeover. We then offer actionable insights into how organizations can detect, contain, and prevent similar identity-driven threats in their environments.
Attack chain overview
The campaign that Storm-2949 deployed can be divided into two phases: targeted identity compromise and cloud infrastructure compromise. We discuss each of these phases in detail in the succeeding sections.
Figure 1. Storm-2949 attack diagram.
Cloud compromise: Microsoft Entra ID and Microsoft 365
In this phase, the threat actor targeted specific users through social engineering to obtain their Microsoft Entra ID credentials. Using these credentials, the threat actor then proceeded to exfiltrate data from Microsoft 365 applications.
Initial access and persistence through targeted social engineering and SSPR abuse
We assess with high confidence that Storm-2949 leveraged a social engineering technique consistent with known abuses of Microsoft’s Self-Service Password Reset (SSPR) process. In such attacks, a threat actor initiates the SSPR process on behalf of a targeted user and subsequently employs social engineering tactics to persuade the user to complete multifactor authentication (MFA) prompts that appear to be legitimate.
For example, the threat actor might impersonate an internal information technology (IT) support representative and contact the user claiming that their account requires urgent verification, instructing them to approve MFA prompts as part of a routine password reset procedure.
Once the user approves these prompts, the threat actor is able to reset the user’s password and remove existing authentication methods, such as phone numbers, email addresses, and Microsoft Authenticator registrations, effectively eliminating MFA as a control and enabling unrestricted account access. Immediately after gaining access to the compromised account, the threat actor is then prompted to re-enable MFA and register a new authentication method. At this stage, the threat actor enrolls Microsoft Authenticator on their own device, granting themselves persistent access and preventing the legitimate user from signing in.
Storm-2949 used a similar process repeatedly across multiple users within the targeted organization. The selection of victims, which included IT personnel and senior leadership, indicated deliberate targeting. Based on the roles of the compromised users and the investigation findings, we assess that the threat actor likely used an organized and convincing phishing scheme to lure users into completing the fraudulent MFA prompts and thereby compromise their identities.
Directory discovery and persistence
Following the initial identity takeover, the threat actor conducted directory discovery using Microsoft Graph API. Using a custom Python script, they issued automated API requests to enumerate users and applications within the tenant. Through these queries, the threat actor searched Microsoft Entra ID for user accounts based on name patterns and role attributes, likely to identify privileged identities and additional high‑value targets.
Figure 2 illustrates the types of Graph API queries observed:
Figure 1. Discovery using cURL.
During this attack phase, the threat actor also attempted to establish persistence by adding credentials to a compromised service principal to enable continued access independent of the compromised user accounts. This attempt failed due to insufficient permissions. Undeterred, the threat actor continued enumerating service principals and known application identifiers, indicating an effort to map application‑level access paths and expand long‑term footholds within the environment. Using the same social engineering techniques and SSPR abuse described earlier, the threat actor expanded their foothold by compromising three additional cloud user accounts.
Microsoft 365 discovery and exfiltration
Storm-2949 leveraged their access to the compromised user accounts to explore and exfiltrate files from the victim organizations’ cloud file storage services. Shortly after obtaining initial access within the organization, they targeted Microsoft 365 applications, including OneDrive and SharePoint, identifying and accessing the organization’s sensitive files, focusing on IT documents concerning virtual private network (VPN) configurations and remote access procedures. We assess that this behavior reflects an attempt to identify opportunities for lateral movement from a compromised cloud identity into the endpoint network.
The threat actor then launched a large-scale data exfiltration from these storage services. In one instance, Storm-2949 used the OneDrive web interface to download thousands of files in a single action to their own infrastructure. This pattern of data theft was repeated across all compromised user accounts, likely because different identities had access to different folders and shared directories.
Cloud compromise: Microsoft Azure
Armed with access to multiple compromised identities – which were assigned with privileged custom Azure role-based access control (RBAC) roles on several Azure subscriptions – and a growing understanding of the environment, the threat actor shifted focus toward the victim’s Azure environment. With a clear agenda centered on data exfiltration, Storm-2949 demonstrated a relentless drive to uncover and extract the most sensitive assets within the victim’s Azure environment, specifically from production-based Azure subscriptions.
Their campaign targeted not only core applications but also the broader ecosystem of interconnected resources such as Azure App Services web applications, Azure Key Vaults, Azure Storage accounts, and SQL databases. These resources collectively power the organization’s cloud-hosted services. This phase marked a transition from identity-centric abuse and SaaS data theft to targeting a range of Azure services, with an emphasis on both PaaS and IaaS workloads.
Azure App Service and Key Vault compromise
One of Storm-2949’s main targets was a production Azure App Service web application that contained sensitive data. Following several failed attempts to access this application, likely due to gateway and network restrictions, Storm-2949 shifted focus to other web apps that appeared to be part of the same ecosystem. These auxiliary apps, such as those handling authentication or internal APIs, were individually deployed Azure App Service instances with their own resource identities.
Storm-2949 successfully compromised several of these secondary web apps by taking advantage of the user’s privileged Azure RBAC permissions and invoking the Azure management-plane operation, microsoft.Web/sites/publishxml/action, which retrieves the application’s publishing profile. This profile often contains basic authentication credentials for deployment endpoints such as FTP, Web Deploy, and the Kudu management console. Kudu is a built-in administrative interface for Azure App Services that allows authenticated users to browse the file system, inspect environment variables, and execute commands within the app’s context.
Despite successfully compromising several of these auxiliary web apps, Storm-2949 was unable to gain access to the primary production application they were ultimately targeting. It is assesed, that the secondary services, while part of the same broader ecosystem, didn’t contain the level of sensitive data or privileged access the threat actor was seeking. While these footholds provided visibility into application configurations and infrastructure, they didn’t deliver the high-value assets that aligned with the threat actor’s data exfiltration objectives. As a result, the threat actor was forced to pursue alternative paths in their effort to reach the production web app.
Storm-2949 recalibrated their approach and shifted their focus toward backend resources that were part of the sensitive web app ecosystem and could provide stronger leverage. The threat actor pivoted to the organization’s Azure Key Vault estate – an environment more likely to centralize sensitive secrets and offer indirect access to production systems. Part of the compromised user’s Azure RBAC permissions was the privileged Owner role over a specific Key Vault that seemed to contain credentials that would enable the compromise of the production application.
Over the span of four minutes, the threat actor successfully manipulated Key Vault access configurations and accessed dozens of secrets within the said Key Vault. These secrets included database connection strings, identity credentials, and more, dramatically expanding the attack’s blast radius.
Among these secrets, we believe the threat actor found credentials that enabled them to access the application they coveted the most, which was the main production web app. After they successfully authenticated into the web app, the threat actor changed its password to retain control. They then began exfiltrating sensitive data from it.
Azure Storage and SQL data exfiltration
In parallel, Storm-2949 expanded access across additional cloud resources inside the ecosystem that contained the web app, including Azure Storage accounts and an Azure SQL server.
To enable access to the server, the threat actor abused their existing Azure RBAC permissions to manipulate the SQL server firewall rules by using the microsoft.sql/servers/firewallrules/write operation. They then connected to the SQL server using the credentials they obtained (along with the web app credentials) from the compromised Key Vault.
The threat actor proceeded with data exfiltration and continued to delete the modified SQL firewall rules, which is an activity consistent with defense evasion. Similar to the SQL server compromise, to set up and prepare for massive data exfiltration from Azure Storage, the threat actor also manipulated storage account network access configurations using the microsoft.storage/storageaccounts/write operation. This manipulation enabled public access to the storage accounts from a closed set of threat actor-owned IP addresses. In addition, the threat actor abused the Azure management-plane operation microsoft.Storage/storageAccounts/listkeys/action to access multiple storage account Shared Access Signature (SAS) tokens and account keys, enabling the use of static, non-interactive authentication to retrieve data.
Using these keys, the threat actor downloaded large volumes of data from several Azure Storage accounts using a custom Python script that leveraged the Azure SDK for Storage. The script allowed them to programmatically enumerate and download blobs directly to their own endpoint device. This storage‑based exfiltration continued over multiple days since the initial access, with the threat actor alternating between secret- and OAuth‑based authentication as access conditions and controls evolved.
Azure Virtual Machines compromise
Apart from the web app and data-store resource compromise, the abuse of Azure Virtual Machine (VM) extensions and administrative features – specifically Run Command and the VMAccess extension – were also prominent elements of this attack. These activities appear to have been primarily intended to expand operational access within the victim environment by leveraging compromised VMs as intermediary footholds. Observed actions across these systems focused on credential harvesting and environment discovery, as well as attempts to access resources that weren’t directly reachable through previously compromised identities. These efforts included domain reconnaissance and the collection of authentication material that could facilitate movement between cloud and on‑premises environments, as well as enable access to additional high‑value assets.
Shortly after the initial access, the threat actor operated in parallel, trying to compromise the organization’s virtual machines. Using the compromised users assigned with privileged Azure RBAC permissions, the threat actor deployed the VMAccess extension to create a new local administrator account on a targeted VM. VMAccess is an Azure VM extension intended to help administrators restore access to a VM when credentials get lost or misconfigured by allowing password resets or the addition of privileged local users through the Azure management plane. In this case, the threat actor abused the extension to gain backdoor access to an administrator user on the VM.
Using the Run Command feature, the threat actor deployed a script attempting to abuse the VM’s managed identity by requesting an access token from the Azure Instance Metadata Service (IMDS) and using it to authenticate to – and retrieve secrets from – the production web app-related Key Vault. However, the threat actor wasn’t able to retrieve the secrets because the managed identity lacked the required permissions. Yet, this attempt shows the threat actor using guest-level execution as a bridge to additional Azure resource access through workload identity.
Figure 2. Token theft and Key Vault access script.
ScreenConnect installation and defense evasion
Storm-2949 further abused the Run Command by running a PowerShell script intended to deploy persistent remote access while reducing host-based security visibility on multiple VMs.
The script attempted to weaken Microsoft Defender Antivirus by disabling several protections, including real-time protection and behavior monitoring, and by interfering with its associated service. These changes lowered the likelihood that subsequent activity would be blocked or generate actionable alerts on the device.
The script then installed the ScreenConnect remote monitoring and management (RMM) tool obtained from threat actor-controlled infrastructure. The installation process included several steps intended to masquerade the tool’s presence, such as making the network request appear consistent with trusted software updates and placing files in locations intended to resemble legitimate system content.
To further obscure the tool’s presence, the script attempted to rename or configure the installed service to resemble legitimate Windows components, providing a simple form of local masquerading.
Finally, the script attempted cleanup actions to remove local forensic artifacts that could be attributed to the threat actor. These included clearing Windows event logs, removing execution artifacts, and deleting command history and temporary files. Such steps are commonly observed in post-compromise activity and are generally intended to complicate investigation rather than provide durable evasion.
Post-compromise activity using ScreenConnect
The threat actor used the deployed ScreenConnect to launch commands across multiple compromised devices, performing basic discovery. This included collecting host level details (for example, operating system and configuration information) and enumerating domain context such as user accounts and group memberships.
Across a subset of those hosts, the threat actor focused on credential harvesting techniques. They discovered and exfiltrated .pfx certificate files – artifacts that might contain private keys and could be valuable for follow-on access if imported or reused elsewhere. In parallel, they searched for remote file shares for likely credential exposure by scanning files for password related strings. Not every collection effort occurred on every host; rather, it was distributed across systems based on what data and access each host provided.
These actions show ScreenConnect being used as a practical execution channel to run discovery, collect credentials, and attempt to operationalize access across different devices.
While the threat actor ultimately established execution on several endpoints, these systems didn’t appear to yield high value data aligned with their objectives. The endpoint activity primarily served as a secondary capability for discovery and credential harvesting, rather than a core exfiltration channel.
Throughout this incident, Microsoft Defender generated multiple alerts that helped analysts piece together activity across endpoints and cloud. Defender correlated these signals into unified incidents, surfacing high-fidelity alerts and a coherent view of threat actor activity. This kind of cross-domain correlation – collecting and normalizing telemetry and linking related alerts – illustrates the value of an integrated detection and response approach for improving signal-to-noise clarity and end-to-end visibility.
Mitigation and protection guidance
The visibility provided by correlated alerts across identities, cloud, and endpoints can help organizations investigate and understand attacks end-to-end. Building on this visibility, organizations can reduce risk and limit the impact of similar attacks by deploying appropriately scoped detection and response capabilities (including Microsoft Defender where applicable) and by applying targeted hardening practices.
Ensure adequate security coverage across attack surfaces
To effectively detect and respond to attacks that span identity, cloud, and endpoint environments, organizations should ensure they have monitoring, detection, and response capabilities deployed and properly configured across those surfaces. The following examples describe how Microsoft Defender capabilities can be used to help with this; equivalent controls might be available in other security solutions.
Use Microsoft Defender for Endpoint for:
Tamper protection enabled to prevent threat actors from stopping security services such as Defender for Endpoint, which can help prevent hybrid cloud environment attacks.
Endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t 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 detected post-breach.
Investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to help remediate alerts, significantly reducing alert volume.
In addition, leverage the Microsoft Defender XDR to hunt for threats across cloud environments and resource with advanced hunting. Security teams can proactively investigate threat actor activity by querying telemetry across multiple domains using tables such as CloudAuditEvents, CloudStorageAggregatedEvents, and others, enabling deep visibility into control-plane and data-plane operations, authentication events, and cross-service attack patterns.
In addition to deploying the appropriate Defender capabilities, organizations should apply the following security controls and practices to mitigate similar attack paths:
Identity protection
Secure accounts with credential hygiene. Practice the principle of least privilege and audit privileged account activity in your Microsoft Entra ID and Azure environments to slow or stop threat actors.
Enable Conditional Access policies. Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.
Ensure MFA is required for all users. Adding more authentication methods, such as the Microsoft Authenticator app or a phone number, increases the level of protection if one factor is compromised.
Configure and harden resources firewall rules and access controls to allow access only from trusted IP ranges and virtual networks to prevent unauthorized access.
Use Azure policies to continuously enforce the hardened configurations.
Use Azure policies for Azure Storage to prevent network and security misconfigurations and maximize the protection of business data stored in your storage accounts.
Enable immutable storage for Azure Blob Storage to protect from accidental or malicious modification or deletion of blobs or storage accounts.
Enable Azure Monitor for Azure Blob Storage to collect, aggregate, and log data to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.
Enable logs in Azure Key Vault and retain them for up to a year to enable recreation of activity trails for investigation purposes when a security incident occurs or network is compromised.
Restrict public network access to Azure Key Vault by enabling private endpoints and disabling public access to reduce exposure to unauthorized access attempts.
Regularly audit Azure RBAC role assignments and Key Vault access policies, depending on the Key Vault permission model, to ensure least privilege and detect over-permissioned identities. Microsoft explicitly recommends Azure RBAC over Key Vault access policies.
Configure SQL server firewall rules to restrict access to known IP addresses and monitor for unauthorized changes to firewall configurations.
Practice and apply Azure App Service security best practices:
Disable legacy authentication methods and enforce managed identity usage for Azure App Services to prevent credential theft through publishing profiles.
Monitor and restrict access to Azure App Service publishing credentials by limiting RBAC permissions and auditing usage of the publish profile API.
Enable diagnostic logging in App Service logs to detect suspicious deployment or configuration changes.
Enable Microsoft Azure Backup for virtual machines to protect the data on your Microsoft Azure virtual machines, and to create recovery points that are stored in geo-redundant recovery vaults.
Audit and restrict the use of Azure VM features and extensions such as Run Command and VMAccess by limiting RBAC permissions and monitoring for suspicious invocation patterns.
IOCs reflect observations at the time of analysis and may not be exhaustive or persistent.
Indicator
Type
Description
176.123.4[.]44
IP address
Attacker egressed from this address
91.208.197[.]87
IP address
Attacker egressed from this address
185.241.208[.]243
IP address
ScreenConnect instance used by Attacker
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.
Note that the following detections only covers the threat activities we’ve observed at the time of analysis.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
– Sign-in activity from attacker infrastructure to compromised identities
– Sign-in and authentication activity to Azure resources
Microsoft Defender XDR – Authentication with compromised credentials – Compromised user account in a recognized attack pattern – Malicious sign in from a risky IP address – Malicious sign in from an IP address associated with recognized attacker infrastructure – Malicious sign in from recognized attacker infrastructure – Malicious sign-in from an unusual user agent – Malicious sign-in from known threat actor IP address – Successful authentication from a malicious IP – Successful authentication from a suspicious IP – Successful authentication using compromised credentials – User compromised through session cookie hijack – User signed in from a known malicious IP Address – Impossible Travel
Microsoft Defender for Identity – Possibly compromised user account signed in – Possibly compromised service principal account signed in
Microsoft Defender for Cloud Defender for Resource Manager Suspicious invocation of a high-risk ‘Initial Access’ operation detected (Preview)
Defender for Databases Login from an unusual location
Defender for Storage – Access from an unusual location to a storage account Access from an unusual location to a storage blob container – Access from an unusual location to a sensitive blob container – Access from a known suspicious IP address to a sensitive blob container – Access from a suspicious IP address – Unusual unauthenticated public access to a sensitive blob container
Execution
– Various types of execution-related suspicious activity by an attacker were observed
Microsoft Defender XDR – Possibly compromised user ran a malicious script using an Azure VM extension – Potential hybrid ransomware or hands-on-keyboard attack originating from Azure VM extensions – Hybrid ransomware or hands-on-keyboard attack originating from Azure VM extensions – Azure VM extension activity followed by ransomware or hands-on-keyboard attack
Microsoft Defender for Cloud Defender for Resource Manager – Suspicious invocation of a high-risk ‘Execution’ operation detected (Preview) – Azure Resource Manager operation from suspicious IP address – Suspicious Run Command invocation detected (Preview)
Defender for Servers P2 – Run Command with a suspicious script was detected on your virtual machine – Suspicious Run Command usage was detected on your virtual machine (Preview) – Suspicious unauthorized Run Command usage was detected on your virtual machine (Preview)
Microsoft Defender for Endpoint – Compromised account conducting hands-on-keyboard attack – Potential human-operated malicious activity – Suspicious process execution – Suspicious command execution via ScreenConnect – Suspicious activity through Azure VM extension process
Persistence
– Attacker device registered as MFA method
– ScreenConnect installed on Azure VMs
Microsoft Defender for Identity – Suspicious addition of default third‑party MFA method to user account – Suspicious Entra device join or registration
Microsoft Defender for Cloud Apps – Suspicious addition of device with strong MFA – Suspicious addition of strong authentication device – Malicious device with strong MFA was registered
Microsoft Defender for Endpoint Uncommon remote access software
Defense evasion
– Attempts to tamper with Microsoft Defender Antivirus
– Manipulation of Azure Storage account, Key Vault, and SQL database configurations
Microsoft Defender for Endpoint – Attempt to turn off Microsoft Defender Antivirus protection – Attempt to clear event log – Event log was cleared
Microsoft Defender for Cloud Defender for Resource Manager Suspicious invocation of a high-risk ‘Defense Evasion’ operation detected (Preview)
Defender for Key Vault Suspicious policy change and secret query in a key vault
Credential access
– Secret extraction from Azure Key Vault
– Attempted theft of workload identity tokens using Azure VM Run Command
– Credential harvesting from endpoints through ScreenConnect
– Publishing Azure App Service web app profile for credential access
– Listing Azure storage account access keys for access
Microsoft Defender for Endpoint – Indication of local security authority secrets theft – Password stealing from files
Microsoft Defender for Cloud Defender for Resource Manager Suspicious invocation of a high-risk ‘Credential Access’ operation detected (Preview)
Defender for Servers P2 Run Command with a suspicious script was detected on your virtual machine
Defender for Key Vault – Suspicious policy change and secret query in a key vault – High volume of operations in a key vault – Unusual application accessed a key vault – Unusual operation pattern in a key vault – Unusual user accessed a key vault – Access from a suspicious IP address to a key vault
Discovery
– Domain and system discovery commands run on virtual machines
Microsoft Defender for Endpoint Suspicious sequence of exploration activities
Microsoft Defender for Cloud Apps Suspicious file access
Lateral movement
– Traversal between cloud resources and applications
Microsoft Defender for Identity Suspicious sign-in to a web app following MFA phone number tampering activity
Microsoft Defender for Cloud Apps Compromised user accessed a SaaS application
Microsoft Defender for Cloud Defender for Resource Manager Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)
Exfiltration
– Data exfiltration from Azure Storage accounts and other resources
– Data exfiltration from file storage services
Microsoft Defender XDR Suspicious behavior: Mass download
Microsoft Defender for Cloud Apps – Suspicious massive data read – Suspicious mass download from risky or unusual session – Suspicious mass download from risky or unusual session – Suspicious mass download from risky or unusual session – Possible exfiltration of data archive – Possible data exfiltration from a suspicious IP address – Suspicious quantity of downloaded archive files
Microsoft Defender for Cloud Defender for Resource Manager Suspicious invocation of a high-risk ‘Data Collection’ operation detected (Preview)
Defender for Storage – The access level of a potentially sensitive storage blob container was changed to allow unauthenticated public access – Publicly accessible storage containers successfully discovered – Publicly accessible storage containers unsuccessfully scanned – Unusual amount of data extracted from a storage account – Unusual data access activity – Unusual amount of data extracted from a sensitive blob container – Unusual number of blobs extracted from a sensitive blob container – Potential data exfiltration detected – Access from a suspicious IP address
This research is provided by Microsoft Defender Security Research with contributions from Adi Segal, Karam Abu Hanna, Alon Marom, and members of Microsoft Threat Intelligence.
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.
AI and agentic application deployments on cloud-native platforms are increasing, and they often prioritize speed over secure configuration. Our observations from aggregated and anonymized Microsoft Defender for Cloud signals showed cases where AI services were publicly exposed with weak or missing authentication, creating exploitable misconfigurations that attackers actively abused. These issues enabled low-effort, high-impact outcomes such as remote code execution, credential theft, and access to sensitive internal tools and data.
Exploitable misconfigurations bypass traditional vulnerability models, allowing threat actors to leverage them without using sophisticated techniques or zero-days. Organizations should therefore surface these misconfigurations early to reduce their attack surface and protect their critical AI workloads. Defender for Cloud can help customers identify and prioritize risks associated with such misconfigurations by detecting exposed Kubernetes services and unsafe deployment patterns.
In this blog, we look at examples of exploitable misconfigurations we’ve observed in some of the popular AI applications and platforms. We also provide practical guidance on how to deploy AI agents securely.
Background
AI and agentic applications are being rolled out at scale, moving rapidly from experimentation to broadly deployed systems. These applications are no longer isolated components; rather, they sit at the center of workflows, automation, and decision-making across organizations.
Based on our observation of the aggregated and anonymized signals coming from Microsoft Defender for Cloud, many of the AI deployments in real-world environments run on cloud-native infrastructure, with Kubernetes emerging as the preferred operating layer for AI workloads. This finding aligns with Cloud Native Computing Foundation’s research, which shows that organizations rely heavily on Kubernetes clusters to run their AI workloads.
As AI applications become connected to more internal systems and data sources, the impact of mistakes increases: a single misconfiguration could not only expose an application endpoint, it could also allow access to sensitive data, infrastructure, or operational capabilities behind it.
In practice, many of the most dangerous risks in AI environments don’t come from novel attack techniques or zero-day vulnerabilities. Instead, they stem from exploitable misconfigurations—user’s configuration choices that make powerful capabilities externally reachable when insufficiently protected, creating clear paths to abuse.
What is an exploitable misconfiguration?
We use the term exploitable misconfiguration to describe a configuration issue where public exposure (for example, an internet-reachable user interface or API) is combined with missing or weak authentication and authorization. This combination creates a practical attack path that could result in serious outcomes such as remote code execution (RCE), sensitive data exposure, or tampering with pipelines and artifacts, often without requiring complex exploitation.
Exploitable misconfigurations create low-effort paths to high-impact compromises, making hardening more than a nice-to-have. Defender for Cloud signals indicate that more than half of cloud-native workload exploitations, including AI applications, stem from misconfigurations. In that context, remediation becomes a race against the clock: organizations need to fix these issues quickly or attackers will leverage them first.
Exploitable misconfigurations in popular AI applications
In the following sections, we discuss examples of exploitable misconfigurations found in popular applications and platforms across the AI and agentic ecosystem.
MCP servers
The Model Context Protocol (MCP) lets AI agents discover and interact with external tools and data sources in a standardized way. MCP servers can be installed locally or accessed remotely, with support for Server-Sent Events (SSE) and streamable HTTP. While this protocol supports authorization mechanisms, including OAuth, it doesn’t enforce them. As a result, misconfigured MCP servers become a critical and easily exploitable issue in AI and agentic environments.
We’ve observed multiple instances of remotely exposed MCP servers being deployed without authentication. In these instances, unauthenticated access allowed direct interaction with sensitive internal tools, including ticketing systems, HR systems, and private code repositories. This issue results from insecure MCP server implementations that execute tool actions in the server’s security context, instead of the context of the user (or agent). Signals from Defender for Cloud shows that 15% of remote MCP servers are severely insecure and allow unauthenticated access to sensitive internal data and operational capabilities.
Mage AI
Mage AI is an open-source platform for building, running, and orchestrating data and AI pipelines. We found that when Mage AI is deployed on Kubernetes using the official Helm chart, the default installation exposed the application through an internet-facing LoadBalancer on port 6789 with no authentication enabled. The exposed web UI included functionality for executing shell commands, allowing arbitrary code execution inside the application using the mounted service account. In the default configuration, this service account was bound to highly privileged roles that effectively granted cluster-admin capabilities. This default setup was observed in the wild and was actively exploited, resulting in unauthenticated, internet-accessible shell access with high privileges.
Figure 1. Dumping a token of a privileged service account attached to a Mage AI workload.
Through responsible disclosure, we reported this issue to Mage AI, and authentication is now enabled by default. We’d like to thank Mage AI for responding to and addressing this issue.
kagent
kagent is an open-source framework under CNCF’s CNAI landscape that’s designed to run AI agents on Kubernetes. When deployed using the official Helm chart, kagent comes with various AI agents configured as Kubernetes services, such as the k8s-agent, which assists with cluster operations. A user could then talk to the AI agent and ask it to perform operations (for example, deploy a privileged pod) on the Kubernetes cluster.
While kagent isn’t publicly exposed by default, it does lack authentication by default, which means that if this application is exposed publicly, anonymous users would be able to ask the AI agents to deploy malicious and privileged workloads. These workloads could then facilitate cluster-to-cloud lateral movements. Using this unauthenticated access, the attackers could also exfiltrate credentials from other workloads running on the cluster and configure malicious models and AI agents, among others, in the kagent application.
Figure 2 shows how threat actors could exfiltrate API keys for AI services supported by kagent, such as Azure OpenAI API keys, simply by interacting with the AI agent:
Figure 2. Exfiltrating Azure OpenAI API keys stored in kagent model configurations, which are stored as Base64-encoded Kubernetes secrets.
Microsoft AutoGen Studio
AutoGen Studio is a low‑code agentic framework for building multi‑agent workflows. It lets users configure agent skills, assign models, and design the workflows that coordinate tasks across agents. Microsoft AutoGen Studio ships without authentication enabled by default:
Figure 3. Screenshot of AutoGen Studio documentation.
AutoGen Studio isn’t publicly exposed by default. However, an attacker could tamper with components, deploy malicious agent configurations, or extract API keys from linked AI services on exposed ones, as shown in Figure 4:
Figure 4. Publicly exposed AutoGen Studio exposing API keys of AI services in plaintext.
Minimizing the risk: Practical deployment guidance
AI applications are at risk of misconfiguration as organizations race to adopt and integrate AI capabilities. Teams deploy agents, connect models to internal tools, and operationalize data pipelines, often stitching together new components on top of existing infrastructure. In such scenarios, speed might get prioritized over secure defaults, least-privilege access, and proper isolation. At the same time, code and configuration are increasingly produced through vibe coding, where AI-assisted code might get generated using weak security practices. These factors could result in AI applications getting deployed with insecure configurations, which could then lead to severe consequences.
Apart from the applications discussed previously, we’ve observed instances misconfigurations in the following AI applications in the wild:
With AI systems being adopted and integrated at a rapid pace, the question is no longer whether to use AI, but how to deploy it safely. Organizations should ensure that their security controls are keeping pace, and that they start treating AI services like any other high-impact workload, not as experimental tooling:
Public access is a security choice: Some AI services need to be internet-facing, but public access should be an explicit decision and protected with authentication, authorization, and appropriate network controls.
Enforce authentication and authorization everywhere: Apply authentication controls consistently, including internal AI services and tool endpoints.
Context and least privilege: Workloads should operate in the context of an authenticated user or agent, not under broad service-level identities. Permissions should be scoped to the minimum required.
Continuously audit AI workloads: Track what AI services exist, what they can access, and how they are exposed as systems evolve.
How Microsoft Defender for Cloud helps detect exposures in Kubernetes
Exploitable misconfigurations are a reminder that many breaches in cloud-native environments don’t start with a zero-day, they start with something reachable that shouldn’t be, paired with improper access controls.
If such misconfigured AI applications are exposed publicly, often through Kubernetes Services, Microsoft Defender for Containers customers can benefit from detection capabilities through the alert Exposed Kubernetes service detected. This alert identifies the creation or update of Kubernetes load-balancer services that expose these applications, helping teams prioritize the issues that represent the highest impact and lowest-effort paths for attackers.
Figure 5. Exposed services alert for publicly exposed kagent application.
This research is provided by Microsoft Defender Security Research with contributions from Yossi Weizman, Tushar Mudi, and members of Microsoft Threat Intelligence.
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.
Logs and telemetry are the foundation of modern cybersecurity. They enable threat detection, incident response, forensic investigation, and compliance across endpoints, networks, and cloud environments. Yet, despite their importance, high‑quality security attack logs are notoriously difficult to collect, especially at scale.
Real‑world security telemetry is often composed of repeated benign activity occurring across environments and with very rare malicious activity. Gathering, labeling, and maintaining datasets with real attack logs is costly and operationally challenging. It requires not only labeling malicious activities, but also fully reconstructing attack scenarios. These challenges significantly slow detection engineering and limit the quality of both the rule-based detection authoring and anomaly-detection approaches.
In this post, we explore a different path: using AI to generate realistic, high‑fidelity synthetic security attack logs. By translating attacker behaviors, expressed as tactics, techniques, and procedures (TTPs)—directly into structured telemetry, we aim to accelerate detection development while preserving realism and security.
Why is this work important for Microsoft Defender customers?
For Microsoft Defender customers, this work is crucial because it directly addresses the challenge of obtaining high-quality, realistic security attack logs needed for effective threat detection and response. By leveraging AI-driven synthetic log generation, organizations can accelerate the development of detection rules and AI-based automation approaches, while ensuring privacy and reducing operational overhead. Synthetic logs enable customers to simulate a broader range of attack scenarios—including rare and emerging threats—without exposing sensitive data or relying on costly lab-based simulations. Ultimately, this approach enhances the agility and effectiveness of Microsoft Defender detection and response capabilities, helping customers stay ahead of evolving cyber threats.
Why Synthetic Security Logs in addition to Lab Simulations?
Synthetic data has been widely adopted in various fields as a privacy-conscious substitute for real data, and it offers even greater advantages in cybersecurity. It enables the creation of safe, shareable datasets that avoid exposure of sensitive customer information, allows simulation of rare or emerging attacks that are challenging to observe in real environments, accelerates the process of detection engineering and testing, and supports reproducible experiments for benchmarking and evaluation.
While synthetic logs are not a replacement for all lab-based validation, they can complement lab simulations by speeding up early-stage detection design, testing, and coverage expansion. Traditionally, generating realistic attack telemetry requires executing real attacks in controlled lab environments. While accurate, this approach is slow, labor‑intensive, and difficult to scale. It also limits agility for the security teams responsible for defending our systems and delays the rollout of new threat detections into production. This blog examines whether AI-assisted synthetic log generation can provide similar fidelity, without the operational overhead of lab‑based attack execution.
Core Idea: From TTPs to Logs
Attackers can abuse TTP through various actions that exploit different processes. At a high level, the proposed workflow consumes “TTP + Action” as input and produces structured security logs as output.
Input: High‑level attacker TTPs from the MITRE ATT&CK framework [1], a widely used knowledge base of adversary tactics and techniques, and concrete attacker actions. See the example below.
Tactic
Technique
Action
Stealth
T1202 – Indirect Command Execution
The attackers executed forfiles and obfuscated their actions using variable expansion of %PROGRAMFILES and hex characters (for example, 0x5d). They obfuscated the use of echo, open, read, find, and exec to extract file contents, then passed the output to a Python interpreter for execution.
Output: Realistic log entries with correctly populated fields such as “Command Line”, “Process Name”, “Parent Process Name”, and other relevant telemetry fields.
Goal: The goal is not to reproduce logs verbatim, but to generate realistic, semantically correct logs that would accurately trigger detections, mirroring real attacker behavior.
Approaches for Synthetic Attack Log Generation
We explore three increasingly sophisticated techniques for generating logs.
Prompt‑Engineered Generation: Our baseline approach uses a series of carefully designed expert‑crafted prompts. The workflow comprises a structured, multi‑stage dialogue:
Prompting: The model is given a detailed attack scenario and context.
Iterative Generation: Logs are generated across multiple turns to maintain coherence.
Evaluation: An independent large language model (LLM)-as-a-Judge assesses realism and consistency.
As depicted in the following image, the prompts explicitly instruct the model to reason like a cybersecurity researcher, leverage MITRE ATT&CK knowledge, and produce coherent attack narratives.
Diagram that shows a three-stage AI agent pipeline: prompting for attack scenarios, iterative generation of logs, and LLM-as-a-Judge evaluation.
Agentic Workflow-based Generation: While the first approach works well in simpler cases, it struggles with complex, multi‑stage scenarios. To address these limitations, we introduced an agentic workflow using three specialized agents focused on different tasks:
Generator Agent: Produces an initial set of logs based on the input.
Evaluator Agent: Reviews logs and provides structured feedback.
Improver Agent: Suggests targeted refinements based on feedback.
As depicted in the image below, these agents collaborate in an iterative loop (generate, evaluate, improve), allowing the system to correct errors, fill gaps, and refine details over multiple turns. This collaborative process significantly improves log completeness and fidelity, especially for complex attack chains.
Diagram that shows a cyclical agentic workflow where generator, evaluator, and improver agents collaborate to produce synthetic telemetry logs.
Multi-Turn Reinforcement Learning with Verifiable Rewards: While the synthetic logs generated by the agentic workflow are often semantically correct, preserving key properties like parent‑child process relationships and event ordering, they still differ noticeably from real event logs, especially in process paths, command‑line arguments, service names and so on. This limits the usage of these logs to test detection efficacy; effective detection engineering requires reliably distinguishing benign activity from malicious behavior. To address this challenge, we conduct experiments using Reinforcement Learning with Verifiable Rewards (RLVR). Instead of rigid rewards used by the evaluator agent in the previous agentic workflow approach, we use partial rewards to learn the policies as follows:
We use an LLM‑as‑a‑Judge as follows to compare the synthesized data against ground‑truth logs.
The model only awards partial rewards based on semantic alignment and imposes a penalty if the generated string is not an exact match of the ground-truth logs, producing a more context-aware and flexible reward signal to guide the learning process.
The judge also produces reasoning, making evaluations transparent, and auditable.
Diagram that shows the LLM-as-a-Judge evaluation comparing generated logs to ground truth, issuing rewards or penalties to drive policy updates.
While this direction of research shows a lot of promise, it is heavily dependent on the amount of labeled training data. To address this limitation, we applied data augmentations, including:
Paraphrasing attack narratives while preserving technical intent
This allowed us to scale from hundreds to thousands of training examples.
Evaluation Datasets
To ensure our approach generalizes across environments and attack types, we evaluated it on three complementary datasets:
Goal‑Driven (GD) Campaigns: These are tightly scoped datasets produced by repeatable attack simulations conducted by our threat researchers. GDs are built around a specific security objective (e.g., detecting credential dumping on Windows servers). They provide clean ground truth and well‑defined attacker actions. We used a total of 10 different GD executions to evaluate our approaches.
Security Datasets Project: An open‑source initiative [2] that provides malicious and benign datasets from multiple platforms, enabling broader evaluation and generalizability across different environments.
ATLASv2 Dataset: The ATLASv2 dataset [3] is comprised of Windows Security Auditing logs, Sysmon logs, Firefox logs, and Domain Name System (DNS) telemetry. These logs are generated across two Windows VMs by executing 10 multi‑stage attack scenarios and introducing realistic noise and cross‑host behaviors. We limited the evaluation of synthetic attack logs to malicious activity during the attack windows.
Note: The external datasets from the Security Datasets Project and ATLASv2 are used strictly for research and validation of our log generation methods. These datasets are not used in the development, training, or deployment of any commercial products.
Evaluation
Methodology: We evaluated the prompt engineering and agentic workflow approach on the three datasets across multiple reasoning and non‑reasoning models, using recall as our primary metric. Recall measures the model’s ability to generate semantically relevant log instances (true positives) expected for a given attack scenario. Our LLM‑as‑a‑Judge performs flexible matching, focusing on:
New process name
Parent process name
Command line semantics
For example, a synthetic log containing “forfiles.exe” can successfully match a ground‑truth entry with the full path “D:\Windows\System32\forfiles.exe”.
Key Results: The results in experimental evaluation demonstrate that prompt-only approaches establish a baseline but show inconsistent performance. The agentic workflows deliver dramatic recall improvements across all datasets. Reasoning models, combined with agentic refinement, achieve the highest fidelity.
Finally, our experiments training reinforcement learning approaches conclude that while it shows a significant promise, a substantial amount of labeled data will be required for the agent to learn effective policies to make the synthetic data identical to benign logs.
Table 1 and Table 2 report the performance of the prompt-based and agentic workflow-based approaches, respectively. For reasoning models (o1, o3 and o3-mini), we report the recall values using a Medium reasoning effort. Overall, agentic collaboration emerges as the most effective technique for high‑quality synthetic attack logs generation.
Table 1: Recall values for prompt-based log generation.Table 2: Recall values for agentic workflow-based log generation.
Across the evaluation datasets we used, AI‑driven synthetic log generation shows strong potential to produce semantically meaningful logs from TTPs and attacker actions. It can capture multi‑event sequences, preserve parent‑child process relationships, and generate realistic command lines.
This capability can accelerate detection engineering by reducing dependence on costly lab setups and enabling rapid experimentation, without sacrificing realism or safety. Our early experiments with reinforcement learning with verifiable rewards also look promising and could improve verbatim alignment when sufficient training data is available.
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.
A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques.
Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections.
This article details an ongoing investigation into active campaign. We will update this report as new details emerge. Latest update: May 14, 2026.
May 14 update
A new variant of the recent Dirty Frag vulnerability, named Fragnesia (CVE-2026-46300), has been discovered. Similarly to Dirty Frag, this variant leverages a different bug to be able to manipulate Linux page cache behavior to achieve privilege escalation. Fragnesia leverages a bug in the esp/xfrm module only, unlike Dirty Frag that also provided an attack path via rxrpc.
Signatures Trojan:Linux/DirtyFrag.Z!MTB and Trojan:Linux/DirtyFrag.DA!MTB, released initially to cover Dirty Frag, also cover the public exploit for Fragnesia and can be used as indicators of a possible abuse of this vulnerability. A patch is available, and while no in-the-wild exploitation has been observed at this time, we urge users and organizations to apply the patch as soon as possible by running update tools. If patching is not possible at this point, consider applying the same mitigations for Dirty Frag.
Why Dirty Frag matters
Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access.
Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments.
This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces.
Technical overview
Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability.
The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads.
Exploitation scenarios
Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including:
Compromised SSH accounts
Web-shell access on internet-facing applications
Container escapes into the host environment
Abuse of low-privileged service accounts
Post-exploitation activity following phishing or remote access compromise
Once local access is established, successful exploitation may allow attackers to escalate privileges to root and gain broad control over the affected Linux host.
Limited In-The-Wild Exploitation
Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either “Dirty Frag” or “Copy Fail”.
The campaign shows a sequential attack timeline where an external connection gains SSH access and spawns an interactive shell, followed by staging and execution of an ELF binary (./update) that immediately triggers a privilege escalation via ‘su’.
After gaining elevated access, the actor modifies a GLPI LDAP authentication file (evidenced by a .swp file from vim), performs reconnaissance of the GLPI directory and system configuration, and inspects an exploit artifact. The activity then shifts to accessing sensitive data and interacting with PHP session files — first deleting multiple session files and then forcefully wiping additional ones — before reading remaining session data, indicating both disruption of active sessions and access to session contents.
Mitigation guidance
The Linux Kernel Organization released patches, which are linked at the National Vulnerability Database (NVD), to fix CVE-2026-43284 on May 8, 2026. Customers who have not applied these patches are urged to do so as soon as possible. As of May 8, 2026, patches for CVE-2026-43500 are not available. CVE-2026-43500 is reportedly reserved for the RxRPC issue but is not yet published in NVD.
While comprehensive remediation guidance continues to evolve, organizations should evaluate interim mitigations immediately.
Recommended actions include:
Disable unused rxrpc kernel modules where operationally possible
Assess whether esp4, esp6, and related xfrm/IPsec functionality can be temporarily disabled safely
Restrict unnecessary local shell access
Harden containerized workloads
Increase monitoring for abnormal privilege escalation activity
Prioritize kernel patch deployment once vendor advisories are released
The following example prevents vulnerable modules from loading and unloads active modules where possible:
cat /dev/null
These mitigations should be carefully evaluated before deployment, particularly in environments relying on IPsec VPNs or RxRPC functionality.
Post-mitigation integrity verification
Mitigation alone may not reverse changes already introduced through successful exploitation attempts.
If exploitation occurred prior to mitigation, malicious modifications may persist in memory or cached file content even after vulnerable modules are disabled. Organizations should validate the integrity of critical files and assess whether cache clearing is appropriate for their environment.
echo 3 | sudo tee /proc/sys/vm/drop_caches
Cache clearing can temporarily increase disk I/O and impact production performance and should be evaluated carefully before deployment.
Microsoft Defender coverage
Microsoft Defender XDR customers can refer to the following list of applicable detections below that provides coverage for behaviors surrounding “Dirty Frag” exploitation.
Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Microsoft Defender for Endpoint – Suspicious SUID/SGID process launch
Microsoft Defender for Cloud – Potential exploitation of dirtyfrag vulnerability detected
Microsoft Defender Vulnerability Management – Microsoft Defender Vulnerability Management surfaces devices vulnerable to “Dirty Frag” which are linked to the following CVEs:
CVE-2026-43284 CVE-2026-43500 CVE-2026-46300
Advanced hunting query
Customers can use this advanced hunting query to surface possible exploitation.
let fragnesia = DeviceProcessEvents
| where Timestamp >= ago(1d)
| where ProcessCommandLine has "fragnesia"
| distinct DeviceId
;
let lpeModuleTerms = dynamic(["algif-skcipher","net-pf-38","crypto-seqiv(rfc4106(gcm(aes)))","xfrm-type-10-50"]);
DeviceProcessEvents
| where Timestamp >= ago(1d)
| where DeviceId in (fragnesia)
| where ProcessCommandLine has_any (lpeModuleTerms)
| distinct DeviceId
Microsoft Defender Threat Intelligence
Microsoft Defender Threat Intelligence published a threat analytics article and a vulnerability profile for this vulnerability
A newly disclosed Linux local privilege escalation vulnerability known as “Dirty Frag” enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500). Public reporting and proof-of-concept activity indicate the exploit is designed to provide more reliable privilege escalation than traditional race-condition-dependent Linux local privilege escalation techniques.
Dirty Frag may be leveraged after initial compromise through SSH access, web-shell execution, container escape, or compromise of a low-privileged account. Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments. Microsoft Defender is actively monitoring related activity and investigating additional detections and protections.
This article details an ongoing investigation into active campaign. We will update this report as new details emerge.
Why Dirty Frag matters
Local privilege escalation vulnerabilities are frequently used by threat actors after initial access to expand control over a compromised environment. Once root access is obtained, attackers can disable security tooling, access sensitive credentials, tamper with logs, pivot laterally, and establish persistent access.
Dirty Frag is notable because it introduces multiple kernel attack paths involving rxrpc and esp/xfrm networking components to improve exploitation reliability. Rather than relying on narrow timing windows or unstable corruption conditions often associated with Linux local privilege escalation exploits, Dirty Frag appears designed to increase consistency across vulnerable environments.
This increases operational risk in environments where threat actors already possess limited local execution capability through compromised accounts, vulnerable applications, containers, or exposed administrative interfaces.
Technical overview
Dirty Frag abuses Linux kernel networking and memory-fragment handling behavior involving esp4, esp6, and rxrpc components. Similar to the previously disclosed CopyFail vulnerability (CVE-2026-31431), the exploit attempts to manipulate Linux page cache behavior to achieve privilege escalation. However, Dirty Frag introduces additional attack paths that expand exploitation opportunities and improve reliability.
The vulnerability affects systems where vulnerable modules are present and accessible. In many enterprise environments, these components may already be enabled to support IPsec, VPN functionality, or other networking workloads.
Exploitation scenarios
Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including:
Compromised SSH accounts
Web-shell access on internet-facing applications
Container escapes into the host environment
Abuse of low-privileged service accounts
Post-exploitation activity following phishing or remote access compromise
Once local access is established, successful exploitation may allow attackers to escalate privileges to root and gain broad control over the affected Linux host.
Limited In-The-Wild Exploitation
Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either “Dirty Frag” or “Copy Fail”.
The campaign shows a sequential attack timeline where an external connection gains SSH access and spawns an interactive shell, followed by staging and execution of an ELF binary (./update) that immediately triggers a privilege escalation via ‘su’.
After gaining elevated access, the actor modifies a GLPI LDAP authentication file (evidenced by a .swp file from vim), performs reconnaissance of the GLPI directory and system configuration, and inspects an exploit artifact. The activity then shifts to accessing sensitive data and interacting with PHP session files — first deleting multiple session files and then forcefully wiping additional ones — before reading remaining session data, indicating both disruption of active sessions and access to session contents.
Mitigation guidance
The Linux Kernel Organization released patches, which are linked at the National Vulnerability Database (NVD), to fix CVE-2026-43284 on May 8, 2026. Customers who have not applied these patches are urged to do so as soon as possible. As of May 8, 2026, patches for CVE-2026-43500 are not available. CVE-2026-43500 is reportedly reserved for the RxRPC issue but is not yet published in NVD.
While comprehensive remediation guidance continues to evolve, organizations should evaluate interim mitigations immediately.
Recommended actions include:
Disable unused rxrpc kernel modules where operationally possible
Assess whether esp4, esp6, and related xfrm/IPsec functionality can be temporarily disabled safely
Restrict unnecessary local shell access
Harden containerized workloads
Increase monitoring for abnormal privilege escalation activity
Prioritize kernel patch deployment once vendor advisories are released
The following example prevents vulnerable modules from loading and unloads active modules where possible:
cat /dev/null
These mitigations should be carefully evaluated before deployment, particularly in environments relying on IPsec VPNs or RxRPC functionality.
Post-mitigation integrity verification
Mitigation alone may not reverse changes already introduced through successful exploitation attempts.
If exploitation occurred prior to mitigation, malicious modifications may persist in memory or cached file content even after vulnerable modules are disabled. Organizations should validate the integrity of critical files and assess whether cache clearing is appropriate for their environment.
echo 3 | sudo tee /proc/sys/vm/drop_caches
Cache clearing can temporarily increase disk I/O and impact production performance and should be evaluated carefully before deployment.
Microsoft Defender coverage
Microsoft Defender XDR customers can refer to the following list of applicable detections below that provides coverage for behaviors surrounding “Dirty Flag” exploitation.
Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Microsoft Defender for Endpoint – Suspicious SUID/SGID process launch
Microsoft Defender for Cloud – Potential exploitation of dirtyfrag vulnerability detected
Microsoft Defender Vulnerability Management – Microsoft Defender Vulnerability Management surfaces devices vulnerable to “Dirty Frag” which are linked to the following CVEs: CVE-2026-43284 CVE-2026-43500
Microsoft Defender Threat Intelligence
Microsoft Defender Threat Intelligence published a threat analytics article and a vulnerability profile for this vulnerability
AI agents have fundamentally changed the threat model of AI model-based applications. By equipping these models with plugins (also called tools), your agents no longer just generate text; they now read files, search connected databases, run scripts, and perform other tasks to actively operate on your network.
Because of this, vulnerabilities in the AI layer are no longer just a content issue and are an execution risk. If an attacker can control the parameters passed into these plugins via prompt injection, the agent may be driven to perform actions beyond its intended use.
The AI model itself isn’t the issue as it’s behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data.
To build powerful applications, developers rely heavily on frameworks like Semantic Kernel, LangChain, and CrewAI. These frameworks act as the operating system for AI agents, abstracting away complex model orchestration. But this convenience comes with a hidden cost: because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk.
As part of our mission to make AI systems more secure and eliminate new class of vulnerabilities, we’re launching a research series focused on identifying vulnerabilities in popular AI agent frameworks. Through responsible disclosure, we work with maintainers to ensure issues are addressed before sharing our findings with the community.
In this post, we share details on the vulnerabilities we discovered in Microsoft’s Semantic Kernel, along with the steps we took to address them and interactive way to try it yourself. Stay tuned for upcoming blogs where we’ll dive into similar vulnerabilities found in frameworks beyond the Microsoft ecosystem.
Background
We discovered a vulnerable path in Microsoft Semantic Kernel that could turn prompt injection into host-level remote code execution (RCE).
A single prompt was enough to launch calc.exe on the device running our AI agent, with no browser exploit, malicious attachment, or memory corruption bug needed. The agent simply did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code.
Figure 1. Illustration of CVE-2026-26030 exploitation using a local model.
This scenario is the real security story behind modern AI agents. Once an AI model is wired to tools, prompt injection draws a thin line between being just a content security problem and becoming a code execution primitive. In this post in our research series on AI agent framework security, we show how two vulnerabilities in Semantic Kernel could allow attackers to cross that line, and what customers should do to assess exposure, patch affected agents, and investigate whether exploitation may already have occurred.
A representative case study: Semantic Kernel
Semantic Kernel is Microsoft’s open-source framework for building AI agents and integrating AI models into applications. With over 27,000 stars on GitHub, it provides essential abstractions for orchestrating AI models, managing plugins, and chaining workflows.
During our security research into the Semantic Kernel framework, we identified and disclosed two critical vulnerabilities: CVE-2026-25592 and CVE-2026-26030. These flaws, which have since been fixed, could allow an attacker to achieve unauthorized code execution by leveraging injection attacks specifically targeted at agents built within the framework.
In the following sections, we break down the mechanics of these vulnerabilities in detail and provide actionable guidance on how to harden your agents against similar exploitation.
CVE-2026-26030: In-Memory Vector Store
Exploitation of this vulnerability requires two conditions:
The attacker must have a prompt injection vector, allowing influence over the agent’s inputs
The targeted agent must have the Search Plugin backed by In-Memory Vector Store functionality using the default configuration
When both these two conditions are met, the vulnerability enables an attacker to achieve RCE from a prompt.
To demonstrate how this vulnerability could be exploited, we built a “hotel finder” agent using Semantic Kernel. First, we created an In Memory Vector collection to store the hotels’ data, then exposed a search_hotels(city=…) function to the kernel (agent) so that the AI model could invoke it through tool calling.
Figure 2. Semantic Kernel agent configured with In-Memory Vector collection.
When a user inputs, for example, “Find hotels in Paris,” the AI model calls the search plugin with city=”Paris”. The plugin then first runs a deterministic filter function to narrow down the dataset and computes vector similarity (embeddings).
With this understanding of how a Semantic Kernel agent performs the search, let’s dive deep into the vulnerability.
Issue 1: Unsafe string interpolation
The default filter function that we mentioned previously is implemented as a Python lambda expression executed using eval(). In our example, The default filter will result to new_filter = “lambda x: x.city == ‘Paris'”.
Figure 3. Default filtering function definition.
The vulnerability is that kwargs[param.name] is AI model-controlled and not sanitized. This acts as a classic injection sink. By closing the quote (‘) and appending Python logic, an attacker could turn a simple data lookup into an executable payload:
Input:‘ or MALICIOUS_CODE or ‘
Result:lambda x: x.city == ” or MALICIOUS_CODE or ”
Issue 2: Avoidable blocklist
The framework developers anticipated this RCE risk and implemented a validator that parses the filter string into an Abstract Syntax Tree (AST) before execution.
Figure 4. Blocklist implementation.
Before running a user-provided filter code, the application runs a validation function designed to block unsafe operations. At a high level, the validation does the following:
It only allows lambda expressions. It rejects outright any attempt to pass full code blocks (such as import statements or class definitions).
It scans every element in the code for dangerous identifiers and attributes that could enable arbitrary code execution (for example, strings like eval, exec, open, __import__, and similar ones). If any of these identifiers appear, the code is rejected.
If the code passes both checks, it is executed in a restricted environment where Python’s built-in functions (like open and print) are deliberately removed. So even if something slips through, it shouldn’t have access to dangerous capabilities.
The resulting lambda is then used to filter records in the Vector Store.
While this approach is solid in theory, blocklists in dynamic languages like Python are inherently fragile because the language’s flexibility allows restricted operations to be reintroduced through alternate syntax, libraries, or runtime evaluation.
We found a way to bypass this blocklist implementation through a specially crafted exploit prompt.
Exploit
Our exploit prompt was designed to manipulate the agent into triggering a Search Plugin invocation with an input that ultimately leads to malicious code execution:
A Malicious prompt demanding execution of the search_hotels function with the malicious argument.
This prompt circumvented the agent to trigger the following function calling:
Invocation of the “search hotels” function with the malicious argument.
As result, the lambda function was formatted as the following and executed inside eval(). This payload escaped the template string, traversed Python’s class hierarchy to locate BuiltinImporter, and used it to dynamically load os and call system(). These steps bypassed the import blocklists to launch an arbitrary shell command (for example, calc.exe) while keeping the template syntax valid with a clean closing expression.
The filter function didn’t block the payload because of the following reasons:
1. Missing dangerous names
The payload used several attributes that weren’t in the blocklist:
__name__ – Used to find BuiltinImporter by name
load_module – The method that imports modules
system – The method that executes shell commands
BuiltinImporter – The class itself
2. Structural check passes
The payload was wrapped inside a valid lambda expression. The check isinstance(tree.body, ast.Lambda) passed because the entire thing is in itself a lambda that just happens to contain malicious code in its body.
3. Empty __builtins__ is irrelevant The eval() call used {“__builtins__”: {}} to remove access to built-in functions. However, this protection was meaningless because the payload never used built-ins directly. Instead, it started with tuple(), which exists regardless of the builtins environment, and crawled through Python’s type system to reach dangerous functionality.
4. No ast.Subscript checking While not used in this payload, it’s worth noting that the filter only checked ast.Name and ast.Attribute nodes. If the payload needed to use a blocked name, it could’ve accessed it using bracket notation (for example, obj[‘__class__’] instead of obj.__class__), which creates an ast.Subscript node that the validation completely ignored.
Mitigation
After responsibly disclosing the vulnerability to MSRC, the Microsoft Semantic Kernel team implemented a comprehensive fix using four layers of protection to eliminate every escape primitive needed to turn a lambda filter into executable code:
AST node-type allowlist – Permits only safe constructs like comparisons, boolean logic, arithmetic, and literals.
Function call allowlist – Checks even allowed AST call nodes to ensure only safe functions can be invoked.
It uses the In-Memory Vector Store and relies on its filter functionality (when acting as the backend for the Search Plugin using default configurations).
What to do if I am affected?
You don’t need to rewrite your agent. Upgrading the Python semantic-kernel dependency to version 1.39.4 or higher mitigates the risk.
What about the time that my agent was vulnerable?
While patching closes the bug, but it doesn’t answer the retrospective question defenders care about: whether their agent was exploited before they upgraded.
First, define the vulnerable window for each affected deployment: from the moment a vulnerable Semantic Kernel Python version was deployed until the moment version 1.39.4 or later was installed. Any investigation should focus on that time range.
Second, hunt for host-level post-exploitation signals during that vulnerable window. Because successful exploitation results in code execution on the host, the most useful evidence is in endpoint telemetry: suspicious child processes, outbound connections, or persistence artifacts created by the agent host process. We provide a set of practical advanced hunting queries for further investigation in a separate section of this blog.
If you find suspicious activity during that window, treat it as a potential host compromise. Review the affected host, rotate credentials and tokens accessible to the agent, and investigate what data or systems that host could reach.
CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin
Before diving into the mechanics of this second vulnerability, here is what an agent sandbox escape looks like in practice: with a single prompt, an attacker could bypass a cloud-hosted sandbox, write a malicious payload directly to the host device’s Windows Startup folder, and achieve full RCE.
The container boundary
Semantic Kernel includes a built-in plugin called SessionsPythonPlugin that allows agents to safely execute Python code inside Azure Container Apps dynamic sessions, which are isolated cloud hosted sandboxes with their own filesystem.
The security model relies entirely on this boundary. Code runs in the isolated sandbox and cannot touch the host device where the agent process runs. To help move data in and out of the sandbox, the plugin uses helper functions like UploadFile and DownloadFile, which run on the host side to transfer files across this boundary.
The vulnerability
In the .NET software development kit (SDK), DownloadFileAsync was accidentally marked with a [KernelFunction] attribute, which officially advertised it to the AI model as a callable tool, complete with its parameter schema:
Because of this attribute, the localFilePath parameter, which dictates exactly where File.WriteAllBytes() saves data on the host device, was now entirely AI controlled. With no path validation, directory restriction, or sanitization in place, an attacker wouldn’t need a complex hypervisor exploit; they just needed to prompt the model to do it for them.
(Note: Arbitrary File Read. A similar vulnerability existed in reverse for the upload_file() function across both the Python and .NET SDKs. It accepted any local file path without validation, allowing prompt injections to exfiltrate sensitive host files, like SSH keys or credentials, directly into the sandbox).
Attack chain overview
By chaining two exposed tools, an attacker could turn standard function calling into a sandbox escape:
Step 1: Create the payload
An injected prompt instructs the agent to use the ExecuteCode tool to generate a malicious script inside the isolated container:
At this point, the payload is contained. It exists only in the sandbox and cannot execute on the host.
Step 2: Escape the sandbox
A second injected instruction tells the AI model to use the DownloadFileAsync tool to download the file to a dangerous location on the host:
The agent calls:
The agent fetches the script from the sandbox’s API and writes it directly to the host’s Windows\Start Menu\Programs\Startup folder.
Step 3: Execute the code
On the next user sign-in, the script runs, granting full host compromise.
This exploit illustrates the MITRE ATLAS technique AML.T0051 (LLM Prompt Injection) cascading into AML.T0016 (Obtain Capabilities).
Exposing DownloadFileAsync provided a direct file write primitive on the host filesystem, effectively negating the container isolation.
The fix and how to defend
Semantic Kernel patched this vulnerability by removing the root cause of tool exposure and adding defense in depth:
Removed AI access – The [KernelFunction] attribute was removed, making the function invisible to the AI model. The AI agent can no longer invoke it, and prompt injection can no longer reach it:
This single change breaks the entire attack chain. The AI can now only be called directly by the developer’s intentional code.
Path validation – For developers calling the function programmatically, a ValidateLocalPathForDownload() method was added using path canonicalization (Path.GetFullPath()) and directory allowlist matching to ensure the target path falls within permitted directories:
Similar opt-in protections were applied to uploads.
How do I know if I am affected?
Your agent is vulnerable to CVE-2026-25592 if it uses a Semantic Kernel .NET SDK version older than 1.71.0.
Defending the agentic edge
If you use Semantic Kernel, our primary recommendation is to upgrade immediately. You don’t need to rewrite your agent’s architecture; the security updates simply remove the AI model’s ability to trigger these functions autonomously.
More broadly, defending AI agents requires acknowledging that AI models aren’t security boundaries. Security teams must correlate signals across two layers: the AI model level (intent detection through meta prompts and content safety filters) and the host level (execution detection). If an attacker bypasses the AI model guardrails, traditional endpoint defense must be in place to detect anomalous behavior, such as an AI agent process suddenly spawning command lines or dropping scripts into Startup folders.
Not bugs, but developed by design
Untrusted data being used as input for high-risk operations isn’t entirely new. In the early days of web application security, such input was passed directly into SQL queries or filesystem APIs. Today, agents are doing something similar, in that they could map untrusted natural-language input to system tools.
The overarching lesson from both vulnerabilities is that both aren’t bugs in the AI model itself, but rather issues in agent architecture and tool design. We must make a clear distinction between model behavior and agent architecture. The AI model functions exactly as it was designed to: translate intent into structured tool calls.
When models are connected to system tools, prompt injection risks may extend beyond typical chatbot misuse and require additional safeguards. Instead, it becomes a direct path to concrete execution primitives like data exfiltration, arbitrary file writes, and RCE. For a deeper look at the runtime risks of tool-connected AI models, see Running OpenClaw safely: identity, isolation, and runtime risk.
As mentioned previously, your LLM is not a security boundary. The tools you expose define your attacker’s affected scope. Any tool parameter the model can influence must be treated as attacker-controlled input.
In the next blog in this series, we’ll expand beyond Semantic Kernel to explore structurally similar execution vulnerabilities that we found in other widely used third-party agent frameworks.
CTF challenge: Attack your own agent
If you want to see how prompt injections escalate into execution and to put your skills to the test, we’ve packaged the vulnerable hotel-finder agent that we described in this blog into an interactive, hands-on capture-the-flag (CTF) challenge.
This CTF challenge lets you step into the shoes of an attacker and try to exploit the CVE-2026-26030 vulnerability in a controlled environment. You need to craft a prompt injection that not only bypasses the agent’s natural language defenses but also smuggle a Python AST-traversal payload through the vulnerable eval() sink.
To see if you can manipulate the AI model into launching arbitrary code and popping calc.exe on the server, download the challenge, spin it up in a sandbox, and see if you can achieve RCE. Keep in mind that this challenge is for educational purposes only, and shouldn’t be run in production environments.
Reconnaissance:
Exploit (jailbreak and payload):
Note: Because the agent will running locally on your device, calc.exe will open on your desktop. In a real-world scenario, such an executable file will launch remotely on the server hosting the agent.
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.
Microsoft researchers continue to observe the evolution of an infostealer campaign distributing ClickFix‑style instructions and targeting macOS users. In this recent iteration, threat actors attempt to take advantage of users who are looking for helpful advice on macOS-related issues (for example, optimizing their disk space) in blog sites and other user-driven content platforms by hosting their malicious commands in these sites.
These commands, which are purported to install system utilities, load an infostealing malware like Macsync, Shub Stealer, and AMOS into the targets’ devices instead. The malware then collects and exfiltrates data, including media files, iCloud data and Keychain entries, and cryptocurrency wallet keys. In some campaigns, the malware replaces legitimate cryptocurrency wallet apps with trojanized versions, putting users at an added security risk.
Prior iterations of this campaign delivered the infostealers through disk image (.dmg) files that required users to manually install an application. This recent activity reflects a shift in tradecraft, where threat actors instruct users to run Terminal commands that leverage native utilities to retrieve remotely hosted content, followed by script‑based loader execution.
Unlike application bundles opened through Finder—which might be subjected to Gatekeeper verification checks such as code signing and notarization—scripts downloaded and launched directly through Terminal (for example, by using osascript or shell interpreters) don’t undergo the same evaluation. This delivery mechanism enables attackers to initiate malware execution through user‑driven command invocation, reducing reliance on traditional application delivery methods and increasing the likelihood of successful execution.
In this blog, we take a look at three campaigns that use this new tradecraft. We also provide mitigation guidance and detection details to help surface this threat.
Activity overview
Initial access
Standalone websites were seen hosting pages that included a Base64-encrypted instruction for end users to run. Some sites present this information in multiple languages. As of this writing, these websites that we’ve observed are either already down or have been reported.
Figure 1: Landing page of a script campaign (domenpozh[.]net)Figure 2. ClickFix instructions hosted on mac-storage-guide.squarespace[.]com.Figure 3. mac-storage-guide.squarespace[.]com page was seen presenting content in different languages, such as Japanese.
In other instances, content that included instructions leading to malware were observed to be hosted on Craft, a note-taking platform that lets writers and content creators take notes and distribute their content. We’ve observed that pages like macclean[.]craft[.]me were taken down relatively quickly.
Figure 4. ClickFix instruction hosted on macclean[.]craft[.]me.
Threat actors were also publishing fake troubleshooting posts on the popular blogging site Medium to distribute ClickFix instructions. These posts claim to solve common macOS problems. Blog sites such as macos-disk-space[.]medium[.]com instruct users to “fix” an issue by pasting a command into Terminal. The command then decodes and runs an AppleScript or Bash loader. These blogs were reported and taken down quickly.
We observed three distinct execution paths leveraging different infrastructure. We’re classifying these as a loader install campaign, a script install campaign, and a helper install campaign. In the loader and helper campaigns, we observed that a random seven-digit value (hereinafter referred to as random IDs), was used in data staging, marking the staging folders as /tmp/shub_<random ID> or/tmp/<random ID>.
The underlying goal remains the same in these campaigns: sensitive data collection, persistence, and exfiltration.
The following table summarizes the key differences between the campaigns. We discuss the details of each of these campaigns in the succeeding sections of this blog.
Activity or technique
Loader campaign
Script campaign
Helper campaign
Initial installation
No file written on disk
No file written on disk
/tmp/helper /tmp/update
Condition to exit execution
Russian keyboard detected
Failure to resolve an active command-and-control (C2) endpoint (all infrastructure checks fail)
Not applicable (handled in later loader/payload stages)
Trezor Suite.appLedger Wallet.app
Loader install campaign
Since February 2026, Microsoft researchers have observed a campaign that requests a loader shell from the attacker’s infrastructure using curl once a user copies and runs ClickFix commands using Terminal. It leads to further execution of a second-stage shell script.
This second shell script is a zsh loader that decodes and decompresses an embedded payload using Base64 and Gzip, respectively. It then executes the payload using eval.
Figure 5: Shell loader.
The next-stage script also functions as a macOS reconnaissance and execution ‑control loader that first fingerprints the system by collecting the following information:
Keyboard locale
Hostname
Operating system version
External IP address
It then builds and sends a JSON object to an attacker‑controlled server containing an event name (loader_requested or cis_blocked) along with this telemetry. It also uses the presence of Russian/CIS keyboard layouts as a deliberate kill switch, reporting a cis_blocked event and stop the execution.
Figure 6: Reconnaissance loader with CIS kill switch.
If the system isn’t blocked, the script silently beacons a “loader requested” event and then downloads and executes a remote AppleScript payload directly in memory using osascript.
Figure 7: Reconnaissance loader with AppleScript payload delivery.
AppleScript infostealer
This multi-stage macOS AppleScript stealer employs user interaction-based credential capture, conducts broad data collection across browsers, Keychains, messaging applications, wallet artifacts, and user documents, and stages the collected data into a compressed archive for exfiltration to a remote endpoint. The malware further tampers with locally installed applications to intercept sensitive data, establishes persistence through a masqueraded LaunchAgent that mimics legitimate software updates, and maintains remote command execution capabilities by periodically polling a server for instructions, which are executed at runtime.
Data collection: tmp/shub_<random ID> staging
We observed that the stealer self-identifies as “SHub Stealer” (it writes the marker SHub into its staging directory). It prompts the target user to enter their password, pretending to install a “helper” utility. It then validates the entered password using the command dscl . -authonly <username>. Upon successful validation, it sends a password_obtained event to its C2 infrastructure.
The malware stages collected data under a /tmp/shub_<random ID>/ folder. The collected data includes:
Browser credentials
Notes
Media files
Telegram data
Cryptocurrency wallets
Keychain entries
iCloud account data
The stealer also collects documents smaller than 2 MB and stages them within a FileGrabber repository located at /tmp/shub_<random ID>/FileGrabber/.
The targeted file types are:
txt
pdf
docx
wallet
key
keys
doc
jpeg
png
kdbx
rtf
jpg
seed
Once the data collection is complete, data is compressed and exfiltrated. The stealer deletes staging artifacts to reduce forensic evidence.
Wallet exfiltration and trojanization
Subsequently, the stealer probes the system for the presence of any of the following cryptocurrency wallet applications:
Electrum
Coinomi
Exodus
Atomic
Wasabi
Ledger Live
Monero
Bitcoin
Litecoin
DashCore
lectrum_LTC
Electron_Cash
Guarda
Dogecoin
Trezor_Suite
Sparrow
When it finds any of these applications, it stages their data for exfiltration.
The stealer was also observed replacing legitimate cryptocurrency wallets apps with attacker-controlled or trojanized ones:
Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc/app.zip
Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip
Exodus.app is replaced by appex.zip fetched from <C2 domain>/zxc/appex.zip
These trojanized cryptocurrency wallet applications pose a serious risk to their users who might be unaware of the stealthy compromise and continue to use and transact with them.
Figure 8. Trojanized apps installation.
Persistence
For persistence, the malware creates an additional script within the newly created ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/ folder.
A malicious implant named GoogleUpdate is configured to RunAtLoad disguised as an agent. Microsoft Defender Antivirus detects this implant as Trojan:MacOS/SuspMalScript.
A new property list (plist), /Library/LaunchAgents/com.google.keystone.agent.plist,is then staged to run this agent.
Figure 9. Plist staging.
The executable is then given permission to run with the following command:
Figure 10. GoogleUpdate granted permission to run.
Once com.google.keystone.agent.plist loads, it functions as a backdoor-style bot component that registers the infected macOS system with attacker infrastructure at <C2 domain>/api/bot/heartbeat, uniquely identifies the host using a hardware-derived ID, and periodically beacons system metadata such as hostname, operating system version, and external IP address.
The C2 server can return Base64-encoded instructions, which the script decodes and executes locally and deletes traces, enabling remote command execution on demand. This process creates a persistent remote-control channel, where the attacker could push arbitrary shell code to the infected device at any time.
Figure 11. Backdoor style bot with heartbeat driven payload execution.
Script install campaign
In April 2026, Microsoft researchers observed an ongoing campaign that runs a heavily obfuscated infostealer when users run it through Terminal.
The attack begins with a social‑engineering instruction containing a Base64‑encoded command.
When decoded, this instruction resolves a one‑line shell pipeline that retrieves a remote script, which is then handed off immediately for execution. By encoding the command and streaming its output directly into the shell, the attacker avoids placing a recognizable payload on disk during the initial stage.
Figure 12. Payload delivery.
The retrieved script.sh payload is launched directly from the network stream, with no intermediate file written to disk. It’s responsible for establishing persistence and deploying follow-on functionality. It delivers the second-stage Base64 encoded script under a plist staged at ~/Library/LaunchAgent/com.<random name>.plist.
Figure 13. Payload staged into a plist.
The persisted AppleScript is heavily obfuscated in its original form (character ID concatenation). After decoding, the key logic follows:
Figure 14. AppleScript stager (decoded).
This AppleScript functions as a C2 discovery and execution orchestrator for a macOS malware campaign. The AppleScript is used as the control layer and standard Unix tools for network interaction and execution. Its first role is C2 discovery. It iterates over a list of potential server identifiers (for example {0x666[.]info}), constructs candidate URLs (http://<value>/), and probes them using curl with a realistic Chrome macOS user agent and a benign POST body (-d “check”). This connectivity test is performed through the following command:
If none of the hard‑coded infrastructure responds successfully, the script falls back to Telegram‑based C2 discovery. It fetches a Telegram bot page using curl -s hxxps://t[.]me/ax03bot and extracts a hidden server identifier embedded in an HTML <span dir=”auto”> element using sed. This lets the attacker rotate C2 infrastructure dynamically.
Figure 16. Telegram-based C2 endpoint discovery.
Once a working C2 endpoint is identified, the script moves into execution orchestration. It sends a final POST request to the resolved server containing a transaction ID (txid) and module identifier, then immediately pipes the server response into osascript for execution:
This command enables arbitrary AppleScript execution directly from the server, fully in memory, with no payload written to disk. Output and errors are suppressed, and execution only proceeds if all connectivity checks succeed. Overall, this isn’t a simple downloader but a resilient, infrastructure‑aware loader designed to dynamically discover C2 endpoints, evade takedowns, and execute attacker‑controlled AppleScript logic on demand.
We observed data exfiltration to the attacker’s infrastructure on a C2/upload.php endpoint leveraging curl.
Figure 17. Exfiltration of archived data.
Helper install campaign (AMOS)
Starting at the end of January 2026 , another ClickFix campaign relied on an executable file named helper or update to run. In this campaign, once a user ran the encoded ClickFix instructions, a first-stage script decoded a Base64 payload and then decompressed the payload using Gunzip.
Figure 18. First-stage script requested.
The first-stage script led to the retrieval of the second stage-malicious Mach Object (Mach-O) executable into the newly created /tmp/<file name> folder.
Figure 19. /tmp/helper installation.
In February 2026, this campaign retrieved the payload under a /tmp/update folder.
Figure 20. /tmp/update installation.
This malicious executable file has its extended properties removed and is then given permission to run and launch on the victim’s device.
Virtualization detection
The infection chain begins with an AppleScript based stager that uses array subtraction obfuscation to conceal its strings and commands. This stager performs an anti-analysis gate by invoking system_profiler and inspecting both memory and hardware profiles. Specifically, it searches for common virtualization indicators such as QEMU, VMware, and KVM. In addition to explicit hypervisor vendor strings, the script also checks for a set of generic hardware artifacts commonly observed in virtualized or analysis environments, including:
Chip: Unknown
Intel Core 2
Virtual Machine
VirtualMac
If any of these indicators are present, execution is terminated early, preventing further stages from running.
Data collection and exfiltration
Like the loader install campaign, the stealer prompts the user to enter their password. It validates locally whether the entered password is correct using dscl utility.
After capturing the target user’s password, the malware then focuses on stealing high-value credentials and financial artifacts. It copies macOS Keychain databases, enabling access to stored website passwords, application secrets, and WiFi credentials.
It also collects browser authentication material from Chromium‑based browsers, including saved usernames and passwords, session cookies, autofill data, and browser profile state that can be reused for account takeover. In addition, the script targets cryptocurrency wallets, copying data associated with both browser‑based and desktop wallets. This includes browser extensions such as MetaMask and Phantom, as well as desktop wallets including Exodus and Electrum.
The stealer compresses collected data into a ZIP file /tmp.out.zip, which is then exfiltrated to a <C2 domain>/contact> endpoint. The stealer removes staging artifacts to reduce forensic evidence.
Figure 21. Archiving and exfiltration of data.
Wallet exfiltration and trojanization
Similar to the loader campaign, the stealer in the helper also replaces legitimate wallet apps with attackers-controlled ones:
Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc.app.zip.
Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip
Backdoor deployment and persistence
To maintain long‑term access to infected systems, the helper campaign deploys a multi‑stage persistence mechanism built around two cooperating components: a primary backdoor binary and a lightweight execution wrapper.
Download and execution of the backdoor component (.mainhelper)
The persistence chain begins with the download of a second‑stage backdoor implant named .mainhelper into the current user’s home directory. As shown in Figure 22, the obfuscated AppleScript issues a network retrieval command that fetches this Mach‑O executable from an attacker-controlled endpoint (<C2 domain>/zxc/kito) and writes it as a hidden file under the user profile.
Figure 22. Second implant downloaded.
Once it’s given attributes and permissions to run, the /.mainhelper implant joins the compromised device to a C2 endpoint hxxp://45.94.47[.]204/api/. The implant executes tasks from the attacker, providing a remote-control capability to the attacker on the compromised system.
Figure 23. C2 instance.
Creation of the execution wrapper (.agent)
In addition to the backdoor binary, the stealer creates a secondary file named .agent, also placed in the user’s home directory. Unlike .mainhelper, .agent isn’t a full implant. Instead, it is a lightweight shell wrapper whose sole purpose is to launch and supervise the .mainhelper process. The script writes the wrapper to disk and configures it so that, if the backdoor process terminates or crashes, .agent relaunches it.
After prompting the victim for their macOS password and validating it, the script escalates privileges to establish system-level persistence. It constructs a LaunchDaemon plist, stages the XML content to a temporary file (/tmp/starter), and then writes it to /Library/LaunchDaemons/com.finder.helper.plist.
LaunchDaemon plist staging and loading
LaunchDaemon is configured to run /bin/bash with the path to ~/.agent as its argument, rather than invoking the backdoor binary directly. As shown in Figure 25, the script sets correct ownership, loads the daemon using launchctl, and enables both RunAtLoad and KeepAlive.
Figure 24. Plist staging.
As a result, on every system boot, launchd runs the .agent wrapper with root privileges, which in turn ensures that the .mainhelper backdoor process is running.
Figure 25. Plist loading.
Mitigation and protection guidance
Apple Xprotect has updated signatures to protect users against this threat. Additionally, in macOS 26.4 and later, Apple has introduced a mitigation that directly addresses the ClickFix delivery mechanism.
When a user attempts to paste a potentially malicious command into Terminal, they will now see the following prompt:
Possible malware, Paste blocked
Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.
Organizations can also follow these recommendations to mitigate threats associated with this threat:
Educate users. Warn them against running instructions from untrusted sources.
Monitor Terminal usage. Alert on suspicious Terminal or shell sessions spawned by installers or user apps.
Detect native tool abuse. Flag unusual sequences of macOS utilities (curl, Base64, Gunzip, osascript, and dscl).
Inspect outbound downloads. Monitor curl activity fetching encoded or compressed payloads from unknown domains.
Protect credential stores. Detect unauthorized access to keychain items, browser data, SSH keys, and cloud credentials.
Monitor data staging. Alert on archive creation of sensitive artifacts followed by HTTP POST exfiltration.
Enable endpoint protection. Ensure macOS endpoint detection and response (EDR) or extended detection and response (XDR) monitors script execution and living‑off‑the‑land behavior.
Restrict C2 traffic. Block outbound connections to suspicious or newly registered domains.
Microsoft also recommends the following mitigations to reduce the impact of this threat.
Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your 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.
Allow investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to mitigate attackers from using local administrator privileges to set antivirus exclusions.
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.
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.
Tactic
Observed activity
Microsoft Defender coverage
Execution
User copies, pastes, and runs Base64 instructions Base64 instructions are deobfuscated Executable files are created from remote attacker’s infrastructureInstalled malware implant is executed Malicious AppleScript is retrieved from attacker infrastructureSequence of malicious instructions are executed
Microsoft Defender for Endpoint Suspicious shell command execution Obfuscation or deobfuscation activity Executable permission added to file or directory Suspicious launchctl tool activity ‘SuspMalScript’ malware was prevented Possible AMOS stealer Activity Suspicious AppleScript activity Suspicious piped command launched Suspicious file or information obfuscation detected
Microsoft Defender Antivirus Trojan:MacOS/Multiverze – Created executable file Trojan:MacOS/SuspMalScript – Malware implant downloaded by the loader campaign Behavior:MacOS/SuspAmosExecution – Malicious file execution Behavior:MacOS/SuspOsascriptExec – Malicious osascript execution Behavior:MacOS/SuspDownloadFileExec – Suspicious file download and execution Behavior:MacOS/SuspiciousActiviyGen
Data collection
Malware collects data from bash history, browser credentials, and other sensitive foldersMultiple files are collected into staging foldersCollected data is staged and archived into a folder Staging folders are removed
Microsoft Defender for Endpoint Suspicious access of sensitive filesSuspicious process collected data from local systemEnumeration of files with sensitive dataSuspicious archive creationSuspicious path deletion
Microsoft Defender Antivirus Behavior:MacOS/SuspPassSteal – Suspicious process collected data from local systemTrojan:MacOS/SuspDecodeExec – Malicious plist detection
Defense evasion
Malware deletes the staging paths following exfiltrationExecution of obfuscated code to evade inspection
Microsoft Defender for Endpoint Suspicious path deletionSuspicious file or information obfuscation detected
Credential access
Malware steals user account credential and stages files for exfiltration
Microsoft Defender for Endpoint Suspicious access of sensitive filesUnix credentials were illegitimately accessed
Exfiltration
Malware exfiltrates staged data using curl and HTTP POST
Microsoft Defender for Endpoint Possible data exfiltration using curl
Microsoft Defender Antivirus Behavior:MacOS/SuspInfoExfilTrojan:MacOS/SuspMacSyncExfil
Threat intelligence reports
Microsoft Defender customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender 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 help prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Hunting queries
Microsoft Defender
Microsoft Defender customers can run the following queries to find related activity in their networks:
Initial access
//Loader campaign installation
DeviceNetworkEvents
| where InitiatingProcessCommandLine has_any ("loader.sh?build=","payload.applescript?build=")
// Helper campaign installation
DeviceFileEvents
| where InitiatingProcessCommandLine has_all("curl", "/tmp/helper","-o")
//Install of /update install campaign
DeviceFileEvents
| where InitiatingProcessCommandLine has_all("curl", "/tmp/update","-o")
| where FileName== "update"
Exfiltration to C2 infrastructure
//loader campaign
DeviceProcessEvents
| where ProcessCommandLine has_all("curl", "post","/debug/event", "build_hash")
DeviceProcessEvents
| where ProcessCommandLine has_all("curl","/tmp","post","-H","-f","build","/gate")
| where not (ProcessCommandLine has_any(".claude/shell-snapshots"))
//script campaign
DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all ("curl","-F","txid","zip","max-time")
//helper campaign
DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("curl","post","-H","user","buildid","cl","cn","/tmp/")
Bot C2 installation and communication
//loader campaign - bot install
DeviceFileEvents
| where InitiatingProcessCommandLine =="base64 -d"
| where FolderPath endswith @"Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate"
//loader campaign – bot communication
DeviceProcessEvents
| where ProcessCommandLine has_all("/api/bot/heartbeat","post","curl")
//script campaign second stage execution
DeviceProcessEvents
| where ProcessCommandLine has_all("curl","POST","txid","osascript","bmodule","max-time")
//helper campaign - bot install
//Alternate query for helper or bot update installation
DeviceFileEvents
| where InitiatingProcessCommandLine has_all ("curl","zxc","kito")
DeviceProcessEvents
| where InitiatingProcessFileName =="osascript"
| where ProcessCommandLine has_all ("sh","echo","-c", "cp","/tmp/starter",".plist")
Indicators of compromise
Domains distributing ClickFix
Indicator
Type
Description
cleanmymacos[.]org
Domain
Distribution of ClickFix instructions
mac-storage-guide.squarespace[.]com
Domain
Distribution of ClickFix instructions
claudecodedoc[.]squarespace[.]com
Domain
Distribution of ClickFix instructions
domenpozh[.]net
Domain
Distribution of ClickFix instructions
macos-disk-space[.]medium[.]com
Domain
Distribution of ClickFix instructions
macclean[.]craft[.]me
Domain
Distribution of ClickFix instructions
apple-mac-fix-hidden[.]medium[.]com
Domain
Distribution of ClickFix instructions
Loader campaign
Indicator
Type
Description
rapidfilevault4[.]sbs
Domain
Payload delivery and C2
coco-fun2[.]com
Domain
Payload delivery and C2
nitlebuf[.]com
Domain
Payload delivery and C2
yablochnisok[.]com
Domain
Payload delivery and C2
mentaorb[.]com
Domain
Payload delivery and C2
seagalnssteavens[.]com
Domain
Payload delivery and C2
res2erch-sl0ut[.]com
Domain
Payload delivery and C2
filefastdata[.]com
Domain
Payload delivery and C2
metramon[.]com
Domain
Payload delivery and C2
octopixeldate[.]com
Domain
Payload delivery and C2
pewweepor092[.]com
Domain
Payload delivery and C2
bulletproofdomai2n[.]com
Domain
Payload delivery and C2
benefasts-fhgs2[.]com
Domain
Payload delivery and C2
repqoow77wiqi[.]com
Domain
Payload delivery and C2
do2wers[.]com
Domain
Payload delivery and C2
rapidfilevault4[.]cyou
Domain
Payload delivery and C2
reews09weersus[.]com
Domain
Payload delivery and C2
pepepupuchek13[.]com
Domain
Payload delivery and C2
pewqpeee888[.]com
Domain
Payload delivery and C2
wewannaliveinpicede[.]com
Domain
Payload delivery and C2
datasphere[.]us[.]com
Domain
Payload delivery and C2
rapidfilevault5[.]sbs
Domain
Payload delivery and C2
coco2-hram[.]com
Domain
Payload delivery and C2
poeooeowwo777[.]com
Domain
Payload delivery and C2
korovkamu[.]com
Domain
Payload delivery and C2
metrikcs[.]com
Domain
Payload delivery and C2
metlafounder[.]com
Domain
Payload delivery and C2
terafolt[.]com
Domain
Payload delivery and C2
haploadpin[.]com
Domain
Payload delivery and C2
rawmrk[.]com
Domain
Payload delivery and C2
mikulatur[.]com
Domain
Payload delivery and C2
milbiorb[.]com
Domain
Payload delivery and C2
doqeers[.]com
Domain
Payload delivery and C2
we2luck[.]com
Domain
Payload delivery and C2
quantumdataserver5[.]homes
Domain
Payload delivery and C2
bintail[.]com
Domain
Payload delivery and C2
molokotarelka[.]com
Domain
Payload delivery and C2
trehlub[.]com
Domain
Payload delivery and C2
avafex[.]com
Domain
Payload delivery and C2
rhymbil[.]com
Domain
Payload delivery and C2
boso6ka[.]com
Domain
Payload delivery and C2
res2erch-sl2ut[.]com
Domain
Payload delivery and C2
pilautfile[.]com
Domain
Payload delivery and C2
bigbossbro777[.]com
Domain
Payload delivery and C2
miappl[.]com
Domain
Payload delivery and C2
peloetwq71[.]com
Domain
Payload delivery and C2
fastfilenext[.]com
Domain
Payload delivery and C2
beransraol[.]com
Domain
Payload delivery and C2
pelorso90la[.]com
Domain
Payload delivery and C2
medoviypirog[.]com
Domain
Payload delivery and C2
wewannaliveinpice[.]com
Domain
Payload delivery and C2
malkim[.]com
Domain
Payload delivery and C2
pipipoopochek6[.]com
Domain
Payload delivery and C2
hello-brothers777[.]com
Domain
Payload delivery and C2
dialerformac[.]com
Domain
Payload delivery and C2
persaniusdimonica8[.]com
Domain
Payload delivery and C2
hilofet[.]com
Domain
Payload delivery and C2
tmcnex[.]com
Domain
Payload delivery and C2
nibelined[.]com
Domain
Payload delivery and C2
pissispissman[.]com
Domain
Payload delivery and C2
bankafolder[.]com
Domain
Payload delivery and C2
perewoisbb0[.]com
Domain
Payload delivery and C2
us41web[.]live
Domain
Payload delivery and C2
uk176video[.]live
Domain
Payload delivery and C2
jihiz[.]com
Domain
Payload delivery and C2
beltoxer[.]com
Domain
Payload delivery and C2
swift-sh[.]com
Domain
Payload delivery and C2
hitkrul[.]com
Domain
Payload delivery and C2
kofeynayagush[.]com
Domain
Payload delivery and C2
Script campaign
Indicator
Type
Description
hxxps://cauterizespray[.]icu/script[.]sh
URL
Payload delivery
hxxps://enslaveculprit[.]digital/script[.]sh
URL
Payload delivery
hxxps://resilientlimb[.]icu/script[.]sh
URL
Payload delivery
hxxps://thickentributary[.]digital/script[.]sh
URL
Payload delivery
hxxp://paralegalmustang[.]icu/script[.]sh
URL
Payload delivery
hxxps://round5on[.]digital/script[.]sh
URL
Payload delivery
hxxps://qjywvkbl[.]degassing-mould[.]digital
URL
Payload delivery
hxxps://zg5mkr7q[.]apexharvestor[.]digital
URL
Payload delivery
hxxps://kvrnjr30[.]apexharvestor[.]digital
URL
Payload delivery
hxxps://yygp4pdh[.]apexharvestor[.]digital
URL
Payload delivery
hxxps://t[.]me/ax03bot
URL
Payload delivery
0x666[.]info
Domain
Payload delivery, C2, and exfiltration
honestly[.]ink
Domain
Payload delivery, C2, and exfiltration
95.85.251[.]177
IP address
Payload delivery, C2, and exfiltration
pla7ina[.]cfd
Domain
Payload delivery, C2, and exfiltration
play67[.]cc
Domain
Payload delivery, C2, and exfiltration
Helper campaign
Indicator
Type
Description
rvdownloads[.]com
Domain
Payload delivery
famiode[.]com
Domain
Payload delivery
contatoplus[.]com
Domain
Payload delivery
woupp[.]com
Domain
Payload delivery
saramoftah[.]com
Domain
Payload delivery
ptrei[.]com
Domain
Payload delivery
wriconsult[.]com
Domain
Payload delivery
kayeart[.]com
Domain
Payload delivery
ejecen[.]com
Domain
Payload delivery
stinarosen[.]com
Domain
Payload delivery
biopranica[.]com
Domain
Payload delivery
raxelpak[.]com
Domain
Payload delivery
octopox[.]com
Domain
Payload delivery
boosterjuices[.]com
Domain
Payload delivery
ftduk[.]com
Domain
Payload delivery
dryvecar[.]com
Domain
Payload delivery
vcopp[.]com
Domain
Payload delivery
kcbps[.]com
Domain
Payload delivery
jpbassin[.]com
Domain
Payload delivery
isgilan[.]com
Domain
Payload delivery
arkypc[.]com
Domain
Payload delivery
hacelu[.]com
Domain
Payload delivery
stclegion[.]com
Domain
Payload delivery
xeebii[.]com
Domain
Payload delivery
hxxp://138.124.93[.]32/contact
URL
Exfiltration endpoint
hxxp://168.100.9[.]122/contact
URL
Exfiltration endpoint
hxxp://199.217.98[.]33/contact
URL
Exfiltration endpoint
hxxp://38.244.158[.]103/contact
URL
Exfiltration endpoint
hxxp://38.244.158[.]56/contact
URL
Exfiltration endpoint
hxxp://92.246.136[.]14/contact
URL
Exfiltration endpoint
hxxps://avipstudios[.]com/contact
URL
Exfiltration endpoint
hxxps://joytion[.]com/contact
URL
Exfiltration endpoint
hxxps://laislivon[.]com/contact
URL
Exfiltration endpoint
hxxps://mpasvw[.]com/contact
URL
Exfiltration endpoint
hxxps[://]lakhov[.]com/contact
URL
Exfiltration endpoint
Update campaign infrastructure
Indicator
Type
Description
reachnv[.]com
Domain
Delivery of the update install variant of the helper campaign
vagturk[.]com
Domain
Delivery of the update install variant of the helper campaign
futampako[.]com
Domain
Delivery of the update install variant of the helper campaign
octopox[.]com
Domain
Delivery of the update install variant of the helper campaign
lbarticle[.]com
Domain
Delivery of the update install variant of the helper campaign
raytherrien[.]com
Domain
Delivery of the update install variant of the helper campaign
joeyapple[.]com
Domain
Delivery of the update install variant of the helper campaign
This research is provided by Microsoft Defender Security Research with contributions from Arlette Umuhire Sangwa, Kajhon Soyini, Srinivasan Govindarajan, Michael Melone, and members of Microsoft Threat Intelligence.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Phishing campaigns continue to improve sophistication and refinement in blending social engineering, delivery and hosting infrastructure, and authentication abuse to remain effective against evolving security controls. A large-scale credential theft campaign observed by Microsoft Defender Research exemplifies this trend, using code of conduct-themed lures, a multi-step attack chain, and legitimate email services to distribute fully authenticated messages from attacker-controlled domains.
The campaign targeted tens of thousands of users, primarily in the United States, and directed them through several stages of CAPTCHA and intermediate staging pages designed to reinforce legitimacy while filtering out automated defenses. The lures in this campaign used polished, enterprise-style HTML templates with structured layouts and preemptive authenticity statements, making them appear more credible than typical phishing emails and increasing their plausibility as legitimate internal communications. Because the messages contained concerning accusations and repeated time-bound action prompts, the campaign created a sense of urgency and pressure to act.
The attack chain ultimately led to a legitimate sign-in experience that was part of an adversary‑in‑the‑middle (AiTM) phishing flow, which allowed the attackers to proxy the authentication session and capture authentication tokens that could provide immediate account access. Unlike traditional credential harvesting, AiTM attacks intercept authentication traffic in real time, bypassing non-phishing-resistant multifactor authentication (MFA).
In this blog, we’re sharing our analysis of this campaign’s lures, infrastructure, and techniques. Organizations can defend against financial fraud initiated through phishing emails by educating users about phishing lures, investing in advanced anti-phishing solutions like Microsoft Defender for Office 365 and configuring essential email security settings, and encouraging users to employ web browsers that support SmartScreen. Organizations can also enable network protection, which lets Windows use SmartScreen as a host-based web proxy.
Multi-step social engineering campaign leading to credential theft
Between April 14 and 16, 2026, the Microsoft Defender Research team observed a series of sophisticated phishing campaigns targeting more than 35,000 users across over 13,000 organizations in 26 countries, with majority of targets located in the United States (92%). The campaign did not focus on a single vertical but instead impacted a broad range of industries, most notably Healthcare & life sciences (19%), Financial services (18%), Professional services (11%), and Technology & software (11%). Messages were distributed in multiple distinct waves between 06:51 UTC on April 14 and 03:54 UTC on April 16.
Figure 1. Timeline of campaign messages sent by hourFigure 2. Campaign recipients by country and industry
Emails in this campaign posed as internal compliance or regulatory communications, using display names such as “Internal Regulatory COC”, “Workforce Communications”, and “Team Conduct Report”. Subject lines included “Internal case log issued under conduct policy” and “Reminder: employer opened a non-compliance case log”.
Message bodies claimed that a “code of conduct review” had been initiated, referenced organization-specific names embedded within the text, and instructed recipients to “open the personalized attachment” to review case materials. At the top of each message, a notice stated that the message had been “issued through an authorized internal channel” and that links and attachments had been “reviewed and approved for secure access”, reinforcing the email’s purported legitimacy. To further support the confidentiality of the supposed review, the end of each message contained a green banner stating that the contents had been encrypted using Paubox, a legitimate service associated with HIPAA-compliant communications.
Figure 3. Sample phishing email
Analysis of the sending infrastructure indicated that the campaign emails were sent using a legitime email delivery service, likely originating from a cloud-hosted Windows virtual machine. The messages were sent from multiple sender addresses using domains that are likely attacker-controlled.
Each campaign email included a PDF attachment with filenames such as Awareness Case Log File – Tuesday 14th, April 2026.pdf and Disciplinary Action – Employee Device Handling Case.pdf. The attachment provided additional context about the supposed conduct review, including a summary of the review process and instructions for accessing supporting documentation. Recipients were directed to click a “Review Case Materials” link within the PDF, which initiated the credential harvesting flow.
Figure 4. PDF attachment
When clicked, users were initially directed to one of two attacker-controlled domains (for example, acceptable-use-policy-calendly[.]de or compliance-protectionoutlook[.]de). These landing pages displayed a Cloudflare CAPTCHA, presented as a mechanism to validate that the user was coming “from a valid session”. This CAPTCHA likely served as a gating mechanism to impede automated analysis and sandbox detonation.
Figure 5. CAPTCHA challenge
After completing the CAPTCHA, users were redirected to an intermediate site designed to prepare them for the final stage of the attack. This page informed users that the requested documentation was encrypted and required account authentication. While this stage of the attack has several hallmarks of device code phishing, we were only able to confirm the AITM portion of the attack chain.
Figure 6. Intermediate site asking users to click “Review & Sign”
After clicking the provided “Review & Sign” button, users were presented with a sign-in prompt requesting their email address.
Figure 7. Prompt directing users to enter their email address
After submission, users were required to complete a second CAPTCHA involving image selection.
Figure 8. Second CAPTCHA challenge
Once these steps were completed, users were shown a message indicating that verification was successful and that their “case” was being prepared.
Figure 9. Message telling users that “Verification completed successfully”
Following these steps, users were redirected to a third site hosting the final stage of the attack. Analysis of the underlying code indicates that the final destination varied depending on whether the user accessed the workflow from a mobile device or a desktop system.
Figure 10. Code used to redirect users based on platform
On the final page, users were informed that all materials related to their code of conduct review had been “securely logged”, “time-stamped”, and “maintained within the organization’s centralized compliance tracking system”. They were then prompted to schedule a time to discuss the case, which required signing in to their account.
Figure 11. Final page instructed users to sign in
Selecting the “Sign in with Microsoft” option redirected users to a Microsoft authentication page, initiating an AiTM session hijacking flow designed to capture authentication tokens and compromise user accounts.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.
Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for multifactor authentication (MFA). Refer to this article for the different authentication methods and features.
Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Phishing emails
Microsoft Defender for Office 365 – A potentially malicious URL click was detected – A user clicked through to a potentially malicious URL – Suspicious email sending patterns detected – Email messages containing malicious URL removed after delivery – Email messages removed after delivery – Email reported by user as malware or phish
Persistence
Threat actors sign in with stolen valid entities
Microsoft Entra ID Protection – Anomalous Token – Unfamiliar sign-in properties – Unfamiliar sign-in properties for session cookies
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Hunting queries
Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:
Campaign emails by sender address
The following query identifies emails associated with this campaign using a message’s sending email address.
EmailEvents
| where SenderMailFromAddress in (" cocpostmaster@cocinternal.com "," nationaladmin@gadellinet.com ","
nationalintegrity@harteprn.com”,” m365premiumcommunications@cocinternal.com”,” documentviewer@na.businesshellosign.de”)
Indicators of compromise
Indicator
Type
Description
First seen
Last seen
compliance-protectionoutlook[.]de
Domain
Domain hosting malicious campaign content
2026-04-14
2026-04-16
acceptable-use-policy-calendly[.]de
Domain
Domain hosting malicious campaign content
2026-04-14
2026-04-16
cocinternal[.]com
Domain
Domain hosting sender email address
2026-04-14
2026-04-16
Gadellinet[.]com
Domain
Domain hosting sender email address
2026-04-14
2026-04-16
Harteprn[.]com
Domain
Domain hosting sender email address
2026-04-14
2026-04-16
Cocpostmaster[@]cocinternal.com
Email address
Email address used to send campaign emails
2026-04-14
2026-04-16
Nationaladmin[@]gadellinet.com
Email address
Email address used to send campaign emails
2026-04-14
2026-04-16
Nationalintegrity[@]harteprn.com
Email address
Email address used to send campaign emails
2026-04-14
2026-04-16
M365premiumcommunications[@]cocinternal.com
Email address
Email address used to send campaign emails
2026-04-14
2026-04-16
Documentviewer[@]na.businesshellosign.de
Email address
Email address used to send campaign emails
2026-04-14
2026-04-16
Awareness Case Log File – Monday 13th, April 2026.pdf
Filename
Name of PDF attachment containing phishing link
2026-04-14
2026-04-14
Awareness Case Log File – Tuesday 14th, April 2026.pdf
Filename
Name of PDF attachment containing phishing link
2026-04-15
2026-04-15
Awareness Case Log File – Wednesday 15th, April 2026.pdf
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Microsoft Defender is investigating a high-severity local privilege escalation vulnerability (CVE-2026-31431) affecting multiple major Linux distributions including Red Hat, SUSE, Ubuntu, and AWS Linux. This vulnerability allows unauthorized escalation of privileges to root, impacting a significant portion of cloud Linux workloads and millions of Kubernetes clusters. Although active exploitation has been limited and primarily observed in proof-of-concept testing, the vulnerability’s broad applicability has caused widespread concern.
Given the availability of a fully working exploit proof-of-concept (PoC) and the race to patch systems, Microsoft Defender is seeing preliminary testing activity that might result most likely in increased threat actor exploitation over the next few days, as also confirmed by the recent addition of this vulnerability to the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerability (KEV) catalog.
In this report, Microsoft Defender shares detailed analyses and detection insights for this vulnerability, as well as mitigation recommendations and hunting guidance for customers to act on. Further investigation towards providing stronger protection measures is in progress, and this report will be updated when more information becomes available.
Vulnerability details
Technical element
Details
Vulnerability type
Local privilege escalation
Attack vector
Code execution from unprivileged user
Prerequisites for exploitation
Local access to the machine as non-privileged user
Brief technical explanation
A bug in the Linux kernel’s crypto-subsystem can be abused by an attacker to corrupt the cache of any readable file, including setuid binaries. This corruption could be carried out by unprivileged users and could result in code execution with root privilege, effectively escalating the unprivileged user to root in an unauthorized way.
The vulnerability affects virtually all Linux distributions running kernels released from 2017 until patched versions are applied, including but not limited to Ubuntu (for example, 24.04 LTS), Amazon Linux 2023, Red Hat Enterprise Linux (RHEL 10.1), and SUSE 16, as well as other distributions like Debian, Fedora, and Arch Linux. The CVSS score is 7.8 (High), reflecting its significant impact.
From an impact assessment standpoint, successful exploitation leads to full root privilege escalation (high impact to confidentiality, integrity, and availability) and could facilitate container breakout, multi-tenant compromise, and lateral movement within shared environments. Its reliability, stealth (in-memory-only modification), and cross-platform applicability make it particularly dangerous in cloud, CI/CD, and Kubernetes environments where untrusted code execution is common.
CVE-2026-31431 (also known as “Copy Fail”) is a high‑severity local privilege escalation (LPE) vulnerability affecting the Linux kernel’s cryptographic subsystem. The vulnerability type is a logic flaw within the algif_aead module of the AF_ALG (userspace crypto API), which results in improper handling of memory during in-place operations.
The attack vector is local (AV:L) and requires low privileges with no user interaction, meaning any unprivileged user on a vulnerable system can attempt exploitation. Critically, this vulnerability is not remotely exploitable in isolation, but becomes highly impactful when chained with an initial access vector such as Secure Shell (SSH) access, malicious CI job execution, or container footholds. The primary prerequisite for exploitation is the ability to execute code as a local non-privileged user on a system running a vulnerable Linux kernel with the affected crypto module enabled.
From a technical perspective, the flaw originates from an in-place optimization introduced in 2017, where the kernel reuses source memory as the destination during cryptographic operations. By abusing the interaction between the AF_ALG socket interface and the splice() system call, an attacker can perform a controlled 4-byte write into the kernel’s page cache of any readable file. This enables corruption of in-memory representations of privileged binaries (for example, /usr/bin/su) without modifying the on-disk file.
When executed, the modified binary yields root privileges, effectively breaking the system’s privilege boundary. Notably, the exploit is deterministic, does not rely on race conditions, and could be implemented in a very small (~732‑byte) script that works across distributions. Because the page cache is shared across containers and the host , the vulnerability also enables cross-container impacts and container escape scenarios.
The following is one possible exploitation attack chain.
Phase 1: The attacker begins with reconnaissance. This may occur after gaining limited visibility into an environment (for example, a compromised CI runner, web container, or multi‑tenant host). Kernel version information is easily obtainable from within containers and user namespaces and does not require elevated privileges.
Because containers share the host kernel, a single vulnerable kernel version immediately expands the impact radius from one container to the entire node.
Phase 2: The attacker leverages a compact Python script that interacts only with standard kernel interfaces exposed to unprivileged users. The script does not rely on networking, compilation, or third‑party libraries, making it ideal for execution in restricted containers and hardened environments.
Phase 3: The attacker runs the script as either a regular Linux user on a host, or a compromised container process with no special capabilities. Crucially, the vulnerability does not require root inside the container, Kernel modules, or network access. This makes it ideal for post‑exploitation scenarios where the attacker already has any foothold at all.
Phase 4: The exploit abuses an interaction between the AF_ALG (asynchronous crypto) socket interface, the splice() system call and improper error handling during a failed copy operation. This results in a controlled 4‑byte overwrite in the kernel page cache, allowing the attacker to corrupt sensitive kernel‑managed data even though they are unprivileged. This corruption occurs entirely within the kernel, bypassing traditional user‑space protections.
Phase 5: By corrupting kernel structures associated with credentials or execution context, the attacker escalates their process to UID 0. This completes the transition from unprivileged user to full root without touching the network. At this point, kernel trust boundaries are broken, SELinux/AppArmor protections are effectively neutralized, and local security controls are bypassed.
Mitigation and protection guidance
Immediate actions (0-24 hours):
Identify all instances of affected products/versions in your environment.
Apply mitigation based on patch availability:
If patches exist, apply immediately. Links to security bulletins and vendor patches are available at NVD – CVE-2026-31431.
If no patches exist, choose one of these interim mitigations:
○ Disable affected feature
○ Implement network isolation
○ Apply access controls
Review logs for signs of exploitation.
Because this vulnerability impacts a large swath of Linux devices, it is strongly recommended to do the following:
Patch or update your distribution’s kernel packages or to block AF_ALG socket creation.
Treat any container RCE as potential host compromise and enforce rapid node recycling after compromise indicators.
Microsoft Defender XDR detections
Microsoft Defender XDR customers can refer to the following list of applicable detections. 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.
This research is provided by Microsoft Defender Security Research with contributions from Andrea Lelli, Dietrich Nembhard, Nir Avnery, Ori Glassman, and members of Microsoft Threat Intelligence.
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.
During the first quarter of 2026 (January-March), Microsoft Threat Intelligence detected approximately 8.3 billion email-based phishing threats, with monthly volumes declining slightly from 2.9 billion in January to 2.6 billion in March. By the end of the quarter, QR code phishing emerged as the fastest-growing attack vector, more than doubling over the period, while CAPTCHA-gated phishing evolved rapidly across payload types. Overall, 78% of email threats were link-based, while malicious payloads accounted for 19% of attacks in January—boosted by large HTML and ZIP campaigns—before settling at 13% in both February and March. Credential phishing remained the dominant objective behind malicious payloads throughout the quarter. This shift toward link-based delivery, combined with the payload trends, suggests that threat actors increasingly preferred hosted credential phishing infrastructure over locally-rendered payloads as the quarter progressed.
These trends reflect how threat actors continue to iterate on both scale and delivery techniques to improve effectiveness. At the same time, disruption efforts can meaningfully impact this activity. Following Microsoft’s Digital Crime Unit-led action against the Tycoon2FA phishing-as-a-service (PhaaS) platform in early March, associated email volume declined 15% over the remainder of the month, alongside a significant reduction in access to active phishing pages, limiting the platform’s immediate effectiveness. While Tycoon2FA has since adapted by shifting hosting providers and domain registration patterns, these changes reflect partial recovery rather than full restoration of previous capabilities. Alongside these shifts, business email compromise (BEC) activity remained prevalent, totaling approximately 10.7 million attacks in the quarter, largely driven by low-effort, generic outreach messages. At the same time, Microsoft Defender Research observed early indications of emerging techniques such as device code phishing—sometimes enabled by offerings like EvilTokens—which, while not yet at the scale of the trends discussed below, reflect continued innovation in credential theft methods.
This blog provides a view of email threat activity across the first quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code phishing, CAPTCHA evasion tactics, malicious payloads, and BEC activity, analyze how disruption efforts and infrastructure changes influenced threat actor operations, and provide recommendations and Microsoft Defender detections to help mitigate these threats. By bringing these trends together, this blog can help defenders understand how email-based attacks are evolving and where to focus detection, mitigation, and user protection strategies.
Tycoon2FA disruption impact
Since its emergence in August 2023, Tycoon2FA has rapidly become one of the most widespread PhaaS platforms, leveraging adversary-in-the-middle (AiTM) techniques to attempt to defeat non-phishing-resistant multifactor authentication (MFA) defenses. The group behind the PhaaS platform (tracked by Microsoft Threat Intelligence as Storm-1747) leases malicious infrastructure and sells phishing kits that impersonate various enterprise application sign-in pages and incorporate evasion tactics, such as fake CAPTCHA pages.
The quarter began with Tycoon2FA in a period of reduced activity. January volumes represented a 54% decline from December 2025, marking the second consecutive month of sharp decreases. While post-holiday seasonal effects may have contributed to this decrease in volume, some of the reduction might also have been the result of Microsoft’s Digital Crimes Unit disruption of RedVDS, a service used by many Tycoon2FA customers to distribute malicious email campaigns.
After surging 44% in February, phishing attacks pointing to Tycoon2FA fell 15% in March driven largely by the effects of a coordinated disruption operation. In early March 2026, Microsoft’s Digital Crimes Unit, in coordination with Europol and industry partners, took action to disrupt Tycoon2FA’s infrastructure and operations, significantly impairing the platform’s hosting capabilities. While Tycoon2FA-linked messages continued to circulate after the disruption, almost one-third of March’s total volume was concentrated in a three-day period early in the month; daily volumes for the remainder of March were notably lower than historical averages, and targets’ ability to reach active phishing pages was substantially reduced.
Tycoon2FA’s infrastructure composition evolved multiple times during the first three months of 2026. In January, Tycoon2FA domains started shifting toward newer generic top-level domains (TLDs) such as .DIGITAL, .BUSINESS, .CONTRACTORS, .CEO, and .COMPANY, moving away from previous commonly used TLDs or second-level domains like .SA.COM, .RU, and .ES. This trend became even more well-established in February. Following the March disruption, however, Microsoft Threat Intelligence observed a notable increase in Tycoon2FA domains with .RU registrations, with more than 41% of all Tycoon2FA domains using a .RU TLD since the last week of March.
Figure 2. Top TLDs and second-level domains (2LDs) associated with Tycoon2FA infrastructure (November 2025 – March 2026)
Additionally, toward the end of March, we saw Tycoon2FA moving away from Cloudflare as a hosting service and now hosts most of its domains across a variety of alternative platforms, suggesting the group is attempting to find replacement services that offer comparable anti-analysis protections.
QR code phishing attacks
In recent years, QR codes have rapidly emerged as a preferred tool among phishing threat actors seeking to bypass traditional email defenses. By embedding malicious URLs within image-based QR codes in the body of an email or within the contents of an attachment, threat actors attempt to exploit the limitations of text-based scanning engines and redirect victims to phishing sites on unmanaged mobile devices.
The most significant shift in Q1 2026 was the rapid escalation of QR code phishing, with attack volumes increasing from 7.6 million in January to 18.7 million in March, a 146% increase over the quarter. After an initial 35% decline in January (continuing a late-2025 downtrend), volumes reversed course dramatically, growing 59% in February and another 55% in March. By the end of the quarter, QR code phishing had reached its highest monthly volume in at least a year.
Figure 3. Trend of QR code phishing attacks by weekly volume (November 2025 – March 2026)
PDF attachments were the dominant delivery method throughout the quarter, growing from 65% of QR code attacks in January to 70% in March. While the overall volume of DOC/DOCX payloads containing malicious QR codes steadily increased each month, their share of overall delivery payloads decreased from 31% in January to 24% in March. A notable late-quarter development was the emergence of QR codes embedded directly in email bodies, which surged 336% in March. While still a small share of total volume (5%), this approach eliminates the need for an attachment altogether and highlights a shift in threat actor delivery methods that defenders should continue to monitor.
CAPTCHA tactics
Threat actors use CAPTCHA pages to delay detection and increase user interaction. These pages function as a visual decoy, giving the appearance of a legitimate security check while concealing a transition to malicious content. By forcing users to engage with the CAPTCHA before accessing the payload, threat actors reduce the likelihood of automated scanning tools identifying the threat and increase the chances of successful credential harvesting or malware delivery. Additionally, fake CAPTCHAs are used in ClickFix attacks to trick users into copying and executing malicious commands under the guise of human verification, allowing malware to bypass conventional security controls.
After declining in both January (-45%) and February (-8%), CAPTCHA-gated phishing volumes exploded in March, more than doubling (+125%) to 11.9 million attacks, the highest volume observed over the last year.
Figure 4. CAPTCHA-gated phishing volume (November 2025 – March 2026)
The most notable aspect of Q1 CAPTCHA trends was the rapid rotation of delivery methods, as threat actors appeared to actively experiment with which payload formats most effectively evade email defenses:
HTML attachments started the year as the most common method to deliver CAPTCHA-gated phishing (37% in January), but dropped 34% in February, hitting its lowest monthly volume since August 2025. Although their volume more than doubled in March, hitting an annual monthly high, HTML files were still only the second-most common delivery method to close the quarter.
SVG files, which had seen consecutive months of decreasing volumes, grew by 49% in February at the same time nearly every other delivery payload type decreased. Because of this, it was the most common delivery method for the month, which had not happened since November 2025. This one-month spike reversed itself in March, however, and the number of SVG files delivering CAPTCHA-gated phish fell by 57%, accounting for just 7% of delivery payloads.
PDF files saw a meteoric rise in volume during the first quarter of the year. After seeing steady month-over-month declines since July 2025, and hitting an annual monthly low point in January 2026, the number of PDF attachments leading to CAPTCHA-gated phishing sites more than quadrupled in March (+356%). Not only did it retake its spot as the most common delivery method for these attacks since last July, but it eclipsed its annual high by more than 37%.
DOC/DOCX files, which didn’t make up more than 9% of CAPTCHA-gated phishing payloads over the previous nine months, increased almost five times (+373%) in March to account for 15% of payloads.
Email-embedded URLs, which had once delivered more than half of CAPTCHA-gated phish at the end of August 2025, hit an eight-month low after falling 85% between December and February. While their volume nearly doubled in March, they remained well below late-2025 levels.
Figure 5. Monthly CAPTCHA-gated phishing volume by distribution method (Q1 2026)
Another notable shift in CAPTCHA-gated phishing attacks was the erosion of Tycoon2FA’s impact on the landscape. At the end of 2025, more than three-quarters of CAPTCHA-gated phishing sites were hosted on Tycoon2FA infrastructure. This share decreased significantly over the course of the first three months of 2026, falling to just 41% in March. This broadening of CAPTCHA-gated phishing sites being used by an increasing number of threat actors and phishing kits, combined with the overall surge in volume, indicates that this technique is becoming a more entrenched component of the phishing playbook rather than a specialty of a small number of tools.
Three-day campaign delivers CAPTCHA-gated phishing content using malicious SVG attachments
Between February 23 and February 25, 2026, a large, sustained campaign sent more than 1.2 million messages to users at more than 53,000 organizations in 23 countries. Messages in the campaign included a number of different themes, including an important 401K update, a credit hold warning, a question about a received payment, a payment request for a past due invoice, and a voice message notification.
Many of the messages contained a fake confidentiality disclaimer to enhance the credibility of the messages and provide a proactive excuse about why a recipient may have mistakenly received an email that may not be applicable to them.
Figure 6. Example fake confidentiality message used in February 23-25 phishing campaign
Attached to each message was an SVG file that was named to appropriately match the theme of the email. All the file names included a Base64-encoded version of the recipient’s email address. Example of file names used in the campaign include the following:
If an attached SVG file was opened, the user’s browser would open locally and fetch content from one of the three following hostnames:
bouleversement.niovapahrm[.]com
haematogenesis.hvishay[.]com
ubiquitarianism.drilto[.]com
Initially, the user would be shown a “security check” CAPTCHA. Once the CAPTCHA had been successfully completed, the user would then be shown a fake sign-in page used to compromise their account credentials.
Malicious payloads
Credential phishing tightened its grip on the malicious payload landscape across Q1, growing from 89% of all payload-based attacks in January to 95% in February before settling at 94% in March. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery continued its long-term decline, representing just 5–6% of payloads by the end of the quarter.
Figure 7. Malicious payloads by file type (Q1 2026)
The most striking payload trend was the volatility across file types, driven by large campaigns that created dramatic week-to-week swings:
HTML attachments started Q1 as the leading file type (37% of payloads in January), fell to an annual low in February (-57%), then nearly tripled in March (+175%). This volatility was largely campaign-driven, with concentrated activity in the first half of January and the third week of March.
Malicious PDFs followed a steady upward trajectory, increasing 38% in February and another 50% in March to reach their highest monthly volume in over a year. By March, PDFs accounted for 29% of payloads, up from 19% in January.
ZIP/GZIP attachments were similarly volatile by nearly doubling in January (+94%), dropping 38% in February, then surging 79% in March. Threat actors commonly use ZIP files to circumvent Mark of the Web (MOTW) protections.
SVG files emerged briefly in February as a notable delivery method (with a 50% volume increase) before declining 32% in March, mirroring the pattern seen in CAPTCHA-gated phishing.
Figure 8. Daily malicious payload file type (Q1 2026)
Large-scale HTML phishing campaign hosts content on multiple PhaaS infrastructures
On March 17, 2026, Microsoft Threat Intelligence observed a massive phishing campaign that drove a significant surge in malicious HTML attachments during the month. The campaign involved more than 1.5 million confirmed malicious messages sent to over 179,000 organizations across 43 countries, accounting for approximately 7% of all malicious HTML attachments observed in March.
All messages in this campaign were likely sent using the same tool or service, which exhibited several distinct and highly consistent characteristics. Most notably, sender addresses across the campaign featured excessively long, keyword‑stuffed usernames that embedded URLs, tracking identifiers, and service references. These usernames were crafted to resemble legitimate transactional, billing, or document‑related notification senders. Examples of observed sender usernames include:
The emails themselves contained little to no message body content. While subject lines varied, they consistently impersonated routine business and workflow notifications, including payment and remittance alerts (for example, Automated Clearing House (ACH), Electronic Funds Transfer (EFT), wire), invoice or aging statements, and e‑signature or document delivery requests. These subjects relied on urgency, approval language, and transactional framing to prompt recipients to review, sign, or access an attached document.
Each message included an HTML attachment with a file name aligned to the email’s theme. When opened, the HTML file launched locally on the recipient’s device and immediately redirected the user to an initial external staging page. This page performed basic screening and then redirected the user to a secondary landing page hosting the phishing content. On the final landing page, users were presented with a CAPTCHA challenge before being directed to a fraudulent sign‑in page designed to harvest account credentials.
Interestingly, although messages in this campaign shared common tooling, structure, and delivery characteristics, the infrastructure hosting the final phishing payload was linked to multiple different PhaaS providers. Most observed phishing endpoints were associated with Tycoon2FA, while additional activity was linked to Kratos (formerly Sneaky2FA) and EvilTokens infrastructure.
Business email compromise
Microsoft defines business email compromise (BEC) as a text-based attack targeting enterprise users that impersonates a trusted entity for the purpose of persuading a recipient into initiating a fraudulent financial transaction or sending the threat actor sensitive documents. These attacks fluctuated across Q1, totaling approximately 10.7 million attacks: rising 24% in January, dipping 8% in February, then surging 26% in March.
The composition of BEC attacks remained consistent throughout Q1. Generic outreach messages (like “Are you at your desk?”) accounted for 82–84% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 9–10%. This pattern underscores that BEC operators overwhelmingly favor establishing a conversational rapport before making fraudulent requests, rather than leading with direct financial asks.
Within the smaller subset of explicit financial requests, two sub-categories showed notable movement. Payroll update requests grew 15% in February, reaching their highest volume in eight months, potentially reflecting tax season-related social engineering. Gift card requests fell 37% in February to their lowest level since July before rebounding sharply in March (+108%), though they still represented less than 3% of overall BEC messages. These fluctuations suggest that BEC operators adjust their specific financial pretexts seasonally while maintaining a consistent overall approach.
Figure 10. Initial BEC email content by type (Q1 2026)
Defending against email threats
Microsoft recommends the following mitigations to reduce the impact of this threat.
Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Microsoft Defender for Endpoint
The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.
Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site
Microsoft Defender for Office 365
The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.
A potentially malicious URL click was detected
A user clicked through to a potentially malicious URL
Suspicious email sending patterns detected
Email messages containing malicious URL removed after delivery
Email messages removed after delivery
Email reported by user as malware or phish
Microsoft Security Copilot
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following Threat Analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
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 shift to remote and hybrid work since the pandemic expanded global hiring and accelerated digital onboarding, increasing reliance on online identity verification and remote access. Threat actors such as Jasper Sleet, a North Korea-aligned threat actor, exploit this model by posing as legitimate hires using stolen or fabricated identities and AI-assisted deception to gain trusted access, generate revenue, and in some cases enable data theft, extortion, or follow-on compromise.
In the initial job-discovery phase, these fraudulent applicants posing as remote IT workers systematically survey organization career sites and external hiring portals to identify active technical roles and recruitment workflows. A previously published Microsoft Threat Intelligence blog highlights how these actors use generative AI at scale to analyze job postings and extract role‑specific language, required skills, certifications, and tooling expectations. They then use those insights to construct tailored fake digital personas and submit highly convincing job applications, increasing their likelihood of passing screening and entering legitimate hiring pipelines, and even onboarding once hired into the targeted roles successfully.
Organizations using common and widely adopted human resources (HR) software as a service (SaaS) platforms like Workday often expose their job postings through external career sites for applicants to submit job applications. These job listing sites are often targeted by this threat actor to find open job roles. While this activity might be hard to detect from usual job hunting behavior, knowing the threat actor’s interests and objectives to infiltrate into the target organization might present an opportunity for defenders to look for anomalous patterns in a hiring candidate’s behaviors by leveraging the access to the right telemetry and available threat actor intelligence being published.
While these activities could happen on any HR SaaS platform, this blog focuses on Workday as an example due to its widespread adoption and rich event logs, which are useful for hunting and detection, that are available to customers. The discussion highlights how customers using Microsoft Defender for Cloud Apps can monitor and detect fraudulent remote IT worker activity in pre-recruitment and post-recruitment phases, offering guidance on threat hunting and relevant threat detection strategies to help security and HR teams surface suspicious candidates early and detect risky onboarding activity after hire.
Attack chain overview
In the observed campaigns, the threat actors leverage routine HR workflows like external-facing career sites with open job postings to help with their job search and application process. Once they’re successfully contacted, interviewed, and hired, they complete typical new-hire onboarding formalities like setting up payroll accounts, which are also through the HR SaaS platform like Workday.
Figure 1. Timeline of events through the recruitment phases.
Activities in pre-recruitment phase
In the pre-recruitment phase, Microsoft has observed Jasper Sleet accessing Workday Recruiting Web Service endpoints exposed through external career sites from known actor infrastructure and email accounts, indicating a discovery phase of open roles and recruitment workflows.
Workday lets organizations use internal, non-public APIs such as Recruiting Web Service to allow programmatic access to apply for jobs in these organizations. These APIs are used to connect to external career sites involved in talent management and applicant tracking systems and allow applicants to browse and apply for open job roles. To access these APIs, an organization has to allow setting up of OAuth clients and associated OAuth tokens, and expose the APIs so that the organization’s external career sites can use them.
Microsoft has observed API call events coming from known Jasper Sleet infrastructure in Workday telemetry to hrrecruiting/* API endpoints. These events access information about job postings, applications, and related questionnaires, and to submit job applications and questionnaires.
Some common API calls being made by the threat actor’s activity when using the Workday portal include the following:
hrrecruiting/accounts/*
hrrecruiting/jobApplicationPackages/*
hrrecruiting/validateJobApplication/*
hrrecruiting/resumes/*
Figure 2. Sample view of API call events indicating access to hrrecruiting API endpoints on an organization’s Workday instance from an external account.
It’s important to note here that these API calls could also be made by legitimate job applicants. However, Microsoft has observed the Jasper Sleet threat actor using multiple external accounts suspiciously to access the same set of API calls in a consistent, repeating pattern, as shown in Figure 2, indicating a possible job discovery phase activity on open job roles and following up on job applications submitted. This anomaly sets the threat actor behavior apart from legitimate job applicants.
Defender for Cloud Apps’ Workday connector enables organizations to view and track API activity to their /hrrecruiting endpoints. The connector also lets them identify external accounts and their corresponding infrastructure metadata. Organizations can match this information against any available threat intelligence feeds on Jasper Sleet so they can identify fraudulent applications early in the recruiting process.
Activities in recruiting phase
In the recruiting phase, signals outside of Workday could help with investigation of threat actor behavior. The threat actor communicates with the target organization’s hiring team using emails and meeting conferencing platforms like Microsoft Teams, Zoom, or Cisco Webex for scheduling interviews. Using advanced hunting tables in Microsoft Defender, organizations can track suspicious communications (for example, email and Teams messages with external accounts originating from suspicious IP addresses or email addresses that could possibly be associated with the threat actor) and raise a red flag early in the hiring process. Additionally, organizations that use Zoom or Cisco Webex must leverage Defender for Cloud Apps’ Zoom or Cisco Webex connectors to detect malicious external accounts in the interviewing process.
Organizations can also leverage Defender for Cloud Apps’ DocuSign connector, which enables them to monitor activity related to hiring documentation, like offer letter signing from suspicious external sources.
Activities in post-recruitment phase
When Jasper Sleet is hired for a role in the organization, a legitimate account is created and assigned to them as part of the onboarding process. In organizations that use HR workflows in Workday for onboarding new hires, we’ve observed sign-ins to the newly created Workday profile and setting up of payroll details originating from known Jasper Sleet infrastructure.
Figure 3. A sample event indicating a payroll account change operation by a new hire.
The threat actor now has legitimate access to organization data, and they can access internal SaaS applications like Teams, SharePoint, OneDrive, and Exchange Online. Hence, it’s important to investigate any alerts associated with new hire accounts, especially alerts that are related to access to organization data from different locations and anonymous proxies performing search and downloads on Microsoft 365 suite or other third-party SaaS applications. Microsoft has observed a spike in impossible travel alerts for such new hires, indicating suspicious remote IT worker behavior in the initial months of onboarding.
Figure 4. Frequent impossible travel alerts on a new hire in the first two months since joining.
Mitigation and protection guidance
Microsoft recommends leveraging access to telemetry coming from multiple data sources and monitoring behavioral anomalies in hiring candidates as part of background verification in HR recruitment processes. Organizations can also leverage threat intelligence as an aid, when available, to strengthen confidence in these anomalies.
These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR.
Organizations can follow these recommendations to mitigate threats associated with this threat actor:
Enable connectors in Microsoft Defender for Cloud Apps to gain visibility and track activity from external user accounts associated with fraudulent candidates. Investigate events of both external users and newly hired internal users originating from malicious infrastructure. For more information, see the following articles in Microsoft Learn:
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.
Tactic
Observed activity
Microsoft Defender coverage
Resource Development
Threat actors accessing external facing Workday sites to research job postings and submit job applications.
Microsoft Defender for Cloud Apps – Possible Jasper Sleet threat actor activity in Workday Recruiting Web Service
Resource Development
Once hired and onboarded, the threat actor signs in to the newly created Workday account to update payroll details from known Jasper Sleet infrastructure
Microsoft Defender for Cloud Apps – Suspicious Payroll and Finance related activity in Workday
Initial Access
Anomalous sign-ins and access to internal resources by newly hired threat actor
Microsoft Defender XDR – Impossible travel – Sign-in activity by suspected North Korean entity Jasper Sleet
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Hunting queries
Microsoft Defender XDR customers can run the following queries to find related activity to any suspicious indicators in their networks:
Access to Workday Recruiting Web Service API by external users
let api_endpoint_regex = 'hrrecruiting/*';
CloudAppEvents
| where Application == 'Workday'
| where IsExternalUser
| where ActionType matches regex api_endpoint_regex
| where IPAddress in () or AccountId in ();
| summarize make_set(ActionType) by AccountId, IPAddress, bin(Timestamp, 1d)
Emails and Teams communications related to interviews
//Email communications
EmailEvents
| where SenderMailFromAddress == "" or RecipientEmailAddress == ""
| where Subject has "Interview"
| project Timestamp, SenderMailFromAddress, SenderDisplayName, SenderIPv4, SenderIPv6, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation
EmailEvents
| where SenderIPv4 == "" or SenderIPv6 == ""
| where Subject has "Interview"
| project Timestamp, SenderMailFromAddress, SenderDisplayName, SenderIPv4, SenderIPv6, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation
//Microsoft Teams communications
CloudAppEvents
| where Application == "Microsoft Teams"
| where IsExternalUser
| where AccountId == "" or AccountDisplayName == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)
CloudAppEvents
| where Application == "Microsoft Teams"
| where IsExternalUser
| where IPAddress == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)
//Zoom or Cisco Webex communication events after enabling the Microsoft Defender for Cloud apps connectors
CloudAppEvents
| where Application == "Zoom"
| where IsExternalUser
| where IPAddress == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)
CloudAppEvents
| where Application == "Cisco Webex"
| where IsExternalUser
| where IPAddress == ""
| summarize make_set(ActionType) by IPAddress, AccountId, bin(Timestamp, 1d)
Hiring phase involving accessing and signing of agreements through DocuSign
CloudAppEvents
| where Application == "DocuSign"
| where IsExternalUser
| where ActionType == "ENVELOPE SIGNED"
| where IPAddress in ("") or AccountId == ""
New hire onboarding and payroll activities originating from known Jasper Sleet infrastructure
CloudAppEvents
| where Application == "Workday"
| where AccountId == ""
| where ActionType has_any ("Add", "Change", "Assign", "Create", "Modify") and ActionType has_any ("Account", "Bank", "Payment", "Tax")
| where IPAddress in ("")
| summarize make_set(ActionType) by IPAddress, bin(Timestamp, 1d)
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.
Threat actors are initiating cross-tenant Microsoft Teams communications while impersonating IT or helpdesk personnel to socially engineer users into granting remote desktop access. After access is established through Quick Assist or similar remote support tools, attackers often execute trusted vendor-signed applications alongside attacker-supplied modules to enable malicious code execution.
This access pathway might be used to perform credential-backed lateral movement using native administrative protocols such as Windows Remote Management (WinRM), allowing threat actors to pivot toward high-value assets including domain controllers. In observed intrusions, follow-on commercial remote management software and data transfer utilities such as Rclone were used to expand access across the enterprise environment and stage business-relevant information for transfer to external cloud storage. This intrusion chain relies heavily on legitimate applications and administrative protocols, allowing threat actors to blend into expected enterprise activity during multiple intrusion phases.
Threat actors are increasingly abusing external Microsoft Teams collaboration to impersonate IT or helpdesk personnel and convince users to grant remote assistance access. From this initial foothold, attackers can leverage trusted tools and native administrative protocols to move laterally across the enterprise and stage sensitive data for exfiltration—often blending into routine IT support activity throughout the intrusion lifecycle. Microsoft Defender provides correlated visibility across identity, endpoint, and collaboration telemetry to help 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 channels, attackers may initiate contact through applications such as Microsoft Teams in a way that appears consistent with routine IT support interactions.
Microsoft Teams applies multiple security controls at the point of first external contact – before any chat, call, or file exchange occurs – including external tenant labeling, Accept/Block prompts, message previews, and phishing indicators designed to help users assess risk prior to engagement. However, this attack chain relies on convincing users to bypass those warnings and voluntarily grant remote access through legitimate support tools. In observed intrusions, risk is introduced not by external messaging alone, but when a user approves follow on actions — such as launching a remote assistance session — that result in interactive system access.
In observed intrusions, risk is introduced not by external messaging alone, but when a user approves follow‑on actions — such as launching a remote assistance session — that result in interactive system access.
An approved external Teams interaction might enable threat actors to:
Establish credential-backed interactive system access
Deploy trusted applications to execute attacker-controlled code
Pivot toward identity and domain infrastructure using WinRM
Deploy commercially available remote management tooling
Stage sensitive business-relevant data for transfer to external cloud infrastructure
In the campaign, lateral movement and follow-on tooling installation occurred shortly after initial access, increasing the risk of enterprise-wide persistence and targeted data exfiltration. As each environment is different and with potential handoff to different threat actors, stages might differ if not outright bypassed.
Figure 1: Attack chain.
Attack chain overview
Stage 1: Initial contact via Teams (T1566.003 Spearphishing via Service)
The intrusion begins with abuse of external collaboration features in Microsoft Teams, where an attacker operating from a separate tenant initiates contact while impersonating internal support personnel as a means to social engineer the user. This activity does not stem from a weakness in Microsoft Teams or its built‑in security protections. Instead, attackers abuse legitimate collaboration features by persuading users to override multiple, clearly presented security warnings, highlighting the broader challenge of defending against attacks driven by social engineering rather than technical exploitation.
Because interaction occurs within an enterprise collaboration platform rather than through traditional email‑based phishing vectors, it might bypass initial user skepticism associated with unsolicited external communication. Security features protecting Teams users are detailed here, for reference. It’s important to note that this attack relies on users willfully ignoring or overlooking security notices and other protection features. The lure varies and might include “Microsoft Security Update”, “Spam Filter Update”, “Account Verification” but the objective is constant: convince the user to ignore warnings and external contact flags, launch a remote management session, and accept elevation. Voice phishing (vishing) is sometimes layered to increase trust or compliance if voice interactions don’t replace the messaging altogether.
Timing matters. We regularly see a “ChatCreated” event to indicate a first contact situation, followed by suspicious chats or vishing, remote management, and other events that commonly produce alerts to include mailbombing or URL click alerts. All of these can be correlated by account and chat thread information in your Defender hunting environment.
Teams security warnings:
External Accept/Block screens provide notice to users about First Contact events, which prompt the user to inspect the sender’s identity before accepting:
Figure 2: External Accept/Block screens.
Higher confidence warnings alert the user of spam or phishing attempts on first contact:
Figure 3: spam or phishing alert.
External warnings notify users that they are communicating with a tenant/organization other than their own and should be treated with scrutiny:
Figure 4: External warnings.
Message warnings alert the user on the risk in clicking the URL:
Figure 5: URL click warning.
Safe Links for time-of-click protection warns users when URLs from Teams chat messages are malicious:
Figure 6: time-of-click protection warning.
Zero-hour Auto Purge (ZAP) can remove messages that were flagged as malicious after they have been sent:
Figure 7: Removed malicious from ZAP.
It’s important to note that the attacker often does not send the URL over a Teams message. Instead, they will navigate to it while on the endpoint during a remote management session. Therefore, the best security is user education on understanding the importance of not ignoring external flags for new helpdesk contacts. See “User education” in the “Defend, harden, and educate (Controls to deploy now)” section for further advice.
Stage 2: Remote assistance foothold
With user consent obtained through social engineering, the attacker gains interactive control of the device using remote support tools such as Quick Assist. This access typically results in the launch of QuickAssist.exe, followed by the display of standard Windows elevation prompts through Consent.exe as the attacker is guided through approval steps.
Figure 8: Quick Assist Key Logs.
From the user’s perspective, the attacker convinces them to open Quick Assist, enter a short key, the follow all prompts and approvals to grant access.
Figure 9 – Quick Assist Launch.
This step is often completed in under a minute. The urgency and interactivity are the signal: a remote‑assist process tree followed immediately by “cmd.exe” or PowerShell on the same desktop.
Stage 3: Interactive reconnaissance and access validation
Immediately after establishing control through Quick Assist, the attacker typically spends the first 30–120 seconds assessing their level of access and understanding the compromised environment. This is often reflected by a brief surge of cmd.exe activity, used to verify user context and privilege levels, gather basic system information such as host identity and operating system details, and confirm domain affiliation. In parallel, the attacker might query registry values to determine OS build and edition, while also performing quick network reconnaissance to evaluate connectivity, reachability, and potential opportunities for lateral movement.
Figure 10: Enumeration.
On systems with limited privileges—such as kiosks, VDI, or non-corp-joined devices—actors might pause without deploying payloads, leaving only brief reconnaissance activity. They often return later when access improves or pivot to other targets within the same tenant.
Stage 4: Payload placement and trusted application invocation
Once remote access is established, the intrusion transitions from user‑assisted interaction to preparing the environment for persistent execution. At this point, attackers introduce a small staging bundle onto disk using either archive‑based deployment or short‑lived scripting activity. As activity moves beyond initial social engineering, Microsoft security protections shift from user‑facing warnings to behavior‑based detection, correlation, and automated response across identity, endpoint, and network layers.
After access is established, attackers stage payloads in locations such as ProgramData and execute them using DLL side‑loading through trusted signed applications. This includes:
AcroServicesUpdater2_x64.exe loading a staged msi.dll
Allowing attacker‑supplied modules to run under a trusted execution context from non‑standard paths.
Figure 11: Sample Payload.
Stage 5: Execution context validation and registry backed loader state
Following payload delivery, the attacker performs runtime checks to validate host conditions before execution. A large encoded value is then written to a user‑context registry location, serving as a staging container for encrypted configuration data to be retrieved later at runtime.
In this stage, a sideloaded module acting as an intermediary loader decrypts staged registry data in memory to reconstruct execution and C2 configuration without writing files to disk. This behavior aligns with intrusion frameworks such as Havoc, which externalize encrypted configuration to registry storage, allowing trusted sideloaded components to dynamically recover execution context and maintain operational continuity across restarts or remediation events.
Microsoft Defender for Endpoint may detect this activity as:
Execution from user‑writable directories such as ProgramData
Attack surface reduction rules and Windows Defender Application Control policies can be used to restrict execution pathways commonly leveraged for sideloaded module activation.
Stage 6: Command and control
Following successful execution of the sideloaded component, the updater‑themed process AcroServicesUpdater2_x64.exe began initiating outbound HTTPS connections over TCP port 443 to externally hosted infrastructure.
Unlike expected application update workflows which are typically restricted to known vendor services these connections were directed toward dynamically hosted cloud‑backed endpoints and unknown external domains. This behavior indicates remote attacker‑controlled infrastructure rather than legitimate update mechanisms.
Establishing outbound encrypted communications in this manner enables compromised processes to operate as beaconing implants, allowing adversaries to remotely retrieve instructions and maintain control within the affected environment while blending command traffic into routine HTTPS activity. The use of cloud‑hosted hosting layers further reduces infrastructure visibility and improves the attacker’s ability to modify or rotate communication endpoints without altering the deployed payload.
This activity marks the transition from local execution to externally directed command‑and‑control — enabling subsequent stages of discovery and movement inside the enterprise network.
Stage 7: Internal discovery and lateral movement toward high value assets
Shortly after external communications were established, the compromised process began initiating internal remote management connections over WinRM (TCP 5985) toward additional domain‑joined systems within the enterprise environment.
Microsoft Defender may surface these activities as multi‑device incidents reflecting credential‑backed lateral movement initiated from a user‑context remote session.
Analysis of WinRM activity indicates that the threat actor used native Windows remote execution to pivot from the initially compromised endpoint toward high‑value infrastructure assets, including identity and domain management systems such as domain controllers. Use of WinRM from a non‑administrative application suggests credential‑backed lateral movement directed by an external operator, enabling remote command execution, interaction with domain infrastructure, and deployment of additional tooling onto targeted hosts.
Targeting identity‑centric infrastructure at this stage reflects a shift from initial foothold to broader enterprise control and persistence. Notably, this internal pivot preceded the remote deployment of additional access tooling in later stages, indicating that attacker‑controlled WinRM sessions were subsequently leveraged to extend sustained access across
Stage 8: Remote deployment of auxiliary access tooling (Level RMM)
Subsequent activity revealed the remote installation of an additional management platform across compromised hosts using Windows Installer (msiexec.exe). This introduced an alternate control channel independent of the original intrusion components, reducing reliance on the initial implant and enabling sustained access through standard administrative mechanisms. As a result, attackers could maintain persistent remote control even if earlier payloads were disrupted or removed.
Stage 9: Data exfiltration
Actors used the file‑synchronization tool Rclone to transfer data from internal network locations to an external cloud storage service. File‑type exclusions in the transfer parameters suggest a targeted effort to exfiltrate business‑relevant documents while minimizing transfer size and detection risk.
Microsoft Defender might detect this activity as possible data exfiltration involving uncommon synchronization tooling.
Mitigation and protection guidance
Family / Product
Protection
Reference documents
Microsoft Teams
Review external collaboration policies and ensure users receive clear external sender notifications when interacting with cross‑tenant contacts. Consider device‑ or identity‑based access requirements prior to granting remote support sessions.
Enable Safe Links for Teams conversations with time-of-click verification, and ensure zero-hour auto purge (ZAP) is active to retroactively quarantine weaponized messages.
Disable or restrict remote management tools to authorized roles, enable standard ASR rules in block mode, and apply WDAC to prevent DLL sideloading from ProgramData and AppData paths used by these actors.
Enforce Conditional Access requiring MFA and compliant devices for administrative roles, restrict WinRM to authorized management workstations, and monitor for Rclone or similar synchronization utilities used for data exfiltration via hunting or custom alerts tuned to your environment.
Enable network protection to block implant C2 beaconing to poor-reputation and newly registered domains, and alert on registry modifications to ASEP locations by non-installer processes. Hunting and custom detections tuned to your environment will assist in detecting network threats.
The attackers will often initiate Teams calls with their targets to talk them through completing actions that result in machine compromise. It may be useful to establish a verbal authentication code between IT Helpdesk and employees: a key phrase that an attacker is unlikely to know. Inform employees how IT Helpdesk would normally reach out to them: which medium(s) of communication? Email, Teams, Phone calls, etc. What identifiers would those IT Helpdesk contacts have? Domain names, aliases, phone numbers, etc. Show example images of your Helpdesk vs. an attacker impersonating them over your communication medium. Show examples of how to identify external versus internal Teams communications, block screens, message and call reporting, as well as how to identify a display name vs. the real caller’s name and domain. Inform employees that URLs shared by an external Helpdesk account leading to Safe Links warnings about malicious websites are extremely suspicious. They should report the message as phish and contact your security team. If they receive any URLs from IT Helpdesk that involve going to a webpage for security updates or spam mailbox cleanings, then they should report that to your security team. Treat unsolicited and unexpected external contact from IT Helpdesk as inherently suspicious.
When Defender detects credential‑backed WinRM lateral movement following a Quick Assist session, Automatic Attack Disruption can suspend the originating user session and contain the users prior to domain‑controller interaction — limiting lateral movement before your SOC engages. Look for incidents tagged “Attack Disruption” in your queue.
Teams/MDO, Entra ID, and MDE signals are automatically correlated into unified incidents. This entire attack chain surfaces as one multi-stage incident — not dozens of disconnected alerts. Review “Multi-stage” incidents for the full story.
Threat analytics reports for these TTPs include exposure assessments and mitigations for your environment. Detection logic is continuously updated to reflect evolving tradecraft. Check your Threat Analytics dashboard for reports tagged to these Storm actors.
When an external user initiates contact, Teams presents the recipient with a message preview and an explicit Accept or Block prompt before any conversation begins. Blocking prevents future messages and hides your presence status from that sender.
Following security recommendations can help in improving the security posture of the org. Apply UAC restrictions to local accounts on network logonsSafe DLL Search ModeEnable Network ProtectionDisable ‘Allow Basic authentication’ for WinRM Client/Service
Microsoft Defender provides pre-breach and post-breach coverage for this campaign, supported by the generic and specific alerts listed below.
Tactic
Observed activity
Microsoft Defender coverage
Initial Access
The actor initiates a cross‑tenant Teams chat or call from an often newly created tenant using an IT/Help‑Desk persona
Microsoft Defender for Office 365 – Microsoft Teams chat initiated by a suspicious external user – IT Support Teams Voice phishing following mail bombing activity – A user clicked through to a potentially malicious URL. – A potentially malicious URL click was detected.
Microsoft Defender for Endpoint – Possible initial access from an emerging threat
Execution
The attacker gains interactive control via remote management tools to include Quick Assist.
Microsoft Defender for Endpoint – Suspicious activity using Quick Assist – Uncommon remote access software – Remote monitoring and management software suspicious activity
The implant or sideloaded host typically beacons over HTTPS
Microsoft Defender for Endpoint – Connection to a custom network indicator – A file or network connection related to a ransomware-linked emerging threat activity group detected
Data Exfiltration
Widely available file‑synchronization utility Rclone to systematically transfer data
Microsoft Defender for Endpoint – Possible data exfiltration
Multi-tactic
Many alerts span across multiple tactics or stages of an attack and cover many platforms.
Microsoft Defender (All) – Multi-stage incident involving Execution – Remote management event after suspected Microsoft Teams IT support phishing – An Office application ran suspicious commands
Hunting queries
Security teams can use the advanced hunting capabilities in Microsoft Defender XDR to proactively look for indicators of exploitation.
A. Teams → RMM correlation
let _timeFrame = 30m;
// Teams message signal
let _teams =
MessageEvents
| where Timestamp > ago(14d)
//| where SenderDisplayName contains "add keyword"
// or SenderDisplayName contains "add keyword"
| extend Recipient = parse_json(RecipientDetails)
| mv-expand Recipient
| extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
VictimRecipientDisplayName = tostring(Recipient.RecipientDisplayName)
| project
TTime = Timestamp,
SenderEmailAddress,
SenderDisplayName,
VictimRecipientDisplayName,
VictimAccountObjectId;
// RMM launches on endpoint side
let _rmm =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
| extend VictimAccountObjectId = tostring(InitiatingProcessAccountObjectId)
| project
DeviceName,
QTime = Timestamp,
RmmTool = FileName,
VictimAccountObjectId;
_teams
| where isnotempty(VictimAccountObjectId)
| join kind=inner _rmm on VictimAccountObjectId
| where isnotempty(DeviceName)
| where QTime between ((TTime) .. (TTime +(_timeFrame)))
| project DeviceName, SenderEmailAddress, SenderDisplayName, VictimRecipientDisplayName, VictimAccountObjectId, TTime, QTime, RmmTool
| order by QTime desc
B. Execution
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "cmd.exe"
| where FileName =~ "cmd.exe"
| where ProcessCommandLine has_all ("/S /D /c", "\" set /p=\"PK\"", "1>")
C. ZIP → ProgramData service path → signed host sideload
let _timeFrame = 10m;
let _armOrDevice =
DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has_any (
"C:\\ProgramData\\Adobe\\ARM\\",
"C:\\ProgramData\\Microsoft\\DeviceSync\\",
"D:\\ProgramData\\Adobe\\ARM\\",
"D:\\ProgramData\\Microsoft\\DeviceSync\\")
and ActionType in ("FileCreated","FileRenamed")
| project DeviceName, First=Timestamp, FileName;
let _hostRun =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("AcroServicesUpdater2_x64.exe","DlpUserAgent.exe","ADNotificationManager.exe")
| project DeviceName, Run=Timestamp, Host=FileName;
_armOrDevice
| join kind=inner _hostRun on DeviceName
| where Run between (First .. (First+(_timeFrame)))
| summarize First=min(First), Run=min(Run), Files=make_set(FileName, 10) by DeviceName, Host
| order by Run desc
D. PowerShell → high‑risk TLD → writes %AppData%/Roaming EXE
let _timeFrame = 5m;
let _psNet = DeviceNetworkEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("powershell.exe","pwsh.exe")
| where RemoteUrl matches regex @"(?i)\.(top|xyz|zip|click)$"
| project DeviceName, NetTime=Timestamp, RemoteUrl, RemoteIP;
let _exeWrite = DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has @"\AppData\Roaming\" and FileName endswith ".exe"
| project DeviceName, WTime=Timestamp, FileName, FolderPath, SHA256;
_psNet
| join kind=inner _exeWrite on DeviceName
| where WTime between (NetTime .. (NetTime+(_timeFrame)))
| project DeviceName, NetTime, RemoteUrl, RemoteIP, WTime, FileName, FolderPath, SHA256
| order by WTime desc
E. Registry breadcrumbs / ASEP anomalies
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\SOFTWARE\Classes\Local Settings\Software\Microsoft"
| where RegistryValueName in~ ("UCID","UFID","XJ01","XJ02","UXMP")
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, PreviousRegistryValueData, InitiatingProcessFileName
| order by Timestamp desc
F. Non‑browser process → API‑Gateway → internal AD protocols
let _timeFrame = 10m;
let _net1 =
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteUrl has ".execute-api."
| where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
| project DeviceName,
Proc=InitiatingProcessFileName,
OutTime=Timestamp,
RemoteUrl,
RemoteIP;
let _net2 =
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemotePort in (135,389,445,636)
| project DeviceName,
Proc=InitiatingProcessFileName,
InTime=Timestamp,
RemoteIP,
RemotePort;
_net1
| join kind=inner _net2 on DeviceName, Proc
| where InTime between (OutTime .. (OutTime+(_timeFrame)))
| project DeviceName, Proc, OutTime, RemoteUrl, InTime, RemotePort
| order by InTime desc
G. PowerShell history deletion
DeviceFileEvents
| where Timestamp > ago(14d)
| where FileName =~ "ConsoleHost_history.txt" and ActionType == "FileDeleted"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath
| order by Timestamp desc
DeviceProcessEvents
| where Timestamp > ago(2d)
| where FileName =~ "rclone.exe" or ProcessVersionInfoOriginalFileName =~ "rclone.exe"
| where ProcessCommandLine has_all ("copy ", "--config rclone_uploader.conf", "--transfers 16", "--checkers 16", "--buffer-size 64M", "--max-age=3y", "--exclude *.mdf")
J. Quick Assist–anchored recon (no staging writes within 10 minutes)
let _reconWindow = 10m; // common within 1-5 minutes
let _stageWindow = 15m; // common 1-2 minutes after recon, or less
// Anchor on RMM
let _rmm =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
| project DeviceName, RMMTime=Timestamp;
// Recon commands within X minutes of RMM start (targeted list)
let _recon =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
| where ProcessCommandLine has_any (
"whoami", "hostname", "systeminfo", "ver", "wmic os get",
"reg query HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
"query user", "net user", "nltest", "ipconfig /all", "arp -a", "route print",
"dir", "icacls"
)
| project DeviceName, ReconTime=Timestamp, ReconCmd=ProcessCommandLine, ReconProc=FileName;
// Suspect staging writes (ZIP/EXE/DLL)
let _staging =
DeviceFileEvents
| where Timestamp > ago(14d)
| where ActionType in ("FileCreated","FileRenamed")
| where FileName matches regex @"(?i).*\\.(zip|exe|dll)$"
| project DeviceName, STime=Timestamp, StageFile=FileName, StagePath=FolderPath;
// Correlate RMM + recon, then exclude cases with staging writes in the next X minutes
let _rmmRecon =
_rmm
| join kind=inner _recon on DeviceName
| where ReconTime between (RMMTime .. (RMMTime+(_reconWindow)))
| project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd;
_rmmRecon
| join kind=leftouter _staging on DeviceName
| extend HasStagingInWindow = iff(STime between (RMMTime .. (RMMTime+(_stageWindow))), 1, 0)
| summarize HasStagingInWindow=max(HasStagingInWindow) by DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd
| where HasStagingInWindow == 0
| project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd
K. Sample Correlation Query Between Chat, First Contact, and Alerts
Note. Please modify or tune for your specific environment.
let _timeFrame = 30m; // Tune: how long after the Teams event to look for matching alerts
let _huntingWindow = 4d; // Tune: broader lookback increases coverage but also cost
// Seed Teams message activity and normalize the victim/join fields you want to carry forward
let _teams = materialize (
MessageEvents
| where Timestamp > ago(_huntingWindow)
| extend Recipient = parse_json(RecipientDetails)
// Optional tuning: add sender/name/content filters here first to reduce volume early
//| where SenderDisplayName contains "add keyword"
// or SenderDisplayName contains "add keyword"
// add other hunting terms
| mv-expand Recipient
| extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
VictimUPN = tostring(Recipient.RecipientSmtpAddress)
| project
TTime = Timestamp,
SenderUPN = SenderEmailAddress,
SenderDisplayName,
VictimUPN,
VictimAccountObjectId,
ChatThreadId = ThreadId
);
// Distinct key sets used to prefilter downstream tables before joining
let _VictimAccountObjectId = materialize(
_teams
| where isnotempty(VictimAccountObjectId)
| distinct VictimAccountObjectId
);
let _VictimUPN = materialize(
_teams
| where isnotempty(VictimUPN)
| distinct VictimUPN
);
let _ChatThreadId = materialize(
_teams
| where isnotempty(ChatThreadId)
| distinct ChatThreadId
);
// Find first-seen chat creation events for the chat threads already present in _teams
// Tune: add more CloudAppEvents filters here if you want to narrow to external / one-on-one / specific chat types
let _firstContact = materialize(
CloudAppEvents
| where Timestamp > ago(_huntingWindow)
| where Application has "Teams"
| where ActionType == "ChatCreated"
| extend Raw = todynamic(RawEventData)
| extend ChatThreadId = tostring(Raw.ChatThreadId)
| where isnotempty(ChatThreadId)
| join kind=innerunique (_ChatThreadId) on ChatThreadId
| summarize FCTime = min(Timestamp) by ChatThreadId
);
// Alert branch 1: match by victim object ID
// Usually the cleanest identity join if the field is populated consistently
let _alerts_by_oid = materialize(
AlertEvidence
| where Timestamp > ago(_huntingWindow)
| where AccountObjectId in (_VictimAccountObjectId)
| project
ATime = Timestamp,
AlertId,
Title,
AccountName,
AccountObjectId,
AccountUpn = "",
SourceId = "",
ChatThreadId = ""
);
// Alert branch 2: match by victim UPN
// Useful when ObjectId is missing or alert evidence is only populated with UPN
let _alerts_by_upn = materialize(
AlertEvidence
| where Timestamp > ago(_huntingWindow)
| where AccountUpn in (_VictimUPN)
| project
ATime = Timestamp,
AlertId,
Title,
AccountName,
AccountObjectId,
AccountUpn,
SourceId = "",
ChatThreadId = ""
);
// Alert branch 3: match by chat thread ID
// Tune: this is typically the most expensive branch because it inspects AdditionalFields
let _alerts_by_thread = materialize(
AlertEvidence
| where Timestamp > ago(_huntingWindow)
| where AdditionalFields has_any (_ChatThreadId)
| extend AdditionalFields = todynamic(AdditionalFields)
| extend
SourceId = tostring(AdditionalFields.SourceId),
ChatThreadIdRaw = tostring(AdditionalFields.ChatThreadId)
| extend ChatThreadId = coalesce(
ChatThreadIdRaw,
extract(@"/(?:chats|channels|conversations|spaces)/([^/]+)/", 1, SourceId)
)
| where isnotempty(ChatThreadId)
| join kind=innerunique (_ChatThreadId) on ChatThreadId
| project
ATime = Timestamp,
AlertId,
Title,
AccountName,
AccountObjectId,
AccountUpn = "",
SourceId,
ChatThreadId
);
//
// add branch 4 to corrilate with host events
//
// Add first-contact context back onto the Teams seed set
let _teams_fc = materialize(
_teams
| join kind=leftouter _firstContact on ChatThreadId
| extend FirstContact = isnotnull(FCTime)
);
// Join path 1: Teams victim object ID -> alert AccountObjectId
let _matches_oid =
_teams_fc
| where isnotempty(VictimAccountObjectId)
| join hint.strategy=broadcast kind=leftouter (
_alerts_by_oid
) on $left.VictimAccountObjectId == $right.AccountObjectId
// Time bound keeps only alerts near the Teams activity; widen/narrow _timeFrame to tune sensitivity
| where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
| extend MatchType = "ObjectId";
// Join path 2: Teams victim UPN -> alert AccountUpn
let _matches_upn =
_teams_fc
| where isnotempty(VictimUPN)
| join hint.strategy=broadcast kind=leftouter (
_alerts_by_upn
) on $left.VictimUPN == $right.AccountUpn
| where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
| extend MatchType = "VictimUPN";
// Join path 3: Teams chat thread -> alert chat thread
let _matches_thread =
_teams_fc
| where isnotempty(ChatThreadId)
| join hint.strategy=broadcast kind=leftouter (
_alerts_by_thread
) on ChatThreadId
| where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
| extend MatchType = "ChatThreadId";
//
// add branch 4 for host events
//
// Merge all match paths and collapse multiple alert hits per Teams event into one row
union _matches_oid, _matches_upn, _matches_thread
| summarize
AlertTitles = make_set(Title, 50),
AlertIds = make_set(AlertId, 50),
MatchTypes = make_set(MatchType, 10),
FirstAlertTime = min(ATime)
by
TTime,
SenderUPN,
SenderDisplayName,
VictimUPN,
VictimAccountObjectId,
ChatThreadId
Protecting your organization from collaboration‑based impersonation attacks as demonstrated throughout this intrusion chain, cross‑tenant helpdesk impersonation campaigns rely less on platform exploitation and more on persuading users to initiate trusted remote access workflows within legitimate enterprise collaboration tools such as Microsoft Teams.
Organizations should treat any unsolicited external support contact as inherently suspicious and implement layered defenses that limit credential‑backed remote sessions, enforce Conditional Access with MFA and compliant device requirements, and restrict the use of administrative protocols such as WinRM to authorized management workstations. At the endpoint and identity layers, enabling Attack Surface Reduction (ASR) rules, Zero‑hour Auto Purge (ZAP), Safe Links for Teams messages, and network protection can reduce opportunities for sideloaded execution and outbound command‑and‑control activity that blend into routine HTTPS traffic.
Finally, organizations should reinforce user education—such as establishing internal helpdesk authentication phrases and training employees to verify external tenant indicators—to prevent adversaries from converting legitimate collaboration workflows into attacker‑guided remote access and staged data exfiltration pathways. As attackers adapt their impersonation tactics, Microsoft Defender Experts continues to strengthen protections across Teams, identity, and endpoint security to help reduce risk as threats shift.
This research is provided by Microsoft Defender Security Research with contributions from Jesse Birch, Sagar Patil, Balaji Venkatesh S (DEX), Eric Hopper, Charu Puhazholi, and other members of Microsoft Threat Intelligence.
Learn More
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
In identity-based attack campaigns, any initial access activity can turn an already serious intrusion into a critical incident once it allows a threat actor to obtain domain-administration rights. At that point, the attacker effectively controls the Active Directory domain: they can change group memberships and Access Control Lists (ACLs), mint Kerberos tickets, replicate directory secrets, and push policy through mechanisms like Group Policy Objects (GPOs), among others.
What makes domain compromise especially challenging is how quickly it could happen: in many real-world cases, domain-level credentials are compromised immediately following the very first access, and once these credentials are exposed, they’re often abused immediately, well before defenders can fully scope what happened. Apart from this speed gap, responding to this type of compromise could also prove difficult. For one, incident responders can’t just simply “turn off” domain controllers, service accounts, or identity infrastructure and core services without risking business continuity. In addition, because compromised credential artifacts can spread fast and be replayed to expand access, restoring the identity infrastructure back to a trusted state usually means taking steps (for example, krbtgt rotation, GPO cleanup, and ACL validation) that could take additional time and effort in an already high-pressure situation.
These challenges highlight the need for a more proactive approach in disrupting and containing credential-based attacks as they happen. Microsoft Defender’s predictive shielding capability in automatic attack disruption helps address this need. Its ability to predict where attacks will pivot next and apply just in time hardening actions to block credential abuse—including those targeting high-privilege accounts like domain admins—and lateral movement at near-real-time speed, shifting the advantageto the defenders.
Previously, we discussed how predictive shielding was able to disrupt a human-operated ransomware incident. In this blog post, we take a look at a real-world Active Directory domain compromise that illustrates the critical inflection point when a threat actor achieves domain -level control. We walk through the technical details of the incident to highlight attacker tradecraft, the operational challenges defenders face after domain compromise, and the value of proactive, exposure-based containment that predictive shielding provides.
Predictive shielding overview
Predictive shielding is a capability in Microsoft Defender’s automatic attack disruption that helps stop the spread of identity-based attacks, before an attacker fully operationalizes stolen credentials. Instead of waiting for an account to be observed doing something malicious, predictive shielding focuses on moments when credentials are likely exposed: when Defender sees high-confidence signals of credential theft activity on a device, it can proactively restrict the accounts that might have been exposed there.
Essentially, predictive shielding works as follows:
Defender detects post-breach activity strongly associated with credential exposure on a device.
It evaluates which high-privilege identities were likely exposed in that context.
It applies containment to those identities to reduce the attacker’s ability to pivot, limiting lateral movement paths and high-impact identity operations while the incident is being investigated and remediated. The intent is to close the “speed gap” where attackers can reuse newly exposed credentials faster than responders can scope, reset, and clean up.
This capability is available as an out-of-the-box enhancement for Microsoft Defender for Endpoint P2 customers who meet the Microsoft Defender prerequisites.
The following section revisits a real-world domain compromise that showcases how attack disruption and predictive shielding changed the outcome by acting on exposure, rather than just observed abuse. Interestingly, this case happened just as we’re rolling out the predictive shielding, so you can see the changes in both attacker tradecraft and the detection and response actions before and after this capability was deployed.
Attack chain overview
In June 2025, a public sector organization was targeted by a threat actor. This threat actor progressed methodically: initial exploitation, local escalation, directory reconnaissance, credential access, and expansion into Microsoft Exchange and identity infrastructure.
Figure 1. Attack diagram of the domain compromise.
Initial entry: Pre-domain compromise
The campaign began at the edge: a file-upload flaw in an internet-facing Internet Information Services (IIS) server was abused to plant and launch a web shell. The attacker then simultaneously performed various reconnaissance activities using the compromised account through the web shell and escalated their privileges to NT AUTHORITY\SYSTEM by abusing a Potato-class token impersonation primitive (for example, BadPotato).
The discovery commands observed in the attack include the following example:
Using the compromised IIS service account, the attacker attempted to reset the passwords of high-impact identities, a common technique used to gain control over accounts without performing credential dumping. The attacker also deployed Mimikatz to dump logon secrets (for example, MSV, LSASS, and SAM), harvesting credentials that are exposed on the device.
Had predictive shielding been released at this point, automated restrictions on exposed accounts could have stopped the intrusion before it expanded beyond the single-host foothold. However, at the time of the incident, this capability hasn’t been deployed to customers yet.
Key takeaway: At this stage of an attack, it’s important to keep the containment host‑scoped. Defenders should prioritize blocking credential theft and stopping escalation before it reaches the identity infrastructure.
First pivot: Directory credential materialization and Exchange delegation
Within 24 hours, the attacker abused privileged accounts and remotely created a scheduled task on a domain controller. The task initiated NTDS snapshot activity and packaged the output using makecab.exe, enabling offline access to directory credential material that’s suitable for abusing credentials at scale:
Because the first malicious action by the abused account already surfaced the entire Active Directory credentials, stopping its path for total domain compromise was no longer feasible.
The threat actor then planted a Godzilla web shell on Exchange Server, used a privileged context to enumerate accounts with ApplicationImpersonation role assignments, and granted full access to a delegated principal across mailboxes using Add‑MailboxPermission. This access allowed the threat actor to read and manipulate all mailbox contents.
The attack also used Impacket’s atexec.py to enumerate the role assignments remotely. Its use triggered the attack disruption capability in Defender, revoking the account sessions of an admin account and blocking it from further use.
Following the abused account’s disruption, the attacker attempted several additional actions, such as resetting the disrupted account’s and other accounts’ passwords. They also attempted to dump credentials of a Veeam backup device.
Key takeaway: This pivot is a turning point. Once directory credentials and privileged delegation are in play, the scope and impact of an incident expand fast. Defenders should prioritize protecting domain controllers, privileged identities, and authentication paths.
Scale and speed: Tool return, spraying, and lateral movement
Weeks later, the threat actor returned with an Impacket tooling (for example, secretsdump and PsExec) that resulted in repeated disruptions by Defender against the abused accounts that they used. These disruptions forced the attacker to pivot to other compromised accounts and exhaust their resources.
Following Defender’s disruptions, the threat actor then launched a broad password spray from the initially compromised IIS server, unlocking access to at least 14 servers through password reuse. They also attempted remote credential dumping against a couple of domain controllers and an additional IIS server using multiple domain and service principals.
Key takeaway: Even though automatic attack disruption acted right away, the attacker already possessed multiple credentials due to the previous large-scale credential dumping. This scenario showcases the race to detect and disrupt credential abuse and is the reason we’re introducing predictive shielding to preemptively disrupt exposed accounts at risk.
Predictive shielding breaks the chain: Exposure-centric containment
In the second phase of the attack, we activated predictive shielding. When exposure signals surfaced (for example, credential dumping attempts and replay from compromised hosts), automated containment blocked new sign-in attempts and interactive pivots not only for the abused accounts, but also for context-linked identities that are active on the same compromised surfaces.
Attack disruption contained high-privileged principals to prevent these accounts from being abused. Crucially, when a high-tier Enterprise or Schema Admin credential was exposed, predictive shielding contained it pre-abuse, preventing what would normally become a catastrophic escalation.
Second pivot: Alternative paths to new credentials
With high-value identities pre-contained, the threat actor pivoted to exploiting Apache Tomcat servers. They compromised three Tomcat servers, dropped the Godzilla web shell, and launched the PowerShell-based Invoke-Mimikatz command to harvest additional credentials. At one point, the attacker operated under Schema Admin:
They then used Impacket WmiExec to access Microsoft Entra Connect servers and attempt to extract Entra Connect synchronization credentials. The account used for this pivot was later contained, limiting further lateral movement.
Last attempts and shutdown
In the final phase of the attack, the threat actor attempted a full LSASS dump on a file sharing server using comsvcs.dll MiniDump under a domain user account, followed by additional NTDS activity:
Attack disruption in Defender repeatedly severed sessions and blocked new sign-ins made by the threat actor. On July 28, 2025, the attack campaign lost momentum and stopped.
How predictive shielding changed the outcome
Before compromising a domain, attackers are mostly constrained by the hosts they control. However, even a small set of exposed credentials could remove their constraints and give them broad access through privileged authentication and delegated pathways. The blast radius spreads fast, time pressure spikes, and containment decisions become riskier because identity infrastructure and high-privilege accounts are production dependencies.
The incident we revisited earlier almost followed a similar pattern. It unfolded while predictive shielding was still being launched, so the automated predictive containment capability only became active at the midway of the attack campaign. During the attack’s first stages, the threat actor had room to scale—they returned with new tooling, launched a broad password spray attack, and expanded access across multiple servers. They also attempted remote credential dumping against domain controllers and servers.
When predictive shielding went live, it helped shift the story and we then saw the change of pace—instead of reacting to each newly abused account, the capability allowed Defender to act preemptively and turn credential theft attempts into blocked pivots. Defender was able to block new sign-ins and interactive pivots, not just for the single abused account, but also for context-linked identities that were active on the same compromised surfaces.
With high-value identities pre-contained, the adversary shifted tradecraft and chased other credential sources, but each of their subsequent attempts triggered targeted containment that limited their lateral reach until they lost momentum and stopped. How this incident concluded is the operational “tell” that containment is working, in that once privileged pivots get blocked, threat actors often hunt for alternate credential sources, and defenses must continue following the moving blast radius.
As predictive shielding matures, it will continue to expand its prediction logic and context-linked identities.
MITRE ATT&CK® techniques observed
The following table maps observed behaviors to ATT&CK®.
Tactics shown are per technique definition.
Tactic(s)
Technique ID
Technique name
Observed details
Initial Access
T1190
Exploit Public-Facing Application
Exploited a file-upload vulnerability in an IIS server to drop a web shell.
Persistence
T1505.003
Server Software Component: Web Shell
Deployed web shells for persistent access.
Execution
T1059.001
Command and Scripting Interpreter: PowerShell
Used PowerShell for Exchange role queries, mailbox permission changes, and Invoke-Mimikatz.
Privilege Escalation
T1068
Exploitation for Privilege Escalation
Used BadPotato to escalate to SYSTEM on an IIS server.
Credential Access
T1003.001
OS Credential Dumping: LSASS Memory
Dumped LSASS using Mimikatz and comsvcs.dll MiniDump.
Credential Access
T1003.003
OS Credential Dumping: NTDS
Performed NTDS-related activity using ntdsutil snapshot/IFM workflows on a domain controller.
Execution; Persistence; Privilege Escalation
T1053.005
Scheduled Task/Job: Scheduled Task
Created remote scheduled tasks to execute under SYSTEM on a domain controller.
Discovery
T1087.002
Account Discovery: Domain Account
Enumerated domain groups and accounts using net group and AD Explorer.
Lateral Movement
T1021.002
Remote Services: SMB/Windows Admin Shares
Used admin shares/SMB-backed tooling (for example, PsExec) for lateral movement.
Lateral Movement
T1021.003
Remote Services: Windows Remote Management
Used WmiExec against Microsoft Entra Connect servers.
Credential Access
T1110.003
Brute Force: Password Spraying
Performed password spraying leading to access across at least 14 servers.
Collection
T1114.002
Email Collection: Remote Email Collection
Expanded mailbox access broadly through impersonation or permission changes.
Command and Control
T1071.001
Application Layer Protocol: Web Protocols
Web shells communicated over HTTP/S.
Defense Evasion
T1070.004
Indicator Removal on Host: File Deletion
Used cleanup scripts (for example, del.bat) to remove dump artifacts.
Persistence; Privilege Escalation
T1098
Account Manipulation
Manipulated permissions and roles to expand access and sustain control.
Credential Access
T1078
Valid Accounts
Reused compromised service and domain accounts for access and lateral movement.
Learn more
For more information about automatic attack disruption and predictive shielding, see the following Microsoft Learn articles:
Check out our latest Ninja show showcasing how predictive shielding expands to identity centric attacks
Microsoft Threat Intelligence uncovered a macOS‑focused cyber campaign by the North Korean threat actor Sapphire Sleet that relies on social engineering rather than software vulnerabilities. By impersonating a legitimate software update, threat actors tricked users into manually running malicious files, allowing them to steal passwords, cryptocurrency assets, and personal data while avoiding built‑in macOS security checks. This activity highlights how convincing user prompts and trusted system tools can be abused, and why awareness and layered security defenses remain critical.
Microsoft Threat Intelligence identified a campaign by North Korean state actor Sapphire Sleet demonstrating new combinations of macOS-focused execution patterns and techniques, enabling the threat actor to compromise systems through social engineering rather than software exploitation. In this campaign, Sapphire Sleet takes advantage of user‑initiated execution to establish persistence, harvest credentials, and exfiltrate sensitive data while operating outside traditional macOS security enforcement boundaries. While the techniques themselves are not novel, this analysis highlights execution patterns and combinations that Microsoft has not previously observed for this threat actor, including how Sapphire Sleet orchestrates these techniques together and uses AppleScript as a dedicated, late‑stage credential‑harvesting component integrated with decoy update workflows.
After discovering the threat, Microsoft shared details of this activity with Apple as part of our responsible disclosure process. Apple has since implemented updates to help detect and block infrastructure and malware associated with this campaign. We thank the Apple security team for their collaboration in addressing this activity and encourage macOS users to keep their devices up to date with the latest security protections.
This activity demonstrates how threat actors continue to rely on user interaction and trusted system utilities to bypass macOS platform security protections, rather than exploiting traditional software vulnerabilities. By persuading users to manually execute AppleScript or Terminal‑based commands, Sapphire Sleet shifts execution into a user‑initiated context, allowing the activity to proceed outside of macOS protections such as Transparency, Consent, and Control (TCC), Gatekeeper, quarantine enforcement, and notarization checks. Sapphire Sleet achieves a highly reliable infection chain that lowers operational friction and increases the likelihood of successful compromise—posing an elevated risk to organizations and individuals involved in cryptocurrency, digital assets, finance, and similar high‑value targets that Sapphire Sleet is known to target.
In this blog, we examine the macOS‑specific attack chain observed in recent Sapphire Sleet intrusions, from initial access using malicious .scpt files through multi-stage payload delivery, credential harvesting using fake system dialogs, manipulation of the macOS TCC database, persistence using launch daemons, and large-scale data exfiltration. We also provide actionable guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help defenders identify similar threats and strengthen macOS security posture.
Sapphire Sleet’s campaign lifecycle
Initial access and social engineering
Sapphire Sleet is a North Korean state actor active since at least March 2020 that primarily targets the finance sector, including cryptocurrency, venture capital, and blockchain organizations. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.
Recent campaigns demonstrate expanded execution mechanisms across operating systems like macOS, enabling Sapphire Sleet to target a broader set of users through parallel social engineering workflows.
Sapphire Sleet operates a well‑documented social engineering playbook in which the threat actor creates fake recruiter profiles on social media and professional networking platforms, engages targets in conversations about job opportunities, schedules a technical interview, and directs targets to install malicious software, which is typically disguised as a video conferencing tool or software developer kit (SDK) update.
In this observed activity, the target was directed to download a file called Zoom SDK Update.scpt—a compiled AppleScript that opens in macOS Script Editor by default. Script Editor is a trusted first-party Apple application capable of executing arbitrary shell commands using the do shell script AppleScript command.
Lure file and Script Editor execution
Figure 1. Initial access: The .scpt lure file as seen in macOS Script Editor
The malicious Zoom SDK Update.scpt file is crafted to appear as a legitimate Zoom SDK update when opened in the macOS Script Editor app, beginning with a large decoy comment block that mimics benign upgrade instructions and gives the impression of a routine software update. To conceal its true behavior, the script inserts thousands of blank lines immediately after this visible content, pushing the malicious logic far below the scrollable view of the Script Editor window and reducing the likelihood that a user will notice it.
Hidden beneath this decoy, the script first launches a harmless looking command that invokes the legitimate macOS softwareupdate binary with an invalid parameter, an action that performs no real update but launches a trusted Apple‑signed process to reinforce the appearance of legitimacy. Following this, the script executes its malicious payload by using curl to retrieve threat actor‑controlled content and immediately passes the returned data to osascript for execution using the run script result instruction. Because the content fetched by curl is itself a new AppleScript, it is launched directly within the Script Editor context, initiating a payload delivery in which additional stages are dynamically downloaded and executed.
Figure 2. The AppleScript lure with decoy content and payload execution
Execution and payload delivery
Cascading curl-to-osascript execution
When the user opens the Zoom SDK Update.scpt file, macOS launches the file in Script Editor, allowing Sapphire Sleet to transition from a single lure file to a multi-stage, dynamically fetched payload chain. From this single process, the entire attack unfolds through a cascading chain of curl commands, each fetching and executing progressively more complex AppleScript payloads. Each stage uses a distinct user-agent string as a campaign tracking identifier.
Figure 3. Process tree showing cascading execution from Script Editor
The main payload fetched by the mac-cur1 user agent is the attack orchestrator. Once executed within the Script Editor, it performs immediate reconnaissance, then kicks off parallel operations using additional curl commands with different user-agent strings.
Note the URL path difference: mac-cur1 through mac-cur3 fetch from /version/ (AppleScript payloads piped directly to osascript for execution), while mac-cur4 and mac-cur5 fetch from /status/ (ZIP archives containing compiled macOS .app bundles).
The following table summarizes the curl chain used in this campaign.
User agent
URL path
Purpose
mac-cur1
/fix/mac/update/version/
Main orchestrator (piped to osascript) beacon. Downloads com.apple.cli host monitoringcomponent and services backdoor
mac-cur2
/fix/mac/update/version/
Invokes curl with mac-cur4 which downloads credential harvester systemupdate.app
mac-cur3
/fix/mac/update/version/
TCC bypass + data collection + exfiltration (wallets, browser, keychains, history, Apple Notes, Telegram)
Figure 4. The curl chain showing user-agent strings and payload routing
Reconnaissance and C2 registration
After execution, the malware next identifies and registers the compromised device with Sapphire Sleet infrastructure. The malware starts by collecting basic system details such as the current user, host name, system time, and operating system install date. This information is used to uniquely identify the compromised device and track subsequent activity.
The malware then registers the compromised system with its command‑and‑control (C2) infrastructure. The mid value represents the device’s universally unique identifier (UUID), the did serves as a campaign‑level tracking identifier, and the user field combines the system host name with the device serial number to uniquely label the targeted user.
Figure 5. C2 registration with device UUID and campaign identifier
Host monitoring component: com.apple.cli
The first binary deployed is a host monitoring component called com.apple.cli—a ~5 MB Mach-O binary disguised with an Apple-style naming convention.
The mac-cur1 payload spawns an osascript that downloads and launches com.apple.cli:
Figure 6. com.apple.cli deployment using osascript
The host monitoring component repeatedly executes a series of system commands to collect environment and runtime information, including the macOS version (sw_vers), the current system time (date -u), and the underlying hardware model (sysctl hw.model). It then runs ps aux in a tight loop to capture a full, real‑time list of running processes.
During execution, com.apple.cli performs host reconnaissance while maintaining repeated outbound connectivity to the threat actor‑controlled C2 endpoint 83.136.208[.]246:6783. The observed sequencing of reconnaissance activity and network communication is consistent with staging for later operational activity, including privilege escalation, and exfiltration.
In parallel with deploying com.apple.cli, the mac-cur1 orchestrator also deploys a second component, the services backdoor, as part of the same execution flow; its role in persistence and follow‑on activity is described later in this blog.
Credential access
Credential harvester: systemupdate.app
After performing reconnaissance, the mac-cur1 orchestrator begins parallel operations. During the mac‑cur2 stage of execution (independent from the mac-cur1 stage), Sapphire Sleet delivers an AppleScript payload that is executed through osascript. This stage is responsible for deploying the credential harvesting component of the attack.
Before proceeding, the script checks for the presence of a file named .zoom.log on the system. This file acts as an infection marker, allowing Sapphire Sleet to determine whether the device has already been compromised. If the marker exists, deployment is skipped to avoid redundant execution across sessions.
If the infection marker is not found, the script downloads a compressed archive through the mac-cur4 user agent that contains a malicious macOS application named (systemupdate.app), which masquerades as the legitimate system update utility by the same name. The archive is extracted to a temporary location, and the application is launched immediately.
When systemupdate.app launches, the user is presented with a native macOS password dialog that is visually indistinguishable from a legitimate system prompt. The dialog claims that the user’s password is required to complete a software update, prompting the user to enter their credentials.
After the user enters their password, the malware performs two sequential actions to ensure the credential is usable and immediately captured. First, the binary validates the entered password against the local macOS authentication database using directory services, confirming that the credential is correct and not mistyped. Once validation succeeds, the verified password is immediately exfiltrated to threat actor‑controlled infrastructure using the Telegram Bot API, delivering the stolen credential directly to Sapphire Sleet.
Figure 7. Password popup given by fake systemupdate.app
Decoy completion prompt: softwareupdate.app
After credential harvesting is completed using systemupdate.app, Sapphire Sleet deploys a second malicious application named softwareupdate.app, whose sole purpose is to reinforce the illusion of a legitimate update workflow. This application is delivered during a later stage of the attack using the mac‑cur5 user‑agent. Unlike systemupdate.app, softwareupdate.app does not attempt to collect credentials. Instead, it displays a convincing “system update complete” dialog to the user, signaling that the supposed Zoom SDK update has finished successfully. This final step closes the social engineering loop: the user initiated a Zoom‑themed update, was prompted to enter their password, and is now reassured that the process completed as expected, reducing the likelihood of suspicion or further investigation.
Persistence
Primary backdoor and persistence installer: services binary
The services backdoor is a key operational component in this attack, acting as the primary backdoor and persistence installer. It provides an interactive command execution channel, establishes persistence using a launch daemon, and deploys two additional backdoors. The services backdoor is deployed through a dedicated AppleScript executed as part of the initial mac‑cur1 payload that also deployed com.apple.cli, although the additional backdoors deployed by services are executed at a later stage.
During deployment, the services backdoor binary is first downloaded using a hidden file name (.services) to reduce visibility, then copied to its final location before the temporary file is removed. As part of installation, the malware creates a file named auth.db under ~/Library/Application Support/Authorization/, which stores the path to the deployed services backdoor and serves as a persistent installation marker. Any execution or runtime errors encountered during this process are written to /tmp/lg4err, leaving behind an additional forensic artifact that can aid post‑compromise investigation.
Figure 8. Services backdoor deployment using osascript
Unlike com.apple.cli, the services backdoor uses interactive zsh shells (/bin/zsh -i) to execute privileged operations. The -i flag creates an interactive terminal context, which is required for sudo commands that expect interactive input.
Figure 9. Interactive zsh shell execution by the services backdoor
Additional backdoors: icloudz and com.google.chromes.updaters
Of the additional backdoors deployed by services, the icloudz backdoor is a renamed copy of the previously deployed services backdoor and shares the same SHA‑256 hash, indicating identical underlying code. Despite this, it is executed using a different and more evasive technique. Although icloudz shares the same binary as .services, it operates as a reflective code loader—it uses the macOS NSCreateObjectFileImageFromMemory API to load additional payloads received from its C2 infrastructure directly into memory, rather than writing them to disk and executing them conventionally.
The icloudz backdoor is stored at ~/Library/Application Support/iCloud/icloudz, a location and naming choice intended to resemble legitimate iCloud‑related artifacts. Once loaded into memory, two distinct execution waves are observed. Each wave independently initializes a consistent sequence of system commands: existing caffeinate processes are stopped, caffeinate is relaunched using nohup to prevent the system from sleeping, basic system information is collected using sw_vers and sysctl -n hw.model, and an interactive /bin/zsh -i shell is spawned. This repeated initialization suggests that the component is designed to re‑establish execution context reliably across runs.
From within the interactive zsh shell, icloudz deploys an additional (tertiary) backdoor, com.google.chromes.updaters, to disk at ~/Library/Google/com.google.chromes.updaters. The selected directory and file name closely resemble legitimate Google application data, helping the file blend into the user’s Home directory and reducing the likelihood of casual inspection. File permissions are adjusted; ownership is set to allow execution with elevated privileges, and the com.google.chromes.updaters binary is launched using sudo.
To ensure continued execution across reboots, a launch daemon configuration file named com.google.webkit.service.plist is installed under /Library/LaunchDaemons. This configuration causes icloudz to launch automatically at system startup, even if no user is signed in. The naming convention deliberately mimics legitimate Apple and Google system services, further reducing the chance of detection.
The com.google.chromes.updaters backdoor is the final and largest component deployed in this attack chain, with a size of approximately 7.2 MB. Once running, it establishes outbound communication with threat actor‑controlled infrastructure, connecting to the domain check02id[.]com over port 5202. The process then enters a precise 60‑second beaconing loop. During each cycle, it executes minimal commands such as whoami to confirm the execution context and sw_vers -productVersion to report the operating system version. This lightweight heartbeat confirms the process remains active, is running with elevated privileges, and is ready to receive further instructions.
Privilege escalation
TCC bypass: Granting AppleEvents permissions
Before large‑scale data access and exfiltration can proceed, Sapphire Sleet must bypass macOS TCC protections. TCC enforces user consent for sensitive inter‑process interactions, including AppleEvents, the mechanism required for osascript to communicate with Finder and perform file-level operations. The mac-cur3 stage silently grants itself these permissions by directly manipulating the user-level TCC database through the following sequence.
The user-level TCC database (~/Library/Application Support/com.apple.TCC/TCC.db) is itself TCC-protected—processes without Full Disk Access (FDA) cannot read or modify it. Sapphire Sleet circumvents this by directing Finder, which holds FDA by default on macOS, to rename the com.apple.TCC folder. Once renamed, the TCC database file can be copied to a staging location by a process without FDA.
Sapphire Sleet then uses sqlite3 to inject a new entry into the database’s access table. This entry grants /usr/bin/osascript permission to send AppleEvents to com.apple.finder and includes valid code-signing requirement (csreq) blobs for both binaries, binding the grant to Apple-signed executables. The authorization value is set to allowed (auth_value=2) with a user-set reason (auth_reason=3), ensuring no user prompt is triggered. The modified database is then copied back into the renamed folder, and Finder restores the folder to its original name. Staging files are deleted to reduce forensic traces.
Figure 10. Overwriting original TCC database with modified version
Collection and exfiltration
With TCC bypassed, credentials stolen, and backdoors deployed, Sapphire Sleet launches the next phase of attack: a 575-line AppleScript payload that systematically collects, stages, compresses, and exfiltrates seven categories of data.
Exfiltration architecture
Every upload follows a consistent pattern and is executed using nohup, which allows the command to continue running in the background even if the initiating process or Terminal session exits. This ensures that data exfiltration can complete reliably without requiring the threat actor to maintain an active session on the system.
The auth header provides the upload authorization token, and the mid header ties the upload to the compromised device’s UUID.
Figure 11. Exfiltration upload pattern with nohup
Data collected during exfiltration
Host and system reconnaissance: Before bulk data collection begins, the script records basic system identity and hardware information. This includes the current username, system host name, macOS version, and CPU model. These values are appended to a per‑host log file and provide Sapphire Sleet with environmental context, hardware fingerprinting, and confirmation of the target system’s characteristics. This reconnaissance data is later uploaded to track progress and correlate subsequent exfiltration stages to a specific device.
Installed applications and runtime verification: The script enumerates installed applications and shared directories to build an inventory of the system’s software environment. It also captures a live process listing filtered for threat actor‑deployed components, allowing Sapphire Sleet to verify that earlier payloads are still running as expected. These checks help confirm successful execution and persistence before proceeding further.
Messaging session data (Telegram): Telegram Desktop session data is collected by copying the application’s data directories, including cryptographic key material and session mapping files. These artifacts are sufficient to recreate the user’s Telegram session on another system without requiring reauthentication. A second collection pass targets the Telegram App Group container to capture the complete local data set associated with the application.
Browser data and extension storage: For Chromium‑based browsers, including Chrome, Brave, and Arc, the script copies browser profiles and associated databases. This includes saved credentials, cookies, autofill data, browsing history, bookmarks, and extension‑specific storage. Particular focus is placed on IndexedDB entries associated with cryptocurrency wallet extensions, where wallet keys and transaction data are stored. Only IndexedDB entries matching a targeted set of wallet extension identifiers are collected, reflecting a deliberate and selective approach.
macOS keychain: The user’s sign-in keychain database is bundled alongside browser data. Although the keychain is encrypted, Sapphire Sleet has already captured the user’s password earlier in the attack chain, enabling offline decryption of stored secrets once exfiltrated.
Cryptocurrency desktop wallets: The script copies the full application support directories for popular cryptocurrency desktop wallets, including Ledger Live and Exodus. These directories contain wallet configuration files and key material required to access stored cryptocurrency assets, making them high‑value targets for exfiltration.
SSH keys and shell history: SSH key directories and shell history files are collected to enable potential lateral movement and intelligence gathering. SSH keys may provide access to additional systems, while shell history can reveal infrastructure details, previously accessed hosts, and operational habits of the targeted user.
Apple Notes: The Apple Notes database is copied from its application container and staged for upload. Notes frequently contain sensitive information such as passwords, internal documentation, infrastructure details, or meeting notes, making them a valuable secondary data source.
System logs and failed access attempts: System log files are uploaded directly without compression. These logs provide additional hardware and execution context and include progress markers that indicate which exfiltration stages have completed. Failed collection attempts—such as access to password manager containers that are not present on the system—are also recorded and uploaded, allowing Sapphire Sleet to understand which targets were unavailable on the compromised host.
Exfiltration summary
#
Data category
ZIP name
Upload port
Estimated sensitivity
1
Telegram session
tapp_<user>.zip
8443
Critical — session hijack
2
Browser data + Keychain
ext_<user>.zip
8443
Critical — all passwords
3
Ledger wallet
ldg_<user>.zip
8443
Critical — crypto keys
4
Exodus wallet
exds_<user>.zip
8443
Critical — crypto keys
5
SSH + shell history
hs_<user>.zip
8443
High — lateral movement
6
Apple Notes
nt_<user>.zip
8443
Medium-High
7
System log
lg_<user> (no zip)
8443
Low — fingerprinting
8
Recon log
flog (no zip)
8443
Low — inventory
9
Credentials
Telegram message
443 (Telegram API)
Critical — sign-in password
All uploads use the upload authorization token fwyan48umt1vimwqcqvhdd9u72a7qysi and the machine identifier 82cf5d92-87b5-4144-9a4e-6b58b714d599.
Defending against Sapphire Sleet intrusion activity
As part of a coordinated response to this activity, Apple has implemented platform-level protections to help detect and block infrastructure and malware associated with this campaign. Apple has deployed Apple Safe Browsing protections in Safari to detect and block malicious infrastructure associated with this campaign. Users browsing with Safari benefit from these protections by default. Apple has also deployed XProtect signatures to detect and block the malware families associated with this campaign—macOS devices receive these signature updates automatically.
Microsoft recommends the following mitigation steps to defend against this activity and reduce the impact of this threat:
Educate users about social engineering threats originating from social media and external platforms, particularly unsolicited outreach requesting software downloads, virtual meeting tool installations, or execution of terminal commands. Users should never run scripts or commands shared through messages, calls, or chats without prior approval from their IT or security teams.
Block or restrict the execution of .scpt (compiled AppleScript) files and unsigned Mach-O binaries downloaded from the internet. Where feasible, enforce policies that prevent osascript from executing scripts sourced from external locations.
Always inspect and verify files downloaded from external sources, including compiled AppleScript (.scpt) files. These files can execute arbitrary shell commands via macOS Script Editor—a trusted first-party Apple application—making them an effective and stealthy initial access vector.
Limit or audit the use of curl piped to interpreters (such as curl | osascript, curl | sh, curl | bash). Social engineering campaigns by Sapphire Sleet rely on cascading curl-to-interpreter chains to avoid writing payloads to disk. Organizations should monitor for and restrict piped execution patterns originating from non-standard user-agent strings.
Exercise caution when copying and pasting sensitive data such as wallet addresses or credentials from the clipboard. Always verify that the pasted content matches the intended source to avoid falling victim to clipboard hijacking or data tampering attacks.
Monitor for unauthorized modifications to the macOS TCC database. This campaign manipulates TCC.db to grant AppleEvents permissions to osascript without user consent—a prerequisite for the large-scale data exfiltration phase. Look for processes copying, modifying, or overwriting ~/Library/Application Support/com.apple.TCC/TCC.db.
Audit LaunchDaemon and LaunchAgent installations. This campaign installs a persistent launch daemon (com.google.webkit.service.plist) that masquerades as a legitimate Google or Apple service. Monitor /Library/LaunchDaemons/ and ~/Library/LaunchAgents/ for unexpected plist files, particularly those with com.google.* or com.apple.* naming conventions not belonging to genuine vendor software.
Protect cryptocurrency wallets and browser credential stores. This campaign targets nine specific crypto wallet extensions (Sui, Phantom, TronLink, Coinbase, OKX, Solflare, Rabby, Backpack) plus Bitwarden, and exfiltrates browser sign-in data, cookies, and keychain databases. Organizations handling digital assets should enforce hardware wallet policies and rotate browser-stored credentials regularly.
Encourage users to use web browsers that support Microsoft Defender SmartScreen like Microsoft Edge—available on macOS and various platforms—which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
Microsoft Defender for Endpoint customers can also apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:
Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
Turn on network protection to block connections to malicious domains and IP addresses.
Microsoft Defender detection and hunting guidance
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Microsoft Defender for Endpoint – Enumeration of files with sensitive data – Suspicious File Copy Operations Using CoreUtil – Suspicious archive creation – Remote exfiltration activity – Possible exfiltration of archived data
Command and control
– Mach-O backdoors beaconing to C2 (com.apple.cli, services, com.google.chromes.updaters)
Microsoft Defender Antivirus – Trojan:MacOS/NukeSped.D – Backdoor:MacOS/FlowOffset.B!dha – Backdoor:MacOS/FlowOffset.C!dha
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Hunting queries
Microsoft Defender XDR
Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:
Suspicious osascript execution with curl piping
Search for curl commands piping output directly to osascript, a core technique in this Sapphire Sleet campaign’s cascading payload delivery chain.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName == "osascript" or InitiatingProcessFileName == "osascript"
| where ProcessCommandLine has "curl" and ProcessCommandLine has_any ("osascript", "| sh", "| bash")
| project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName
Suspicious curl activity with campaign user-agent strings
Search for curl commands using user-agent strings matching the Sapphire Sleet campaign tracking identifiers (mac-cur1 through mac-cur5, audio, beacon).
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName == "curl" or ProcessCommandLine has "curl"
| where ProcessCommandLine has_any ("mac-cur1", "mac-cur2", "mac-cur3", "mac-cur4", "mac-cur5", "-A audio", "-A beacon")
| project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
Detect connectivity with known C2 infrastructure
Search for network connections to the Sapphire Sleet C2 domains and IP addresses used in this campaign.
let c2_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
let c2_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (c2_domains) or RemoteIP in (c2_ips)
| project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine
TCC database manipulation detection
Search for processes that copy, modify, or overwrite the macOS TCC database, a key defense evasion technique used by this campaign to grant unauthorized AppleEvents permissions.
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath has "com.apple.TCC" and FileName == "TCC.db"
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
Suspicious LaunchDaemon creation masquerading as legitimate services
Search for LaunchDaemon plist files created in /Library/LaunchDaemons that masquerade as Google or Apple services, matching the persistence technique used by the services/icloudz backdoor.
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath startswith "/Library/LaunchDaemons/"
| where FileName startswith "com.google." or FileName startswith "com.apple."
| where ActionType == "FileCreated"
| project Timestamp, DeviceId, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
Malicious binary execution from suspicious paths
Search for execution of binaries from paths commonly used by Sapphire Sleet, including hidden Library directories, /private/tmp/, and user-specific Application Support folders.
Credential harvesting using dscl authentication check
Search for dscl -authonly commands used by the fake password dialog (systemupdate.app) to validate stolen credentials before exfiltration.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName == "dscl" or ProcessCommandLine has "dscl"
| where ProcessCommandLine has "-authonly"
| project Timestamp, DeviceId, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
Telegram Bot API exfiltration detection
Search for network connections to Telegram Bot API endpoints, used by this campaign to exfiltrate stolen credentials.
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has "api.telegram.org" and RemoteUrl has "/bot"
| project Timestamp, DeviceId, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine
Reflective code loading using NSCreateObjectFileImageFromMemory
Search for evidence of reflective Mach-O loading, the technique used by the icloudz backdoor to execute code in memory.
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType has "NSCreateObjectFileImageFromMemory"
or AdditionalFields has "NSCreateObjectFileImageFromMemory"
| project Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName, AdditionalFields
Suspicious caffeinate and sleep prevention activity
Search for caffeinate process stop-and-restart patterns used by the services and icloudz backdoors to prevent the system from sleeping during backdoor operations.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessCommandLine has "caffeinate"
| where InitiatingProcessCommandLine has_any ("icloudz", "services", "chromes.updaters", "zsh -i")
| project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
Detect known malicious file hashes
Search for the specific malicious file hashes associated with this Sapphire Sleet campaign across file events.
let malicious_hashes = dynamic([
"2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
"05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
"5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
"5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
"95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
"8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
"a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
]);
DeviceFileEvents
| where Timestamp > ago(30d)
| where SHA256 in (malicious_hashes)
| project Timestamp, DeviceId, DeviceName, FileName, FolderPath, SHA256, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine
Data staging and exfiltration activity
Search for ZIP archive creation in /tmp/ directories followed by curl uploads matching the staging-and-exfiltration pattern used for browser data, crypto wallets, Telegram sessions, SSH keys, and Apple Notes.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where (ProcessCommandLine has "zip" and ProcessCommandLine has "/tmp/")
or (ProcessCommandLine has "curl" and ProcessCommandLine has_any ("tapp_", "ext_", "ldg_", "exds_", "hs_", "nt_", "lg_"))
| project Timestamp, DeviceId, DeviceName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
Search for Script Editor (the default handler for .scpt files) spawning curl, osascript, or shell commands—the initial execution vector in this campaign.
DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName == "Script Editor" or InitiatingProcessCommandLine has "Script Editor"
| where FileName has_any ("curl", "osascript", "sh", "bash", "zsh")
| project Timestamp, DeviceId, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
Microsoft Sentinel
Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.
Detect network indicators of compromise
The following query checks for connections to the Sapphire Sleet C2 domains and IP addresses across network session data:
let lookback = 30d;
let ioc_domains = dynamic(["uw04webzoom.us", "uw05webzoom.us", "uw03webzoom.us", "ur01webzoom.us", "uv01webzoom.us", "uv03webzoom.us", "uv04webzoom.us", "ux06webzoom.us", "check02id.com"]);
let ioc_ips = dynamic(["188.227.196.252", "83.136.208.246", "83.136.209.22", "83.136.208.48", "83.136.210.180", "104.145.210.107"]);
DeviceNetworkEvents
| where TimeGenerated > ago(lookback)
| where RemoteUrl has_any (ioc_domains) or RemoteIP in (ioc_ips)
| summarize EventCount=count() by DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName
Detect file hash indicators of compromise
The following query searches for the known malicious file hashes associated with this campaign across file, process, and security event data:
let selectedTimestamp = datetime(2026-01-01T00:00:00.0000000Z);
let FileSHA256 = dynamic([
"2075fd1a1362d188290910a8c55cf30c11ed5955c04af410c481410f538da419",
"05e1761b535537287e7b72d103a29c4453742725600f59a34a4831eafc0b8e53",
"5fbbca2d72840feb86b6ef8a1abb4fe2f225d84228a714391673be2719c73ac7",
"5e581f22f56883ee13358f73fabab00fcf9313a053210eb12ac18e66098346e5",
"95e893e7cdde19d7d16ff5a5074d0b369abd31c1a30962656133caa8153e8d63",
"8fd5b8db10458ace7e4ed335eb0c66527e1928ad87a3c688595804f72b205e8c",
"a05400000843fbad6b28d2b76fc201c3d415a72d88d8dc548fafd8bae073c640"
]);
search in (AlertEvidence, DeviceEvents, DeviceFileEvents, DeviceImageLoadEvents, DeviceProcessEvents, DeviceNetworkEvents, SecurityEvent, ThreatIntelligenceIndicator)
TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d))
and (SHA256 in (FileSHA256) or InitiatingProcessSHA256 in (FileSHA256))
Detect Microsoft Defender Antivirus detections related to Sapphire Sleet
The following query searches for Defender Antivirus alerts for the specific malware families used in this campaign and joins with device information for enriched context:
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Microsoft Defender has been investigating reports of malicious Chromium‑based browser extensions that impersonate legitimate AI assistant tools to harvest LLM chat histories and browsing data. Reporting indicates these extensions have reached approximately 900,000 installs. Microsoft Defender telemetry also confirms activity across more than 20,000 enterprise tenants, where users frequently interact with AI tools using sensitive inputs.
The extensions collected full URLs and AI chat content from platforms such as ChatGPT and DeepSeek, exposing organizations to potential leakage of proprietary code, internal workflows, strategic discussions, and other confidential data.
At scale, this activity turns a seemingly trusted productivity extension into a persistent data collection mechanism embedded in everyday enterprise browser usage, highlighting the growing risk browser extensions pose in corporate environments.
Attack chain overview
Attack chain illustrating how a malicious AI‑themed Chromium extension progresses from marketplace distribution to persistent collection and exfiltration of LLM chat content and browsing telemetry.
Reconnaissance
The threat actor targeted the rapidly growing ecosystem of AI-assistant browser extensions and the user behaviors surrounding them. Many knowledge workers install sidebar tools to interact with models such as ChatGPT and DeepSeek, often granting broad page-level permissions for convenience. These extensions also operate across Chromium-based browsers such as Google Chrome and Microsoft Edge using a largely uniform architecture.
We also observed cases where agentic browsers automatically downloaded these extensions without requiring explicit user approval, reflecting how convincing the names and descriptions appeared. Together, these factors created a large potential audience that frequently handles sensitive information in the browser and a platform where look-alike extensions could blend in with minimal friction.
The actors also reviewed legitimate extensions, such as AITOPIA, to emulate familiar branding, permission prompts, and interaction patterns. This allowed the malicious extensions to align with user expectations while enabling large-scale telemetry collection from browser activity.
Weaponization
The threat actor developed a Chromium-based browser extension compatible with both Google Chrome and Microsoft Edge. The extension was designed to passively observe user activity, collecting visited URLs and segments of AI-assisted chat content generated during normal browser use.
Collected data was staged locally and prepared for periodic transmission, enabling continuous visibility into user browsing behavior and interactions with AI platforms.
To reduce suspicion, the extension presented its activity as benign analytics commonly associated with productivity tools. From a defender perspective, this stage introduced a browser-resident data collection capability focused on URLs and AI chat content, along with scheduled outbound communication to external infrastructure.
Delivery
The malicious extension was distributed through the Chrome Web Store, using AI-themed branding and descriptions to resemble legitimate productivity extensions. Because Microsoft Edge supports Chrome Web Store extensions, a single listing enabled distribution across both browsers without requiring additional infrastructure.
User familiarity with installing AI sidebar tools, combined with permissive enterprise extension policies, allowed the extension to reach a broad audience. This trusted distribution channel enabled the extension to reach both personal and corporate environments through routine browser extension installation.
Exploitation
Following installation, the extension leveraged the Chromium extension permission model to begin collecting data without further user interaction. The granted permissions provided visibility into a wide range of browsing activity, including internal sites and AI chat interfaces.
A misleading consent mechanism further enabled this behavior. Although users could initially disable data collection, subsequent updates automatically re-enabled telemetry, restoring data access without clear user awareness.
By relying on user trust, ambiguous consent language, and default extension behaviors, the threat actor maintained continuous access to browser-resident data streams.
Installation
Persistence was achieved through normal browser extension behavior rather than traditional malware techniques. Once installed, the extension automatically reloaded whenever the browser started, requiring no elevated privileges or additional user actions.
Local extension storage maintained session identifiers and queued telemetry, allowing the extension to resume collection after browser restarts or service worker reloads. This approach allowed the data collection functionality to continue across browser sessions while appearing similar to a typical installed browser extension.
Command and Control (C2)
At regular intervals, the extension transmitted collected data to threat actor–controlled infrastructure using HTTPS POST requests to domains including deepaichats[.]com and chatsaigpt[.]com. By relying on common web protocols and periodic upload activity, the outbound traffic appeared similar to routine browser communications.
After transmission, local buffers were cleared, reducing on-disk artifacts and limiting local forensic visibility. This lightweight command-and-control model allowed the extension to regularly transmit browsing telemetry and AI chat content from both Chrome and Microsoft Edge environments.
Actions on Objective
The threat actor’s objective appeared to be ongoing data collection and visibility into user activity. Through the installed extension, the threat actor collected browsing telemetry and AI-related content, including prompts and responses from platforms such as ChatGPT and DeepSeek. Telemetry was enabled by default after updates, even if previously declined, meaning users could unknowingly continue contributing data without explicit consent.
This data provided insight into internal applications, workflows, and potentially sensitive information that users routinely shared with AI tools. By maintaining periodic exfiltration tied to persistent session identifiers, the threat actor could maintain an evolving view of user activity, effectively turning the extension into a long-term data collection capability embedded in normal browser usage.
Technical Analysis
The extension runs a background script that logs nearly all visited URLs and excerpts of AI chat messages. The data is stored locally in Base64-encoded JSON and periodically uploaded to remote endpoints, including deepaichats[.]com.
Collected data includes full URLs (including internal sites), previous and next navigation context, chat snippets, model names, and a persistent UUID. Telemetry is enabled by default after updates, even if previously declined. The code includes minimal filtering, weak consent handling, and limited data protection controls.
Overall, the extension functions as a broad telemetry collection mechanism that introduces privacy and compliance risks in enterprise environments.
The following screenshots show extensions observed during the investigation:
Figure 1. Details page for the browser extension fnmhidmjnmklgjpcoonkmkhjpjechg, as displayed in the browser extension management interface.Figure 2. Details page for the browser extension inhcgfpbfdjbjogdfjbclgolkmhnooop, as displayed in the browser extension management interface.
Mitigation and protection guidance
Monitor network POST traffic to the extension’s known endpoints (*.chatsaigpt.com, *. deepaichats.com, *.chataigpt.pro, *.chatgptsidebar.pro) and assess impacted devices to understand scope of data exfiltrated.
Leverage Microsoft Purview data security to implement AI data security and compliance controls around sensitive data being used in browser-based AI chat applications.
Create, monitor, and enforce organizational policies and procedures on AI use within your organization.
Finally, educate users to avoid side‑loaded or unverified productivity extensions. Also suggest end users review their installed extensions in chrome or edge and remove unknown extensions.
Microsoft Defender XDR detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, SaaS apps, email & collaboration tools 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.
Tactic
Observed activity
Microsoft Defender coverage
Execution, Persistence
Malicious extensions are installed and loaded
Microsoft Defender for Endpoint – Attempt to add or modify suspicious browser extension, Suspicious browser extension load – Trojan:JS/ChatGPTStealer.GVA!MTB, Trojan:JS/Rossetaph
Exfiltration
User ChatGPT and DeepSeek conversation histories are exfiltrated
Microsoft Defender for Endpoint Attack C2s are blocked by Network Protection
Hunting queries
Microsoft Defender XDR
Browser launched with malicious extension IDs
Purpose: high confidence signal that a known‑bad extension is present or side‑loaded.
DeviceProcessEvents
| where FileName in~ ("chrome.exe","msedge.exe")
| where ProcessCommandLine has_any ("fnmihdojmnkclgjpcoonokmkhjpjechg", "inhcgfpbfdjbjogdfjbclgolkmhnooop" ) // “Chat GPT for Chrome with GPT‑5, Claude Sonnet & DeepSeek & AI Sidebar with Deepseek, ChatGPT, Claude and more”)
| project Timestamp, DeviceName, Account=InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessParentFileName
| order by Timestamp desc
Outbound Connections to the Attacker’s Infrastructure
Purpose: Direct evidence of browser traffic to the campaign’s domains.
DeviceNetworkEvents
| where RemoteUrl has_any ( "chatsaigpt.com","deepaichats.com","chataigpt.pro","chatgptsidebar.pro")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,RemoteUrl, RemoteIP, RemotePort, Protocol
| order by Timestamp desc
Installations of Malicious IDs
Purpose: Enumerate all devices where either of the two malicious IDs is installed.
DeviceTvmBrowserExtensions
| where ExtensionId in ("fnmihdojmnkclgjpcoonokmkhjpjechg", "inhcgfpbfdjbjogdfjbclgolkmhnooop")
| summarize Devices=dcount(DeviceName) by BrowserName
| order by Devices desc
Detecting On-Disk Artifacts of Malicious Extensions
Purpose: Identify any systems where the malicious Chrome or Edge Extensions are present by detecting file activity inside their known extension directories.
DeviceFileEvents
| where FolderPath has_any ( @"\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\fnmihdojmnkclgjpcoonokmkhjpjechg",@"\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\inhcgfpbfdjbjogdfjbclgolkmhnooop",@"\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Extensions\\fnmihdojmnkclgjpcoonokmkhjpjechg",@"\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Extensions\\inhcgfpbfdjbjogdfjbclgolkmhnooop")
| where ActionType in~ ("FileCreated","FileModified","FileRenamed")
| project Timestamp, DeviceName, InitiatingProcessFileName, ActionType, FolderPath, FileName, SHA256, AccountName
| order by Timestamp desc
Microsoft Defender Experts has observed the Contagious Interview campaign, a sophisticated social engineering operation active since at least December 2022. Microsoft continues to detect activity associated with this campaign in recent customer environments, targeting software developers at enterprise solution providers and media and communications firms by abusing the trust inherent in modern recruitment workflows.
Threat actors repeatedly achieve initial access through convincingly staged recruitment processes that mirror legitimate technical interviews. These engagements often include recruiter outreach, technical discussions, assignments, and follow-ups, ultimately persuading victims to execute malicious packages or commands under the guise of routine evaluation tasks.
This campaign represents a shift in initial access tradecraft. By embedding targeted malware delivery directly into interview tools, coding exercises, and assessment workflows developers inherently trust, threat actors exploit the trust job seekers place in the hiring process during periods of high motivation and time pressure, lowering suspicion and resistance.
Attack chain overview
Initial access
As part of a fake job interview process, attackers pose as recruiters from cryptocurrency trading firms or AI-based solution providers. Victims who fall for the lure are instructed to clone and execute an NPM package hosted on popular code hosting platforms such as GitHub, GitLab, or Bitbucket. In this scenario, the executed NPM package directly loads a follow-on payload.
Execution of the malicious package triggers additional scripts that ultimately deploy the backdoor in the background. In recent intrusions, attackers have adapted their technique to leverage Visual Studio Code workflows: when victims open the downloaded package in Visual Studio Code, they are prompted to trust the repository author. If trust is granted, Visual Studio Code automatically executes the repository’s task configuration file, which then fetches and loads the backdoor.
A typical repository hosted on Bitbucket, posing as a blockchain-powered game.Sample task found in the repository (bottom: URL shortener redirecting to vercel.app).
Once the victim executes the task or the package is successfully executed, a backdoor is launched. Over time, the attackers deploy various cross platform functional backdoor families to establish initial foothold on the impacted devices and then pivot into more traditional intrusion operations.
OtterCookie
OtterCookie is the most widely observed backdoor variant in this campaign. First observed in September 2024, this JavaScript based backdoor was in active development phase and over time, it evolved from a basic tool for executing remote commands and searching for crypto keys into a modular program capable of broader data theft with a capability to check for VM environments, install communication clients like socket.io for C2, exfiltrate information, executes arbitrary shell commands, load other modules to collect specific intended data and reports results.
Microsoft Defender Experts continue to observe two active OtterCookie variants, with the latest tracked since October 2025 retains the same core functionality but introduces significantly heavier obfuscation that hides strings, URLs, and logic through encoded index lookups and shuffled arrays. This reduces runtime artifacts and visibility while making static analysis and signature-based detection substantially harder through deliberate stealth and intent masking.
OtterCookie variant comparison: direct strings and API calls (top) versus an obfuscated string pool with index‑based lookups masking indicators and logic (bottom).
Beaconing agent
Microsoft Defender Experts has observed this JavaScript backdoor variant (shown below) in active use since at least October 2025. The malware operates as a lightweight command-and-control beacon capable of collecting host fingerprints, including hostname, network identifiers, operating system details, and public IP address. It periodically contacts a remote controller to exchange status information and retrieve tasking and can execute arbitrary attacker-supplied code by spawning a local runtime and piping the payload directly through standard input.
The backdoor launches detached background child processes, tracks their process identifiers for lifecycle management, supports remote configuration updates and shutdown commands, and reports execution errors back to the controller. These capabilities enable stealthy execution, resilient remote code execution, system reconnaissance, and ongoing remote process control.
JavaScript backdoor variant.
Data collection
Once a foothold is established via backdoors, attackers move on to collecting sensitive information from compromised devices. Although the objective remains consistent, the methods vary depending on the underlying platform and the specific capabilities of each backdoor.
Enumerating sensitive data
On Windows systems, through beaconing agent a script was launched to enumerate credential and keystore material (as shown in the image below). This includes environment configuration files, wallet mnemonic phrases, password stores such as KeePass database, 1Password artifacts, notes, and cryptographic keys. Collected data is packaged and exfiltrated to attacker-controlled infrastructure via HTTP POST requests.
On macOS, attackers through the same beaconing agent adapt their behavior by issuing system commands to search the entire filesystem for files matching credential- and secret-related patterns (as shown in the image below). To improve efficiency and reduce noise, the search logic deliberately excludes common system, vendor, and developer directories before exfiltrating the results to remote servers.
In contrast, intrusions leveraging the OtterCookie backdoor employ a modular Node.js-based approach. The malicious module performs broad file-harvesting operations across local drives, excluding large system and development cache directories. The backdoor targets high-value assets such as cryptographic keys, environment files, documents, images, source code, and package artifacts. Files matching predefined patterns are exfiltrated to attacker-controlled endpoints using axios-based form-data uploads, allowing the activity to blend into legitimate web traffic.
[Normalized view] Obfuscated OtterCookie variant defining file-extension include and exclude lists.
Spying and clipboard data read
Through the backdoor, the attacker installs benign npm packages such as node-global-key-listener and screenshot-desktop for keylogging and desktop screenshot. The backdoor also loads a Node.js module that orchestrates staged payload execution via PowerShell and CMD, ultimately collecting active window metadata and clipboard contents through repeated, hidden PowerShell commands.
Observed events in an intrusion involving screenshot capture via the screenshot-desktop NPM package (screenCapture_1.3.2).Process tree (condensed for clarity) highlighting covert PowerShell‑based surveillance activity.
While the above is implemented through a separate module, OtterCookie also embeds a clipboard watcher function that captures clipboard content and exfiltrates it to attacker-controlled infrastructure.
Snippet illustrating how two different OtterCookie variants implement this clipboard monitoring functionality.
Follow-up payloads: Invisible Ferret
In the early stages of this campaign, Invisible Ferret was primarily delivered via BeaverTail, an information stealer that also functioned as a loader. In more recent intrusions, however, Invisible Ferret is predominantly deployed as a follow-on payload, introduced after initial access has been established through the beaconing agent or OtterCookie.
Invisible Ferret is a Python-based backdoor used in later stages of the attack chain, enabling remote command execution, extended system reconnaissance, and persistent control after initial access has been secured by the primary backdoor.
Process tree snippet from an incident where the beaconing agent deploys Invisible Ferret.
Other Campaigns
Another notable backdoor observed in this campaign is FlexibleFerret, a modular backdoor implemented in both Go and Python variants. It leverages encrypted HTTP(S) and TCP command and control channels to dynamically load plugins, execute remote commands, and support file upload and download operations with full data exfiltration. FlexibleFerret establishes persistence through RUN registry modifications and includes built-in reconnaissance and lateral movement capabilities. Its plugin-based architecture, layered obfuscation, and configurable beaconing behavior contribute to its stealth and make analysis more challenging.
While Microsoft Defender Experts have observed FlexibleFerret less frequently than the backdoors discussed in earlier sections, it remains active in the wild. Campaigns deploying this backdoor rely on similar social engineering techniques, where victims are directed to a fraudulent interview or screening website impersonating a legitimate platform. During the process, users encounter a fabricated technical error and are instructed to copy and paste a command to resolve the issue. This command retrieves additional payloads, ultimately leading to the execution of the FlexibleFerret backdoor.
Code quality observations
Recent samples exhibit characteristics that differ from traditionally engineered malware. The beaconing agent script contains inconsistent error handling, empty catch blocks, and redundant reporting logic that appear minimally refined. Similarly, the FlexibleFerret Python variant combines tutorial-style comments, emoji-based logging, and placeholder secret key markers alongside functional malware logic.
These patterns, including instructional narrative structure and rapid iteration cycles, suggest development workflows that prioritize speed and functional output over refined engineering. While these characteristics may indicate the use of development acceleration tools, they primarily reflect evolving threat actor development practices and rapid tooling adaptation that enable quick iteration on malicious code.
Snippets from the Python variant of FlexibleFerret highlighting tutorial‑style comments and AI‑assisted code with icon‑based logging.
Security implications
This campaign weaponizes hiring processes into a persistent attack channel. Threat actors exploit technical interviews and coding assessments to execute malware through dependency installations and repository tasks, targeting developer endpoints that provide access to source code, CI/CD pipelines, and production infrastructure.
Threat actors harvest API tokens, cloud credentials, signing keys, cryptocurrency wallets, and password manager artifacts. Modular backdoors enable infrastructure rotation while maintaining access and complicating detection.
Organizations should treat recruitment workflows as attack surfaces by deploying isolated interview environments, monitoring developer endpoints and build tools, and hunting for suspicious repository activity and dependency execution patterns.
Mitigation and protection guidance
Harden developer and interview workflows
Use a dedicated, isolated environment for coding tests and take-home assignments (for example, a non-persistent virtual machine). Do not use a primary corporate workstation that has access to production credentials, internal repositories, or privileged cloud sessions.
Establish a policy that requires review of any recruiter-provided repository before running scripts, installing dependencies, or executing tasks. Treat “paste-and-run” commands and “quick fix” instructions as high-risk.
Provide guidance to developers on common red flags: short links redirecting to file hosts, newly created repositories or accounts, unusually complex “assessment” setup steps, and instructions that request disabling security controls or trusting unknown repository authors.
Reduce attack surface from tools commonly abused in this campaign
Ensure tamper protection and real-time antivirus protection are enabled, and that endpoints receive security updates. These campaigns often rely on script execution and commodity tooling rather than exploiting a single vulnerability, so layered endpoint protection remains effective.
Restrict scripting and developer runtimes where possible (Node.js, Python, PowerShell). In high-risk groups, consider application control policies that limit which binaries can execute and where they can be launched from (for example, preventing developer tool execution from Downloads and temporary folders).
Monitor for and consider blocking common “download-and-execute” patterns used as stagers, such as curl/wget piping to shells, and outbound requests to low-reputation hosts used to serve payloads (including short-link redirection services).
Protect secrets and limit downstream impact
Reduce the exposure of secrets on developer endpoints. Use just-in-time and short-lived credentials, store secrets in vaults, and avoid long-lived tokens in environment files or local configuration.
Enforce multifactor authentication and conditional access for source control, CI/CD, cloud consoles, and identity providers to mitigate credential theft from compromised endpoints.
Review and restrict access to password manager vaults and developer signing keys. This campaign explicitly targets artifacts such as wallet material, password databases, private keys, and other high-value developer-held secrets.
Detect, investigate, and respond
Hunt for execution chains that start from a code editor or developer tool and quickly transition into shell or scripting execution (for example, Visual Studio Code/Cursor App→ cmd/PowerShell/bash → curl/wget → script execution). Review repository task configurations and build scripts when such chains are observed.
Monitor Node.js and Python processes for behaviors consistent with this campaign, including broad filesystem enumeration for credential and key material, clipboard monitoring, screenshot capture, and HTTP POST uploads of collected data.
If compromise is suspected, isolate the device, rotate credentials and tokens that may have been exposed, review recent access to code repositories and CI/CD systems, and assess for follow-on payloads and persistence.
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.
Tactic
Observed Activity
Microsoft Defender Coverage
Execution
curl or wget command launched from NPM package to fetch script from vercel.app or URL shortner
Microsoft Defender for Endpoint Suspicious process execution
Microsoft Defender for Endpoint Suspicious Node.js process behavior Possible OtterCookie malware activity Suspicious Python library load Suspicious connection to remote service
Microsoft Defender for Antivirus Suspicious ‘BeaverTail’ behavior was blocked
Credential Access
Enumerating sensitive data
Microsoft Defender for Endpoint Enumeration of files with sensitive data
Discovery
Gathering basic system information and enumerating sensitive data
Microsoft Defender for Endpoint System information discovery Suspicious System Hardware Discovery Suspicious Process Discovery
Collection
Clipboard data read by Node.js script
Microsoft Defender for Endpoint Suspicious clipboard access
Hunting Queries
Microsoft Defender XDR
Microsoft Defender XDR customers can run the following queries to find related activity in their networks.
Run the below query to identify suspicious script executions where curl or wget is used to fetch remote content.
DeviceProcessEvents
| where ProcessCommandLine has_any ("curl", "wget")
| where ProcessCommandLine has_any ("vercel.app", "short.gy") and ProcessCommandLine has_any (" | cmd", " | sh")
Run the below query to identify OtterCookie-related Node.js activity by correlating clipboard monitoring, recursive file scanning, curl-based exfiltration, and VM-awareness patterns.
Run the below query to detect possible Node.js beaconing agent activity.
DeviceProcessEvents
| where ProcessCommandLine has_all ("handleCode", "AgentId", "SERVER_IP")
Run the below query to detect possible BeaverTail and InvisibleFerret activity.
DeviceProcessEvents
| where FileName has "python" or ProcessVersionInfoOriginalFileName has "python"
| where ProcessCommandLine has_any (@'/.n2/pay', @'\.n2/pay', @'\.npl', '/.npl', @'/.n2/bow', @'\.n2/bow', '/pdown', '/.sysinfo', @'\.n2/mlip', @'/.n2/mlip')
Run the below query to detect credential enumeration activity.
DeviceProcessEvents
| where InitiatingProcessParentFileName has "node"
| where (InitiatingProcessCommandLine has_all ("cmd.exe /d /s /c", " findstr /v", '\"dir')
and ProcessCommandLine has_any ("account", "wallet", "keys", "password", "seed", "1pass", "mnemonic", "private"))
or ProcessCommandLine has_all ("-path", "node_modules", "-prune -o -path", "vendor", "Downloads", ".env")
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.
Microsoft Defender has been investigating reports of malicious Chromium‑based browser extensions that impersonate legitimate AI assistant tools to harvest LLM chat histories and browsing data. Reporting indicates these extensions have reached approximately 900,000 installs. Microsoft Defender telemetry also confirms activity across more than 20,000 enterprise tenants, where users frequently interact with AI tools using sensitive inputs.
The extensions collected full URLs and AI chat content from platforms such as ChatGPT and DeepSeek, exposing organizations to potential leakage of proprietary code, internal workflows, strategic discussions, and other confidential data.
At scale, this activity turns a seemingly trusted productivity extension into a persistent data collection mechanism embedded in everyday enterprise browser usage, highlighting the growing risk browser extensions pose in corporate environments.
Attack chain overview
Attack chain illustrating how a malicious AI‑themed Chromium extension progresses from marketplace distribution to persistent collection and exfiltration of LLM chat content and browsing telemetry.
Reconnaissance
The threat actor targeted the rapidly growing ecosystem of AI-assistant browser extensions and the user behaviors surrounding them. Many knowledge workers install sidebar tools to interact with models such as ChatGPT and DeepSeek, often granting broad page-level permissions for convenience. These extensions also operate across Chromium-based browsers such as Google Chrome and Microsoft Edge using a largely uniform architecture.
We also observed cases where agentic browsers automatically downloaded these extensions without requiring explicit user approval, reflecting how convincing the names and descriptions appeared. Together, these factors created a large potential audience that frequently handles sensitive information in the browser and a platform where look-alike extensions could blend in with minimal friction.
The actors also reviewed legitimate extensions, such as AITOPIA, to emulate familiar branding, permission prompts, and interaction patterns. This allowed the malicious extensions to align with user expectations while enabling large-scale telemetry collection from browser activity.
Weaponization
The threat actor developed a Chromium-based browser extension compatible with both Google Chrome and Microsoft Edge. The extension was designed to passively observe user activity, collecting visited URLs and segments of AI-assisted chat content generated during normal browser use.
Collected data was staged locally and prepared for periodic transmission, enabling continuous visibility into user browsing behavior and interactions with AI platforms.
To reduce suspicion, the extension presented its activity as benign analytics commonly associated with productivity tools. From a defender perspective, this stage introduced a browser-resident data collection capability focused on URLs and AI chat content, along with scheduled outbound communication to external infrastructure.
Delivery
The malicious extension was distributed through the Chrome Web Store, using AI-themed branding and descriptions to resemble legitimate productivity extensions. Because Microsoft Edge supports Chrome Web Store extensions, a single listing enabled distribution across both browsers without requiring additional infrastructure.
User familiarity with installing AI sidebar tools, combined with permissive enterprise extension policies, allowed the extension to reach a broad audience. This trusted distribution channel enabled the extension to reach both personal and corporate environments through routine browser extension installation.
Exploitation
Following installation, the extension leveraged the Chromium extension permission model to begin collecting data without further user interaction. The granted permissions provided visibility into a wide range of browsing activity, including internal sites and AI chat interfaces.
A misleading consent mechanism further enabled this behavior. Although users could initially disable data collection, subsequent updates automatically re-enabled telemetry, restoring data access without clear user awareness.
By relying on user trust, ambiguous consent language, and default extension behaviors, the threat actor maintained continuous access to browser-resident data streams.
Installation
Persistence was achieved through normal browser extension behavior rather than traditional malware techniques. Once installed, the extension automatically reloaded whenever the browser started, requiring no elevated privileges or additional user actions.
Local extension storage maintained session identifiers and queued telemetry, allowing the extension to resume collection after browser restarts or service worker reloads. This approach allowed the data collection functionality to continue across browser sessions while appearing similar to a typical installed browser extension.
Command and Control (C2)
At regular intervals, the extension transmitted collected data to threat actor–controlled infrastructure using HTTPS POST requests to domains including deepaichats[.]com and chatsaigpt[.]com. By relying on common web protocols and periodic upload activity, the outbound traffic appeared similar to routine browser communications.
After transmission, local buffers were cleared, reducing on-disk artifacts and limiting local forensic visibility. This lightweight command-and-control model allowed the extension to regularly transmit browsing telemetry and AI chat content from both Chrome and Microsoft Edge environments.
Actions on Objective
The threat actor’s objective appeared to be ongoing data collection and visibility into user activity. Through the installed extension, the threat actor collected browsing telemetry and AI-related content, including prompts and responses from platforms such as ChatGPT and DeepSeek. Telemetry was enabled by default after updates, even if previously declined, meaning users could unknowingly continue contributing data without explicit consent.
This data provided insight into internal applications, workflows, and potentially sensitive information that users routinely shared with AI tools. By maintaining periodic exfiltration tied to persistent session identifiers, the threat actor could maintain an evolving view of user activity, effectively turning the extension into a long-term data collection capability embedded in normal browser usage.
Technical Analysis
The extension runs a background script that logs nearly all visited URLs and excerpts of AI chat messages. The data is stored locally in Base64-encoded JSON and periodically uploaded to remote endpoints, including deepaichats[.]com.
Collected data includes full URLs (including internal sites), previous and next navigation context, chat snippets, model names, and a persistent UUID. Telemetry is enabled by default after updates, even if previously declined. The code includes minimal filtering, weak consent handling, and limited data protection controls.
Overall, the extension functions as a broad telemetry collection mechanism that introduces privacy and compliance risks in enterprise environments.
The following screenshots show extensions observed during the investigation:
Figure 1. Details page for the browser extension fnmhidmjnmklgjpcoonkmkhjpjechg, as displayed in the browser extension management interface.Figure 2. Details page for the browser extension inhcgfpbfdjbjogdfjbclgolkmhnooop, as displayed in the browser extension management interface.
Mitigation and protection guidance
Monitor network POST traffic to the extension’s known endpoints (*.chatsaigpt.com, *. deepaichats.com, *.chataigpt.pro, *.chatgptsidebar.pro) and assess impacted devices to understand scope of data exfiltrated.
Leverage Microsoft Purview data security to implement AI data security and compliance controls around sensitive data being used in browser-based AI chat applications.
Create, monitor, and enforce organizational policies and procedures on AI use within your organization.
Finally, educate users to avoid side‑loaded or unverified productivity extensions. Also suggest end users review their installed extensions in chrome or edge and remove unknown extensions.
Microsoft Defender XDR detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, SaaS apps, email & collaboration tools 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.
Tactic
Observed activity
Microsoft Defender coverage
Execution, Persistence
Malicious extensions are installed and loaded
Microsoft Defender for Endpoint – Attempt to add or modify suspicious browser extension, Suspicious browser extension load – Trojan:JS/ChatGPTStealer.GVA!MTB, Trojan:JS/Rossetaph
Exfiltration
User ChatGPT and DeepSeek conversation histories are exfiltrated
Microsoft Defender for Endpoint Attack C2s are blocked by Network Protection
Hunting queries
Microsoft Defender XDR
Browser launched with malicious extension IDs
Purpose: high confidence signal that a known‑bad extension is present or side‑loaded.
DeviceProcessEvents
| where FileName in~ ("chrome.exe","msedge.exe")
| where ProcessCommandLine has_any ("fnmihdojmnkclgjpcoonokmkhjpjechg", "inhcgfpbfdjbjogdfjbclgolkmhnooop" ) // “Chat GPT for Chrome with GPT‑5, Claude Sonnet & DeepSeek & AI Sidebar with Deepseek, ChatGPT, Claude and more”)
| project Timestamp, DeviceName, Account=InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessParentFileName
| order by Timestamp desc
Outbound Connections to the Attacker’s Infrastructure
Purpose: Direct evidence of browser traffic to the campaign’s domains.
DeviceNetworkEvents
| where RemoteUrl has_any ( "chatsaigpt.com","deepaichats.com","chataigpt.pro","chatgptsidebar.pro")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,RemoteUrl, RemoteIP, RemotePort, Protocol
| order by Timestamp desc
Installations of Malicious IDs
Purpose: Enumerate all devices where either of the two malicious IDs is installed.
DeviceTvmBrowserExtensions
| where ExtensionId in ("fnmihdojmnkclgjpcoonokmkhjpjechg", "inhcgfpbfdjbjogdfjbclgolkmhnooop")
| summarize Devices=dcount(DeviceName) by BrowserName
| order by Devices desc
Detecting On-Disk Artifacts of Malicious Extensions
Purpose: Identify any systems where the malicious Chrome or Edge Extensions are present by detecting file activity inside their known extension directories.
DeviceFileEvents
| where FolderPath has_any ( @"\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\fnmihdojmnkclgjpcoonokmkhjpjechg",@"\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\inhcgfpbfdjbjogdfjbclgolkmhnooop",@"\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Extensions\\fnmihdojmnkclgjpcoonokmkhjpjechg",@"\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Extensions\\inhcgfpbfdjbjogdfjbclgolkmhnooop")
| where ActionType in~ ("FileCreated","FileModified","FileRenamed")
| project Timestamp, DeviceName, InitiatingProcessFileName, ActionType, FolderPath, FileName, SHA256, AccountName
| order by Timestamp desc
Following its emergence in August 2023, Tycoon2FA rapidly became one of the most widespread phishing-as-a-service (PhaaS) platforms, enabling campaigns responsible for tens of millions of phishing messages reaching over 500,000 organizations each month worldwide. The phishing kit—developed, supported, and advertised by the threat actor tracked by Microsoft Threat Intelligence as Storm-1747—provided adversary-in-the-middle (AiTM) capabilities that allowed even less skilled threat actors to bypass multifactor authentication (MFA), significantly lowering the barrier to conducting account compromise at scale.
Figure 1. Monthly volume of Tycoon2FA-related phishing messages
Tycoon2FA’s platform enabled threat actors to impersonate trusted brands by mimicking sign-in pages for services like Microsoft 365, OneDrive, Outlook, SharePoint, and Gmail. It also allowed threat actors using its service to establish persistence and to access sensitive information even after passwords are reset, unless active sessions and tokens were explicitly revoked. This worked by intercepting session cookies generated during the authentication process, simultaneously capturing user credentials. The MFA codes were subsequently relayed through Tycoon2FA’s proxy servers to the authenticating service.
To evade detection, Tycoon2FA used techniques like anti-bot screening, browser fingerprinting, heavy code obfuscation, self-hosted CAPTCHAs, custom JavaScript, and dynamic decoy pages. Targets are often lured through phishing emails containing attachments like .svg, .pdf, .html, or .docx files, often embedded with QR codes or JavaScript.
This blog provides a comprehensive up-to-date analysis of Tycoon2FA’s progression and scale. We share specific examples of the Tycoon2FA service panel, including a detailed analysis of Tycoon2FA infrastructure. Defending against Tycoon2FA and similar 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.
Tycoon2FA phishing services were advertised and sold to cybercriminals on applications like Telegram and Signal. Phish kits were observed to start at $120 USD for access to the panel for 10 days and $350 for access to the panel for a month, but these prices could vary.
Tycoon2FA is operated through a web‑based administration panel provided on a per user basis that centrally integrates all functionality provided by the Tycoon 2FA PhaaS platform. The panel serves as a single dashboard for configuring, tracking, and refining campaigns. While it does not include built‑in mailer capabilities, the panel provides the core components needed to support phishing campaigns. This includes pre‑built templates, attachment files for common lure formats, domain and hosting configuration, redirect logic, and victim tracking. This design makes the platform accessible to less technically skilled actors while still offering sufficient flexibility for more experienced operators.
Figure 2. Tycoon2FA admin panel sign-in screen
After signing in, Tycoon2FA customers are presented with a dashboard used to configure, monitor, and manage phishing campaigns. Campaign operators can configure a broad set of campaign parameters that control how phishing content is delivered and presented to targets. Key settings include lure template selection and branding customization, redirection routing, MFA interception behavior, CAPTCHA appearance and logic, attachment generation, and exfiltration configuration. Campaign operators can choose from highly configurable landing pages and sign-in themes that impersonate widely trusted services such as Microsoft 365, Outlook, SharePoint, OneDrive, and Google, increasing the perceived legitimacy of attacks.
Figure 3. Phishing page theme selection and configuration settings
Campaign operators can also configure how the malicious content is delivered through attachments. Options include generating EML files, PDFs, and QR codes, offering multiple ways to package and distribute phishing lures.
Figure 4. Malicious attachment options
The panel also allows operators to manage redirect chains and routing logic, including the use of intermediate pages and decoy destinations. Support for automated subdomain rotation and intermediary Cloudflare Workers-based URLs enables campaigns to adapt quickly as infrastructure is identified or blocked. The following is a visual example of redirect and routing options, including intermediate pages and decoy destinations used within a phishing campaign.
Figure 5. Redirect chain and routing configuration
Once configured, these settings control the appearance and behavior of the phishing pages delivered to targets. The following examples show how selected themes (Microsoft 365 and Outlook) are rendered as legitimate-looking sign-in pages presented to targets.
Figure 6. Sample Tycoon2FA phishing pages
Beyond campaign configuration, the panel provides detailed visibility into victim interaction and authentication outcomes. Operators can track valid and invalid sign-in attempts, MFA usage, and session cookie capture, with victim data organized by attributes such as targeted service, browser, location, and authentication status. Captured credentials and session cookies can be viewed or downloaded directly within the panel and/or forwarded to Telegram for near‑real‑time monitoring. The following image shows a summary view of victim account outcomes for threat actors to review and track.
Figure 7. Tycoon2FA panel dashboard
Captured session information including account attributes, browsers and location metadata, and authentication artifacts are exfiltrated through Telegram bot.
Figure 8. Exfiltrated session information
In addition to configuration and campaign management features, the panel includes a section for announcements and updates related to the service. These updates reflect regular maintenance and ongoing changes, indicating that the service continues to evolve.
Figure 9. Tycoon2FA announcement and update panel
By combining centralized configuration, real-time visibility, and regular platform updates, the service enables scalable AiTM phishing operations that can adapt quickly to defensive measures. This balance of usability, adaptability, and sustained development has contributed to Tycoon2FA’s adoption across a wide range of campaigns.
Tycoon2FA infrastructure
Tycoon2FA’s infrastructure has shifted from static, high-entropy domains to a fast-moving ecosystem with diverse top-level domains (TLDs) and short-lived (often 24-72 hours) fully qualified domain names (FQDNs), with the majority hosted on Cloudflare. A key change is the move toward a broader mix of TLDs. Early tracking showed heavier use of regional TLDs like .es and .ru, but recent campaigns increasingly rotated across inexpensive generic TLDs that require little to no identity verification. Examples include .space, .email, .solutions, .live, .today, and .calendar, as well as second-level domains such as .sa[.]com, .in[.]net, and .com[.]de.
Tycoon2FA generated large numbers of subdomains for individual phishing campaigns, used them briefly, then dropped them and spun up new ones. Parent root domains might remain registered for weeks or months, but nearly all campaign-specific FQDNs were temporary. The rapid turnover complicated detection efforts, such as building reliable blocklists or relying on reputation-based defenses.
Subdomain patterns have also shifted toward more readable formats. Instead of high entropy or algorithmically generated strings, like those used in July 2025, newly observed subdomains used recognizable words tied to common workflows or services, like those observed in December 2025.
Some subdomains resembled everyday processes or tech terms like cloud, desktop, application, and survey, while others echoed developer or admin vocabulary like python, terminal, xml, and faq. Software as a service (SaaS) brand names have appeared in subdomains as well, such as docker, zendesk, azure, microsoft, sharepoint, onedrive, and nordvpn. This shift was likely used to reduce user suspicion and to evade detection models that rely on entropy or string irregularity.
Tycoon2FA’s success stemmed from closely mimicking legitimate authentication processes while covertly intercepting both user credentials and session tokens, granting attackers full access to targeted accounts. Tycoon2FA operators could bypass nearly all commonly deployed MFA methods, including SMS codes, one-time passcodes, and push notifications. The attack chain was typical yet highly effective and started with phishing the user through email, followed by a multilayer redirect chain, then a spoofed sign-in page with AiTM relay, and authentication relay culminating in token theft.
Tycoon2FA phishing emails
In observed campaigns, threat actors gained initial access through phishing emails that used either embedded links or malicious attachments. Most of Tycoon2FA’s lures fell into four categories:
PDF or DOC/DOCX attachments with QR codes
SVG files containing embedded redirect logic
HTML attachments with short messages
Redirect links that appear to come from trusted services
Email lures were crafted from ready-made templates that impersonated trusted business applications like Microsoft 365, Azure, Okta, OneDrive, Docusign, and SharePoint. These templates spanned themes from generic notifications (like voicemail and shared document access) to targeted workflows (like human resources (HR) updates, corporate documents, and financial statements). In addition to spoofing trusted brands, phishing emails often leveraged compromised accounts with existing threads to increase legitimacy.
While Tycoon2FA supplied hosting infrastructures, along with various phishing and landing page related templates, email distribution was not provided by the service.
Defense evasion
From a defense standpoint, Tycoon2FA stood out for its continuously updated evasion and attack techniques. A defining feature was the use of constantly changing custom CAPTCHA pages that regenerated frequently and varied across campaigns. As a result, static signatures and narrowly scoped detection logic became less effective over time. Before credentials were entered, targets encounter the custom CAPTCHA challenge, which was designed to block automated scanners and ensure real users reach the phishing content. These challenges often used randomized HTML5 canvas elements, making them hard to bypass with automation. While Cloudflare Turnstile was once the primary CAPTCHA, Tycoon2FA shifted to using a rotating set of custom CAPTCHA challenges. The CAPTCHA acted as a gate in the flow, legitimizing the process and nudging the target to continue.
Figure 10. Custom CAPTCHA pages observed on Tycoon2FA domains
After the CAPTCHA challenge, the user was shown a dynamically generated sign-in portal that mirrored the targeted service’s branding and authentication flow, most often Microsoft or Gmail. The page might even include company branding to enhance legitimacy. When the user submitted credentials, Tycoon2FA immediately relayed them to the real service, triggering the genuine MFA challenge. The phishing page then displayed the same MFA prompt (for example, number matching or code entry). Once the user completed MFA, the attacker captured the session cookie and gained real-time access without needing further authentication, even if the password was changed later. These pages were created with heavily obfuscated and randomized JavaScript and HTML, designed to evade signature-based detection and other security tools.
The phishing kit also disrupted analysis through obfuscation and dynamic code generation, including nonfunctional dead code, to defeat consistent fingerprinting. When the campaign infrastructure encountered an unexpected or invalid server response (for example, a geolocation outside the allowed targeting zone), the kit replaced phishing content with a decoy page or a benign redirect to avoid exposing the live credential phishing site.
Tycoon2FA further complicated investigation by actively checking for analysis of environments or browser automation and adjusting page behavior if detected. These evasive measures included:
Intercepting user input
Keystroke monitoring
Blocking copy/paste and right click functions
Detecting or blocking automated inspection
Automation tools (for example, PhantomJS, Burp Suite)
Disabling common developer tool shortcuts
Validating and filtering incoming traffic
Browser fingerprinting
Datacenter IP filtering
Geolocation restrictions
Suspicious user agent profiling
Increased obfuscation
Encoded content (Base64, Base91)
Fragmented or concatenated strings
Invisible Unicode characters
Layered URL/URI encoding
Dead or nonfunctional script
If analysis was suspected at any point, the kit redirected to a legitimate decoy site or threw a 404 error.
Complementing these anti-analysis measures, Tycoon2FA used increasingly complex redirect logic. Instead of sending victims directly to the phishing page, it chained multiple intermediate hosts, such as Azure Blob Storage, Firebase, Wix, TikTok, or Google resources, to lend legitimacy to the redirect path. Recent changes combined these redirect chains with encoded Uniform Resource Identifier (URI) strings that obscured full URL paths and landing points, frustrating both static URL extraction and detonation attempts. Stacked together, these tactics made Tycoon2FA a resilient, fast-moving system that evaded both automated and manual detection efforts.
Credential theft and account access
Captured credentials and session tokens were exfiltrated over encrypted channels, often via Telegram bots. Attackers could then access sensitive data and establish persistence by modifying mailbox rules, registering new authenticator apps, or launching follow-on phishing campaigns from compromised accounts. The following diagram breaks down the AiTM process.
Figure 11. AiTM authentication process
Tycoon2FA illustrated the evolution of phishing kits in response to rising enterprise defenses, adapting its lures, infrastructure, and evasion techniques to stay ahead of detection. As organizations increasingly adopt MFA, attackers are shifting to tools that target the authentication process itself instead of attempting to circumvent it. Coupled with affordability, scalability, and ease of use, Tycoon2FA posed a persistent and significant threat to both consumer and enterprise accounts, especially those that rely on MFA as a primary safeguard.
Mitigation and protection guidance
Mitigating threats from phishing actors begins with securing user identity by eliminating traditional credentials and adopting passwordless, phishing-resistant MFA methods such as FIDO2 security keys, Windows Hello for Business, and Microsoft Authenticator passkeys.
If Microsoft Defender alerts indicate suspicious activity or confirmed compromised account or a system, it’s essential to act quickly and thoroughly. The following are recommended remediation steps for each affected identity:
Reset credentials – Immediately reset the account’s password and revoke any active sessions or tokens. This ensures that any stolen credentials can no longer be used.
Re-register or remove MFA devices – Review users’ MFA devices, specifically those recently added or updated.
Revert unauthorized payroll or financial changes – If the attacker modified payroll or financial configurations, such as direct deposit details, revert them to their original state and notify the appropriate internal teams.
Remove malicious inbox rules – Attackers often create inbox rules to hide their activity or forward sensitive data. Review and delete any suspicious or unauthorized rules.
Verify MFA reconfiguration – Confirm that the user has successfully reconfigured MFA and that the new setup uses secure, phishing-resistant methods.
To defend against the wide range of phishing threats, Microsoft Threat Intelligence recommends the following mitigation steps:
Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Microsoft 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links used in phishing and other attacks.
Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
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 attack tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants
Use the Attack Simulator in Microsoft Defender for Office 365 to run realistic, yet safe, simulated phishing and password attack campaigns. Run spear-phishing (credential harvest) simulations to train end-users against clicking URLs in unsolicited messages and disclosing credentials.
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 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.
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.
The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Threat actor gains access to account through phishing
Microsoft Defender for Office 365 – A potentially malicious URL click was detected – Email messages containing malicious file removed after delivery – Email messages containing malicious URL removed after delivery – Email messages from a campaign removed after delivery. – Email messages removed after delivery – Email reported by user as malware or phish – A user clicked through to a potentially malicious URL – Suspicious email sending patterns detected
Microsoft Defender XDR – User compromised in AiTM phishing attack – Authentication request from AiTM-related phishing page – Risky sign-in after clicking a possible AiTM phishing URL – Successful network connection to IP associated with an AiTM phishing kit – Successful network connection to a known AiTM phishing kit – Suspicious network connection to a known AiTM phishing kit – Possible compromise of user credentials through an AiTM phishing attack – Potential user compromise via AiTM phishing attack – AiTM phishing attack results in user account compromise – Possible AiTM attempt based on suspicious sign-in attributes – User signed in to a known AiTM phishing page
Defense evasion
Threat actors create an inbox rule post-compromise
Threat actors use AiTM to support follow-on behaviors
Microsoft Defender for Endpoint – Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site
Additionally, using Microsoft Defender for Cloud Apps connectors, Microsoft Defender XDR raises AiTM-related alerts in multiple scenarios. For Microsoft Entra ID customers using Microsoft Edge, attempts by attackers to replay session cookies to access cloud applications are detected by Microsoft Defender XDR through Defender for Cloud Apps connectors for Microsoft Office 365 and Azure. In such scenarios, Microsoft Defender XDR raises the following alerts:
Stolen session cookie was used
User compromised through session cookie hijack
Microsoft Defender XDR raises the following alerts by combining Microsoft Defender for Office 365 URL click and Microsoft Entra ID Protection risky sign-ins signal.
Possible AiTM phishing attempt
Risky sign-in attempt after clicking a possible AiTM phishing URL
Microsoft Security Copilot
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments:
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Advanced hunting
Microsoft Defender customers can run the following advanced hunting queries to find activity associated with Tycoon2FA.
Suspicious sign-in attempts
Find identities potentially compromised by AiTM attacks:
AADSignInEventsBeta
| where Timestamp > ago(7d)
| where IsManaged != 1
| where IsCompliant != 1
//Filtering only for medium and high risk sign-in
| where RiskLevelDuringSignIn in (50, 100)
| where ClientAppUsed == "Browser"
| where isempty(DeviceTrustType)
| where isnotempty(State) or isnotempty(Country) or isnotempty(City)
| where isnotempty(IPAddress)
| where isnotempty(AccountObjectId)
| where isempty(DeviceName)
| where isempty(AadDeviceId)
| project Timestamp,IPAddress, AccountObjectId, ApplicationId, SessionId, RiskLevelDuringSignIn, Browser
Suspicious URL clicks from emails
Look for any suspicious URL clicks from emails by a user before their risky sign-in:
UrlClickEvents
| where Timestamp between (start .. end) //Timestamp around time proximity of Risky signin by user
| where AccountUpn has "" and ActionType has "ClickAllowed"
| project Timestamp,Url,NetworkMessageId
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Login
