Kit de respuesta a incidentes centrado en la detección para administradores de Zimbra que investigan CVE-2026-73570. Busca en los registros indicadores de explotación, examina ubicaciones de persistencia y recopila paquetes de evidencia con marcas de tiempo sin alterar el estado del host.
Asistentes de respuesta a incidentes centrados en la detección y preservación de evidencia para administradores de Zimbra que investigan una posible explotación de CVE-2026-73570.
[!CAUTION] Este es un proyecto comunitario independiente, no un oráculo de compromiso del proveedor. El verificador es de solo lectura e informa evidencia por severidad; no puede probar que un host esté limpio. Si se confirma o se sospecha razonablemente un compromiso de root, trate el host como no confiable: preserve la evidencia, conténgalo, rote los secretos desde un sistema limpio y reconstruya en una plataforma compatible.
Service status change: localhost y sintaxis sospechosa de shell/descarga.Zimbra.jsp.gs-dbus, procesos falsos, IRC/PowerBots, cron, rc.local, claves SSH, sudo, archivos temporales y conexiones salientes activas.No explota, descarga payloads, contacta infraestructura de IOC, elimina artefactos, envía datos, inspecciona contenido de buzones ni reemplaza el análisis forense. La ausencia de hallazgos puede significar registros faltantes/rotados, persistencia inactiva, permisos insuficientes, una variante no reconocida o recopilación posterior a la limpieza del atacante.
Ejecute en el host Zimbra desde una sesión administrativa confiable. Prefiera recopilar evidencia antes de una investigación extensa porque el trabajo en sistemas en vivo puede cambiar el estado volátil y los tiempos de acceso.
sudo ./scripts/check-zimbra-73570.sh
sudo ./scripts/check-zimbra-73570.sh --since-days 30 --json /secure/case/check-report.json
sudo ./scripts/collect-evidence.sh --output /secure/case
Los códigos de salida del verificador son:
| Código | Significado |
|---|---|
| 0 | Sin hallazgos medios/altos/críticos (no es prueba de seguridad) |
| 1 | Uno o más hallazgos medios |
| 2 | Uno o más hallazgos altos o críticos |
| 64 | Uso inválido |
La salida del verificador utiliza las categorías INFO, MEDIUM, HIGH y CRITICAL. Deliberadamente no colapsa evidencia matizada en una única bandera COMPROMISED. Un informe JSON se escribe solo cuando se solicita --json. Las comprobaciones de archivos se pueden probar contra un fixture aislado con --root; las comprobaciones de procesos y red en vivo se omiten entonces.
El recopilador crea un directorio con modo 0700 y un archivo comprimido junto a él, registra metadatos de recopilación y escribe manifiestos SHA-256. Lee archivos sospechosos solo para calcular su hash y no los pone en cuarentena, trunca, cambia permisos, elimina ni ejecuta. El paquete resultante puede contener nombres de host sensibles, nombres de usuario, extractos de registros, configuración, direcciones IP y claves públicas: manténgalo cifrado, con control de acceso y fuera de este repositorio.
Los indicadores se separan en:
Consulte IOCS.md, iocs.csv y iocs.json. No se incluyen muestras de malware ni evidencia específica de víctimas. No se contactó ninguna URL de payload durante el desarrollo; el estado de las URL es histórico/no verificado a menos que un tercero confiable lo establezca de forma independiente.
La evidencia saneada respalda esta cadena de trabajo:
Intento de inyección de comandos SMTP
-> ejecución como zimbra
-> persistencia JSP
-> inventario/reconocimiento del sistema
-> despliegue de GSocket
-> gs-dbus / [kcached]
-> bot Perl IRC
-> posible escalada a root o persistencia
Esta es una cadena derivada del incidente, no un comportamiento universal de CVE. En el conjunto de evidencia saneada, la descarga/ejecución como cuenta de servicio, un shell interactivo, una configuración de Nginx controlada por el atacante lanzada por root, procesos root gs-dbus/[kcached] y persistencia root por hora están directamente corroborados. Los mecanismos exactos de escalada de privilegios, la línea de tiempo de despliegue de JSP, cada rama del payload, la identidad del operador y la atribución siguen siendo brechas dependientes de la evidencia. Consulte docs/triage.md.
No publique evidencia en vivo de víctimas ni muestras de malware. Después de la validación interna y la autorización, los paquetes de indicadores defensivos pueden compartirse con Shadowserver. Los envíos a URLhaus deben limitarse a URL verificadas de forma independiente como URL activas de entrega de malware; las URL históricas o no verificadas no deben enviarse como activas.
Todas las pruebas utilizan fixtures estáticos y no realizan actividad de red:
make validate
Esto verifica la sintaxis de Bash, la consistencia del esquema IOC/CSV/JSON, la detección de fixtures, la salida legible por máquina y la higiene del repositorio. shellcheck se utiliza cuando está instalado.
Revise CONTRIBUTING.md antes de proponer indicadores o cambios de detección. Reporte problemas de seguridad de forma privada como se describe en SECURITY.md. Licenciado bajo Apache-2.0; consulte LICENSE.