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 forgedService status changetext and determine the originating SMTP source. - Pivot on the shell's
process.entity_idand descendants forcurl,wget,ping,nslookup,id, interpreters, JSP writes, Java orjspawnhelpershells, named pipes,openssl s_client, systemd units, PAM or sudo changes,memfdexecution, 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-patchlevel,zimbra-snmppackage state, notification configuration, and whetherzmswatchwas 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
- Cupsd or Foomatic-rip Shell Execution
- File Creation by Cups or Foomatic-rip Child
- Potential Java Service Exploitation via Suspicious Child Process
- Potential SAP NetWeaver Exploitation
- Potential Telnet Authentication Bypass (CVE-2026-24061)