Microsoft Threat Intelligenceは、Zimbra Collaboration SuiteのSNMP通知経路に存在するCVE-2026-73570の悪用を検知した。この脆弱性により、任意のユーザー操作や認証なしで、リモートからシステムコマンドを実行できる。これは、オプションのzimbra-snmpパッケージがインストールされ、インターネット経由で到達可能なZimbraサーバーでSNMP通知が有効になっている場合に発生する。
Microsoftによると、悪用は特別に細工されたSMTPメッセージから始まる。攻撃者が制御する値がSNMP通知の処理に到達し、サービス状態の監視に関連するshell呼び出しに挿入される可能性がある。その結果、攻撃者はzimbraサービスアカウントの権限でコマンドを実行できる。
公開前に始まっていた悪用
Zimbraは2026年7月20日にリリース10.1.20で修正を提供した。一方、脆弱性が公に開示されたのは8月13日だった。7月28日から8月7日にかけて、Microsoftは脆弱性の一般公開前に、同じ経路を通じたコマンド実行の可能性を確認する、範囲外の外部スキャンおよびテストツールを検知した。
テストではHTTPリクエスト、DNSクエリ、ICMP、さらにcurl、wget、ping、nslookup、idなどのコマンドが使用され、コマンド実行とサーバーへの外部アクセスが確認された。必ずしも完全なペイロードをダウンロードする必要はなかった。
コマンド実行からサーバー制御へ
初期アクセスの後、攻撃者はZimbraのアプリケーションパス内にJSP形式のバックドアを設置し、リバースshellセッションを作成して、バックグラウンドで処理を実行した。Microsoftは、実行を維持したり、メモリ上からペイロードを起動したりするために、cron、systemd、memfd_createが使用されたことも検知した。
ある攻撃チェーンでは、sudoの使用を許可されたコンポーネントとPAMに関連する経路が悪用され、zimbraアカウントの権限がrootへ昇格された。また攻撃者は、Zimbraの正規コンポーネントを模倣したzimlog.serviceという名前のsystemdサービスをインストールし、システム起動時にペイロードを実行した。
活動は最初のサーバーにとどまらなかった。Zimbra内に存在するSSH認証情報とrsyncプログラムが使用され、メールクラスター内の他のノードへファイルやバックドアが転送された。これによりアクセス範囲が拡大し、単一の侵入口への依存が低減された。
認証情報とメールデータの標的化
攻撃者はZimbraのローカル設定から値を収集した。そこにはLDAP、MySQL、Postfix、Amavis、レプリケーションサービスの認証情報が含まれていた。また、zimbraPreAuthKey、zimbraAuthTokenKey、zimbraTwoFactorAuthSecretなどのキーも標的にした。
Microsoftの分析によると、一部のツールはメールデータベース、デバイスデータ、外出先設定に加え、証明書、秘密鍵、Postfix設定ファイルの読み取りを試みた。ある事案では、メールボックスの新しいバックアップがアーカイブにまとめられ、その後AzCopyを使用してAzure Blobストレージへの転送が試みられた。利用可能な証拠は、転送が完了したことを確認していない。
運用者が行うべきこと
基本的な推奨事項は、すべてのZimbraサーバーを10.1.20以降へアップグレードすることだ。直ちに修正できない場合、Microsoftはオプションのzimbra-snmpパッケージを削除し、SNMP通知を無効にし、SNMPおよびSMTPへのアクセスを信頼できるホストだけに制限することを推奨している。
また、インターネットに公開されたメールサーバー上でのreverse shellに関するアラートは、高優先度のインシデントとして扱うべきであり、既知のマルウェア名の検索だけで済ませてはならない。より深刻な結果の一部では、特定のマルウェアファミリーを伴わない通常の対話型shellの使用が確認された。対応措置には、Zimbraの秘密情報と認証キーのローテーション、systemdサービス、PAMモジュール、sudoの検査、すべてのメールノードにおける予期しないJSPファイルおよび生成されたservletの痕跡の調査が含まれる。
この調査は、実際のリスクが単一のコマンド実行に限定されないことを示している。公開されたメールサーバーの1つの脆弱性が、秘密情報の収集、永続的なアクセス手段の設置、クラスター内での横展開、メールデータの抽出試行の出発点になり得る。一方、アーカイブの作成やクラウド転送ツールの実行といった指標だけでは、データ窃取の成功は証明できない。実際に何が起きたかを特定するには、プロセス、ファイル、通信のログを関連付ける必要がある。