Zimbra Swatchdog SNMP Command Injection Execution

Detects a Unix shell launched by Perl from a generated Zimbra ".swatchdog_script" when the shell command line contains an "snmptrap" invocation and Zimbra SNMP service fields, followed by an unexpected child process other than "snmptrap". This sequence provides high-confidence evidence of external command execution through CVE-2026-73570, an unauthenticated command-injection vulnerability in Zimbra's SNMP monitoring path.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/09/30"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/09/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a Unix shell launched by Perl from a generated Zimbra ".swatchdog_script" when the shell command line contains
 11an "snmptrap" invocation and Zimbra SNMP service fields, followed by an unexpected child process other than "snmptrap".
 12This sequence provides high-confidence evidence of external command execution through CVE-2026-73570, an unauthenticated
 13command-injection vulnerability in Zimbra's SNMP monitoring path.
 14"""
 15false_positives = [
 16    """
 17    Authorized security testing or a purpose-built synthetic process fixture may reproduce this lineage. Patched Zimbra
 18    10.1.20 and later invokes `snmptrap` without passing the attacker-controlled value through a shell. On vulnerable
 19    installations, legitimate monitoring should launch `snmptrap` from the shell but should not launch another child.
 20    """,
 21]
 22from = "now-9m"
 23index = ["logs-endpoint.events.process-*"]
 24language = "eql"
 25license = "Elastic License v2"
 26name = "Zimbra Swatchdog SNMP Command Injection Execution"
 27note = """## Triage and analysis
 28
 29### Investigating Zimbra Swatchdog SNMP Command Injection Execution
 30
 31CVE-2026-73570 affects Zimbra Collaboration installations before 10.1.20 when the optional `zimbra-snmp` package is
 32installed, SNMP notifications are enabled, `zmswatch` is running, and SMTP is attacker-reachable. A crafted SMTP
 33request can poison `/var/log/zimbra.log` with a forged service-status record. Vulnerable Swatchdog processing captures
 34the attacker-controlled service value and interpolates it into a Perl backtick expression, causing a Unix shell to
 35interpret shell grammar embedded in an `snmptrap` command.
 36
 37This rule targets execution immediately after the vulnerable boundary rather than one payload, callback domain, or
 38utility. It requires a shell child of Perl, a generated `.swatchdog_script` parent command line, `snmptrap`, the Zimbra
 39SNMP service fields, and an additional child process spawned by that shell. A match is very high-confidence evidence
 40of command injection, even if a downloaded payload was encoded, changed, or never written to disk. Shell-only payloads
 41that use built-ins or redirection without starting another process are outside this rule and require the companion
 42network or poisoned-log detection.
 43
 44### Possible investigation steps
 45
 46- Preserve the complete process tree, command lines, process entity identifiers, executable hashes, environment, open
 47  files, network connections, and memory for the matching shell, Perl parent, and descendant processes.
 48- Identify the unexpected child process from the second event in the sequence and determine what command, script, or
 49  interpreter it executed.
 50- Extract the injected command without executing it. Identify callback destinations, downloaded files, output
 51  redirection, background execution, decoders, and commands chained after `snmptrap`.
 52- Search `/var/log/zimbra.log`, Postfix logs, remote syslog, and rotated records for the preceding forged
 53  `Service status change` text and determine the originating SMTP source.
 54- Pivot on the shell's `process.entity_id` and descendants for `curl`, `wget`, `ping`, `nslookup`, `id`, interpreters,
 55  JSP writes, Java or `jspawnhelper` shells, named pipes, `openssl s_client`, systemd units, PAM or sudo changes,
 56  `memfd` execution, Zimbra credential access, SSH or rsync, archive creation, and AzCopy.
 57- Review all Zimbra mailbox and MTA peers for matching process ancestry, files, hashes, service units, webshells, and
 58  cluster movement. Do not scope the incident to only the first server.
 59- Verify the Zimbra release, `zimbra-mta-patch` level, `zimbra-snmp` package state, notification configuration, and
 60  whether `zmswatch` was running when the event occurred.
 61
 62### False positive analysis
 63
 64- Confirm whether an approved security test or detection exercise intentionally generated the process event.
 65- Review the full ancestry and command line before considering an exception. Legitimate vulnerable-path monitoring
 66  should launch `snmptrap`, but not the additional child process required by this rule.
 67- If a benign fixture is confirmed, constrain any exception to the dedicated test host and time window rather than
 68  excluding Perl, shells, `snmptrap`, or Zimbra paths globally.
 69
 70### Response and remediation
 71
 72- Isolate the affected Zimbra node while preserving volatile evidence and mail-flow continuity through a known-clean
 73  peer where possible.
 74- Upgrade all affected nodes to Zimbra Collaboration 10.1.20 or later. Patching does not remove persistence or prove
 75  the server was not previously compromised.
 76- Scope every cluster node and remove redundant webshells, unauthorized services, PAM or sudo modifications, SSH keys,
 77  local accounts, cron jobs, memory-backed payloads, and remote-access tooling.
 78- Rebuild confirmed compromised hosts from trusted media.
 79- Rotate Zimbra service credentials, LDAP/MySQL/Postfix/Amavis secrets, domain pre-authentication keys, token-signing
 80  keys, exposed two-factor secrets, certificates and private keys, active sessions, and cloud transfer tokens.
 81"""
 82references = [
 83    "https://www.microsoft.com/en-us/security/blog/2026/09/30/unauthenticated-command-injection-on-internet-facing-mail-servers-tracking-cve-2026-73570/",
 84    "https://wiki.zimbra.com/wiki/Zimbra_Releases/10.1.20",
 85    "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories",
 86    "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search=CVE-2026-73570",
 87    "https://www.pruva.dev/reproductions/REPRO-2026-00327",
 88]
 89risk_score = 99
 90rule_id = "1fa1a434-75a7-4c58-9bef-331d62bf3f82"
 91setup = """## Setup
 92
 93This rule requires process events from Elastic Defend on every Zimbra MTA and mailbox node. Use a policy that records
 94Linux process starts with complete child and parent command lines. Confirm that `process.parent.command_line` retains
 95the generated `.swatchdog_script` path and that `process.command_line` retains the shell's `snmptrap` command.
 96
 97Forward Zimbra and Postfix logs off-host as a companion data source. The matching process sequence proves external
 98execution behavior, while the preceding poisoned log record can identify the remote SMTP source and submitted text.
 99"""
100severity = "critical"
101tags = [
102    "Domain: Endpoint",
103    "OS: Linux",
104    "Use Case: Threat Detection",
105    "Use Case: Vulnerability",
106    "Tactic: Initial Access",
107    "Tactic: Execution",
108    "Data Source: Elastic Defend",
109    "Resources: Investigation Guide",
110    "Threat: Vulnerability Exploit",
111    "Rule Type: Event Correlation (EQL)",
112    "Platform: Linux",
113    "Vuln: CVE-2026-73570",
114]
115timestamp_override = "event.ingested"
116type = "eql"
117
118query = '''
119sequence by host.id with maxspan=30s
120  [process where
121    host.os.type == "linux" and
122    event.type == "start" and
123    event.action in ("exec", "exec_event", "start") and
124    process.name in ("sh", "bash", "dash", "ash", "zsh", "ksh") and
125    process.parent.name like~ "perl*" and
126    process.parent.command_line like~ "*.swatchdog_script*" and
127    process.command_line like~ "*snmptrap*" and
128    process.command_line like~ "*zmservicename*" and
129    process.command_line like~ "*zmservicestatus*"
130  ] by process.entity_id
131  [process where
132    host.os.type == "linux" and
133    event.type == "start" and
134    event.action in ("exec", "exec_event", "start") and
135    process.name != "snmptrap"
136  ] by process.parent.entity_id
137'''
138
139
140[[rule.threat]]
141framework = "MITRE ATT&CK"
142[[rule.threat.technique]]
143id = "T1059"
144name = "Command and Scripting Interpreter"
145reference = "https://attack.mitre.org/techniques/T1059/"
146[[rule.threat.technique.subtechnique]]
147id = "T1059.004"
148name = "Unix Shell"
149reference = "https://attack.mitre.org/techniques/T1059/004/"
150
151
152
153[rule.threat.tactic]
154id = "TA0002"
155name = "Execution"
156reference = "https://attack.mitre.org/tactics/TA0002/"
157[[rule.threat]]
158framework = "MITRE ATT&CK"
159[[rule.threat.technique]]
160id = "T1190"
161name = "Exploit Public-Facing Application"
162reference = "https://attack.mitre.org/techniques/T1190/"
163
164
165[rule.threat.tactic]
166id = "TA0001"
167name = "Initial Access"
168reference = "https://attack.mitre.org/tactics/TA0001/"

Triage and analysis

Investigating Zimbra Swatchdog SNMP Command Injection Execution

CVE-2026-73570 affects Zimbra Collaboration installations before 10.1.20 when the optional zimbra-snmp package is installed, SNMP notifications are enabled, zmswatch is running, and SMTP is attacker-reachable. A crafted SMTP request can poison /var/log/zimbra.log with a forged service-status record. Vulnerable Swatchdog processing captures the attacker-controlled service value and interpolates it into a Perl backtick expression, causing a Unix shell to interpret shell grammar embedded in an snmptrap command.

This rule targets execution immediately after the vulnerable boundary rather than one payload, callback domain, or utility. It requires a shell child of Perl, a generated .swatchdog_script parent command line, snmptrap, the Zimbra SNMP service fields, and an additional child process spawned by that shell. A match is very high-confidence evidence of command injection, even if a downloaded payload was encoded, changed, or never written to disk. Shell-only payloads that use built-ins or redirection without starting another process are outside this rule and require the companion network or poisoned-log detection.

Possible investigation steps

  • Preserve the complete process tree, command lines, process entity identifiers, executable hashes, environment, open files, network connections, and memory for the matching shell, Perl parent, and descendant processes.
  • Identify the unexpected child process from the second event in the sequence and determine what command, script, or interpreter it executed.
  • Extract the injected command without executing it. Identify callback destinations, downloaded files, output redirection, background execution, decoders, and commands chained after snmptrap.
  • Search /var/log/zimbra.log, Postfix logs, remote syslog, and rotated records for the preceding forged Service status change text and determine the originating SMTP source.
  • Pivot on the shell's process.entity_id and descendants for curl, wget, ping, nslookup, id, interpreters, JSP writes, Java or jspawnhelper shells, named pipes, openssl s_client, systemd units, PAM or sudo changes, memfd execution, Zimbra credential access, SSH or rsync, archive creation, and AzCopy.
  • Review all Zimbra mailbox and MTA peers for matching process ancestry, files, hashes, service units, webshells, and cluster movement. Do not scope the incident to only the first server.
  • Verify the Zimbra release, zimbra-mta-patch level, zimbra-snmp package state, notification configuration, and whether zmswatch was running when the event occurred.

False positive analysis

  • Confirm whether an approved security test or detection exercise intentionally generated the process event.
  • Review the full ancestry and command line before considering an exception. Legitimate vulnerable-path monitoring should launch snmptrap, but not the additional child process required by this rule.
  • If a benign fixture is confirmed, constrain any exception to the dedicated test host and time window rather than excluding Perl, shells, snmptrap, or Zimbra paths globally.

Response and remediation

  • Isolate the affected Zimbra node while preserving volatile evidence and mail-flow continuity through a known-clean peer where possible.
  • Upgrade all affected nodes to Zimbra Collaboration 10.1.20 or later. Patching does not remove persistence or prove the server was not previously compromised.
  • Scope every cluster node and remove redundant webshells, unauthorized services, PAM or sudo modifications, SSH keys, local accounts, cron jobs, memory-backed payloads, and remote-access tooling.
  • Rebuild confirmed compromised hosts from trusted media.
  • Rotate Zimbra service credentials, LDAP/MySQL/Postfix/Amavis secrets, domain pre-authentication keys, token-signing keys, exposed two-factor secrets, certificates and private keys, active sessions, and cloud transfer tokens.

References

Related rules

to-top