Crafted emails give attackers shells on Zimbra servers running SNMP notifications

The first probes Microsoft logged came eight days after Zimbra shipped the fix and 16 days before the CVE went public ^[1][2]. Both scanning tools used the same swatchdog-to-snmptrap route that later appeared in confirmed compromises ^[6].

The flaw sits in Zimbra's SNMP notification processing ^[1]. A crafted SMTP request carries shell metacharacters into the notification data ^[10]. When a service-state change sets off health monitoring, swatchdog places that attacker-controlled value inside an snmptrap shell command ^[10]. Whatever it contains runs with the privileges of the zimbra service account ^[3].

Early probes were built to confirm execution without delivering a payload ^[9]. Some ran local identity checks or dropped a small fingerprint script that showed both command execution and outside access to the server's webroot ^[9]. Others used curl, wget, ping and nslookup to reach one-off subdomains on oast[.]fun, oast[.]online, dnslog[.]pp[.]ua and requestrepo[.]com, plus campaign infrastructure under bypass[.]eu[.]org ^[7]. HTTP callbacks carried a ZB73570 User-Agent. DNS and ICMP callbacks used randomized subdomains ^[8].

In confirmed intrusions, attackers planted JSP web shells by changing webroot permissions, rebuilding an encoded, compressed payload from staged fragments, writing it into publicly reachable application directories and deleting the fragments ^[15]. Shells went onto both Jetty and mailboxd paths, with extra copies on peer mailbox nodes ^[17]. Other chains used cron, systemd or memfd_create for recurring or memory-backed execution ^[16].

Two distinct scanning tools, campaign infrastructure and automated payload delivery running beside hands-on-keyboard sessions describe an organized, repeated operation ^[6][7][13]. Microsoft's attack-chain diagram merges behavior from several confirmed compromises. No single host necessarily showed every stage ^[18].