Microsoft

As organizations adopt AI, they must secure both cloud and AI environments through a unified security control plane as their attack surface expands. Because modern applications and AI 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 cloud infrastructure, applications, identities, data, and AI systems in one place. 

Modern IT estates now span multiple clouds and on-premises systems, with architectures built on containers, Kubernetes, serverless functions, microservices, APIs, and AI-powered workloads. This increases both the volume and the interconnectedness of security signals. The challenge is no longer identifying individual risks, but determining how misconfigurations, identities, and data exposures combine to create real attack paths, and which of these are most critical to fix at the source. 

KuppingerCole’s Leadership Compass: Cloud Native Application Protection Platforms (CNAPP) reflects this shift. The report describes how CNAPP is evolving from a consolidation of cloud security tools into the security foundation for AI-native enterprises, combining cloud security, AI security posture management, runtime protection, attack path analysis, cloud detection and response, and agentic AI operations into unified platforms.

Read the full report

Within this evolving market, KuppingerCole names Microsoft a Leader across all four of its Leadership categories: Overall, Product, Innovation, and Market. In the report’s words: 

“Microsoft earns its Overall Leadership with its Defender for Cloud that is redefining the CNAPP market by extending cloud security beyond infrastructure protection and into a unified security platform for cloud, data, identity, AI, and security operations, supported by one of the industry’s most advanced agentic AI ecosystems.” 

That recognition reflects where the category is heading: toward platforms that unify cloud and AI security into one operational view of risk. 

Why CNAPP is being redefined 

KuppingerCole makes a clear point: CNAPP is no longer about posture or visibility alone. It is becoming the operational foundation for securing AI-powered applications, services, and business processes, across the full software lifecycle from cloud infrastructure to the AI systems running on top of it.

Modern environments introduce complexity across: 

• Multicloud and hybrid infrastructure. 
• Rapid development and continuous deployment. 
• Containers, serverless, microservices, and APIs. 
• AI models, agents, pipelines, and machine identities. 

This complexity exposes the limits of traditional, siloed tools, where cloud posture, workload protection, AI security, and the security operations center (SOC) each live in their own console. Organizations now need platforms that can: 

• Correlate posture, runtime, identity, data, application, and AI signals. 
• Prioritize risk based on exploitability, not severity alone. 
• Integrate security across development, cloud operations, and the SOC. 
• Bring AI systems into the same risk model as the rest of the cloud. 

Runtime intelligence is now central to this shift. Across the platforms KuppingerCole evaluated, 94% detect active exploitation of the complex attack paths they surface, moving teams from long lists of findings to the exposures threat actors can actually use. 

What distinguishes leading platforms 

KuppingerCole evaluates providers on product strength, innovation, and market presence, and, more importantly, on how effectively they help organizations manage real risk across cloud and AI. Several themes define the next generation of platforms: 

• AI security posture management that governs models, pipelines, and AI-specific attack paths. 
• Agentic AI that investigates, validates exposures, and helps remediate, not just detect. 
• Runtime-driven risk prioritization focused on what is exploitable in production. 
• Security graphs and attack path analysis across identity, data, network, workload, and AI. 
• Convergence of CNAPP with cloud detection and response, integrated with the SOC. 

Taken together, these capabilities represent a move from fragmented visibility to connected, contextual risk management that spans cloud and AI in a single fabric. 

How Microsoft helps organizations manage real risk  1. Connect cross-domain signals to prioritize real attack paths 

Most security tools surface large volumes of findings, but isolated findings do not reflect how cyberattacks actually happen. Microsoft Defender for Cloud uses the Cloud Security Graph and risk-based, multicloud attack path analysis to correlate posture, identity (human and non-human), data, network, and workload signals and identify which risks are truly exploitable. A misconfigured storage resource may look low priority on its own. Exposed to the internet, combined with excessive permissions, and connected to sensitive data, it becomes part of a clear attack path.  

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

Get started with Microsoft Defender for Cloud 2. Secure AI as part of cloud risk, and use AI to run security 

Defender for Cloud brings AI security posture management into the same model as the rest of the cloud, helping organizations validate AI deployment configurations, access controls, model provenance, approved model usage, and identify potential shadow AI risks within supported environments. Through Microsoft Security Copilot and a growing set of specialized security agents, the platform also helps teams investigate, prioritize, guide remediation, and automate workflows.  

What this means: Organizations can govern AI as part of cloud risk rather than in a separate silo, and shift AI from flagging risk to actively helping resolve it. 

3. Reduce complexity from code to cloud to SOC 

As environments scale, fragmented tools make it difficult to understand how risks connect and where to focus first. Defender for Cloud connects code and infrastructure definitions, assesses cloud configurations, protect workloads at runtime, monitor applications and APIs, govern identities, correlate threats across the broader digital estate, and use AI to accelerate investigation and remediation across multicloud and hybrid environments. 

What this means: Security teams can investigate faster, prioritize more consistently, and respond more quickly across fragmented cloud and application environments. 

What this signals for security leaders 

The Leadership Compass offers a signal for where cloud security is headed: toward platforms that connect context across cloud, application, and AI 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 see AI models, agents, and pipelines as part of cloud risk, or is AI a separate tool? 
• Can it prioritize risk based on exploitability, not just severity? 
• Does AI help the team investigate and remediate, or only detect? 
• Can it scale across multicloud and AI environments and reach into the SOC? 

These are the capabilities that define the next generation of cloud-native application protection. 

Bottom line 

KuppingerCole’s 2026 CNAPP Leadership Compass reinforces a clear shift: CNAPP is becoming the control plane for managing risk across cloud, identity, data, applications, and AI. Microsoft’s recognition as a Leader across all four Leadership categories reflects this shift, bringing posture, runtime, identity, data, application, and AI signals into a connected platform that helps organizations prioritize and reduce risk continuously.  

Get the full report Learn more 

• Read KuppingerCole’s Leadership Compass: Cloud Native Application Protection Platforms (CNAPP)  to see how leading vendors are evaluated and how the category is shifting toward securing the AI-native enterprise. 
• Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across cloud and AI can help reduce 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 KuppingerCole Leadership Compass for Cloud Native Application Protection Platforms (CNAPP) appeared first on Microsoft Security Blog.

In this article

1. Activity overview
2. How ClickFix works 
3. Campaign overview
4. ClickFix moved from open pages to fingerprinting gates
5. The fingerprinting gate
6. Mitigation and protection guidance
7. Indicators of compromise (IOC)
8. References
9. Learn more

Microsoft Threat Intelligence observed a macOS ClickFix campaign distributing infostealers, including MacSync and Atomic Stealer (AMOS), through a large cluster of look-alike domains. The campaign evolved from broadly serving ClickFix lures to using a server-side browser-fingerprinting gate that shows the lure primarily to visitors whose environment appears consistent with a genuine macOS browser. This cloaking limits visibility for crawlers, sandboxes, and some automated analysis workflows. The blog details the domain pattern, fingerprinting checks, infection chain, detection coverage, and hunting pivots that defenders can use to identify related activity.

Activity overview

Microsoft Threat Intelligence has been tracking a macOS ClickFix operation that distributes information-stealing malware through a large family of algorithmically named domains. Over several weeks of monitoring, Microsoft observed a notable shift in tradecraft: the same infrastructure moved from openly serving the malicious command in the served page’s HTML source to concealing the lure behind a server-side fingerprinting gate that reveals the payload only to visitors the server assesses as a genuine macOS target. The chain ultimately delivers information stealers such as MacSync or Atomic Stealer (AMOS).

This activity is consistent with the broader shift in macOS ClickFix tradecraft that Microsoft Threat Intelligence previously documented, in which threat actors instruct users to run Terminal commands that retrieve remotely hosted content rather than the traditional approach of delivering a disk image for manual installation. The cluster described here is notable for two reasons: its domains are mass-produced by a recognizable name generator, and it adopted server-side cloaking on existing infrastructure, giving defenders a clear before-and-after view of the same operation.

In this blog, we describe the campaign’s domain-generation pattern, the two delivery phases we observed, the fingerprinting gate that now fronts the infrastructure, and the end-to-end infection chain. We also provide hunting guidance, mitigation recommendations, and defanged indicators of compromise.

How ClickFix works 

ClickFix is a social-engineering technique where attackers persuade users to copy and run a command in Terminal instead of downloading a traditional macOS application. The lure usually appears as a fake verification step, software update, download error, or CAPTCHA, with the command disguised as something required to complete the action. Because execution starts from a user-run Terminal command rather than a downloaded app bundle, the flow can avoid parts of the normal macOS application trust path, including quarantine handling, code-signing evaluation, and notarization checks typically applied to downloaded applications.

In this campaign, ClickFix remains the delivery mechanism, but the important change is that the lure is no longer shown to every visitor. The page first profiles the visitor through a browser-fingerprinting gate and primarily requests consistent with a genuine macOS browser environment receive the fake “Download for macOS” page and copied Terminal command.

Figure 1a – The counterfeit “Download for macOS” page served to a qualifying visitor by a cloaked gate (apricotfilepoint[.]com). The page displays a forged “Verified Publisher” badge and offers a one-click Copy of an obfuscated curl one-liner.

Delivery is conditional. During analysis, the same URLs returned different content to different requests. In some case the macOS ClickFix lure, and in others an apparently benign decoy page.

In our testing, a request presenting a Windows browser received a decoy page such as a fake browser-extension or VPN landing page (Figure 1b) or a page impersonating an unrelated business such as a logistics and freight-forwarding company rather than the ClickFix lure. Because this decision is made server-side on a per-request basis, a given scan or visit may receive benign or decoy content and still be interacting with malicious infrastructure, so an apparently benign or look-alike response does not mean the domain is safe. We examine how the gate evaluates each request later in this post.

Figure 1b – A decoy page (a fake “Urban VPN Proxy” browser extension landing page) returned to non qualifying requests on the same domain (apricotfilepoint[.]com). Campaign overview

The key change in this campaign is not the ClickFix lure itself, but the new layer placed in front of it. Microsoft Threat Intelligence confirmed more than 250 ClickFix front-end domains during the tracking window, and many followed a repeated naming pattern using the token “file” with dictionary-style words, such as filecopperbasket, filevelvettractor, fileoceanhammer, and filemarblegarden.

Some related domains place “file” token in the middle or at the end, such as applefilevault, bananafastfile, and orangesmartfile, while others omit it completely, such as cloudsendhub and syncdatavault. Defenders should treat the naming pattern as a hunting pivot, not a complete signature. The stronger signal is the combination of dictionary-style domains, shared infrastructure behaviour, and the fingerprinting gate that controls who sees the ClickFix lure. This naming pattern is useful for clustering and hunting, but it is not the main story. The more important behaviour is that these domains now serve a browser-fingerprinting gate before showing any malicious content.

ClickFix moved from open pages to fingerprinting gates

In its earlier phase, the campaign’s domains served the lure directly. Retrieving one returned a “complete your download in Terminal” page with the malicious command present in the HTML. A scanner that does not execute JavaScript could recover the entire attack from the page source, including: the macOS paste-to-Terminal instructions, clipboard-write logic, obfuscated shell command, and encoded staging URL. Because the command was embedded in the served page, the domains were readily identifiable from passive data and static content matching.

The same infrastructure that previously exposed its ClickFix lure directly to visitors has evolved to employ a server-side fingerprinting gate. Rather than immediately presenting the malicious content, affected domains now return a minimal page containing only a lightweight JavaScript profiling routine(~2.5 KB size). To both casual visitors and automated scanners, the site may appear blank, inactive, or apparently benign.  In reality, the page serves as an evaluation layer that determines whether a visitor should be shown the ClickFix lure.

Across Microsoft Threat Intelligence’s investigation of this domain cluster, the outcomes were consistent. Simple crawlers received an empty, parked-looking page. JS-capable crawlers and sandbox environments that failed fingerprinting checks were served apparently benign decoy page, and requests presenting a genuine macOS browser fingerprint were shown the ClickFix lure.

Figure 2 – Earlier open-lure delivery compared with the current fingerprinting-gated delivery flow. The fingerprinting gate

The gate profiles each visitor using a combination of browser, hardware, and runtime attributes, which are submitted to the server for evaluation. The following sections break down the categories of signals collected.

Browser profiling and environment collection

The first stage builds a browser fingerprint by collecting browser and page details from six objects exposed to the page: navigator, screen, window, document, location, and console. From navigator, it captures values such as platform, for example, “MacIntel”, user agent, language, vendor, and plugins, which establish the visitor’s claimed device and browser identity.

Display values from screen and window, including screen size, color depth, window dimensions, and pixel ratio, provide consistency signals for whether that identity is consistent with a real, non‑virtualized Mac environment. Page context from document and location, including title, referrer, character set, URL, and host, helps tie the fingerprint to the delivery context. The console object is also enumerated as part of the runtime surface and later helps identify developer tools or automated log-capturing environments. These values are merged into a single fingerprint object tagged with mode: “php” and later submitted back to the server for evaluation.

Figure 3a – The gate collects browser, system, and environment characteristics from multiple browser objects to build a visitor fingerprint. Hardware validation

The gate then performs additional validation to determine whether the visitor resembles a genuine macOS user. One notable check uses WebGL, a browser graphics API normally used to render 2D and 3D content, to retrieve graphics-processing details from the visitor’s device. In this campaign, those WebGL-derived GPU signals help distinguish real Apple hardware from virtualized, emulated, software-rendered, or sandboxed environments before the server decides whether to return the ClickFix lure.

Figure 3b – WebGL-derived GPU signals can help distinguish likely Apple hardware from virtualized, emulated, software-rendered, or sandboxed environments. Environment and behavioral checks

Additional probes evaluate characteristics such as timezone configuration, touch-input support, and whether the page is running inside an embedded frame. These signals help identify uncommon execution contexts that may indicate automated analysis or monitoring infrastructure.

The script records three signals:

• timezoneOffset reads the system’s local timezone offset. Unusual or inconsistent values can contribute to identifying hosted infrastructure, sandbox environments, or otherwise atypical execution context.
• frame checks whether the page is running inside an iframe. While common in legitimate scenarios, embedded execution contexts can also be associated with crawlers, analysis tools, and other automated environments, making this a useful qualification signal.
• touchEvent checks for touch-input support. On desktop macOS systems, touch support is generally uncommon; unexpected touch capabilities can contribute to identifying an emulated, spoofed, or otherwise atypical environment.

Together, these checks help the gate distinguish a normal macOS desktop browser session from framed, headless, mobile, sandboxed, or automated environments before the server decides what content to return.

Figure 3c – Additional checks evaluate environmental attributes that can help differentiate legitimate users from automated systems. Anti-analysis techniques

The gate also incorporates checks designed to detect browser instrumentation, automation frameworks, and modified browser behavior. Rather than simply determining whether a visitor is a bot, these probes appear intended to identify environments commonly used by researchers, crawlers, and security-analysis platforms. The implementation details described here are intended to help defenders recognize and detect gate behavior in malicious traffic-distribution infrastructure.

Figure 3d – The gate performs checks intended to identify browser instrumentation and automated analysis environments.

Two checks stand out. The first is a toString() counter. The script creates a temporary function whose toString() method increases a counter, then writes that function to the console. In a normal browser, this counter usually remains unchanged. However, if the developer console is open, or if a headless or log-capturing tool serializes console output, the function may be converted to a string, causing the counter to increase.

The second is a prototype-tamper probe built around a normal browser capability check. The gate calls canPlayType(“video/mp4”), which normally checks whether the browser supports MP4 playback. Here, that check is repurposed as a tripwire. A genuine browser handles the codec check natively and silently, but some automated or stealth browsers fake codec support in JavaScript. If that JavaScript path calls the hooked Array.prototype.includes, the gate sets the proto:true signal and flags the environment as potentially instrumented or automated.

Fingerprint submission

Once profiling is complete, the collected attributes are packaged and silently submitted back to the same server for evaluation. This process occurs without any user interaction or visible page content.

Figure 3e – Collected fingerprint data is submitted to the server, which determines whether the visitor qualifies to receive the ClickFix lure.

The following is the sample fingerprint the client sends to the server (values are representative and defanged):

Server-side victim selection

With the fingerprinting logic in place, the malicious content is no longer present in the initial page shown to the visitor. Instead, the server withholds the ClickFix lure until it receives and evaluates the submitted fingerprint, then returns one of two responses:

• A bot, crawler, sandbox, virtual machine, unexpected geography, or unexpected browser receives a blank page, a benign decoy, or no content.
• A genuine Mac and browser in an expected context receive the ClickFix lure: the counterfeit “Verified Publisher / Download for macOS” page and its poisoned one-liner. The targeting is primarily environment-based: genuine macOS users in an expected browser and request context receive the ClickFix lure.

This is a Traffic Distribution System (TDS) gate. We call it a TDS because the payload is delivered by server-side, on demand, only to visitors the operator selects security crawlers, researchers, and sandboxes are served no malicious content. This gating can make automated detection and analysis more difficult because those tools may see only an apparently benign response even though the infrastructure can deliver the ClickFix lure to selected macOS visitors.

Figure 4 – Server-side fingerprint evaluation and possible responses for selected and non-selected visitors. Inside the infection chain: from gated lure to AMOS

The individual techniques used by the gate are not inherently malicious or novel. Browser fingerprinting, hardware validation checks, and Traffic Distribution System (TDS)-style visitor filtering are common in anti-abuse systems and have previously appeared in exploit-kit and malvertising ecosystems. What distinguishes this activity is how these techniques are integrated into a ClickFix campaign. Rather than immediately presenting a malicious command, the actor performs server-side victim qualification before revealing the lure, reducing visibility to researchers and automated security systems while maintaining access to intended macOS targets.

Using a qualified macOS target, we analyzed the complete infection chain. The activity began on a file<word><word>[.]com domain hosting the fingerprinting gate, which returned the counterfeit Download for macOS page (Figure 1a). A non-qualifying request received little or no visible content. The page uses GitHub-themed branding to mimic a legitimate software download experience; the branding is spoofed and does not indicate any compromise of GitHub.

When the victim runs the Terminal command, the campaign retrieves and executes a remote script from a /curl/<id> URL. The chain then progresses through multiple script stages before ultimately downloading and launching Atomic Stealer (AMOS), an information stealer that harvests credentials, browser and cryptocurrency wallet data, authentication stores, and other sensitive files before exfiltrating them. We detailed AMOS delivery across multiple macOS ClickFix lures in earlier research.

Because delivery is restricted to qualified visitors, the fingerprinting gate is often a more reliable hunting target than the downstream malware. Systems that inspect page content without executing client-side JavaScript can observe the gate logic directly, while environments that fail qualification are redirected to apparently benign or no content. Because these characteristics also appear in legitimate anti-bot implementations, evaluate combinations rather than single indicators. Useful signals include self-submitting fingerprinting forms, hidden fingerprint data fields, artifacts such as the mode:”php” parameter, and domains following the observed file naming convention; correlating several of these improves confidence and reduces false positives.

Mitigation and protection guidance

Organizations can apply the following recommendations to reduce exposure to this and similar macOS ClickFix campaigns:

• Educate users. Reinforce that no legitimate download, CAPTCHA, or verification step requires pasting a command into Terminal.
• Monitor Terminal usage. Alert on Terminal or shell sessions that spawn curl, base64, gunzip, or osascript, particularly when initiated shortly after web browsing.
• Detect native-tool abuse. Flag unusual sequences of macOS utilities such as curl piped to zsh, base64 -d, and xattr -c immediately preceding chmod +x.
• Inspect outbound downloads. Monitor curl activity that retrieves encoded or compressed payloads from newly registered or low-reputation domains, including /curl/<hex-id> request paths.
• Protect credential stores. Detect unauthorized access to keychain items, browser credential databases, SSH keys, and cryptocurrency wallet data.
• Monitor data staging. Alert on the creation of archives of sensitive artifacts followed by HTTP POST exfiltration.
• Block on infrastructure, not just front-end domains. Where validated, prioritize blocking known shared back end and staging hosts (for example, malware-c2 and the /curl/<id> staging hosts) over individual disposable front-end domains.
• Hunt the generation pattern. Where feasible, alert the file<word><word> domain pattern rather than maintaining a list of individual domains.

On macOS 26.4 and later, Apple introduced a mitigation that displays a warning when a user attempts to paste a potentially malicious command into Terminal, directly addressing the ClickFix delivery mechanism.

When a user attempts to paste a potentially malicious command into Terminal, they will now see the following prompt:

Possible malware, Paste blocked

Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.

Microsoft Defender XDR detections Tactic Observed activity Microsoft Defender coverage  Initial Access Malicious webpage Microsoft Defender for SmartScreen
SmartScreen Detection Blocks webpage (Figure 5) Execution   User copies, pastes, and runs encoded instructions. The instructions are decoded, executable files are created from remote attacker infrastructure, and the malware implant is executed.Microsoft Defender for Endpoint
– Behavior:MacOS/SuspAmosExecution
– Malicious file execution  
– Behavior:MacOS/SuspOsascriptExec
– Malicious osascript execution
– Behavior:MacOS/SuspDownloadFileExec
– Behavior:MacOS/SuspInfoExfil
– Behavior:MacOS/SuspiciousActiviyGen.AE
– Suspicious file download and executionCredential access Keychain extraction Behavior:MacOS/SuspKeyChainCopy.ABCollection & Exfiltration  Browser data, crypto wallets, keys etc.  – Behavior:MacOS/SuspInfostealExec
– Behavior:MacOS/SuspCredCopy
– Behavior:MacOS/SuspPassSteal

Microsoft Defender SmartScreen displays a warning message to Microsoft Edge users when they visit a ClickFix landing page:

Figure 5. Microsoft Defender SmartScreen flagging a ClickFix webpage. Microsoft Security Copilot  

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

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

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

Advanced hunting

The following query is an illustrative starting point. Validate table/column names and adjust the time range and indicators for your environment before running.

Known-IOC network sweep (mirrors a standard IOC hunt; populate from the IOC table and refresh as domains rotate)

let lookback = 30d; let SuspiciousDomains = dynamic(["lemonfilewave.com","limefilescope.com","mangocloudfile.com"]); DeviceNetworkEvents | where Timestamp >ago(lookback) | where RemoteUrl has_any (SuspiciousDomains) Indicators of compromise (IOC) Indicator Type Description applefilevault[.]comDomainClickFix Webpageapricotfilepoint[.]comDomainClickFix Webpage bananafastfile[.]comDomainClickFix Webpagecloudfilebridge[.]comDomainClickFix Webpagefilecedarwallet[.]online.DomainClickFix Webpagefilecopperbasket[.]sbsDomainClickFix Webpagefilecrimsonsignal[.]onlineDomainClickFix Webpagefilemarblegarden[.]sbsDomainClickFix Webpagefileoceanhammer[.]sbsDomainClickFix Webpagefilerubyfolder[.]sbsDomainClickFix Webpagefilevelvettractor[.]sbsDomainClickFix Webpagelemonfilewave[.]comDomainClickFix Webpagelimefilescope[.]comDomainClickFix Webpagemangocloudfile[.]comDomainClickFix Webpageorangesmartfile[.]comDomainClickFix Webpagesyncdatavault[.]comDomainClickFix Webpagecloudsendhub[.]comDomainClickFix Webpage References

• ClickFix campaign uses fake macOS utilities lures to deliver infostealers | Microsoft Security Blog
• Think before you Click(Fix): Analyzing the ClickFix social engineering technique | Microsoft Security Blog
• macOS ClickFix Lures Deploy AppleScript Stealer & Persistent RAT | The Lens blog – netskope – June 17, 2026
• Clickfix Github Themed macOS Infostealer Deliver Campaign IOCs | GitHub gist – brkalbyrk – May 16, 2026
• Atomic macOS Stealer (AMOS): Reading the C2 Protocol from a PCAP | Pcap AI blog – June 23, 2026
• Evil evolution: ClickFix and macOS infostealers | Sophos Blog – March 11, 2026

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 From open lures to cloaked gates: How a macOS ClickFix campaign learned to hide appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. Indicators of compromise (IOC)
4. Microsoft Defender XDR detections
5. Advanced hunting queries
6. Learn more

Microsoft Threat Intelligence identified a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others. The malicious releases contain a Mini Shai-Hulud variant, a self-propagating credential-stealing worm delivered through a large, heavily obfuscated Bun-based JavaScript payload. The malware typically executes automatically through an npm preinstall lifecycle hook before package installation completes.

Once executed, the malware searches developer workstations and continuous integration and continuous delivery (CI/CD) environments for npm, GitHub, cloud, and infrastructure credentials. It uses recovered identities to authenticate to npm, GitHub, Amazon Web Services (AWS), Kubernetes, and HashiCorp Vault, enabling it to enumerate packages, repositories, workflow secrets, cloud parameters, and secret-store values. Collected data is encrypted and transmitted through an attacker-controlled HTTPS endpoint, with GitHub repositories serving as a fallback exfiltration channel.

The payload’s most significant capability is automated propagation. After obtaining an npm publishing token, it enumerates packages available to the compromised identity, downloads their latest tarballs, inserts the malware and setup loader, adds a preinstall hook, increments the patch version, and republishes the modified packages. The malware can also use stolen GitHub credentials to inject Claude and Visual Studio Code configuration files into repositories, establishing persistence and creating an additional developer-to-developer infection path.

In this blog, we’re sharing our analysis of this supply chain attack, along with protection, detection, amd hunting guidance. Organizations that installed an affected package with lifecycle scripts enabled should treat the associated developer workstation or build runner as potentially compromised. Investigations should prioritize credentials accessible to the affected identity, unauthorized npm releases, unexpected repository or workflow modifications, suspicious cloud and secret-store access, and artifacts produced by affected build systems. Organizations should revoke and rotate exposed credentials from a known-clean environment and rebuild affected systems and downstream artifacts from trusted sources.

Attack chain overview

The campaign appeared as a rapid sequence of unauthorized patch releases across more than 400 npm packages maintained by otherwise unrelated publishers. Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release, indicating that the attackers modified and published package tarballs directly rather than compromising each public source repository.

Affected releases typically added a preinstall lifecycle script that launched a malicious file, setup.mjs, contained within the package, which launched the large, obfuscated Bun JavaScript bundle included in the package. Because npm runs preinstall scripts before installation completes, the payload could execute on developer workstations and build runners before application tests or conventional security checks began.

After execution, the malware performs the following actions:

1. Determines whether it is running on a developer workstation or in a CI/CD environment. On workstations, it detaches itself to continue after installation; on CI/CD systems, it remains in the active job to access workflow secrets, runner credentials, and OpenID Connect (OIDC) publishing permissions. Both paths could support further package or repository propagation when suitable credentials are found.
2. Collects credentials from local files, environment variables, command-line tools, and GitHub Actions runner memory.
3. Authenticates to npm, GitHub, AWS, Kubernetes, and HashiCorp Vault to enumerate additional accessible resources and secrets.
4. Encrypts and exfiltrates collected data through an HTTPS channel, using GitHub repositories as a fallback.
5. Uses recovered npm publishing access to modify and republish additional packages.
6. Uses GitHub credentials to inject files into Claude and Visual Studio Code configurations across repository branches for persistence.

The payload’s  package-propagation routine downloads each publisher’s latest release, inserts itself, increments the patch version, and publishes the resulting archive. This mechanism can rapidly transform one compromised npm identity into many malicious package releases.

Figure 1. Attack chain.

0. Initial publisher access

Evidence points towards stolen maintainer credentials as the attack vector for initial compromise. Later propagation used stolen npm publishing tokens and, in targeted workflows, GitHub Actions OIDC publishing access.

1. Payload startup and background execution

 The malicious npm package uses a lifecycle hook to launch its bundle.

During preflight, the payload checks the environment, exits on Russian-language systems, avoids duplicate instances, and starts a detached copy in the background on developer systems.

Figure 2. Platform identification and execution.

In CI environments, the payload remains attached so it can access credentials available to the active build job.

2. Initial credential discovery

The payload first collects information that is immediately available from the local system, shell, and GitHub Actions runner.

Figure 3. Credential discovery.

The shell collector attempts to obtain the GitHub CLI token and captures the values of all process environment variables. The filesystem collector searches credential files, shell histories, cloud configuration, Secure Shell (SSH) keys, and other sensitive locations.

3. Cloud and secret store enumeration

The recovered code then creates dedicated collectors for cloud and infrastructure services.

Figure 4. Credential enumeration.

These modules do not merely scan files for token patterns; they use available credentials to call service APIs, verify access, and retrieve additional secrets permitted to those identities.

The following snippet shows the authentication attempt made using the found credentials:

Figure 5. Credential validation.

4. GitHub credential theft and enumeration

Discovered GitHub tokens are validated before being used for additional collection or repository access.

Figure 6. GitHub credential collector.

The payload checks token scopes, enumerates writable repositories, and identifies repositories where workflow execution could expose additional secrets.

6. GitHub Actions OIDC abuse

The payload also contains a targeted publishing path for GitHub Actions workflows configured as npm trusted publishers.

Figure 7. Re-publishing package using GitHub OIDC token.

Packages published through this route can carry valid provenance because the publication originates from a legitimate workflow identity.

7. Exfiltration and fallback

Collected results are serialized as JSON, gzip-compressed, and encrypted with a randomly generated AES-256-GCM using a randomly generated 32-byte key and 12-byte initialization vector (IV). The AES key is then encrypted with the attacker’s RSA public key using RSA-OAEP-SHA256.

The payload first attempts delivery through an attacker-controlled dynamic HTTPS endpoint. The active domain can change through on-chain contract (0xE1f2395ee43e45A1556EC6438a88c31B83493103, selector 0x53ed5143) or, as a fallback, from a cryptographically verified signed GitHub commit (Signed fallback marker: thebeautifulmarchoftime). If that channel is unavailable, it creates a public GitHub repository with the description Shai-Hulud: Here We Go Again.

Encrypted results are committed as files such as: results-<timestamp>-<counter>.json.

At the time of analysis, the live contract returns npm-cache[.]com. Earlier candidates include pypi-get[.]com and js-mirror[.]com.

Figure 8. Exfiltrating stolen information.

In one fallback path, a stolen GitHub token is added separately using double Base64 encoding. This token field is encoded, not encrypted.

8. Repository persistence and secondary spread

The payload can use stolen GitHub credentials to inject the malware and supporting setup files into eligible repository branches. The recovered code targets Claude and Visual Studio Code configuration paths, including .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and .vscode/setup.mjs.

These changes create a secondary infection route: future Claude or Visual Studio Code activity can restart the payload even after the original npm installation has completed. In a conditional GitHub fallback path, the payload also attempts to install a token-monitor component that maintains credential access and contains a destructive handler if the monitored token is revoked.

Figure 9. Injecting the malicious code into development ecosystems.

9. Worm behavior: Package modification and publication

The npm tokens found in collected data are checked for package-write permission and two-factor authentication (2FA)-bypass capability.

Figure 10. Republishing the package using stolen NPM token. Figure 11. Malicious update to existing package and republishing.

The propagation routine downloads a package’s latest tarball, copies the current malware bundle into it, adds a loader, and replaces its lifecycle scripts. This creates the worm-like propagation pattern: one stolen token can produce malicious patch releases across every package available to that publisher. This also explains why malicious releases frequently appeared as an otherwise ordinary patch-version increment without corresponding source commits or pull requests.

Mitigation and protection guidance

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

• Update npm CLI to npm CLI v11.10.0+  and use the npm CLI min-release-age feature.
• Review dependency trees, lockfiles, artifact repositories, and CI caches for the five compromised versions, including transitive references.
• Pin known-good package versions.
• Purge npm and yarn caches on affected developer endpoints and build hosts, especially if the compromised tarballs were written into shared CI caches.
• Rotate credentials and secrets from a clean host if a build system or workstation imported a compromised version, because second-stage execution can expose tokens and compromise build integrity.
• Ensure that Microsoft Defender Antivirus cloud-delivered protection, Microsoft Defender for Endpoint telemetry, Microsoft Defender for Containers, and Microsoft Defender XDR investigation workflows are enabled across developer and CI assets.
• Organizations that produce software artifacts should also review their own release hardening because this incident appears consistent with CI/CD pipeline abuse through GitHub Actions OIDC publishing. Defenders should review token scopes, workflow approvals, protected environments, release provenance, and anomaly detection around automated package publication. Supply chain response cannot stop at host triage; it must also include verification that the release process itself has not been subverted.
• After remediation, validate recovery deliberately. Rebuild affected projects from a known-good dependency baseline, confirm that compromised hashes are absent from package caches and artifact stores, and review endpoint telemetry for any lingering NodeJS directory artifacts such as Math_Symbol.js, Math_init.js,  or names similar to math_<guid>.js, or suspicious node child processes. For development organizations that share base images or golden build runners, rebuild those images as well so future jobs do not silently inherit poisoned caches or post-compromise persistence.

Indicators of compromise (IOC) IndicatorDescription54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668  setup.mjs (npm tarball preinstall loader)fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb  setup.mjs (.claude and .vscode repository loader) 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bccMath_*.jsnpm-cache[.]comC2 domainpypi-get[.]comC2 domainjs-mirror[.]comC2 domainhxxps[:]//npm-cache[.]com:443/routerC2 URL Microsoft Defender XDR detections

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

TacticObserved activityMicrosoft Defender coverageInitial access / ExecutionMalicious files embedded in compromised npm packages execute the embedded payload automatically through a malicious preinstall lifecycle hook.Microsoft Defender Antivirus
– Trojan:NPM/ShaiLoader.BY
– Trojan:NPM/MalBun.A
– Trojan:NPM/ShaiWorm.DAY!MTB

Microsoft Defender for Endpoint
– Suspicious Node.js process behavior
– Suspicious Node.js script executionExecution / Defense evasionThe preinstall loader launches a heavily obfuscated Bun-based JavaScript payload designed to hinder analysis and evade Node.js-focused monitoring.Microsoft Defender Antivirus
– Behavior:Linux/SuspBunActivity.A
– Behavior:Win32/SuspBunActivity.A

Microsoft Defender for Endpoint 
– Suspicious usage of Bun runtime
– Suspicious installation of Bun runtime
– Suspicious Node.js process behavior
– Suspicious script execution via Bun
– Suspicious Node.js script execution  

Microsoft Defender for Cloud
– Suspicious npm supply-chain compromise activity detectedCredential access / CollectionThe malware searches developer workstations and CI/CD environments for npm, GitHub, cloud, Kubernetes, and secrets.Microsoft Defender for Endpoint
– Credential access attempt
– Suspicious cloud credential access
– Enumeration of files with sensitive data
– Suspicious access of sensitive files  

Microsoft Defender for Cloud
– Sha1-Hulud Campaign Detected: Possible command injection to exfiltrate credentials Advanced hunting queries

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

Execution of the preinstall script

DeviceProcessEvents | where Timestamp > ago(3d) | where FileName in~ ("node", "node.exe") | where ProcessCommandLine in~ ("node setup.mjs", "node setup.mjs") CloudProcessEvents | where Timestamp > ago(3d) | where FileName in~ ("node", "node.exe") | where ProcessCommandLine in~ ("node setup.mjs", "node setup.mjs")

Execution of second-stage JavaScript using Bun runtime

DeviceProcessEvents | where Timestamp > ago(3d) | where InitiatingProcessFileName in~ ("node", "node.exe") | where InitiatingProcessCommandLine in~ ("node setup.mjs", "node setup.mjs") | where FileName in~ ("bun", "bun.exe") | where FolderPath contains "bun-dl-" or ProcessCommandLine has "node_modules"

Malicious JavaScript from malicious packages

DeviceFileEvents | where Timestamp > ago(3d) | where SHA256 in~ ("9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc", "fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb", "54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668")

Credential access by malicious JavaScript

DeviceProcessEvents | where Timestamp > ago(3d) | where ProcessCommandLine has_any ('gh auth token', 'gcloud config config-helper', 'az account get-access-token', "azd auth token") | where InitiatingProcessFileName in~ ("bun", "bun.exe") | where InitiatingProcessFolderPath contains "bun-dl-" or InitiatingProcessCommandLine has "node_modules" Microsoft Security Copilot

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

For this campaign, Security Copilot can help analysts summarize affected devices, pivot from the package hashes to endpoint evidence, identify hosts that communicated with the IPFS path or C2 infrastructure, and build remediation actions such as cache purge, credential rotation, and containment sequencing for impacted developer systems and build runners.

Threat intelligence reports

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

As with other active supply-chain investigations, defenders should monitor for updated intelligence on package status, additional affected versions, infrastructure changes, and newly surfaced post-compromise tradecraft. Microsoft will continue to incorporate validated indicators and detections into Microsoft security products as the investigation evolves.

Learn more

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

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

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

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

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

The post ChainDrop supply chain compromise: Anatomy of a self-propagating worm appeared first on Microsoft Security Blog.

The calculus of cybersecurity has changed. AI is reshaping how organizations build, deploy, operate, and defend digital systems. AI-powered development tools, agents, and autonomous workflows are accelerating innovation but they are also introducing new attack surfaces, new trust boundaries, and new security challenges.

Microsoft has long helped organizations secure their digital estates using Zero Trust principles. That leadership was recently recognized by KuppingerCole analysts, which named Microsoft as the Overall Leader in its Zero Trust Platform Leadership Compass, ranking Microsoft highest for both product and innovation leadership.

Learn more about Zero Trust for AI

As organizations accelerate AI adoption, secure software development becomes more important than ever. That’s why we are expanding the Zero Trust for AI strategy with two major additions: a new AI-focused Zero Trust Assessment experience and a new DevSecOps pillar in the Zero Trust Workshop. Together, they help organizations get ready for AI by assessing exposure, risks, prioritizing remediation, and securing AI-enabled development from source code to deployment.

• Zero Trust Assessment tool updates: New set of assessment checks for AI, Security Operations (SecOps), and Infrastructure.
• Zero Trust Workshop updates: New dedicated pillar focused on Developer Security (DevSecOps) and additional guidance for AI Memory.
• New guidance: New practical guidance for security practitioners and a new e-book titled Zero Trust for AI, rebuilding security controls for autonomous and agentic systems.

This builds directly on the Zero Trust for AI strategy announced at RSA Conference 2026 and moves the conversation from architecture to implementation. If that announcement was about establishing Zero Trust for AI, this one is about operationalizing it: giving security, engineering, and platform teams the specific controls they need to act.

To learn more about our work in applying Zero Trust for AI and agents watch this Microsoft Mechanics video:

const currentTheme = localStorage.getItem('blogInABoxCurrentTheme') || (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'); // Modify player theme based on localStorage value. let options = {"autoplay":false,"hideControls":null,"language":"en-us","loop":false,"partnerName":"cloud-blogs","poster":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/image\/microsoftcorp\/1120798-ZeroTrustSecurityForAIAgents_tbmnl_en-us?wid=1280","title":"","sources":[{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1120798-ZeroTrustSecurityForAIAgents-0x1080-6439k","type":"video\/mp4","quality":"HQ"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1120798-ZeroTrustSecurityForAIAgents-0x720-3266k","type":"video\/mp4","quality":"HD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1120798-ZeroTrustSecurityForAIAgents-0x540-2160k","type":"video\/mp4","quality":"SD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1120798-ZeroTrustSecurityForAIAgents-0x360-958k","type":"video\/mp4","quality":"LO"}]}; if (currentTheme) { options.playButtonTheme = currentTheme; } document.addEventListener('DOMContentLoaded', () => { ump("ump-6a723060e32fa", options); }); New AI pillar in Zero Trust Assessment tool

The Zero Trust Assessment provides an automated view of security posture by evaluating tenant configuration and activity signals across the environment and translating those findings into prioritized recommendations. As organizations adopt AI agents, Copilots, developer tools, and autonomous workflows, the Assessment helps security and platform teams establish a baseline, measure progress, and identify gaps across both traditional and AI-powered environments. It now includes expanded coverage with new pillars for AI, Security Operations, and Infrastructure (in addition to existing Identity, Devices, Network, and Data pillars), with Zero Trust for AI-focused checks that help organizations evaluate the controls required for secure AI adoption.

Additionally, enhanced reporting delivers both practitioner-level guidance and executive-ready summaries that communicate risk, progress, and next steps. Results map directly into the Zero Trust Workshop’s First, Then, Next framework, transforming assessment findings into a prioritized roadmap for remediation and implementation. Together, the Assessment and Workshop help organizations move from understanding risk to executing a structured plan for continuous improvement across their Zero Trust and AI security journey.

Explore the Zero Trust Assessment updates What’s New in the Zero Trust Workshop

AI is fundamentally changing software development. Developers increasingly rely on AI assistants to generate code, recommend packages, create infrastructure configurations, and automate testing. While these capabilities accelerate delivery, they also amplify the consequences of governance gaps, excessive permissions, insecure dependencies, and compromised supply chains.

That is why Microsoft is introducing a new DevSecOps pillar (with 15 control groups and 91 tasks that help teams apply Zero Trust from source code to cloud deployment) in the Zero Trust Workshop. The pillar translates the three Zero Trust principles—verify explicitly, use least privilege, and assume breach—into practical guidance and controls for developer platforms, continuous integration and continuous delivery (CI/CD) pipelines, source repositories, dependencies, artifacts, and infrastructure-as-code.

The Zero Trust Workshop also improves the AI pillar to include guidance based on the Microsoft AI Memory framework, helping teams treat memory as a governed security boundary with clear intent, provenance, lifecycle visibility, and user control.

See the updates in the Zero Trust Workshop How to run Zero Trust Workshop

The Zero Trust Workshop follows a simple three-step motion: plan the right pillars and stakeholders, run the Zero Trust Assessment to establish a baseline, and use the facilitated workshop to turn findings into a 12- to 24-month roadmap.

Tasks are organized into First, Then, Next phases so teams can start with foundational controls and build momentum. The new DevSecOps pillar also highlights cross-pillar work that strengthens Identity, Infrastructure, and Security Operations, plus four tasks focused directly on AI-assisted development: code governance, tool allowlisting, data protection, and AI and machine learning pipeline supply-chain security.

Get practical guidance in the new Zero Trust for AI e-book

To help organizations navigate this shift, Microsoft recently published Zero Trust for AI: Rebuilding security controls for autonomous and agentic systems, a practical guide that applies Zero Trust principles to AI agents, tools, memory, data, and runtime operations. The e-book provides security leaders, architects, and practitioners with a framework for evaluating AI risks and implementing controls that scale with AI adoption.

Zero Trust for AI e-book

Practical guidance for securing AI systems.

Get the e-book

Knowing what to do is one thing. Knowing how to operationalize it at scale is another. Our patterns and practices provide repeatable, proven approaches to the most complex AI security challenges, much like software design patterns offer reusable solutions to common engineering problems.

The table below highlights our practical recommendations aligned with Zero Trust principles to help practitioners translate strategy into concrete implementation.

Pattern and Practice GuidanceWhat it coversLeast privilege for AI agentsGuidance on applying Zero Trust to AI agents.Zero Trust for source code accessGuidance on building Zero Trust protections for source code security.Manage memory safety in agentic systemsGuidance for treating AI memory as a governed security boundary.Protect the software supply chainGuidance for applying Zero Trust across the software development lifecycle.Security adoption guidance for developmentGuidance on building secure development programs and governance. How can partners help?

Partners can use the Zero Trust Assessment tool and Workshop to turn broad security interest into a focused, outcome-driven customer engagement. The Assessment tool helps establish a baseline across one or more Zero Trust pillars, including AI and DevSecOps scenarios, so customers can see where they are today and where to prioritize first. The Workshop then translates those findings into an executive summary, prioritized recommendations, and a phased roadmap. For customers, this creates a clear path from risk visibility to practical action plans that partners—as trusted advisors—can help prioritize and execute.

Learn how Microsoft partners deliver the Zero Trust Workshop through Frontier Accelerate for Security: Envisioning and POC.

Customer success stories

Ford Motor Company: Microsoft Security solutions offered Ford a unified, AI-powered platform to detect, address, and prevent cyberthreats across its hybrid environment. Grounded in a Zero Trust architecture, every access request—whether from users, devices, or applications—is continuously verified. This principle guided Ford’s approach to securing its hybrid environment, reinforcing protection before expanding visibility. Read more about how Ford builds trust across global operations.

The Microsoft security stack is more than technology. It contributes to Ford’s business in moving faster against cyberthreats and building a more secure future.”

—Weston Maggetti, Platform Manager, Ford Motor Company

SEB Group: SEB based its Zero Trust journey on identity, deploying Microsoft Entra ID and Microsoft Defender for Identity. It removed online identity exposure with Windows Hello for passwordless access, and extended protection with Microsoft Defender for Endpoint. Read more about how SEB implements Zero Trust.

Our Microsoft Security solutions are vital to our Zero Trust journey. That enhanced visibility helps to keep our SaaS (software as a service) landscape as simple as possible so that it’s easier to defend.”

—Ulf Larsson, Security Chief Technology Officer (CTO), SEB Group

Get started

To get started, use the Assessment and Workshop together to turn Zero Trust for AI into a practical implementation plan:

• Use the Zero Trust Assessment tool to establish a baseline and prioritize the Workshop roadmap across Identity, Devices, Data, Infrastructure, and Network.
• Run the Zero Trust Workshop with the new DevSecOps pillar to secure developer platforms, pipelines, code, and artifacts.
• Complement your Zero Trust journey by assessing your posture and acting where attackers strike most. SecureNow, in Microsoft Security Exposure Management, helps you improve security across patching, open-source software, source code, internet-facing assets, and hygiene.

Get started with a Zero Trust strategy

Learn more about Microsoft Security solutions on our website and bookmark the Microsoft Security blog for expert insights on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest cybersecurity news and updates.

The post Advance Zero Trust for AI: New tools and guidance to secure AI agents and DevSecOps appeared first on Microsoft Security Blog.

In this article

1. What is device isolation?
2. Case study: QNET
3. Attack chain overview
4. MITRE ATT&CK techniques observed
5. References
6. Learn more

Microsoft Defender’s attack disruption now includes device isolation, a new response action that extends autonomous protection directly to compromised endpoints.

At QNET, an attacker initiated a multi-stage attack using a legitimate Windows tool on a compromised endpoint to retrieve a malicious remote payload–a classic living-off-the-land (LOL) technique that often evades traditional containment. By automatically enforcing the new device isolation action on the compromised endpoint, Defender attack disruption stopped the attack dead in its tracks. From the first high-severity alert to completed isolation, after only 128 seconds, Defender cut off the attack chain before the second-stage payload could establish persistence or move beyond the host.

The growing threat: when the endpoint is the blast radius

Attack disruption has proven highly effective at stopping multistage, cross-domain attacks by disrupting the attacker’s ability to move across the environment. In many identity-driven attack scenarios, containing the compromised user is enough to shut down the attack chain, preventing lateral movement and limiting the attacker’s ability to access additional systems, identities, and resources.

However, we are increasingly seeing a different class of high-severity incidents that begin with initial access directly on the device. Once adversaries establish a foothold on an endpoint, they can plant multiple persistence mechanisms and continue operating locally on the machine. This means that acting against the user’s identity alone is no longer enough to dismantle the threat.

In these scenarios, the attacker has multiple ways to communicate and operate on the device beyond the user entity; the malicious code is already executing locally on the machine. The attacker doesn’t have to move laterally immediately; they can establish persistence, steal credentials, inject into processes, and prepare follow-on stages directly from the compromised endpoint itself.

Previously, stopping these attacks required manual triage and response, giving attackers time to advance. Device isolation closes this gap by automatically correlating signals, assessing the threat, and isolating the compromised device within seconds.

Traditional response approaches often depend on static playbooks triggered by individual alerts and maintained through manual tuning. Attack disruption instead uses AI-driven correlation and real-time analysis to identify multi-stage attacks by connecting signals across the environment before taking action. Device isolation is enforced only when the disruption pipeline reaches a high-confidence verdict—a threshold maintained at 99% precision.

What is device isolation?

When Microsoft Defender determines with high confidence that an endpoint is compromised, it isolates the device to immediately stop attacker activity and reduce the risk of further impact, such as data exfiltration and lateral movement.

What happens during device Isolation

When a device is isolated, all external network connectivity is blocked while maintaining access to required security services like Microsoft Defender for Endpoint. Selective isolation is supported, allowing customer-defined services or exclusions to continue functioning.

Automatic device isolation is scoped to the affected device (supported today on onboarded MDE workstations), time-limited, and operator-controlled. Security teams can review context, take follow-up actions, and manually release isolation when it’s safe to do so.

Why it matters

Device isolation is a powerful containment control because it disrupts the attack regardless of how the device was compromised or what the attacker planned to do next. A single action cuts off network access, breaking lateral movement, command and control, credential theft, and rapid encryption–effectively stopping hands-on activity and preventing spread to other systems. It is designed to work hand in hand with user containment. Isolating only the device or only the user leaves gaps; together, each one makes up for the weaknesses of the other, thereby mitigating these gaps to more effectively contain the attack.

Case study: QNET

QNET is a global direct-selling company with a distributed workforce and a lean security operations center (SOC). Like most teams of its size, QNET runs Defender with attack disruption enabled and relies on it to handle the first five minutes of a high-severity incident so analysts can focus on finding the root cause.

In the incident detailed here, attack disruption proved decisive: it stopped a multi-stage attack on a single endpoint within 128 seconds by automatically enforcing device isolation, its newest disruption action. Without this autonomous disruption, the human-in-the-loop delay could have been the difference between a contained initial living-off-the-land binary (LOLBin) execution and a fully detonated second-stage payload that had achieved credential theft and persistence.

In the customer’s words

“At QNET, we’ve seen a real impact from Microsoft’s attack disruption capability. During a recent incident, the device isolation was triggered almost immediately, which gave us confidence that the threat was contained early before it had any chance to spread.

What stood out for us is how this changes the way the team operates. Instead of racing against time to investigate and contain an active threat, my team can step in knowing the situation is already under control. That shift allows us to focus more on root cause analysis and remediation, rather than spending critical time trying to piece together what’s happening while the risk is still ongoing.

From a day-to-day SOC perspective, it makes our response more efficient and far less reactive. The alerts are clear, the actions are meaningful, and the disruption happens early enough to actually make a difference, not after the damage is done.

Overall, it’s helped us streamline our incident response and reduce exposure, while giving the team more breathing room to focus on what really matters.”

—  Ben Bredenkamp, Group CIO, QI Group

Attack chain overview 08:30 – 09:22BaselineA user opened a malicious file, likely delivered through email or browser download. The file executed mshta.exe, a legitimate Windows utility commonly abused by attackers. The mshta.exe process contacted an attacker-controlled URL and retrieved a second-stage payload. Persistence artifacts were then prepared (RunMRU activity was observed shortly afterward).09:23:20Initial Access / ExecutionThe malicious second stage executed through mshta.exe, establishing code execution on the device. Observed activity included suspicious command execution and user-level persistence behavior (RunMRU registry interaction).  09:23:20DetectionTwo independent Defender detection engines triggered within the same second:

– Behavioral/execution-based detection flagged suspicious command activity (RunMRU abuse).

– The correlation engine identified the activity pattern as malicious and consistent with real attack behavior (not benign tooling usage).  09:25:02Disruption decisionThe disruption pipeline correlated the alerts, evaluated the threat model (single endpoint, no lateral movement signs, malicious code already executing under user context), and selected device isolation as the action most likely to immediately contain the attack.  09:25:16Playbook startDefender autonomously initiated the IsolateDevice response playbook – the same containment action a SOC analyst would trigger manually – with full audit logging and a built-in auto-release mechanism to prevent prolonged business impact.  09:25:28Device isolatedThe IsolateDevice action completed successfully. The endpoint was cut off from all external and internal network communication, allowing only Defender management traffic. Communication with attacker-controlled infrastructure was immediately terminated.  09:25 – onwardPost-isolationNo additional malicious activity was observed. The mshta-launched payload was unable to continue execution, retrieve additional stages, or establish persistence. With no lateral movement or follow-on activity, the incident remained fully contained to a single endpoint. The SOC inherits a contained incident.  

Total time from first detection to enforced isolation: 128 seconds.

The results

To summarize the results of the new device isolation response action:

• From first detection, Defender isolated the device in just 128 seconds.
• No second-stage payloads were observed after isolation. The mshta process was orphaned at the network layer; there was no outbound C2, and no follow-on download.
• No lateral movement attempts were observed before or after isolation.
• No SOC actions were required during the disruption window. The QNET SOC analyst who picked up the incident inherited an already-contained host and a complete action timeline.

MITRE ATT&CK techniques observed TacticTechnique IDTechnique nameObserved detailsInitial Access / ExecutionT1204.002User Execution: Malicious FileUser opened a malicious file delivered via browser download or email, resulting in execution of mshta.exe at approximately 09:23:20 UTC on device a3198469…b13.Defense EvasionT1218.005System Binary Proxy Execution: MshtaSigned Microsoft binary mshta.exe was abused to proxy execution of attacker-controlled HTA/script content and evade application trust controls.Command and ControlT1071.001Application Layer Protocol: Web Protocolsmshta.exe initiated outbound HTTP/HTTPS communication to attacker-controlled infrastructure to retrieve a second-stage payload.ExecutionT1059Command and Scripting InterpreterHTA-delivered script content executed through the mshta.exe host process, enabling attacker-controlled command execution in user context.PersistenceT1112Modify RegistrySuspicious RunMRU-related registry interaction indicated attempted user-level persistence preparation.Discovery / ExecutionT1057Process DiscoveryDefender behavioral detections observed suspicious command activity consistent with attacker reconnaissance and execution staging immediately after payload launch.Impact Mitigation (Defender response)–Device Isolation (Defender Automatic Attack Disruption)Defender correlated multiple high-confidence detections and autonomously executed the IsolateDevice response action at 09:25:16 UTC, completing isolation by 09:25:28 UTC.Command and Control (Prevented)T1105Ingress Tool TransferIsolation interrupted outbound connectivity before additional payload stages or tooling could be retrieved from attacker infrastructure.Lateral Movement (Prevented)TA0008Lateral MovementNo evidence of lateral movement activity was observed before containment; device isolation prevented any subsequent propagation opportunities.Persistence (Prevented)TA0003PersistenceAfter isolation, no additional persistence artifacts or follow-on malicious processes were observed on the endpoint. References

• Automatic attack disruption in Microsoft Defender XDR
• Automatic attack disruption — supported triggers and enforced actions
• Device Isolation in Attack Disruption
• MITRE ATT&CK T1218.005 — Mshta
• MITRE ATT&CK T1204 — User Execution

Learn more

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

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

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

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

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

The post 128 Seconds to disruption: Microsoft Defender stops ransomware at QNET  appeared first on Microsoft Security Blog.

In this article

1. The CaptiveCrunch campaign
2. Storm-2945 and Midnight Blizzard
3. CaptiveCrunch tradecraft and tooling
4. How to protect against CaptiveCrunch activity
5. Microsoft Defender detections and hunting guidance
6. Indicators of compromise

Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945, a sub-cluster of Midnight Blizzard, conducting widespread but targeted traffic manipulation attacks involving hospitality sector networks served by captive portals worldwide. Despite some tactic, technique, and procedure (TTP) similarities to the Forest Blizzard DNS hijacking operation that we publicly disclosed in April 2026, we attribute this campaign, which we call CaptiveCrunch, to Storm-2945. As reported by ReliaQuest on July 23, a portion of this activity leverages doppelganger domains mimicking Microsoft online services to conduct follow-on adversary-in-the-middle (AitM) phishing operations that abuse the device code authentication flow in Microsoft Entra ID. Microsoft Threat Intelligence has also identified active traffic manipulation attacks leading to the delivery of malware on impacted systems. Microsoft has observed Storm-2945 leveraging AI to support a significant portion of these operations.

Today, we are sharing our findings on these ongoing intrusions to raise awareness of this threat and enable customers to protect their devices, especially while traveling. We provide our assessment of Storm-2945’s relationship to Midnight Blizzard and analysis of the CaptiveCrunch campaign, detailing the malware and tradecraft used in these operations. We also provide mitigation, detection, and hunting guidance to help organizations identify and defend against Storm-2945 and related activity.

Microsoft Threat Intelligence would like to thank our partners at Anthropic and OpenAI for their collaboration and support during this investigation.

The CaptiveCrunch campaign

Since February 2026, Storm-2945 has conducted AI-augmented operations including targeted device code and OAuth code phishing campaigns leading to Entra device registration and subsequent data collection from Microsoft 365. Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945 manipulating DNS and HTTP traffic from networks served by captive portals to redirect user traffic through actor-controlled infrastructure. Although our investigation into the initial compromise vector for the captive portal networks is ongoing, we have observed notable commonalities in the equipment and management systems used across multiple affected networks. These similarities suggest that the activity might not be limited to isolated compromises of individual venues and could reflect access to shared services within portions of the captive portal ecosystem.

Figure 1. Overview of the CaptiveCrunch attack flow

As part of the CaptiveCrunch campaign, Storm-2945 has leveraged their AitM position to redirect users through actor-controlled phishing infrastructure and has also delivered malware purporting to be browser or operating system updates in response to automated connectivity checks issued by users’ browsers. Multiple variants have been delivered, including fully-featured Windows remote access trojans (RAT) in compiled Golang, with functionality to conduct system enumeration, collect files and keystrokes, steal credentials and session tokens, conduct audio and video surveillance, monitor for removable media, and provide the threat actor a remote shell on infected systems.  

The threat actor infrastructure leverages a variety of ClickFix techniques to elicit the user into downloading and executing the malware:

Figure 2. ClickFix prompt with manual user instructions Figure 3. ClickFix prompt with additional user instructions after verification failure

In addition to variants of malware targeting Windows systems, Microsoft Threat Intelligence is also aware of indications that the threat actor might be targeting Android devices with similar techniques as the ClickFix landings also include instructions for Android devices to download and install an APK file.

To date, Microsoft has identified widespread compromise of Wi-Fi networks at hospitality-related organizations and other networks serviced by captive portal equipment in several countries. ReliaQuest has identified this activity not only at hotels, but also conference centers and other shared venues, and assesses that the goal of this activity is to access the accounts of corporate travelers.

Storm-2945 and Midnight Blizzard

Microsoft Threat Intelligence assesses that Storm-2945 is an operational sub-cluster of Midnight Blizzard based on distinctive technical and operational overlaps. These include technical similarities to Storm-2372, a Midnight Blizzard initial access operations sub-cluster, also notable for their device code and OAuth code phishing operations tracked throughout 2025, Microsoft Graph-based email exfiltration, social engineering delivered via commercial messaging apps, and significant similarities in victimology.

Midnight Blizzard is a Russia-based threat actor attributed by the US and UK governments to the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs), and information technology (IT) service providers, primarily in the US and Europe. Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. Their focus is to collect intelligence through longstanding and dedicated espionage in support of Russian foreign policy interests.

Midnight Blizzard operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection. They utilize diverse initial access methods, and Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection.

CaptiveCrunch tradecraft and tooling CornFlake: Remote access and infostealer implant

CornFlake is a full-featured Windows RAT written in Go that serves as Storm-2945’s primary persistent implant. Microsoft has observed the threat actor rapidly iterating on this malware layer, which features customizable capabilities from the social engineering user interface and data collection capabilities to anti-detection and evasion techniques.

On initial execution, CornFlake operates in dropper mode: it displays a convincing fake progress window designed to occupy the victim’s attention while the binary copies itself to %APPDATA%\svchost32\svchost32.exe and establishes persistence.

Fake window options configurable by the threat actor at build time:

• winupdate — A Windows Update screen displaying “Working on updates… Don’t turn off your computer”
• defender — A Windows Security virus scan
• directx — A DirectX End-User Runtime Web Installer
• vcredist — A Microsoft Visual C++ 2015-2022 Redistributable installer
• sysopt — A disk optimization utility
• netfix — A Windows Network Diagnostics tool
• browser — A browser update prompt
• pdfview — A document viewer installer

Figure 4. False update window

CornFlake registers as a Windows service named svchost32 with the display name “Cloud Sync Service” and description “Synchronizes files with the cloud storage provider”, deliberately mimicking the legitimate svchost.exe process. It establishes redundant persistence mechanisms: Windows service registrations, Registry Run keys, named scheduled tasks, and a persistence watchdog routine that runs continuously to restore any persistence mechanism that is removed by defenders or endpoint protection.

For command and control (C2), CornFlake performs an Elliptic Curve Diffie-Hellman (ECDH) P-256 ephemeral key exchange with the C2 server, derives a session key via SHA-256, and communicates over a custom JSON protocol framed within the encrypted channel. This provides an encrypted channel to the C2 server, with each C2 session using a unique ephemeral key, making decryption of captured traffic impossible without the session-specific private key. The runtime configuration file sync.dat supports hot reconfiguration of C2 servers, watched directories, file targeting patterns, and Transport Layer Security (TLS) settings without requiring redeployment.

Once established on a victim system, CornFlake provides the operator with a comprehensive collection toolkit, gated by configuration flags that allow selective activation post-deployment:

CapabilityDescriptionKeyloggingRaw input API-based keylogger capturing all keystrokes, including password fieldsClipboard monitoringCaptures clipboard changes with SHA-256 deduplication and records the active window title at time of captureScreenshot captureIdle-triggered and on-demand screenshots with configurable idle thresholdAudio surveillanceWindows Audio Session API (WASAPI)-based microphone capture, encoded as WAV filesVideo surveillanceMedia Foundation-based webcam capture, encoded as JPEGBrowser credential theftChromeKatz-derived module supporting live cookie extraction from process memory (Chromium browsers) and stored password extraction from on-disk databases, including Chrome App-Bound Encryption (ABE) bypass and Firefox NSS/SDR decryptionFile exfiltrationTargets files based on file extensions with real-time file system monitoring and an upload throttle (1,000 files or 500 MB per cycle). File extensions are categorized as Documents, Archives, Images, Code, Data, Emails, and KeysUSB drive monitoringDetects and scans removable media when insertedSecurity posture sweepCollects 18 categories of host intelligence including installed software, antivirus (AV)/endpoint detection and response (EDR) products, Defender exclusions, User Account Control (UAC) level, Remote Desktop Protocol (RDP) history, Office most recently used (MRU) files, and credential hintsRemote shellArbitrary command execution via cmd.exe or PowerShell (with -NoP flag to suppress profile-based detection)

CornFlake also exposes a localhost HTTP API server (/upload, /reload, /status) that transforms the RAT into a modular platform: companion or next-stage payloads such as ChocoShell could task file exfiltration, trigger configuration hot reloads or check C2 connectivity using the pre-established secure C2 channel for communication.

ChocoShell: PowerShell infostealer

ChocoShell is the campaign’s Powershell-based infostealer, delivered and executed entirely in-memory. Its primary objective is the high-volume theft of browser session cookies, saved passwords, Microsoft 365 Single Sign-On (SSO) tokens, and Wi-Fi credentials from compromised systems. Where CornFlake provides the operator with a persistent, long-running foothold on the device, ChocoShell is designed to extract the most operationally valuable credentials, giving the operator access to victim cloud environments.

The ChocoShell script was authored with full developer comments that reveal the operator’s intent behind each code decision, including explicit references to Microsoft detection signatures and the reasoning behind specific evasion choices. The consistent coding standard and descriptive commentary suggest the author might have leveraged AI-assisted code generation.

Defense evasion. Upon execution, ChocoShell beacons to a hardcoded C2 server at 213.145.86[.]112 and implements several evasion techniques in sequence. It disables the Antimalware Scan Interface (AMSI) via .NET reflection to prevent ScriptBlock scanning and evades Microsoft behavioral detection that triggers on suspicious PowerShell web request cmdlets. A timing-based sandbox detection check is also employed as a virtual machine (VM) detection mechanism, silently exiting without performing any collection if detected.

C2 communication. ChocoShell communicates with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel. Additional tooling is fetched from /cdn/chunks/polyfill-7e2b.min.js, disguised as a JavaScript polyfill file. This downloaded module is Base64-decoded and executed in memory via [ScriptBlock]::Create(), providing browser encryption key extraction capabilities, SYSTEM token impersonation, and Defender signature locking. Exfiltrated data is sent by POST to /t/event as GZip-compressed, Base64-wrapped JSON.

Privilege escalation. ChocoShell requires administrative privileges for its most impactful capabilities: SYSTEM token impersonation for Chrome ABE decryption, Volume Shadow Copy Service (VSS) shadow copy creation, Defender signature locking. It implements three silent UAC bypass techniques with ordered fallback:

1. SilentCleanup task hijack: Writes a malicious command to HKCU\Environment\windir, then triggers the built-in SilentCleanup scheduled task, which resolves %windir% from the user’s environment, executing the threat actor’s command at elevated privilege. The registry value is cleaned up after two seconds to avoid cloud detection.
2. wsreset.exe COM hijack: Creates a COM handler key in HKCU\Software\Classes and launches the auto-elevating Windows Store reset tool.
3. sdclt.exe folder hijack: Hijacks HKCU\Software\Classes\Folder\shell\open\command and launches the Windows Backup utility with the /KickOffElev flag.

If none of the silent bypasses succeed (for example, the user is not a local administrator), ChocoShell falls back to a visible UAC prompt via Start-Process -Verb RunAs. Notably, the script also contains a variant designed to execute within the WinGet Desired State Configuration (DSC) host process (ConfigurationRemotingServer), suggesting an attack vector through malicious WinGet DSC configuration used in Windows machine provisioning.

Credential and session theft. Once running with elevated permissions, ChocoShell locks Defender signature updates and systematically harvests data from multiple sources. For Chromium-based browsers (Chrome, Edge, Brave, Opera, Opera GX, Vivaldi), it extracts the master encryption key from the browser’s Local State file, handling both the modern ABE scheme (Chrome v127+) and the legacy data protection API (DPAPI)-only scheme. ABE decryption requires SYSTEM-level DPAPI access, which the malware obtains by impersonating a SYSTEM process token borrowed from winlogon.exe, wininit.exe, or services.exe. Locked browser SQLite databases are accessed through three strategies: shared file access, Volume Shadow Service snapshots, and direct copy as a fallback.

As a parallel collection path, ChocoShell launches Chrome, Edge, and Brave with the –remote-debugging-port flag and issues Network.getAllCookies through the Chrome DevTools Protocol (CDP). This completely bypasses ABE, enabling the browser to perform its own internal decryption and returns plaintext cookie values. To handle privilege issues (SYSTEM-launched browsers inherit the wrong token), the malware creates transient scheduled tasks with TASK_LOGON_INTERACTIVE_TOKEN to launch the browser under the signed-in user’s session. After extraction, the browser is stopped and relaunched with –restore-last-session to avoid alerting the user.

For Firefox family browsers (Firefox, Waterfox, LibreWolf, Floorp, Zen), the malware copies unencrypted cookies.sqlite databases from each profile. Additionally, ChocoShell collects Microsoft 365 and Azure Active Directory (AD) access tokens, refresh tokens, and Web Account Manager (WAM) tokens from .tbres files in the Token Broker cache. Collection of these tokens represents a significant threat to enterprise environments, as threat actors could replay SSO sessions without browser cookies. Additionally, Wi-Fi credentials are harvested via netsh wlan show profile with key=clear.

Exfiltration and cleanup. All collected data is aggregated into a JSON structure, GZip-compressed, Base64-encoded, and sent by POST to the C2’s /t/event endpoint. After exfiltration, all collected data variables are nulled, garbage collection is forced, VSS shadow copies are deleted via Windows Management Instrumentation (WMI), temporary elevation scripts are removed, and all UAC bypass registry keys (already cleaned during escalation) are verified removed.

FruitStone: Operator C2 panel

FruitStone is the web-based C2 panel that Storm-2945 operators use to manage the entire CaptiveCrunch campaign infrastructure. Implemented as a single-page application (HTML and JavaScript) serving as the front-end of the C2 server with all functionality exposed without authentication, FruitStone provides a centralized dashboard for managing compromised endpoints, building and deploying new campaign payloads, and reviewing all collected data (such as screenshots, keystrokes, browser credentials).

Operational cover. The panel is branded as “CloudSync Console” with a footer reading “Acuity Systems, Inc. — Cloud Infrastructure Portal v3.2.1,” designed to appear as legitimate enterprise cloud management software if the panel URL is discovered by defenders or hosting providers. This masquerading extends to the CornFlake agent’s service name (Cloud Sync Service) and description (“Synchronizes files with the cloud storage provider”), creating a consistent cover story across the toolchain.

Figure 5. CloudSync Console panel masquerade

Session management and multi-operator support. FruitStone uses JSON Web Token (JWT)-based authentication, session revocation, and rate limiting with IP blocking to prevent brute force attacks against the panel sign in. Multiple operators could be provisioned with individual accounts, and all active sessions are visible with IP address, user-agent, and creation time to enable operational security awareness across the operators.

Agent management. The panel displays all registered CornFlake agents in a dashboard with real-time status updates via Server-Sent Events (SSE). Each agent card shows comprehensive system information including hostname, username, OS version, CPU, RAM, disk usage, screen resolution, timezone, domain membership, and camera/microphone presence, all collected during the CornFlake posture sweep. Agents are grouped by country and subnet, with geographic distribution visualized on a map.

Operators could interact with individual agents through:

• Remote shell — Interactive cmd.exe or PowerShell command execution with command history
• File system browser — Live directory traversal and arbitrary file download from compromised hosts
• Collection tasking — On-demand screenshot, process list, keylog buffer flush, clipboard dump, security posture survey, ChromeKatz cookie/password extraction, camera capture, and audio recording
• Configuration push — Live runtime reconfiguration of C2 servers, watch paths, and C2 beacon timing
• Agent update — In-place implant update by pushing a new CornFlake build to a running agent
• Agent kill — Remote termination of the CornFlake implant

Campaign builder. A step-by-step wizard enables operators to configure and build new CornFlake payloads directly from the panel:

1. Identity — Campaign ID, C2 host and port, HTTP base URL, executable file name (svchost32.exe by default), and dropper type (C dropper at ~19 KB, Go stub at ~8 MB, or standalone self-installer)

Figure 6. Identity tab

2. Capabilities — Toggle individual collection modules: screenshots, process enumeration, keylogging, clipboard monitoring, posture survey, file exfiltration, and ChromeKatz browser credential theft

Figure 7. Capabilities tab

3. File Paths — Configure targeted directories and file extensions by category (documents, archives, images, code, data, emails, encryption keys)

Figure 8. File paths tab

4. Evasion — Enable garble symbol randomization (for GoLang payloads), XOR string encoding, GZip upload compression, and debug mode

Figure 9. Evasion tab

Infrastructure management. FruitStone provides management interfaces for three layers of supporting infrastructure:

• Proxy relays — Multi-proxy C2 relay architecture with TLS certificate tracking (fingerprint, expiry), health checks, connection counts, bytes forwarded, and rotation capabilities that push updated server lists to all online agents
• Beacon profiles — Configurable timing profiles controlling agent sleep intervals, reconnection delays, TLS Server Name Indication (SNI) spoofing (like teams.microsoft.com), and DNS fallback domains
• Staging servers — External payload hosting infrastructure with push-to-deploy, file listing, and health monitoring

Figure 10. View of the CloudSync staging servers interface Device code abuse for cloud access

Since July 16, Microsoft has observed a portion of CaptiveCrunch landing pages redirecting users to device code authentication flow experiences. In these cases, users served these landings might be instructed to enter a device code into a legitimate Microsoft sign-in page, a technique commonly referred to as device code phishing.

Device code authentication is a legitimate OAuth workflow designed for devices that cannot support a traditional sign-in experience. However, threat actors could abuse this flow by initiating an authentication request on behalf of a user then convincing the user to enter an actor-controlled device code into a legitimate Microsoft authentication page. When successful, the victim authenticates the threat actor’s session rather than their own.

This activity is consistent with previously reported device code phishing operations conducted by Midnight Blizzard since August 2024. The observed technique does not appear fundamentally novel; however, integrating device code phishing into captive portal and traffic manipulation operations might increase the likelihood that users perceive the authentication request as legitimate. For additional details on Midnight Blizzard-related device code phishing techniques, see: Storm-2372 conducts device code phishing campaign. To understand other threat actors’ use of device code phishing and associated mitigations, see Inside an AI‑enabled device code phishing campaign.

How to protect against CaptiveCrunch activity Minimize trust in hospitality and guest networks

When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy.

• Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi‑Fi whenever practical.
  • For enterprise-managed devices, organizations can choose to prevent Wi-Fi connections to networks that have not been provisioned via Mobile Device Management (MDM). See: https://learn.microsoft.com/windows/client-management/mdm/policy-csp-wifi#allowmanualwificonfiguration
• Consider using enterprise-managed travel routers or hotspot devices that establish encrypted tunnels back to trusted corporate infrastructure before accessing sensitive resources.
• Avoid downloading software updates, certificates, browser updates, network troubleshooting tools, or security utilities presented through captive portals or other unexpected web prompts.
• Verify update requests through trusted operating system mechanisms rather than pop-up messages or website prompts.

Strengthen identity and access controls

Organizations should assume that public and hospitality network infrastructure might not be trustworthy and should adopt controls that limit exposure to traffic manipulation, credential theft, and device code phishing.

• Educate users to recognize ClickFix-style prompts, fake verification checks, and paste-and-run instructions as malicious, especially when they invoke command interpreters or script hosts such as cmd.exe, PowerShell, rundll32.exe, or mshta.exe.
• Use passwordless solutions like passkeys and implement multifactor authentication (MFA).
  • Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
  • Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.
• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force MFA.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 
• Use a Security Service Edge (SSE) solution like Global Secure Access to secure access to any app or resource using network, identity, and endpoint access controls.

Reduce exposure during captive portal registration

Organizations should review what information employees provide to hospitality providers when connecting to guest networks.

• Do not reuse corporate credentials on hotel, conference, or guest-network registration pages.
• Where possible, organizations should evaluate whether venue-provided wireless is required for corporate events and conferences.
• Organizations should minimize unnecessary disclosure of employee identities, organizational affiliations, and travel details when booking accommodations or registering for guest network access, consistent with corporate policy and applicable local requirements.

Microsoft Defender detections and hunting guidance

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

Microsoft Defender for Endpoint detects Storm-2945 activity under the detection Suspicious activity linked to a Russian state-sponsored threat actor has been detected. However, these alerts might be triggered by unrelated threat actor activity. The following chart lists Microsoft Defender detections specific to the TTPs utilized by Storm-2945 in this attack.

Tactic Observed activity Microsoft Defender coverage Initial accessFile download via captive portal redirection Microsoft Defender for Endpoint – Suspicious downloaded fileInitial accessClickFix technique, fake browser or OS update, initial file downloadMicrosoft Defender for Endpoint
– Possible initial access from an emerging threat
– Possible ClickFix activityPersistenceCornFlake registers a Windows service, a Registry Run key, a scheduled taskMicrosoft Defender for Endpoint
– Suspicious Scheduled Task Process Launched  
– Suspicious scheduled task
– Suspicious file added to run key
– Suspicious service registration

Microsoft Entra ID Protection
– Microsoft Entra threat intelligence
– Verified threat actor IPStealth/Defense evasionChocoShell disables AMSIMicrosoft Defender for Endpoint
– Possible Antimalware Scan Interface (AMSI) tamperingCredential accessChocoShell’s theft of browser session cookies, saved passwords, Microsoft 365 SSO tokens, and Wi-Fi credentials.   Device code abuse.Microsoft Defender for Endpoint
– Possible theft of passwords and other sensitive web browser information
– Suspicious DPAPI activity

Microsoft Defender For Identity
– Anomalous OAuth device code authentication activity

Microsoft Defender XDR
– User account compromise via OAuth device code phishing
– Malicious sign in from an IP address associated with recognized attacker infrastructure
– Suspicious Azure authentication through possible device code phishingCollectionCornFlake monitoring and loggingMicrosoft Defender for Endpoint
– Activity that might lead to information stealerPrivilege escalationChocoShell UAC bypass techniquesMicrosoft Defender for Endpoint
– UAC bypass was detected
– Possible Component Object Model (COM) hijacking Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Midnight Blizzard

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

Hunting queries Microsoft Defender XDR

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

Detect file creation after Wi-Fi connectivity test on devices

The following query checks for a file creation on a device within two minutes of the device performing built‑in Network Connectivity Status Indicator (NCSI) test, which occurs when network connectivity is established to a Wi-Fi network with a captive portal. This activity might indicate an attacker’s initial access file presence on a device.

Please note that not all files discovered through this query might be malicious or related to this threat activity.

let ncsi_endpoints = dynamic(["msftconnecttest.com","edge-http.microsoft.com","msftncsi.com","captive.apple.com","clients1.google.com", "clients3.google.com","clients4.google.com","clients6.google.com","connectivitycheck.gstatic.com","connectivitycheck.android.com", "android.clients.google.com","www.gstatic.com","detectportal.firefox.com","detectportal.brave-http-only.com","cloudflareportal.com", "cloudflarecp.com","cloudflareok.com","connectivity-check.warp-svc","connectivity.cloudflareclient.com","spectrum.s3.amazonaws.com", "nmcheck.gnome.org"]); let NCSIEvents = DeviceNetworkEvents | where Timestamp > ago(7d) | where RemoteUrl has_any (ncsi_endpoints) | project NCSI_Timestamp = Timestamp, DeviceId, DeviceName, RemoteUrl, NCSI_ReportId = ReportId, NCSI_InitiatingProcessFileName = InitiatingProcessFileName, NCSI_InitiatingProcessCommandLine = InitiatingProcessCommandLine, NCSI_AccountName = InitiatingProcessAccountName; let FileDownloadEvents = DeviceFileEvents | where Timestamp > ago(7d) | where ActionType == "FileCreated" | where FileName has_any (".exe",".msi",".zip",".rar",".7z") | project Download_Timestamp = Timestamp, DeviceId, FileName, FolderPath, Download_ReportId = ReportId, Download_InitiatingProcessFileName = InitiatingProcessFileName, Download_InitiatingProcessCommandLine = InitiatingProcessCommandLine, Download_AccountName = InitiatingProcessAccountName; NCSIEvents | join kind=inner ( FileDownloadEvents ) on DeviceId | where Download_Timestamp >= NCSI_Timestamp and Download_Timestamp <= NCSI_Timestamp + 2m | project NCSI_Timestamp, Download_Timestamp, DeviceName, DeviceId, RemoteUrl, FileName, FolderPath, InitiatingProcessFileName = Download_InitiatingProcessFileName, InitiatingProcessCommandLine = Download_InitiatingProcessCommandLine, AccountName = Download_AccountName, NCSI_ReportId, Download_ReportId

Detect connectivity to Storm-2945 infrastructure

The following query checks for connectivity to Storm-2945 infrastructure observed in this attack activity.

let target_domains = dynamic(["ms365-device.com", "ms365-live.com", "m365-owa.com", "owa-ms365.com"]); let target_ips = dynamic(["31.57.243.154", "38.146.28.75", "38.146.28.132", "104.194.159.150", "107.189.26.194", "213.145.86.112"]); DeviceNetworkEvents | where RemoteUrl has_any(target_domains) or RemoteIP in (target_ips) | project Timestamp, DeviceName, DeviceId, RemoteUrl, RemoteIP, LocalIP, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName = InitiatingProcessAccountName, ReportId

Detect CornFlake RAT presence on affected systems

The following query checks for the presence of the CornFlake RAT binary.

DeviceProcessEvents | where FolderPath == "%APPDATA%\\svchost32\\svchost32.exe" or FolderPath endswith @"\svchost32\svchost32.exe" | project Timestamp, DeviceName, DeviceId, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName, ReportId

Detect CornFlake RAT Windows service registration

The following query checks for the CornFlake RAT Windows service registration.

DeviceRegistryEvents | where RegistryKey has @"\SYSTEM\CurrentControlSet\Services\svchost32" | where ActionType == "RegistryValueSet" | where (RegistryValueName == "DisplayName" and RegistryValueData == "Cloud Sync Service") or (RegistryValueName == "Description" and RegistryValueData == "Synchronizes files with the cloud storage provider") | project Timestamp, DeviceName, DeviceId, RegistryKey, RegistryValueName, RegistryValueData, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName, ReportId Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect network IP and domain indicators of compromise using ASIM

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

//IP list and domain list- _Im_NetworkSession let lookback = 30d; let ioc_ip_addr = dynamic(["213.145.86.112"]); let ioc_domains = dynamic(["213.145.86.112/t/pixel.gif", "213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "213.145.86.112/t/event"]); _Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now()) | where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains) | summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect web sessions IP and file hash indicators of compromise using ASIM

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

//IP list - _Im_WebSession let lookback = 30d; let ioc_ip_addr = dynamic(["213.145.86.112"]); let ioc_sha_hashes =dynamic([“918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593”, “be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42c”]); _Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now()) | where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes) | summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect domain and URL indicators of compromise using ASIM

The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:

// file hash list - imFileEvent // Domain list - _Im_WebSession let ioc_domains = dynamic(["https://213.145.86.112/t/pixel.gif", "https://213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "https://213.145.86.112/t/event"]); _Im_WebSession (url_has_any = ioc_domains)

ChocoShell C2 communications

The following query detects ChocoShell communications with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel.

let lookback = 30d; let ioc_url_artifacts = dynamic(["/t/pixel.gif?m="]); _Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now()) | where DstDomain in (ioc_url_artifacts) | summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor Indicators of compromise IndicatorTypeDescriptionFirst seenms365-device[.]comDomainCaptiveCrunch DCF redirect2026-07-23ms365-live[.]comDomainCaptiveCrunch DCF redirect2026-05-14m365-owa[.]comDomainCaptiveCrunch AitM infrastructure2026-07-20owa-ms365[.]comDomainCaptiveCrunch AitM infrastructure2026-07-1631.57.243[.]154  IP addressCaptiveCrunch AitM infrastructure2026-07-1638.146.28[.]75  IP addressCaptiveCrunch AitM infrastructure2026-07-0138.146.28[.]132IP addressCaptiveCrunch DNS Resolver2026-07-15104.194.159[.]150  IP addressCaptiveCrunch AitM infrastructure2026-04-28107.189.26[.]194IP addressChocoShell C2 / CaptiveCrunch DNS Resolver2026-02-27213.145.86[.]112  IP addressChocoShell C22026-07-01918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593  File hashCornFlake2026-07-03be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42cFile hashChocoShell2026-07-10 References

• https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/
• https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication

Learn more

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

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

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

The post CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft appeared first on Microsoft Security Blog.

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

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

Project Perception brings agentic defense to security operations

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

Learn more about Project Perception Microsoft Defender secures the full AI attack surface, from inbox to cloud

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

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

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

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

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

Microsoft Entra strengthens identity across the AI-powered enterprise Strengthen identity foundations for AI-powered operations

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

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

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

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

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

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

The unified Insider Risk Management alerts list, showing inline agent summaries, the new Categorization column, and combined classic and agent filtering on a single page. Advanced endpoint management now broadly available

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

Stay In the Loop

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

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

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

As organizations move beyond AI experimentation, success will depend on how effectively they combine intelligence and trust. The same systems that amplify knowledge, accelerate decisions, and unlock new outcomes must also protect data, govern AI, and build resilience. In this next phase of transformation, security is not separate from innovation—it is an enabler that helps make responsible innovation possible at a faster pace. That starts with asking better questions—the kind that help organizations turn intelligence into action and trust into a foundation for progress. 

AI is changing how security decisions are made. Defenders now have access to more signals, insights, and analytical power than ever before. But better security does not start with more information. It starts with asking the right questions: What are we trying to protect? What risks matter most? What conditions need to be true? And what decisions do we need to make with confidence? 

That clarity matters because security is shaped by more than technology. The challenges organizations face rarely exist in isolation. They emerge across people, processes, technology, data, identities, and governance. Understanding those connections is what allows security teams to use platforms, AI, and automation to make better decisions under real-world conditions. 

Connect with Microsoft Security at Black Hat USA 2026 Security as a systems challenge 

Security has never been a single-layer challenge. Vulnerabilities can emerge across code, data, identities, and integrations, while exposure is often created at the intersections between them. Designing for security requires a systems mindset—understanding how these elements work together, where failure can occur, and what safeguards are needed so no single layer carries the burden alone. That is why defense in depth remains essential: layered controls, ongoing monitoring, mitigations, and risk management across the AI lifecycle help organizations reduce exposure while continuing to adapt. 

This is especially important as AI becomes more embedded in how organizations operate. AI can help teams analyze vast amounts of information, identify patterns, and surface recommendations at a scale that was previously unthinkable. Those AI outputs still require oversight, governance, and human judgment, with clear accountability for how AI-generated insights are validated and used. But insight only creates value when it is grounded in the right context and connected to action. 

AI-generated insights still require validation, oversight, and resilience planning because AI systems can produce incomplete or inaccurate outputs.

Clarity creates better decisions 

The most important security decisions start with a clear view of the risk, the level of control or visibility required, and the outcome the system is designed to achieve. When we optimize for capability over context, we miss how security decisions are actually made: through signals, expertise, validation, and judgment. This becomes even more important as AI expands what is possible. Better analysis can surface more insights, but better decisions still depend on understanding what matters most and applying the right context. That matters most when conditions are changing quickly, and teams need to act before every answer is certain. 

Threat intelligence offers a useful example. Defenders operate in environments defined by ambiguity, incomplete information, and rapidly changing conditions. Success rarely comes from a single source or signal. It comes from combining multiple forms of intelligence, applying expertise, validating assumptions, and connecting insights in ways that strengthen assurance.  

The lesson extends beyond threat intelligence. Different security objectives require different combinations of signals, analysis, and human judgment. Resilient decisions come from bringing those elements together thoughtfully, rather than relying on a single source of truth or assuming technology alone can provide the answer. 

Designing for better outcomes  

As AI becomes more embedded in security operations, the quality of our outcomes depends on how clearly we define the objectives we are trying to achieve. Security leaders create the most value when they identify the risks that matter most, the conditions that need to be true, and the systems required to support better decisions. 

Then we design for those outcomes through the right mix of controls, safeguards, and decision-making processes. This shows up not just in architecture, but in how teams establish guardrails, validate assumptions, and respond to the unexpected. The aim is not to make security harder for defenders. It is to make the work easier to execute, supported by platforms, tooling, and AI that help deliver greater speed, accuracy, and confidence. 

The systems we are building today do not exist in isolation. They interact with people, shape decisions, and operate at a scale that can amplify both strengths and weaknesses. Our responsibility extends beyond technology choices. We have to help organizations design systems they can understand, govern, and rely on with confidence as complexity grows. 

Trust is not something we can take for granted, and that does not change in the era of AI. It is built through deliberate choices: the controls we establish, the visibility we create, the assumptions we validate, and the safeguards we put in place. As AI becomes more embedded in how organizations operate, security leaders have a responsibility to help build confidence in the systems people rely on every day. 

Building trustworthy AI systems requires governance, security, privacy protections, transparency, and accountability across the full technology stack, aligned to responsible AI principles and standards.

The risk is not simply that we choose the wrong tool, model, or platform. The greater risk is believing that one answer can solve a complex, evolving problem. AI can help teams make sense of complexity, but it does not eliminate the need for judgment. If anything, it raises the importance of defining the right outcomes and designing systems that make the right actions easier to take. 

Better security starts with better questions, and with the clarity to act on them. The organizations that succeed will apply AI thoughtfully, define outcomes clearly, and combine analytical power with the expertise, judgment, and adaptability needed to build more resilient systems in the age of AI. 

Explore Microsoft Security 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.

The post ​​Better security starts with better questions appeared first on Microsoft Security Blog.

Why security needs a new Cyber Stack — Introducing Project Perception

The physics of cybersecurity are changing. Autonomous systems can now reason, adapt and operate continuously. At the same time, the cost of offense is falling, while the volume, velocity and complexity of what must be secured continues to grow. Attackers can generate exploits faster, scale campaigns further and operate with unprecedented efficiency. The approaches built for a world of human actors cannot keep pace with a world of AI, agents and machine-speed attacks.

Security needs a new Cyber Stack. A new Cyber Stack must continuously perceive risk across the entire digital estate, reason across vast amounts of context and take action at machine speed. It must learn and adapt as environments evolve, helping organizations stay ahead of threats. And because security is ultimately a human mission, it must amplify defenders with better insights and more powerful ways to act. The defining characteristic of the next generation of security systems will not be their ability to generate more alerts. It will be their ability to continuously perceive, reason and act.

That vision led us to build Project Perception. A new agentic security system designed for the realities of AI. It turns signals into real-time protections using AI to defend against AI.

Project Perception brings together signals, context, models and specialized agents into a continuously learning system of defense. It can reason, prioritize and act at machine speed while keeping humans firmly in control and empowering them with powerful new workflows.

Project Perception is based on a simple idea: effective defense requires continuous understanding of how an attacker sees the world, how a defender evaluates risk and how protections are improved over time. To accomplish this, Perception coordinates three classes of specialized agents. Red team agents identify potential paths to compromise before an attacker can exploit them. Blue team agents investigate, reason over context and determine what represents meaningful risk. Green team agents take corrective actions and strengthen defenses across the environment. Working together, these agents form a closed-loop system that continuously discovers, evaluates and improves an organization’s security posture.

A system like Project Perception is only as effective as the visibility it has, the actions it can take, the experience of the teams building it and the models it can use. Microsoft brings together all four.

We see across identities, endpoints, applications, data, clouds and AI systems, providing broad visibility across the digital estate. Equally important, we can help customers take action across those environments. Combined with decades of security research, threat intelligence and real-world operational experience defending organizations, these capabilities shape how Project Perception reasons, prioritizes and responds.

Security is a 24/7 mission. Organizations need protection that is highly effective, continuously available and affordable at scale. That requires more than access to the most capable model. It requires applying the right model to the right task. Project Perception adopts a multi-model architecture that combines frontier and specialized cyber models, optimizing for both quality and cost.

As part of this multi-model strategy, we are committed to bringing customers the best models for each security task, including innovating with our own specialized models. The first scenario is software vulnerability management, bringing MAI-Cyber-1-Flash inside MDASH, our software vulnerability multi-model team of agents. MDASH with MAI-Cyber-1-Flash delivers 96% on CyberGym, an industry leading benchmark, +12 points above Mythos. And this same configuration delivers almost 50% of cost savings vs. the current MDASH configuration in market today. That’s the power of a well-tuned, multi-model system with access to uniquely rich historical training data. Next, Project Perception will take advantage of MAI-Cyber-1-Flash for many more security workflows, beyond the software vulnerability scenario.

We are bringing this vision to customers around the world through Project Perception, which enters public preview on August 3.

YouTube Video

https://www.youtube-nocookie.com/embed/ACx7NxQW9uo?feature=oembed A Cyber Stack built for agentic security

Delivering agentic security requires more than adding agents to existing workflows. It requires a new Cyber Stack, designed from the ground up.

The stack begins with signals and sensors that provide awareness across the digital estate. Security context transforms those signals into token-efficient understanding that agents can use. Models provide intelligence and reasoning. A harness coordinates models and agents across security workflows. Agents apply that intelligence across security workflows and actuators translate decisions into protection. Together, these layers create a continuous learning system that can understand risk, adapt to changing conditions and improve security outcomes over time.

While each layer provides important capabilities, the power of Project Perception comes from how they work together.

Security context built for AI

Effective reasoning requires more than raw signals. Agents need context.

Microsoft transforms its breadth of visibility, threat intelligence and security expertise into a security context that connects security data, knowledge and semantics across the digital estate. The result is a continuously updated representation of an organization’s assets, identities, relationships, risks and activities that gives agents a shared, near real-time, understanding of the environment they are helping to defend.

This shared understanding is foundational to how Project Perception operates. Rather than forcing agents to continuously gather, correlate and reconstruct context from raw signals, it provides them with immediate and token-efficient access to the information they need to reason over risk, prioritize actions and make decisions. By grounding every interaction in this rich security context, Project Perception improves the accuracy and consistency of reasoning while reducing the time, compute and cost required to operate at scale.

A multi-model architecture built for security

No single model will be optimal for every security task. Effective cyber defense requires applying the right model to the right problem at the right time.

For Project Perception, the right model is determined by the combination of quality, reliability, latency and cost. Rather than relying on a single model, Project Perception adopts a multi-model architecture that continuously selects the capabilities best suited to the task, optimizing for both effectiveness and economics. Because security is an always-on mission, sustainable economics are essential to operating protection at scale.

This approach is shaped by ongoing research, benchmarking and evaluation across frontier and specialized models. Our security researchers continuously assess models against real-world security workflows, enabling us to match each task with the model that delivers the best outcome. This allows customers to benefit from advances in AI without being tied to any single model.

Actuators — insights to actions

Security teams do not need more information. They need better outcomes.

That is why actuators are a critical part of the Cyber Stack. Project Perception is deeply integrated across Microsoft Security products, enabling agents to connect insights to actions. Organizations can continuously reduce risk rather than simply identify it, helping defenders strengthen security while remaining in control.

Built with safety first

Underpinning every layer of the Cyber Stack is a foundation of trust. Project Perception is built in alignment with Microsoft’s Responsible AI principles and inherits the security, compliance, governance and operational controls our customers already rely on. This ensures these capabilities are delivered with the same rigor, accountability and enterprise readiness that customers expect.

The future of security

Security has always been a race between attackers and defenders. AI changes the speed, scale and economics of that race. Defenders need systems that can continuously perceive, reason and act alongside them.

 Project Perception is how we begin to build that future.

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.

Microsoft’s AI Red Team Announces New Alliance: Enhancing AI Security Through Global AI Red Teaming

Hayete Gallot leads Microsoft’s work to help organizations operate securely in an AI-driven world. Her scope includes identity, threat protection, compliance and data security at global scale.

The post Rethinking security for the age of AI appeared first on Microsoft Security Blog.

In this article

1. Building a global alliance
2. What the research focuses on
3. Why this matters

Most AI safety testing still happens inside the walls of individual organizations. That has resulted in a fundamental disconnect: many of the highest-risk failure modes in modern AI systems require deep domain expertise, multilingual context, or regional understanding that no single internal team can fully replicate on its own. 

As frontier models become more capable, the attack surface expands with them. AI red teaming is no longer just about prompt injection or content safety edge cases. It increasingly involves security operations, misuse scenarios, multilingual harms, alignment failures, and domain-specific abuse patterns that can vary significantly across geographies and languages. 

Microsoft’s AI Red Team has observed that meaningful testing of advanced AI systems- and models similarly requires broader participation from researchers and practitioners who operate outside traditional corporate security boundaries. To address that gap, today we are announcing the External Red Team Alliance (EXTRA), a formalized global extension of Microsoft’s AI Red Team designed to support and encourage external expertise to advance AI safety and security testing.  We are proud to share we are funding the development of new AI safety assessments on six continents through unrestricted gifts. 

Building a global alliance

EXTRA is a two-part initiative focused on expanding AI safety research and strengthening external collaboration. 

The first component supports a global academic network focused on advancing AI safety and security research. Microsoft’s AI Red Team has provided unrestricted gifts to 18 university labs spanning six continents. The goal is intentionally broad: support researchers who are already investigating difficult, unresolved questions in AI safety and help them continue pushing that work forward independently. 

Some of the supporting institutions include: 

• Carnegie Mellon University Security and Privacy Institute (CyLab), United States 

• Georgetown University – Georgetown Security Lab (SecLab), United States 

• Harvard University Berkman Klein Center for Internet & Society (BKC), United States 

• Howard University Research Institute for Tactical Autonomy (RITA), United States 

• Indian Institute of Technology Madras – Centre for Responsible AI (CeRAI), India 

• Korea Advanced Institute of Science & Technology – KAIST Web Security & Privacy (WSP) Lab, Korea 

• New York University – NYU Alignment Research Group (ARG), United States 

• Northeastern University Network and Distributed Systems Security (NDS2) Lab, United States 

• University College London – UCL Information Security Research Group (UCL ISec), United Kingdom 

• University of Cagliari Pattern Recognition and Applications (PRA) Lab, Italy 

• University of California – Berkeley Risk and Security Lab; Center for Responsible, Decentralized Intelligence (CRDI), United States 

• University of Melbourne Artificial Intelligence Assurance Lab, Australia 

• University of Pretoria Data Science for Social Impact (DSFSI) Research Group, South Africa 

• University of São Paulo Center for Artificial Intelligence (C4AI), Brazil 

• University of Toronto CleverHans Lab, Canada 

• University of Washington Department of Human Centered Design & Engineering (HCDE), United States 

“Academic research is critical to understanding the cyber security landscape and finding solutions that work for all of society – and partnerships like this with industry are essential to delivering on that promise. Through partnerships, civil society and public institutions researchers gain access to frontier technology to understand how models work and bring their expertise to the task of determining risk and developing more effective countermeasures for the benefit of society as a whole.”

Nicolas Papernot, professor, University of Toronto. 

The second component of EXTRA focuses on operational collaboration. Microsoft is building a distributed network of specialists who can participate directly in red teaming highly specialized areas where deeper expertise is required. That includes researchers, practitioners, and regional experts who understand specific attack classes, languages, cultural contexts, or technical domains that internal teams may not fully cover alone. 

Beyond expanding participation, EXTRA is also intended to help advance the science of AI safety evaluation. By bringing together academic researchers, security practitioners, and domain experts from around the world, the initiative aims to contribute to the development of more robust methodologies and testing practices for increasingly capable AI systems. Today’s cybersecurity ecosystem depends on coordinated vulnerability research, responsible disclosure programs, academic inquiry, and global communities of independent security researchers who routinely identify risks that vendors alone would not find. Likewise, advancing AI safety will benefit from ongoing contributions from experts across institutions, disciplines, and geographies to identify emerging threats, strengthen safeguards, and improve evaluation practices. 

“As frontier model capabilities advance, they create new risk opportunities, particularly in low-resource settings. Partnerships, such as this EXTRA, bring greater attention to the study of the local risk landscape and can enable broader impact of the work carried out around the globe in smaller academic settings.”

Balaraman Ravindran, head of the Robert Bosch Centre for Data Science and Artificial Intelligence (RBC-DSAI) at IIT Madras.  What the research focuses on

The research areas funded through EXTRA reflect several of the emerging areas Microsoft’s AI Red Team continues to encounter when evaluating advanced AI systems. 

Some universities are examining the cybersecurity implications of AI systems themselves — including how models can be attacked, manipulated, or abused in operational environments. Other labs are exploring the inverse problem: how AI systems can assist defenders and improve cyber operations. 

The structure of the program is intentional. The funding is unrestricted because the objective is not to direct research outcomes toward product requirements or predefined deliverables. The goal is to strengthen independent safety research capacity globally and create stronger long-term collaboration between academia and operational AI security teams. 

Why this matters

“Managing frontier AI risk requires more than internal safeguards. It requires continuous engagement with experts who understand how these systems behave across different technical, linguistic, and cultural contexts. EXTRA reflects Microsoft’s broader Frontier Governance Framework approach: combining rigorous internal governance with external support and collaboration to better identify, assess, and mitigate emerging risks as AI capabilities advance. By supporting independent research and building stronger connections with universities and specialists around the world, we are helping strengthen the broader ecosystem needed for trustworthy and secure AI development,” says Natasha Crampton, Chief Responsible AI Officer, Microsoft 

Governments too are increasingly focused on understanding the capabilities and security implications of frontier AI systems to strengthen resilience. But just as coordinated international research helped unlock the benefits of previous technological revolutions, diverse expertise from researchers and practitioners around the world is essential to identify emerging threats, improve defenses, and build greater confidence in AI systems.   

“Frontier AI is already shaping the future of both cybersecurity and national security. Understanding how these systems can be misused, and identifying risks before they become real-world threats, requires expertise that spans institutions, disciplines, and borders.” says Mike Yeh, VP & Deputy General Counsel, Customer Security and Trust, Microsoft 

AI red teaming is becoming more interdisciplinary, multilingual, and globally distributed. The expertise needed to identify meaningful failure modes increasingly lives across universities, independent research communities, and regional specialists. 

EXTRA reflects a practical shift in how AI security testing must operate going forward. External expertise is no longer supplemental to red teaming; in many cases, it is essential. 

Microsoft would like to thank these people for their important contributions with this project: Steph Ballard, Blake Bullwinkel, Nicholas Butts, Janelle Bryant, Kaja Ciglic, Hector de Rivoire, Eugenia Kim, Amanda Minnich, Shujaat Mirza, Jingxia Ni, Saphir Qi, Giorgio Severi, Hilary Solan, Hiwot Tesfaye, Sam Vaughan, Marguerita Wicklander, and the many teams at these schools around the world who helped coordinate 

The post Enhancing AI security through global AI red teaming appeared first on Microsoft Security Blog.

In this article

1. Tycoon2FA Q2 disruption impact
2. QR code phishing attacks
3. CAPTCHA-gated phishing tactics
4. Malicious payloads
5. Business email compromise
6. Microsoft Teams threats
7. Notable phishing campaigns
8. Mitigation and protection guidance
9. Indicators of compromise (IOCs)

The second quarter of 2026 (April–June) was largely defined by the continuing downstream effects following Microsoft’s Digital Crimes Unit-led disruption efforts against the Tycoon2FA phishing-as-a-service (PhaaS) platform in March. Phishing volume linked to the platform fell 92% from pre-disruption averages, including QR code phishing and CAPTCHA-gated phishing both declining from their March highs. Despite ongoing efforts to rebuild operations, Tycoon2FA did not recover its previous scale or influence during Q2, and no single service emerged to replace the platform at comparable scale.

Inside tycoon2fa

Infrastructure, tradecraft, and detections ›

These trends reflect both the measurable impact that disruption operations can have on phishing ecosystems and the adaptability of threat actors as they diversify delivery channels. At the same time, Microsoft Threat Intelligence observed continued growth in Teams-based social engineering, particularly voice phishing (vishing), with weekly malicious call attempts reaching nearly ten times the mid-2025 baseline by the end of the quarter. This activity illustrates how threat actors continue to expand beyond email into trusted workplace communication platforms where communications may appear more trustworthy to users.

Microsoft detected approximately 7.6 billion email-based phishing threats throughout the quarter, with monthly volumes declining modestly from 2.7 billion in April to 2.4 billion in June. Credential phishing remained the dominant objective behind malicious payloads, while business email compromise (BEC) activity largely returned to historical norms after a brief, anomalous surge in April. Notable campaigns observed during the quarter also demonstrated how threat actors combine automation, trusted services, and multi-stage delivery chains to scale operations. These campaigns ranged from an automated BEC campaign that reached more than 67,000 users across 42,000 organizations in under three hours, to a multi-stage phishing campaign that used nested EML files, calendar invitations, and a Microsoft authentication redirect to deliver malware.

Q2 AiTM token compromise

April phishing campaign tactics, detections, and mitigations ›

This blog provides a view of email threat activity across the second quarter of 2026, highlighting key trends in phishing techniques, payload delivery, and threat actor behavior observed by Microsoft Threat Intelligence. We examine shifts in QR code and CAPTCHA-gated phishing activity, malicious payload trends, BEC activity, the growth of Teams-based threats, and notable campaigns observed during the quarter. We also provide recommendations and Microsoft Defender detections to help organizations identify and mitigate evolving threats while prioritizing defensive measures.

Tycoon2FA Q2 disruption impact

The disruption operation that Microsoft’s Digital Crimes Unit launched against Tycoon2FA infrastructure in early March continued to produce measurable results throughout Q2 2026. After falling 15% in March and another 22% in April, Tycoon2FA-linked phishing volume dropped 74% in May to just 1.5 million messages, then fell another 20% in June to 1.2 million, by far the lowest monthly volumes observed in at least a year. For reference, the average monthly volume of phishing messages linked to Tycoon2FA during the second half of 2025 was 15.1 million. By the end of Q2, volumes were running at roughly 8% of that baseline, representing a 92% total decline since the disruption operation began.

email threat landscape

Q1 trends that shaped Q2 activity ›

Figure 1. Tycoon2FA monthly malicious messages volume (July 2025–June 2026)

Tycoon2FA’s influence across two primary phishing tactics, QR code lures and CAPTCHA-gated landing pages, also continued to decline throughout the quarter:

• CAPTCHA-gated phishing: Tycoon2FA’s share of CAPTCHA-gated phishing sites fell from 41% in March to 16% in April and 12% by June, down from a peak of 76% in December 2025.
• QR code phishing: The share of QR code campaigns redirecting to Tycoon2FA domains decreased from 20% in March to 17% in April and 14% by June, down from a peak of 33% in November 2025.

These declines indicate that the platform’s customer base has not migrated to replacement infrastructure at anything close to the scale they previously operated.

After being forced off Cloudflare, which had provided anti-analysis protection that made Tycoon2FA pages harder to scan and take down, the service continued to rely on infrastructure hosted on the .RU top-level domain (TLD), a shift that began in late March. More than 40% of newly observed Tycoon2FA domains used .RU registrations throughout Q2. While this reflects an ongoing effort to find replacement hosting, Tycoon2FA’s role in the phishing ecosystem has nonetheless been significantly diminished and the pace of recovery has been slow.

QR code phishing attacks

After peaking at 18.7 million attacks in March, the highest monthly volume in at least a year, QR code phishing declined for three consecutive months in Q2. Volume fell 7% in April to 17.4 million, then dropped more sharply in May (-38%) and June (-22%), closing the quarter at 8.3 million attacks. By June, QR code phishing had returned to levels last seen in mid-2025.

Figure 2. Trend of QR code phishing attacks by weekly volume (January 2026–June 2026)

The delivery methods used in QR code attacks shifted notably during Q2. PDF attachments remained the dominant vehicle throughout, but their dominance weakened after April:

• PDF attachments peaked at 79% of QR code attacks in April before falling to 59% in May and 58% in June. By raw volume, malicious PDFs containing QR codes dropped more than 60% between April and June.
• DOC/DOCX attachments moved in the opposite direction, increasing 30% in May to account for 38% of QR code payloads, the highest share since December 2025. By June, DOC/DOCX payloads reached 40% of QR code attacks. This swap between PDF and DOC/DOCX dominance is a pattern that has recurred throughout the past year, as operators appear to rotate between delivery formats.
• Email-embedded QR codes, which had surged 336% in March and accounted for 5% of QR code attacks, effectively disappeared in Q2. This delivery method dropped to near-zero across all three months, leaving QR code phishing almost entirely an attachment-based tactic.

Figure 3. QR code phishing delivery method share by month (January-June 2026) CAPTCHA-gated phishing tactics

After accumulating to nearly 12 million attacks in March, the highest monthly volume observed over the past year, CAPTCHA-gated phishing declined sharply throughout Q2. Volume fell 32% in April to 8.2 million, then dropped another 65% in May and 24% in June, closing the quarter at just 2.2 million attacks. Since the March peak, CAPTCHA-gated phishing has fallen more than 81%, reaching its lowest monthly volume in more than a year.

Figure 4. CAPTCHA-gated phishing volume (January 2026–June 2026)

The rapid rotation of delivery methods that characterized Q1 continued into Q2, with no single payload type maintaining the top position for more than one or two months:

• PDF attachments surged to 63% of CAPTCHA-gated attacks in April, the highest single-payload share observed in the past year, after more than quadrupling in March. This dominance was short-lived, however. PDF volumes dropped 69% in May and another 70% in June, falling to just 22% of attacks by the end of the quarter.
• HTML attachments, which had been a major delivery vector through January (37% of attacks), declined sharply during Q2. After declining to 8% in April, HTML payloads fell to just 3% in May before recovering slightly to 5% in June, their lowest sustained share in at least a year.
• SVG files reached their lowest observed volume in April (5% of attacks) before rebounding to 12% in May and 26% in June. While still well below the levels seen when Tycoon2FA actively used SVG files, this gradual recovery bears monitoring.
• Email-embedded URLs reclaimed the top position in June for the first time since December 2025, accounting for 30% of CAPTCHA-gated attacks. This was more a function of every other delivery method declining in raw volume than a resurgence in URL-based delivery. The actual volume of URL-delivered CAPTCHA-gated phish in June was still far lower than most months over the past year.
• DOC/DOCX files declined from their March spike, falling steadily from 15% to 10% of attacks over the quarter.

Figure 5. CAPTCHA-gated phishing distribution method share by month (January-June 2026)

Tycoon2FA’s continued decline was a significant factor in the overall volume reduction. The platform’s share of CAPTCHA-gated phishing fell from 41% in March to 16% in April, 18% in May, and 12% by June, down from a peak of 76% in December 2025. No single service has emerged to fill the gap at comparable scale, contributing to the sustained decline in CAPTCHA-gated phishing activity overall.

Malicious payloads

Credential phishing continued to dominate the malicious payload landscape throughout Q2, accounting for 94–96% of all payload-based attacks each month. These credential phishing payloads either linked users to phishing pages or locally loaded spoofed sign-in screens on a user’s device. Traditional malware delivery represented just 4–6% of payloads, consistent with its long-term decline.

HTML and PDF attachments remained the two most common malicious payload types across the quarter, together accounting for roughly 60–70% of all payload-based attacks each month:

• HTML attachments held the top position across all three months at 35–41% of attacks. After peaking in April, HTML payload volume declined 33% in May and another 17% in June.
• PDF attachments consistently ranked second at 24–31% of attacks. PDF volume was relatively stable in April before declining 41% in May and 4% in June.
• SVG files continued the decline that has tracked closely with Tycoon2FA’s diminishing activity. After peaking at 23% of malicious payloads in July 2025, SVG’s share fell to around 7% by Q2, consistent with SVG’s historical role as a preferred Tycoon2FA payload format.
• DOC/DOCX and ZIP/GZIP files oscillated without a clear directional trend. DOC/DOCX increased 26% in May before falling 17% in June, while ZIP/GZIP attachments declined 48% in April, rebounded 27% in May, then dropped 40% in June.
• ICS files (calendar invitations), while still a small share of overall payload volume (roughly 4%), nearly quadrupled in June (+277%). These attacks take advantage of the fact that calendar invitations are processed differently than standard email attachments and can inject malicious links into a user’s calendar without requiring an explicit open-and-click interaction.
• EXE files continued to decline, falling to their lowest monthly volume in June, reflecting the broader shift away from traditional malware delivery via email attachments.

Figure 6. Malicious payload file type (Q2 2026) Business email compromise

April 2026 produced the most anomalous BEC data point in more than a year: nearly 9 million attacks, a 121% increase from March and more than double any previous month. The spike was short-lived as volume fell 62% in May to 3.4 million and settled at 3.9 million in June, both figures consistent with the monthly baseline that had held throughout the prior year. The April surge appeared to be driven by a small number of high-volume campaigns rather than a fundamental escalation in BEC activity.

Figure 7. Monthly BEC attack volume (January 2026–June 2026)

The composition of BEC attacks remained consistent throughout Q2. Generic outreach messages (like “Are you at your desk?”) accounted for 87–92% of initial contact emails each month, while explicit requests for specific financial transactions or documents represented just 3–8%. This pattern underscores that BEC operators overwhelmingly favor establishing conversational rapport with targets before making fraudulent requests, rather than leading with direct financial asks.

Figure 8. Initial BEC email content by type (Q2 2026)

Within the smaller subset of explicit financial requests, the most notable trend was the near-disappearance of fake invoice payment requests:

• Invoice payment requests fell 67% in May and another 77% in June, reaching their lowest volume in more than a year. By June, invoice-themed BEC accounted for less than 0.4% of all attacks, down from around 3.6% in March.
• Payroll update requests declined moderately across the quarter, from roughly 4% of attacks in March to 2.3% by June.
• Gift card requests remained at roughly 1–4% of attacks, with no clear directional trend.

Microsoft Teams threats

While email remains the dominant initial access vector, threat actors increasingly abused Microsoft Teams during Q2 to deliver social engineering, phishing, and malware payloads. Unlike email, Teams traffic typically bypasses secure email gateways and benefits from the perceived legitimacy of a colleague-initiated chat, which can make lures particularly effective in this environment.

Teams-based phishing volume climbed steadily throughout Q2, with the average number of detected attacks rising 19% from March to April, holding roughly flat into May (+1%), then increasing another 10% into June. Financial and executive impersonation has remained largely absent from Teams-based attacks over the past several months.

Figure 9. Weekly observed malicious Microsoft Teams calls (January-June 2026)

The dominant lure theme remained technical support impersonation, with attackers posing as an employee’s information technology (IT) help desk, typically warning of an impending account lockout. However, the way attackers presented themselves continued to evolve:

• Display names shifted away from IT- or help desk-branded identities. For the second consecutive month, more than half (52%) of Teams-based phishing attacks in June used generic display names rather than obvious IT support impersonation.
• Attacker email addresses associated with these chats moved away from support-themed domains toward software-as-a-service (SaaS) terminology, scan/update language, and infrastructure keywords. This shift may align with the broader rise of ClickFix-style attacks adopting update-fix and similar themes.

Figure 10. Malicious Teams call impersonation percentage (Q2 2026)

Vishing through Teams showed the steepest growth of any threat category tracked in this report during Q2. Average weekly malicious call attempts rose 31% from April to May and another 27% into June, with the final two weeks of June recording the two highest weekly volumes on record. Since the beginning of 2026, weekly vishing attempts have increased roughly 80% and now run at nearly ten times the mid-2025 baseline. Attackers time these calls deliberately when targets are most likely to be online and active, with the heaviest activity falling between 14:00 and 20:00 UTC, Monday through Friday, with near-zero weekend activity. Notably, a growing share of these calls go unanswered, end quickly, or are rejected outright, partly reflecting Microsoft’s ongoing efforts to harden the Teams attack surface and improve protections against social engineering abuse.

Notable phishing campaigns

The following campaigns were observed during the quarter and highlight notable credential phishing, BEC, and malware delivery activity. For analysis of a separate code of conduct-themed credential phishing campaign observed in April of Q2, see Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise.

Automated BEC campaign scales aging report and payroll diversion lures

On June 1, 2026, Microsoft Defender Research observed a high-volume BEC campaign that used automation to operate at scale. Over a send window of under three hours (14:08–16:52 UTC), the actor reached more than 67,000 users across more than 42,000 organizations, almost exclusively in the United States. Targeting spanned a broad range of industries rather than a single vertical, most notably retail and consumer goods (17%), technology and software (15%), and financial services (14%). The campaign ran two lures in succession from shared infrastructure: arequest impersonating sales executives to obtain aging report data and customer contact details, and a payroll diversion pretext impersonating the CEO or President to redirect salary payments to attacker-controlled bank accounts.

Figure 11. Timeline of campaign messages sent by minute, separated by lure theme

Delivery was fully scripted. The messages were generated programmatically using Python’s email.mime library, identifiable from its default MIME boundary format (===============[integer]==), and dispatched through the Amazon Simple Email Service (SES) API rather than a manual webmail interface, as indicated by the SES Feedback-ID and Message-ID formats. This allowed the actor to iterate through a recipient list and inject per-message variables (like spoofed executive display names, recipient addresses, and unique tracking identifiers) at volume. Messages were sent from a DomainKeys Identified Mail (DKIM)-configured Slovak domain (ecajovna[.]sk) through SES, so they passed Sender Policy Framework (SPF) and achieved DKIM alignment. Neither lure contained a malicious link or attachment; both relied on eliciting a reply to attacker-controlled mailboxes that mimicked legitimate providers (ilyff[.]com, j-gmails[.]com, x2mails[.]com).

Automation also extended to targeting and follow-up. The actor addressed generic role-based mailboxes (like “ar”, “accountsreceivable”, “hr”, “payroll”) rather than named individuals, reducing per-target effort. Each message embedded a 1×1 open-tracking pixel served from an Amazon SES engagement subdomain, with per-message identifiers that let the actor confirm which recipients opened the email and prioritize follow-up against those targets. The combination of scripted message generation, API-based bulk delivery, role-based targeting, and automated engagement tracking allowed a single actor to run a personalized, financially motivated BEC operation at a scale not practical to execute manually.

Figure 12. Rendered example of aging report email used in this campaign Figure 13. Rendered example of payroll diversion email used in this campaign Staff update campaign with nested EML file and calendar invitation leads to BAT file dropper

Between June 14–15, 2026, Microsoft Defender Research observed a phishing campaign targeting more than 107,000 users across nearly 19,000 organizations, almost exclusively in the United States. The campaign targeted a broad range of industries rather than a single vertical, most notably financial services (17%), technology and software (14%), and retail and consumer goods (14%). Emails impersonated an internal “Internal Affairs – Financials & Staff Updates” function at the recipient’s own organization, with the display name and subject line both opening with the recipient’s organization name and closing with constant trailing text. The messages were sent from a Postfix host on 9i6pokerdepot[.]com routed through Barracuda’s outbound mail service, and DKIM passed cleanly for the sending domain.

Figure 14. Rendered sample of initial campaign email

The visible email body contained minimal content. One line told the reader to download the attached file for the meeting summary, followed by a confidentiality notice. Each message carried two attachments: a nested EML posing as a Teams archive recording, and an ICS calendar invite addressed to placeholder administrative accounts at the recipient’s domain. The nested EML’s file name retained an unfilled template token ( {{DATE2}} ), indicating a per-recipient templating tool.

When opened, the EML displayed a voicemail notification with a single action button. That button pointed to Microsoft’s OAuth sign-in endpoint at login.microsoftonline[.]com, with parameters that asked for a silent sign-in attempt against an Entra application that the attacker had registered as multi-tenant.

Figure 15. Rendered sample of voicemail notification from the nested EML

Because no active sign-in session could satisfy the silent request, Microsoft’s authentication service redirected the recipient to the destination the attacker had pre-registered on the application. That destination was a path on clickup-attachments[.]com, ClickUp’s public attachment host, and served a Windows batch file named Financial_report.bat. Because the link routed through Microsoft authentication infrastructure, both recipients and URL scanners saw a login.microsoftonline[.]com link.

The batch file ran a hidden PowerShell command that pulled installer.exe from pixeldrain[.]com, saved it under the user’s Temp directory, ran it with a silent flag, and deleted the dropper on exit. Rather than stealing credentials, the campaign ultimately resulted in silent malware execution on the user’s Windows device.

Figure 16. Source code of Financial_report.bat Mitigation and protection guidance

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

• Review the recommended settings for Exchange Online Protection and Microsoft Defender for Office 365 to ensure your organization has established essential defenses and knows how to monitor and respond to threat activity.
• Invest in user awareness training and phishing simulations. Attack simulation training in Microsoft Defender for Office 365, which also includes simulating phishing messages in Microsoft Teams, is one approach to running realistic attack scenarios in your organization.
• Enable Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Responders could also manually check for and purge unwanted emails containing URLs and/or Subject fields that are similar, but not identical, to those of known bad messages. Investigate malicious email that was delivered in Microsoft 365 and use Threat Explorer to find and delete phishing emails.
• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable network protection in Microsoft Defender for Endpoint.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Enable password-less authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support password-less. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Microsoft Defender detections

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

Microsoft Defender for Endpoint

The following alert might indicate threat activity associated with this threat. The alert, however, can be triggered by unrelated threat activity.

• Suspicious activity likely indicative of a connection to an adversary-in-the-middle (AiTM) phishing site

Microsoft Defender for Office 365

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• A potentially malicious URL click was detected
• A user clicked through to a potentially malicious URL
• Suspicious email sending patterns detected
• Email messages containing malicious URL removed after delivery
• Email messages removed after delivery
• Email reported by user as malware or phish

Microsoft Security Copilot

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

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

Microsoft Defender XDR threat analytics

• Activity Profile: Email threat landscape, June 2026
• Activity Profile: Email threat landscape, May 2026
• Activity Profile: Email threat landscape, April 2026
• Tool Profile: Tycoon2FA
• Technique Profile: QR code phishing
• Technique Profile: ClickFix technique leverages clipboard to run malicious commands
• Threat Overview Profile: Business Email Compromise
• Threat Overview Profile: Adversary-in-the-middle credential phishing

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 (IOCs) IndicatorTypeDescriptionFirst seenLast seen9i6pokerdepot[.]comDomainSending domain; DKIM-signed by the operator2026-06-152026-06-15Customer.Service[@]9i6pokerdepot[.]comEmail addressCampaign sender address2026-06-152026-06-15t90141296286.p.clickup-attachments[.]comDomainClickUp attachment subdomain hosting the stage 2 BAT dropper2026-06-152026-06-15hxxps://t90141296286.p.clickup-attachments[.]com/t90141296286/fb39c3a9-3161-40ad-847b-0683e0409d6f/Financial_report.batURLStage 2 BAT dropper download URL2026-06-152026-06-15hxxps://pixeldrain[.]com/api/file/3v92oJiLURLFinal installer payload download URL2026-06-152026-06-15Re: Teams Archive Recording for {{DATE2}}.emlFile nameNested EML attachment template name; the literal {{DATE2}} indicates an unfilled per-recipient template token2026-06-152026-06-15Financial_report.batFile nameStage 2 dropper batch file delivered from the OAuth error redirect2026-06-152026-06-15ecajovna[.]skDomainDomain used to send campaign emails2026-06-012026-06-01ilyff[.]comDomainReply-to domain used to receive victim responses2026-06-012026-06-01j-gmails[.]comDomainReply-to domain used to receive victim responses2026-06-012026-06-01x2mails[.]comDomainReply-to domain used to receive victim responses2026-06-012026-06-01contact[@]ecajovna[.]skEmail addressAddress used to send campaign emails2026-06-012026-06-01mail[@]ilyff[.]comEmail addressReply-to address2026-06-012026-06-01me[@]j-gmails[.]comEmail addressReply-to address2026-06-012026-06-01me[@]x2mails[.]comEmail addressReply-to address2026-06-012026-06-01compliance-protectionoutlook[.]deDomainDomain hosting malicious campaign content2026-04-142026-04-16acceptable-use-policy-calendly[.]deDomainDomain hosting malicious campaign content2026-04-142026-04-16cocinternal[.]comDomain  Domain hosting sender email address2026-04-142026-04-16gadellinet[.]comDomain  Domain hosting sender email address2026-04-142026-04-16harteprn[.]comDomainDomain hosting sender email address2026-04-142026-04-16cocpostmaster[@]cocinternal[.]cmEmail addressEmail address used to send campaign emails2026-04-142026-04-16nationaladmin[@]gadellinet[.]comEmail addressEmail address used to send campaign emails2026-04-142026-04-16nationalintegrity[@]harteprn[.]comEmail addressEmail address used to send campaign emails2026-04-142026-04-16m365premiumcommunications[@]cocinternal[.]comEmail addressEmail address used to send campaign emails2026-04-142026-04-16documentviewer[@]na[.]businesshellosign[.]deEmail addressEmail address used to send campaign emails2026-04-142026-04-165DB1ECBBB2C90C51D81BDA138D4300B90EA5EB2885CCE1BD921D692214AECBC6SHA-256File hash of campaign PDF attachment2026-04-142026-04-16B5A3346082AC566B4494E6175F1CD9873B64ABE6C902DB49BD4E8088876C9EADSHA-256  File hash of campaign PDF attachment2026-04-142026-04-1611420D6D693BF8B19195E6B98FEDD03B9BCBC770B6988BC64CB788BFABE1A49DSHA-256  File hash of campaign PDF attachment2026-04-142026-04-16 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 Email threat landscape: Q2 2026 trends and insights appeared first on Microsoft Security Blog.

Cyber incidents don’t wait—and effective response can’t either. In the age of AI where cyber incidents unfold at machine speed, having the right partnerships in place becomes paramount. While AI is expanding what’s possible, navigating this transformation can be challenging to do alone. That’s why our collaboration with AXA XL is so important—bringing Microsoft Defender Experts Cybersecurity Incident Response services directly to cyber insurance policyholders at the moment it matters most, helping organizations coordinate technical, business, and insurance decisions in parallel rather than in sequence.

Get started with Microsoft Defender Experts Cybersecurity Incident Response

This collaboration reflects Microsoft’s continued investment in building an incident response model designed for real-world conditions, where speed, trust, and alignment matter as much as technology.

In a live incident, security, executive, legal, and insurance teams are all acting at once. Without pre-established coordination, those parallel efforts can slow containment and increase risk. Our approach to incident response—and our work with AXA XL—starts by aligning those paths before a crisis begins.

For example, during a ransomware incident, security teams may be actively containing lateral movement while leadership evaluates operational impact, legal teams assess disclosure requirements, and insurers determine coverage pathways—all within the same window of time. When those decisions aren’t aligned, response slows and risk compounds.

Decades of supporting customers through high-stakes cyber incidents have reinforced a clear truth: effective incident response extends beyond technical execution. It requires coordination across teams and partners before the crisis hits. That experience continues to shape how we design Defender Experts Cybersecurity Incident Response—and how we work with partners like AXA XL.

Incident response must extend beyond technology

As a global insurance provider, AXA XL plays a critical role in helping organizations navigate cyber risk and response. Through this collaboration, AXA XL policyholders gain coordinated access to Microsoft’s dedicated incident response teams—combining threat containment, restoration, and recovery with insurance, legal, and regulatory workflows. By aligning AXA XL’s cyber insurance capabilities with Defender Experts Cybersecurity Incident Response, organizations benefit from a more integrated response model while gaining access to incident response teams informed by Microsoft Threat Intelligence and two decades of experience responding to some of the world’s most complex and consequential cyber incidents.

Previously, organizations often brought incident responders and insurers together in the middle of a crisis. With this collaboration, that relationship is already in place, reducing friction, delays, and uncertainty when time is most critical. AXA XL policyholders and Microsoft customers can now bring Defender Experts Cybersecurity Incident Response to the table the moment it matters—creating a clearer, more predictable path from detection to recovery. The outcome is not simply faster response, but confidence: knowing who to call, how response engages, and how recovery is operationalized before the next decision becomes urgent.

The threat of a cybersecurity incident has long been ‘not if, but when,’ and in the wake of AI, the ‘when’ may quickly become ‘how often.’ The risks organizations are tasked with preventing and overcoming relative to cybersecurity and data privacy are growing exponentially. Partnering with experts can make all the difference where resilience in the face of adversity may be your only saving grace. AXA XL’s strategic partnerships with  cyber incident response providers underscore our commitment to expertise, preparedness, and resilience. By drawing on a deep knowledge of internal expertise and external cyber specialists, we empower our insureds to respond swiftly and effectively to prevail when your number is up.”

—Gwenn Cujdik, Incident Response and Cyber Services Lead for North America, AXA XL

This collaboration reflects Microsoft’s continued investment in building an incident response model designed for real-world conditions, where speed, trust, and coordination matter as much as technology.

Incident response engineered for high-stakes moments—and the readiness behind them

What differentiates Microsoft Defender Experts Cybersecurity Incident Response is not only its deep technical expertise, but its direct connection to Microsoft engineering teams and Microsoft Threat Intelligence. Responders bring first-party insight into identity-based attacks, cloud intrusions, and enterprise compromise—insight informed directly by Microsoft’s global telemetry and security engineering teams. This connection enables responders to move quickly—from identifying the root cause of an attack to deploying mitigations informed by global threat signals. When combined with pre-aligned partners like AXA XL, that technical strength becomes even more impactful, allowing organizations to act decisively without navigating uncertainty during a crisis.

That same expertise extends beyond the moment of crisis. Delivered by the same frontline experts, Microsoft Defender Experts Cybersecurity Incident Response proactive services—incident response planning, assessments, simulations, and advisory engagements—help organizations build resilience, strengthening their ability to prevent, withstand, and recover from an incident.

These proactive engagements also help align internal teams and external partners before an incident occurs—clarifying roles, escalation paths, and decision-making processes. This preparation ensures that when an incident does occur, organizations are not starting from zero but executing against a coordinated plan. Resilience can mean the difference between containing an incident with minimal disruption and becoming the next headline.

Raising the bar for trusted incident response

The collaboration reinforces Microsoft’s long-standing commitment to delivering trusted cyber incident response services. It also underscores Microsoft’s intent to integrate directly into the cyber risk insurance ecosystem—working alongside insurers rather than operating adjacent to them during critical response moments. It reflects a shared belief that organizations deserve response capabilities that are proven, accessible, and designed to work together when it matters most.

As cyberthreats continue to evolve, Microsoft remains focused on strengthening this ecosystem—working with global insurance leaders like AXA XL to help organizations prepare for disruption, respond with confidence, and recover with resilience.

Learn more about Microsoft Defender Experts Cybersecurity Incident Response Learn more

To learn more about how our teams are working together, and how our collaboration with cyber insurance providers like AXA XL can help you strengthen your cyber resilience, visit the Microsoft Defender Experts Cybersecurity Incident Response webpage. 

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 Real world incident response: Microsoft and AXA XL strengthen cyber resilience appeared first on Microsoft Security Blog.

In this article

1. Weston on the future of defense 
2. Our latest intelligence (and response) on npm supply chain attacks
3. Follow the research in the Black Hat Briefings
4. Go deeper in Microsoft sessions
5. Visit booth #2144 for research, community, and hands-on defense
6. Plan your week with Microsoft Security
7. Skill up before and after Black Hat
8. See you at hacker summer camp
9. Microsoft Security booth #2144 experiences and schedule

Across the threat landscape, in this moment, one pattern sits at the center of the story: threat actors are following trust.

They are not only looking for vulnerable systems, but rather targeting the software, services, identities, tools, developer workflows, and AI systems that organizations already depend on.

A package can become a distribution path. A build pipeline can become an access path. A trusted tool can become or expand an attack surface. An AI agent with the wrong access can become a new way to reach code, data, or infrastructure.

While the surfaces may change, the goal for the majority of threat actors remains the same: find what is trusted, abuse it, and scale the impact.

At Black Hat USA 2026, Microsoft Security will walk through how we are seeing this shift unfold, how security teams can look for it earlier, and how threat intelligence, expert-led response, and security operations need to work together when campaigns move across software, identity, cloud, data, and AI systems.

On Wednesday, August 5, 2026, the day begins with David Weston’s keynote, The End of Rare: Defending When Offense Is Cheap, which looks at what defense requires when offensive capability becomes easier to access, automate, and scale. Later that afternoon, Aarti Borkar and Tanmay Ganacharya will resume the main stage for Poisoned at the Source: Inside the Hunt for Supply Chain Attacks, which offers a closer look at how Microsoft Threat Intelligence is hunting attacks across software ecosystems, developer workflows, and trusted services. This includes details into the ongoing attacks on npm (Node package manager). 

Together, these sessions frame the challenge security teams are facing now: when offensive capability becomes easier to scale, security teams need to understand the trust paths threat actors can abuse before those paths become open doors for attacks. 

At our booth, we’ll also showcase Microsoft Defender Experts Threat Intelligence, a new expert-led service delivering continuous, curated intelligence tailored to your organization, and Microsoft Defender Experts MDR, now extended with third-party and multicloud coverage.

From August 4 to 6, 2026, at Mandalay Bay in Las Vegas, you’ll find Microsoft Security on the Business Hall floor at booth #2144, and on Wednesday evening, join us at the Microsoft Security reception at Swingers at Mandalay Bay.

Register for the Microsoft Security reception Weston on the future of defense 

At 9:15 AM PT on Wednesday, August 5, 2026, David Weston, CVP of Agentic Security, will examine what changes for security teams when offensive capability becomes easier to access, automate, and scale. 

The keynote sets up one of the central questions security leaders are facing now: how does the security operations center (SOC) and analysts adapt when threat actors can move faster, test more often, and reuse trusted paths across software, identity, cloud, and AI systems? Join the keynote Wednesday, August 5, 2026, then continue the conversation with Microsoft Security at booth #2144. 

Our latest intelligence (and response) on npm supply chain attacks

That same intelligence-to-action challenge is at the center of our main stage session at Black Hat. 

On Wednesday, August 5, 2026, from 2:30 PM PT to 3:00 PM PT, Aarti Borkar, Corporate Vice President (CVP), Microsoft Security, and Tanmay Ganacharya, Vice President of Microsoft Security Research and Threat Intelligence, will share intelligence and insights into the ongoing supply chain campaigns impacting all areas of the threat landscape. The talk, Poisoned at the Source: Inside the Hunt for Supply Chain Attacks, will walk through Microsoft Threat Intelligence’s investigations into the ongoing npm supply chain attacks targeting software ecosystems, developer workflows, trusted services, and how organizations are handling the challenges associated with npm packages.

Follow the research in the Black Hat Briefings

Microsoft Security researchers will also present peer-reviewed technical research in the Black Hat Briefings. These sessions go deep into cloud, mobile, and software supply chain defense.

GitHub Can Tell You’re Being Hacked. You’re Just Not Listening: Building EDR for GitHub from Its Own Event Stream

• Presented by Yossi Weizman, Principal Security Research Manager
• Wednesday, August 5, 2026, from 10:15 AM PT to 10:45 AM PT

One Click to System: Exploiting Bixby’s Trust Model for Full Device Compromise

• Presented by Dimitrios Valsamaras, Senior Security Researcher
• Wednesday, August 5, 2026, from 12:00 PM PT to 12:40 PM PT

Handle With Care: Chaining Azure Automation Flaws for Cross-Tenant Identity Takeover

• Presented by Shay Shavit, Senior Security Researcher
• Wednesday, August 5, 2026, from 4:30 PM PT to 5:10 PM PT

Check the official Black Hat schedule for final room assignments and any timing updates.

Go deeper in Microsoft sessions

Microsoft experts will also lead sessions that give you a closer look behind the scenes, including:

Mind the Gap: Turning Threat Intelligence into Decisive Action with Expert-Led Defense

• Presented by Wes Malaby, General Manager of Customer Success
• Wednesday, August 5, 2026, from 5:00 PM PT to 5:20 PM PT

Cyber Defense Showdown

• Presented by Fanta Kaba and special guest Jimmie Galaites
• Wednesday, August 5, 2026, from 5:00 PM PT to 5:20 PM PT

Agentic Security: What’s Next

• Presented by Naadia Sayed, Principal Product Manager
• Thursday, August 6, 2026, from 11:15 AM PT to 12:00 PM PT

These sessions extend the main stage story into practitioner decisions: how teams move from intelligence to action, how defenders test their judgment under pressure, and how AI and agents are changing security workflows.

Visit booth #2144 for research, community, and hands-on defense

This year we are transforming the Microsoft Security booth into a community center. Click here to jump to the full schedule.

If the keynote and main stage sessions frame the largest challenges across the threat landscape, booth #2144 is where you can directly explore the workflows behind it: threat intelligence, incident response, AI security, security operations, partner solutions, and hands-on practice.  

Customers: Schedule a time to meet with our team

You will find:

Connection circles, ask-me-anythings (AMAs), meetups led by industry influencers, and lightning talks

Short-form conversations with practitioners and experts on threat intelligence, incident response, AI security, identity, data protection, and security operations. If you swing by when the expo area opens, we’ll also fuel you up so you can skip the food court.

Partner presence

At Black Hat 2026, the Microsoft booth will feature 13 partners from the Microsoft Intelligent Security Association (MISA) who will showcase solutions built with Microsoft Security technology. Security Insider Conversations will feature MISA partners Critical Start (August 5, 2026, at 3:30 PM PT) and Huntress (August 6, 2026, at 2:00 PM PT) alongside Microsoft Security experts. Additionally, thank you to our Microsoft Security VIP Mixer sponsors: Ascent Solutions, Avertium, Devicie, Huntress, Illumio, Maureen Data Systems, and Security Risk Advisors. 

Demo our latest innovations

Explore connected experiences across defending with AI, securing AI, strengthening posture for AI adoption, using security intelligence in investigations and response, working with trusted partners, and connecting with Microsoft Defender experts.

Exclusive swag (featuring a surprise guest)

Spend some time with us at the experience we built around the booth and you’ll earn tokens that can be exchanged for custom patches and hats (because security experts have to wear many hats). Your favorite paperclip may be among the patches. Maybe.

Decompress with mini golf

The biggest Microsoft Security community moment of the week is our reception at Swingers at Mandalay Bay, hosted by Aarti Borkar.

Join us Wednesday, August 5, 2026, from 6:00 PM PT to 9:00 PM PT for food, drinks, mini golf, partner activations, and time with the Microsoft Security team away from the show floor.

Come compare notes with peers, meet Microsoft researchers and responders, and connect with the broader Microsoft Security community.

Space is limited, so reserve your spot early.

Register for the Microsoft Security reception Plan your week with Microsoft Security

You can find Microsoft Security at booth #2144 during Business Hall hours:

• Tuesday, August 4, 2026: 4:00 PM PT to 7:00 PM PT
• Wednesday, August 5, 2026: 9:00 AM PT to 6:00 PM PT
• Thursday, August 6, 2026: 9:00 AM PT to 4:00 PM PT

Stop by early to see the booth schedule, find upcoming AMAs and connection circles, and plan which live sessions and hands-on experiences you want to attend.

Skill up before and after Black Hat

You do not need to be in Las Vegas to take part in the broader Microsoft Security Black Hat experience.

The Microsoft Black Hat Skilling Challenge begins July 20, 2026, and will help defenders build hands-on skills across Microsoft Defender, Microsoft Sentinel, and Microsoft Security Copilot. Attendees can use the challenge to prepare before the event, then bring questions to on-site experts and community sessions. Remote participants can follow along through Microsoft Tech Community, AMAs, recaps, and post-event resources.

Join the Microsoft Black Hat Skilling Challenge See you at hacker summer camp

Threat actors are adapting around the systems organizations already trust. Security teams need to understand those trust paths before they become attack paths.

At Black Hat USA 2026, Microsoft Security will bring the research, expert perspective, and hands-on experiences to help practitioners see where attacker behavior is moving and how defense can adapt.

Add Poisoned at the Source to your schedule. Visit us at booth #2144. Join the skilling challenge. And register for the Microsoft Security reception on Wednesday night.

Register for the Microsoft Security reception Microsoft Security booth #2144 experiences and schedule Tuesday, August 4, 2026 TimeTitle5:00 PM PT to 6:00 PM PTHow Practitioners Build Effective Security Playbooks6:00 PM PT to 7:00 PM PTAgentic Security: What’s Next Wednesday, August 5, 2026 TimeTitle9:00 AM PT to 9:30 AM PTSecurity Communities Meet Up10:00 AM PT to 10:30 AM PTUsing Offensive Security Research to Advance AI Security10:30 AM PT to 11:00 AM PTThe Confused Deputy Strikes Back: How AI Agents Turn Into RCE Proxies12:00 PM PT to 12:30 PM PTHunting in the Gray: When Nation-States and Cybercrime Collide12:30 PM PT to 1:00 PM PTAI in Security Operations: What Actually Works and What Doesn’t1:00 PM PT to 2:00 PM PTAI in the SOC: Lessons Learned from the Front Lines2:30 PM PT to 2:30 PM PTMicrosoft Defender Challenge2:30 PM PT to 3:00 PM PTFrom Alert Fatigue to Action: How Practitioners Prioritize What Matters3:00 PM PT to 3:30 PM PTAgents in the Flow of Work: From Signals to Action3:30 PM PT to 4:00 PM PTWill It Hold Up in Court? Forensic Defensibility of Microsoft 365 Evidence5:00 PM PT to 6:00 PM PTZero Trust for the Agentic Era: An Interactive Discussion for Securing AI Thursday, August 6, 2026 TimeTitle9:00 AM PT to 9:30 AM PTThe Future of Microsoft Security and How Communities Can Support You10:00 AM PT to 10:15 AM PTQuantum Is Here: What Practitioners Must Do Now11:00 AM PT to 12:00 PM PTThe Next Era of Cyber Defense: Clarity, Control, and Response at Scale12:00 PM PT to 12:30 PM PTLessons from the Field: What to Do When You’re Under Attack12:30 PM PT to 1:00 PM PTWhen Browsers Become Agents: The Emerging Security Risks of AI‑Powered Browsers2:30 PM PT to 3:00 PM PTSocial Engineering Always Matters3:00 PM PT to 3:30 PM PTAI Runs on Data: Securing the Foundation of AI Adoption

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 at Black Hat USA 2026: Defending trust in the age of AI and supply chain attacks appeared first on Microsoft Security Blog.

In this article

1. Campaign 1: WebDAV-based ClickFix with Python loaders and blockchain C2
2. Campaign 2: MSHTA-initiated PowerShell chain with steganographic payload delivery
3. Mitigation and protection guidance
4. References
5. Learn more

From late April 2026 to mid-June 2026, Microsoft Defender Experts observed increased ACR Stealer activity across customer environments. These campaigns are successfully using ClickFix lures to steal browser credentials, authentication tokens, and sensitive documents from enterprise environments. Successful compromise can expose browser credentials, session tokens, authentication artifacts, and sensitive enterprise data, potentially enabling account compromise, unauthorized access to cloud resources, and follow-on intrusion activity. Security teams should prioritize monitoring for ClickFix lures, suspicious WebDAV activity, obfuscated PowerShell execution, and attempts to access browser credential stores.

ACR Stealer is an information-stealing malware family reportedly offered through a malware-as-a-service (MaaS) model and associated with the rebranding of Amatera Stealer. During this period, two campaigns stand out, together appearing frequently in reviewed recent intrusions. Both begin the same way, with a ClickFix social engineering technique that tricks targets into running the threat actor’s command, but the intrusion chains that follow diverge in how they deliver payloads, establish execution, and evade detection.

The first campaign relies on WebDAV-delivered payloads, staged PowerShell, Python-based loaders and persistence, and, in some intrusions, blockchain-backed dead-drop command-and-control (C2) resolution. The second campaign takes a more fileless route, using MSHTA, obfuscated PowerShell, and steganography-assisted in-memory execution. Despite these differences, both campaigns ultimately pursue the same goal: stealing browser-stored credentials and other sensitive data for exfiltration.

These two campaigns represent some of the most prevalent ACR Stealer delivery campaigns observed by Defender Experts; however, they do not represent the full range of delivery methods used by this malware family. Attribution to ACR Stealer is based on the observed behavior and post-exploitation tradecraft, corroborated by open-source intelligence on the infrastructure associated with this malware family. Additional campaigns, infrastructure patterns, and execution chains are likely active, and organizations should treat the indicators and techniques described here as representative.

Microsoft Defender for Endpoint can help surface both campaigns through behavioral coverage for living-off-the-land execution, suspicious WebDAV and MSHTA activity, obfuscated PowerShell, scheduled-task persistence, in-memory payload execution, and browser credential theft. In this blog, we analyze both campaigns in detail, including their delivery mechanisms, post-exploitation tradecraft, indicators of compromise, hunting opportunities, and guidance to help defenders detect and disrupt related activity in their environments.

Campaign 1: WebDAV-based ClickFix with Python loaders and blockchain C2 Initial access

In this campaign, a ClickFix prompt, likely delivered through malvertising or SEO-manipulated search results, instructs the target user to run a command that launches cmd.exe. The command subsequently invokes rundll32.exe to load a DLL from a remote WebDAV share accessed over HTTPS. The WebDAV path commonly uses a GUID-based directory structure and filenames designed to resemble legitimate resources (for example, google.ct), enabling the activity to blend with expected network traffic and evade casual inspection.

We observed three variants of the initial execution command:

Variant 1: Direct rundll32 invocation

Variant 2: pushd-Mounted WebDAV Share

Variant 3: Headless and obfuscated pushd execution

Variants 2 and 3 are notable for their use of pushd, which transparently maps the remote WebDAV share to a temporary local drive prior to execution. This technique allows threat actors to execute remotely hosted content through what appears to be a local path, simplifying payload execution while reducing user awareness. In the more advanced variant, threat actors further enhance stealth by launching commands through conhost.exe –headless, suppressing visible console windows, and employing environment variable obfuscation with delayed variable expansion to conceal critical execution components such as pushd, rundll32, and the remote host name. Combined with minimized or headless execution, these techniques reduce user visibility, complicate static analysis and detection, and enable the infection chain to execute with minimal indication to the victim.

Execution, persistence, and evasion through process masquerading

Once rundll32.exe loads the DLL retrieved from the remote server, the malware establishes communication with threat actor-controlled infrastructure and executes a heavily obfuscated PowerShell script. The script employs excessive arithmetic no-ops, dead loops, fake control flow, and randomized variable names to hinder static analysis and evade signature-based detection.

The PowerShell script subsequently deploys another stage that functions as both a malware installer and a persistence mechanism. It:

• Downloads a ZIP-packaged payload from a remote server and extracts it into a deceptive directory under %LocalAppData%\Temp (for example, LogiOptionsPlus).
• Launches a Python script using a bundled pythonw.exe instance to avoid displaying a console window.
• Removes previous deployments and terminates running instances before installation, effectively operating as an updater.
• Establishes persistence through a hidden scheduled task disguised as a legitimate software update, ensuring execution at user sign-in.
• Copies timestamps from a trusted Windows binary (notepad.exe) to the deployed files and clears PowerShell command history to reduce forensic visibility.

PowerShell loader downloads and executes a payload through a masqueraded scheduled task. Python loader launching the stealer

The Python component serves as a heavily obfuscated loader designed to conceal its true functionality until runtime. It employs multiple layers of defense against static analysis, including dynamic API resolution, encoded string reconstruction, junk-data removal, character shifting, string reversal, Base64 decoding, and zlib decompression. These techniques ensure that the embedded payload remains unreadable in its static form and is reconstructed only during execution, significantly hindering signature-based detection and automated analysis.

Once decoded, the final-stage payload functions as an in-memory shellcode loader. It extracts an archive file masquerading as a legitimate application installer, reads a file from the archive, and injects the payload into a system process. The loader allocates executable memory using VirtualAlloc, copies the payload into the allocated memory region, and transfers execution through the Windows Fiber API (ConvertThreadToFiber, CreateFiber, and SwitchToFiber). This technique facilitates stealthy in-memory execution while minimizing artifacts written to disk.

Decoded Python shellcode loader using VirtualAlloc and Fiber-based execution. Credential theft and data staging for exfiltration

The malware (injected code) aggressively harvests information from browser credential stores. It invokes Windows Data Protection API (DPAPI) routines to decrypt locally stored browser passwords, cookies, and authentication tokens. It also enumerates files across the system, targeting PDFs, Microsoft 365 documents, and data stored in enterprise-synchronized directories such as OneDrive and SharePoint. The collected data is subsequently archived, indicating preparation for exfiltration.

Blockchain dead-drop C2 resolution

A notable variation in this campaign is the use of blockchain services for C2 resolution, utilizing a technique known as EtherHiding. While most intrusions rely on more conventional C2 mechanisms, a subset deploys an additional secondary Python loader that leverages blockchain services as dead-drop resolvers. When this loader executes, it has been observed communicating with public blockchain RPC endpoints and third-party Web3 node infrastructure, likely querying data stored on a decentralized public ledger to retrieve follow-up payloads or a C2 address.

By externalizing C2 information to the blockchain, operators could dynamically update infrastructure without modifying or redeploying the malware, significantly complicating detection and takedown efforts. This behavior was observed across both variants of the campaign.

Campaign 2: MSHTA-initiated PowerShell chain with steganographic payload delivery

The second campaign takes a distinctly different approach to both delivery and execution. Where Campaign 1 relies on disk-based artifacts (Python runtime, scheduled tasks, and masquerading binaries), this campaign achieves its objectives almost entirely through fileless, in-memory execution, making it harder to detect through file-based scanning and forensic analysis.

Initial access through MSHTA and ClickFix

The execution chain begins when the victim, directed through malvertising or SEO-manipulated search results, encounters a ClickFix prompt that triggers a command spawning MSHTA to fetch and execute remote HTA content from an threat actor-controlled domain. The embedded VBScript loader abuses COM objects to decode and execute encoded PowerShell content.

VBScript loader using COM objects to decode and launch a PowerShell payload. PowerShell downloader and obfuscation

The decoded PowerShell stage employs obfuscation techniques similar to those seen in Campaign 1: randomized variable names, arithmetic no-op operations, dead loops, misleading control flow, and custom encryption routines. Prior to contacting its next-stage infrastructure, the malware generates a victim-specific identifier and disables certificate validation. The retrieved content is executed directly in memory.

Steganography-based payload delivery

A notable technique in this campaign is the use of steganography to conceal malicious content inside a publicly hosted image. Instead of downloading a secondary script (as in Campaign 1), the malware retrieves a JPEG image from an image-hosting service.

Steganographic payload extraction from a downloaded image prior to decryption and execution.

Analysis of the script revealed custom routines that extract an embedded payload from image pixels, decrypt and decompress it, and execute it entirely in memory. The payload dynamically resolves APIs such as LoadLibrary, GetProcAddress, VirtualAlloc, CreateThread, and WaitForSingleObject at runtime to perform reflective shellcode execution. By combining steganography with in-memory execution, the malware minimizes on-disk artifacts and complicates both detection and analysis.

Credential theft, data collection, and exfiltration

Following execution, the malware accesses credential stores belonging to Chromium-based browsers, including Google Chrome and Microsoft Edge, specifically the Login Data and Web Data databases, alongside Windows DPAPI decryption activity. This behavior indicates attempts to recover stored browser credentials, session cookies, authentication tokens, and other sensitive user information.

The malware also enumerates and accesses multiple high-value PDF documents across Desktop and Downloads locations, suggesting targeted collection of potentially sensitive files. The combination of browser credential harvesting and systematic document access points to an information-stealing objective focused on staging credentials and valuable user data for exfiltration.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of ClickFix lures, script-based payload delivery, credential theft, and post-compromise activity.

• Educate users to recognize ClickFix-style prompts, fake verification checks, and paste-and-run instructions as malicious, especially when they invoke command interpreters or script hosts such as cmd.exe, PowerShell, rundll32.exe, or mshta.exe.
• Reduce exposure to malvertising, SEO poisoning, and other web-based delivery chains by enforcing web filtering, blocking low-reputation or newly observed domains, and limiting access to remote content sources that are not required for business operations.
• Use application control and attack surface reduction rules to restrict PowerShell, Python, mshta.exe, rundll32.exe, and similar tools from launching untrusted or internet-delivered content, particularly from user-writable directories such as Downloads, Temp, and %LocalAppData%.
• Monitor for suspicious persistence and defense-evasion behavior, including scheduled tasks masquerading as software updates, timestomping, PowerShell history clearing, and execution chains that progress from remote content retrieval into PowerShell, Python, or shellcode-loading behavior.
• Investigate abnormal access to Chromium-based browser databases, DPAPI-related decryption activity, staged collection of Microsoft 365 documents or PDFs, and compression activity that may indicate credential theft or data staging for exfiltration.
• If compromise is suspected, isolate affected devices, rotate exposed credentials, revoke potentially compromised tokens, review persistence mechanisms, and investigate outbound connections to remote shares, image-hosting services, or other infrastructure used to resolve or retrieve follow-on payloads.
• Harden endpoints against credential theft by reducing reliance on browser-stored credentials, enforcing multifactor authentication and conditional access, and reviewing how privileged accounts access sensitive applications and synchronized enterprise data.
• Turn on cloud-delivered protection and behavior-based detections to help identify rapidly evolving threats, suspicious script execution, in-memory payload delivery, abuse of browser credential stores, and unusual child-process activity.
• Run endpoint detection and response (EDR) in block mode and enable automated investigation and remediation so post-breach detections are contained, and malicious artifacts can be removed with minimal delay.
• Harden PowerShell by enforcing appropriate execution policies, turning on script block logging, module logging, and transcription, and monitoring this telemetry for signs of malicious script activity.
• Turn on tamper protection and prevent local administrators from weakening antivirus protection through local policy or exclusion changes.

Microsoft Defender XDR detections

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

TacticObserved ActivityMicrosoft Defender CoverageExecution– Suspicious MSHTA launch through ClickFix execution
– Rundll32 loads remote WebDAV DLL
– COM objects launch in-memory PowerShellMicrosoft Defender for Endpoint
– Use of living-off-the-land binary to run malicious code
– Obfuscated command line was launched
– Suspicious process executed PowerShell command
– Suspicious process launch by Rundll32.exe

Microsoft Defender for Antivirus
Behavior:Win32/Interhta.IntPersistencePowerShell creates Scheduled task, masquerading as a software updateMicrosoft Defender for Endpoint
– Suspicious Scheduled Task Process Launched  
– Suspicious scheduled taskStealth/Defense Evasion– Fiber-API in-memory shellcode execution
– Reflective shellcode via CreateThreadMicrosoft Defender for Endpoint
Possible process hollowingCredential AccessCollects browser credentials, cookies, and tokens while enumerating files for exfiltrationMicrosoft Defender for Endpoint
– Information stealing malware activity  
– Suspicious DPAPI activity
– Possible theft of passwords and other sensitive web browser information 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 current information available in the Defender portal about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to help prevent, mitigate, or respond to associated threats found in customer environments:

• Amatera Stealer: Rebranded ACR Stealer With Improved Evasion, Sophistication
• Double Trouble: Latrodectus and ACR Stealer observed spreading via Google Authenticator Phishing Site

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

Advanced hunting queries

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

Run the query below to identify suspicious commands executed through ClickFix-based activity observed while delivering this stealer

DeviceRegistryEvents | where RegistryKey has "RunMRU" | where (RegistryValueData has_all ("rundll32", "@ssl", " /c ", " start ") and (RegistryValueData matches regex @"\\\\[^\\]+@ssl\\[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\\\w+\.\w+,#1" or RegistryValueData matches regex @"(?i)pushd \\\\[^\\]+@ssl\\[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} ")) or RegistryValueData has_all ("@ssl", " /c ", "conhost --headless ") and RegistryValueData contains "rundll32"

Run the query below to identify scheduled task creation used for persistence by a malicious PowerShell script

DeviceProcessEvents | where InitiatingProcessFileName =~ "powershell.exe" | where InitiatingProcessCommandLine has_all ("-Command", "powershell") | where ProcessCommandLine has_all ("schtasks", " /run /tn ", " Autoupdate ") and ProcessCommandLine matches regex "[0-9]{8}"

Run the query below to identify suspicious MSHTA launch through PowerShell

DeviceProcessEvents | where InitiatingProcessParentFileName has "explorer.exe" | where InitiatingProcessFileName =~ "powershell.exe" and InitiatingProcessCommandLine in~ ('"PowerShell.exe" ', '"PowerShell.exe"') | where ProcessCommandLine has_all ('"mshta.exe" https://') and ProcessCommandLine matches regex "/[0-9]{7}" MITRE ATT&CK techniques observed

The following mapping summarizes the primary tactics and techniques observed across the two ACR Stealer intrusion chains. The mapping is intended to help defenders align observed behaviors with existing detection coverage, response playbooks, and hunting priorities.

TacticTechniqueObserved behaviorInitial AccessDrive-by Compromise; User ExecutionClickFix lure prompts command execution.ExecutionCommand and Scripting Interpreter: Windows Command Shell; PowerShell; Pythoncmd.exe, PowerShell, and pythonw.exe launch staged payloads.ExecutionSystem Binary Proxy Execution: Rundll32; MshtaRundll32 loads WebDAV DLLs; mshta.exe runs remote HTA content.PersistenceScheduled Task/Job: Scheduled TaskHidden scheduled task maintains user-logon execution.Defense EvasionObfuscated Files or Information; Masquerading; Indicator Removal: Clear Command HistoryObfuscation, timestomping, history clearing, and masquerading.Defense EvasionObfuscated Files or Information: SteganographyJPEG pixel data hides the encrypted payload.Defense Evasion / ExecutionReflective Code Loading; Process InjectionIn-memory shellcode execution via runtime API resolution.Credential AccessCredentials from Web BrowsersBrowser stores and DPAPI activity used to recover credentials and tokens.CollectionData from Local System; Data StagedPDFs, Office files, and synced enterprise data are staged.Command and ControlWeb Service; Dead Drop ResolverInfrastructure and blockchain RPC endpoints resolve payload or C2 data. Indicators of compromise (IOC) Campaign 1IndicatorDescriptionlooksta[.]icuC2 domaincontrite.quirksturdy[.]icuC2 domainux.strainedeasily[.]icuC2 domaincpppemwjewjoiwejow[.]saleC2 domainbreaksd.wifihot[.]icuC2 domainwalter.filloco[.]icuC2 domainfast.raidher[.]icuC2 domainapigrokcloud[.]icuC2 domainCampaign 2enhanceblabber[.]ccC2 domaindeep-harborio[.]com1st Stage payload hosting siteauramatrixa[.]com1st Stage payload hosting sitezealpraxis[.]com1st Stage payload hosting siteprism-vertex[.]com1st Stage payload hosting siteprism-matrixs[.]com1st Stage payload hosting siteproton-network[.]com1st Stage payload hosting sitecreativecommunityinfo[.]artPayload hosting site References

• Intelligence Insights: May 2026 | Red Canary
• Possible ACR Stealer From Page Impersonating Claude

Learn more

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

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

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

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

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

The post ACR Stealer: Two observed intrusion chains amid increased threat activity appeared first on Microsoft Security Blog.

In this article

1. Real-world scenarios
2. Best Practices: Identity + RBAC + Scope + Safe Tool Binding
3. Looking Ahead

AI agents aren’t only smarter API callers. They plan, chain actions across systems, and invoke tools in sequences while no single human explicitly approves each step. The architectural reality may introduce identity and authorization challenges that organizations are still evolving to address.

When an agent operates without a managed identity and least-privilege role-based access controls (RBAC), it can access or modify sensitive data beyond intended permissions if controls are not properly configured. Since agents can operate across multiple systems within a single workflow, a misconfigured permission may increase the potential impact compared to traditional service account scenarios, depending on how the system is configured and scoped. Organizations are deploying agentic capabilities (multi-step automation, delegated actions, tool use) faster than their identity and authorization models are evolving to safely constrain them.  

The resulting exposure can be significant and may include risks such as unauthorized data access, unintended writes or deletions, and potential privilege escalation arising from overly broad role assignments. In some cases, these conditions can also contribute to gaps in auditability, which may make cyberattack detection, incident response, and regulatory inquiries more complex than necessary.

The right mental model is to treat every agent as a first-class principal: give it a lifecycle-managed identity, assign explicit roles, scope its permissions tightly, and scope tool usage to a preconfigured tools manifest or configuration. 

Real-world scenarios

The risk can occur in real-world implementations. Consider a common pattern: a team provisions an agent with a broad “Reader” role because it’s quick and the initial use case seems read-only. Then the workflow expands to include fixing issues it finds, and suddenly the agent needs write access too. Rather than rethinking the role design, teams grant something broader than intended and move on.

The scope creep is quiet, incremental, and rarely revisited. A related problem emerges when agents work across multiple tools. An agent with access to email, files, a ticketing system, and a code repository may look low-risk at each individual integration, but the combination lets it correlate data across systems and take actions no one explicitly authorized as a whole. Combined access across systems may result in broader effective permissions than evaluated individually.

Underneath both scenarios is a question that teams consistently fail to answer cleanly: is the agent acting under its own identity, a delegated user scope, or some mix of both? That ambiguity matters because it determines who’s accountable when something goes wrong, and what approvals were actually required.

When the answer isn’t documented and enforced upfront, it shows up later in the worst possible context: an incident where logs might capture what tool was called but can’t answer key questions such as: who authorized the action, under what role, or whether it was within intended scope. Sensitive data may be retrieved or summarized beyond its intended audiences if controls are not properly scoped.

An agent helpfully automates a remediation step and modifies or deletes something it shouldn’t have. Then the investigation stalls not because logs are missing, but because the identity model was never coherent enough to make them meaningful. This leaves organizations in the firefighting mood to resolve and solve questions their leadership cannot fully answer to customers, press, or auditors.

Best Practices: Identity + RBAC + Scope + Safe Tool Binding

For best practices in designing agentic identity and authorization, implementing multiple controls is intended to help reduce the potential impact of agent actions when configured and applied appropriately, while helping make privilege decisions explicit and supporting accountability in the event of unexpected or unintended outcomes.

Recommended practices for teams are generally to establish and document:

(1) a unique, dedicated agent principal with a named owner and an explicit purpose

(2) least-privilege, task-based roles that are scoped to the specific resources and data the agent needs

(3) Controlled tool access intended to limit the agent to approved actions

(4) end-to-end auditability so you can answer “what happened, under what authority, and what changed?” quickly.

In practice, the time-limited aspect should typically apply to entitlements (role activation, tokens, or approvals) rather than trying to create a new identity for every task. Most real-world deployments keep the agent identity stable for lifecycle management, while using just-in-time (JIT) elevation to grant narrowly scoped privileges only for the duration of a specific workflow.

Start by making the agent afirst-class principal. Create a dedicated agent identity (not a shared secret or reused service account), document its purpose statement (“what it is allowed to do and why”), and assign clear human ownership for approvals and incident response.

Build in lifecycle management from day one: onboarding checks, credential rotation, suspension/decommissioning procedures, and a fast shutdown mechanism that actually invalidates credentials and tokens. Then design role-based access controls (RBAC) around discrete tasks, not teams or org charts.

Model roles that match the smallest meaningful units of work, such as “Read-only knowledge retrieval,” “Summarize labeled documents,” “Create a draft ticket.” Avoid bundling unrelated permissions to reduce operational friction. When the workflow includes both evidence gathering and remediation, separate duties: use different roles (or different tools) for read versus write, and gate high-impact actions like delete, export, or privilege changes behind step-up approvals.

Scope everything and do it multiple times. Constrain permissions by resource boundary (tenant/subscription/workspace/site), by data boundary (collection, label, sensitivity), and by operation boundary (read/write/export/admin).  

The goal is to help make the where and what of access as explicit as the who. Pair this with safe tool binding by exposing a curated and approved set of tools/actions to the agent, and require explicit allowlists for high-impact operations.

This is where JIT for agents can help manage privilege exposure when implemented appropriately, such as, keep the baseline role minimal, use time-limited entitlements (temporary role activation, short-lived tokens, or per-action approvals) when the workflow genuinely requires higher privilege—and automatically drop back to the baseline when the workflow completes.

Finally, design systems to verify explicitly at every step whenever feasible. Downstream tools and services must re-check claims, roles, and scope on each call rather than trusting the orchestrator implicitly; otherwise, the “weakest link” becomes any integration that assumes upstream validation is sufficient.

Consider incorporating accountability controls as a core product feature, not an afterthought. Instrument agent actions end-to-end so logs capture the agent identity, role used, effective scope, resource accessed, action taken, “on behalf of” user (if applicable), timestamps, and correlation IDs that stitch together orchestrator → tool call → downstream system.

Without those fields, teams can’t reliably reconstruct intent or containment boundaries during an incident. Build and test revocation and recovery paths the same way you test feature reliability: practice disabling the agent identity, rotating credentials, and executing rollback/compensating actions for common failure cases (e.g., bulk ticket creation gone wrong, unintended writes, or export attempts). Operationalize governance with regular access reviews, removal of stale permissions, and mandatory re-approval when workflows change materially. And don’t stop at individual roles—deploy tools and processes that analyze aggregate permissions, because the real risk often emerges when multiple “reasonable” roles combine to enable a high-impact chain of actions.

Common pitfalls tend to undermine these controls in predictable ways. The fastest way to create long-term risk is granting broad Owner/Admin roles to unblock a pilot, then never coming back to refactor permissions once the workflow “works.” Shared secrets across multiple agents erase accountability and make revocation slow and incomplete.

Relying on prompts or “the agent will only do X” narratives instead of hard authorization boundaries invites prompt injection and workflow drift. Without the underlying tool invocations, scopes, and downstream authorization decisions, logging only the LLM response creates an audit trail that looks present but is useless for forensics.

Temporary access that lacks an expiry mechanism becomes permanent access in practice. Teams can avoid these anti-patterns by defaulting to task-based roles, enforcing explicit scopes and tool allowlists, using JIT time-limited entitlements for elevation, re-checking authorization in every downstream system, and treating access review and revocation testing as required operational hygiene—not optional maturity work.

Looking Ahead

Agents are quickly moving from helpers to autonomous actors across email, files, tickets, and cloud resources; driving tighter coupling between identity governance, fine-grained authorization, and tool/action policy.

In the next 30–90 days, inventory your agent identities, remove broad roles, introduce task-scoped RBAC, and require safe tool binding plus end-to-end audit logs (with monitoring) before expanding deployments—especially for cross-tenant/guest agents, B2C agents, and agent ecosystems.

Read the Pattern & Practice (PnP): Least Privilege for Agents and use it as a checklist to close the gaps that most reduce impact: ownership, scope, tool allowlists, and fast revocation. 

The post Least privilege for AI agents: Identity, access, and tool binding appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. How the attack started: GitHub Actions pwn request
3. Mitigation and protection guidance
4. Learn more

On July 14, 2026, Microsoft Threat Intelligence identified a coordinated supply chain compromise of the @asyncapi npm organization, a widely used set of packages for the AsyncAPI specification and code generation. Five package versions across four package names were republished within roughly ninety minutes, each carrying the same maliciously injected loader: @asyncapi/specs (in both the 6.11.2-alpha.1 prerelease and 6.11.2 stable release), @asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, and @asyncapi/generator-helpers@1.1.1.

Because @asyncapi/specs is a transitive dependency of numerous AsyncAPI tooling packages, this attack affected developer workstations, CI/CD pipelines, container builds, or production services that resolved and imported the affected versions during the exposure window. Unlike the more common postinstall-hook supply-chain pattern, this campaign executes at module-load (import/require) time. When any consuming build or application imports a poisoned package, the injected block runs immediately. Because the trigger is an import rather than an install script, the common npm install –ignore-scripts mitigation does not neutralize it. The second stage decrypts and evaluates a Miasma modular runtime with active command and control (C2), persistence, and decentralized fallback channels. Although disabled in this instance, credential-harvesting, propagation, and additional high-risk modules could be enabled through persistence.

Microsoft Defender Antivirus detects and blocks malicious artifacts as Trojan:JS/MiasmStealer.SC  and Trojan:Script/Supychain.A. Microsoft Defender for Endpoint provides behavioral coverage for the suspicious detached Node.js process spawn, IPFS retrieval, and persistence activity. Organizations should immediately remove all five affected versions, purge npm and Yarn caches, hunt for sync.js under the NodeJS masquerade directories, block outbound connections to 85.137.53[.]71 on ports 8080, 8081, and 8091, and rotate all credentials accessible from any environment that imported the compromised packages. Detailed hunting queries, indicators of compromise, and mitigation guidance are provided in the succeeding sections.

Attack chain overview Figure 1. End-to-end attack chain from CI/CD pipeline compromise through import-time execution to IPFS second-stage fetch, with C2 infrastructure and affected packages.

The compromise originated from a pwn request against asyncapi/generator. A misconfigured GitHub Actions workflow (pull_request_target) executed attacker-controlled pull-request (PR) code, exposed the asyncapi-bot personal access token (PAT), and enabled unauthorized pushes to auto-publish branches. The legitimate GitHub Actions OpenID Connect (OIDC) release workflows then published the poisoned packages under the automated identity npm-oidc-no-reply@github[.]com, producing artifacts with valid provenance signatures built from unauthorized source commits.

The campaign progressed through six phases, shown in Figure 1:

1. Pipeline compromise. The attacker exploited a vulnerable GitHub Actions workflow to steal a privileged bot token.
2. Code injection. Heavily obfuscated loaders were inserted into one source file per package.
3. Staged release. An alpha prerelease was followed by a stable release 24 minutes later, with a byte-identical payload, expanding blast radius.
4. Delivery. Consumers pulled poisoned versions through normal npm and Yarn dependency resolution; –ignore-scripts was not effective.
5. Import-time execution. require() or import triggered the malicious main(), which spawned a hidden detached child process.
6. IPFS second-stage fetch. The child downloaded sync.js from IPFS and wrote it to an OS-specific “NodeJS” masquerade directory.

The Miasma runtime provided encrypted bootstrap, persistence, C2 communication, data return paths, and resilient discovery via Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS. Six additional capability modules (credential harvest, encrypted exfiltration, supply-chain propagation, metamorphic generation, AI-tool poisoning, and sandbox evasion) were implemented but disabled in this build.

Time (UTC)Observed event~07:10@asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, and @asyncapi/generator-helpers@1.1.1 republished with the injected loader.08:06:20@asyncapi/specs@6.11.2-alpha.1 published with the malicious importer prepended to index.js.08:30:09@asyncapi/specs@6.11.2 stable published with a byte-identical payload, widening downstream reach.08:49:22First observed downstream fetch of the stable 6.11.2 tarball into a Yarn cache during dependency installation. How the attack started: GitHub Actions pwn request

The attack chain began with a malicious pull request targeting the asyncapi/generator repository’s docs-preview automation. Opened as PR #2155, it carried the attacker-controlled commit 47be388, timestamped 05:08:58 UTC on July 14. The associated Docs Preview (Netlify) workflow started at 05:11:05 UTC.. Although the PR and source fork were later removed, the workflow record remains available.

The pull request PR #2155 targeted manual-netlify-preview.yml, which combined two unsafe choices: it used pull_request_target, placing the job in the base repository’s security context, and it checked out the pull request’s untrusted head commit. The run had a broadly privileged GITHUB_TOKEN, checkout credentials persisted in the local Git configuration until post-job cleanup (the default behavior of actions/checkout), and steps that referenced repository secrets.

The submitted MDX contained code was designed to retrieve JavaScript from rentry[.]co/elzotebo999 and evaluate the response. The public log confirms that the malicious commit was processed by the privileged workflow, but it does not show whether the rentry[.]co web request succeeded or whether a credential was stolen. Later push records identify asyncapi-bot as the authenticated actor. Together, these records establish that the vulnerable workflow ran before the bot-authenticated pushes, but they do not establish how the credential was obtained.

The underlying workflow weakness had been identified before the compromise. On April 29, a proof-of-concept examined whether untrusted pull-request content could be executed in the privileged docs-preview workflow. A May 17 proposal then sought to separate untrusted build activity from steps that received repository secrets and was still under review when the incident occurred.

Trusted publishing became the delivery mechanism

Once the attacker could push commits as asyncapi-bot, there was no need to compromise npm or construct a separate publishing channel. The attacker could ride the project’s normal release path and let its trusted pipeline do the distribution. Commit 3eab3ec carries a timestamp of 06:58:42 UTC, while a surviving push-triggered workflow started at 07:05:42 UTC. Its message, “fix: test release workflow on next”, matched the release workflow’s commit-message condition. The legitimate release-with-changesets.yml workflow then published three poisoned packages at approximately 07:10 UTC.

A closely linked compromise subsequently affected asyncapi/spec-json-schemas. The malicious lineage first triggered workflows on alpha between 07:56 and 08:04 UTC. The same malicious commit was later pushed to master at approximately 08:14 UTC, followed by a child commit at 08:28 UTC. The legitimate if-nodejs-release.yml workflow published @asyncapi/specs@6.11.2-alpha.1 at 08:06 UTC and @asyncapi/specs@6.11.2 at 08:30 UTC.

All five malicious versions were published through npm trusted publishing using GitHub OIDC and carried valid provenance attestations. The attestations accurately identified the legitimate repositories, commits, and workflows that created the packages, even though the triggering commits were unauthorized.

Figure 2. Miasma runtime capabilities recovered from sync.js, including active modules and implemented-but-disabled modules.

The payload operates in multiple stages, each designed to increase evasion and ensure resilient execution. Stage 0 establishes stealth by declaring no npm lifecycle hooks. Stage 1 executes the loader at require-time and spawns a hidden child process. Stage 1b deobfuscates the IPFS fetch logic and downloads sync.js. Stage 2 decrypts the ~8.2 MB encrypted bundle through three cryptographic layers. Stage 3 initializes the full Miasma modular runtime with C2, persistence, and decentralized fallback channels.

Stage 0: No lifecycle hooks declared

The absence of lifecycle hooks is a deliberate evasion choice. Security tooling that focuses on preinstall/postinstall auditing will not flag these packages. All affected packages declared no preinstall, install, or postinstall hooks in package.json. This bypassed hook-focused scanners and left import-time execution as the real trigger path.

Stage 1: Import-time loader

The loader executes the moment any application imports the compromised module; no user action beyond dependency resolution is required. The attacker placed the same bootstrap pattern in each package’s exported entry path, so normal application startup would trigger execution automatically.

• @asyncapi/specs → index.js
• @asyncapi/generator → lib/templates/config/validator.js
• @asyncapi/generator-helpers → src/utils.js
• @asyncapi/generator-components → lib/utils/ErrorHandling.js

spawn('node', [payloadPath], { detached: true, stdio: 'ignore', windowsHide: true, }).unref(); Stage 1b: IPFS fetch

The inner payload reveals hard-coded IPFS content identifiers and OS-aware drop logic. This intermediate stage reconstructs the transport routine at runtime, so the larger second stage never appears in cleartext in the published package.

Package setIPFS CIDspecsQmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyfgenerator-familyQmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 const FILE_URL = 'hxxps://ipfs[.]io/ipfs/'; const FILE_NAME = 'sync.js'; function getTargetDirectory() { if (process.platform === 'win32') return '%LOCALAPPDATA%\NodeJS'; if (process.platform === 'darwin') return '~/Library/Application Support/NodeJS'; if (process.platform === 'linux') return '~/.local/share/NodeJS'; return '~/.config/NodeJS'; } Stage 2: Encrypted payload (sync.js)

Despite appearing cryptographically sophisticated, the entire decryption chain uses static embedded key material, meaning the runtime can be recovered offline without execution. The layered design primarily increases analyst effort; every secret required to unwrap the bundle ships inside the loader.

• sync.js is ~8.2 MB; all key material is static and embedded.
• HKDF-SHA256 uses master string rt-vault-master-key-32b-aaaaaaaa and info string rt-file-key.
• AES-256-GCM uses IV = first 12 bytes and auth tag = last 16 bytes of the blob.
• The decrypted string is ROT-94de-rotated and then executed with eval().

Stage 3: Miasma runtime

The  runtime is a command framework identified as M-RED-TEAM v6.4 with campaign configuration miasma-train-p1. In this build’s configuration, persistence and C2 are active, but data collection and propagation modules remain dormant. The runtime supports traditional remote access trojan (RAT) commands, including directory listing, file retrieval, file upload, remote shell execution, proxying, and data exfiltration. Persistence is installed through platform-specific mechanisms: a Windows HKCU Run key (miasma-monitor), a Linux systemd user unit (miasma-monitor.service), and macOS shell RC injection (.zshrc, .bashrc, or .bash_profile).

• Recovered identifiers: M-RED-TEAM v6.4, miasma-train-p1, and miasma-test-org.
• Persistence: Win HKCU Run value miasma-monitor, Linux miasma-monitor.service, and macOS user-space shell/launch persistence.
• Primary endpoints: 85.137.53[.]71:8080 (C2), 85.137.53[.]71:8081 (upload), 85.137.53[.]71:8091 (management).
• Fallback channels include Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS.
• Disabled in the analyzed build: recon, propagation, AI-poisoning, metamorphic generation, and evasion.

Credential harvesting (disabled in this build)

The framework contains broad credential-access code targeting secrets across major platforms that a developer or continuous integration and continuous delivery (CI/CD) system might access, including browser-saved passwords from multiple browsers.

The framework targets over 100 environment variable names across source control (GITHUB_TOKEN, GITLAB_TOKEN), npm (NPM_TOKEN, NODE_AUTH_TOKEN), AWS (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY), Azure (AZURE_CLIENT_SECRET), GCP (GCLOUD_SERVICE_KEY), container/Kubernetes (DOCKER_TOKEN, K8S_AUTH_TOKEN), secrets managers (DOPPLER_TOKEN, VAULT_TOKEN), and AI platforms (ANTHROPIC_API_KEY, OPENAI_API_KEY).

Credential files targeted from disk include .npmrc (npm tokens), .aws/credentials (AWS keys), kubeconfig (Kubernetes API), id_rsa/id_ed25519 (SSH keys), .vault-token (HashiCorp Vault), .netrc (Git/HTTPS auth), .docker/config.json (Docker registry), and google_credentials.json (GCP service accounts). When a GITHUB_TOKEN is available, the framework can enumerate accessible repositories and CI/CD context through GitHub APIs.

Mitigation and protection guidance

Review dependency trees, lockfiles, artifact repositories, and CI caches for the five compromised versions, including transitive references.

Pin known-good versions: @asyncapi/specs 6.11.1 or earlier, @asyncapi/generator 3.3.0, @asyncapi/generator-components 0.7.0, and @asyncapi/generator-helpers 1.1.0.

Do not rely on npm install –ignore-scripts as a mitigation; this campaign executes when the module is imported, not through a lifecycle hook.

Purge npm and yarn caches on affected developer endpoints and build hosts, especially if the compromised tarballs were written into shared CI caches.

Hunt for sync.js and the NodeJS masquerade directory on endpoints, and investigate any detached Node.js execution that references the IPFS CID or the sync.js file name.

Block or alert on retrieval of the specific IPFS CID and monitor for network connections to 85.137.53[.]71 on ports 8080, 8081, and 8091.

Rotate credentials and secrets from a clean host if a build system or workstation imported a compromised version, because second-stage execution can expose tokens and build integrity.

Ensure that Microsoft Defender Antivirus cloud-delivered protection, Microsoft Defender for Endpoint telemetry, and Microsoft Defender XDR investigation workflows are enabled across developer and CI assets.

Update to NPM CLI to npm CLI v11.10.0+ or Use the NPM CLI min-release-age feature.

Organizations that do not rely on IPFS for business operations can reduce their attack surface by blocking public IPFS gateways (ipfs.io, dweb.link, cloudflare-ipfs.com, and others) at the network perimeter. This proactive measure removes an increasingly common payload delivery channel used in supply chain campaigns without affecting standard development workflows.

Organizations that produce software artifacts should also review their own release hardening. Because this incident appears consistent with CI/CD pipeline abuse through GitHub Actions OIDC publishing, defenders should review token scopes, workflow approvals, protected environments, release provenance, and anomaly detection around automated package publication. Supply chain response cannot stop at host triage; it must also include verification that the release process itself has not been subverted.

After remediation, validate recovery deliberately. Rebuild affected projects from a known-good dependency baseline, confirm that compromised hashes are absent from package caches and artifact stores, and review endpoint telemetry for any lingering sync.js, NodeJS directory artifacts, or suspicious node child processes. For development organizations that share base images or golden build runners, rebuild those images as well so future jobs do not silently inherit poisoned caches or post-compromise persistence.

Indicators of compromise PackageVersionInjected fileTarball SHA-256@asyncapi/specs6.11.2-alpha.1index.jsd425e4583cc6185d41e95c45eda00550045a5d1919b9a012236a4520d009dbd7@asyncapi/specs6.11.2index.js9b2e65db653ca8575c9b10eefb9a80c6006404812c2ec212bf5675e3c690233b@asyncapi/generator3.3.1lib/templates/config/validator.jsbfaeb987faa6de2b5a5eb63b1233d055215b09b0349a9394f2175fd7cdf385e4@asyncapi/generator-components0.7.1lib/utils/ErrorHandling.js082d733db0687dcd768104972b065d4b58cb1e6043688c6c20fa3702337f36ab@asyncapi/generator-helpers1.1.1src/utils.js34014776d3d3ff11bc4439b02fd7ac0f02a887eb3a052eeafff236e2f6db8ad1 TypeIndicatorPublisher identitynpm-oidc-no-reply@github[.]comIPFS URLhxxps://ipfs[.]io/ipfs/Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyfIPFS CIDQmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf@asyncapi/generator lib/templates/config/validator.jsb9993a8ad0518849416798cf29668256ccb96598fc4423501ccab5312812653a@asyncapi/generator-components lib/utils/ErrorHandling.jsb270bdf8e2274ea1af0a6eed74d8f10e5fe61012d6cc226a43cc7cc7fd9f6292@asyncapi/specs index.js (alpha AND stable — identical)8351d251cf0b5a0bd82242deaa0a14e3e1394418d55c0f4259dac4303b79fc0c@asyncapi/generator-helpers src/utils.js6e78713b75bd34828d49896176627f7face7aa9036cd874f2e02d9f23a9a9c71Wrapper – sync.js (generator-family IPFS object)24b9ee242f21a73b55f7bb3297eafb33c60840907386b542ed79fc6b72365168Central C285.137.53[.]71:8080Upload service85.137.53[.]71:8081Management configuration85.137.53[.]71:8091Windows drop path%LOCALAPPDATA%\NodeJS\sync.jsLinux drop path~/.local/share/NodeJS/sync.jsmacOS drop path~/Library/Application Support/NodeJS/sync.jsFallback drop path~/.config/NodeJS/sync.jsRuntime lock file~/.config/.miasma/run/node.lockmDNS service_miasma._tcpHTTP path examples/api/v1/beacon, /api/v1/file-result, /api/v1/file-content/<cid> Microsoft Defender XDR detections

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

TacticObserved activityMicrosoft Defender coverageInitial access / ExecutionCompromised packages published though GitHub Actions OIDC trusted publishingMicrosoft Defender Antivirus
– Trojan:Script/Supychain.A
– Trojan:JS/MiasmStealer.SC
– Trojan:JS/SpawnLoader.MKV!MTB
 
Microsoft Defender for Endpoint
– Suspicious Node.js process behavior
– Suspicious Node.js script executionExecution / Defense evasionModule import triggers obfuscated main(), which spawns a hidden detached nodeMicrosoft Defender Antivirus
– Trojan:JS/VaultLoader.MJZ!MTB

Microsoft Defender for Endpoint 
 – Suspicious Node.js process behavior
– Suspicious Node.js script executionPersistenceOS-specific persistence installed Microsoft Defender for Endpoint 
 – Anomaly detected in ASEP registry
– Suspicious modification of shell profile
– Suspicious Linux service created Advanced hunting queries

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

Persistence drop and detached spawn

// Query 1: sync.js dropped under a NodeJS directory or related detached execution union isfuzzy=true ( DeviceProcessEvents | where Timestamp > ago(30d) | where (ProcessCommandLine has "sync.js" and ProcessCommandLine contains_cs "NodeJS") or ProcessCommandLine has "Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf" | project Timestamp, DeviceName, Evidence = ProcessCommandLine, Initiator = InitiatingProcessCommandLine, EventType = "Process" ), ( DeviceFileEvents | where Timestamp > ago(30d) | where FileName == "sync.js" and FolderPath contains_cs "NodeJS" | project Timestamp, DeviceName, Evidence = strcat(FolderPath, "\\", FileName), Initiator = InitiatingProcessFileName, EventType = "File" )

IPFS CID retrieval

// Query 2: outbound retrieval of the IPFS second stage DeviceNetworkEvents | where Timestamp > ago(30d) | where RemoteUrl has "ipfs.io" | where RemoteUrl has "Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf" | project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName

Poisoned package artifacts in caches

// Query 3: presence of a poisoned tarball in caches DeviceFileEvents | where Timestamp > ago(30d) | where SHA256 in ( "d425e4583cc6185d41e95c45eda00550045a5d1919b9a012236a4520d009dbd7", "9b2e65db653ca8575c9b10eefb9a80c6006404812c2ec212bf5675e3c690233b", "bfaeb987faa6de2b5a5eb63b1233d055215b09b0349a9394f2175fd7cdf385e4", "082d733db0687dcd768104972b065d4b58cb1e6043688c6c20fa3702337f36ab", "34014776d3d3ff11bc4439b02fd7ac0f02a887eb3a052eeafff236e2f6db8ad1") | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName

Suspicious Node.js execution

DeviceProcessEvents | where Timestamp > ago(3d) | where FileName in~ ("node", "node.exe") | where ProcessCommandLine has "node.exe -e \"const _0x5af5e1" or ProcessCommandLine has "node -e \"const _0x5af5e1" | project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessFolderPath Microsoft Security Copilot

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

For this campaign, Security Copilot can help analysts summarize affected devices, pivot from the package hashes to endpoint evidence, identify hosts that communicated with the IPFS path or C2 infrastructure, and build remediation actions such as cache purge, credential rotation, and containment sequencing for impacted developer systems and build runners.

Threat intelligence reports

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

As with other active supply-chain investigations, defenders should monitor for updated intelligence on package status, additional affected versions, infrastructure changes, and newly surfaced post-compromise tradecraft. Microsoft will continue to incorporate validated indicators and detections into Microsoft security products as the investigation evolves.

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 Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery appeared first on Microsoft Security Blog.

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.