That model increasingly reflects a world that no longer exists.

Today’s enterprises operate thousands of interconnected workloads across hybrid and multicloud environments. Mission-critical applications power revenue-generating services, customer experiences, and core business operations that cannot simply be taken offline whenever a security update becomes available. At the same time, vulnerabilities are becoming more visible, more widely distributed, and more rapidly weaponized than ever before.

The result is a growing gap between how quickly organizations can safely remediate vulnerabilities and how quickly adversaries can exploit them. It is time to rethink how the industry approaches security during the critical period between disclosure and remediation. 

The patch window has collapsed 

Traditional vulnerability management was built on the assumption that defenders could move faster than attackers. In many cases, they could.

When a vulnerability was disclosed, organizations had time to understand the issue, assess affected systems, test patches, coordinate change windows, and deploy fixes before widespread exploitation occurred.

Today that timeline is rapidly shrinking.

Modern attack campaigns operate at internet scale. Security research, public disclosures, proof-of-concept exploits, and threat intelligence circulate globally within hours. A vulnerability announced in the morning can become the focus of active scanning and exploitation efforts by the afternoon.

Meanwhile, the operational realities of enterprise environments have not changed. Organizations still must: 

• Understand the vulnerability and its business impact. 
• Identify affected systems across large estates. 
• Evaluate dependencies and compatibility concerns. 
• Validate fixes in test environments. 
• Coordinate deployment schedules. 
• Monitor for regressions and operational risk. 

These are not signs of inefficiency. They are necessary safeguards for business-critical environments. The challenge is that while defensive processes continue to require days or weeks, offensive timelines are increasingly measured in hours. 

That creates one of the most dangerous periods in modern cybersecurity: the window between awareness and remediation.

AI is expanding the defender’s challenge 

AI is helping organizations modernize operations, accelerate development, and improve security outcomes. But the same technological advances are also changing the economics of offensive operations.

Historically, transforming a newly disclosed vulnerability into an effective attack often required extensive manual research and deep technical expertise. Security researchers and attackers alike needed to analyze documentation, understand exploit conditions, study affected software, and develop attack techniques.

Many of those steps can now be accelerated.

AI-assisted workflows can help analyze vulnerability disclosures, identify likely attack paths, evaluate technical dependencies, and summarize complex technical information far more quickly than traditional manual processes.

As these capabilities become more accessible, the timeline between disclosure and exploitation continues to compress. The result is a structural imbalance. 

Defenders remain responsible for protecting entire environments that may include thousands of servers, applications, databases, containers, and network assets. Attackers only need to identify a single viable path to exploitation. 

This asymmetry is driving organizations to ask an increasingly important question: What happens before the patch is deployed?

Why existing security approaches fall short 

The security industry has invested heavily in improving visibility.

Organizations today have access to more vulnerability data, threat intelligence, analytics, and detection capabilities than ever before. Security platforms can rapidly identify affected systems, prioritize remediation, and alert defenders to emerging threats.

These capabilities are essential. But awareness alone does not reduce exposure. Many organizations find themselves in a position where they know exactly which systems are vulnerable but cannot immediately patch them. 

For example, a business-critical application may require extensive validation before updates can be deployed. A manufacturing system may depend on software that cannot be taken offline during production hours. A regulated environment may require additional testing and approval processes before changes can be implemented.

In these situations, the challenge is not identifying risk. The challenge is reducing risk while remediation is still underway.

Visibility, detection, and prioritization help organizations understand the problem. They do not necessarily provide a mechanism for containing that risk immediately.

As attack timelines continue to compress, the industry needs a complementary approach focused on exposure reduction rather than simply exposure awareness.

Why the network is emerging as the fastest control plane 

When a workload cannot immediately defend itself, another layer must help provide protection. Increasingly, organizations are looking to the network. 

Unlike endpoint-based controls, network-level protections operate around workloads rather than inside them. This distinction becomes particularly important during periods of elevated risk.

The network already understands communication patterns, connectivity requirements, trust relationships, and traffic flows. It sits at a strategic position where organizations can influence how systems interact with one another without necessarily modifying the applications themselves.

This creates opportunities to reduce exploitability while remediation efforts are underway. Network-enforced protections can help: 

• Restrict access to vulnerable systems. 
• Limit exposure to potential attack paths. 
• Reduce opportunities for lateral movement. 
• Segment high-risk assets. 
• Contain potential blast radius. 
• Adjust controls dynamically as new information becomes available. 

Perhaps most importantly, network controls can often be implemented significantly faster than enterprise software patches can be validated and deployed.

The objective is not to avoid patching. The objective is to create a meaningful layer of defense during the period when patching has not yet been completed.

As AI compresses the time between vulnerability disclosure and exploitation, organizations need a defensive layer that can act immediately, without waiting for every workload to be patched, every application to be modified, or every endpoint agent to understand a new threat.

The network is uniquely positioned to become that control point: it already sits in the path of communication, has visibility across heterogeneous workloads, and can enforce protections consistently across large cloud estates without changing the applications themselves. More importantly, network controls can increasingly move beyond simple IP, port, and signature-based blocking toward context-aware, adaptive enforcement that constrains the specific behavior an exploit depends on while preserving legitimate traffic.

Consider an HTTP/2 denial-of-service vulnerability: the safest interim guidance may be to disable HTTP/2 entirely until systems are patched, but that can carry significant application and performance impact. A more precise network and workload-aware response could instead bound the exploitable behavior—limiting concurrent streams, tightening request constraints, or rate-limiting abusive connection patterns—while keeping the service available. This is why the network is becoming more than a connectivity layer: it can serve as a programmable, ubiquitous enforcement fabric that buys organizations the most valuable commodity during a zero-day—the time to patch safely.

In an era where vulnerabilities may be weaponized within hours, every day of risk reduction matters.

The rise of adaptive security 

The next evolution of cybersecurity is unlikely to rely solely on static policies or manual response processes. Modern environments are simply too large, dynamic, and interconnected. 

Organizations increasingly need security systems capable of understanding risk, evaluating context, and adapting protections as conditions change. This shift points toward a broader industry trend: adaptive security. 

Adaptive security systems aim to move beyond predefined rules toward continuously improving risk management. Rather than treating every vulnerability equally, they seek to understand the specific conditions that make a flaw exploitable and determine the most effective way to reduce exposure. At a high level, these systems must solve three critical challenges. 

First, they must understand the vulnerability itself. 

This requires ingesting information from security advisories, vulnerability disclosures, threat intelligence, exploit research, and other sources to develop a meaningful understanding of how a threat operates.

Second, they must correlate that understanding with real-world environments. 

A vulnerability only becomes a material risk when specific systems, configurations, connectivity paths, and exposure conditions exist. Understanding this context is essential to determining actual risk.

Third, they must translate intelligence into action. 

Insight without enforcement provides limited value. The ultimate goal is to reduce exposure through controls that can be applied quickly, consistently, and at scale.

AI is expected to play a significant role throughout this process, not merely as an analytical tool, but as an enabling technology that helps security systems understand complex relationships and make informed decisions faster than would otherwise be possible.

Looking at the future of cybersecurity

The cybersecurity industry has spent decades improving vulnerability management, patch deployment, and security operations. Those investments remain essential and will continue to be foundational elements of every organization’s security strategy. But the environment around us is changing.

Attackers are moving faster. Infrastructure is becoming more complex. AI is compressing timelines across the entire threat landscape. In this new reality, organizations cannot rely on patching alone. 

The future of cybersecurity will depend on an organization’s ability to reduce risk during the time between disclosure and remediation. Success will come from combining strong patch management practices with compensating controls capable of responding at machine speed.

The organizations that thrive will be those that treat security as a continuous, adaptive process rather than a sequence of point-in-time responses. The fundamental question is no longer whether vulnerabilities will emerge. They will. 

The question is how effectively organizations can protect themselves while they work to eliminate them.

As the patch window continues to collapse, the industry will need new approaches that complement traditional remediation strategies, reduce exposure quickly, and help defenders regain the one resource that has become increasingly scarce in modern cybersecurity: time.

Microsoft is investing in new and innovative capabilities able to provide immediate protection from the storm, buying organizations the time they need to safely validate and deploy a permanent patch without exposing their environment to unnecessary risk.

The post The patch window is collapsing: Why security needs a new control plane appeared first on Microsoft Security Blog.

As organizations adopt cloud-native architectures at scale, protecting workloads requires more than scanning. Today, 82% of container users run Kubernetes in production, making runtime visibility and protection critical for modern applications.¹

That change, from scanning workloads to protecting them where they run, is exactly what Frost & Sullivan describes in its Frost Radar™: Cloud Workload Protection Platforms, 2026. Out of more than 45 qualified vendors, it benchmarked 20, and it found the category moving to a single runtime security model, one that ties together code, cloud, runtime, identity, and the security operations center (SOC).

Within that market, Frost & Sullivan names Microsoft a visionary leader, its category for vendors that balance innovation with growth and help set the direction of the market. Microsoft is also the largest cloud workload protection platform (CWPP) provider by revenue, with an estimated share of more than 22% of the global CWPP market. In the analyst’s words:

“Microsoft is positioned as a visionary leader in this analysis for its scale and breadth of [Microsoft] Defender for Cloud within a unified framework. The platform stands out for its breadth of coverage across infrastructure, workloads, identities, entitlements, data, and applications, and for its deep integration with Microsoft’s broader security ecosystem, allowing organizations to secure modern and AI-native application lifecycles, while reducing operational complexity.”

Scale and breadth, in one framework. That is what customers are asking for, and it is where this category is heading. 

Why cloud workload protection is being redefined

For a long time, protecting a workload meant scanning its image, fixing known vulnerabilities, and hardening configurations before deployment. That still matters. But it is no longer enough, because what looks safe before deployment can become exploitable once the workload is running.

Most teams are also dealing with real sprawl. A modern estate spans several clouds and mixes containers, Kubernetes, serverless functions, microservices, and AI workloads. Every layer throws off its own signals, and those signals rarely connect on their own. One misconfiguration looks harmless until it sits next to an over-permissioned identity and a container that is already live. Then it is a path into production.

The tools were not built for this. Posture sits in one console, workload scanning in another, detection in a third, and teams are left connecting them by hand, usually in the middle of an incident. What they need instead is one platform that can:

• Bring posture, runtime, identity, and control-plane signals into one place.
• Rank risk by what is truly exploitable, not by a severity score alone.
• Stop risky workloads close to deployment, before they reach production.
• Get what it finds at runtime to the developers and the SOC who can act on it.

The market is moving the same way. Frost & Sullivan expects CWPP spending to grow from $6.43 billion in 2025 to about $7.95 billion in 2026, and 19.1% a year through 2030. That is teams voting with their budgets to modernize cloud security, meet regulation, and protect the workloads behind their apps, data, and AI services.

What distinguishes leading platforms

Frost & Sullivan scores vendors on two things: how fast they innovate and how fast they grow. But the report is blunt about something more telling: the bar for leadership has moved. It is now, in the analyst’s words:

“Increasingly defined by runtime telemetry depth, container, and K8s security, workload behavior analysis, cloud-native threat detection, remediation and response automation, SOC integration, AI workload protection, and global go-to-market execution.”

Put plainly, discovery, scanning, and compliance checklists no longer separate the leaders. Depth at runtime does. The platforms pulling ahead tend to share a few traits:

• They cover real ground, from infrastructure and workloads to identities, data, and applications, without asking you to bolt five products together.
• They go deep at runtime, not just posture and log review.
• They carry cloud detection and response (CDR) straight into the SOC.
• They connect code, cloud, and the SOC instead of treating each as its own island.
• They span clouds with both agent and agentless coverage, and they are moving quickly on AI and data security.

None of that is about longer findings lists. It is about context: seeing how the pieces connect and acting on the few that matter.

How Microsoft helps organizations protect cloud workloads

Microsoft’s capabilities address the problems customers raise most, and Frost & Sullivan points to the same strengths: 

“The strength in scaled runtime protection depth, strong CDR expansion, and ability to operationalize cloud runtime security across [Microsoft] Defender XDR, [Microsoft] Sentinel, GitHub, [Microsoft] Security Copilot, and the broader Microsoft security stack give Microsoft clearest advantages, particularly for large enterprises that already operate across Microsoft security, Azure infrastructure, GitHub, and Sentinel environments.”

Here is what that looks like in practice, starting from the problem in each case. 

1. Protect workloads while they are running

Microsoft Defender for Cloud watches workloads while they run. A lightweight sensor (eBPF-based) picks up Kubernetes events, process activity, and network traffic, and detections map to MITRE ATT&CK, so alerts line up with real cyberattacker behavior. Most of the recent effort has gone into the container layer: DNS detection for Kubernetes on Azure AKS, Amazon EKS, and Google GKE; anti-malware that blocks rather than just alerts; runtime protection for EKS Bottlerocket; and drift blocking when a binary changes mid-run.

Defender for Cloud can also act before a workload starts. Kubernetes’ gating applies policy at the cluster and namespace level, so a risky or non-compliant image is blocked before it ever starts. Frost & Sullivan calls this out as especially relevant to CWPP, because it puts preventive controls right next to production. That is the whole idea: catch a bad image before it becomes an incident, not after.

2. Get runtime signal to the SOC

Runtime signal only helps if it reaches the people who respond. With expanded CDR, Defender for Cloud ties runtime telemetry, Kubernetes audit data, process and network activity, control-plane events, and identity signals to specific workload incidents, then hands them to Microsoft Defender XDR and Microsoft Sentinel. A suspicious process in a running cluster does not land as a lonely alert. It arrives already connected to the identity that launched it and the activity around it.

For the SOC, that means faster answers and far less stitching signals together by hand.

3. Send runtime findings back to the developers who can fix them

Finding a problem at runtime is only half the work. Someone still has to fix it. Defender for Cloud links runtime context, exploitability, and attack-path detail to developer workflows through GitHub Advanced Security and Copilot Autofix, syncing both ways between security and development. A risk caught in production can go straight to the engineer who owns the code, get fixed at the source, and be checked afterward.

The right issue reaches the right owner, and security and DevOps finally work from the same list.

4. Extend protection to AI and across clouds

More and more, the workloads worth protecting are AI. Defender for Cloud supports model scanning and threat protection, including prompt injection and suspicious access, for Azure AI Foundry and Azure OpenAI, and AI security posture management for Google Vertex AI and Amazon Bedrock. It spans Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP), and hybrid environments with both agent and agentless coverage, and Microsoft Security Copilot adds guided investigation across the workflow.

Protection follows the workload, whether that is a new AI service or a third cloud.

What this signals for security leaders

For anyone choosing a workload protection platform this year, the shift in this report changes the questions worth asking. The ones to put at the top:

• Is workload protection part of one cloud security platform, or a separate tool wired onto the SOC after the fact?
• Can it stop a risky workload before production, or only flag it afterward?
• Does it connect runtime activity to identity, data, and control-plane context, and rank what is genuinely exploitable?
• Do its findings reach both the SOC and the developers who can act on them?
• Does it hold up across several clouds and AI workloads?

The vendors that can answer “yes” are the ones shaping what comes next, and the Frost Radar places Microsoft among them.

Bottom line

Frost & Sullivan’s Frost Radar™: Cloud Workload Protection Platforms, 2026 reinforces a clear shift. Cloud workload protection is leaving isolated scanning behind for runtime security that connects posture, identity, code, and the SOC. Frost & Sullivan positions Microsoft as a visionary leader, and the largest CWPP provider by revenue, because Defender for Cloud brings that range together in one framework, goes deep at runtime and in CDR, and plugs into the wider Microsoft security stack.

Learn more

• Read Frost & Sullivan’s Frost Radar™: Cloud Workload Protection Platforms, 2026 to see how leading vendors are evaluated and how the category is shifting toward unified cloud runtime security. 
• 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.

¹Kubernetes Established as the De Facto ‘Operating System’ for AI as Production Use Hits 82% in 2025 CNCF Annual Cloud Native Survey. PR Newswire, January 20, 2026.

The post Microsoft named a Leader in the Frost Radar™: Cloud Workload Protection Platforms, 2026 appeared first on Microsoft Security Blog.

MacSync Stealer is a macOS-focused information stealer that relies on changing infrastructure to deliver payloads, communicate with compromised devices, and exfiltrate data. Earlier reporting by RST Cloud identified the threat through a limited set of domains and documented rapid command-and-control (C2) replacement after public disclosure.

Microsoft Defender Experts expanded that view by correlating recurring endpoints and network behaviors across the activity. This behavior-led approach connected more than 30 domains and showed that the infrastructure supported more than C2 communication, extending into active collection, staging, and exfiltration. The findings demonstrate that although domains may rotate quickly, repeated execution patterns, request characteristics, staging behavior, and upload methods provide defenders with more durable opportunities to investigate MacSync Stealer activity. 

Activity overview 

Microsoft Defender Experts reviewed endpoint and network telemetry to determine which MacSync Stealer behaviors persisted as infrastructure changed. The investigation followed the activity from C2 communication through collection, staging, and exfiltration, using recurring technical traits to connect activity across rotating domains. Execution began from an interactive shell session consistent with ClickFix social engineering, where users are tricked into pasting or running commands in Terminal. The shell session used curl to retrieve attacker-controlled payload content, followed by script-driven execution and outbound communication. 

After execution, the malware communicated with attacker-controlled infrastructure using recurring URI paths, macOS User-Agent strings, API-key headers, and curl command-line options. These request traits became durable behavioral pivots because they remained consistent even as domains changed. The activity then progressed into collection behavior targeting macOS Keychain material, browser data, locally stored credentials, cloud and Secure Shell (SSH) credentials, and sensitive files from common user directories. 

The investigation also confirmed active data exfiltration, not just beaconing. Collected data was staged under temporary paths, compressed into an archive, split into chunks, and uploaded through HTTP PUT requests using curl with the –data-binary argument. Upload parameters such as upload_id, chunk_index, and total_chunks provided additional hunting opportunities that could be correlated with process, command-line, file, and network telemetry across the attack chain. 

Discovery of additional rotating infrastructure 

To identify related MacSync Stealer infrastructure, Microsoft Defender Experts required multiple endpoint and network behaviors to align before treating a domain as connected. Correlation focused on recurring traits across payload retrieval, C2 check-in, and exfiltration, including process ancestry, command-line patterns, request paths, headers, and upload parameters. Applying this standard linked more than 30 domains, making the domain count an outcome of the behavioral methodology rather than the primary finding. 

The strongest pivots combined network request shape with endpoint execution context. Related infrastructure shared recurring URI patterns such as /curl/, /dynamic?txd=, and /gate?buildtxd=; curl command lines using -k, -s, –max-time, and –data-binary; macOS User-Agent strings; API-key headers; and HTTP PUT uploads that included upload_id, chunk_index, and total_chunks parameters. RST Cloud used recurring URI patterns to surface eleven additional candidate domains and found a static API-key value shared across four confirmed C2 domains while the build token rotated per deployment. Domains were treated as related when multiple behavioral traits aligned across process, command-line, and network telemetry, reducing reliance on any single domain indicator. 

This finding reinforces a practical defender lesson: rotating infrastructure can weaken static domain blocking and retrospective IOC matching, but repeated request patterns and process behaviors create durable hunting opportunities. Figure 1 shows representative defanged command-line patterns used as pivots across payload retrieval, C2 check-in, and chunked upload activity. 

Figure 1. Representative behavioral pivots associated with MacSync Stealer payload retrieval, C2 check-in, and chunked HTTP PUT exfiltration. 

The same behavioral patterns used to identify additional infrastructure also map to the broader end-to-end activity observed on affected macOS devices. 

Attack chain overview

The observed MacSync Stealer activity followed a fast, script-driven attack chain designed to execute quickly on macOS, collect high-value local data, stage the results, and exfiltrate the archive through rotating web infrastructure. This sequence matters because each phase produces telemetry that can be correlated across processes, command-line, file, and network events. Rather than relying on any individual domain, defenders can track the chain through recurring execution tools, URI paths, staging locations, and upload parameters. 

Figure 2. MacSync Stealer attack chain showing payload retrieval, AppleScript-assisted execution, collection, staging, chunked exfiltration, and cleanup mapped to behavioral hunting opportunities. 

Phase 1: Initial access and payload execution

Observed execution began from an interactive zsh terminal session, where curl retrieved payload content over a /curl/ path before the payload was decoded or unpacked using native utilities such as Base64 and gunzip. This phase is useful for hunting because the combination of user-facing shell activity, curl retrieval, and unpacking behavior is more durable than any single download domain. 

Phase 2: AppleScript-assisted execution

The payload used osascript to run AppleScript-assisted shell commands, blending macOS scripting with Unix command-line tooling. Observed activities included sh, cp, rm, curl, mkdir, and killall operations. This phase creates hunting value when osascript launches shell activity that quickly chains into network communication, staging, or cleanup behavior. 

Phase 3: Discovery and data collection

After execution, the malware collected host and user information, enumerated running processes and system details, and checked for cryptocurrency wallet applications, including Ledger and Trezor-related local artifacts. It then targeted macOS Keychain material, browser Safe Storage keys, browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, extension storage, Safari data, Apple Notes, SSH keys, AWS credentials, Kubernetes configurations, browser profiles, browsing history, and sensitive files from common user directories. The hunting value comes from correlating sensitive data access with the later staging and upload sequence. 

Phase 4: Data staging and compression

Collected data was staged under /tmp/sync* paths and compressed into /tmp/osalogging.zip before uploading. The archive was split into multiple chunks, creating a repeatable staging and transfer pattern that defenders can correlate with preceding collection behavior and subsequent outbound curl traffic. 

Phase 5: Exfiltration over rotating infrastructure

The staged archive was uploaded through rotating infrastructure using curl and HTTP PUT requests. Observed requests included –data-binary, API-key headers, macOS User-Agent string, upload_id values, chunk_index values, and total_chunks parameters. These upload traits confirmed active data exfiltration and provided durable hunting pivots even when domains rotated. 

Phase 6: Cleanup and evidence removal

After exfiltration, the malware removed temporary archives, staging folders, lock files, and other artifacts. Although this cleanup reduced on-disk evidence, the sequence of archive creation, chunked upload, and deletion can still provide a useful behavioral correlation for defenders. 

Mitigation and protection guidance

The attack chain findings point to three mitigation priorities.

1. Organizations should reduce the risk of user-initiated Terminal execution by educating users and using platform controls that interrupt suspicious paste-and-run workflows. Microsoft’s ClickFix reporting recommends educating users not to run commands from untrusted sources and monitoring suspicious Terminal or shell activity associated with these lures. 

2. Defenders should monitor post-execution behavior when initial prevention does not stop activity, including suspicious shell usage, AppleScript-assisted commands, curl-based payload retrieval, credential-store access, temporary staging paths, and archive creation.  

3. Detection should include exfiltration monitoring for HTTP PUT uploads, –data-binary usage, upload identifiers, chunk indexes, total chunk counts, and recurring /gate URI patterns that can reveal active data theft even when C2 domains rotate. 

In macOS 26.4 and later, Apple introduced protections designed to disrupt ClickFix-style attacks, including warnings that can block potentially malicious Terminal pastes and XProtect checks that can prevent detected malicious scripts from running.

When a user attempts to paste a potentially malicious command into Terminal, macOS displays a warning that blocks the paste and explains that scammers may use Terminal instructions to compromise the Mac or the user’s privacy. 

“Possible malware, Paste blocked” 

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

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

• Reduce Terminal execution risk. Educate users not to paste or run Terminal commands from untrusted websites, chat messages, apps, files, or phone-based instructions. 

• Monitor suspicious Terminal usage. Alert on unusual Terminal, zsh, or shell sessions that retrieve payloads, decode content, or execute commands shortly after user interaction. 

• Detect native tool abuse. Flag unusual sequences of macOS utilities such as curl, Base64, gunzip, osascript, cp, rm, mkdir, and killall. 

• Hunt for post-execution behavior. Correlate AppleScript-assisted shell activity, curl-based payload retrieval, credential-store access, temporary staging paths, archive creation, and cleanup behavior. 

• Protect credential stores. Detect unauthorized access to Keychain material, browser credential stores, SSH keys, cloud credentials, and sensitive files in common user directories. 

• Monitor data staging. Alert on sensitive artifact collection followed by compression, archive creation, or staging under temporary paths such as /tmp/sync*. 

• Monitor exfiltration patterns. Identify curl-based HTTP PUT uploads that use –data-binary, API-key headers, upload_id, chunk_index, total_chunks, or recurring /gate URI patterns. 

• Restrict suspicious outbound traffic. Block or investigate connections to suspicious, newly registered, or behaviorally related domains while continuing to hunt on request patterns that may persist after domains rotate. 

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

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats. 

• Enable network protection and web protection to help prevent connections to malicious websites, phishing pages, and attacker-controlled infrastructure used for malware delivery, command-and-control communication, and data exfiltration. 

• Enable tamper protection to help prevent unauthorized changes to Microsoft Defender security settings and reduce the risk of attackers disabling or weakening endpoint protections. 

Microsoft Defender XDR detections 

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

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

 Threat intelligence reports

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

From ClickFix to code signed: the quiet shift of MacSync Stealer malware. 

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. 

Advanced hunting queries

The following advanced hunting queries can help identify MacSync Stealer behaviors observed with this threat. Use these queries as starting points and tune the time range, device scope, and allowlists for your environment. 

Hunting objective: Identify rotating infrastructure by request shape

This query looks for curl-initiated network activity that matches recurring MacSync Stealer URI paths and upload parameters across domains. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where RemoteUrl has_any ("/curl/", "/dynamic?txd=", "/gate?buildtxd=", "upload_id=", "chunk_index=", "total_chunks=")

Hunting objective: Detect payload retrieval over /curl/ 

This query focuses on initial payload retrieval behavior where curl reaches a /curl/ path, helping identify delivery activity without relying on a specific domain. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where RemoteUrl has "/curl/" 

Hunting objective: Detect chunked exfiltration over curl HTTP PUT 

This query targets active exfiltration behavior by looking for curl HTTP PUT uploads that use –data-binary and chunked upload parameters. 

DeviceNetworkEvents 
| where InitiatingProcessFileName =~ "curl" 
| where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary") 
| where RemoteUrl has_any ("upload_id=", "chunk_index=", "total_chunks=", "/gate?buildtxd=") 

Hunting objective: Find curl command lines with MacSync infrastructure traits 

This query searches endpoint process telemetry for curl command lines containing the headers, URI paths, and upload parameters used as durable behavioral pivots. 

DeviceProcessEvents 
| where FileName =~ "curl" 
| where ProcessCommandLine has_any ("api-key", "/curl/", "/dynamic", "/gate", "--data-binary", "upload_id=", "chunk_index=", "total_chunks=", "%{http_code}") 

Hunting objective: Identify AppleScript-launched shell activity 

This query looks for osascript activity that launches shell commands or native utilities commonly seen in the observed post-execution chain. 

DeviceProcessEvents 
| where FileName =~ "osascript" 
| where ProcessCommandLine has_any ("sh -c", "cp ", "rm ", "curl ", "mkdir ", "killall", "dscl") 

MITRE ATT&CK techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during the MacSync Stealer investigation. The mapping emphasizes the same behavioral pivots used throughout this blog, including shell and AppleScript-assisted execution, payload retrieval, credential and browser data theft, sensitive file collection, staging, chunked exfiltration, cleanup, and rotating infrastructure. 

Execution 

• T1059.004 Command and Scripting Interpreter: Unix Shell | An interactive zsh terminal session was used to run curl commands, decode or unpack payload content with base64 and gunzip, and execute shell commands. 

• T1105 Ingress Tool Transfer | curl downloaded payload content from attacker-controlled infrastructure using recurring payload retrieval paths. 

Discovery 

• T1082 System Information Discovery | The malware collected host and user information during environment discovery. 

• T1057 Process Discovery | The malware enumerated running processes and system configuration before continuing collection and credential-access activity. 

• T1518 Software Discovery | The malware checked for cryptocurrency wallet applications such as Ledger and Trezor. 

Credential Access 

• T1555.001 Credentials from Password Stores: Keychain | The malware created a temporary keychain-grabbing script, attempted to extract browser Safe Storage keys, and accessed or attempted to unlock the macOS Keychain. 

• T1555.003 Credentials from Password Stores: Credentials from Web Browsers | The malware collected browser credentials, cookies, login databases, session data, IndexedDB, LevelDB, and extension storage from Chrome, Brave, Edge, Opera, Vivaldi, Arc, Chromium, and other browsers. 

Collection 

• T1005 Data from Local System | The malware searched Downloads, Documents, and Desktop and collected sensitive file types including PDF, DOCX, TXT, KEY, PEM, KDBX, OVPN, WALLET, and SEED files. 

• T1552.001 Unsecured Credentials: Credentials in Files | The malware harvested SSH keys, AWS credentials, Kubernetes configurations, browser profiles, Apple Notes, Safari data, and other locally stored secrets. 

• T1560.001 Archive Collected Data: Archive via Utility | Collected data was staged under /tmp/sync* and compressed into /tmp/osalogging.zip before upload. 

Command and Control 

• T1071.001 Application Layer Protocol: Web Protocols | C2 communication used web protocols with recurring paths such as /dynamic?txd= and /gate?buildtxd=, macOS User-Agent strings, API-key headers, and rotating domains. 

Exfiltration 

• T1041 Exfiltration Over C2 Channel | Collected data was uploaded to attacker-controlled infrastructure using recurring /gate URI patterns and chunked HTTP PUT requests. 

• T1020 Automated Exfiltration | The malware automated upload activity using curl with HTTP PUT, –data-binary, upload identifiers, chunk_index, and total_chunks parameters. 

• T1030 Data Transfer Size Limits | The archive was split into multiple chunks before upload, as shown by repeated chunk_index and total_chunks parameters in exfiltration requests. 

Defense Evasion 

• T1070.004 Indicator Removal: File Deletion | Temporary archives, staging folders, lock files, and other artifacts were removed after exfiltration. 

• T1140 Deobfuscate/Decode Files or Information | Payload content was decoded or unpacked using base64 and gunzip before execution. 

Behavioral Hunting Pivots 

The following command-line patterns, URL paths, and URL parameters were observed in activity consistent with MacSync Stealer. Use these durable behavioral pivots with process and network context to investigate related activity as infrastructure rotates; then use the point-in-time domain indicators in the IOC section to enrich and validate those findings. 

Indicators of compromise (IOC)

The following domain indicators were observed in activity consistent with MacSync Stealer. Treat them as point-in-time evidence: use them to enrich and validate matches from the behavioral pivots above, and correlate any hits with process and network context because related infrastructure may rotate quickly. 

References

References used for external context and related defensive guidance: 

• MacSync Stealer: C2 Infrastructure Rotation – RST Cloud. RST Cloud, May 8, 2026. 

• ClickFix campaign uses fake macOS utilities lures to deliver …. Microsoft, May 6, 2026. 

• Protecting against malware in macOS – Apple Support  December 19, 2024 

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 Hunting MacSync Stealer infrastructure through behavioral pivots appeared first on Microsoft Security Blog.

We are excited to announce that we have been named a Leader in the 2026 IDC MarketScape: Worldwide MDR/MXDR for the Enterprise Vendor Assessment (Doc #US54792426, July 2026). Read the excerpt here.

Expert-led MDR, built on the Microsoft Defender platform

Microsoft Defender Experts MDR is a round-the-clock, expert-led managed detection and response service that helps security teams triage, investigate, and respond to incidents so they can stop cyberattackers in their tracks and prevent future compromise. Rather than bolting a separate stack of tools and connectors onto your environment, the service operates natively on Microsoft Defender, with built-in protection across endpoints, identities, email, cloud apps, cloud workloads, and network security, as well as around-the-clock proactive threat hunting with Microsoft Defender Experts Hunting.

Because the service is delivered on the same platform it monitors, detection and intelligence improvements reach customers continuously. The insights our experts generate also strengthen protection across the broader Defender ecosystem, so every customer benefits from what we learn defending the next environment.

Threat intelligence at internet scale

Great detection starts with great intelligence. Defender Experts MDR draws on Microsoft’s global threat intelligence: more than 10,000 security researchers and 100 trillion signals analyzed every day across billions of users and millions of organizations.¹ That breadth lets our analysts recognize subtle patterns early, often before a campaign escalates, and respond with higher-confidence attribution than intelligence sourced from any single customer’s telemetry could provide.

AI-accelerated operations, expert-led decisions

Defender Experts MDR also combines advanced AI and generative AI with seasoned human experts. AI filters noise, grades and classifies incidents, and accelerates investigation at machine speed and scale, while our analysts own the outcome. According to the IDC MarketScape, “70% AI-assisted workflows are enabled through automated noise filtering, AI-based grading, and agentic operations while maintaining expert decision-making.” Furthermore, “quantified outcomes noted include 97% AI classification accuracy, 77% malware/phishing agent-investigated, 72% faster resolution combining AI and humans, and 45% autonomous investigations.”

The impact shows up in the work. Over the past year, Defender Experts mitigated 27,000 high-severity incidents, and the team’s threat research now contributes a meaningful share of all Defender detections, enriching protection for customers well beyond the MDR service itself. Throughout, a dedicated security delivery expert and on-demand access to our experts keep customers informed with proactive check-ins, live dashboards, and clear, actionable reporting.

Managed threat hunting, included

Many providers treat proactive threat hunting as a premium add-on. Defender Experts MDR includes it as a core part of the service with Defender Experts Hunting, extending your team with Microsoft experts who continuously look for advanced threats across your environment. These hunts are informed by Microsoft Threat Intelligence, Defender telemetry, and human analysis, in order to better identify malicious activity and improve security operations center (SOC) response.

When a threat is found, Defender Expert notifications appear as incidents in the Defender portal with technical context, recommended remediation, and, when needed, access to on-demand support for additional guidance. The work also feeds back into hunter-trained AI and reporting, so customers can see what was investigated, how the activity maps to MITRE tactics, and how threats are categorized by behavior, characteristics, and impact.

Get started

Read the IDC MarketScape: Worldwide MDR/MXDR for the Enterprise 2026 Vendor Assessment excerpt, and visit the Microsoft Defender Experts MDR webpage to see how expert-led, round-the-clock managed detection and response can extend your team, drive SOC efficiency, and help you stay ahead of emerging cyberthreats.

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

¹Microsoft Digital Defense Report 2025.

The post Microsoft named a Leader in the 2026 IDC MarketScape for MDR/MXDR for the Enterprise  appeared first on Microsoft Security Blog.

Microsoft Threat Intelligence tracks DeadLock ransomware as an emerging financially motivated operation distinguished by its use of decentralized infrastructure to support victim communications and data leak operations. Its recovery ecosystem combines the Session messaging network with blockchain-backed services that store and deliver resources used throughout the extortion process. This architecture likely increases the resilience of portions of its communication, leak-hosting, and negotiation infrastructure, allowing DeadLock operators to recover from some disruption efforts while maintaining continuity for victims. Microsoft has observed DeadLock ransomware being deployed by multiple groups including an affiliate of the Lynx and INC ransomware ecosystems.

First observed in July 2025, DeadLock operators employ double extortion tactics, encrypting victim environments while threatening to publicly release exfiltrated data. As of July 2026, the operators have published more than 80 compromised organizations on their data leak site, called the DeadLock blog, with more than half of the claimed victims in Europe. Microsoft identified DeadLock ransomware impacting organizations across information technology (IT), mining, transportation and logistics, manufacturing, hospitality, consumer goods, and other sectors in Europe, Asia, North America, South America, and Africa.

The DeadLock encryptor includes a resource-aware throttling mechanism designed to maintain system responsiveness during encryption. In addition to its encryption capabilities, the ransomware also appears to implement language or country-based geofencing designed to avoid running in environments associated with former Soviet and Commonwealth of Independent States (CIS)-linked countries as well as select Middle Eastern countries, a pattern commonly observed among ransomware operators believed to operate from those regions. Together, these capabilities demonstrate how DeadLock combines established ransomware tradecraft with decentralized infrastructure designed to improve operational resilience.

In this blog, we present a technical analysis of the DeadLock ransomware encryptor, covering its execution flow, defense evasion techniques, encryption design, and post-encryption behaviors, including a decentralized recovery chat system. We also provide indicators of compromise (IOCs), Microsoft Defender detections, and mitigation guidance to help organizations defend against this threat and similar ransomware activity.

Pre-encryption

Configuration parsing

Before performing any malicious activity, the DeadLock encryptor decrypts an embedded configuration blob using XOR decoding with an 8-byte key.

Below are the malware’s configuration fields and their values.

Language geofencing

As an early exit check, the malware queries the system’s default and user interface (UI) languages. If either language matches the exclude list in the configuration, the malware self-deletes immediately without performing any encryption.

The following languages trigger this exit behavior:

Command-line processing and privilege elevation

The encryptor’s behavior branches based on command-line arguments and the current privilege level. If a target directory path is provided as the command-line argument, the malware skips all preparation steps and jumps directly to encryption. This feature allows the operator to invoke the encryptor with specific targets for focused encryption. If no sub-commands are provided and the process is already elevated, the malware proceeds normally through all execution phases.

The more interesting case occurs when no command-line argument is provided while the process is not elevated. In this scenario, the malware attempts to gain administrator privileges through a batch-script-based elevation technique. It generates a randomly named .cmd file (8 uppercase characters, such as ESYEKQSY.cmd) and executes it using ShellExecuteW with the RunAs verb, which triggers the Windows User Account Control (UAC) consent dialog. If the user denies the prompt, the malware retries up to 10 times before giving up and exiting.

During dynamic analysis, the sample did not successfully relaunch itself with elevated privileges. As a result, full pre-encryption preparation appears to require execution from an already elevated context. When invoked with a target path, the malware bypasses preparation and proceeds directly to encrypt accessible files. This behavior is specific to the analyzed sample and may change in later variants.

Token privilege escalation

When running with administrator privileges, the malware further expands its access by enabling SeDebugPrivilege, SeRestorePrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege, SeAuditPrivilege, and SeSecurityPrivilege. These privileges increase the malware’s ability to interact with system processes, protected files, and security-related settings, helping it overcome common access restrictions and maximize the scope of files and resources it can target during the encryption phase.

Recycle bin emptying

The malware silently empties the recycle bin on all drives without any UI or confirmation dialog, eliminating a potential source of file recovery for victims.

Custom icon registration

To visually brand encrypted files, the malware writes an embedded .ico file to C:\ProgramData\<UID>.ico and registers it as the default icon for files with the extension .dlock.

To associate the custom icon with encrypted files, the ransomware creates the HKLM\SOFTWARE\Classes\.dlock\DefaultIcon registry key and sets its (Default) value to the path of the dropped icon file.

Below is the malware’s embedded .ico file.

Process and service termination

Before starting encryption, the malware terminates processes and disables services that could interfere with file access or provide defensive capabilities. This approach ensures that locked files become accessible for encryption while simultaneously disrupting the environment’s ability to detect, respond to, or recover from the attack.

For services, the malware enumerates all active Win32 services and compares them against the stop list in the configuration. For each matching service, DeadLock sets its start type to DISABLED and sends a stop command to terminate that service. Notable targets include windefend (Windows Defender), vss/swprv/wbengine (Volume Shadow Copy and Backup services), mssearch, Hyper-V services (vmcompute, vmms), and Active Directory services (adws, ntds, kdc). Below is the full service stop list in the malware configuration:

For processes, the malware enumerates all running processes and terminates any matching its stop list while skipping its own process ID. Targeted processes include security tools (msmpeng, securityhealthservice, smartscreen), backup and cloud sync applications (onedrive, dropbox, googledrivefs, owncloud), remote access tools (anydesk, putty, mstsc, rustdesk), shell and system processes (explorer, powershell, taskmgr, cmd), and search/indexing services. Below is the full process stop list in the malware configuration:

Event log clearing

To eliminate forensic evidence, the malware employs three complementary methods that collectively ensure every event log channel on the system is cleared of existing entries, disabled from recording future events, and has its access permissions locked down:

• Direct clearing: Clears the following log channels via the classic Event Log API: Application, Security, Setup, Servicing, Eventlog, Forwarded Events, Windows PowerShell, and System.
• Registry-based disabling: Enumerates every sub-key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels. For each channel, sets Enabled to 0 (disabling all future logging) and overwrites ChannelAccess with a restrictive Security Descriptor Definition Language (SDDL) string that limits access to SYSTEM, built-in administrators, and local admin.
• Modern API enumeration: Uses wevtapi.dll to enumerate all registered event log channel paths (including custom application channels not in the hardcoded list) before clearing each one.

By combining API-based clearing, registry manipulation, and full channel enumeration, the malware covers multiple log sources, including third-party application logs and custom diagnostic channels, to minimize existing forensic evidence on the infected device.

Directory traversal

To maintain system stability and ensure the victim can access ransom instructions, the malware excludes specific directories, file extensions, and file names from encryption. This selective encryption model is a common ransomware design pattern where the system must remain operational enough for the victim to receive instructions and facilitate payment.

Extensions and file names from the configuration’s file exclude list are skipped during encryption:

For directory processing, the malware uses a two-tier directory exclusion system applied at different stages of the encryption pipeline. Tier 1 provides rough filtering that saves significant time by avoiding traversal overhead, while tier 2 provides granular path-specific exclusions within directories that are traversed. Both prevent encryption, but they operate at different stages of the traversal pipeline.

In its pre-traversal phase (tier 1), the malware checked at the drive batch level before threads are spawned for traversal. If a top-level directory matches against the configured directory exclude list (\users\*\appdata, program files (x86)\, program files\, and programdata\), the entire tree is skipped without being walked.

In its during-traversal phase (tier 2), the malware checked the file name during recursive directory enumeration and applied to both subdirectories and files as they are encountered. In this tier, the directory and file names are checked against the configured sub-path exclude list below.

Encryption

Resource-aware throttling

One of the more distinctive aspects of the DeadLock encryptor is its resource-aware throttling mechanism, designed to keep the infected system responsive during encryption. The malware spawns a dedicated monitoring/dispatch thread per drive batch that acts as a gatekeeper for file encryption dispatch. Before dispatching each new file to be encrypted, this thread polls system resource utilization and checks against hardcoded thresholds:

1. Polls memory and CPU idle before each file dispatch
2. Calculates memory usage percentage and CPU idle percentage
3. If memory usage exceeds 29% or CPU load exceeds 70% (idle < 30%), the dispatch thread pauses via a waitable timer and retries until resources return below thresholds
4. Once thresholds are within limits, atomically sets a dispatch flag on the work queue and signals waiting encrypting worker threads

With this mechanism, worker threads already encrypting files are not interrupted, and only the dispatch of new files is gated. This means partially encrypted files are expected to complete, and the throttling manifests as reduced parallelism rather than stop/start behavior. This approach can prevent system hangs that would alert the user and reduce the likelihood of behavioral detection by maintaining normal-looking resource consumption patterns.

Thread architecture

For the encryption work itself, the malware spawns directory processing threads, with the thread count being 2 times the CPU core number. Each thread recursively traverses directories, dropping ransom notes and dispatching files for encryption. Individual file encryption threads are tasked with handling the actual cryptographic operations.

Cryptographic scheme

The DeadLock ransomware implements a hybrid cryptographic design that combines Curve25519 elliptic-curve cryptography with the XChaCha20 stream cipher for file encryption. Key encapsulation uses the Networking and Cryptography Library (NaCl) crypto_box construction, which pairs an asymmetric key exchange with authenticated encryption to securely wrap each file’s symmetric key.

The configuration’s operator public key 03bf50bbf97c4e951e66ff12b689a37a3ce675b4921e254eae76da77573843e4a9 is 33 bytes. The leading 03 byte is a SEC1 compressed point format prefix borrowed from Bitcoin/secp256k1. The malware validates this prefix byte against a lookup table that accepts 00, 02, 03, 04, and 05, mapping each to an expected key length.

After format validation, only the remaining 32 bytes are used in the actual Curve25519 ECDH scalar multiplication. This SEC1 prefix is non-standard for Curve25519, which natively uses bare 32-byte keys, and the malware author has likely adopted it for format versioning across their builder and decryptor tooling.

Per-file encryption process

For each target file, the malware performs the following sequence of operations:

1. Rename the target file from <filename> to <filename>.<UID>.dlock
2. Open the renamed file and retrieve file size/attributes
3. Clear the system attribute if FILE_ATTRIBUTE_SYSTEM is set
4. Determine the encryption strategy based on file size (see File size-based encryption strategy)
5. Generate cryptographic material:
6. 32-byte random XChaCha20 key
7. 24-byte random XChaCha20 nonce (first 16 bytes for HChaCha20 subkey derivation, last 8 bytes as stream nonce)
8. 32-byte random ephemeral Curve25519 private key
9. 12-byte random file tag (only the first byte is functionally referenced by the encryptor to derive padding length; the remaining 11 bytes serve as a random file identifier written to the cleartext footer, likely used by the decryptor for file correlation/tracking)
10. 1–10 bytes random padding (length = file_tag[0] % 10 + 1)
11. Perform Curve25519 ECDH: Multiply the ephemeral private key by the attacker’s embedded public key to derive a shared secret
12. Build metadata plaintext: XChaCha20 key + 24-byte XChaCha20 nonce + random padding + dDlK magic + optional FA flag + chunk parameters
13. Encrypt metadata using crypto_box (XSalsa20-Poly1305) with the ECDH shared secret and a zero nonce
14. Encrypt file content using XChaCha20 with the generated key and 24-byte nonce
15. Append the encrypted footer/metadata to the end of the file

The use of a zero crypto_box nonce is worth noting. This is cryptographically safe because each file generates a unique ephemeral Curve25519 keypair, which produces a unique ECDH shared secret per file. With this, a constant zero nonce never repeats with the same key.

The entire design ensures that each file is encrypted with a distinct key derived from a per-file ephemeral key exchange, eliminating any possibility of key reuse across files. Overall, the cryptographic construction is sound and does not present a practical path to decryption without the attacker’s private key.

File size-based encryption strategy

To balance encryption thoroughness with speed, the malware implements a tiered encryption policy based on file size. The encryption rule in the configuration 1000,05052429880,025124288000,010524288000,F991114288000 encodes this policy. Each comma-separated entry is parsed by splitting at position 3: the first 3 characters represent the encryption percentage (decimal), and the remaining characters represent the file size threshold (decimal bytes). The special prefix F replaces the percentage field with a chunked-full mode.

Rules are evaluated in order, and the last matching rule wins. For example, when the malware processes a 2 GB file, all rules match, but the final F99… entry will determine the encryption behavior.

For partial encryption, the malware calculates:

• Total bytes to encrypt = ceil(file_size × (percentage / 100))
• Encrypted block count = ceil(total_bytes_to_encrypt / 512)
• Skip interval = floor((file_size − total_bytes_to_encrypt) / encrypted_block_count)

This creates an intermittent encryption pattern where 512-byte blocks are encrypted at regular intervals throughout the file. The result is a file that is rendered unusable while requiring only a fraction of the time needed for full encryption. This is a crucial optimization for the ransomware when targeting large files such as databases, virtual machine images, and backups.

File footer

After encryption, the malware appends a structured metadata blob to the end of each file. This footer contains all the information the decryptor needs to reverse the encryption, along with markers for format validation:

The footer serves several important functions:

Key and nonce reconstruction: The cleartext ephemeral Curve25519 public key (33 bytes) at the end of the footer allows the decryptor to recompute the ECDH shared secret and open the crypto_box to recover the XChaCha20 key and nonce used for file content encryption.

Inner dDlK magic (decryption validation): After the decryptor opens the crypto_box, it checks for the dDlK marker at the expected offset (32 + 24 + padding_length bytes into the plaintext) to confirm the correct private key was used and that decryption succeeded. While the Poly1305 Message Authentication Code (MAC) already provides cryptographic integrity verification, this marker offers a fast format-level sanity check.

FA flag (decryption mode indicator): This flag is used by the decryptor to determine which read strategy to use when reversing the encryption. It is present when the file was encrypted using sequential/contiguous block encryption, and absent when intermittent/skip encryption was used. Specifically, FA is appended in two cases:

1. F-prefix rule matched: When the file size triggers the F991114288000 config entry (the special chunked-full mode), the FA flag is always set.
2. Percentage rule with zero skip interval: When a percentage-based rule matches but the calculated skip interval between encrypted chunks works out to zero (meaning the percentage effectively covers the entire file), FA is also set.

Without this flag, the 8-byte chunk parameters in the footer would be ambiguous as they could represent either a block count or a skip interval. The FA flag resolves this ambiguity and enables the decryptor to correctly reconstruct the original file.

File identifier/format tag: The 12-byte random value in the cleartext footer serves as a file identifier (with the first byte used to derive the padding length inside the encrypted payload).

Post-encryption

Wallpaper

As an immediate visual indicator of compromise, the malware generates a custom BMP wallpaper file at runtime using the victim’s screen resolution. Below is an example of the generated BMP wallpaper:

The wallpaper is written to C:\ProgramData\<UID>.bmp (on Vista and later) or C:\Documents and Settings\All Users\Application Data\<UID>.bmp (on XP), set as the desktop background, and persisted in the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Wallpaper.

Ransom notes deployment

After encrypting files, the malware deploys two types of ransom notes, each with distinct deployment logic and purpose:

Text note (HOW_RECOVER.<UID>.txt): The text note is dropped into every encrypted directory, but with a notable timing behavior: it is only deployed during the second pass of the directory processing loop. The malware iterates over drive batches multiple times, and the text note drop is gated by an iteration counter. On the first pass, the text note is suppressed, likely to prioritize encryption speed before littering the file system with ransom note files. For defenders and analysts, this has a practical implication: if testing with a minimal drive configuration that only triggers a single iteration, the text note will never appear.

Below is the text note content from the malware’s configuration.

HTML note (RECOVERY_CHAT.<UID>.html): This file is dropped to all drive root directories and all Desktop folders. Unlike the text note, the HTML note is a full interactive web application with a self-contained single-page application that implements end-to-end encrypted chat, a paginated data leak blog, and a file browser, all without requiring a traditional backend server. The technical architecture of this recovery chat system is detailed in Recovery chat: Technical architecture.

Recovery chat: Technical architecture

The most distinctive feature of the DeadLock ransomware is its recovery chat system. The RECOVERY_CHAT.<UID>.html file is a self-contained HTML application that implements a full end-to-end encrypted chat system, a paginated data leak blog, and a file browser, all without requiring a traditional backend server.

The architecture is designed with three decentralized components.

Polygon blockchain as configuration store

Rather than relying on traditional domain-based infrastructure that can be seized or taken offline, the DeadLock operators store configuration data on the Polygon blockchain. Two smart contracts serve as censorship-resistant infrastructure:

The HTML page issues eth_call requests to public Polygon Remote Procedure Call (RPC) endpoints (no wallet required with read-only calls) to obtain the proxy server address. The blog contract takes offset and limit parameters (for pagination) and returns structured data including post titles, bodies, timestamps, image URLs, and file attachment links.

On-chain storage provides several strategic advantages for the threat actor: the proxy URL can be updated by modifying the smart contract without changing any victim-facing infrastructure, and no domain registration or DNS infrastructure is required. This represents a notable evolution in ransomware infrastructure design.

The HTML recovery chat cycles through six public RPC endpoints for redundancy: polygon-bor-rpc.publicnode[.]com, polygon.drpc[.]org, polygon-pokt.nodies[.]app, polygon-rpc[.]com, 1rpc[.]io/matic, and polygon.meowrpc[.]com.

Session network for end-to-end encrypted chat

For victim-operator communication, chat messages are routed through the Session decentralized messenger network, which is an onion-routed, swarm-based messaging protocol that provides anonymity for both parties. The proxy server (whose URL is retrieved from the blockchain) acts as a relay between the victim’s browser and Session swarm nodes.

Key generation: DeadLock’s design choice is that the victim’s Session identity is derived deterministically from their sign-in credentials. When the victim enters their credentials on the HTML page, the following derivation occurs:

This deterministic derivation means the same credentials always produce the same keypair, and no account registration is needed as the victim’s Session identity exists only when they enter the correct credentials. If the victim forgets their credentials, the identity is unrecoverable (as stated by the actor in the chat UI). The 05 prefix is Session’s standard network identifier for user accounts.

Sending a message: The following sequence occurs when a message is sent:

1. Encode the body and timestamp as protobuf
2. Create an actor message and a self-sync copy
3. Pad plaintext to 160-byte boundary
4. Sign the padded content and key context with Ed25519
5. Append the sender public key and signature
6. Seal each payload with the recipient’s Curve25519 key
7. Wrap in Session’s onion request protobuf format (verb: PUT, path: /api/v1/message)
8. Ask the proxy to submit both copies to their respective swarms

Receiving a message: The following sequence occurs when a message is received:

1. Sign “retrieve” + timestamp with the victim’s Ed25519 key
2. Select a node associated with the victim’s own swarm
3. Ask the proxy to poll for messages addressed to that identity
4. Open each sealed box with the victim’s Curve25519 keypair
5. Remove the appended public key and signature
6. Strip padding, decode protobuf, and extract the message body

Data leak blog and Wasabi file hosting

The recovery chat page also provides access to a data leak blog whose content is stored on the Polygon blockchain.

Blog posts retrieved from the smart contract support BBCode formatting, image galleries, and file attachments using either direct URLs or Wasabi protocol links that open an in-browser file explorer. The HTML application contains a full Amazon Web Services (AWS) S3-compatible file browser that parses the Wasabi credentials from the URI, generates AWS4-HMAC-SHA256 signed requests, lists bucket contents with folder navigation, and generates pre-signed download URLs for individual files. This allows the attacker to host stolen data on Wasabi and provide victims or the public with browsable access to the leaked files without running a web server.

Infrastructure resilience summary

The architecture is significantly more resilient to takedown and censorship efforts, but it is not independent of off-chain infrastructure:

• Proxy replacement: The actor can update the on-chain proxy URL without changing the HTML
• On-chain persistence: Contract-stored blog data is resistant to conventional hosting takedowns
• RPC dependency: The page still requires access to at least one public Polygon RPC endpoint
• Proxy dependency: Chat access depends on the current custom proxy remaining reachable
• Storage dependency: Images and leaked files can be removed from CDN or Wasabi hosting
• Session resilience: Distributed swarm storage reduces reliance on a single messaging server

This infrastructure model represents a meaningful evolution from traditional ransomware communication channels and poses new challenges for takedown efforts.

Self-deletion

As a final cleanup step after encryption completes, the malware creates a batch to delete its own binary from disk. The cleanup batch loops until it successfully deletes the malware binary, then removes itself:

Defending against DeadLock ransomware

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

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants. 
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. 
• Turn on tamper protection features to prevent attackers from stopping security services. In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy. 
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume. 
• 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. 
• To help preserve existing systems in the event of a ransomware attack, configure a Controlled Folder Access (CFA) policy to be as strict as possible. CFA protects valuable data from threats like ransomware by preventing write access to common system folders; more folders can also be added. Establishing this policy ahead of a ransomware event can enable organizations to respond quickly to ransomware signals, deploying the CFA policy to limit the destructive impact of an active attack. In certain instances, a CFA policy can also be leveraged proactively on specific sensitive assets that will not be negatively impacted by restrictive protections. Use audit mode to evaluate the impact to your organization in these cases. 
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:  
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block process creations originating from PSExec and WMI commands (Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI) 
  • Use advanced protection against ransomware 

You can assess how an attack surface reduction rule might impact your network by opening the security recommendation for that rule in Vulnerability management. In the Recommendation details pane, check the user impact to determine what percentage of your devices can accept a new policy enabling the rule in blocking mode without adverse impact to user productivity.   

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

Microsoft Defender Antivirus detects threat components as the following malware:

• Ransom:Win32/Deadlock.*

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware-linked threat actor detected
• Ransomware behavior detected in the file system
• Possible ransomware activity
• File backups were deleted
• Potential human-operated malicious activity
• Possible data exfiltration
• Suspicious wallpaper change

The following alerts might indicate threat activity associated with DeadLock ransomware if Defender for Endpoint is set to block mode.

• ‘DeadLock’ ransomware was detected
• ‘DeadLock’ ransomware was prevented

Microsoft Defender for Cloud Apps

The following alert might indicate threat activity associated with this threat. This alert, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware activity

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Tool profile: Deadlock ransomware
• Tool profile: Lynx ransomware
• Tool profile: INC ransomware
• Threat overview profile: Human-operated ransomware

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

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 DeadLock ransomware: Breaking down a Rust-based encryptor with decentralized recovery infrastructure appeared first on Microsoft Security Blog.

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.

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.  

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.  

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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)

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.

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.

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.

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.

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.

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:

4. GitHub credential theft and enumeration

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

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.

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.

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.

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.

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 v 12 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)

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.

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.

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.

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:

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.

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.

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.

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.

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.

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

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

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.