Zimbra Swatchdog SNMP Command Injection Execution

Description

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.

Query · eql

sequence by host.id with maxspan=30s
  [process where
    host.os.type == "linux" and
    event.type == "start" and
    event.action in ("exec", "exec_event", "start") and
    process.name in ("sh", "bash", "dash", "ash", "zsh", "ksh") and
    process.parent.name like~ "perl*" and
    process.parent.command_line like~ "*.swatchdog_script*" and
    process.command_line like~ "*snmptrap*" and
    process.command_line like~ "*zmservicename*" and
    process.command_line like~ "*zmservicestatus*"
  ] by process.entity_id
  [process where
    host.os.type == "linux" and
    event.type == "start" and
    event.action in ("exec", "exec_event", "start") and
    process.name != "snmptrap"
  ] by process.parent.entity_id

Implementation guide

This rule requires process events from Elastic Defend on every Zimbra MTA and mailbox node. Use a policy that records Linux process starts with complete child and parent command lines. Confirm that process.parent.command_line retains the generated .swatchdog_script path and that process.command_line retains the shell's snmptrap command.

Forward Zimbra and Postfix logs off-host as a companion data source. The matching process sequence proves external execution behavior, while the preceding poisoned log record can identify the remote SMTP source and submitted text.

Known false positives

  • Authorized security testing or a purpose-built synthetic process fixture may reproduce this lineage. Patched Zimbra 10.1.20 and later invokes `snmptrap` without passing the attacker-controlled value through a shell. On vulnerable installations, legitimate monitoring should launch `snmptrap` from the shell but should not launch another child.

Analyst notes

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.
Raw source Zimbra Swatchdog SNMP Command Injection Execution · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2026/09/30"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/09/30"

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
    """
    Authorized security testing or a purpose-built synthetic process fixture may reproduce this lineage. Patched Zimbra
    10.1.20 and later invokes `snmptrap` without passing the attacker-controlled value through a shell. On vulnerable
    installations, legitimate monitoring should launch `snmptrap` from the shell but should not launch another child.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Zimbra Swatchdog SNMP Command Injection Execution"
note = """## 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 = [
    "https://www.microsoft.com/en-us/security/blog/2026/09/30/unauthenticated-command-injection-on-internet-facing-mail-servers-tracking-cve-2026-73570/",
    "https://wiki.zimbra.com/wiki/Zimbra_Releases/10.1.20",
    "https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories",
    "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search=CVE-2026-73570",
    "https://www.pruva.dev/reproductions/REPRO-2026-00327",
]
risk_score = 99
rule_id = "1fa1a434-75a7-4c58-9bef-331d62bf3f82"
setup = """## Setup

This rule requires process events from Elastic Defend on every Zimbra MTA and mailbox node. Use a policy that records
Linux process starts with complete child and parent command lines. Confirm that `process.parent.command_line` retains
the generated `.swatchdog_script` path and that `process.command_line` retains the shell's `snmptrap` command.

Forward Zimbra and Postfix logs off-host as a companion data source. The matching process sequence proves external
execution behavior, while the preceding poisoned log record can identify the remote SMTP source and submitted text.
"""
severity = "critical"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Use Case: Vulnerability",
    "Tactic: Initial Access",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
    "Threat: Vulnerability Exploit",
    "Rule Type: Event Correlation (EQL)",
    "Platform: Linux",
    "Vuln: CVE-2026-73570",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by host.id with maxspan=30s
  [process where
    host.os.type == "linux" and
    event.type == "start" and
    event.action in ("exec", "exec_event", "start") and
    process.name in ("sh", "bash", "dash", "ash", "zsh", "ksh") and
    process.parent.name like~ "perl*" and
    process.parent.command_line like~ "*.swatchdog_script*" and
    process.command_line like~ "*snmptrap*" and
    process.command_line like~ "*zmservicename*" and
    process.command_line like~ "*zmservicestatus*"
  ] by process.entity_id
  [process where
    host.os.type == "linux" and
    event.type == "start" and
    event.action in ("exec", "exec_event", "start") and
    process.name != "snmptrap"
  ] by process.parent.entity_id
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"


[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.