Microsoft

According to this year’s Microsoft Digital Defense Report, government agencies and services were the sector most impacted by cyber threats in 2026, accounting for 27% of observed activity, up from 17% in 2025. Governments are also the most frequently targeted sectors for nation-state activity. They are attractive targets because they hold sensitive information, operate essential services, and sit at the center of networks of agencies, contractors, technology providers, and critical infrastructure operators.

Dwell time, the period between when an attacker gains access and when defenders detect and stop them, also increased this year across multiple sectors. While organizations responded faster once an intrusion was identified, detecting threats early remains a challenge. Attackers increasingly gain access through techniques that mimic legitimate activity, making malicious behavior harder to spot. For example, phishing accounted for 23% of observed intrusions in 2026, up from 7% in 2025, highlighting the continued importance of compromised identities as an entry point for broader attacks.

Taken together, the implication for governments is clear. Security in the AI era is no longer simply about preventing individual intrusions. It is about ensuring institutions can operate effectively in an environment where risks are interconnected, threats move faster, and attackers remain hidden longer. Public-private partnerships are also more important than ever for securing critical government infrastructure and developing the policies and regulations needed for emerging technologies.

In this year’s report, which examines cyber threat trends observed between July 2025 and June 2026, Terrell Cox, Microsoft’s Corporate Vice President & Deputy Chief Information Security Officer, and I explore how these dynamics are reshaping cyber risk. In a companion blog, Terrell takes a closer look at what these findings mean for CISOs and security professionals.

To strengthen resilience, governments should focus on five priorities:

1. Prepare for a faster threat environment
   AI is compressing the window for action. Adversaries are moving faster. A vulnerability’s discovery in the wild to active weaponization can be well below 24 hours. While the number of publicly disclosed software vulnerabilities (commonly tracked as CVEs) is projected to reach a record 72,000 in 2026.

Governments best prepared for the future will be those that can rapidly gather and assess information, make decisions, coordinate across institutions and industries, and communicate effectively during a crisis. This requires clearly defined responsibilities and trusted relationships established before an incident occurs, enabling swift and coordinated action when it matters most.

2. Build security into the AI ecosystem
   AI is becoming part of the infrastructure that governments, businesses, and citizens rely on every day. As governments continue to adopt AI across public services and encourage its broader use, they should approach its security as a resilience challenge rather than a narrow technical issue.

AI systems depend on interconnected infrastructure, data, models, applications, suppliers, and governance processes. Governments should promote security across this ecosystem through secure-by-design practices, testing and evaluation, stronger supply chain protections, transparency, accountability, and international cooperation on AI risk.

The goal is not to create a separate AI security agenda. It is to integrate AI security into broader efforts to protect critical infrastructure and build national resilience.

3. Plan for incidents to spread
   Governments may not immediately know whether an intrusion is criminal, geopolitical, or something else. Cybercriminals and nation-state actors pursue different objectives, but increasingly rely on many of the same entry points, including compromised identities, exposed applications, social engineering, and legitimate administrative tools.

Microsoft found that 52.2% of intrusions involving valid accounts resulted in additional credential theft, highlighting how quickly attackers can expand beyond an initial foothold. A seemingly isolated compromise can evolve into ransomware, espionage, data theft, or disruption of essential services.

Governments should therefore assess incidents not only by how they begin, but by where they could lead. Response plans should account for the suppliers, partners, and service providers supporting critical functions. As attacks expand beyond their initial targets, they can also cross organizational, sectoral, and national boundaries, reinforcing the need for global collaboration.

4. Enable timely, two-way public-private information sharing
   A compromised account at one organization may provide early warning of a broader campaign. Signals that appear inconclusive in isolation can reveal coordinated activity when combined across organizations and jurisdictions. Modern cybercrime operates through interconnected networks of actors, services, and infrastructure that no single institution can fully see or disrupt on its own.

Information sharing must be timely, trusted, and two-way—also known as bidirectional. The goal is not simply for companies to report threats to government. Public agencies should also return actionable intelligence, guidance, and warnings that help organizations protect their networks, customers, and operations. Trusted channels can enable this exchange among government agencies, law enforcement, critical infrastructure operators, technology providers, and international partners while respecting legal and privacy requirements.

Policymakers can support this cooperation through protections for good-faith information sharing, common anonymization standards, and investment in shared threat intelligence and detection capabilities. Information sharing should also lead to action, including investigations, disruption efforts, and accountability for those responsible for serious cyber intrusions.

5. Prepare essential services to operate through disruption
   The organizations governments depend on to deliver public services, including transportation systems, communications infrastructure, schools, universities, and critical infrastructure operators, are increasingly targeted by cyber threats. Resilience therefore requires understanding not only government systems, but the broader ecosystem that supports them.

Planning documents alone are not enough. Governments should regularly conduct tabletop exercises bringing together policymakers, operational leaders, law enforcement, critical infrastructure operators, and private-sector partners to test how they would respond to incidents disrupting essential services. These exercises can expose gaps in decision-making, information sharing, public communications, and cross-sector coordination before a real-world crisis. Microsoft’s work through initiatives such as the Advancing Regional Cybersecurity (ARC) program, most recently in Kenya, illustrates how scenario-based exercises and cross-sector collaboration can help strengthen preparedness and response capabilities across the broader ecosystem.

Government leaders should also know which services are most critical, which identities, systems, suppliers, and infrastructure support them, and how incidents will be escalated. Shared-service approaches can help extend security and response capabilities to local governments and public institutions that cannot build them independently.

As cyber incidents cross organizational and national boundaries, resilience depends not only on technical preparedness, but on whether institutions can coordinate effectively under pressure.

In an era of AI-enabled and increasingly interconnected cyber threats, resilience is no longer simply about recovering from an attack. It is about preparing for a world in which cyber incidents move faster, spread further, and affect more organizations than ever before. Governments best prepared for the future will be those that can contain harm, adapt quickly, and continue delivering critical services when citizens need them the most.

The post Preparing governments for an era of interconnected cyber risk appeared first on Microsoft Security Blog.

Every year, the Microsoft Digital Defense Report gives us an opportunity to step back from individual threats and look broadly at what Microsoft’s security and threat intelligence teams are seeing. Today, we released the 2026 Report, which reflects a security environment that continues to grow more interconnected.

We see that across the report. Threat activity can span infrastructure, identities, applications, cloud environments, and software supply chains. AI systems and agents increasingly interact with data, tools, and business systems. And activity that looks incomplete in one part of an environment can become clearer when separate signals are considered together. That makes the connections across an environment increasingly relevant to how we understand both cyberthreats and defense.

Read the 2026 Microsoft Digital Defense Report

The pace of change also matters. AI models are becoming more capable, automation is expanding, and new connections are forming across the systems organizations rely on. These developments can change the speed and scale of security activity even as the underlying security fundamentals remain familiar.

Several findings in this year’s report illustrate that.

AI in the threat landscape

Threat actors are incorporating AI into reconnaissance, social engineering, malware and exploit development, and post-compromise activity. For now, much of their use remains focused on specific parts of existing attack workflows, even as more advanced applications of AI continue to develop.

AI can give threat actors greater speed, scale, and ability to tailor activity more efficiently. We see that in social engineering, where AI can make campaigns more targeted, and in technical work, where automation can compress parts of the attack process. The underlying methods often remain familiar. People, identities, exposed systems, and trusted access continue to feature prominently in the threat activity Microsoft observes.

AI is also becoming more connected to the systems and processes organizations already rely on. That brings another dimension to the security work.

Securing AI as part of the enterprise

Agents are a good example of these observations. They can interact with enterprise data, applications, APIs, and tools, with different levels of access and autonomy depending on how they are designed and deployed. Those connections are what allow agents to perform useful work, and they are also part of what security teams need to understand.

That makes it increasingly important to look at AI as part of a broader system. A model may be one component, but its security also depends on the data it can reach, the tools it can use, the identities and permissions involved, and the infrastructure and services around it.

The report looks at agent identity, appropriate access, authentication between agents, attribution, and the ability to revoke access. It also examines security considerations specific to AI, including prompt injection, memory, models and data, agent behavior, and the integrity of software and services around AI systems.

There is a lot we are still learning as these technologies develop. Security teams do have a strong foundation to build from. Identity and authorization, data protection, least privilege, monitoring, testing, and secure software development all remain relevant. AI puts those disciplines into new systems and increasingly connected workflows.

Read the executive summary of the 2026 Microsoft Digital Defense Report AI and vulnerability discovery

Advances in the application of AI toward code analysis are making it possible to examine software and identify weaknesses more effectively. That creates new opportunities to find vulnerabilities earlier and strengthen software before weaknesses are exploited. Those same advances can give threat actors more capable tools for vulnerability discovery and exploit development.

This is an important area to watch as capabilities develop. AI is giving defenders new ways to find and address weaknesses while giving cyberattackers new ways to look for them. The work on both sides continues to advance.

Connecting what defenders know

The same interconnectedness that shapes how activity moves across systems also shapes how defenders understand it. Security teams work with information from endpoints, identities, cloud environments, applications, email, networks, and threat intelligence. The report shows why those signals become more useful when they can be considered together. Threat activity spanning several systems may leave a pattern that no individual source shows on its own. In a more connected environment, the ability to relate activity across systems becomes an important part of understanding what is happening and where attention is needed.

The same principle extends beyond an individual organization. Trusted sharing of intelligence and information across organizations and public-private partnerships can connect pieces of activity that no one organization sees on its own.

AI can help with that work. Established techniques and repeatable tasks are increasingly candidates for automation, including bringing relevant information together and giving experienced defenders more capacity for deeper investigation.

The discussion of red teaming in this year’s report captures the balance well. Connecting known information and running established techniques can increasingly be automated. Finding an undocumented attack path, or recognizing how weaknesses that appear unrelated fit together, continues to benefit from experienced operators staying close to the work.

That balance will continue to evolve. There is substantial opportunity to use AI to help defenders work more effectively while preserving the human judgment, context, and expertise that remain essential to security work.

The 2026 Microsoft Digital Defense Report looks across the threat landscape, cybercrime, resilience, and the relationships among technologies, identities, systems, and people. Taken together, those findings give us a broader view of the increasingly interconnected environment security teams are responsible for understanding and protecting.

I encourage you to read the full report for a deeper look at the findings, data, and recommendations from Microsoft’s security and threat intelligence teams.

Read the 2026 Digital Defense Report for the full findings, data, and recommendations.

Get the full 2026 Microsoft Digital Defense 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 Insights from the 2026 Microsoft Digital Defense Report  appeared first on Microsoft Security Blog.

In this article

1. Why you should attend Microsoft Ignite
2. Make the most of your time at Microsoft Ignite
3. Explore the Security sessions at Microsoft Ignite 2026
4. Build your schedule

In the agentic era, the stakes are higher: AI agents now act with real access to your identities, your data, and your cloud, so every adoption decision is a trust decision. That is why security is a through line at Microsoft Ignite 2026, from a Security Pre-Day before the event opens to a security segment in the keynote, and four security themes across all four days.

Join us in San Francisco from November 17 to 20, 2026, or online. See the Microsoft Security roadmap first, get hands-on with new agentic security solutions, and connect directly with the experts, partners, and peers who can help you make it real. This year we spotlight our AI-first, end-to-end security platform designed to protect identities, devices, data, applications, clouds, infrastructure, and the AI agents now working alongside your teams.

Register for Microsoft Ignite 2026 Why you should attend Microsoft Ignite

• Understand where Microsoft is placing its bets. See what is being announced, what is shipping next, and what it means for your architecture, your security operations center (SOC), and your governance model.
• Build skills you can use immediately. Technical breakouts run from level 200 to level 400, paired with instructor-led labs and onsite certifications, so you leave with implementation guidance rather than slideware.
• Pressure-test your plans with the people who built it. Bring your real architecture, deployment, and roadmap questions to Microsoft engineers, MVPs, and the product teams behind these tools.
• See the proof, not the promise. Customer stories, live demos, and partner solutions show what is already working in production today.
• Connect with the people who make it real. Expert meetups, connection pods, table talks, and evening events put you alongside security practitioners, leaders, Microsoft partners, and peers working the same problems.

Make the most of your time at Microsoft Ignite

Whether you join us in San Francisco or online, you will have access to a full slate of experiences designed to help you connect, learn, and grow as a security professional. Here is what is in store.

Start a day early at the Security Pre-Day

On Monday, November 16, 2026, from 1:00 PM PT to 5:00 PM PT, the Security Pre-Day gives you four hours with Microsoft Security leaders and external industry voices before the main event begins. Expect presentations paired with interactive roundtables and ask-me-anythings (AMAs) with our security experts, built for security decision makers and practitioners alike.

Select the Security Pre-Day option during Microsoft Ignite registration.

Hear the news first in the keynote and Innovation Session

The opening keynote runs Tuesday, November 17, 2026, from 10:00 AM PT to 12:00 PM PT at Chase Center and sets the direction for the week with Satya Nadella, Microsoft CEO, and Judson Althoff.

Later in the week, the Security Innovation Session goes deeper on the security news with executive-led demos.

Where the security community comes together

Microsoft Ignite is where the security community gathers. Beyond the sessions, you will find expert meetups, connection pods, and evening experiences created for security professionals and leaders.

Secure the Night

You are invited to Secure the Night on Tuesday, November 17, 2026, an evening bringing the security community together to connect, celebrate, and have some fun. Join fellow customers and Microsoft Security leaders for a night designed to make meaningful connections.

Interested in attending? Fill out the interest form to be notified when registration goes live.

Security and Agent 365 Neighborhood at Microsoft Hub

Bring your hardest questions to the people who build and defend with these products every day. Microsoft engineers, MVPs, and partners staff the Hub throughout the week. Experience hands-on demo, participate in community conversations and happy hours with industry experts. Also check out our Security Insider podcast recorded real time.

Partners and the Microsoft Intelligent Security Association

Microsoft Intelligent Security Association (MISA) members have a full week ahead at Microsoft Ignite. Beyond the partner-focused security sessions running throughout the event, the MISA Demo Station returns to the Expert Meetup Hub from November 17 to 19, 2026, where members will demo their solutions with customers on the show floor.

Thank you to our MISA partners Ascent Solutions, Avertium, BlueVoyant, Devicie, Huntress, Illumio, Mphasis, and RSM who are sponsoring the Microsoft Secure the Night party, each hosting an interactive activation on the party floor, and the week wraps with an exclusive MISA Happy Hour on November 19, 2026—a chance for MISA partners to network with fellow members and select Microsoft Security stakeholders. For information on registration for the MISA Happy Hour, please reach out to your dedicated MISA representative.

Explore the Security sessions at Microsoft Ignite 2026

Below are the four themes shaping this year’s Security track, along with a few sessions you will not want to miss. You can view the full catalog here and filter by topic, format, and role to plan your week.

Here is an overview of the Security tracks with some highlights of our top sessions.

Defend with AI

Security operations are being rebuilt around agents. This track covers what changes when AI can not only analyze but act, and how the SOC’s operating model, data foundation, and response playbooks have to evolve to keep pace.

Sessions to watch for

• The Alert Is Dead. The Blueprint for the Agentic SOC, which maps what replaces alert-centric operations end to end.
• The Agentic SOC Reality Check: Market Hype vs. AI Models vs. Automation, a real-time architectural breakdown with no slides and no canned speeches.
• Winning the Race Against Time with Autonomous Protection, on how AI is changing the economics of cyberattacks and how to compress your response window.
• Turn signal into real-time protections with Project Perception, a hands-on lab in agentic security.

Also in this track: threat intelligence at AI speed, AI-powered endpoint vulnerability discovery and remediation, attack disruption, finding and fixing code vulnerabilities with codename MDASH, and building the security data foundation the agentic SOC runs on.

Secure AI

Your organization is already shipping agents. This track is about seeing them, governing them, and protecting them from code to runtime, across the identities they use and the data they touch.

Sessions to watch for

• When AI acts, security has to answer: Microsoft Security for AI, the platform view of securing agentic AI.
• Inside look: Microsoft Security as customer zero for Agent 365, covering what we learned running it ourselves.
• Local agents are here. Can you find and secure them?, paired with a companion lab on end-to-end threat protection for local agents.
• AI Agents Are Scaling. Are Your Access Controls Ready?, a peer discussion on identity for non-human actors.

Also in this track: prioritizing and remediating your riskiest agents, a Zero Trust approach to securing AI runtime with Microsoft Defender, data protection and governance for agents with Microsoft Purview, securing Microsoft 365 Copilot and Cowork, and turning AI security research into deployable defenses.

Get Ready for AI

Before you scale AI, the fundamentals have to hold: identity, device and app trust, data hygiene, exposure management, and Zero Trust. This track is the practitioner’s path to an AI-ready security foundation.

Sessions to watch for

• Build secure foundations to scale AI across your organization, the anchor session for this track.
• Identity Knows What Your SOC Doesn’t: Stop Threats Faster Together, on closing the gap between identity and security operations.
• Can’t Phish a Passkey. But Can You Prove Who’s Behind It? and SMS MFA Is Dead. What Comes Next?, a pair on the state of phishing-resistant authentication.
• Zero Trust for AI workshop, a hands-on lab with a companion lightning talk, Apply Zero Trust for AI: the practitioner’s shortlist.
• Insights from Microsoft’s journey to prepare its data for AI adoption, on what it actually took internally.

Also in this track: reducing exposure across your digital estate, a single policy model for humans and agents, protecting cloud and container applications from code to runtime, getting privileged access right, and getting more out of the E5 you already own.

Secure Data

Data is the substrate AI runs on, and the thing cyberattackers are after. This track is about discovering, classifying, and protecting sensitive data across clouds, devices, AI apps, and agents.

Sessions to watch for

• Microsoft Purview: Build the Trusted Data Foundation for AI, the place to start.
• Strengthen and Manage Data Security Posture with Microsoft Purview, on data security posture management in practice.
• Deploy Copilot with confidence: Find and protect exposed sensitive data, a hands-on lab to run before you turn Copilot loose.
• Microsoft Purview AMA: Preparing Your Data for Secure AI, where you can bring your questions to the product team.

Also in this track: closing exfiltration gaps with data loss prevention, and turning global regulatory requirements into operating controls.

Choose the session format that fits how you learn

• Breakout sessions run 45 minutes at level 200 to 400, led by experts with live demos and real architecture. They are the technical core of the Security track.
• Theater sessions are 25 minutes of fast, demo-driven content in the Hub, designed to show rather than tell.
• Lightning talks are 15 minutes in intimate mini-theaters, built for curiosity, questions, and quick insight.
• Table talks are 45-minute, small-group technical discussions on real-world challenges and trade-offs, moderated by Microsoft subject matter experts.
• Hands-on labs are 75 minutes, instructor-led and proctor-supported, in a live environment. RSVP is required and labs fill fast.

Build your schedule

Do not miss your chance to be part of Microsoft Ignite. Explore the full session catalog, filter by topic, format, and role to plan your week, and register today to connect with the global security community and get hands-on with the latest innovations.

Register now for Microsoft Ignite 2026

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 ​​Secure what’s next: Your guide to Microsoft Security at Microsoft Ignite 2026 appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. References
4. Learn More

Microsoft Threat Intelligence identified and tracked exploitation of CVE-2026-73570, an unauthenticated OS command injection vulnerability in the Zimbra Collaboration Suite SNMP notification path. Exploitation can be triggered by a specially crafted email against internet-facing Zimbra servers when the optional zimbra-snmp package is installed and SNMP notifications are enabled, without requiring authentication or user interaction.

Following successful exploitation, observed activity included deployment of JSP web shells and reverse shells, privilege escalation, persistent remote-access tooling, and memory-backed execution. Threat actors also accessed email and collected authentication and mailbox data, with archive creation and subsequent transfer activity observed. The activity included both automated payload delivery and hands-on-keyboard operations on compromised mail servers. Microsoft observed affected organizations in more than one region and industry. Based on the environments investigated, exploitation was not limited to a single sector or geographic area. The diagram combines behaviors observed across multiple confirmed compromises; no single host necessarily exhibited every stage.

From remediation to public disclosure

CVE-2026-73570 is an unauthenticated OS command-injection vulnerability in the Zimbra Collaboration Suite SNMP notification path. An attacker can send a specially crafted SMTP request that introduces untrusted input into SNMP notification processing. If the input is not sufficiently sanitized, embedded shell commands can execute with the privileges of the zimbra service account. Exploitation requires the optional zimbra-snmp package to be installed and SNMP notifications to be enabled.

Zimbra version 10.1.20, released July 20, 2026, contains the relevant remediation. CVE-2026-73570 was publicly disclosed on August 13, 2026. Microsoft telemetry identified activity targeting the same injection path during the interval between those events.

Attack chain overview Figure 1. CVE-2026-73570 attack chain, mapped to MITRE ATT&CK tactics and composited across all confirmed compromises. Pre-disclosure reconnaissance and pre-exploitation probing

Between July 28 and August 7, after a fix became available on July 20 but before public disclosure on August 13, Microsoft observed two distinct out-of-band scanning tools probing the vulnerable injection point. The activity used the same swatchdog-to-snmptrap execution path later observed during exploitation.

The operators first validated command execution using lightweight out-of-band probes to unique subdomains hosted on public interaction and collaborator services, including oast[.]fun, oast[.]online, dnslog[.]pp[.]ua, requestrepo[.]com, and campaign-associated infrastructure under bypass[.]eu[.]org. The probes included HTTP requests and DNS, ICMP, and in-band identity checks, using commands such as curl, wget, ping, nslookup, and id. HTTP requests used the CVE-specific ZB73570 User-Agent, while DNS and ICMP requests used randomized callback subdomains.

The probes were designed to confirm execution without delivering a payload by performing local identity checks or dropping a small system fingerprint script, demonstrating both command execution and external access to the server’s webroot.

Figure 2. Out-of-band command-execution validation using HTTP, DNS, and ICMP callbacks to unique collaborator subdomains. Initial access

CVE-2026-73570 allows a crafted SMTP request containing shell metacharacters to reach Zimbra’s SNMP notification processing. When a service-state change triggers health monitoring, swatchdog incorporates the attacker-controlled value into a snmptrap shell invocation, enabling command execution.

Figure 3. CVE-2026-73570 command-injection sequence that changes webroot permissions, reconstructs encoded fragments, and deploys a JSP webshell. Figure 4. JSP webshell artifacts placement across Zimbra application and servlet-work directories. Figure 5. Remote content retrieved with wget or curl and piped to a shell for execution.

Exploitation of the Zimbra vulnerability provided attackers with direct command execution as the zimbra service account. In observed cases, attackers used this access to deploy JSP webshells by changing webroot permissions, reconstructing an encoded and compressed payload from staged fragments, and writing the decoded payload to publicly accessible application directories. The staging fragments were then removed, leaving the webshell available for subsequent HTTP-based access.

Attackers also used the initial command execution to download and execute content directly through wget or curl, launch background processes, and establish interactive reverse shells. Other execution chains used cron, systemd, or memfd_create to maintain recurring or memory-backed execution.

Multiple JSP webshells were deployed across Jetty and mailboxd application paths, including additional copies on peer mailbox nodes. This provided alternative access paths across different Zimbra configurations and reduced reliance on a single webshell. In some cases, attackers temporarily enabled write access to a public directory to deploy the webshell and then restored the directory permissions, limiting the visibility of the change during basic permission checks.

Reconnaissance — Cluster mapping and environment discovery
The actor first mapped the Zimbra deployment using zmprov to identify mailbox and MTA nodes. This provided an overview of the server roles within the environment and helped identify systems of interest for subsequent activity.

The actor also checked for the presence of the Zimbra SSH identity, likely to determine whether existing administrative trust could enable movement between Zimbra hosts. In parallel, DNS-based callbacks were used to transmit environment details, including mailbox-server counts and other host-specific information.

Figure 6. Cluster-aware reconnaissance using Zimbra provisioning commands to enumerate mailbox and MTA nodes and test administrative SSH trust. Application and host persistence

Microsoft observed a privilege-escalation technique that abused Zimbra’s legitimate, sudo-authorized service helpers and the interaction between zmmailboxdmgr, its writable log directory, the sudo PAM configuration, pam_exec, and zmstat-fd.

The attacker first verified that the server exposed the required Zimbra helpers and that the mailbox manager’s log directory was writable. They then backed up /etc/pam.d/sudo, replaced the legitimate zmmailboxd.out log with a symlink to the PAM configuration, and invoked the privileged zmmailboxdmgr process. This caused the PAM file to become owned by the zimbra service account, allowing the attacker to modify it.

The attacker added a pam_exec session hook that invoked a local script, then triggered a sudo session through the legitimate zmstat-fd helper. The hook executed as root and created a NOPASSWD: ALL entry for the zimbra account, providing unrestricted sudo access. The attacker subsequently restored the original PAM content and removed temporary files and other staging artifacts, while retaining the newly created sudoers entry.

The resulting root access was confirmed through subsequent passwordless sudo operations, including system configuration and file ownership changes. The controller also contained fallback paths involving Postfix, a Java agent, zmstat-fd, and nginx; however, the observed child processes indicate that the mailbox-manager/PAM path was the escalation technique successfully exercised on this server.

Figure 7. Privilege-escalation sequence using a writable Zimbra log path, zmstat-fd, pam_exec, and a sudoers entry for the zimbra account.

A second persistence mechanism was established through a systemd service named zimlog.service. The name was consistent with a Zimbra logging component, but the payload was manually installed in /etc/systemd/system/, outside the Zimbra application directories. The service file was moved from /tmp into the system-wide systemd directory using sudo and assigned to the Zimbra service account. Its timestamps were then modified to match existing systemd services, including rsync.service and sshd.service. The service was enabled with systemctl enable, establishing execution at system boot, and its status was subsequently checked.

Figure 8. Disguised zimlog.service systemd unit installed for host persistence and timestomped to resemble an older file. Zimbra service credential and authentication-key collection

The actor targeted Zimbra’s centralized service and authentication secrets rather than individual mailbox passwords. The zmlocalconfig -s command exposed credentials used by LDAP, MySQL, Postfix, Amavis, and replication services. The actor then used the recovered credentials for authenticated LDAP queries that retrieved high-value attributes, including zimbraPreAuthKey, zimbraAuthTokenKey, and zimbraTwoFactorAuthSecret. Portions of the collected data were compressed into hidden archives.

Figure 9. Zimbra credential and authentication-secret discovery, including service credentials, token material, and preauthentication keys.

The combined zmlocalconfig -s and authenticated ldapsearch sequence was observed across multiple compromised Zimbra servers. A separate credential-dumping malware family observed in another affected environment extended this tactic by collecting Zimbra configuration credentials and authentication material through an automated backdoor.

Lateral movement across the Zimbra cluster

The observed activity used Zimbra’s existing SSH identity at /opt/zimbra/.ssh/zimbra_identity to access other trusted nodes in the cluster. SSH was invoked in noninteractive mode with host-key verification disabled, enabling automated connections between peer systems. rsync was then used to move staged payload fragments, helper scripts, and JSP webshells between nodes. The transfer workflow included validation of the received fragments and removal of source files after transfer, supporting payload reconstruction on the destination while reducing artifacts left on the originating system.

This activity enabled the same tooling and webshells to be deployed across multiple Zimbra nodes, extending access beyond the initially compromised host.

Figure 10. Lateral movement across trusted Zimbra cluster nodes using the existing zimbra SSH identity and rsync-based artifact transfer. Command and control

The actor used HTTP and HTTPS callbacks to validate command execution, retrieve payloads, and return command output. DNS-label callbacks provided an additional channel for execution confirmation and limited host-data transfer. The observed activity established a reverse shell using standard Linux utilities. A named pipe at /tmp/s was used to connect an interactive /bin/sh session to openssl s_client, which maintained an encrypted connection to a remote endpoint. This allowed commands received over the connection to be passed to the shell and their output returned through the same channel.

Figure 11. Command-and-control activity using an OpenSSL-encrypted reverse shell to attacker-controlled infrastructure. Remote-access agents and Zimbra Implants

In one campaign, the attackers used a multi-stage payload chain beginning with agent2.sh, a lightweight shell downloader that retrieved Stage 1 malware from a dynamic DNS domain and staged it within Zimbra’s log-directory structure. The same chain was observed across multiple hosts in separate environments. The downloaded zimdown2 Go binary acted as an installer for the final zimclient2 remote-access agent. It retrieved and verified the agent using its SHA-256 hash, supported multiple download methods, and reported installation status over a separate WebSocket channel. It also selected writable installation paths and runtime-generated filenames based on the host environment.

The final zimclient2 payload was a full remote-access agent providing interactive shell access, bidirectional file operations, and SOCKS5 proxying. It supported WebSocket, TLS, and raw TCP transports, providing resilient remote access and potential network pivoting through compromised Zimbra servers. Evidence identified several persistence mechanisms associated with the payload, including systemd services, OpenRC, cron, shell startup files, SSH authorized keys, and local account creation:

Persistence mechanismEvidenceSystemdUnit files, daemon-reload, enable, and startOpenRC/etc/init.d/ scripts, rc-update, rc-serviceCron/etc/cron.d/, crontab, @reboot, and scheduled entriesShell startup/etc/profile, /etc/bashrc, .bash_profile, .zprofileSSH keys.ssh/authorized_keys creation or modificationLocal accountsuseradd, adduser, and password-setting activity Zimbra Credential and Mailbox Exfiltration-Attempt Implant

The observed activity also included Zimbra-specific payloads. In one case, a Go executable contained the embedded module path zimbra-exfil/client-dump, indicating that it was specifically designed to operate against Zimbra Collaboration Suite installations. The payload was intended to run under the Zimbra service account, which has broad read access across the Zimbra installation.

Figure 12. zimbra-exfil client-dump binary workflow for reading localconfig.xml and extracting Zimbra service-account credentials.

Upon execution, the binary reads /opt/zimbra/conf/localconfig.xml – Zimbra’s primary configuration file and extracts a defined set of service account credentials including mysql_root_password, zimbra_mysql_password, ldap_root_password, zimbra_ldap_password, ldap_postfix_password, ldap_amavis_password, ldap_nginx_password, ldap_replication_password, and ldap_bes_searcher_password.

These values are then populated to construct pre-formatted MySQL and LDAP connection strings to the local Zimbra MySQL instance via Unix socket and exports full table contents from mailbox, mailbox_metadata, mobile_devices, and out_of_office, along with all tables under the zimbra.* namespace.

Figure 13. Automated export of Zimbra mailbox, metadata, mobile-device, out-of-office, and related database content using recovered credentials.

A dedicated function, identified in analysis as dumpSecrets, handles collection from both the local filesystem and the LDAP directory service. From the filesystem, the binary stages SSL certificate and private key files and Postfix LDAP configuration files. From the LDAP directory, the binary performs authenticated queries targeting specific attributes of significant sensitivity. The zimbraAuthTokenKey attribute, retrieved from cn=config,cn=zimbra, is the key material Zimbra uses to sign user session tokens across the platform; access to this value enables session token generation for arbitrary accounts without requiring account credentials. The pre-authentication key allows construction of pre-authenticated login URLs for any user account. The full collection breakdown is as follows:

Figure 14. Credential, certificate, LDAP secret, mail-rule, and configuration artifacts collected and staged by the Zimbra exfiltration-attempt implant.

Collected files are staged in a timestamped working directory under /tmp/zimbra_dump_YYYYMMDD_HHMMSS/, compressed into a ZIP archive, and

prepared for attempted transfer to a remote endpoint whose address is supplied as a hex-encoded command-line argument.

Collection and exfiltration attempt

On one compromised Zimbra server, the actor archived recent mailbox-backup content into /opt/zimbra/final.tar.gz. The actor then downloaded AzCopy from hxxps://aka[.]ms/downloadazcopy-v10-linux and invoked it with an operator-supplied Azure Blob SAS URL targeting wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log. This activity shows mailbox-data collection, local archive staging, and an exfiltration attempt using cloud-storage tooling; available evidence does not confirm that the transfer completed successfully.

Figure 15. Mailbox-backup collection staged as /opt/zimbra/final.tar.gz and transferred with AzCopy to Azure Blob. Mitigation and protection guidance

Microsoft Defender surfaced malicious activity across every observed attack path. A tactical detector built for the SNMP command-injection pattern recognized every confirmed exploitation event while operating in evaluation mode. Independently of that detector, Microsoft Defender Antivirus detected and quarantined Chopper, GodzillaWebShell, CoinMiner, Looptik, SuspGoLang, and Dirtelti payloads, and behavioral protection alerted on suspicious permission changes, background execution, dropped-and-launched files, anonymous memfd_create execution, and reverse-shell activity.

Endpoint detection and response telemetry preserved the process lineage, network connections, and file activity used to reconstruct the attack paths, and Advanced Hunting pivots across process lineage, command-and-control infrastructure, file hashes, and the S3-hosted dropper URL expanded a ten-day seed query into a fleet-wide hunt across the full advanced hunting retention window, identifying additional affected hosts.

Patch and reduce exposure

• Patch immediately. Upgrade all Zimbra Collaboration Suite instances to version 10.1.20 or later, which remediates CVE-2026-73570.
• Mitigate where patching must wait. Uninstall the optional zimbra-snmp package, disable SNMP notifications, and restrict SNMP and SMTP access to trusted hosts only.

2. Scope and contain

• Treat reverse-shell alerts on internet-facing mail servers as priority incidents. A confirmed reverse-shell connection indicates attacker access even when no payload is quarantined, making rapid scoping, containment, and credential review essential.
• Do not rely solely on named-malware detections. Several of the most consequential outcomes in this campaign, including full mail-store staging for an exfiltration attempt, involved no malware family at all, only a plain interactive shell.

3. Rotate secrets and review persistence

• Rotate Zimbra authentication secrets and inspect system services. Rotate all domain zimbraPreAuthKey values and review systemd units for unexpected ownership, enablement, or timestamp changes, including units that resemble Zimbra or operating-system logging components.
• Hunt for redundant webshell persistence. Inspect active Zimbra application directories and servlet work directories across every mailbox node for unexpected JSP files, generated *_jsp.java or compiled servlet artifacts, and recent permission changes on publicly served directories. Do not assume that removing one known JSP eliminates access.
• Limit the blast radius of mail-server service accounts. Where feasible, confine them with namespace, seccomp, or AppArmor controls to reduce the impact of any future command-injection-class vulnerability in the mail stack.

4. Deploy and verify Microsoft Defender protections

• Enable Microsoft Defender for Endpoint protections on Linux servers. Real-time protection, behavior monitoring, and endpoint detection and response telemetry work together to quarantine malicious payloads, surface suspicious behaviors, preserve evidence for investigation, and support proactive hunting.

5. Hunt for related activity

• Look for the injection signature itself. A legitimate snmptrap invocation immediately followed by shell metacharacters and a wget or curl call, wrapped in a trailing ‘#’ comment that swallows the remaining legitimate arguments.
• Hunt beyond the advanced hunting window. Microsoft Defender XDR advanced hunting retains 30 days of raw event data, which no longer covers the pre-disclosure reconnaissance and early exploitation described here. For activity older than that window, search the second-stage infrastructure listed in the appendix in Microsoft Sentinel or archived logs, and pivot every recovered indicator across the entire device fleet rather than only the hosts that triggered an initial alert.

TacticObserved activityMicrosoft Defender coverageInitial AccessExploitation of an unauthenticated command-injection vulnerability in a Zimbra service-monitoring component (CVE-2026-73570), enabling remote command execution without credentials.Microsoft Defender for Endpoint
Exploit:Linux/SnmpTrapCmdInject.A
Possible CVE-2026-73570 vulnerability exploitationExecutionA second-stage payload is retrieved over HTTP using standard download utilities with fallbacks, then launched as a detached background process.Microsoft Defender for Endpoint
Trojan:Linux/ShellDropper.AA
HackTool:Linux/SuspFetchExecFallback.A

Suspicious command execution via Java application Suspicious file dropped and launched Process launched in the background Suspicious piped command launchedPersistenceWrite access is granted to a Zimbra web-application directory, and a base64/gzip-encoded payload is decoded directly into a .jsp file inside it.Microsoft Defender for Endpoint
Exploit:Linux/SnmpTrapJspDrop.APrivilege EscalationA symbolic link is created into the system’s PAM configuration directory (/etc/pam.d/) in conjunction with the Zimbra mailbox process (zmmailboxd).Microsoft Defender for Endpoint
HackTool:Linux/ZimbraPLE.A

Suspicious execution of elevated process Possible post-exploitation activity on a Zimbra mail serverDefense EvasionThe payload checks for specific legitimate processes before proceeding, disguises itself under trusted system component names, removes staging artifacts, and terminates competing malicious processes.Microsoft Defender for Endpoint
Trojan:Linux/FakeSysResolved.AA
HackTool:Linux/SuspKworkerMasqStage.A
Trojan:Linux/SuspKworkerImplant.B Trojan:Linux/FakeChronydMiner.A

Suspicious file or information obfuscation detected Suspicious anonymous process created using memfd_create Suspicious timestamp modificationCredential AccessA dropped JSP tool reads Zimbra’s local config file for LDAP/admin credentials and self-deletes afterward; companion tools invoke Zimbra’s zmlocalconfig utility and craft ldapsearch queries against admin accounts and Zimbra-specific password/auth-token attributes.Microsoft Defender for Endpoint
Backdoor:Java/ConfigCredDumper.A
HackTool:Linux/ZimbraLeakSecreat.A
HackTool:Linux/ZimbraSuspLDAP.A

Enumeration of files with sensitive data Possible post-exploitation activity on a Zimbra mail serverCommand and ControlBackdoor components communicate over web-based channels disguised as mail-server traffic on dynamically-resolved domains, with a follow-on stage using separate infrastructure.Microsoft Defender for Endpoint
Backdoor:Linux/FakeZimDownloader.A
Backdoor:Linux/FakeZimClient.A

Possible reverse shell Suspicious communication with a remote target Suspicious file or content ingress Microsoft Security Copilot

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

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

• Incident investigation: correlate the snmptrap injection, dropper execution, privilege escalation, persistence, and outbound C2 signals on an affected mail server into a single timeline.
• Script and file analysis: summarize the behavior of recovered dropper scripts and stripped Go binaries, including the downloader fallbacks, masquerade filenames, and persistence mechanisms they select at runtime.
• Device summary: assess whether a mail server that triggered a reverse-shell or memfd_create alert shows further staging, persistence, or beacon activity.
• Vulnerability impact assessment: identify internet-facing Zimbra Collaboration Suite hosts still running a version earlier than 10.1.20.

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following behavior-based queries to identify confirmed exploitation and post-exploitation activity associated with CVE-2026-73570 on Linux Zimbra servers. The queries intentionally avoid incomplete static IOC lists and use public Device* tables. Tune results for approved Zimbra maintenance and administrative activity.

The queries cover the confirmed SNMP command-injection boundary, suspicious Zimbra web-shell writes and Java-launched native shells, memory-backed execution, persistence and privilege-escalation artifacts, DNS callbacks, and collection or cloud-transfer activity. A command, file operation, or connection must be interpreted according to the evidence it actually provides; it does not automatically prove every downstream outcome.

Advanced hunting queries

Confirmed shell-mediated Zimbra SNMP command injection

This query identifies the high-confidence exploitation boundary where Perl running a generated Zimbra swatchdog script creates a Unix shell containing the SNMP command and shell grammar inside the service value. A match confirms shell-mediated command execution; nested payload outcomes require separate evidence.

let lookback = 30d; DeviceProcessEvents | where Timestamp > ago(lookback) | where FileName in~ ("sh", "bash", "dash") | where InitiatingProcessFileName =~ "perl" | where InitiatingProcessCommandLine contains ".swatchdog_script" | extend Cmd = tolower(ProcessCommandLine) | where Cmd contains "snmptrap" | where Cmd matches regex @"(^|\s)-c(\s|$)" | where Cmd matches regex @"::zmservicename\s+s\s+.*[;&|<>`$].*\s+\S+-mib::zmservicestatus" | project Timestamp, DeviceId, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, ProcessId, ProcessCreationTime, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, InitiatingProcessId, InitiatingProcessCreationTime, SHA1, SHA256, ReportId | order by Timestamp desc;

Suspicious JSP writes in Zimbra webroots

This query identifies JSP or generated JSP-source writes in Zimbra web application and servlet-work directories when the initiating process is associated with shell execution, transfer, decoding, Java, jspawnhelper, Perl, or the SNMP injection path. Review each result to distinguish deployment from later activation.

let lookback = 30d; DeviceFileEvents | where Timestamp > ago(lookback) | where FileName endswith ".jsp" or FileName endswith "_jsp.java" | where FolderPath contains "/jetty_base/webapps/" or FolderPath contains "/jetty/webapps/" or FolderPath contains "/mailboxd/webapps/" or FolderPath contains "/work/zimbra/jsp/" | where InitiatingProcessFileName in~ ("sh", "bash", "dash", "curl", "wget", "tee", "base64", "rsync", "java", "jspawnhelper", "perl") or InitiatingProcessCommandLine contains "snmptrap" or InitiatingProcessCommandLine contains "Runtime.getRuntime().exec" | project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, FileName, SHA1, SHA256, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, ReportId | order by Timestamp desc;

Zimbra Java or jspawnhelper launching native shells

This query finds native shells, FIFO creation, and OpenSSL execution launched by Zimbra Java or jspawnhelper context. These events can reveal web-shell or application-mediated native command execution, including reverse-shell behavior.

let lookback = 30d; DeviceProcessEvents | where Timestamp > ago(lookback) | where FileName in~ ("sh", "bash", "dash", "mkfifo", "openssl") | where InitiatingProcessFileName in~ ("java", "jspawnhelper") or InitiatingProcessFolderPath contains "/opt/zimbra/" | where ProcessCommandLine contains " -c " or ProcessCommandLine contains " -i" or ProcessCommandLine contains "mkfifo" or ProcessCommandLine contains "s_client" | project Timestamp, DeviceId, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, ProcessId, ProcessCreationTime, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, InitiatingProcessId, InitiatingProcessCreationTime, ReportId | order by Timestamp desc;

Campaign-context anonymous memory-backed execution

This query finds anonymous memfd or file-descriptor-backed process execution only when Zimbra exploit ancestry or known campaign process context is present. It identifies memory-backed execution behavior, not the exact syscall or process injection.

let lookback = 30d; DeviceProcessEvents | where Timestamp > ago(lookback) | extend FullPath = strcat(FolderPath, "/", FileName) | where FileName startswith "memfd:" or FullPath contains "/memfd:" or FullPath startswith "/proc/self/fd/" or ProcessCommandLine contains "/proc/self/fd/" | where InitiatingProcessCommandLine contains ".swatchdog_script" or InitiatingProcessCommandLine contains "snmptrap" or ProcessCommandLine has_any (".kworker_sys", ".lpe_core", "softwaretech", "ksmd", "/tmp/init", "/dev/shm/systemd-resolved", "chronyd-helper.service", "syslog_init.service") or InitiatingProcessCommandLine has_any (".kworker_sys", ".lpe_core", "softwaretech", "ksmd", "/tmp/init", "/dev/shm/systemd-resolved") | project Timestamp, DeviceId, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, ProcessId, ProcessCreationTime, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, InitiatingProcessId, InitiatingProcessCreationTime, SHA1, SHA256, ReportId | order by Timestamp desc;

Zimbra persistence and privilege-escalation artifacts

This query combines process and file evidence for the systemd units, pre-authentication changes, PAM/sudo manipulation, and related artifacts observed in the investigation. Commands and file events must be correlated with runtime evidence before claiming durable persistence or successful privilege escalation.

let lookback = 30d; union ( DeviceProcessEvents | where Timestamp > ago(lookback) | where ProcessCommandLine contains "zimlog.service" or ProcessCommandLine contains "chronyd-helper.service" or ProcessCommandLine contains "syslog_init.service" or ProcessCommandLine contains "zimbraPreAuthKey" or ProcessCommandLine contains "pam_exec" or ProcessCommandLine contains "zmstat-fd" or ProcessCommandLine contains "/etc/sudoers.d/81_metric" | project Timestamp, DeviceId, DeviceName, EvidenceType="Process", ActionType, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId ), ( DeviceFileEvents | where Timestamp > ago(lookback) | where FileName in~ ("zimlog.service", "chronyd-helper.service", "syslog_init.service", "81_metric") or FolderPath == "/etc/pam.d" or FolderPath == "/etc/sudoers.d" | project Timestamp, DeviceId, DeviceName, EvidenceType="File", ActionType, FileName, FolderPath, ProcessCommandLine=InitiatingProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId ) | order by Timestamp desc;

DNS and out-of-band callbacks from the Zimbra injection path

This query finds nslookup, dig, host, or ping callback commands executed through the confirmed Zimbra swatchdog and SNMP shell lineage. It remains useful when callback domains rotate because it detects the behavior rather than a static domain list.

let lookback = 30d; DeviceProcessEvents | where Timestamp > ago(lookback) | where FileName in~ ("sh", "bash", "dash") | where InitiatingProcessFileName =~ "perl" | where InitiatingProcessCommandLine contains ".swatchdog_script" | extend Cmd = tolower(ProcessCommandLine) | where Cmd contains "snmptrap" | where Cmd matches regex @"(^|\s)-c(\s|$)" | where Cmd has_any ("nslookup", "dig", "host", "ping") | where Cmd contains "zmservicename" and Cmd contains "zmservicestatus" | project Timestamp, DeviceId, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, ProcessId, ProcessCreationTime, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, InitiatingProcessId, InitiatingProcessCreationTime, ReportId | order by Timestamp desc;

Zimbra collection, archive staging, and cloud-transfer invocation

This query identifies Zimbra LDAP export, archive creation and staging, and AzCopy invocation associated with collection activity. Archive creation and transfer invocation do not by themselves prove that exfiltration completed.

let lookback = 30d; DeviceProcessEvents | where Timestamp > ago(lookback) | where FileName in~ ("zmslapcat", "slapcat", "tar", "gzip", "find", "wget", "curl", "azcopy", "bash", "sh", "nohup") | where ProcessCommandLine contains "zmslapcat" or ProcessCommandLine contains "/opt/zimbra/backup/" or ProcessCommandLine contains "/opt/zimbra/final.tar.gz" or ProcessCommandLine contains "downloadazcopy-v10-linux" or ProcessCommandLine contains "azcopy copy" or ProcessCommandLine contains "HISTFILE=/dev/null" | project Timestamp, DeviceId, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, ProcessId, ProcessCreationTime, SHA1, SHA256, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessCommandLine, InitiatingProcessId, InitiatingProcessCreationTime, ReportId | order by Timestamp desc; MITRE ATT&CK techniques observed TacticTechniqueObserved activityReconnaissanceT1595.002 Active Scanning: Vulnerability ScanningCanary subdomains in ping and nslookup callbacks; no payload.Initial AccessT1190 Exploit Public-Facing ApplicationCrafted SMTP request into SNMP notification processing, running as the zimbra account.ExecutionT1059.004 Command and Scripting Interpreter: Unix Shellperl to dash or bash; de.sh, agent2.sh, and aliyun_update.tar.gz piped into a shell.ExecutionT1105 Ingress Tool Transfercurl, wget, python3, python, perl, and /dev/tcp download fallbacks.Privilege EscalationT1068 Exploitation for Privilege EscalationGitHub LPE toolkit staged as .lpe_core in tmpfs; quarantined as Looptik.PersistenceT1053.003 Scheduled Task/Job: CronCrontab ‘* * * * *’ and ‘@reboot’ entries relaunching .kworker_sys.PersistenceT1543.002 Create or Modify System Process: Systemd Servicezimlog.service installed, enabled, assigned to the Zimbra account, and timestomped on one server; a separate payload installed chronyd-helper.service as a root service.PersistenceT1505.003 Server Software Component: Web ShellMultiple JSP webshells deployed across Zimbra application paths and propagated to peer mailbox nodes to provide redundant HTTP-accessible command execution.Defense EvasionT1036.005 Masquerading: Match Legitimate Name or Locationsystemd-resolved, _chronyd, .kworker_sys, and a mail archive saved as .ico.Defense EvasionT1620 Reflective Code LoadingXOR-decoded ELF run from memfd_create via /proc/self/fd.DiscoveryT1083 File and Directory DiscoveryTen operator directory listings; droppers probing writable, executable staging paths.Command and ControlT1071.001 Application Layer Protocol: Web ProtocolsWebSocket tasking at psk1zim[.]abrdns[.]com/agentws, with TLS and raw TCP fallbacks.Command and ControlT1102.001 Web Service: Dead Drop ResolverEncrypted commands polled from a Base mainnet contract over public JSON-RPC.CollectionT1560.001 Archive Collected Data: Archive via Utilitytar zcvf of the full Zimbra mail store, run twice.CollectionT1074.001 Data Staged: Local Data StagingArchive written as five.ico into the public Zimbra web directory.ImpactT1496 Resource HijackingMiner staged as .kworker_sys; rival miners killed and pools sinkholed via /etc/hosts. Indicators of compromise Network indicators IndicatorTypeRole117.107.25[.]243:7071IPv4 (C2)Dropper C2, serving de.sh192.255.193[.]111:9004IPv4 (C2)Miner C2, serving the build_amd64 cryptominer staged as .kworker_systranszimbra[.]linkpc[.]netDynamic-DNS domainDropper C2, serving agent.sh/agent2.sh/zimdown2psk1zim[.]abrdns[.]com/agentwsDynamic-DNS domainzimclient2 WebSocket (port 80, /agentws) and raw TCP (8080) command channeltls[.]psk1zim[.]abrdns[.]comDomain (C2)zimclient2 TLS command channel (port 443)wslogzimbra[.]linkpc[.]net/wsstatWebSocket URLzimdown2 installer status reporting; separate from payload hostingmexico-cashpay-test.s3.dualstack.mx-central-1.amazonaws[.]com/pakistan/2026/aliyun_update.tar.gzS3-hosted URLTarball dropper; confirmed executed on one host, retried elsewhere45.32.30[.]235:8081IPv4:port (C2)Reverse shell; earliest confirmed C2 in this campaign45.32.30[.]235:8080IPv4:port (C2)Same C2 IP, different port; interactive session + mail-store staging193.42.40[.]135:443IPv4:port (C2)Organization-wide reverse-shell/recon wave3.209.137[.]175:443IPv4:port (C2)Secondary C2, rotated-infrastructure eventgithub[.]com/<redacted>/lpe-toolkitPublic GitHub releaseLegitimate public tool repurposed as an attacker privilege-escalation payload0x25bdA7Feb3553995AD68a9A8Ed8c731b73a71586Base contract addressCommand channel for the memfd-executed stage; block on JSON-RPC bodies rather than the public RPC providers File hashes (SHA-256) IndicatorTypeRoledee5af1c0f76b45d28bafd6e60c07bb8e391d98addf81ef8f13d073acdb3c48aSHA-256de.shaea991f694911e321b0ab97534f2ad0291c392c0a43dabff664c563618bd036dSHA-256build_amd646ab7de2509038edf580aef6229c1c3db17f4da8f2d7d940818faf617d1938244SHA-256agent2.shbf28f38122bf20d5fac969cc414daa6a890cdea872d389ca93d2092b6b7773cfSHA-256zimdown2b594a42b8f1c6f090327bb9a3361c2d3515537fb7ac8da6b9061b9a3f330e159SHA-256Zimclient265A7576C389326B6CDF9C993D0BE6E5D50FED9655D1CDF2A3A50F2C21C8EC435SHA-256‘Looptik’ hacktool (GitHub-hosted LPE toolkit)22EF852F6EBC39EE71235B90648B4B200B385C47D25C79545986493F8C70DB69SHA-256Loader staged as ‘systemd-resolved’; installs /usr/sbin/_chronyd and decodes the in-memory stage 2518FE65DD349180191D9B258AB24876AAED6613CD657D0B626D1FC24E03A22B6SHA-256Decoded in-memory stage 2; Base-chain command agent References

• NVD: CVE-2026-73570
• Zimbra Security Advisories – Zimbra :: Tech Center
• Zimbra Releases/10.1.20 – Zimbra :: Tech Center
• CISA Known Exploited Vulnerabilities Catalog: CVE-2026-73570

Learn More

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

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

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

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

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570 appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Mitigation and protection guidance
3. Learn More

In July 2026, Microsoft Defender Experts observed phishing campaigns targeting organizations across multiple industries that distributed a masqueraded MSP360 Remote Monitoring and Management (RMM) installer through meeting invitations, PDF-themed lures, software update prompts, and other social-engineering content. Once executed, the legitimate MSP360 installer, distributed under a deceptive file name established remote management access on affected devices and enabled threat actors to gain an initial foothold using trusted administrative software.

Microsoft observed the MSP360 deployment being used to download and install a ConnectWise ScreenConnect client, creating a secondary remote-access channel that provided redundant access to compromised systems. Microsoft did not observe exploitation of ScreenConnect software itself; rather, threat actors abused legitimately obtained remote administration software to establish and maintain access. After access was established, threat actors used these remote administration channels to deploy additional tools and conduct post-compromise activity, including information collection and credential-access operations.

This activity highlights how threat actors continue to abuse legitimate remote administration software to blend into normal IT operations while maintaining persistent access and reducing detection opportunities. Microsoft Defender for Endpoint detects suspicious and uncommon remote-management activity, while the hunting queries and mitigations in this post can help organizations identify and restrict unapproved RMM use.

Attack chain overview

The observed multi-stage intrusion chain began when phishing lures delivered a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer under deceptive filenames. Following successful User Account Control (UAC) elevation, the installer established MSP360 services for persistent access and leveraged the RMM agent to invoke PowerShell, download, and silently install ConnectWise ScreenConnect.

This effectively introduced a second remote administration channel on the compromised device, which the threat actor subsequently used to transfer and execute additional tooling supporting credential access, local data collection, and other post-compromise activity.

Figure 1. Attack chain showing phishing delivering a masqueraded MSP360 RMM installer that deploys ScreenConnect for persistent remote access and follow-on activity. Initial Access: Phishing Campaign Delivering Masqueraded MSP360 RMM Installer

Microsoft observed multiple phishing campaigns that used a multi-stage delivery chain to distribute legitimate, digitally signed MSP360 RMM software (v2.5.0.67). Phishing emails directed users to actor-controlled landing pages that impersonated document-sharing portals, invitation workflows, Adobe Reader download pages, Zoom installation pages, and business collaboration platforms.

Upon user interaction, victims were redirected to download locations hosted on both attacker-controlled infrastructure and legitimate cloud services including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase. The downloaded executables used filenames crafted to resemble legitimate business content, meeting invitations, PDF documents, and software installers. Analysis of downloaded samples showed that many ultimately contained the same MSP360 RMM installer package despite appearing as different files to the victim.

MSP360 SHA256: 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc

MSP360 SHA1: f34330d4c6e0aa978dc3af40360c14b31ad51127

Observed lure themes:

We have observed the threat actor using multiple social-engineering themes, including:

• Workplace meeting requests
• Zoom and Google Meet installation prompts
• Adobe Acrobat and PDF reader updates
• RSVP invitations and e-cards
• Job offer documents
• Document review and signature requests
• DHL and package-delivery themed content

Examples of observed filenames included:

• VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe
• ZoomSetup_Installation_v2.5.0.67_ oid[redacted].exe
• PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_ oid[redacted].exe
• RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_ oid[redacted].exe
• SSA.GOV_STATEMENT_rmm_v2.5.0.67_ oid[redacted].exe

Figure 2. Actor-controlled tax-document lure prompting download of a masqueraded MSP360 installer. Figure 3. Image displaying the execution of downloaded MSP360 RMM.

The campaign relied on a diverse set of payload-hosting mechanisms. Microsoft observed the actor distributing the payload through attacker-controlled domains, websites assessed to be compromised, and legitimate cloud-hosted services. Cloud-hosted services used for payload distribution included Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase.

This approach enabled the actor to rapidly rotate delivery infrastructure while continuing to distribute the same MSP360 installer using different lure themes and filenames.

RMM platforms are attractive to threat actors because they are designed to provide administrators with broad remote management capabilities across managed endpoints, including remote command execution, software deployment, file transfer, and persistent service-based access. When abused, these same capabilities can give threat actors a flexible post-compromise channel for maintaining access, deploying additional tooling, and conducting follow-on activity while blending in with legitimate remote administration workflows.

MSP360 RMM installation and foothold establishment

After victims downloaded and executed the masqueraded MSP360 installer, the binary launched from the user’s Downloads directory under a filename designed to resemble a legitimate business document.

The installer subsequently dropped multiple installation components, including System.dll, nsExec.dll, and UAC.dll, to the following folder paths before relaunching itself through an elevation workflow generated by the installer framework. Next, the installer invoked a Windows User Account Control (UAC) elevation workflow. In observed successful installations, the process continued with elevated privileges, allowing deployment of MSP360 components and services. In unsuccessful installations, the elevation did not complete, and deployment terminated before the software was fully installed.

Following elevation, the installer initiated the MSP360 installation workflow and recorded installation status messages using Windows eventcreate.exe. The installer generated “Begin installation” and “End installation. MSP360 de Success.” events under the event source: MSP360 RMM Agent installer. The installer dropped multiple MSP360 plugins and binaries within the installation directory: C:\Program Files\RMM Agent\.

The installer also performed prerequisite discovery by enumerating installed .NET runtimes using: dotnet –list-runtimes. To establish long-term access on the affected device, the installer registered two Windows services: RMM.Agent.exe & RMM.Agent.Launcher.exe. Microsoft observed events indicating stopping any existing MSP360 services and installing new MSP360 services.

In addition to service-based persistence, the installer created registry-based autorun entries for MSP360 user interface components, ensuring the tray applications would automatically launch when users signed in.

The installation routine also modified the Windows Firewall configuration by creating an inbound allow rule for the MSP360 agent. The rule allowed inbound UDP traffic to C:\Program Files\RMM Agent\RMM.Agent.exe on port 48678. This configuration enabled network communications required by the remote management platform.

Figure 4. Process execution flow of the MSP360 RMM installation.

Not every execution of the installer resulted in a successful deployment. In some instances, the installer was launched by the user and began its installation routine but subsequently attempted to obtain elevated privileges through User Account Control (UAC). When elevation was denied or aborted, the installation terminated before completing deployment of the MSP360 RMM components. The process execution flow showed installation initialization activity followed by events indicating that administrative privileges were required, with no subsequent evidence of the persistence mechanisms, services, or remote management functionality observed during successful installations.

Figure 5. Unsuccessful installation of MSP360 RMM. Remote command execution from MSP360 Agent and ScreenConnect deployment

Following successful installation of MSP360 RMM, the newly installed RMM.Agent.exe service launched PowerShell. The PowerShell process modified the execution policy for the current session and executed Invoke-WebRequest commands to download an MSI package named ClientSetup.msi from actor-controlled infrastructure. The downloaded package was then installed silently through msiexec.exe using the /qn switch, eliminating visible user interaction. This installation activity resulted in the deployment of a ConnectWise ScreenConnect client on the compromised endpoint, including ScreenConnect.ClientService.exe, ScreenConnect.WindowsClient.exe, and supporting components.

The installer additionally created Windows service registrations, application uninstall entries, and authentication-related registry modifications associated with the newly deployed ScreenConnect client.

Figure 6. The process execution flow of the remote command execution and ScreenConnect deployment.

Following deployment, the ScreenConnect client service launched with configuration parameters referencing actor-controlled infrastructure and subsequently established successful outbound communications. The service then spawned ScreenConnect.WindowsClient.exe, providing an additional remote access channel independent of MSP360. Following establishment of the ScreenConnect session, the threat actor used ScreenConnect to transfer and stage additional executables in the following directories:

• C:\Users\%user%\OneDrive\Documents\ScreenConnect\Temp\
• C:\Users\%user%\Documents\ScreenConnect\Temp\

Examples of frequently observed files included:

• WindVerify.exe
• WindowsUpdate.exe
• WindowsSecurity_PIN.exe
• WindowsSecurity_Password.exe
• WindowsPassKey.exe
• SCHider.exe
• PIN.exe
• phonepc.exe
• DefenderDT.exe
• DefenderControl.exe
• phonelinkupdate.exe
• PhoneLinkPrompt.exe
• Passwords.EXE
• OpenCamera.exe
• open_phone_link.exe
• MouseHiderGUI.exe
• HideUL.exe
• HideMouseApp.dll
• HideMouse.exe
• HideFromControlPanel.exe
• HideCursor.exe
• BannerHider.exe
• WebBrowserBookmarksView.exe
• WebBrowserPassView.exe

These files were among the most frequently observed utilities delivered by the threat actor following establishment of a ScreenConnect session. Several filenames were intentionally chosen to resemble legitimate Windows, Microsoft Defender, Phone Link, and security-related components, likely to reduce user suspicion and blend into normal operating system activity. These utilities were observed during post-compromise activity and were used to support subsequent operations on affected systems. Several of the observed tools are commonly associated with credential access, information collection, execution of additional payloads, and efforts to reduce defender visibility.

The execution of these files occurred through ScreenConnect’s built-in RunFile functionality, which allows files to be transferred to and executed on managed endpoints. This activity demonstrates how the threat actor leveraged a legitimate MSP360 RMM deployment to establish an initial foothold before deploying ConnectWise ScreenConnect as a secondary remote access platform. The combination of MSP360 and ScreenConnect provided the threat actor with redundant remote administration channels and enabled the transfer, execution, and management of additional tooling during subsequent stages of the intrusion.

The threat actor subsequently used these remote access platforms to facilitate follow-on activities including information collection, credential access, and the deployment of additional utilities on compromised systems.

Microsoft also observed separate activity during July in which FaronicsDeployAgent.exe, a legitimate deployment and remote access application, was used in a similar manner to MSP360 RMM. In this activity, the threat actor leveraged FaronicsDeployAgent.exe as the initial remote management platform and subsequently used it to download and install ScreenConnect. This observation demonstrates that the deployment of ScreenConnect was not limited to MSP360-based intrusions, with additional legitimate remote administration software also being leveraged to establish remote access and facilitate ScreenConnect installation.

Attribution

Microsoft has not attributed this activity to a named threat actor. The campaigns are tracked as unattributed activity.

Mitigation and protection guidance

Microsoft recommends the following actions to help organizations reduce their exposure to this activity. Check the recommendations card for the deployment status of monitored mitigations.

• Govern approved RMM tools: For approved RMM systems used in your environment, enforce security settings where possible to implement multi-factor authentication (MFA).
• Restrict unauthorized software: Use Application Control for Windows to create policies to block unapproved IT management tools. Both solutions include functionality to block specific software publisher certificates:
  • Application Control for Windows file rule levels allow administrators to specify the level at which they want to trust their applications, including listing certificates as untrusted.
  • AppLocker’s publisher rule condition is available for files that are digitally signed, which can enable organizations to block non-approved RMM instances that include publisher information.
• Block specific signed applications: Microsoft Defender for Endpoint also provides functionality to block specific signed applications using the block certificate action.
• Consider searching for unapproved RMM software installations (see the Advanced hunting section). If an unapproved installation is discovered, reset passwords for accounts used to install the RMM services. If a system-level account was used to install the software, further investigation may be warranted.
• Strengthen endpoint protection: 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 provide near-instant, automated protection against new and emerging threats.
• Investigate unauthorized installations: Turn on the following attack surface reduction rule to block or audit activity associated with this threat:
  • Use advanced protection against ransomware
  • Block process creations originating from PsExec and WMI commands. Some organizations may experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI

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.

Tactic Observed activity Microsoft Defender coverage Initial accessDelivery of masqueraded MSP360 application v2.5.0.67Microsoft Defender Antivirus
– SupportScam:Win32/RogueMSP.MU!MTBExecutionExecution of the RMM softwareMicrosoft Defender for Endpoint
– Suspicious usage of remote management software
– Uncommon remote access software PersistencePersistence established by RMM softwareMicrosoft Defender for Endpoint
– Anomaly detected in ASEP registry
– Suspicious file registered as a service Credential AccessPotential credential-access activity following RMM deploymentMicrosoft Defender for Endpoint
– Possible theft of passwords and other sensitive web browser information Threat intelligence reports

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

Advanced hunting

// Run this query to identify the presence of MSP360 RMM agent

let MSP360RMM = "108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc"; DeviceFileEvents | where Timestamp >= ago(30d) | where SHA256 =~ MSP360RMM

// Run this query to identify the remote command execution from MSP360 RMM Agent

DeviceProcessEvents | where Timestamp >= ago(30d) | where (InitiatingProcessVersionInfoCompanyName == "MSP360" and ProcessCommandLine == "\"powershell.exe\"") or ( InitiatingProcessCommandLine == "\"powershell.exe\"" and ProcessCommandLine has_all ("msiexec.exe","\\Temp\\",".msi") and InitiatingProcessParentFileName == "RMM.Agent.exe")

// Run this query to identify the suspicious network connections from the threat actor’s use of ScreenConnect

let MaliciousURLs = DeviceNetworkEvents | where Timestamp >= ago(30d) | where InitiatingProcessCommandLine == "\"powershell.exe\"" | where InitiatingProcessParentFileName == "RMM.Agent.exe" | where isnotempty(RemoteUrl) | distinct RemoteUrl; DeviceNetworkEvents | where Timestamp >= ago(30d) | where InitiatingProcessFileName has_any ( "ScreenConnect.ClientService.exe","ScreenConnect.WindowsClient.exe","ScreenConnect.Client.exe") | where isnotempty(RemoteUrl) | where RemoteUrl in (MaliciousURLs)

// Run this query to identify the suspicious payloads dropped and launched by the threat actor’s use of ScreenConnect

DeviceProcessEvents | where Timestamp >= ago(30d) | where InitiatingProcessCommandLine has_all ("ScreenConnect.WindowsClient.exe", "RunFile","\\Documents\\","\\Temp\\") MITRE ATT&CK Techniques observed

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

Resource Development

• T1583.001 Acquire Infrastructure: Domains | Domains were used to host phishing landing pages, payload delivery infrastructure, and ScreenConnect services associated with the campaign.
• T1583.006 Acquire Infrastructure: Web Services | The threat actor leveraged legitimate cloud-hosting providers including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase for payload distribution.

Initial Access

• T1566.002 Phishing: Spearphishing Link | Victims received workplace meeting, Zoom, Google Meet, invitation, RSVP, PDF, and Adobe-themed phishing emails containing links that redirected to malicious payload download locations.
• T1204 User Execution | Victims downloaded and executed a masqueraded MSP360 installer distributed under deceptive filenames designed to resemble legitimate business documents and software.

Execution

• T1059.001 Command and Scripting Interpreter: PowerShell | The MSP360 RMM.Agent.exe service launched PowerShell to download and install ConnectWise ScreenConnect.
• T1059.003 Command and Scripting Interpreter: Windows Command Shell | Installation workflows used cmd.exe for logging, prerequisite checks, file management, and installation-related tasks.
• T1218.007 System Binary Proxy Execution: Msiexec | The downloaded ClientSetup.msi package was installed silently using msiexec.exe /qn.

Persistence

• T1543.003 Create or Modify System Process: Windows Service | MSP360 and ScreenConnect were installed as Windows services to establish persistent access.
• T1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | MSP360 created registry Run entries to automatically launch tray application components at user logon.

Defense Evasion

• T1036 Masquerading | The actor distributed legitimate MSP360 software under filenames designed to resemble meeting applications, invitations, PDFs, and business documents.
• T1036.005 Match Legitimate Name or Location | Follow-on tooling used filenames that closely resembled legitimate Windows, Microsoft Defender, security, and Phone Link applications.
• T1112 Modify Registry | MSP360 and ScreenConnect modified registry locations associated with services, persistence, credential provider components, protocol handlers, and uninstall entries.

Command and Control

• T1219 Remote Access Software | The threat actor abused legitimate remote administration software including MSP360 RMM and ConnectWise ScreenConnect to maintain access to victim systems.
• T1105 Ingress Tool Transfer | MSP360 downloaded ScreenConnect, while the threat actor’s use of ScreenConnect was subsequently used to transfer and execute additional tooling on compromised endpoints.
• T1071.001 Application Layer Protocol: Web Protocols | PowerShell and ScreenConnect communicated with actor-controlled infrastructure over HTTP/HTTPS.
• T1573 Encrypted Channel | Payload retrieval and remote access communications occurred over encrypted network channels.
• T1102 Web Service | Multiple cloud-hosted web services were used throughout the delivery and command-and-control infrastructure.

Discovery

• T1082 System Information Discovery | The installer enumerated installed .NET runtimes using dotnet –list-runtimes during the installation workflow.

Collection

• T1005 Data from Local System | Additional tooling delivered through ScreenConnect was observed in post-compromise activity and used to collect information from victim devices.

Indicators of compromise (IOCs)

Observed indicators associated with this campaign are listed below.

IndicatorTypeDescription•108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dcSHA256Legitimate MSP360 RMM v2.5.0.67 installer observed being distributed under deceptive filenames during the campaign. The observed sample was signed using a certificate that has since been revoked.•f094b8263471c7b76dbed03d420736449920368fa0eca2ed6b1aea2645138d97
•857c2f283de799faa74b56e862c0a9f96e67aa1b4fa4a9e46395098365b99de3
•6a89de024ca62536de6f5fc10e49896bb1ac330ca39dce30203afdcc45ae237e
•4188c6588f3dcda881c3f2d12df580051179a999f040b799af506edeb3211a26SHA256Legitimate MSP360 RMM Agent Service observed during the campaign•adswre[.]cfd
•trews[.]cfd
•swedcorry[.]stefneyv[.]com
•ojsuyw[.]niyari[.]org
•bunstar[.]harej[.]si
•adsaw[.]cfd
•sdfghj[.]rd-team[.]ruDomainsDomains contacted by ScreenConnect clients in observed malicious sessions.•ceb3f7fe9a618ff29a21b126383c23900fad58d6ae2b5552d7e306e4b6acf4b0
•02f2ce03a2650f17bfe6e8744eebbf58522016cbdb92af8f2217b5dd4a1ad550
•499d07894f730fb685ee3cbfc1a933e0da93750c1ed25a49b2eb9c32adef156a
•d49cc01641c3045bf3119f9d71e7ffd29bfce32ca4b27cc96340716ed4d41cdc
•67c979dc13961b09f24f85a801e4c918420adca6117c92efbeeeaa68a6344f55
•6cc665057c4a4fe42a309afd3a7fa96cf1af126e9c6e08e56df5105e05378bcc
•dd434f3ffcafeda538d43226665115ba136ad0fdb43dad8536e1368ca9a17b64
•40f8e774e1e7a484b78c7ae4336bc47aa9cab20dc8e1e67d89838e807975f9b1
•3ff5e49fd2f2bd0758467763c44d69e781b7460af84a6e3966e2621bc5bf7096
•374c4934b14a1151ea68847c8627c3f1c0b878f4e673bda3f15e4388dfde0187
•bc8b1b0c80512ba0e8ffccfee5b507df16a3355db1143c3ba81ef42dac1baa6c
•c2c004a56de2a99f5b06ceb58d8a4b371fb60fd66ff5936786fe8d8037ead208
•5bf8cf29ac6803e7269b045dea48003af7cfe48bedfc081b57ff9e86cb08971b
•19035c8e2520fb70b3e2ec5338c14311b88a26cc1fb8304a01494260b6b55af1
•d232d82e410de12702a67c58acf927304ee42f3e6d81a9d71eca99f9052126db
•d3cb7ded277b49be06e6a1860f7c7e913e252802e9d32453a185e24797bf53ef
•e31e5da7c58a7e8f89f9629f095edd7d741a1fb0b85fcb39f3818dbd9497b1e3
•1a534d04bf30894d20764e91f7e94e0a73f060f0abacc9feeedba427995c83a8
•77fb0e75f4396cb57bbbd28f6dc5310369a87abec9e2acc457aa99a0063ed27a
•fc96a04c615847f0fb1391f04d9d1aac7f78ddfb7d459168df0a4172b98354e2
•06ad69b9bebad3cc75b594cc5bb1ca0035ea22bb8a683002ca051d948566426b
•a93c946c237b981189d2668d938a9d4d1d9681757e48dae8d9d65ed25b5da657
•529543b4fe6a4c21d28be56dbf92fcac91d8df808d8518b4275c973fa547ad63
•ccea4e1acc51ac43ba9da76ada00e7e308cc33d9c5c264dff82d1be83e957b88
•a03c84ae9e569c04fdd271277f508bba5a299d53c3c0efe0819338d178fe1c5bSHA256Utilities transferred or executed through ScreenConnect sessions and observed during post-compromise activity. Several of the identified tools are commonly associated with credential access, information collection, and efforts to reduce defender visibility. Learn More

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

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

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

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

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Phishing Abuses RMM Tools for Persistent Access appeared first on Microsoft Security Blog.

What began as a single compromised identity quickly expanded into an organization’s development and cloud environments. In our latest Cyberattack Series report, we examine how the Microsoft Detection and Response Team (DART)—the team that delivers Microsoft Defender Experts Cybersecurity Incident Response—investigated activity by Storm-3068, a threat actor that turned a successful self-service password reset into access to Azure DevOps, development pipelines, and Kubernetes resources. By leveraging legitimate identity and cloud services rather than malware or software exploits, the threat actor established persistent access, enumerated repositories, and obtained credentials that opened a path into connected cloud infrastructure. This case highlights a growing challenge for defenders: when identities, source code, pipelines, and production environments are tightly linked, a single account compromise can provide a pathway to much broader access across the organization. Read on to learn more or access the full report. 

Read the full cyberattack report What happened? 

The intrusion began with Storm-3068 gaining access to a user account through a self-service password reset process and then taking full control of the identity by registering its own authentication methods. With persistent access established, the threat actor shifted its focus to Azure DevOps using legitimate administrative tools and automated scripts to enumerate repositories, projects, pipelines, and deployment environments.

TACTIC: Trusted pipelines were exploited
Rather than deploying malware, the threat actor modified development pipelines to collect Kubernetes credentials and expand access into cloud infrastructure.​​ 

Azure DevOps proved to be a high-value target because it sat at the intersection of identity, software development, and cloud operations. By mapping trusted deployment paths and connected resources, the threat actor was able to identify opportunities to expand beyond the initial compromise.

The investigation revealed that Storm-3068 created a malicious pipeline designed to harvest Kubernetes credentials at scale. The pipeline deployed a kube agent and executed multiple jobs intended to collect kubeconfig files containing cluster connection details and authentication information. Leveraging the permissions of the compromised account, the threat actor deployed the pipeline that was authorized to access more than 50 resources and authenticated to services. In addition to deploying a kube agent, the threat actor modified pipeline scripts to install the Atera remote management agent and download the Chisel tunneling utility. These tools were deployed in an attempt to provide the threat actor with alternative mechanisms for remote access and to expose the Kubernetes API server. Chisel commands were executed to establish a reverse tunnel to an external IP address to enable potential remote interaction with the Kubernetes clusters.

Using Azure DevOps audit logs and Git version history, investigators reconstructed the next stage of the intrusion. The threat actor added seven stolen kubeconfig files to a repository, providing the credentials needed to access targeted Kubernetes clusters.

INSIGHT: Azure DevOps can reveal much more than source code
Repositories, pipelines, service connections, and deployment settings can provide threat actors with a roadmap to an organization’s broader environment.

How did Microsoft respond? 

Once engaged, DART moved quickly to investigate the intrusion and disrupt the threat actor’s access. By analyzing telemetry across identity systems, development platforms, and cloud infrastructure, the team pieced together how the cyberattack unfolded and identified where the threat actor had expanded beyond the initial compromise.

Throughout the engagement, DART worked side by side with the customer, sharing findings through daily briefings and providing prioritized guidance to support containment and remediation efforts. As new details emerged, this close coordination helped the customer make informed decisions and respond quickly. DART also collaborated with Microsoft Threat Intelligence to place the activity in a broader threat context, helping refine the investigation and focus response efforts across affected environments.

Beyond containing the intrusion, DART provided recommendations to help improve resilience and reduce opportunities for future compromise. Read the full report to learn how the investigation uncovered the extent of the threat actor’s access and the key lessons organizations can apply to defend against similar identity-driven attacks. 

Learn more about Microsoft Defender Experts Cybersecurity Incident Response What can customers do to strengthen their defenses? 

 While the attack began with a compromised identity, its impact grew as the threat actor moved through development and cloud environments. Organizations can reduce similar risks by focusing on:

• Monitoring password reset activity for unusual patterns, including repeated reset attempts or activity targeting multiple users.
• Strengthening protection for privileged accounts by limiting exposure to self-service password reset workflows and requiring phishing-resistant multifactor authentication.
• Requiring approvals for code changes and enforcing branch protection policies to prevent unauthorized modifications.
• Restricting direct commits to critical branches so changes follow established review and approval processes.
• Controlling pipeline permissions and limiting who can create, modify, or execute build and deployment pipelines.
• Applying least-privilege access principles across identities, development platforms, and cloud resources to minimize the impact of a compromised account.

INSIGHT: Identities are the new attack path
This incident demonstrates how a single compromised identity can provide access to development platforms, cloud resources, and production environments when those systems are tightly connected.​ 

As this case demonstrates, a single compromised identity can become a pathway to much broader access when development platforms, deployment pipelines, and cloud infrastructure are tightly connected. Regular reviews of identity, DevOps, and cloud security controls can help reduce opportunities for threat actors to exploit those connections.

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 compromise 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.  

Read the latest cyberattack report Learn more

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

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

The post ​​Beyond source code: A path to the keys to the kingdom appeared first on Microsoft Security Blog.

In this article

1. Star Blizzard TTPs observed in 2026
2. Defending against Star Blizzard and RedFlick-related activity
3. Microsoft Defender detections
4. Hunting queries
5. Indicators of compromise

Since January 2026, Microsoft has observed Russian state threat actor Star Blizzard evolve their detection evasion capabilities through large-scale phishing campaigns, the use of accounts on compromised websites, and a novel malware delivery technique that Microsoft tracks as “RedFlick”. These changes represent a notable shift in the actor’s operational tradecraft and support ongoing cyberespionage activity targeting Ukrainian individuals and institutions as well as international non-government organizations (NGOs), Western think tanks, governments, and other organizations associated with international policy—particularly those with a nexus in supporting Ukraine.

As part of this evolution, Star Blizzard adopted RedFlick, a malware delivery technique that helps evade detection by initiating a set of scheduled tasks to deploy the actor’s custom backdoor, CosmicPulse. This technique is a notable departure from the actor’s previous use of ClickFix-based infection chains which required victims to complete multiple actions before CosmicPulse could be installed. By contrast, the RedFlick infection flow only requires a single user interaction, reducing friction in the compromise process. Combined with the actor’s shift toward large-scale phishing operations during the same period, these changes likely improve Star Blizzard’s ability to reach more targets, evade detection, and increase the likelihood of successful compromise.

This blog provides updated technical analysis of Star Blizzard’s tactics, techniques, and procedures (TTPs) observed throughout 2026, building on our 2025 and 2023 blogs. It details the actor’s evolving phishing, persistence, and malware delivery techniques, and provides recommendations, indicators of compromise (IOCs), detections, and hunting guidance to help organizations identify and defend against RedFlick-related activity. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with recommendations and mitigations to secure their accounts.

Star Blizzard TTPs observed in 2026

Star Blizzard is attributed by the United States Cybersecurity and Infrastructure Agency (CISA) as subordinate to the Russian Federal Security Service Centre (FSB) Centre 18. Star Blizzard periodically overhauls their TTPs to avoid detection, often in response to public exposure of the actor’s campaigns that have involved targeted social engineering through messaging apps and credential theft. Since Google Threat Intelligence Group published its report on Star Blizzard’s COLDCOPY malware in October 2025, Microsoft observed the actor refine their initial access and evasive techniques to include:

• Moving away from targeted spear phishing to large-scale initial contact phishing campaigns
• Using compromised websites to create accounts to send phishing emails
• Updating malware deployment to facilitate the installation of a CosmicPulse downloader

As of the writing of this blog, the RedFlick campaigns have targeted Ukrainian individuals and institutions, as well as international NGOs, think tanks, governments, and financial institutions that have supported Ukraine politically or financially. Microsoft has observed this activity affect over 100 organizations primarily in the United States and United Kingdom, consistent with Star Blizzard’s longstanding targeting priorities.

Microsoft continues to observe some previously reported Star Blizzard phishing techniques throughout 2026; however, the TTPs discussed in this blog have been associated primarily with the actor’s new larger-scale phishing campaigns.

Larger-scale initial contact phishing

Microsoft previously reported on Star Blizzard’s spear-phishing campaigns observed during 2023-2024. During these operations, the actor continued to rely on their conventional TTPs such as initiating email contact with targets before sending a follow-up containing a malicious link, to actor-controlled/compromised infrastructure purposed for credential theft, while impersonating known political or diplomatic figures to lure victims into responding.

In 2026, Microsoft observed Star Blizzard shift from exclusively targeted spear-phishing operations to also conducting larger-scale phishing campaigns. The larger-scale phishing operations were observed at a scale not previously seen from the actor, ranging from tens to hundreds of email messages per campaign. This change likely reflects the actor’s adoption of a mass-mailing phishing platform to automate campaign execution and increase the likelihood of successful compromises by significantly expanding the initial targeting pool. The progression of these campaigns is summarized in the following timeline, including examples of Star Blizzard’s phishing subject lines, targeting details, and the malware delivery methods observed across each campaign:

• January
  • “Повідомлення про результати податкової перевірки” (Notice of tax audit results) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• February
  • “списання з Вашого рахунку за оплату штрафу” (Debiting from your account for payment of a fine) – Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
• March
  • “Invitation to an IISS [Private Roundtable/Closed-Door Discussion] on European Security” – Initial contact campaign targeting government officials, security researchers, academia, media, and NGOs. Respondents received a RedFlick lure attachment.
  • “Invitation to a Closed CES Roundtable Discussion” – Initial contact campaign targeting US and Europe technology-sector organizations. Respondents received a RedFlick lure attachment.
  • “Atlantic Council Closed-Door Strategic Discussion” – Initial contact campaign targeting government officials, foreign policy practitioners, security researchers, academia, media, and NGOs. Respondents received a link to DarkSword iOS backdoor installation.
• April
  • “Closed-Door Online Session on Global Capital Allocation & M&A” – Initial contact campaign targeting international financial organizations and researchers. Respondents received a RedFlick lure attachment.
• May
  • “Future of Peace Operations Forum – A Closed Strategic Dialogue” – Initial contact campaign targeting diplomatic and multilateral organizations. Respondents received a RedFlick lure attachment.
  • “Future of Liberty Forum” – Initial contact campaign targeting employees of a US-based think tank. Respondents received a RedFlick lure attachment.
• June
  • “Invitation to the MAMA Summit on the Current Situation Surrounding the Ukrainian Crisis” – Initial contact campaign targeting incumbent/former diplomatic staff. Respondents received a RedFlick lure attachment.
  • “Invitation to the Chatham House London Conference 2026 – 9 July 2026” – Initial contact campaign targeting think tanks, NGOs, and national parliamentary. Respondents received a RedFlick lure attachment.
• July
  • “Thought you might find this USUBC roundtable of interest” – Initial contact campaign targeting think tanks, NGOs, and Ukraine civil society. Respondents received a RedFlick lure attachment.
  • “Інформація щодо тимчасового відключення водопостачання” (Information about temporary water supply shutdown) – Targeted Kyiv-based hotels with an attached RedFlick lure.
• August
  • “Payment Advice Note from 06.08.2026” – Targeted employees of an international financial organization with an attached RedFlick lure.

Once a recipient responds to the initial phishing email, Star Blizzard typically sends a follow-up message containing a password-protected RAR or ZIP archive. The archive contains files that initiate the RedFlick infection flow. The password is included as an image in the follow-up email shown in Figure 1, along with additional examples of Star Blizzard follow-up emails below:

Figure 1. July 2026 RedFlick campaign follow-up email regarding an “omitted” attachment Figure 2. June 2026 RedFlick campaign follow-up email with the subject line “Invitation to the Chatham House London Conference 2026” Figure 3. August 2026 RedFlick campaign follow-up email with a payment notice subject line sent to all targets

Since January 2026, Microsoft observed at least 13 distinct large-scale phishing campaigns targeting primarily NGOs, think tanks, and government organizations worldwide. The earliest campaigns, observed between January and February, targeted unspecified users of the Ukraine email provider Ukr.net. These emails impersonated Ukrainian authorities and were themed as notifications of a tax audit or outstanding fine.

Beginning in March 2026, Star Blizzard expanded targeting outside of Ukraine. Subsequent campaigns frequently used lures themed as invitations to conferences or events purportedly organized by a reputable think tank or NGO. Microsoft also observed the actor target multiple individuals within the same organization, with phishing emails often crafted to appear as internal communications originating from the targeted organization itself. The actor’s shift from Ukraine-focused operations to global targets could indicate Star Blizzard initially targeted Ukraine to test their new capabilities.

The large-scale campaigns have demonstrated capabilities previously unassociated with Star Blizzard. For example, a campaign observed in mid-August 2026 employed steganography to conceal identifiers. Throughout 2026, Star Blizzard has also continued to develop additional operational capabilities. Notably, ProofPoint reported in March that the actor had targeted vulnerable Apple iOS devices to deploy the DarkSword backdoor.

Creating accounts on compromised websites

Since March 2026, Star Blizzard has made another notable change to their TTPs to support the higher-volume phishing operations, using accounts created on compromised websites to send phishing emails to targets. This change coincided with the actor’s shift to larger-scale phishing campaigns and has been observed almost exclusively in support of these operations. Previously, the actor would create accounts on free email services (predominantly using Protonmail and Microsoft consumer accounts) to impersonate an individual that would be well known to the prospective target, whether it was a political figure, academic, or former diplomat. In the large-scale campaigns, Star Blizzard has used accounts created on websites hosted on CPanel and WordPress, using the same account name across multiple website domains. Microsoft Threat Intelligence assesses with high confidence that these websites have been compromised by Star Blizzard for this purpose.

Updating malware delivery and installation TTPs

Between January and August 2026, Microsoft observed multiple waves of Star Blizzard phishing campaigns alongside notable changes in the actor’s initial access TTPs, particularly the use of RedFlick scheduled tasks. During this period, Microsoft observed three significant shifts in the threat actor’s delivery techniques.

From ClickFix to VHDX Figure 4. VHDX lure execution chain

In mid-January 2026, Microsoft observed the use of a malicious Virtual Hard Disk v2 (VHDX), delivered through a phishing email containing a password-protected ZIP file. The VHDX file ships a malicious LNK file disguised as a PDF document, alongside a hidden directory containing a BAT script and a legitimate decoy PDF.

When the victim opens the LNK file, conhost.exe is launched in a hidden window and cmd.exe is subsequently spawned to execute the embedded BAT script:

The BAT file opens the decoy PDF and invokes SSH.exe with PermitLocalCommand enabled, ultimately downloading and executing a remotely hosted MSI installer:

In multiple campaigns, Microsoft observed an MSI installer creating a scheduled task that uses control.exe to download and execute a remotely hosted CosmicPulse downloader masquerading as a Control Panel applet (CPL). Unlike earlier campaigns that relied on ClickFix lures and user interaction, this approach relies on compiling the CosmicPulse downloader as a Control Panel applet DLL.

The shift from interactive user execution to remote execution and masquerading as a CPL item highlights an evolution in both persistence and defense evasion techniques.

CosmicPulse downloader

The Control Panel applet DLL is a downloader with the sole purpose of downloading and installing a version of CosmicPulse, a malicious Python backdoor, on the target device. The downloader is also known publically as NOROBOT or BAITSWITCH.

Similar to previous versions, this downloader downloads, persists, and executes a version of CosmicPulse on the infected device. Upon execution, it downloads two ZIP files and stores them on disk. It then writes an encrypted AES key to the HKEY_CURRENT_USER\Software\Classes\.mollis registry key. One ZIP file contains a Python 3.8 64-bit package and a Python file that serves as the CosmicPulse bootstrapper. The bootstrapper reads the encrypted key from the registry, recovers it using an embedded key in AES-ECB mode, and then uses the recovered key to decode the CosmicPulse payload (also known as YESROBOT) contained in the second ZIP file. The below image shows the process of the CosmicPulse installation.

Figure 5. CosmicPulse downloader, installing CosmicPulse backdoor

Since January 2026, Microsoft has observed the CosmicPulse backdoor going through various little changes to circumvent existing signatures. However, the capabilities and purpose of this backdoor remain the same as described in previous articles.

Persistence through multiple scheduled tasks

In April 2026, Microsoft observed Star Blizzard changing persistence tactics to include RedFlick scheduled tasks. Whereas a malicious MSI file installed a single scheduled task in January—by April, the actor’s MSI installer created three scheduled tasks masquerading as legitimate network components, each with their own purpose. The TTPs have overlaps with the spear-phishing campaigns reported by the Digital Security Lab Ukraine (DLUA) in June 2026. In at least one incident, Microsoft has observed either the first or third task deploying an instance of CosmicPulse on the infected machine.

Figure 6. Scheduled task installed through MSI installer observed in April 2026

Task 1 – Registration beaconing and dynamic DLL execution task

The first task masquerades as a legitimate Internet Quality Test Connection task. The scheduled command serves two purposes. First, it sends a UTF-16 and Base64-encoded string containing the network or computer name and the username of the infected device to the C2 server. Thereby, it exfiltrates basic information about the infected host.

Second, an attacker-controlled DLL can be executed remotely through invoking Control_RunDLL from Shell32.dll. Microsoft was unable to obtain a variant of this payload. The task uses a WebDAV UNC path to access the remote payload, allowing the resource to be retrieved over HTTP rather than through a conventional SMB network share.

Task 2 – Supporting task

The second installed task, named Network Configuration Manager, supports the WebDAV-based execution used by the other tasks. The invoked command causes Windows to treat the UNC-style path as a WebDAV resource and process it through the WebDAV redirector and associated WebClient functionality.

Through WebDAV, Windows applications can interact with a remote web resource as though it is a file or folder path while the underlying communication is performed using HTTP/HTTPS rather than conventional SMB. The task therefore prepares the WebDAV client functionality required by the other scheduled tasks.

Task 3 – CosmicPulse downloader execution

The third installed task, named System Health Monitor, uses control.exe to access a remote path hosted on the hardcoded C2 server and execute the next stage.

Hiding payloads in PDF files

In July 2026, Microsoft observed another change in Star Blizzard’s delivery techniques, this time involving a multistage execution chain.

Figure 7. Overview of attack chain from July 2026

The phishing email contains a password-protected RAR archive nested inside a ZIP file. After the archive is opened, it exposes an LNK file.

When executed, the LNK file uses conhost.exe and curl to download a PDF from an actor-controlled server:

After downloading the PDF, the command runs a second PowerShell payload. This payload searches the PDF for the magic header cAB, extracts the subsequent 208 bytes of Base64-encoded data, and executes the decoded command through PowerShell. The resulting conhost command, shown below, attempts to download and install another MSI file:

As in previous campaigns, the Python installer contains obfuscated PowerShell code. When executed, the code attempts to create two additional scheduled tasks. The first scheduled task again serves as a helper task, consistent with the supporting tasks observed in previous campaigns. The second scheduled task attempts to download and execute a CPL applet again.

Star Blizzard’s shift from ClickFix-based delivery chains to VHDX files, expanded use of scheduled tasks for persistence, and concealment of payloads within PDF files demonstrate the actor’s continued ability to adapt their delivery methods in response to evolving defenses. The actor’s recent use of PDFs to conceal payloads further illustrates efforts to bypass layered defenses through increasingly complex execution chains. Taken together, these changes demonstrate Star Blizzard’s continued efforts to streamline malware deployment, reduce required user interaction, and improve operational scalability while maintaining its longstanding espionage objectives.

Defending against Star Blizzard and RedFlick-related activity

Microsoft Threat Intelligence advises organizations that are most likely at risk—primarily those in government, NGOs, or think tanks adjacent to Ukraine policy or support—to implement the following recommendations to mitigate against Star Blizzard activity.

Protecting against Star Blizzard phishing

As previously reported, Star Blizzard’s success relies on sophisticated, targeted phishing lures that trick users into engaging with the actor by impersonating trusted contacts. While Star Blizzard has changed their overall TTPs, the actor continues to employ the same phishing patterns against users:

• Star Blizzard continues to impersonate trusted contacts that users or organizations would expect an email from. Star Blizzard also continues using email from free providers such as Proton @proton[.]me, particularly in Evilginx spear-phishing operations observed throughout 2026. However, despite the actor’s recent shift toward leveraging compromised legitimate websites that impersonate real individuals associated with a target’s organization, users can still remain vigilant for other Star Blizzard TTPs, several of which have been observed in previous campaigns:
  • Star Blizzard continues to make initial contact with a target by sending an email, usually without an attachment.
  • If a user engages, Star Blizzard will follow up with an email with an attachment. In this particular campaign, it has been an archive file such as a RAR or ZIP.
  • The email sender contains names of actual persons and organizations they belong to—however, the organization is not within the root or registered domain itself but in the username or local part of the email address. This should draw a red flag to the email’s authenticity. When in doubt, directly contact the person you think sent the email using a previously established and trusted contact method such as known email address or phone number.
  • The emails in these RedFlick campaigns are often sent in bulk.
• To best mitigate against this activity, Microsoft suggests the following policies to strengthen network environments against Star Blizzard phishing operations:
  • Using phishing resistant authentication methods.
  • Lockdown account access using Conditional Access policies.
  • Use advanced anti-phishing solutions like Microsoft Defender for Office 365 that monitor and scan incoming emails and visited websites.
  • Turn on Safe Links and Safe Attachments for Office 365.

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

• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.
• 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.
• Configure investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable Conditional Access policies. Conditional Access policies evaluate sign-in requests using additional identity driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
• Implement continuous access evaluation.
• Turn on Microsoft Defender Antivirus real-time protection.
• Continuously monitor suspicious or anomalous activities. Investigate sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services).
• Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
• Use the Attack Simulator in Microsoft Defender for Office 365 to organize realistic, yet safe, simulated phishing and password attack campaigns in your organization by training end users against clicking URLs in unsolicited messages and disclosing their credentials. Training should include checking for poor spelling and grammar in phishing emails or the application’s consent screen as well as spoofed app names, logos, and domain URLs appearing to originate from legitimate applications or companies. Note that Attack Simulator testing only supports phishing emails containing links at this time.
• Microsoft Defender customers can turn on attack surface reduction rules to prevent common attack techniques:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts
• Utilize Windows Firewall, Windows Firewall with Advanced Security, or an enterprise firewall/filtering solution to help prevent or restrict outbound SSH connection attempts to external or public networks that are not essential for business.

Microsoft Defender detections

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

Tactic Observed activity Microsoft Defender coverage Initial access– Phishing emails with attached archive files or PDFs throughout the campaign
– VHDX file executes malicious LNK disguised as a PDF; use of LNK to hide malicious payload across all campaigns
– LNK file uses curl to download a PDF from an actor-controlled serverMicrosoft Defender for Endpoint
– Star Blizzard Activity Group
– Suspected PDF phishing detected
– Suspicious phishing activity detected
– Suspicious LNK execution from container
– Suspicious file download via curl Execution– Execution of RedFlick scheduled task and CosmicPulse backdoor
– MSI file installs scheduled tasks across all campaigns Microsoft Defender Antivirus
– Trojan:Script/RedFlick
– Backdoor:Script/CosmicPulse
– Backdoor:Python/CosmicPulse

Microsoft Defender for Endpoint
– Suspicious msiexec.exe behavior
– Suspicious script execution Stealth– CosmicPulse downloader masquerades as a Control Panel applet.
– The LNK file is disguised as a PDFMicrosoft Defender for Endpoint
– Suspicious use of Control Panel item
– Suspicious process name Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor profile: Star Blizzard
• Tool profile: CosmicPulse
• Activity profile: New Star Blizzard spearphishing campaign targets WhatsApp accounts
• Threat overview: Evolving phishing threats

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

Hunting queries Microsoft Defender XDR

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

Conhost.exe invokes curl

The following query will detect the use of conhost.exe to launch curl to download a decoy PDF from an actor-controlled server, which Star Blizzard used in July 2026. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents | where Timestamp > ago(7d) | where FileName == "conhost.exe" | where ProcessCommandLine has "curl" | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName, DeviceId, ProcessId, ProcessUniqueId, InitiatingProcessUniqueId

Invoke SSH to launch local command line

The following query will detect the invocation of SSH to initiate a local command prompt, which Star Blizzard used in January 2026 to download and execute a remotely hosted MSI installer. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)

DeviceProcessEvents | where Timestamp > ago(7d) | where ProcessCommandLine has "ssh.exe" | where ProcessCommandLine has "PermitLocalCommand=yes" | where ProcessCommandLine has "LocalCommand=cmd.exe" | project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, ProcessId, InitiatingProcessId, ReportId

Persistence through scheduled tasks

The following query will detect Star Blizzard’s uniquely named scheduled tasks that attempt to masquerade as legitimately-named tasks, used for persistence by Star Blizzard in April 2026.

union isfuzzy=true ( DeviceProcessEvents | where Timestamp > ago(7d) | where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") | project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields , RegistryKey = tostring(dynamic(null)), RegistryValueName = tostring(dynamic(null)) , SourceTable = "DeviceProcessEvents" , ProcessId, AccountName, AccountDomain, AccountSid ) , ( DeviceEvents | where Timestamp > ago(7d) | where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") | project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields, RegistryKey, RegistryValueName , SourceTable = "DeviceEvents" , ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = "" ) , ( DeviceRegistryEvents | where Timestamp > ago(7d) | where RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueData has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or InitiatingProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") | project Timestamp, DeviceName, ActionType , ProcessCommandLine = InitiatingProcessCommandLine, AdditionalFields = "" , RegistryKey, RegistryValueName , SourceTable = "DeviceRegistryEvents" , ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = "" ) Microsoft Sentinel

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

Detect network IP and domain indicators of compromise using ASIM

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

let lookback = 30d; let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]); let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]); _Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now()) | where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains) | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and file hash indicators of compromise using ASIM

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

let lookback = 30d; let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]); let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]); _Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now()) | where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains) or Url has_any (ioc_domains) | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Url, Dvc, EventProduct, EventVendor Indicators of compromise IndicatorTypeDescription9707a8694e954e9ee13e839d6e5905ce626c0837c7c90da6d1025bfbe152866bSHA-256Password protected ZIP attachment with file name Documents.zip; observed in January campaign against Ukraine.1f2096ff906915fbf80778f0636446206197351f7e271af97936eeb6f32c179dSHA-256Virtual Disk Image file with file name Documents.vhdx; observed in January campaign against Ukraine; contained in 9707a8694e954e9ee13e839d6e5905ce626c0837c7c90da6d1025bfbe152866b699e92a9e0edf7835879d5697bc67138c0b137117f459caf1a44df357407cad9SHA-256Password protected email attachment with file name Chatham_London_Conference_2026_Invitation.rar; used in June campaign; Password: LiveCrown814224b6e36a09eb2acfc2a95478ca685acb7593b1689be6a4a639fe0d222393cfa7SHA-256Password protected email attachment with file name USUBC_Private_Executive_Roundtable_Webex.rar; used in July campaign; Password: LiteRaspberry9415dd98dbc1a55afe6fd0ed2ed53a79c76f6bde15081a0060422185b74eb1799ee4SHA-256Password protected email attachment with file name Payment Advice Note.zip; used in August campaign in which the actor introduces a new TTP of sending unique ZIP files to each target; Password: BirdMouseCrabetia[.]caDomainHost for RedFlick MSI installer in January 2026 campaign103.245.231[.]248IPv4Host for CosmicPulse downloader DLL in January 2026 campaigngroy[.]ccDomainHost for RedFlick MSI installer in February 2026 campaign2.57.241[.]246IPv4Host for CosmicPulse downloader DLL in February 2026 campaigngliderrompercycl[.]comDomainHost for CosmicPulse backdoor downloadmuvb[.]netDomainHost for RedFlick MSI installer in February 2026 campaign89.125.209[.]168IPv4Host for CosmicPulse downloader DLL in February 2026 campaigndivekickspolic[.]orgDomainHost for CosmicPulse backdoor downloadmatjk[.]clickDomainHost for RedFlick MSI installer in March 2026 campaignbpdaersa[.]clickDomainHost for RedFlick MSI installer in March 2026 campaign103.245.231[.]79IPv4Host for CosmicPulse downloader DLL in March 2026 campaignstuseamandesilt[.]orgDomainHost for CosmicPulse backdoor downloadItechx[.]telDomainHost for RedFlick MSI installer in April 2026 campaign45.84.59[.]66IPv4Host for CosmicPulse downloader DLL in April 2026 campaignguach[.]netDomainHost for RedFlick PowerShell code installer in June 2026 campaignruten[.]observerDomainHost for CosmicPulse downloader DLL in June-July 2026 campaignsbyveo[.]orgDomainHost for RedFlick PowerShell code installer in July 2026 campaignsecure-dns-hub[.]comDomainHost for CosmicPulse downloader DLL in July 2026-current campaigns103.160.59[.]97IPv4Host for CosmicPulse downloader DLL in July 2026 campaignqumel[.]linkDomainHost for CosmicPulse downloader DLL in July 2026 campaigncyrna[.]topDomainHost for RedFlick MSI installer in August 2026 campaigndrasw[.]clubDomainHost for CosmicPulse downloader DLL in August 2026 campaign References

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-341a
• https://www.zscaler.com/blogs/security-research/coldriver-updates-arsenal-baitswitch-and-simplefix
• https://dslua.org/publications/spearphishing-via-fake-urc-2026-invitations-targets-ukrainian-csos/
• https://cloud.google.com/blog/topics/threat-intelligence/new-malware-russia-coldriver
• https://x.com/threatinsight/status/2037560142880006266

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 Star Blizzard refines phishing and malware delivery with the RedFlick technique appeared first on Microsoft Security Blog.

In this article

1. Observed operators and targeting
2. Malware packaging and distribution
3. NeedyMantis architecture and capabilities
4. Mitigation and protection guidance
5. Hunting queries
6. Indicators of compromise

Microsoft Threat Intelligence has identified NeedyMantis, a modular post-compromise malware family observed in a limited number of targeted operations affecting telecommunications organizations, universities, medical nonprofits, intergovernmental organizations, and government contractors. Based on observed activity, NeedyMantis is typically deployed after a threat actor has already established access to a target environment, indicating that the malware is used to maintain long-term access and support follow-on operations.

NeedyMantis activity dates back to at least October 2025. We discovered the malware family while analyzing and pivoting from research and indicators of compromise associated with the DAEMON Tools supply chain compromise, which Kaspersky previously reported on as part of its investigation into the campaign. Observed activity involving NeedyMantis has thus far aligned with activity that Microsoft associates with threat actors operating from China, although Microsoft has not determined whether all observed activity is attributable to the same operator.

While NeedyMantis employs techniques commonly used by modern malware, its architecture combines multiple loaders, custom encrypted file archives, a custom executable file format, and modular components that enable operators to evade analysis and extend functionality through additional modules. These characteristics, combined with its use in targeted intrusions, make NeedyMantis a useful case study for understanding how threat actors establish and maintain long-term access within victim environments.

In this blog, we analyze the NeedyMantis malware framework. We examine its packaging and deployment, custom archive format, loader architecture, command-and-control (C2) communications, and modular design. We also provide indicators of compromise (IOCs), Microsoft Defender detections, and mitigation guidance to help organizations defend against this threat and related activity.

Observed operators and targeting

At the time of writing, Microsoft has observed at least one threat actor using NeedyMantis malware: Storm-3069. Storm-3069 is Microsoft Threat Intelligence’s designator for activity associated with the DAEMON Tools supply chain compromise. While Microsoft assesses the activity originates from China, it has not attributed Storm-3069 to a Chinese nation-state actor. Microsoft identified NeedyMantis through follow-on analysis of indicators associated with Kaspersky’s investigation of the DAEMON Tools compromise.

Microsoft has observed additional NeedyMantis activity beyond Storm-3069’s activity in the DAEMON Tools campaign, indicating that the malware might be used by more than one operator. Observed activity involving NeedyMantis has thus far aligned with activity Microsoft associates with threat actors operating from China, such as targeting that aligns with Chinese interests and the use of selective deployment.

NeedyMantis has been observed in intrusions affecting telecommunications organizations, universities, intergovernmental organizations, medical nonprofits, and government contractors. Combined with the malware’s limited observed deployment and alignment with activity Microsoft associates with China-based threat actors, this victimology suggests NeedyMantis is deployed selectively rather than broadly. However, Microsoft has not determined whether all observed activity is attributable to the same threat actor or whether multiple actors have access to the malware.

Malware packaging and distribution

As previously mentioned, observed activity suggests that the malware is typically deployed after a threat actor has established access to a target environment. As a result, the methods used to gain access before NeedyMantis is deployed may vary across intrusions.

NeedyMantis is composed of multiple components written in C++ and x64 shellcode. The malware starts with a first-stage loader and a file archive. The loader and archive have been found packaged alongside legitimate software, with the first-stage loader–masquerading as a required DLL—being loaded through DLL sideloading.

Some of the open-source, software abused by the malware include: Poedit (translation), curl (data transfer), Vim (text editor), and TightVNC (remote access). Microsoft has also observed NeedyMantis masquerading as Microsoft Office, Broadcom, Intel, and NVIDIA DLL components. The following is a list of some of the DLL path names used by the malware:

• %ProgramFiles%\Poedit\WinSparkle.dll
• %ProgramData%\USOShared\libcurl.dll
• %ProgramData%\VIM\vim64.dll
• %ProgramData%\TightVNC\VIM\vim64.dll
• %ProgramData%\office\dbghelp.dll
• %ProgramData%\broadcom\dbghelp.dll
• %ProgramData%\Intel\jli.dll
• %ProgramFiles%\modifiable\nvml.dll
• %ProgramData%\ics\nvml.dll

The malware’s file archive is named the same as the loader DLL without the extension, for example WinSparkle or libcurl.

In one observed incident, an operator used the Impacket toolkit during hands-on-keyboard activity to copy the legitimate software, malicious DLL, and file archive from a network share and execute it on a targeted device. This activity occurred after the actor had already obtained access to the environment and illustrates one method by which NeedyMantis can be introduced during an intrusion post-compromise.

NeedyMantis is observed during the post-compromise stage of an intrusion after an actor has established access to the target environment. While one known user of the malware, Storm-3069, has been associated with supply chain compromises, Microsoft has not observed NeedyMantis itself being distributed through a supply chain compromise. However, supply chain activity remains one possible means by which an actor could gain the access necessary to deploy the malware.

NeedyMantis architecture and capabilities First-stage loader

NeedyMantis’ first-stage loader is DLL sideloaded and launched when the legitimate software it is packaged with is run. Its only task is to extract the second-stage loader from its file archive and continue execution there.

In the analyzed sample, the loader DLL was named WinSparkle.dll (SHA-256: e842dd7642c8e04b5ec20b6393848a9c904e4832930950c16664fe7800ba382e) and its file archive was named WinSparkle (SHA-256: 9cb68f986043a576e19d32184c583b7d8f571c7219d8dc0065dced1c13f077ef). NeedyMantis spoofed and replaced the WinSparkle software update component of the Poedit translation software.

The loader employs common anti-analysis techniques to hinder analysis, like obfuscating most of its important strings.

Figure 1. Example obfuscated strings being deobfuscated

This technique is known as obfuscated stack strings because each piece of the string is built up one at a time on the function’s stack. Once built up, it is deobfuscated using various mathematical operations. Most of the obfuscated strings in this loader are Windows DLL and API names. These deobfuscated strings are used to resolve Windows APIs dynamically at runtime.

In addition to obfuscated strings, a lot of the code’s constant values are stored obfuscated as well.

Figure 2. Example obfuscated constant value “1032” being deobfuscated

Finally, the loader has two anti-debugger methods: one based on ProcessDebugFlags and the other using ThreadHideFromDebugger.

As noted above, the loader’s main objective is to extract the next stage from its file archive and launch it. In the analyzed sample, the next stage was named encryptbase64.ps1.

Custom file archives

NeedyMantis’ file archives are in an encrypted and compressed custom file format. To get access to the files, the outer layer of the archive is XOR-decoded and RtlDecompressBuffer decompressed. Once decompressed, there are individual file entries. In each file entry, the file’s name is XOR-decoded and its contents are RtlDecompressBuffer decompressed.

The file format’s offsets, XOR keys, and values change from sample to sample.

Figure 3. Example output of an archive unpacking tool displaying metadata of the WinSparkle file archive

This archive contains the following 11 files:

• 7-zip.chm – Legitimate component of 7-Zip
• 7-zip.dll – Legitimate component of 7-Zip
• 7-zip32.dll – Legitimate component of 7-Zip
• 7z.exe – Legitimate component of 7-Zip
• Disk2vhd.dll – Legitimate Sysinternals component Disk2vhd
• main.dll – Legitimate Sysinternals component Ctrl2Cap
• kernel32.dll – Legitimate kernel32.dll
• encryptbase64.ps1 – Second-stage loader
• dnsapi.dll – Not a dnsapi.dll, but contains the malware’s configuration
• ws2_32.dll – Not a ws2_32.dll, but contains a WebSockets based communications DLL
• msvcrt140.dll – Not a msvcrt140.dll, but contains shellcode to load module DLLs and resolve exports

While this archive contains several legitimate software components, the malware’s functionality is implemented by the remaining files, discussed below.

Other analyzed NeedyMantis file archives have contained different file names and components. An older version of the malware, for example, used a libcurl (SHA-256: c82520eb03c084226be4eafbff46f56dca0aa8804a2a7f23a085a96afe71ef77) file archive, and it contained only four files:

• 300.c – Malware’s configuration
• 300.s – WebSockets-based communications DLL
• is – Persistence module using Windows Services
• m.l – Main component

Second-stage loader

In the analyzed sample, encryptbase64.ps1 was the second-stage loader. Despite its .ps1 PowerShell extension, the file contains x64 shellcode. Its purpose is to decode and decompress an embedded binary which is NeedyMantis’ main component.

This loader also has some anti-analysis functionality that differs from stage one. For string decoding, it locates two encoded blocks of data and XOR keys at calculated offsets and then decodes them. The first block, most relevantly, contains a few Windows DLL and API names that are resolved dynamically. The second block, shown below, contains a list of Windows DLL names and Windows API hash values:

Figure 4. Decoded Windows API hash values

The component uses a rotate right (ROR) based algorithm with a configurable rotation value (the analyzed sample used value 11) to resolve these Windows API hashes. Figure 5 shows a snippet of Python code reproducing the algorithm:

Figure 5. Python snippet of Windows API hashing algorithm

This second-stage loader’s objective is to extract embedded data, XOR-decode it, and then RtlDecompressBuffer decompress it. The location of the encoded data and XOR key are at calculated offsets, which change from sample to sample.

Once decoded the resulting data is a DLL that has been formatted using a custom executable file format. It is a minimized version of a PE file.

Figure 6. Example output of custom executable file format to PE file conversion tool Main component

NeedyMantis’ main component orchestrates C2 communications and handles additional downloaded modules.

It creates a mutex named <username>-<process name>, such as Contoso-Poedit.exe. Like in the first-stage loader, most of the main component’s strings and constant values are stored as obfuscated stack strings.

Configuration

The malware’s configuration was stored in a dnsapi.dll file from the custom file archive. This file name spoofs a Windows networking library. In the sample analyzed, the file contains a 3448-byte binary structure. The structure includes the following fields:

• 0x00: Unknown (config contained “300”, but components also reference “400”)
• 0x1c: Communication component name (ws2_32.dll)
• 0x128: C2 port (443)
• 0x12c: C2 host (corp.tripswithengine[.]com)
• 0x334: C2 URI (/library/zip/)
• 0x53C: WinHttpOpen AccessType (0)
• 0x954: Proxy username (not set)
• 0xB5C: Proxy password (not set)
• 0xD64: Sleep time related (300)
• 0xD68: Sleep time related (300)

Communications DLL

As referenced in the configuration, NeedyMantis makes use of a communication component called ws2_32.dll. This component is also stored in the custom file archive. Like the config file, the file name spoofs a Windows networking library.

This communications DLL has one export named SystemInfo. As shown below in Figure 7, SystemInfo exposes 10 functions for the main component to initiate and maintain a WebSockets connection with the C2:

Figure 7. Communications DLL API functions

The library uses WinINet APIs for WebSockets. It also has a hard-coded user-agent of firefox/21.0.

We have also spotted a second version of the communications DLL in a file archive. It implements the same communications API but uses Libwebsockets (LWS) instead of WinINet.

Command and control

The initial C2 beacon is an HTTPS GET request, similar to Figure 8 below:

Figure 8. Initial C2 HTTPS GET request

The Set-Cookie header contains system information. The header value can be Base64-decoded and RtlDecompressBuffer decompressed. Once decompressed it contains a JSON object. The key values are:

• c – Computer name
• u – Username
• o – Base64-encoded data, once decoded it contains line separated “: ” entries
  • p – Process name
  • pa – Parent process
  • f – Files in ProgramFiles directory
  • p – Process list

The connection is then converted to WebSockets and a binary C2 protocol is continued. The binary protocol is separated into a header and optional data components. The 44-byte header includes the following fields:

• 0x00: 16-byte XOR key
• 0x10: Uncompressed data length
• 0x14: Compressed data length
• 0x18: Command number
• 0x28: Data length
• 0x2c: Optional data

A 16-byte random XOR key is generated and the header is XOR-encoded, starting at offset 0x18. If there is any data, it is compressed with RtlCompressBuffer and optionally encrypted with RC4.

The initial messages of the binary protocol are a key exchange with the C2 server. The protocol is performed as such:

• 32-bytes are received from the C2 server, but then ignored
• A 1024-byte random buffer is created
• The first 32-bytes of this random buffer are used as the RC4 key for further communications
• A 256-byte buffer is created that starts with google.com followed by random bytes
• The 256-byte buffer is RC4 encrypted
• A random length between 292 and 1282 is picked
• The C2 protocol message data is structured as such:
  • 0x00: The random length
  • 0x04: RC4 encrypted google.com buffer
  • 0x104: The random 1024-byte buffer used to create the RC4 key (at least 32 bytes of it)
• This message data is compressed, but not RC4 encrypted
• A random command number between 1 and 45 is chosen
• The C2 server uses the buffer at offset 0x104 to recreate the RC4 key and presumably checks the RC4 encrypted google.com buffer
• The server sends back the random command number as an acknowledgement

Commands

The main component only has a handful of commands. Commands sent to the C2 include:

• 1110 – Sends computer name and username
• 1112 – Sends a hard-coded identifier (like 20001)
• 1150 – Keep alive

Commands received from the C2 include:

• 1020 – Load module
• 1030 – Unload module
• 1050 / 1150 – Dispatch data to module
• 1070 – Turn off active flags

The main component’s load, unload, and data dispatch commands show that NeedyMantis can extend its functionality through additional modules, but the capabilities of those modules remain unconfirmed.

Mitigation and protection guidance

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

• Look for outbound connections in network egress traffic to corp.tripswithengine[.]com.
• Turn on cloud-delivered protection and block at first sight to rapidly identify and block new and unknown malware variants.
• Run Endpoint Detection and Response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.    
• Enable network protection in Microsoft Defender for Endpoint.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors.
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block execution of potentially obfuscated scripts

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

Microsoft Defender detections

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

Tactic Observed activity Microsoft Defender coverage ExecutionShellcode loading, DLL sideloading, decryption, and decompressionMicrosoft Defender for Endpoint
– Suspicious DLL loaded
– An executable file loaded an unexpected DLL file
– Suspicious decode command

Microsoft Defender Antivirus
– TrojanDropper:Win64/NeedyMantisExecutionHands-on-keyboard leveraging Impacket tool for follow-on activityMicrosoft Defender for Endpoint
– Ongoing hands-on-keyboard attack via Impacket toolkit
– Impacket toolkit
– Impacket module execution

Microsoft Defender Antivirus
– HackTool:Win32/ImpacketExecutionStorm-3069 threat actor TTPsMicrosoft Defender for Endpoint
– Suspicious activity linked to an emerging threat actor has been detectedCommand and controlNetwork connectivity to NeedyMantis infrastructureMicrosoft Defender Antivirus
– Behavior:Win64/NeedyMantis Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Tool profile: NeedyMantis
• Actor profile: Storm-3069
• Tool profile: Impacket

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 malware and associated activity.

Hunting queries Microsoft Defender XDR

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

NeedyMantis masquerading as software

A listing of legitimate, unmodified application folders, along with malicious replacement DLL filenames sideloaded by NeedyMantis.

DeviceFileEvents | where Timestamp > ago(7d) | where ( (FolderPath matches regex @"^[A-Za-z]:\\Program Files\\Poedit" and FileName == "WinSparkle.dll") or (FolderPath matches regex @"^[A-Za-z]:\\Program Files \(x86\)\\Poedit" and FileName == "WinSparkle.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\USOShared" and FileName == "libcurl.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\VIM" and FileName == "vim64.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\TightVNC\\VIM" and FileName == "vim64.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\office" and FileName == "dbghelp.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\broadcom" and FileName == "dbghelp.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\Intel" and FileName == "jli.dll") or (FolderPath matches regex @"^[A-Za-z]:\\Program Files\\modifiable" and FileName == "nvml.dll") or (FolderPath matches regex @"^[A-Za-z]:\\Program Files \(x86\)\\modifiable" and FileName == "nvml.dll") or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\ics" and FileName == "nvml.dll") ) | project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, FileName, SHA1, SHA256, MD5, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessAccountUpn, InitiatingProcessMD5, InitiatingProcessSHA1, InitiatingProcessSHA256, InitiatingProcessFolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessCreationTime, ReportId, TenantId

NeedyMantis C2

This query identifies connectivity to the NeedyMantis command and control site for this activity.

search in (DeviceNetworkEvents, EmailUrlInfo, UrlClickEvents, DeviceEvents, DeviceFileEvents, DeviceProcessEvents) "corp.tripswithengine.com" | where Timestamp > ago(7d) | extend SourceTable = $table | project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessAccountUpn, AccountName, AccountUpn, RemoteIP, LocalIP, IPAddress, RemoteUrl, Url, UrlDomain, FileOriginUrl, FileOriginReferrerUrl, FileOriginIP, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName, FileName, FolderPath, NetworkMessageId, SourceTable

NeedyMantis communications DLL hard-coded user-agent

Identify connectivity utilizing the NeedyMantis hard-coded user-agent.

search in (DeviceNetworkEvents, DeviceEvents, UrlClickEvents, EmailUrlInfo) "Firefox/21.0" | where Timestamp > ago(7d) | extend SourceTable = $table | project Timestamp, DeviceName = iff(isnull(DeviceName), "", DeviceName), AccountUpn = coalesce(InitiatingProcessAccountUpn, AccountUpn, ""), AccountName = coalesce(InitiatingProcessAccountName, AccountName, ""), RemoteIP = coalesce(RemoteIP, IPAddress, ""), Url = coalesce(RemoteUrl, Url, ""), UserAgent = AdditionalFields, SourceTable 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.

NeedyMantis C2

This query identifies connectivity to the NeedyMantis command and control site for this activity.

search in (CommonSecurityLog, SecurityEvent, AzureDiagnostics) "corp.tripswithengine.com" | where TimeGenerated > ago(7d) | project TimeGenerated, DeviceName, Computer, SourceIP, SourcePort, SourceUserName, DestinationIP, DestinationPort, DestinationHostName, DestinationDnsDomain, RequestURL, ProcessName, DestinationUserName, SourceHostName, Message, $table

NeedyMantis communications DLL hard-code user-agent

Identify connectivity utilizing the NeedyMantis hard-code user-agent.

CommonSecurityLog | where TimeGenerated > ago(7d) | where RequestClientApplication contains "Firefox/21.0" or Message contains "Firefox/21.0" | project TimeGenerated, DeviceName, SourceUserName, SourceIP, DestinationIP, RequestURL, RequestClientApplication Indicators of compromise IndicatorTypeDescriptionFirst seenLast seene842dd7642c8e04b5ec20b6393848a9c904e4832930950c16664fe7800ba382e SHA-256First-stage loader WinSparkle.dll 2026-05-21 2026-05-219cb68f986043a576e19d32184c583b7d8f571c7219d8dc0065dced1c13f077efSHA-256Custom file archive WinSparkle 2026-05-23 2026-05-23c82520eb03c084226be4eafbff46f56dca0aa8804a2a7f23a085a96afe71ef77SHA-256Custom file archive libcurl2025-10-032025-10-03corp.tripswithengine[.]comHost nameC2 host name References

• https://securelist.com/tr/daemon-tools-backdoor/119654/
• https://winsparkle.org/
• https://poedit.com/

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 NeedyMantis: Unpacking a post-compromise malware family used in targeted operations appeared first on Microsoft Security Blog.

In this article

1. Attack overview
2. Technical analysis
3. Mitigation and protection guidance
4. References
5. Learn More

Microsoft Security Research has identified malicious cloud activity associated with JADEPUFFER, a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation. Our investigation found an extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration.

These findings expand the publicly documented activity associated with JADEPUFFER, tracked by Microsoft as Storm-3168, demonstrating an evolution in the threat actor’s cloud operations and providing the first detailed view into its Azure activity. We identified bulk destructive operations in a compromised Azure environment. The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections. Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.

This activity highlights a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale. As these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments. Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI.

Attack overview

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The other performed discovery, destructive operations, and credential collection.

Discovery before destruction

For the impacted tenant, in early June 2026, one of the compromised service principals enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes with 300+ successful read operations. This breadth of activity would give the threat actor visibility across the organization’s Azure environment.

About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.

16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.

70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.

A seven-minute destructive sequence

Less than one second after the unsuccessful ListKey operation against a non-existent storage account, the second compromised service principal began with its destructive activities. This compromised service principal then attempted 150+ destructive or credential collection related operations in 35 minutes.

The destructive sequence lasted for about 7 minutes. This involved 100+ storage account deletion attempts. Most Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. An Azure Key Vault, Function App, App service plan were also deleted, all of which belonged to the same resource group and appeared to support the Function app.

The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type.

Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.

Credential collection

About 30 minutes after the final destructive activity, the same service principal made an inventory request for Azure Storage Accounts and sent 30+ successful ListKeys requests, asking ARM to return each storage account’s access keys. These storage accounts included Azure Site Recovery related storage accounts.

Technical analysis Possible initial access

• Credential exposure: While it is unclear how the service principal was initially compromised, its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated. We could not confirm whether this secret was used for the activity described here.
• Application Probing: Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers, against sensitive paths related to WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code) and other web-shell like paths. However, the App Service targets did not overlap with the affected Azure subscriptions, and we found no App Service to ARM (Azure Resource Manager) credential path for the impacted tenant.

Coordinated automation

The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.

We observed five unique tokens issued for the service principal used for destruction and credential collection – four tokens supported deletion, while the fifth token handled storage inventory and key retrieval. Two of the tokens used for deletion were active during the same 70 second period. While one of these tokens focused on Storage account deletion, the other focused on a mixture of Storage and SQL deletion.

While the Key Vault, Function App, and App Service plan associated with the same application were deleted, a similarly named storage account in the same resource group was spared and later targeted by the compromised service principal through a successful ListKeys operation.

The operations followed the identity’s existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions and the one additional successful key retrieval. Direct SQL DB Contributor access authorized the multiple SQL deletion attempts, which were ultimately unsuccessful because of the unsupported API version used for the Azure SQL Database resource type.

Destructive activity indicative of a ransomware-aligned objective

The threat actor deleted numerous Azure resources, while also targeting backup and recovery related resources such as Azure Site Recovery locks or Azure Storage Accounts which had terraform and backup themed names, potentially intending to impair the victim’s ability to recover from the destructive activity.

The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type. Although the database deletions were unsuccessful, their inclusion in the same destructive sequence provides additional insight into the intended scope of the activity.

The compromised service principal also made multiple attempts to retrieve storage account keys, which could provide access to sensitive data.

Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations.

However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the risk and impact of activity similar to that observed in this campaign:

• Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview.
• Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation.
• Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud.
• Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC.
• Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices.
• Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed.
• Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below.

TacticAlert nameDefender for Cloud CoverageCollection, ExfiltrationPossible data exfiltration detectedDefender for App ServicesExfiltration– An abnormally large number of rows were extracted from an SQL server
– Unusual volume of data extracted (Azure Cosmos DB)
– Access from an unusual location Defender for DatabasesPersistence, Execution, Command and ControlCommunication with suspicious domain identified by threat intelligenceDefender for DNSExfiltration– Unusual amount of data extracted from a storage blob container
– Unusual number of blobs extracted from a storage blob container
– Unusual amount of data extracted from a sensitive blob container
– Unusual amount of data extracted from a storage file share
– Unusual number of files extracted from a storage file shareDefender for StorageInitial Access– Access from a known suspicious IP address to a sensitive blob container
– Access from a suspicious IP address
– Access from a known suspicious IP address to a sensitive storage file shareDefender for Storage Defense EvasionAzure Resource Manager operation from suspicious proxy IP addressDefender for Resource ManagerCredential Access– Unusual operation pattern in a key vault
– High volume of operations in a key vault
– Unusual application accessed a key vaultDefender for Key Vaults

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across cloud 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

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

Threat intelligence reports

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

• Microsoft Defender XDR Threat Analytics report on Storm-3168

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 threat.

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

• T1190 Exploit Public-Facing Application | Storm-3168 linked infrastructure repeatedly probed sensitive application paths on applications hosted in Azure App Service for potential exploitation.
• T1078.004 Valid Accounts: Cloud Accounts | Compromised service principals were used for Azure resource discovery and destruction.
• T1526 Cloud Service Discovery | The identities enumerated subscriptions, virtual machines, resource groups, Azure Storage, Web Apps, App Service plans, locks, and Recovery Services.
• T1485 Data Destruction | Azure Storage, Key Vault, Function App, and App Service plan resources were deleted. Azure SQL deletion was also attempted, extending the destructive objective toward databases.
• T1490 Inhibit System Recovery | Site Recovery disk locks and an Azure Backup protection lock were targeted for deletion

Indicators of compromise (IOC) IndicatorTypeDescription45.131.66[.]106IPv4App Service probing and malicious ARM requests34.153.223[.]102IPv4App Service probing64.20.53[.]230IPv4App Service probing References

• JADEPUFFER: Agentic ransomware for automated database extortion by Sysdig

Learn More

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

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

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

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

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.
• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Learn how Microsoft is reimagining the SOC for the agentic era with ISOC in Microsoft Defender

The post Storm-3168: Agentic-driven cloud attacks using compromised service principals appeared first on Microsoft Security Blog.

In this article

1. Who is Storm-2570?
2. Storm-2570 attack chain: From initial foothold to impact
3. What Storm-2570 activity means for defenders
4. Mitigation and protection guidance
5. Microsoft Defender detections
6. Hunting queries

Activity associated with Storm-2570, a ransomware affiliate linked to multiple ransomware payloads, illustrates how tracking and responding to ransomware attacks by payload alone can obscure the affiliates carrying out intrusions and the recurring behaviors that defenders can use to detect and disrupt them. Microsoft Threat Intelligence has observed Storm-2570 using consistent post-compromise tools and techniques across deployments involving Qilin, DragonForce, Anubis, and BERT ransomware. Across multiple investigations, Storm-2570 has maintained largely uniform tradecraft, infrastructure overlaps, and repeated use of the same remote access and cloud exfiltration tooling despite operating across multiple ransomware ecosystems.

These findings reinforce the value of examining threat actor behavior across the attack chain rather than treating each ransomware payload as an isolated activity set. Recurring remote access, credential access, lateral movement, security tampering, and data exfiltration activity can help defenders connect related intrusions and respond before ransomware deployment, even when the final payload changes.

In this blog post, we delve into the attack techniques attributed to Storm-2570. While Storm-2570’s methodology aligns with the tactics, techniques, and procedures (TTPs) of many tracked ransomware actors, analysis of their post-compromise tactics provides essential insights into how organizations can harden and defend against ransomware threat actors, informing opportunities to disrupt attackers even if they have gained initial access to a network. At the end of this blog, we also provide a comprehensive recommendation section with detection details.

Who is Storm-2570?

Storm-2570 is a ransomware affiliate that Microsoft Threat Intelligence has tracked since April 2025. We assess that Storm-2570 has operated across multiple ransomware as a service (RaaS) ecosystems, including Qilin, DragonForce, Anubis, and BERT.

To date, Microsoft Threat Intelligence has observed Storm-2570 in multiple investigated intrusions affecting organizations in United States, Canada, United Kingdom, Spain, Netherlands, and Puerto Rico, including healthcare and public health, education, government agencies and services, financial services, energy, consumer retail, Information technology (IT), food and agriculture, consumer services, commercial facilities, non-government organization (NGO), chemicals, critical manufacturing, and transportation.

Unlike actors that consistently support a single ransomware operation, Storm-2570 appears to be a cross-ecosystem threat actor that works with multiple ransomware groups and shifts between operations as opportunities arise, giving the threat actor the flexibility to use and deploy multiple families and improve opportunities for payouts. As a result, organizations could encounter the same actor, tools, and intrusion methods despite different ransomware payloads being deployed.

Figure 1. Storm-2570’s RaaS deployment timeline Storm-2570 attack chain: From initial foothold to impact

While the method through which Storm-2570 gains initial access remains unconfirmed, observed intrusion chains indicate subsequent use of remote management tooling and hands-on-keyboard activity to progress toward credential access, lateral movement, exfiltration, and ransomware deployment.

Across incidents, Microsoft has observed the use of commodity tools in the pre-ransom attack stage even when the ransomware payload changed. These tools include:

• Remote monitoring and management (RMM) tools, including Atera, MeshAgent, ScreenConnect, Splashtop, Remotely_Agent, and NinjaRMM
• Discovery and lateral movement tools, including NetScan, Nmap, PsExec, Impacket, NetExec, and Remote Desktop Protocol (RDP) batch scripts
• Data collection and exfiltration tools, including s5cmd and Rclone

These tools enable remote administration, command execution, persistence, and tunneling or proxy access.

Figure 2. Storm-2570 attack chain Frequent use of remote management tooling across the attack chain

MeshAgent, a remote device management software, stands out as one of Storm-2570’s most frequently observed remote access and execution tools across multiple intrusions. Rather than appearing as a one-off utility, MeshAgent repeatedly shows up at key points in Storm-2570 attack chains, often after the actor has gained access and is preparing to expand control, run commands, deploy additional tooling, or move toward ransomware impact. In several cases, Storm-2570 used MeshAgent along with MeshCentral as an operational bridge between initial hands-on-keyboard activity and later-stage actions, such as account manipulation, discovery, credential access, security tampering, and ransomware deployment.

Many intrusions tracked by Microsoft have shown Storm-2570 tailoring MeshAgent deployments to the compromised environment. The actor renames MeshAgent-related binaries or services with victim-themed names, likely to make the tool appear more legitimate in the environment. For example, Storm-2570 renames the variant of the meshagent64 RMM tool to include the name of the compromised organization, such as meshagent64-[organization name].exe and uses Base64-encoding to obfuscate the commands being executed. In one such intrusion, MeshAgent was used alongside NinjaRMM before the activity progressed to ntdsutil for credential dumping, network scanning, and Qilin deployment.

Storm-2570 uses a diverse set of remote access tools rather than relying on a single capability. The threat actor rotates among commercially available RMM platforms, remote desktop components, and tunneling utilities, often deploying multiple tools during the same intrusion. For example, Storm-2570 uses Atera to install agents and execute interactive commands, while ngrok and Cloudflared.exe expose RDP services or establish persistent outbound tunnels. Storm-2570 uses AteraAgent to issue commands and to further download and install Splashtop Streamer in compromised environments. Splashtop appears to be the interactive remote control component delivered through Atera, giving the threat actor hands-on keyboard access. The actor also uses tools such as ScreenConnect for command execution and account or domain reconnaissance and installs Remotely_Agent as a persistent remote management service.

Use of tunneling utilities for persistent remote access

Storm-2570 also pairs remote access tooling with tunneling utilities such as Cloudflared.exe to create resilient outbound access paths. In one intrusion, Storm-2570 installed MeshAgent and later created a persistent Cloudflare Tunnel service on the victim host. The tunnel was configured to run automatically as a service under LocalSystem, allowing the threat actor to maintain an encrypted outbound channel from inside the network. This type of tunnel can help bypass inbound firewall restrictions and provide covert remote access for follow-on activity.

Discovery and credential access

Post-compromise, Storm-2570 routinely conducts internal network discovery using tools such as NetScan, SoftPerfect Network Scanner Portable, and Nmap, alongside native discovery commands and file-searching activity. These activities are used to identify reachable hosts and services, map internal networks and remote systems, and locate systems, network shares, and files that may facilitate data collection, credential access, or encryption operations.

For credential access and harvesting, Storm-2570 uses tools like Mimikatz, LaZagne, and pypykatz. Storm-2570 also uses ntdsutil in intrusions for NTDS.dit credential dumping, a credential theft technique against Active Directory domain credentials. The ntdsutil command usage pattern is consistent with creating an Install From Media (IFM) copy of Active Directory database material. In an intrusion context, attackers can use this to obtain NTDS.dit and related registry hives for offline extraction of password hashes and credential material.

The command uses the legitimate Windows ntdsutil.exe to activate the NTDS Active Directory instance and create a full IFM backup in C:\Windows\Temp\<XXXXXXXXX>.

Storm-2570 uses this command to dump or stage Active Directory database NTDS.dit and supporting registry hive material, then copy it off-host and potentially extract domain credential hashes offline, indicating that the actor has high-privilege access to a victim’s domain controller:

Defense evasion

After acquiring privileged credentials, Storm-2570 uses defense evasion tactics preceding ransomware deployment, including antivirus tampering and the modification of Microsoft Defender settings and Defender exclusions. In multiple observed intrusions, Storm-2570 disabled real-time monitoring, added Defender exclusions for C:\PerfLogs to weaken endpoint detections, and modified registry values under Microsoft Defender service keys to further impair protections.

These tactics are consistent across Storm-2570 ransomware intrusions involving Qilin, DragonForce, and Anubis deployment, including cases where the actor used registry changes to alter DisableAntiSpyware, DisableRealtimeMonitoring, and WinDefend service behavior.

Lateral movement and deployment preparation

Storm-2570 moves into lateral movement and deployment preparation phase typically by using a mix of legitimate administrative tooling, offensive frameworks, and remote execution utilities.

Across multiple investigated intrusions, Storm-2570 was observed leveraging PsExec, Impacket, NetExec, RDP batch scripts, and admin shares to reach additional systems, execute commands remotely, and stage tooling across the environment. The actor uses these capabilities to facilitate data exfiltration and prepare victim networks for ransomware deployment. These tools frequently appear alongside earlier discovery activity, credential access, and remote access tooling such as MeshAgent, and often precede the use of s5cmd for exfiltration or ransomware payload execution.

PsExec is one of the most consistent lateral movement and deployment tools used by Storm-2570. The actor frequently uses PsExec, sometimes with host lists such as @ip.txt, to move laterally and install renamed MeshAgent binaries across compromised environments. Storm-2570 utilizes MeshAgent during the lateral movement phase in several intrusions as a remote access tool deployed onto newly compromised systems.

The following are examples of PsExec commands with host lists @ip.txt:

Storm-2570 also uses RDP and RDP-enabling scripts as part of this phase. If RDP is not allowed in the environment, Storm-2570 needs admin privileges to modify the policy and enable it. In several intrusions, rdp.bat script appeared with PsExec, including cases where PsExec ran rdp.bat across hosts using @ip.txt.

The RDP batch script (rdp.bat) enables inbound Remote Desktop access by modifying Terminal Server settings and adding a firewall rule to allow TCP port 3389, as observed in the command below:

Additionally, the threat actor uses ngrok to expose TCP 3389 (default port for RDP), after which PsExec-related activity and security tampering appears. These examples show Storm-2570 combining RDP access, tunneling, and remote execution to sustain hands-on-keyboard control and reach additional systems.

Storm-2570’s use of Impacket and NetExec over Server Message Block (SMB) further supports their lateral movement pattern. Impacket is a collection of open-source Python classes designed for working with network protocols, and is popular with adversaries due to its ease of use and wide range of capabilities. Microsoft Defender for Endpoint has a dedicated attack surface reduction rule to defend against lateral movement techniques used by Impacket; protecting lateral movement pathways can also mitigate Impacket.

The following NetExec SMB command is used to conduct credential theft and reconnaissance against internal Windows hosts:

Data collection and exfiltration

Storm-2570 frequently performs data theft using cloud and file-transfer utilities that are capable of moving large volumes of data quickly from compromised environments to a remote attacker-owned cloud resource. Microsoft has observed Storm-2570 using s5cmd or Rclone to stage and exfiltrate data, often after the actor has already completed discovery, credential access, lateral movement, and remote access setup. Tools like Rclone provide data synchronization capabilities, moving newly created or updated files to cloud resources in real-time to enable continuous exfiltration throughout all stages of the attack without needing attacker interaction.

Most commonly, Storm-2570 relies on s5cmd, a command-line utility designed for managing Amazon S3 and compatible object storage services, for S3-based exfiltration. In multiple intrusions, the actor staged s5cmd.exe alongside a credentials file and used it to copy documents, spreadsheets, images, databases, mail-related files, archives, and other business-relevant file types to S3 buckets. Storm-2570 identifies high-value drives and network shares, stages s5cmd.exe and a credentials file, and then executes run copy (cp) operations with extension filters to transfer selected data to attacker-controlled S3 buckets. To interact with the destination S3 bucket, s5cmd requires credentials for authentication and the credentials file stores the AWS access keys for authentication to the S3 bucket.

The following is an example of s5cmd data exfiltration command lines:

Overall, Storm-2570’s exfiltration tradecraft shows a strong preference for tools that blend into legitimate administrative or cloud-transfer workflows, allowing double-extortion operations: first collecting sensitive data through cloud-transfer tooling, then deploying ransomware.

What Storm-2570 activity means for defenders

Storm-2570 illustrates common human-operated ransomware attacks and how modern ransomware affiliates increasingly operate independently of a single ransomware brand. Ransomware affiliates’ use of common tools, intrusion methods, and operational patterns remain remarkably consistent. Although Storm-2570’s techniques are not novel, recognizing the patterns used by ransomware affiliates can be important for defenders to know to improve prevention, detection, and incident response.

Mitigation and protection guidance

To defend against Storm-2570 TTPs and similar activity, Microsoft recommends the following mitigation measures:

• Follow the defending against ransomware guidance in Microsoft’s ransomware as a service blog post which details how to build credential hygiene as well as how to limit lateral movement using the principle of least privilege.
• Turn on tenant-wide tamper protection features to prevent attackers from stopping security services or using antivirus exclusions. Without tamper protection, attackers could simply turn off Microsoft Defender Antivirus without the need to acquire higher privileges.
  • Customers running Intune or Microsoft Defender for Endpoint Security Configuration can enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO.
  • In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy.
  • If there is an issue with a device during roll out of various antivirus features, the device can be placed in Troubleshooting mode to turn off Tamper Protection temporarily without impacting the wider organizational security policy.
• For approved RMM systems used in your environment, enforce security settings where possible to implement MFA. If an unapproved RMM installation is discovered in your network, reset passwords for accounts used to install the RMM services. If a System-level account was used to install the software, further investigation may be warranted.
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block execution of potentially obfuscated scripts
  • Block Webshell creation for Servers
  • Block process creations originating from PSExec and WMI commands (Some organizations might experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI.)
  • Block use of copied or impersonated system tools
  • Use advanced protection against ransomware

Microsoft Defender detections

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

Tactic Observed activity Microsoft Defender coverage ExecutionStorm-2570 delivers tools such as PsExec, Impacket, NetExec, and RDP batch scripts, to carry out post-compromise activityMicrosoft Defender Antivirus
– Behavior:Win32/PsexecRemote

Microsoft Defender for Endpoint
– Hands-on-keyboard attack involving multiple devices
– Remote access software
– Suspicious PowerShell command line
– Suspicious PowerShell download or encoded command execution
– Ransomware-linked threat actor detectedPersistenceStorm-2570 uses RMM tools for persistence, payload delivery, and lateral movementMicrosoft Defender for Endpoint
– Suspicious Atera activity
– File dropped and launched from remote locationDefense ImpairmentStorm-2570 disables Microsoft DefenderMicrosoft Defender for Endpoint
– Defender detection bypass
– Attempt to turn off Microsoft Defender Antivirus protectionCredential AccessStorm-2570 has used tools like Mimikatz, LaZagne, and pypykatz for credential access and harvesting and NTDS.dit for credential dumpingMicrosoft Defender Antivirus – HackTool:Win32/Mimikatz – HackTool:Win64/Mimikatz – HackTool:Linux/LaZagne – HackTool:Win32/LaZagne – HackTool:Win64/LaZagne Microsoft Defender for Endpoint
– Exposed credentials at risk of compromise
– Compromised account credentials
– Process memory dumpExfiltrationStorm-2570 uses Rclone and s5cmd for data theftMicrosoft Defender for Endpoint
– Potential human-operated malicious activity
– Renaming of legitimate tools for possible data exfiltration
– Possible data exfiltration
– Hidden dual-use tool launch attemptImpactStorm-2570 deploys Anubis, DragonForce, Qilin, and BERT ransomwareMicrosoft Defender Antivirus
– Ransom:Win32/Qilinloader – Behavior:Win32/Ransomware!Qilin – Ransom:Linux/Qilin – Ransom:Win32/Qilin – Ransom:Win32/DragonForce – Ransom:Win64/Anubis

Microsoft Defender for Endpoint
– Possible ransomware activity based on a known malicious extension
– Possible compromised user account delivering ransomware-related files
– Potentially compromised assets exhibiting ransomware-like behavior
– Ransomware behavior detected in the file system
– File dropped and launched from remote location Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

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

• Actor Profile: Storm-2570
• Tool Profile: Qilin ransomware
• Tool Profile: Anubis ransomware
• Tool Profile: DragonForce ransomware

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

Hunting queries Microsoft Sentinel

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

Hunt for PsExec-based remote execution and deployment

DeviceProcessEvents | where Timestamp > ago(30d) | where FileName in~ ("psexec.exe", "psexec64.exe") or ProcessCommandLine has_any ("psexec.exe", "psexec64.exe") | where ProcessCommandLine has_any ("@ip.txt", "-accepteula", "\\") | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256, DeviceId, ReportId | order by Timestamp desc

Hunt for renamed MeshAgent binaries and services

let MeshAgentTerms = dynamic(["meshagent", "meshagent64", "meshcentral"]); union isfuzzy=true ( DeviceProcessEvents | where Timestamp > ago(30d) | where FileName has_any (MeshAgentTerms) or ProcessCommandLine has_any (MeshAgentTerms) or InitiatingProcessCommandLine has_any (MeshAgentTerms) | project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256, RegistryKey="", RegistryValueName="", SourceTable="DeviceProcessEvents" ), ( DeviceFileEvents | where Timestamp > ago(30d) | where FileName has_any (MeshAgentTerms) or FolderPath has_any (MeshAgentTerms) or InitiatingProcessCommandLine has_any (MeshAgentTerms) | project Timestamp, DeviceName, ActionType, FileName, FolderPath, ProcessCommandLine="", InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256, RegistryKey="", RegistryValueName="", SourceTable="DeviceFileEvents" ), ( DeviceRegistryEvents | where Timestamp > ago(30d) | where RegistryKey has_any (MeshAgentTerms) or RegistryValueName has_any (MeshAgentTerms) or RegistryValueData has_any (MeshAgentTerms) or InitiatingProcessCommandLine has_any (MeshAgentTerms) | project Timestamp, DeviceName, ActionType, FileName="", FolderPath="", ProcessCommandLine="", InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256="", RegistryKey, RegistryValueName, SourceTable="DeviceRegistryEvents" ) | order by Timestamp desc 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 Beyond the ransomware: Tracking Storm-2570’s consistent tradecraft across deployments appeared first on Microsoft Security Blog.

AI agents are now running on employee devices, cloud platforms, and across developer workflows. Security teams need to see those agents, govern what they can reach, and contain them when something goes wrong. This month’s updates help you discover and control local AI agents, extend Zero Trust to agent traffic, and strengthen the security operations center (SOC) foundations that AI-era operations depend on.

Here’s what’s new:

Extend protection and support investigations with Microsoft Defender Bring more context into email investigation and hunting with Microsoft Security Copilot

Available for organizations using both Microsoft Defender and Microsoft Security Copilot, a new email detonation summary delivers AI-generated explanations of URL and file sandboxing results, helping SOC teams investigate faster by reducing the manual effort required to correlate detonation evidence and contextual signals.

Prevent and disrupt threats with Microsoft Defender Protect sensitive data in motion with Microsoft Purview and Microsoft Entra Stop sensitive data from reaching shadow AI over the network

Now generally available, Microsoft Purview and Microsoft Entra Global Secure Access bring data security to the network across human actions and on-behalf-of (OBO) agentic traffic. Context-aware Microsoft Purview classification and policies are enforced by Entra at the network layer. Organizations can discover sensitive files and text in real time and block them from being shared to risky destinations. For example, if an employee or OBO agent tries to upload a sensitive document to an unsanctioned AI tool, the policy can stop the transfer before the data leaves.

Prevent employees from sharing proprietary or sensitive organizational data to potentially risky locations such as consumer AI apps. Protect, investigate, and clean up enterprise data with Microsoft Purview Manage labeling at enterprise scale with less administrative overhead

Microsoft Purview auto-labeling helps organizations automatically apply data security controls to sensitive content at enterprise scale. New auto-labeling enhancements improve policy scale, admin experience, and reporting. Policies now support simulations of up to 20 million items and up to 50,000 sites through adaptive scopes. Administrators can edit a policy without re-running simulation. New audit insights and reporting show policy coverage and processing activity. Together, these enhancements help organizations scale auto-labeling across larger environments with less administrative effort.

Investigate content created in Copilot apps such as Microsoft Loop, Copilot pages through established compliance processes

Microsoft Purview eDiscovery now supports search, hold, review, and export content in user-owned SharePoint embedded containers, to help streamline eDiscovery processes for legal, regulatory, and internal investigations. Investigators can find content from AI-powered experiences, including Microsoft Loop, Copilot Pages, Copilot Notebooks, and applications, such as Outlook newsletters, mapped to a user without requesting the container URL from a SharePoint administrator. An optional HTML conversion produces a more readable version for downstream legal tools, improving the review and export experience for experts.

Archive and permanently remove inactive content to improve AI readiness

With Microsoft Purview Data Lifecycle Management, administrators can now archive inactive SharePoint content without archiving the entire site. Archived content remains subject to retention and legal hold policies, and remains discoverable for eDiscovery, while dropping out of Microsoft 365 Copilot indexing (until reactivated). Organizations can also use Priority Cleanup to permanently delete approved content, including stale Teams recordings and transcripts, so it is no longer discoverable in eDiscovery, SharePoint search, or Microsoft 365 Copilot. Together, these capabilities help organizations meet compliance regulations, including those in highly regulated industries.

Explore Microsoft Purview data compliance solutions Advanced endpoint management extends to GCC High and DoD with Microsoft Intune Bring modern endpoint management to regulated environments

Microsoft Intune Enterprise Application Management, Microsoft Cloud PKI, and Intune Remote Help are coming to Government Community Cloud with High security needs (GCC High), with Enterprise Application Management also being offered to organizations of the Department of Defense (DoD). These capabilities help government and defense organizations simplify application management, modernize certificate lifecycle management, resolve device issues faster, and reduce total cost of ownership, all while operating within their accredited cloud environment.

Learn more about Microsoft Intune endpoint protection solutions Stay in the Loop

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

And join us at Microsoft Ignite, from November 17 to 20, 2026, in San Francisco or online, to see Microsoft Security innovations in action and go hands-on with the team that built it.

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

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

The physics of cybersecurity are changing. So must the security operations center (SOC).

Cyberattackers are using agents to automate execution at unprecedented scale. What once required entire teams now requires a single operator and an agent framework.

That shift has exposed a hard truth: security cannot operate at AI speed when protection and operations are built as separate systems. Every handoff, integration, and boundary slows defenders down. Agents inherit that complexity.

For agentic security to work, the industry needs a different model. It needs a modern cyber stack with the breadth to see across the environment and the depth to investigate and act. Security operations and native protection must function as one system. This is the integrated security operations center (ISOC).

Today we are announcing ISOC in Microsoft Defender: a foundation built for agentic security that brings leading solutions for security information and event management (SIEM) and threat protection together. It gives people and agents a shared foundation to see, understand, and act across the environment, without the complexity of operating separate systems.

Get started with ISOC in Microsoft Defender const currentTheme = localStorage.getItem('blogInABoxCurrentTheme') || (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'); // Modify player theme based on localStorage value. let options = {"autoplay":false,"hideControls":null,"language":"en-us","loop":false,"partnerName":"cloud-blogs","poster":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/image\/microsoftcorp\/1306391-hayete-announce_tbmnl_en-us?wid=1280","title":"1306391-hayete-announce","sources":[{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-hayete-announce-0x1080-6439k","type":"video\/mp4","quality":"HQ"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-hayete-announce-0x720-3266k","type":"video\/mp4","quality":"HD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-hayete-announce-0x540-2160k","type":"video\/mp4","quality":"SD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-hayete-announce-0x360-958k","type":"video\/mp4","quality":"LO"}],"ccFiles":[{"url":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-json\/bloginabox\/v1\/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fsecurity%2F1306391-hayete-announce%2F1306391-hayete-announce_cc_en-us.ttml","locale":"en-us","ccType":"TTML"}],"downloadableFiles":[{"url":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-hayete-announce_transcript_en-us","locale":"en-us","mediaType":"transcript"}]}; if (currentTheme) { options.playButtonTheme = currentTheme; } document.addEventListener('DOMContentLoaded', () => { ump("ump-6ab403fc99cfc", options); }); Built for agentic security

In July 2026, we introduced the end-to-end cyber stack alongside Project Perception, with the focus of delivering the right models, a harness, and specialized agents to help defenders perceive, reason, and act at machine speed. But we are innovating at every layer of the stack, because intelligence and orchestration alone are not enough. Agents depend on the rest of the stack working as one.

They need signals and sensors that provide visibility, context that turns those signals into understanding, and actuators that translate decisions into protection. With ISOC, these layers work in unison, so agents can move beyond isolated tasks and help operate an agentic SOC.

Signals and sensors give the system awareness.

Context turns those signals into understanding.

Actuators turn insights into protective action.

ISOC brings these capabilities together as a foundation, so humans and agents can operate as one system, each contributing what they do best. Agents provide the speed and scale to execute continuously, while people set priorities, apply judgment, and define the outcomes that matter. Together, they empower defenders to keep pace with AI-powered threat actors and achieve better security outcomes.

Integrated protection loop

With ISOC enabling signals, context, and controls to work as one, it breaks the pattern of linear security workflows. The result is an integrated protection loop that continuously turns what defenders learn into stronger pre-breach protection.

Attack disruption in Microsoft Defender shows what this makes possible. Rich telemetry and controls enable the system to detect, predict, and adapt to an attacker while the attack is still unfolding. It disrupts threats in progress and anticipates where attackers may move next. It’s a protection loop that uses exposure insights to strengthen protection in near real-time with threat intelligence focusing the loop on the threats that matter most.

ISOC brings together the capabilities needed to make this loop native, eliminating the burden of assembling, tuning, and maintaining it yourself. And as protection advances, new capabilities can become part of that loop. The result is stronger protection and a different way of working, where practitioners spend less time chasing individual signals and more time applying judgment, setting priorities, and driving security outcomes.

Designed for the practitioner

For too long, practitioners have had to compensate for the boundaries in their security architecture, stitching together signals, rebuilding context, and moving between tools just to get the information and controls needed to act.

ISOC changes their starting point. The capabilities practitioners need to investigate, hunt, automate, manage incidents, understand threats, and take action are brought together and available by default. Instead of organizing their work around the boundaries between tools, teams can organize around the security outcome they are trying to achieve.

And that foundation gets more powerful as autonomy grows. The integrated protection loop can take on more of the continuous work of detecting and defending against threats, while agents help practitioners investigate, reason, and act using the same context and controls already available to them.

There’s no separate agentic layer to assemble or new operating model to stitch together. Practitioners can multiply their expertise where they already work, shifting more of their time from operating the security stack to directing the defense.

const currentTheme = localStorage.getItem('blogInABoxCurrentTheme') || (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'); // Modify player theme based on localStorage value. let options = {"autoplay":false,"hideControls":null,"language":"en-us","loop":false,"partnerName":"cloud-blogs","poster":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/image\/microsoftcorp\/1306391-rob-demo-1_tbmnl_en-us?wid=1280","title":"1306391-rob-demo-1","sources":[{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-rob-demo-1-0x1080-6439k","type":"video\/mp4","quality":"HQ"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-rob-demo-1-0x720-3266k","type":"video\/mp4","quality":"HD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-rob-demo-1-0x540-2160k","type":"video\/mp4","quality":"SD"},{"src":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-rob-demo-1-0x360-958k","type":"video\/mp4","quality":"LO"}],"ccFiles":[{"url":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-json\/bloginabox\/v1\/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fsecurity%2F1306391-rob-demo-1%2F1306391-rob-demo-1_cc_en-us.ttml","locale":"en-us","ccType":"TTML"}],"downloadableFiles":[{"url":"https:\/\/cdn-dynmedia-1.microsoft.com\/is\/content\/microsoftcorp\/1306391-rob-demo-1_transcript_en-us","locale":"en-us","mediaType":"transcript"}]}; if (currentTheme) { options.playButtonTheme = currentTheme; } document.addEventListener('DOMContentLoaded', () => { ump("ump-6ab403fc9d00d", options); }); The path forward

Security has always been a race between attackers and defenders. AI changes the speed, scale, and economics of that race. The next SOC will not be defined by how many AI features it has, but by whether people and agents can perceive, reason, and act across an environment as one system.

Integrated security operations center (ISOC) in Microsoft Defender is available in preview today. Watch a recording of the full announcement or download the whitepaper: Agentic SOC: The new operating model for continuous defense.

Prevent and disrupt threats with Microsoft Defender

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 Reimagining the SOC for the agentic era in Microsoft Defender appeared first on Microsoft Security Blog.

In this article

1. What is device code phishing?
2. EvilTokens platform and operations
3. EvilTokens phishing emails
4. Mitigation and protection guidance
5. Microsoft Defender XDR detections
6. Hunting queries

Following its emergence in February 2026, EvilTokens quickly became one of the most widely used phishing-as-a-service (PhaaS) platforms, providing cybercriminals with AI capabilities for tailoring phishing lures and analyzing compromised inboxes to identify high-value targets. This AI-powered cybercrime platform facilitated sophisticated business email compromise (BEC) campaigns that compromised more than 12,000 inboxes in over 10,000 organizations worldwide.

EvilTokens enabled threat actors to abuse the device code authentication flow, steal tokens, and compromise organizational accounts at scale using an AI-driven infrastructure and automating multiple parts of the attack chain. The toolkit offered a plethora of prebuilt phishing templates and landing pages with an AI-powered assistant to aid in structuring target-specific emails.

Stolen tokens are used for email exfiltration and persistence, often through the creation of malicious inbox rules that conceal communications. In some cases, tokens can also be used to grant new devices access to a victim’s inbox, a particularly durable method to maintain persistence. Microsoft Threat Intelligence tracks the threat actor behind the development and support of the EvilTokens phish kit as Storm-2992.

Post-compromise, EvilTokens enabled threat actors to utilize AI assistants to sift through victim mailbox activity and engineer a phishing message based on the accessible email content. EvilTokens also allowed threat actors to conduct Microsoft Graph reconnaissance to map organizational structure and permissions, enabling continued access and potential lateral movement while tokens remain valid. While token-targeting phishing is not new, it has become far more common and industrialized over the last several years as organizations adopted multifactor authentication (MFA).

To evade detection, EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Targets are lured through deceptive emails that use 44 different themes, including invoices and request for proposals (RFPs), or shared files. These emails contained malicious URLs, PDF attachments, and HTML files.

Campaigns leveraging EvilTokens have impacted organizations in various industries, including wholesale distribution, construction, financial services, real estate, higher education, and healthcare, with the highest concentrations of observed victim activity in the United States, Canada, the United Kingdom, Australia, India, and France. Working with partners, Microsoft’s Digital Crimes Unit (DCU) facilitated a coordinated disruption of infrastructure used to operate the EvilTokens service.

This blog provides a comprehensive, up-to-date analysis of the EvilTokens platform and operations. We share specific examples of the EvilTokens service panel and a detailed analysis of EvilTokens infrastructure. Defending against EvilTokens and similar adversary-in-the-middle (AiTM) phishing threats requires a layered approach that blends technical controls with user awareness. This blog also provides Microsoft Defender detection and hunting guidance, as well as resources on how to set up mail flow rules, enforce spoof protections, and configure third-party connectors to prevent spoofed phishing messages from reaching user inboxes.

What is device code phishing?

One of the primary capabilities of EvilTokens is its device code phishing flow, which abuses device code authentication, a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs, printers, Teams devices, and conferencing devices, that cannot support a standard interactive sign-in. 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 circumvent traditional MFA protections by decoupling authentication from the originating session. Threat actors also use social engineering layouts and other tricks to disguise the legitimate device code flow approval as something else required.

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. Microsoft recommends blocking device code flow wherever possible. If your organization uses Teams devices that require device code flow, scope the exception to specific Teams device resource accounts and exclude the Device Registration Service resource from your Conditional Access policy.

In April 2026, Microsoft tracked a phishing campaign aligned with EvilTokens that used automation platforms to spin up thousands of unique, short-lived polling nodes. This approach allowed the threat actors to deploy complex backend logic (Node.js) that 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.

The following sections examine how EvilTokens operated, the capabilities available through its customer panel, and infrastructure supporting phishing campaigns. We also trace the EvilTokens attack chain, from lure delivery and device code generation through defense evasion, token theft, and post-compromise activity.

EvilTokens platform and operations Distribution and affiliate support

The threat actor tracked as Storm-2992 advertised and sold EvilTokens services to cybercriminals on the actor’s Telegram channels. Cybercriminals continue to gravitate towards apps like Telegram that provide anonymity, cross-platform access, file sharing, and channels for broadcasting announcements to large groups of followers. The threat actor uses Telegram to advertise their phish kit, announce updates, coordinate with their subscribers, and provide customer support.

Figure 1. EvilTokens Telegram bot

EvilTokens phish kits are sold at $1,500 USD for initial purchase, with a monthly subscription fee of $500 for continued access to the kit and control panel. The kit provides additional products, including Antibot redirector, B2B Sender, Office 365 Capture Link, and a Simple Mail Transfer Protocol (SMTP) Sender. Each of these products has additional fees for 30 days of access.

Figure 2. EvilTokens Telegram store bot Customer panel and campaign configuration

The EvilTokens panel provides the core components needed to support phishing campaigns, including pre‑built templates, attachment files for common lure formats, domain and hosting configuration, redirect logic, and victim tracking.

After signing in, EvilTokens subscribers are presented a dashboard with various options to choose from. First, subscribers are asked to choose a deployment method (Cloudflare Workers/Bunny or PHP Hosting) and then are asked to choose from a list of deploy options, including Capture Mode, Layout & Template, Code Display Style, Page Language, CAPTCHA, AI Mode, and Captured Text. These options allow subscribers to highly customize their deployment methods.

Figure 3. EvilTokens platform welcome page

Subscribers are provided with multiple settings and additional guidance for managing captured tokens. Once tokens have been captured, EvilTokens offers its subscribers full access to the victim email account, as well as admin detection, token auto-refresh, and an auto-scan of inboxes using keyword alerts through Telegram.

Figure 4. EvilTokens platform options for managing captured tokens

The toolkit offers additional products, which are detailed under Essential Tools. Here, subscribers are given product information and are provided with a link to download or get the product as well as a video tutorial. Subscribers are even given the opportunity to receive cryptocurrency as a reward for referring the service to others.

Figure 5. EvilTokens Essential Tools page

The platform offers 44 different themes for customizing email templates and landing pages, including text and colors.

Figure 6. EvilTokens template themes EvilTokens phishing emails

EvilTokens offers subscribers personalized lures, using AI to create targeted phishing emails aligned to the target’s role, including the use of various themes to increase the likelihood of user interaction. Themes used include document signing services, Microsoft cloud services, third-party services (cloud identity, file hosting, payment/invoicing), and other miscellaneous services like voicemail and eFax.

Additionally, researchers at Huntress noted email content like construction bid proposals, business partnership agreements, employee compensation/benefits, and password expiring notices in EvilTokens emails.

EvilTokens phishing sequence

The attack chain begins when a user interacts with a malicious attachment or URL embedded within a high-pressure lure (for example, “Action Required: Password Expiration”).

Figure 7. Example of an EvilTokens phishing email

When a user clicks the malicious link or attachment, 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 with a “Copy Code” button along with a “Continue” or “Continue with Microsoft” button that, when clicked, redirects to the official microsoft.com/devicelogin portal.

Figure 8. Example of generated device code

After presenting the code to the user and opening the legitimate microsoft.com/devicelogin URL, the script enters a polling state using the checkStatus() function to monitor the 15-minute window in real time. Every three to five 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.

Figure 9. Example of Microsoft device code sign-in portal

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 sign-in 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 in the backend.

The final stage varies depending on the threat actor’s specific objectives. In some instances, within 10 minutes of the breach, threat actors 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.

EvilTokens adds the capability for threat actors to phish and take actions that they would not be capable of performing without EvilTokens tools assisting them, giving threat actors the ability to mass-phish users and perform other operations at their leisure.

Defense evasion

EvilTokens uses a multi-stage delivery pipeline designed to bypass traditional email gateways and endpoint security. Phishing pages delivered to the user vary in complexity and evasion techniques, adding a customization layer by the operator and which tools they use. Popular techniques include but are not limited to image links (images that link to URLs), multi-stage redirection schemes, and attachments containing multi-stage delivery.

Landing page evasions include fake CAPTCHA checks/verification services that require user interaction before displaying the phishing content. To further evade automated URL scanners and sandboxes, the threat actors will at times 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 abuse of Vercel (.vercel.app), Cloudflare Workers (.workers.dev), and AWS Lambda for hosting the redirect logic. By using these domains, the phishing traffic blends in with legitimate enterprise cloud traffic, evading simple domain-blocklist triggers.

Post-compromise account access

Once authentication tokens are obtained, threat actors can focus on post-compromise activity designed to maintain and expand access and extract data. This access can be used to send further emails internally to the organization and to external contacts, allowing the actor to send phishing emails for seemingly trusted contacts. In one observed incident, the attack progressed to email exfiltration and account persistence through inbox rules created using Microsoft Office. This involved filtering the compromised users and selecting targets:

• High-value target identification: Using the EvilTokens AI capability, the threat actor reviewed and filtered for high-value targets—specifically those in financial, executive, or administrative roles—within the pool of compromised users.
• Accelerated reconnaissance: After gaining access to Microsoft Graph for reconnaissance, the threat actor programmatically mapped internal organizational structures and identified 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 and sensitive information like wire transfer details, pending invoices, and executive correspondence.

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 from unfamiliar senders. Learn how to protect yourself from phishing.
• Configure anti-phishing policies. Anti-phishing policies protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques.
• Configure Safe Links 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, follow the guidance on responding to a compromised email account. 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, 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).
• Increase Advanced Phishing Threshold to 2 or 3.
• Enable Zero-hour auto purge (ZAP) in Microsoft Defender for Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
• 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.
• Create alerting of suspicious inbox-rule creation to quickly identify and triage evidence of business email compromise (BEC) and phishing campaigns. This playbook helps defenders investigate any incident related to suspicious inbox manipulation rules configured by threat actors and take recommended actions to remediate the attack and protect networks.

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

• 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 multifactor 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.
• 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 benefit of 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.
• If there are indications such as alerts that a user’s refresh token is compromised, disable the device and revoke all existing refresh tokens. Disabling the device stops PRTs from working, and revoking the refresh tokens stops any refresh tokens that were issued using the PRT from working. Follow steps from Microsoft’s token theft playbook when responding to alerts related to compromised identities.
• 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.
• Enable network protection and web protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

Microsoft Defender XDR 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.

Using Safe Links and Microsoft Entra ID Protection raises high-confidence device code phishing alerts from Defender.

Tactic Observed activity Microsoft Defender coverage Initial accessDevice code authenticationMicrosoft Defender for Identity
– Anomalous OAuth device code authentication activityCredential accessToken theft following device code authenticationMicrosoft Defender for Identity
– Anomalous token exchange following device code authentication

Microsoft Defender XDR
– User account compromise via OAuth device code phishing
– Suspicious Azure authentication through possible device code phishingPersistence Device registration following anomalous device code authenticationMicrosoft Defender for Identity
– Suspicious Entra device join or registration

Microsoft Defender XDR
– Device registration after potential device code phishingDiscovery Anomalous volume of Microsoft Graph API requests following device code flow authentication Microsoft Defender XDR
– Anomalous Microsoft Graph API activity after potential device code phishing
– Anomalous Microsoft Graph API POST activity after potential device code phishingDefense evasionMalicious inbox rule created after anomalous device code authenticationMicrosoft Defender XDR
– Suspicious inbox rule created after potential device code phishing sign-in Microsoft Security Copilot

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

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

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

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

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the 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.

• Technique profile: Device code phishing

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

Hunting queries

Microsoft Defender XDR customers can use the following queries to detect possible phishing attempts. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential EvilTokens-related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

If a query provides high value insights into possible malicious or otherwise anomalous behavior, you can create a custom detection rule based on that query and surface those insights as custom alerts. To do this, run the query in the Advanced hunting page and select Create detection rule.

Suspicious URL clicked

This query correlates Microsoft Defender for Office 365 signals and Microsoft Entra ID identity data to find the relevant endpoint event BrowerLaunchedToOpen in Microsoft Defender XDR. This event reflects relevant clicks on the malicious URL in the spear-phishing email recognized by Microsoft Defender for Office 365.

AlertInfo | where ServiceSource =~ "Microsoft Defender for Office 365" | join ( AlertEvidence | where EntityType =="Url" | project AlertId, RemoteUrl ) on AlertId | join ( AlertEvidence | where EntityType =="MailMessage" | project AlertId, NetworkMessageId ) on AlertId // Get the unique NetworkMessageId for the email containing the Url | distinct RemoteUrl, NetworkMessageId | join EmailEvents on NetworkMessageId // Get the email RecipientEmailAddress and ObjectId from the email | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId | join kind = inner IdentityInfo on $left.RecipientObjectId == $right.AccountObjectId | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId, OnPremSid // Get the Url click event on the recipient device. | join kind = inner (DeviceEvents | where ActionType == "BrowserLaunchedToOpenUrl"| where isnotempty(RemoteUrl) | project UrlDeviceClickTime = Timestamp , UrlClickedByUserSid = RemoteUrl, InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName ) on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid | distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId, OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName | sort by UrlDeviceClickTime desc

Determine successfully delivered phishing emails to Inbox/Junk folder.

This query identifies threats that were successfully delivered to Inbox/Junk folder.

EmailEvents | where isnotempty(ThreatTypes) and DeliveryLocation in~ ("Inbox/folder","Junk folder") | extend Name = tostring(split(SenderFromAddress, '@', 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, '@', 1)[0]) | extend Account_0_Name = Name | extend Account_0_UPNSuffix = UPNSuffix | extend IP_0_Address = SenderIPv4 | extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress Microsoft Sentinel

Microsoft Sentinel customers can use the following queries to detect phishing attempts. These queries can help customers remain vigilant and safeguard their organization from phishing attacks:

• Phishing link click observed in Network Traffic

References

• Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure Huntress

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 Unmasking EvilTokens: Getting to the root of device code phishing appeared first on Microsoft Security Blog.

AI has already made fundamental changes to the operating environment for cybersecurity. Cyberattackers are testing more paths, adapting their techniques, and moving across digital environments with greater speed and persistence. The weaknesses they exploit remain familiar: excessive permissions, unprotected authentication flows, unpatched systems, exposed execution paths, and gaps between controls. What has changed is how quickly these weaknesses can combine into attack paths that cross identities, endpoints, applications, networks, and AI systems. A single foothold can become a broader compromise, making it increasingly difficult for security teams to determine which risks matter most and where to act first as their organizations adopt AI.

We introduced Secure Now within Microsoft Security Exposure Management in May 2026 to help practitioners prioritize the action they need to take to be prepared for this shift. It provides actionable guidance for strengthening the foundational security needed for AI adoption, with recommendations focused on areas where autonomous attacks can create outsized exposure.

Explore actionable cyberthreat guidance on Secure Now

We continue to see evidence that AI is reshaping the threat landscape. These developments reinforce many of the foundational practices we use internally to secure Microsoft, while also expanding our understanding of where organizations need additional visibility, governance, and control. The examples in this blog illustrate how familiar weaknesses are evolving in the AI era and why continuous exposure reduction remains essential.

When AI agents test their boundaries

Recent frontier model-related agentic security disclosures offered early lessons in how autonomous agents may test the boundaries of their instructions and environments.

In an incident disclosed by OpenAI, agents moved beyond their intended isolation, exploited vulnerabilities in shared Hugging Face infrastructure, and reached production systems. In separate incidents disclosed by Anthropic, agents exploited familiar weaknesses, including SQL injection, exposed credentials, weak passwords, and a malicious PyPI package.

Our customers are asking us how they can reduce this risk by governing agent identities and tools, isolating execution, restricting outbound connectivity, monitoring behavior, and defending against increasingly autonomous external cyberthreats, so that an unexpected agent action or exposed weakness do not become a path across the enterprise.

Explore recommended controls for this attack path.

When trusted paths cross attack surfaces

Microsoft Threat Intelligence recently observed Storm-2945, a subcluster of Midnight Blizzard, manipulating DNS and HTTP traffic across hospitality networks in the CaptiveCrunch campaign. Travelers were redirected into two attack paths: device-code phishing through a legitimate Microsoft sign-in page, or fake software updates that delivered malware.

One network interaction could therefore become either cloud identity access or endpoint compromise. The malware could collect multiple categories of host intelligence, including credentials, session tokens, security configurations, and remote-access history.

Identity remains a leading attack surface, and protecting it requires securing the authentication flow as well as the credential. Security leaders can expand phishing-resistant authentication, block device-code flow where it is unnecessary, and constrain legitimate use through Conditional Access and sign-in risk policies. Endpoint protections can disrupt the parallel malware path.

Explore recommended controls for this attack path.

When cyberattackers exploit everyday operations

A third campaign began with attackers impersonating IT support through Microsoft Teams. After persuading a user to grant control through legitimate remote-support software, they used PowerShell to download a malicious Windows Installer (MSI) package, stage a portable Node.js runtime, and establish persistent command-and-control. From that endpoint, the operator mapped Active Directory and attempted to use WinRM to reach dozens of systems, including domain controllers and certificate authorities.

Each step relied on technology common in enterprise environments—a Teams conversation, remote-support software, Windows Installer, a legitimate runtime, and a native administrative protocol—enabling the cyberattacker to move laterally while blending with expected operations.

Security leaders can disrupt that path with phishing-resistant access controls, managed-device requirements, endpoint attack surface-reduction rules, and tighter restrictions on remote-support tools and WinRM.

Explore recommended controls for this attack path.

Security fundamentals work together

Cyberattackers are moving laterally across surfaces, and security fundamentals matter most at the intersections between them. Through the Secure Future Initiative, Microsoft is operationalizing security as a continuous discipline and applying and sharing lessons from strengthening our own environment. Guided by Zero Trust principles—verify explicitly, use least privilege, and assume breach—we will continue to make high-impact protections easier to adopt and enabled by default where appropriate.

Governed identities, well-defined permissions, protected data, and visibility into AI systems and agents provide resilience as organizations accelerate AI adoption. They also give AI-powered security the context and trusted mechanisms needed to help defenders prioritize risk and act faster. Strengthening these foundations reduces exposure today while preparing organizations for what comes next.

On Secure Now—within Microsoft Security Exposure Management—security leaders can now find information on recent threats paired with focused initiatives across security domains. This brings together guidance on recommended controls and enables customers to take relevant actions to continuously strengthen your posture.

Visit Secure Now to understand recent threats, identify areas of focus, and take action.

Explore the latest exposure management guidance in Secure Now Learn more

Learn more about Microsoft Security Exposure Management.

FastTrack provides eligible customers with access to technical specialists as an included benefit at no additional cost to help strengthen foundational security controls, reduce exposure to cyberthreats, and prepare for broader AI adoption. Get started now.

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 From guidance to action: Security fundamentals that materially reduce risk  appeared first on Microsoft Security Blog.

Every benchmark tells a story. The most valuable ones tell us where to improve next.

For five consecutive quarters Microsoft has published email security benchmarking reports to provide greater transparency into real-world protection outcomes. The results have shown strong Microsoft Defender performance across pre-delivery and post-delivery scenarios, while revealing where threats and defenses continue to evolve.

This quarter’s benchmark examines how continuous measurement informs protection across prevention, detection, and adaptation, and how those insights are helping improve customer outcomes.

Read the latest Microsoft benchmarking data for email security Key takeaways

• Defender again missed the fewest high-severity threats among the solutions evaluated, about 55% fewer than the next-closest secure email gateway (SEG) vendor.
• Layered security adds the most value in promotional and bulk filtering and works; gains for spam and malicious email remain comparatively modest.

Benchmarking results for SEG vendors

In the latest quarterly SEG comparison from May 2026 through July 2026, Defender missed 221 high-severity threats per 1,000 protected users, 55.4% fewer than the next-closest SEG vendor. The benchmark measures missed threats instead of the total number of malicious emails that were caught and filtered, because catch totals can reflect differences in threat volume and exposure across vendor environments. By normalizing missed threats per 1,000 users we are able to provide a more consistent side-by-side comparison.

Figure 1: High-severity email threats missed by SEG vendors (May 2026 through July 2026), measured as threats missed per 1,000 users protected. Data source: Microsoft Defender.

If you’ve read our previous blogs, you’ll see that missed threats have increased across multiple reporting periods, including for Microsoft. This aligns with broader trends we’re seeing as AI makes it easier for cyberattackers to gather public information, tailor messages, and create more convincing impersonation attempts. It reinforces the need for protection that continuously adapts.

Benchmarking results for ICES vendors

Effective email detection combines pre-delivery filtering with post-delivery detection and remediation. This benchmark helps customers evaluate where each layer contributes measurable value.

Similarly to previous quarters, integrated cloud email security (ICES) solutions continue adding the most value in promotional and bulk filtering. We saw an improvement in ICES vendor malicious catch at 0.30% versus 0.13% in the last quarter and spam catch going up to 0.52% versus 0.28% compared to last quarter.

Figure 2: ICES vendor catch contribution (May 2026 through July 2026). Data source: Microsoft Defender.

Defender caught 92% of post-delivery malicious messages on average during the benchmark period, highlighting how the combination of pre-delivery and post-delivery remediation delivers strong results for customers.

At the same time it’s key to understand that Defender doesn’t treat post-delivery remediation as a point-in-time action after the email was first delivered to the inbox. Even after a message reaches the inbox, new threat intelligence can reveal risks that were not apparent at the time of delivery. Defender continuously reevaluates delivered messages and remediates threats as new indicators, campaign intelligence, and threat signals emerge.

Figure 3: Post‑delivery malicious catch by Microsoft Defender (May 2026 through July 2026), shown across vendors and overall average. Data source: Microsoft Defender. How our benchmarking is helping shape product innovation

The value of benchmarking is what happens after measurement. Insights from customer feedback, threat telemetry, and benchmarking have informed recent Microsoft Defender investments:

• More control over promotional mail: Across multiple benchmarking periods, we observed that ICES solutions often delivered the greatest incremental benefit in filtering promotional and bulk email. The new Promotions folder in Outlook builds on these insights by helping users reduce inbox clutter while keeping legitimate marketing and bulk messages accessible.
• Redesigned machine learning and AI model stack: By analyzing and incorporating natural language processing signals, including message topic, alongside other AI detection signals, Defender can improve detection accuracy. During a consecutive four-week period, Microsoft research observed a roughly two-thirds reduction in false negatives and a nearly one-fifth reduction in false positives for Defender customers.
• Protection for people and AI: We built prompt injection protection to detect and isolate malicious AI instructions in email before delivery—helping protect not only people, but also Copilot, agents, and other AI systems that read and act on inbox content. This innovation demonstrates how we continue evolving our defenses to address the latest cyberattack techniques and stay ahead of emerging threats.

Looking ahead

Since July 2025, our goal has been to bring greater transparency to email security effectiveness. Today, we are using benchmarking to help customers understand how cyberthreats evolve, where defenses add value, and how protection improves over time.

Benchmarking is not simply about demonstrating effectiveness, it is about learning from real-world outcomes and translating those insights into stronger protection. As cyberattackers continue to innovate, we remain committed to sharing evidence, improving our technology, and helping customers stay ahead of emerging cyberthreats.

To explore the latest benchmarking data and learn more about how Defender and ICES partners work together, access the benchmarking site.

Read the latest Microsoft Defender benchmarking results Learn more

Learn more about Microsoft Defender.

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

The post Improving email security outcomes with real-world Microsoft Defender insights appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
   1. Email Delivery
   2. Domain registration
   3. Generative AI usage
2. Mitigation and protection guidance
   1. Microsoft Defender detections
   2. Microsoft Security Copilot
   3. Threat intelligence reports
   4. MITRE ATT&CK Techniques observed
   5. Indicators of compromise (IOC)
3. Learn More

Threat actors are increasingly improving their tactics to make suspicious emails look like legitimate email notifications to potential victims, deploying techniques that impersonate internally sent emails from executive team members. While this technique is not new, the adoption of AI has enabled threat actors to improve their campaign templates and construct emails tailored to their recipients. Additionally, threat actors are incorporating multiple techniques within the same email to improve the overall narrative further.

In this blog, we will discuss a recent campaign observed using third-party email delivery infrastructure to send out over a million financial fraud scam emails that displayed multiple indicators consistent with the use of generative AI during email template creation. The threat actor impersonated CEOs of multiple target companies, attempting to convince accounts payable departments of the same companies to process an Automated Clearing House (ACH) payment of nearly $50,000. To add legitimacy, the actor included a forwarded email thread (and a fabricated invoice) between the impersonated CEO and ServiceNow (which was also being impersonated).

Attack chain overview

The campaign follows steps before and during the execution of the campaign: threat actors register impersonation domains, send executive-themed payment requests through trusted infrastructure, embed fabricated invoices and supporting conversations, and attempt to convince finance personnel to initiate ACH transfers.

Figure 1: Attack chain showing domain registration, executive impersonation, invoice fraud delivery, ACH payment execution, and financial theft. Email Delivery

Between August 3 and 5, Microsoft detected a campaign consisting of more than a million emails targeting enterprise users. The attacker used multiple third-party email service accounts to send out the emails. A huge majority of these emails were sent to users in the United States (87.7% of the total campaign).

Figure 2. Campaign timeline. Figure 3. Industry distribution of targeted enterprises of this campaign with ‘IT services & business advisory’ along with ‘Consumer goods’ and others.

Unlike traditional invoice scams that rely on a single social engineering lure, this campaign layered executive impersonation, vendor branding, fabricated invoices, and supporting email conversations into a unified narrative intended to reduce recipient skepticism.

The threat actor impersonated executive team members (such as a CEO, CFO, President) of multiple targeted companies, attempting to convince accounts payable departments of the same companies to process an ACH payment of nearly $50,000. More specifically, the CEOs were impersonated in multiple places in the email such as in the sender display name, reply-to display name, and in the email signature. Email bodies contained a simple and direct “approval” of the “invoice below” as well as urged users to request a PDF version if they need it. Additionally, as mentioned earlier, the email signature contained certain details about the spoofed CEO such as name and email address.

Figure 4. Spoofed message from executive team member.

Important note: Throughout this campaign, threat actors impersonated legitimate organizations using attacker-controlled infrastructure, fabricated communications, and lookalike domains. Microsoft found no evidence that the legitimate organizations referenced in the lures, including ServiceNow, were compromised or involved in the activity. Rather, the campaign relied on fraudulent domains and content designed to mimic trusted brands and individuals.

The threat actor did not stop there. To add further legitimacy, directly below the CEO signature, the actor included “forwarded” content , specifically a professional looking but fabricated “ServiceNow Platform — Annual Subscription” invoice. The extremely detailed invoice contains various ServiceNow branding and logos. It has basic invoice details such as invoice number, issue and due dates, currency, amount due, payment method, and itemized line items. The payment method instructed is a bank transfer to accounts controlled by the threat actor. Microsoft observed the use of multiple financial institutions across samples, indicating that payment destinations may vary between targets. Certain parts of the invoice are personalized to the recipient. Specifically, the “BILLED TO” section has the recipient company name and executive name.

The invoice shown below is a threat actor-created impersonation and was not issued by ServiceNow.

Figure 5. Spoofed ServiceNow invoice.

Finally, directly below the fake invoice, two more “forwarded” emails are included which are essentially a short conversation between the two spoofed executives (the targeted company executive, and ServiceNow President). The two executives are seen discussing the ServiceNow purchase, implementation and handling of the invoice.

Figure 6. “Forwarded” replies thread within the email lacking usual headers.

From a defender point of view there are several indicators within the email indicating that the email and the “forwarded” thread are not genuine.

• “From” headers from the spoofed thread lack any data headers like actual forwarded emails.

• Suspicious language used in the spoofed thread such as “no need to copy me”.
• Suspicious language in headers i.e display name not matching sender address, subjects using financial lure keywords like ‘due bill’, ‘ACH Parment’ etc.
• Despite the sophistication of the generated content, several inconsistencies remained visible to defenders
• In real email threads, the previous threads are normally tabbed or otherwise visually grouped, while the previous threads in this example were left aligned.
• An additional inconsistency was observed where the targeted company’s CEO requested the recipient to send the invoice directly to victims and not CC the sender. However, in the most recent thread, the CEO stated that the invoice is approved and the invoice is sent from his address.

Domain registration

Before initiating the campaign, the threat actor registered several domains. A ‘ServiceNow’ lookalike domain service-nowinc[.]com was registered on July 31, shortly before the campaign activity was observed. This domain was used for the spoofed email address of ServiceNow President. It was also used in several places in the fabricated invoice such as in the contact email in case of any questions. The actor also registered another domain on the same day. The domain domainlify[.]net was used in the Reply-To email.

Figure 7. Account information linked with email of impersonated domain. Generative AI usage

Microsoft observed several indicators consistent with AI-assisted template development. These included extensive HTML comments, structured section labeling, and highly uniform template construction. While these indicators suggest generative AI involvement, they do not independently establish the extent to which AI generated campaign content.

Examples:

Figure 8. Code snippet showing a verbose HTML comment describing a section (a characteristic commonly observed in AI-generated code). Figure 9. Another code snippet showing extensive comments on HTML style elements and sections.

Additionally, the use of ‘em dash’ (“—”) and banner ‘===========’ have also become other indicators associated with AI usage.

Figure 10. Another code example indicating AI usage. This example shows a verbose capitalized section header and yet more style elements excessively commented.

One possible indication of template-based generation is that invoice identifiers and narrative structure remained largely consistent across samples while organization-specific details changed between targets.

Mitigation and protection guidance

Microsoft provides layered protection against this type of executive-impersonation and invoice-fraud campaign. Properly configured email authentication, spoof protection, mail-flow connectors, and Microsoft Defender for Office 365 help identify and block suspicious messages before delivery; messages later determined to be malicious can be quarantined or removed through post-delivery remediation, including Zero-hour Auto Purge. Security teams can then use Microsoft Defender XDR and Security Copilot to investigate related alerts, affected users, and campaign indicators, coordinate response, and take remediation actions.

Together, these capabilities help reduce the likelihood that fraudulent payment requests reach finance personnel and support faster containment if a message is delivered.

To defend against social engineering campaigns involving executive impersonation, invoice fraud, and potentially AI-assisted content development, Microsoft recommends the following mitigations:

Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully.

Enable Zero-hour auto purge (ZAP) in Office 365 to quarantine sent mail in response to newly acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.

Invest in advanced anti-phishing solutions that monitor and scan incoming emails and visited websites. For example, organizations can leverage web browsers like Microsoft Edge that automatically identify and block malicious websites, including those used in this phishing campaign, and solutions that detect and block malicious emails, links, and files.

These links provide information on how to properly configure mail flow with connectors:

• Manage mail flow using a third-party cloud service with Exchange Online
• Configure mail flow using connectors in Exchange Online
• Mail flow rules (transport rules) in Exchange Online
• Enhanced filtering for connectors in Exchange Online

These links provide information on configuring SPF, DKIM, and DMARC:

• Email authentication in cloud organizations
• Set up SPF to identify valid email sources for your custom cloud domains
• Set up DKIM to sign mail from your cloud domain

Microsoft Defender detections

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

Tactic Observed activity Microsoft Defender coverage Financial TheftScam emailsMicrosoft Defender for Office 365
– Invoice scams delivered detected as Spam and malicious categories.
– Email messages marked malicious removed after delivery and spam moved to quarantine
– Email messages removed after delivery
– Messages retroactively removed through Zero-hour Auto Purge (ZAP). 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 Defender XDR customers can use Threat Analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the malicious activity and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

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.

Reconnaissance

T1591 – Gather Victim Organization Information
Threat actors collect publicly available information about target organizations, executives, finance personnel, vendors, and business relationships to build convincing invoice-fraud narratives.

T1598 – Phishing for Information
Information gathered from victims and public sources is used to craft highly targeted business email compromise (BEC) lures.

Resource Development

T1583.001 – Acquire Infrastructure: Domains
Threat actors register domains that impersonate trusted organizations, vendors, or business partners.

T1585.002 – Establish Accounts: Email Accounts
Attacker-controlled email accounts are created to support impersonation and fraudulent communications.

T1583 – Acquire Infrastructure
Third-party email delivery infrastructure and supporting services are leveraged to distribute campaigns.

Initial Access

T1566 – Phishing
Targeted phishing emails are delivered to finance personnel using executive and vendor impersonation themes.

T1566.001 – Spearphishing Attachment
Fraudulent invoices or supporting documents are attached to phishing emails.

T1566.003 – Spearphishing via Service
Third-party email services are used to distribute phishing messages and improve legitimacy.

Defense evasion

T1036 – Masquerading
Attackers disguise emails, domains, invoices, and business correspondence as legitimate communications.

T1656 – Impersonation
Executives, vendors, and trusted business entities are impersonated to establish credibility and influence payment decisions.

Impact

T1657 – Financial Theft
Victims are deceived into transferring funds to attacker-controlled financial accounts through fraudulent invoice payment requests.

Indicators of compromise (IOC) IndicatorTypeDescriptionservice-nowinc[.]com Domain Domain impersonating ServiceNow gomez@service-nowinc[.]comEmail address Email address associated with bank account notifications@uinsure[.]co[.]uk info@tivityhealth[.]com no-reply@lumalisboa[.]com noreply@mctci[.]com info@nuf[.]co[.]jp info@lohnsteuerhilfe-aktuell-verein[.]de info@tovimbatista[.]pt contact@eemusicclass[.]co[.]uk info@lifeones[.]comEmail addressSender email address used to send out emailsdomainlify[.]netDomainNewly registered domain used in Reply-to address Learn More

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

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

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

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

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

• How Microsoft discovers and mitigates evolving attacks against AI guardrails | Microsoft Security Blog
• Manipulating AI memory for profit: The rise of AI Recommendation Poisoning | Microsoft Security Blog – a related example of an AI-era technique observed in email traffic
• Defending the inbox against prompt injection attacks | Microsoft Defender for Office 365 Blog – feature announcement introducing prompt injection protection in Microsoft Defender for Office 365.
• Prompt injection protection in Microsoft Defender for Office 365 – official documentation of the prompt injection protection in Microsoft Defender for Office 365.

The post Protecting organizations from AI-assisted executive impersonation and invoice fraud appeared first on Microsoft Security Blog.

Every wave of technology excitement creates a new opportunity for cyberattackers, and AI is no exception. Microsoft Threat Intelligence has published research showing a growing set of campaigns that impersonate popular AI platforms and tools, including ChatGPT, Microsoft Copilot, DeepSeek, and Claude.1 The goal is to make phishing, search-driven malware campaigns, and malvertising—which is malicious advertising that uses online ads to lure users to harmful sites, downloads, or redirect chains—more convincing. A ChatGPT-themed phishing campaign sent up to 100,000 emails in a single day, tricking users into updating their ChatGPT Plus payment information and stealing personal and credit card data. These campaigns do not represent a compromise of the AI services being referenced. They represent something more familiar—cyberattackers doing what they have always done: borrowing trust. Right now, AI brands can carry significant trust and curiosity, making them attractive themes for cyberattackers to exploit.

Prevent and disrupt cyberthreats with Microsoft Defender

Understanding why this trend matters and what it means for security teams is critical to shaping a modern protection strategy. The tactics are the same ones cyberattackers have always refined: urgency, curiosity, and impersonation of something familiar to lower a user’s guard. What has changed is the wrapper. A message about a new model release, a policy update from a familiar AI assistant, or a plugin that promises to make the workday easier is today’s version of the fake invoice or the shipping notification. AI-themed lures deserve attention not because they are a passing trend tied to one product cycle, but because AI remains a genuine source of excitement and urgency for employees and consumers alike, and cyberattackers are exploiting the human instinct to explore what is new, useful, or urgent.

The attack pattern is evolving

Microsoft’s research team recently observed several AI brand campaigns including:

• A ChatGPT-themed phishing kit built to harvest credit card data.
• A Claude-themed campaign that harvested credentials and access tokens through adversary-in-the-middle (AiTM) techniques.
• Malvertising for a fake AI Windows plugin that delivered the Vidar stealer.
• Fraudulent DeepSeek installers distributed through GitHub.

In one case, an initial access broker tracked as Storm-3075 used AI-themed malvertising to distribute payloads for multiple downstream actors, a sign of how quickly this tactic is being commoditized across the criminal ecosystem.

Figure 1. Snippet of the top portion of the email impersonating ChatGPT and enticing users to click on the link.

What ties these campaigns together is not sophistication in the traditional sense. It is patience and precision in exploiting a moment. Threat actors are capitalizing on anticipated launches and emerging trends, layering multi-stage redirection chains and disposable infrastructure to slip past both users and defenses. That has real implications for security leaders: it means these incidents cannot be evaluated one surface at a time. A single AI-themed lure can begin as an email, become a malicious link, trigger a suspicious download, and end as an identity or endpoint compromise. Organizations that assess each of those as an isolated event are always a step behind. Organizations that connect them see the full shape of the cyberattack, often early enough to stop it.

Turning AI lures into dead ends with Microsoft Defender

In practice, protection starts before the user ever engages with the lure. Microsoft Defender’s anti-phishing policies can help detect spoofing and impersonation attempts, including user and domain impersonation, first-contact messages, mailbox intelligence signals, and other suspicious sender characteristics. For an AI-themed lure, that might look like a fake “Copilot policy update,” a spoofed support notice, or a lookalike domain designed to make a credential collection page feel legitimate.

If the campaign relies on links, Defender’s Safe Links provides URL scanning and detonation during mail flow, plus time-of-click verification when a user selects a link in email, Microsoft Teams, or supported Microsoft 365 apps. That is important when cyberattackers use redirect chains, delayed activation, or links that appear benign at delivery but later resolve to phishing infrastructure, fake sign-in pages, or malicious downloads.

For campaigns that use fake installers, malicious downloads, or weaponized attachments, Safe Attachments adds another layer by detonating attachments in a virtual environment before delivery when policies are configured. For example, if a message promotes a “new AI plugin” but includes a harmful attachment, Safe Attachments can analyze the file for malware, ransomware, or phishing behavior before it reaches the user. If a cyberthreat is identified after delivery, Defender’s post-delivery filtering capabilities help remove malicious content from mailboxes and reduce the window of exposure.

Figure 2. Simplified Defender email detection stack with pre-delivery and post-delivery protections. Protect against multi-stage attacks with attack disruption

But AI-powered attacks don’t stop at email. Their objective is to gain the highest level of access possible, using compromised accounts as a foothold to move across identities, devices, and data. When a cyberattack moves beyond the inbox, Defender helps connect the evidence. Signals from email and collaboration tools, endpoints, identities, and software as a service (SaaS) apps are correlated into an attack story so analysts can see whether the same lure led to a clicked link, a downloaded payload, risky sign-in behavior, or endpoint activity.

As cyberattackers expand beyond email to gain broader access across the environment, Defender moves from detection to disruption. For multi-stage, multi-domain attacks like business email compromise or AiTM, Defender’s powerful, built-in response capability, attack disruption, will contain the compromised asset during the attack to prevent further lateral movement while security teams investigate and remediate. Attack disruption contains more than 81,000 compromised user accounts monthly and is now disrupting more than 45,000 AiTM attacks each month.

Figure 3. Recent attack disruption statistics. (Source: Internal Microsoft Research, September 2026)

In a recent case study, Defender disrupted a business email compromise attack within four minutes of the initial activity (Figure 4). While response times may vary by scenario, this case shows the impact of attack disruption on a real cyberthreat. The cyberattacker used a convincing document-sharing lure to trick a user to start a legitimate Microsoft device code sign-in flow, which avoided traditional credential theft techniques. Defender recognized the resulting device code authentication and follow-on activity as suspicious, correlated signals across identity and email telemetry, and disrupted the attack within four minutes before the attacker could establish persistence, create inbox rules, or execute payroll fraud.

Figure 4. Business email compromise attack through OAuth device code phishing. The takeaway

AI brands are the new bait, but the underlying lesson is bigger than any single campaign. As cyberattackers continue to exploit the momentum around AI, organizations should expect social engineering to become more targeted, more believable, and more difficult to evaluate in isolation.

The answer is not to treat every new lure as a brand-new category of risk. It is to build a protection model that makes trust harder to exploit across the full attack chain. Microsoft Defender helps organizations do that by connecting prevention, detection, investigation, and response across the attack path, so AI-themed lures are harder to deliver, harder to trust, and harder to turn into broader compromise.

Learn more about Microsoft Defender

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.

1AI brands as bait: How threat actors are using the AI hype in social engineering, Microsoft Threat Intelligence. June 8, 2026.

The post Detect and disrupt AI-themed attacks with Microsoft Defender appeared first on Microsoft Security Blog.

In this article

1. Overview
2. Technique Catalog
3. Privilege Escalation
4. Mitigation and protection guidance
5. References
6. Learn more

Microsoft introduces the cloud web applications threat matrix, a MITRE ATT&CK-aligned framework that helps defenders understand, prioritize, and mitigate threats to cloud-hosted web apps and serverless platforms.

Cloud-hosted web applications and serverless platforms create attack paths that can cross application code, managed runtimes, workload identities, deployment pipelines, and connected cloud resources. Investigating the application and underlying cloud platform separately can leave gaps in how defenders understand those paths.

Microsoft developed the Cloud web applications threat matrix to organize relevant techniques using MITRE ATT&CK tactics. The matrix can help security teams assess visibility gaps, prioritize hardening, and plan investigations across cloud-native environments. This blog introduces the framework, examines selected techniques, and outlines defensive priorities for reducing exposure.

Overview

Cloud-hosted web applications and serverless platforms let teams deploy and scale application logic quickly, but they also create attack paths that cross application code, managed runtimes, identities, deployment pipelines, and connected cloud services. These paths can be difficult to detect when the application layer and underlying cloud platform are investigated separately.

To provide a clear and consistent view of the threat landscape affecting cloud hosted web applications and serverless environments, we organize techniques using the MITRE ATT&CK format. Building on Microsoft’s previously published threat matrices for Kubernetes and storage services, this matrix expands coverage for cloud web applications– applications that execute code in a managed environment, are often tightly integrated with other cloud resources, and are commonly exposed to the internet.

The attack techniques presented in this matrix are divided into the following tactics, aligned with the MITRE ATT&CK framework:

• Resource Development

• Initial Access

• Execution

• Persistence

• Privilege Escalation

• Defense Evasion

• Credential Access

• Discovery

• Lateral Movement

• Collection

• Impact

Figure 1. Cloud web applications threat matrix organized by MITRE ATT&CK tactics. Technique Catalog

Below, we walk through each tactic and describe its techniques in more detail.

Resource Development

The resource development tactic consists of techniques that adversaries use to establish resources they can use to support operations. This may include acquiring infrastructure, developing capabilities, or compromising resources that can later be used during targeting.

Subdomain takeover

Deleting a cloud application or service without removing its associated DNS record pointed to a reusable provider endpoint can create a subdomain takeover risk. Depending on the provider’s behavior, service configuration, and naming constraints, a threat actor may be able to register a resource that claims the same address and intercept traffic intended for the original service, potentially serving malicious content or harvesting credentials.

Initial Access

The initial access tactic consists of techniques that are used for gaining access to cloud web applications and serverless environments. This access can be achieved through compromised credentials, vulnerable applications, misconfigured interfaces, or by exploiting connected resources.

Application vulnerability

Running a public-facing web application that hosts a vulnerable application can enable adversaries to access and execute code in the context of the web application, or to access internal resources and gain a foothold in the cloud environment. Such vulnerabilities could stem from the application’s own code, its underlying framework, or third-party libraries and dependencies it uses.

Code injection in connected repository

Threat actors may inject malicious code into source repositories that are linked to cloud web applications or serverless functions. If these repositories are automatically synced with production environments, the injected code executes under the legitimate workflows.

For example, if a threat actor gains commit permissions to a GitHub repository that is configured to deploy GCP Cloud Functions through Cloud Build triggers, their code may be deployed into the application through the legitimate pipeline.

Compromised image in registry

Some cloud web applications are deployed from a container image pulled from private or public registries. Threat actors who get access to a private registry can plant their own compromised images or update an existing image with malicious code, which will run the next time the web application pulls the container image.

Exposed/misconfigured admin interfaces

Some cloud-based web applications expose administrative interfaces for managing deployments, configurations, or runtime operations. If these interfaces are exposed to the internet or misconfigured, threat actors might be able to access them and view critical data, execute commands, or manipulate application behavior.

For example, if an Azure App Service exposes its Kudu interface to the internet, a threat actor with sufficient credentials could execute commands in the app’s environment.

Serverless trigger injection

In cases where the application executes backend workflows in response to event-driven triggers, an end user who can directly or indirectly influence those triggers may cause unintended activity within the application. By manipulating inputs such as crafted file uploads, queue messages, API calls, or other event sources, a threat actor can force serverless functions to run with their supplied data, which could lead to unintended code execution, data access, or further compromise.

For example, a threat actor might upload a modified image file containing a crafted payload through a legitimate web form. The image is then stored in an S3 bucket, which triggers an AWS Lambda function configured to process new uploads. If the function handles the file without proper validation, the threat actors payload could cause unintended behavior or even lead to remote code execution.

Using deployment credentials

In some cloud web applications, deployment credentials can grant management access beyond publishing new code. Adversaries who obtain such credentials might be able to use them to directly interact with the application without modifying its source code.

Azure App Service, compromised deployment credentials can allow access to deployment and SCM (Source code management) interfaces, which may enable file access, command execution, or application modification depending on the app configuration and credential scope.

Execution

The execution tactic consists of techniques that are used by threat actors to run their code inside cloud web applications and serverless environments.

Application exploit (remote code execution)

Deployed web applications that contain a remote code execution vulnerability, or a vulnerability that could eventually lead to code execution, can enable threat actors to run malicious code in the web application context. If the application has access to any additional resources, then the threat actor could access those as well.

Cloud native terminal

Some cloud platforms provide built-in administrative consoles or SSH-style terminals for running commands directly inside the application’s execution environment. Threat actors who gain access to the terminal may be able to extract data, edit the web app files and execute commands.

For example, Azure App Services expose a Kudu console that acts as a built-in terminal; if threat actors obtain deployment credentials, they can use it to browse files, execute commands, and tamper with application code.

Site extensions

Site extensions are an Azure App Services feature that allows users to install additional tools and utilities onto their web application. These extensions run within the context of the App Service and have the same permissions as the application itself – including requests data, file system access and environment variables. Site extensions are installed from a NuGet-based feed that allows third-party package submissions. If threat actors publish a malicious extension that resembles a legitimate package, or compromise an existing package, users who mistakes the package for a trusted extension may install it, allowing the threat actors code to run in the application context.

Persistence

The persistence tactic consists of techniques that are used by threat actors to maintain access to cloud web applications in case their initial foothold is lost.

Cron jobs

In cases where a cloud application uses scheduled or trigger-based tasks, a threat actor with the ability to create or modify such jobs can cause their malicious code to execute automatically. Because these jobs can run independently of normal request flows and often inherit the application’s privileges, control over a scheduled or event-triggered job allows persistent execution even if the main application code is updated.

For example, if a threat actor is able to create or modify a WebJob in Azure App Service, their code will periodically run on the web application, regardless of changes or updates to the application code itself.

Source code modification

A threat actor with access to a development environment may be able to modify the application’s source – which could reside in a git repository, a container image in a registry, or a deployment package in cloud storage. Because cloud web applications are typically deployed through automated pipelines, a single modification can propagate automatically into production, causing the threat actors code to run every time the application restarts. These changes become part of the application’s canonical source, meaning that even if the runtime environment is rebuilt or scaled, the tainted code is redeployed from the same trusted source, maintaining the threat actor access to the application.

Valid cloud accounts

Adversaries may gain access to cloud web applications and serverless environments by leveraging compromised valid cloud accounts. Using legitimate credentials allows threat actors to interact with such services without raising suspicion. This enables them to deploy or modify application code, configure triggers, and maintain control over workloads.

For example, a threat actor who compromises an Entra ID user with sufficient owner-level permissions on a subscription may be able to read or modify function app resources within that scope, subject to resource and policy controls.

Privilege Escalation

The privilege escalation tactic consists of techniques that are used by threat actors to get higher privileges in the environment than those they currently have. This can include accessing workload identity credentials or leveraging application permissions to access additional cloud resources.

Access cloud resources

Web apps deployed in the cloud often run with identities or service accounts that have permissions over additional cloud resources in the environment such as storage, databases and AI services. Additionally, some applications store connection strings or keys to cloud resources in the app configuration files or environment variables. Therefore, if threat actors compromise the application, they can often extract or leverage these credentials to access additional cloud resources.

Access workload identity credentials

Workload identities are identities that are managed by the cloud provider and can be allocated to cloud resources. The identity’s secret is fully managed by the cloud provider, which eliminates the need to manage the credentials. Web apps can use workload identities to perform actions on other cloud resources by querying Instance Metadata Service (IMDS) or similar endpoints. Threat actors who gain access to a web app can leverage their access to the IMDS endpoint to get the workload identity’s token. With a token, the threat actors can access cloud resources.

For example, in Azure App Services, the managed identity access token can be acquired through a local identity endpoint, which is defined in the environment variables (IDENTITY_ENDPOINT). If a threat actor is able to execute code on such an App Service instance, they would be able to query the endpoint and receive an access token to other Azure resources with the managed identity permissions.

Defense Evasion

The defense evasion tactic consists of techniques that are used by threat actors to avoid detection and hide their activity.

Development slots

Many cloud platforms and serverless environments support staging or preview environments (such as deployment slots in Azure App Services, aliases in AWS Lambda, or revision tags in GCP Cloud Run), which allow developers to test and stage new versions of their applications before swapping them into production. These environments can be swapped or promoted with minimal downtime. If a threat actor gains the ability to modify or promote a non-production environment, they may execute malicious code or gain insights into the application’s structure and behavior. In some cases, these staged environments are directly accessible without a swap, meaning a threat actor could execute code in a staging slot or alternate version and potentially evade detection, since the primary production deployment remains untouched.

For example, in Azure App Service, a threat actor who obtains permissions to manage a staging deployment slot could either swap it into production, thus pushing malicious code live, or exploit the slot’s separate URL to run the malicious app without modifying the production’s code.

Disable cloud logging

Threat actors with appropriate permissions may disable or alter cloud logging to hide their actions and avoid detection. This can include turning off diagnostic logging on a web application, deleting or modifying existing log data, changing log retention policies to accelerate log expiration, or redirecting log output. By suppressing logging, the threat actor reduces the visibility that defenders have into ongoing malicious activity, making it harder to detect the compromise, perform incident response, or reconstruct the attack timeline.

Credential Access

The credential access tactic consists of techniques that are used by threat actors to steal credentials. In cloud web application environments, this includes credentials of the running application, workload identities, secrets stored in configuration, or cloud credentials.

Brute force

Some web applications or interfaces may still use basic authentication, either for user access, administrative functions, or deployment interfaces. A threat actor could try to gain access by repeatedly attempting credential combinations, and upon finding valid credentials, use them to access and use the relevant privileges.

For example, Azure App Service exposes the Kudu management console (the SCM site) and FTP endpoints that support basic authentication. This includes user‑scoped deployment credentials, which are manually set by the user and shared across all App Services within a subscription that the user has access to. If a threat actor is able to successfully guess those credentials, they could gain deployment access to multiple applications in the subscription.

Cloud credentials in runtime environment

Some web applications store secrets such as keys, tokens, and connection strings in environment variables or configuration files. In cloud environments, those secrets are often used to access additional cloud services within the environment. If a threat actor gains access, even read-only, to the running application environment, they would be able to retrieve those credentials and use them to authenticate against those external cloud resources.

For example, an Azure Function configured to authenticate to Azure OpenAI with a resource key may store that key and the service endpoint in application settings exposed as environment variables. a threat actor who accesses those variables could use the key to make authorized data-plane API requests to the associated Azure OpenAI resource.

Discovery

The discovery tactic consists of techniques that are used by threat actors to explore the environment to which they gained access. This exploration helps the threat actors to perform lateral movement and gain access to additional resources.

Access to connected cloud storage

Cloud applications often use external storage services for hosting source code, configuration files or assets. Threat actors may exploit misconfigured or compromised read access to this storage to review the code and configuration to find vulnerabilities or sensitive information that could be exploited to take over the application.

For example, in GCP Cloud Run functions, the function code is saved into a bucket in the project. If a threat actor compromised a user with storage read access, they would be able to view the source code.

Cloud service discovery

Cloud‑hosted applications often contain configuration values or runtime information that reference other cloud services the application interacts with, such as service URLs, API endpoints, database connection strings, or resource identifiers. After gaining access to a web application, threat actors can discover additional cloud resources through environment variables, network connections or application code.

Instance metadata API

Cloud platforms expose metadata services that provide information about the running environment, such as instance details, network configuration, and identity credentials. In some cases, this service is available from within cloud web applications as well. Threat actors who gain access to such an application may query the metadata API service to get information about the underlying VM and the application environment.

Lateral Movement

The lateral movement tactic consists of techniques that are used by threat actors to move through the victim’s environment. In cloud web application environments, this includes gaining access to connected cloud resources, third-party services, or internal network resources.

Connector reuse

Cloud applications may use managed connectors or integration resources to interact with third-party services such as email providers, SaaS platforms, databases, or messaging systems. These connectors sometimes store authentication or authorization details – such as OAuth tokens and access keys, that are separate from the web application’s own identity and thus could be reused across multiple applications. A threat actor who compromises a user or identity with permissions over the connector resource can invoke those stored credentials to access the connected third-party services, enabling lateral movement beyond the cloud environment.

For example, in Azure Logic Apps, API connections are standalone resources that store authenticated sessions to external services, such as Office 365, Slack, or SQL databases. A threat actor with sufficient permissions on the resource group can create a new app that uses existing API connectors, triggering actions on the connected services using the stored credentials without needing to extract the underlying secrets.

Collection

The collection tactic consists of techniques that are used by threat actors to collect data from cloud web applications or connected resources.

Access application database

Many applications rely on a connected database to store application data, user information, configuration values, or state. The application often connects to the database by using the application’s cloud identity, or by using a hardcoded connection string. If a threat actor gains code execution abilities, they can interact with the database – query and extract data or modify entries. In cases where the database is accessible from the internet, threat actors may only need read permissions over the web app to access the database.

Event data capture

Cloud applications often generate logs that include diagnostic data, request metadata, or user input. Due to misconfigured logging levels or insufficient filtering, these logs may inadvertently contain sensitive information such as credentials, personally identifiable information (PII), or details about the application environment, including internal paths, dependency versions, and cloud resource names. This information could assist adversaries in furthering their attacks. Logs may be stored locally, streamed to external services, or accessed through debugging interfaces. Logs may be stored locally, streamed to external services, or accessed via debugging interfaces. If a threat actor gains access to the application or its logging infrastructure, they can collect this data to aid further exploitation or reconnaissance.

For example, AWS Lambda functions automatically send all standard output to CloudWatch Logs. If verbose or debug-level logging is misconfigured and left enabled in production, sensitive data may end up in the log group. A threat actor who gains read access to CloudWatch can then harvest this information.

Impact

The impact tactic consists of techniques that are used by threat actors to destroy, abuse, or disrupt the normal behavior of cloud web applications and their environments.

Data destruction

Threat actors who gain sufficient privileges within a cloud web application may delete or corrupt data stored in the app or in connected cloud resources such as databases and storage.

Data theft

If threat actors gain access to the application, its storage, or connected cloud resources, they may be able to retrieve data stored or processed by the application. This includes application content, user information, configuration files, or proprietary content.

Defacement

Adversaries may attempt to alter the web application’s content or appearance to damage reputation, intimidate victims or spread propaganda. This could be done through access to the application itself, to the source code or any assets it uses.

Denial of wallet

Cloud applications often scale dynamically based on demand, incurring costs for compute, storage, and data transfer. Threat actors may intentionally trigger operations that will cause those resources to scale out to impose financial damage. One such approach is to flood a web application with requests, similar to traditional denial-of-service (DoS) attacks. This will cause the application to allocate more resources, thus causing increased charges.

For example, a threat actor could repeatedly invoke a Cloud Function with high memory allocation, leading to inflated billing due to excessive execution time.

Resource hijacking

Threat actors may leverage the compute, network, or storage resources of the application for unauthorized purposes, such as cryptocurrency mining, mass scanning, or traffic proxying.

Mitigation and protection guidance

As organizations adopt cloud-native and serverless architectures, defending against these threats requires visibility across both application behavior and underlying cloud resources. The cloud web applications threat matrix is intended to support this by mapping techniques to attack stages, helping defenders identify where visibility exists and where gaps remain.

Mitigation strategies for individual techniques are detailed within the matrix. Across the matrix, recurring priorities include requiring multifactor authentication, applying least-privilege permissions to users and workloads, and restricting access to applications, deployment environments, and connected resources.

Organizations should also protect source repositories, build systems, and deployment pipelines from unauthorized changes, and install packages and extensions only from trusted sources. Reusable credentials should not be stored in source code or configuration files. Workload identities and secrets management solutions should be used where supported, while network access to sensitive services should be limited to authorized networks.

To support investigation, organizations should centralize security-relevant logs in protected locations and prevent unauthorized changes to logging configurations. Resource quotas, concurrency limits, cost guardrails, and spending alerts can help reduce the impact of resource hijacking and denial-of-wallet activity. Organizations should also maintain and test backup and recovery plans to prepare for destructive operations.

Microsoft Defender for Cloud and Microsoft Defender XDR can support investigation and response across many related signals, including cloud resource posture, workload activity, identity activity, and cross-domain incidents, depending on customer configuration and available telemetry.

References

• Threat Matrix for Cloud Web Applications

• MITRE ATT&CK®

• Threat Matrix for Kubernetes

• Threat Matrix for Storage Services

Learn more

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

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

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

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

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

The post Threat Matrix: Mapping threats across cloud web applications appeared first on Microsoft Security Blog.

In this article

1. Attack chain overview
2. Attribution
3. Mitigation and protection guidance
4. Learn more

Microsoft Security Research is tracking active cloud-based intrusions spanning multiple accounts in which unusual sign-ins were followed by threat actor-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through REST APIs. Microsoft Security Research assesses that this sequence is consistent with automated collection from compromised cloud identities using proxy-associated infrastructure, the activity has been observed since May 2026.

The activity begins with identity-focused social engineering and impersonation infrastructure, proceeds through authentication persistence and cloud reconnaissance, and is followed by targeted data access and activity consistent with data collection and potential exfiltration. Domains, IP addresses, and hosting providers can change quickly, but the recurring sequence of identity compromise, persistence, reconnaissance, content discovery, and exfiltration provides a more durable basis for investigation. Defenders should investigate this sequence across identity, Microsoft Graph, SharePoint, OneDrive, and Exchange signals, then revoke sessions and remove unauthorized authentication methods for confirmed compromises.

Attack chain overview Figure 1. Observed attack sequence showing identity compromise through social engineering, MFA persistence, Microsoft Graph reconnaissance, and cloud data collection/exfiltration. Step 1-2 : Initial access: Passkey and SSO lures

The attack often begins with a seemingly routine call or message on a user’s personal phone number from someone claiming to be from the organization’s IT helpdesk. The caller creates a sense of urgency, explaining that a passkey, multifactor authentication (MFA), or single sign-on (SSO) configuration must be updated immediately to avoid disruption. Employees are directed to a website that closely resembles a legitimate Microsoft sign-in experience and may receive the link through SMS messages sent directly to their personal mobile phones.

Despite the frequent use of passkey-themed lures, passkey enrollment is often not the actor’s true objective. Instead, the passkey narrative serves as a convincing pretext to guide victims through adversary-in-the-middle (AiTM) phishing or device-code authentication flows. In AiTM scenarios, the actor captures credentials and session tokens; in device code attacks, the victim unknowingly authorizes access on the actor’s behalf. This initial interaction may leave very little forensic evidence. If the victim opens the phishing link on a personal mobile device that is not onboarded to Microsoft Defender for Endpoint, the related activity may be absent from endpoint telemetry.

In many investigations, the employee’s recollection of a phone call or text message becomes the earliest and sometimes the only evidence explaining how the compromise began. As a result, investigators must often reconstruct the attack by connecting these reports with subsequent sign-ins, device code authentication events, token activity, and authentication method changes.

Reconnaissance on targeted organization

The actor appears to invest heavily in pre-attack research, likely gathering information about employees and organizational structure from public sources such as social networking and professional profiling platforms.

Reusable domains, personalized targeting

In a smaller number of cases, actors take advantage of already compromised accounts to expand their reach. Using a trusted employee identity, they send similar passkey-themed messages through Microsoft Teams, making the request appear legitimate and significantly increasing the likelihood of engagement. To support these operations, the actors rapidly deploy convincing phishing infrastructure built around themes such as passkeys, SSO enrollment, account activation, and identity verification.

A commonly observed technique involves registering generic domains and embedding the target organization’s name as a subdomain, creating URLs that appear familiar at first glance. Multiple domains may be created for the same organization, allowing the actor to rotate infrastructure as needed. These domains are often registered with Nicenic registrar (observed in previous extortion campaigns) and operational within hours, giving defenders little opportunity to identify and block the infrastructure before employees encounter it. Registration alone should not be interpreted as evidence of registrar involvement in the activity. For example, company-name.integratedsso[.]com and company-name.secure-passkey[.]com illustrate how the same company name can appear under different actor-controlled domains.

Together, the phone-based social engineering, personalized targeting, trusted internal messaging, and rapidly changing phishing infrastructure form the opening chapter of a highly coordinated intrusion designed to blend technical deception with human trust.

The actor creates domains following the pattern companyname[.]maliciousdomain[.]com to impersonate organization-specific authentication portals. Including the victim organization’s name in the URL helps establish credibility and can persuade users to proceed with authentication. Example: contoso[.]add-passkey[.]com.

ThemeDomain examples, defangedPasskeypasskeyhelpdesk[.]com, secure-passkey[.]com†, setupmypasskey[.]com†, add-passkey[.]com†SSO and identity providerintegratedsso[.]com†, oktasession[.]comKey setup and synchronizationkeysyncos[.]com, oskeysync[.]com, oskeysetup[.]com, oskeyregister[.]com, syncmykey[.]com, myconnectkey[.]com, oskeyconnect[.]comSetup and verificationvalidationsetupac[.]com, portalsetuphub[.]com Step 3-4 : User identity compromise From one sign-in to broader application access

In one investigated attack sequence, the activity began with an anomalous sign-in to Microsoft OfficeHome application from an unmanaged device, possibly attacker-owned. Once MFA was completed, the actor began accessing identity portals such as My Sign-Ins and enterprise application stores such as My Apps. Sign-in artifacts, including user-agent patterns, indicated possible AiTM phishing.

Using the same session, the actor further accessed several management applications, including Microsoft Approval Management, which is used for identity and approval-related services. SharePoint Online and OneDrive were used to enumerate sensitive files, primarily through the Graph API. The investigation revealed that the actor’s sessions persisted for approximately one hour while enumerating sensitive files and internal applications.

Passkey lure leads to device code phishing

In another investigated attack sequence, the actor was observed using the device code flow to compromise the session token after the passkey lure. In device code phishing, the user is persuaded to enter a code on the legitimate Microsoft authentication page. This approval issues a token to an attacker-controlled client, which can then access permitted resources without stealing a browser cookie. Following the device code flow, the actor successfully replayed the compromised token, effectively bypassing MFA and conducting enumeration and further attack progression.

Reusing the same credentials after an earlier compromise

The third attack pattern involved the actor signing in with compromised credentials, with MFA approved using a previously registered PhoneAppOTP method. This suggests that the attacker had registered the authenticator app days before launching the campaign. Once the sign in was successful, the actor followed the same reconnaissance pattern observed in other attack sequences. This activity was primarily carried out using an automated system developed with Node.js and Microsoft Graph.

To illustrate how the activity unfolded over time, the following timeline summarizes the key events identified during the investigation.

Time, UTCApplication or resourceWhat happened and why it mattersT+0minOfficeHomeSign-in from an unmanaged context received error 50074, requiring secondary authentication / Multifactor authentication (MFA).T+1minOfficeHomeMFA completed (AiTM with non-phishing resistant MFA) followed by error 50140 for the keep-me-signed-in interruption.T+1minOfficeHomeAuthentication succeeded, establishing the session used for subsequent access.T+2minMy AppsThe session enumerated applications assigned to the compromised identity.T+2minMy ProfileOrganizational profile information was accessed.T+3minMicrosoft Approval ManagementIdentity and approval-related services were accessed. This could expose approval workflows available to the identity.T+3minMicrosoft Account Controls V2Account and authentication management interfaces were accessed.T+4minMy SignInsSign-in and security information was accessed through Microsoft Graph using the same source context, session, Chrome user agent, and browser ID as the OfficeHome authentication.T+10minOCaaSThe organizational application catalogue was loaded through My Apps. In this sequence, OCaaS supports application discovery rather than appearing as an isolated background event.T+11 – T+50minSharePoint OnlineThe session requested access to organizational sites and document resources. The sign-in events do not prove that a document was opened or downloaded.T+11 – T+50minOutlook WebMailbox-related services were accessed, creating an opportunity for mailbox and business-context reconnaissance.T+12minWindows App – WebThe session entered the Azure Virtual Desktop authentication flow. A desktop or remote workspace launch was not confirmed.T+14minInternal virtual application and desktop portalAuthentication succeeded to the internal virtual application and desktop portal. This could expose published applications and virtual desktops assigned to the identity, although no internal virtual application and desktop portal resource launch was confirmed.T+15minOwaDownloadAttachmentsOutlook successfully requested the attachment download resource. This is more consequential than generic mailbox access, but the sign-in telemetry does not prove that an attachment was downloaded.T+16minM365ChatClientMicrosoft 365 collaboration, Teams, and search services were accessed.T+16minInternal business workflow applicationAuthentication succeeded to another internal business workflow application. Step 5 : New MFA device for persistence

Following initial access, the actor’s first objective was to transform a temporary compromise into a persistent foothold. Rather than relying solely on stolen credentials, the actor enrolled an MFA method under their control, typically by registering a new phone number, authenticator application, or software-based one-time password (OTP) token. This effectively inserted an actor-controlled factor into the victim’s identity, allowing future authentication challenges to be satisfied without the user’s involvement.

By registering an actor-controlled MFA method, the threat actor ensured that future authentication challenges could be satisfied using a factor they controlled. While MFA enrollment alone does not survive a complete credential and session reset, it provides a durable persistence mechanism when combined with stolen tokens, unrevoked sessions, or subsequent access to valid credentials. As a result, actors frequently establish MFA persistence early in the intrusion to increase the likelihood of maintaining long-term access to the compromised identity.

Phone or authenticator device addition

Detects a newly registered MFA device with a populated device token. The query compares the previous and updated authentication method values and returns newly added device records.

CloudAppEvents | where ActionType == "Update user." | where tostring(RawEventData.ResultStatus) == "Success" | where RawEventData has_any ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails") | extend AccountObjectId = extract(@"User_([a-f0-9\-]+)", 1, tostring(RawEventData.Target)) | where isnotempty(AccountObjectId) | mvexpand ModifiedProp = RawEventData.ModifiedProperties | where tostring(ModifiedProp.Name) in ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails") | extend OldValue = tostring(ModifiedProp.OldValue), NewValue = tostring(ModifiedProp.NewValue) | extend OldDeviceCount = countof(OldValue, @"""Id"""), NewDeviceCount = countof(NewValue, @"""Id""") | where NewDeviceCount > OldDeviceCount Software token addition

Below is a real-world example of attacker controlled Software token added to the user’s identity with Update user operation. This is added as a second NewValue entry containing the device name NO_DEVICE, device token NO_DEVICE_TOKEN, and the SoftwareTokenActivated device tag.

{ [EF1.1][KR1.2] "Id": "[GUID_REDACTED]", "CreationTime": "2026-09-04T16:57:42.0000000Z", "OrganizationId": "[GUID_REDACTED]", "Operation": "Update user.", "RecordType": 8, "Workload": "AzureActiveDirectory", "ResultStatus": "Success", "UserKey": "Not Available", "UserId": "ServicePrincipal_[GUID_REDACTED]", "Version": 1, "UserType": 4, "ObjectId": "[EMAIL_REDACTED]", "ModifiedProperties": [ { "Name": "StrongAuthenticationPhoneAppDetail", "OldValue": [ { "DeviceName": "[DEVICE_NAME_REDACTED]", "DeviceToken": "[DEVICE_TOKEN_REDACTED]", "DeviceTag": "iOS", "PhoneAppVersion": "6.8.53", "OathTokenTimeDrift": 0, "DeviceId": "[GUID_REDACTED]", "Id": "[GUID_REDACTED]", "TimeInterval": 0, "AuthenticationType": 3, "NotificationType": 2, "LastAuthenticatedTimestamp": "2026-09-04T16:54:47.6425033Z", "AuthenticatorFlavor": "Authenticator", "HashFunction": null, "TenantDeviceId": null, "SecuredPartitionId": 20111, "SecuredKeyId": 7 } ], "NewValue": [ { "DeviceName": "[DEVICE_NAME_REDACTED]", "DeviceToken": "[DEVICE_TOKEN_REDACTED]", "DeviceTag": "iOS", "PhoneAppVersion": "6.8.53", "OathTokenTimeDrift": 0, "DeviceId": "[GUID_REDACTED]", "Id": "[GUID_REDACTED]", "TimeInterval": 0, "AuthenticationType": 3, "NotificationType": 2, "LastAuthenticatedTimestamp": "2026-09-04T16:54:47.6425033Z", "AuthenticatorFlavor": "Authenticator", "HashFunction": null, "TenantDeviceId": null, "SecuredPartitionId": 20111, "SecuredKeyId": 7 }, { "DeviceName": "NO_DEVICE", "DeviceToken": "NO_DEVICE_TOKEN", "DeviceTag": "SoftwareTokenActivated", "PhoneAppVersion": "NO_PHONE_APP_VERSION", "OathTokenTimeDrift": 0, "DeviceId": "[GUID_REDACTED]", "Id": "[GUID_REDACTED]", "TimeInterval": 0, "AuthenticationType": 2, "NotificationType": 1, "LastAuthenticatedTimestamp": "2026-09-04T16:57:42.4514487Z", "AuthenticatorFlavor": "Authenticator", "HashFunction": "hmacsha1", "TenantDeviceId": null, "SecuredPartitionId": 20111, "SecuredKeyId": 7 } ] }, { "Name": "Included Updated Properties", "OldValue": "", "NewValue": "StrongAuthenticationPhoneAppDetail" }, { "Name": "TargetId.UserType", "OldValue": "", "NewValue": "Member" } ] } Step 6 : Graph reconnaissance

Once MFA persistence was established, the actor initiated an extensive internal reconnaissance phase using Microsoft Graph to inventory users, groups, permissions, resources, and accessible content across the tenant with the compromised identity. The actor deliberately rotated infrastructure throughout the attack lifecycle, with separate IP addresses often used for authentication, reconnaissance, and exfiltration activities. As a result, piecing together the full intrusion required correlating activity across multiple stages rather than relying on individual network indicators.

The attack underscores a critical detection challenge: Microsoft Graph abuse rarely appears suspicious when viewed through a single API call. Requests to endpoints such as /users, /groups, or /sites are commonplace in enterprise environments. However, when the same identity, application, or access token systematically traverses multiple tenant resources, evaluates privilege and authentication settings, and subsequently accesses mail, files, attachments, or document content, those actions collectively form a clear reconnaissance-to-exfiltration chain. This attack serves as a strong example of why Graph activity must be assessed holistically, with emphasis on behavioral progression and cross-event correlation rather than individual API requests in isolation.

Graph reconnaissance pattern matrix initiated by the actor Recon patternGraph URI examplesWhat it revealsWhy it mattersTenant profile/organization, /subscribedSkus, /licenseDetailsIdentifies the tenant, verified domains, licenses, and enabled services.Useful setup activity; stronger when followed by user, role, or repository discovery.Directory enumeration/users, /groups, /members, /transitiveMembersBuilds a map of identities, groups, and effective membership.Can identify targets, privileged users, and sensitive collaboration groups.Privilege and MFA discovery/directoryRoles, /roleManagement, /authentication/methodsInspects privileged assignments and registered authentication methods.High-value reconnaissance around identity control and persistence.Application and consent discovery/applications, /servicePrincipals, /oauth2PermissionGrants, /appRoleAssignmentsMaps enterprise applications, OAuth grants, and delegated or app-only access.Can expose reusable access paths and high-value service identities.SharePoint and OneDrive discovery/sites, /lists, /drives, /drive/items, /root/children, /searchLocates sites, document libraries, folders, and files.Often converts broad tenant reconnaissance into a collection-ready file map.Mailbox discovery/messages, /mailFolders, /attachmentsEnumerates messages, folders, and attachment metadata.Supports intelligence collection, business email compromise (BEC), and targeted attachment retrieval.Automation and pagination$top, $skip, $skiptoken, $count, /delta, /searchWalks large result sets or repeatedly searches repositories.Raises confidence when combined with broad discovery or sensitive endpoints.Content collection/content, message or attachment retrieval, large ResponseSizeRetrieves the underlying data after discovery.Strongest indicator that reconnaissance has progressed into collection. Hunt for broad Graph reconnaissance in one session

Find identities or applications touching several reconnaissance categories from the same IP within 30 minutes.

let Lookback = 24h; [MI25.1][IM25.2] GraphAPIAuditEvents | where Timestamp > ago(Lookback) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId), Path = tostring(split(tolower(RequestUri), "?")[0]) | extend ReconType = case( Uri has "/organization" or Uri has "/subscribedskus", "Tenant", Uri has "/users" or Uri has "/groups", "Directory", Uri has "/directoryroles" or Uri has "/rolemanagement", "Privilege", Uri has "/applications" or Uri has "/serviceprincipals" or Uri has "/oauth2permissiongrants", "Application", Uri has "/sites" or Uri has "/drive", "Repository", Uri has "/messages" or Uri has "/mailfolders", "Mailbox", "Other") | where ReconType != "Other" and isnotempty(ActorId) | summarize Requests=count(), Categories=dcount(ReconType), DistinctPaths=dcount(Path), ReconTypes=make_set(ReconType, 10), SampleUris=make_set(RequestUri, 10) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) | where Requests >= 10 and Categories >= 3 and DistinctPaths >= 6 | order by Categories desc, Requests desc Hunt for privilege, MFA, application, and consent discovery

Highlight sensitive control-plane reconnaissance that can expose persistence or escalation opportunities.

GraphAPIAuditEvents | where Timestamp > ago(24h) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId) | where Uri has_any ("/directoryroles", "/rolemanagement", "/authentication/methods", "/applications", "/serviceprincipals", "/oauth2permissiongrants", "/approleassign") | summarize Requests=count(), DistinctPaths=dcount(tostring(split(Uri, "?")[0])), ScopesSeen=make_set(Scopes, 10), SampleUris=make_set(RequestUri, 12) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) | where Requests >= 4 and DistinctPaths >= 2 | order by Requests desc Hunt for SharePoint and OneDrive repository discovery

Detect search, child traversal, delta queries, and paging used to map file repositories.

GraphAPIAuditEvents | where Timestamp > ago(24h) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId), Path = tostring(split(tolower(RequestUri), "?")[0]) | where Uri has_any ("/sites", "/drives", "/drive/") | where Uri has_any ("/search", "/children", "/delta", "$skiptoken", "%24skiptoken", "$top", "%24top") | summarize Requests=count(), DistinctPaths=dcount(Path), SampleUris=make_set(RequestUri, 12) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 20m) | where Requests >= 8 and DistinctPaths >= 4 | order by Requests desc Hunt for mailbox and attachment reconnaissance

Find concentrated enumeration of messages, mail folders, and attachments.

GraphAPIAuditEvents | where Timestamp > ago(24h) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId), Path = tostring(split(tolower(RequestUri), "?")[0]) | where Uri has_any ("/messages", "/mailfolders", "/attachments") | summarize Requests=count(), DistinctPaths=dcount(Path), MessageRequests=countif(Uri has "/messages"), AttachmentRequests=countif(Uri has "/attachments"), TotalResponseBytes=sum(coalesce(ResponseSize, 0)), SampleUris=make_set(RequestUri, 12) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) | where (Requests >= 8 and DistinctPaths >= 4) or AttachmentRequests >= 3 | order by AttachmentRequests desc, Requests desc Step 7-8 : High-volume cloud data collection and suspected exfiltration

Following reconnaissance, the actor transitioned into large-scale data collection across Microsoft 365 workloads using the compromised identities. Microsoft observed high-volume access and download activity targeting Microsoft SharePoint Online and Microsoft OneDrive for Business, with some intrusions extending into Microsoft Exchange Online through REST API-based access to email content. Across SharePoint and OneDrive, the activity generated significant volumes of FileAccessed and FileDownloaded events, indicating systematic retrieval of cloud-hosted documents and organizational data.

The activity frequently exhibited characteristics of automation rather than interactive user behavior. In several cases, Microsoft observed the python-httpx user agent associated with high-volume SharePoint and OneDrive access patterns. However, the user agent alone should not be treated as malicious. Instead, such activity should be evaluated in the broader context of data volume, affected identities, source infrastructure, prior reconnaissance activity, and evidence of identity compromise.

Unlike rapid smash-and-grab operations, data exfiltration was typically measured and sustained, often spanning several hours to multiple days depending on the volume of files and email content available to the compromised user. The actors generally maintained a controlled pace of collection, with fewer than 1,000 files or emails accessed within any one-hour period, likely helping the activity blend with normal enterprise usage while enabling the gradual extraction of large amounts of sensitive data over time.

Hunt for exfiltration through Exchange Online

Exfiltration of data through REST API using Microsoft Office or One Outlook Web

CloudAppEvents | where isempty(AccountObjectId) | where ApplicationId == '20893' | where AccountDisplayName in ("One Outlook Web", "9199bf20-a13f-4107-85dc-02114787ef48", "d3590ed6-52b3-4102-aeff-aad2292ab01c") | where isnotempty(IPAddress) | extend AccountObjectId = tostring(RawEventData.TokenObjectId) | summarize ExchangeRestEventCount=count() by IPAddress, AccountObjectId, bin(Timestamp,1h) | where ExchangeRestEventCount >= 500 Hunt for exfiltration through Microsoft SharePoint Online, OneDrive for Business

Exfiltration of data through python-httpx user agent

CloudAppEvents | where ApplicationId == "20892" or ApplicationId == "15600" | where ActionType in ("FileDownloaded", "FileAccessed", "SyncDownloadedFull") | where isnotempty(AccountObjectId) | where isnotempty(IPAddress) | where isnotempty(UserAgent) | where UncommonForUser has_any("ISP","UserAgent") | where UserAgent has 'python-httpx' | project Timestamp, AccountObjectId, IPAddress, ISP, UserAgent | summarize FilesAccessedLastWindow = count() by AccountObjectId, IPAddress, ISP, UserAgent, bin(Timestamp,2h) | where FilesAccessedLastWindow >=100 Hunt for anomalous high-volume exfiltration

Exfiltration of data through anonymous proxy

CloudAppEvents | where ApplicationId in (20892, 20893, 15600) | where ActionType in~ ("FileDownloaded", "FileAccessed", "FilePreviewed") | where IsAnonymousProxy == true | where UserAgent !has "ODMTADemand" | extend FileSizeBytes = coalesce(tolong(RawEventData.FileSizeBytes), 0) | summarize FileSizeBytes = sum(FileSizeBytes), FirstSeen = min(Timestamp), LastSeen = max(Timestamp), EventCount = count(), ActionTypes = make_set(ActionType), Applications = make_set(Application) by AccountObjectId, IPAddress, TimeBucket = bin(Timestamp, 2h), UserAgent, ISP | extend FileSizeGB = round(FileSizeBytes / 1024.0 / 1024.0 / 1024.0, 2) | where FileSizeGB >= 5 or EventCount >= 1000 | order by EventCount desc Attribution

Microsoft Threat Intelligence assesses that the initial access activity observed in this campaign is used by a range of threat actors, including Storm-3121, Storm-3032, and others. Storm-3121 conducts initial access activity leading to ShinyHunters and Falcon extortion. Storm-3032 represents a set of actors that splintered from the BlackFile group and now operate under the Helix extortion banner. That being said, Microsoft Defender has detection coverage for the known tactics, techniques and procedures from Storm-3121, Storm-3032 and other operators in the same ecosystem.

Mitigation and protection guidance

Microsoft recommends that organizations investigate identity and cloud-workload signals as a connected sequence, with priority given to unusual sign-ins followed bys authentication method enrollment, Microsoft Graph reconnaissance, token issuance, and abnormal SaaS download or mailbox activity.

Investigate

• Review newly registered authentication methods and devices for users with risky or unusual sign-ins and remove unauthorized methods after validating the user.
• Investigate high-volume or programmatic Microsoft Graph activity involving directory enumeration, role discovery, service principal discovery, SharePoint, OneDrive, or sensitivity-label discovery.
• Correlate SharePoint and OneDrive download anomalies, Exchange REST activity, and mailbox or attachment searches with identity and authentication events.

Contain and remediate

• Revoke active sessions and refresh tokens for confirmed compromised identities, reset credentials, remove attacker-registered authentication methods, remove attacker created mailbox rules, and require secure re-registration of authentication methods.

Reduce future risk

• Do not treat an IP or domain match as conclusive on its own. Validate workload behavior, affected identities, persistence events, and data access volume.
• Enforce phishing-resistant MFA (FIDO2/passkeys, Windows Hello for Business) via Conditional Access
• Enforce Conditional Access that requires a managed, compliant device for Exchange, SharePoint, and Graph-privileged apps
• Enforce strict conditional access controls for security info registration, including setting required sign-in frequency to always (require a new interactive auth), requiring managed devices and/or named locations, and requiring phish-resistant MFA as a required authentication strength, and in a separate policy blocking security info registration with a high sign-in risk condition
• Enforce risk-based access policies for risky sign-ins and risky users – remediate elevated risk with phishing-resistant MFA or secure password change, and block access at the highest risk levels.
• Train users against voice and email phishing that targets MFA and passkey enrollment. Provide a verified channel to report unsolicited authentication requests.
• Block the device code and authentication transfer flows via Conditional Access, except where an explicit business need exists.
• Restrict user consent for applications, require admin approval, and regularly review service principals holding high-privilege Graph permissions such as Mail.Read, Files.Read.All, and Directory.Read.All.
• Limit access from unmanaged devices to web-only sessions without download or sync, and disable anonymous sharing links in SharePoint and OneDrive.
• Enable Microsoft Graph activity logs and mailbox auditing, and alert on anomalous enumeration, authentication-method registration, and high-volume file or mail access.
• Educational training: Verify user identity through a rigorous process before performing any helpdesk-initiated credential or MFA reset, and alert on every such reset.

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.

Tactic Observed activity Microsoft XDR Defender coverage Credential AccessUnusual cloud activity from a tracked potentially malicious IPMicrosoft Defender for Cloud
– A storage account was accessed from a suspicious IP address.

Microsoft Defender for Identity
– Malicious registration of a device with strong MFA.
– Malicious registration of an attacker controlled MFA device.
– Suspicious registration of a new Authenticator MFA method.
– Malicious registration of a new Authenticator MFA method.
– Suspicious registration of a new Phone MFA method.
– Malicious registration of a new Phone MFA method – Malicious registration of a new Email MFA method.

Microsoft Defender XDR
– Malicious sign in from an IP address associated with recognized attacker infrastructure.DiscoveryGraph API reconnaissance activityMicrosoft Defender for Identity
– Suspicious Entra Graph API query observed. Exfiltration Data exfiltration activityMicrosoft Defender for Cloud
– Unusual number of blobs extracted from a storage blob container.
– Unusual amount of data extracted from a storage file share.
– Unusual number of files extracted from a storage file share.
– Unusual amount of data extracted from a sensitive blob container.
– Unusual number of blobs extracted from a sensitive blob container.
– Unusual amount of data extracted from a sensitive storage file share.
– Unusual number of files extracted from a sensitive storage file share.
– Sensitive data was exfiltrated from a publicly exposed blob container.

Microsoft Defender XDR
– Automated mass SharePoint/OneDrive file access via python-httpx. Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to investigate activity associated with this intrusion pattern:

• Incident investigation – Generates investigation summaries and helps analysts understand incidents involving compromised identities, suspicious sign-ins, persistence activity, and cloud-based data access.
• Microsoft User analysis – Analyses user accounts, sign-in activity, authentication events, risk indicators, and related identity signals that may help identify compromised accounts.

Customers can also use Microsoft Security Copilot together with Microsoft Threat Intelligence to investigate indicators, threat activity, and related intelligence associated with suspicious sign-ins, Microsoft Graph reconnaissance, and cloud data exfiltration activity.

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.

MITRE ATT&CK Techniques observed

Reconnaissance

• T1591 Gather Victim Org Information | Use of themed domains for credential phishing pages
• T1598.003 Phishing for Information: Spear-phishing Link | Use of spear-phishing emails with links to spoofed sign-in pages

Resource Development

• T1583.001 Acquire Infrastructure: Domains | Use of themed domains for credential phishing pages
• T1585.002 Establish Accounts: Email Accounts | Delivery infrastructure that is comprised of accounts from consumer email providers like Hotmail

Initial Access

• T1078.004 Valid Accounts: Cloud Accounts | The compromised cloud identity is used to authenticate to Microsoft cloud services.

Persistence

• T1556.006 Modify Authentication Process: Multi-Factor Authentication | After gaining account access, the threat actor registers a new authentication method, mobile device, or software-based OTP to establish persistent access to the compromised identity.

Discovery

• T1087.004 Account Discovery: Cloud Account | The threat actor uses Microsoft Graph to enumerate tenant users and identities, including information useful for identifying high-value identities and privileged accounts.
• T1069.003 Permission Groups Discovery: Cloud Groups | Microsoft Graph reconnaissance enumerates group memberships and directory roles, allowing the threat actor to understand privilege relationships and identify potentially valuable identities.

Collection

• T1530 Data from Cloud Storage | The actor searches and accesses SharePoint and OneDrive content and performs high-volume file access/download activity to collect targeted cloud-hosted information.
• T1114 Email Collection | Mailboxes, messages, and attachments are searched for material of interest and email is collected through REST APIs.
• T1213 Data from Information Repositories | The actor searches enterprise cloud repositories, including SharePoint content and other organizational cloud data, to identify information of value for collection.

Exfiltration

• T1567 Exfiltration Over Web Service | The campaign performs high-volume cloud data access and uses automated Python-based activity for rapid collection and exfiltration.

Advanced hunting queries

Additional advanced hunting query for Graph reconnaissance:

Hunt for automated pagination, delta, and search behavior

Identify actors walking large Graph result sets or repeatedly querying for data.

GraphAPIAuditEvents | where Timestamp > ago(24h) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId), Path = tostring(split(tolower(RequestUri), "?")[0]) | where Uri has_any ("$top", "%24top", "$skip", "%24skip", "$skiptoken", "%24skiptoken", "$count", "%24count", "/delta", "/search") | summarize AutomatedRequests=count(), DistinctPaths=dcount(Path), SampleUris=make_set(RequestUri, 12) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 15m) | where AutomatedRequests >= 8 and DistinctPaths >= 4 | order by AutomatedRequests desc Hunt for reconnaissance progressing to content collection

Prioritize sessions where broad discovery and content retrieval occur together.

GraphAPIAuditEvents | where Timestamp > ago(24h) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId) | extend ActivityType = case( Uri has "/content" or Uri has "/attachments", "ContentCollection", Uri has "/users" or Uri has "/groups", "DirectoryRecon", Uri has "/directoryroles" or Uri has "/rolemanagement" or Uri has "/authentication/methods", "PrivilegeRecon", Uri has "/applications" or Uri has "/serviceprincipals", "ApplicationRecon", Uri has "/sites" or Uri has "/drives" or Uri has "/drive/", "RepositoryRecon", Uri has "/messages" or Uri has "/mailfolders", "MailboxRecon", "Other") | where ActivityType != "Other" | summarize DiscoveryFirst=minif(Timestamp, ActivityType != "ContentCollection"), CollectionFirst=minif(Timestamp, ActivityType == "ContentCollection"), DiscoveryCategories=dcountif(ActivityType, ActivityType != "ContentCollection"), ContentRequests=countif(ActivityType == "ContentCollection"), TotalResponseBytes=sum(coalesce(ResponseSize, 0)), SampleUris=make_set(RequestUri, 15) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 1h) | where isnotnull(DiscoveryFirst) and isnotnull(CollectionFirst) | where CollectionFirst >= DiscoveryFirst and DiscoveryCategories >= 2 and ContentRequests >= 1 | order by CollectionFirst desc Hunt for exfiltration through Microsoft Graph

Prioritize sessions where broad discovery and content retrieval occur together.

GraphAPIAuditEvents | where Timestamp > ago(24h) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId) | extend ActivityType = case( Uri has "/content" or Uri has "/attachments", "ContentCollection", Uri has "/users" or Uri has "/groups", "DirectoryRecon", Uri has "/directoryroles" or Uri has "/rolemanagement" or Uri has "/authentication/methods", "PrivilegeRecon", Uri has "/applications" or Uri has "/serviceprincipals", "ApplicationRecon", Uri has "/sites" or Uri has "/drives" or Uri has "/drive/", "RepositoryRecon", Uri has "/messages" or Uri has "/mailfolders", "MailboxRecon", "Other") | where ActivityType != "Other" | summarize DiscoveryFirst=minif(Timestamp, ActivityType != "ContentCollection"), CollectionFirst=minif(Timestamp, ActivityType == "ContentCollection"), DiscoveryCategories=dcountif(ActivityType, ActivityType != "ContentCollection"), ContentRequests=countif(ActivityType == "ContentCollection"), TotalResponseBytes=sum(coalesce(ResponseSize, 0)), SampleUris=make_set(RequestUri, 15) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 1h) | where isnotnull(DiscoveryFirst) and isnotnull(CollectionFirst) | where CollectionFirst >= DiscoveryFirst and DiscoveryCategories >= 2 and ContentRequests >= 1 | order by CollectionFirst desc Indicators of compromise (IOC) Indicators TypeDescriptionpasskeyhelpdesk[.]com DomainsPasskey support luresecure-passkey[.]comDomainsPasskey security setupmypasskey[.]comDomainsPasskey setup add-passkey[.]comDomainsPasskey enrollment integratedsso[.]comDomainsSSO oktasession[.]com DomainsIdentity-provider session keysyncos[.]com DomainsKey synchronization oskeysync[.]com DomainsKey synchronization oskeysetup[.]com DomainsKey setup oskeyregister[.]com DomainsKey registration syncmykey[.]com DomainsKey synchronization myconnectkey[.]com DomainsKey connection oskeyconnect[.]com DomainsKey connection validationsetupac[.]com DomainsAccount validation and setup portalsetuphub[.]com DomainsPortal setup Learn more

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

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

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

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

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

The post Passkey-themed social engineering leads to identity and cloud compromise appeared first on Microsoft Security Blog.