Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570

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

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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:

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.

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.

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

Indicators of compromise

Network indicators

File hashes (SHA-256)

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