
Toolkit de resposta a incidentes com deteção em primeiro lugar para administradores do Zimbra a investigar o CVE-2026-73570. Pesquisa registos à procura de indicadores de exploração, examina locais de persistência e recolhe pacotes de evidências com carimbo temporal sem alterar o estado do anfitrião.
Ferramentas de resposta a incidentes focadas em detecção e preservação de evidências para administradores de Zimbra que investigam suspeitas de exploração da CVE-2026-73570.
[!CAUTION] Este é um projeto comunitário independente, não um oráculo de comprometimento do fornecedor. O verificador é somente leitura e relata evidências por severidade; ele não pode provar que um host está limpo. Se o comprometimento de root for confirmado ou razoavelmente suspeito, trate o host como não confiável: preserve evidências, contenha, rotacione segredos a partir de um sistema limpo e reconstrua em uma plataforma suportada.
Service status change: localhost e sintaxe suspeita de shell/download.Zimbra.jsp.gs-dbus, processos falsos, IRC/PowerBots, cron, rc.local, chaves SSH, sudo, arquivos temporários e conexões de saída ativas.Ele não explora, busca payloads, contata infraestrutura de IOC, remove artefatos, envia dados, inspeciona conteúdo de caixa de correio ou substitui análise forense. A ausência de achados pode significar logs ausentes/rotacionados, persistência inativa, permissões insuficientes, uma variante não reconhecida ou coleta após a limpeza pelo atacante.
Execute no host Zimbra a partir de uma sessão administrativa confiável. Prefira coletar evidências antes de investigações extensas, pois o trabalho em sistemas ativos pode alterar o estado volátil e os tempos de acesso.
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
Os códigos de saída do verificador são:
| Código | Significado |
|---|---|
| 0 | Nenhum achado médio/alto/crítico (não é prova de segurança) |
| 1 | Um ou mais achados médios |
| 2 | Um ou mais achados altos ou críticos |
| 64 | Uso inválido |
A saída do verificador usa as categorias INFO, MEDIUM, HIGH e CRITICAL. Ele deliberadamente não colapsa evidências diferenciadas em um único sinalizador COMPROMISED. Um relatório JSON é gravado somente quando --json é solicitado. As verificações de arquivos podem ser testadas contra um fixture isolado com --root; verificações de processos ativos e rede são então ignoradas.
O coletor cria um diretório com modo 0700 e um arquivo compactado ao lado dele, registra metadados de coleta e grava manifestos SHA-256. Ele lê arquivos suspeitos apenas para gerar hashes e não os coloca em quarentena, trunca, altera permissões, exclui ou executa. O pacote resultante pode conter nomes de host sensíveis, nomes de usuário, trechos de logs, configuração, endereços IP e chaves públicas: mantenha-o criptografado, com controle de acesso e fora deste repositório.
Os indicadores são separados em:
Consulte IOCS.md, iocs.csv e iocs.json. Nenhuma amostra de malware ou evidência específica de vítima está incluída. Nenhuma URL de payload foi contatada durante o desenvolvimento; o status das URLs é histórico/não verificado, a menos que um terceiro confiável estabeleça o contrário de forma independente.
As evidências sanitizadas suportam esta cadeia de trabalho:
Tentativa de injeção de comandos SMTP
-> execução como zimbra
-> persistência JSP
-> inventário/reconhecimento do sistema
-> implantação de GSocket
-> gs-dbus / [kcached]
-> bot IRC em Perl
-> possível escalonamento de privilégios ou persistência de root
Esta é uma cadeia derivada do incidente, não um comportamento universal da CVE. No conjunto de evidências sanitizadas, download/execução como a conta de serviço, um shell interativo, uma configuração Nginx controlada pelo atacante iniciada por root, processos root gs-dbus/[kcached] e persistência de root por hora são diretamente corroborados. Os mecanismos exatos de escalonamento de privilégios, a linha do tempo de implantação do JSP, cada ramo do payload, a identidade do operador e a atribuição permanecem lacunas dependentes de evidências. Consulte docs/triage.md.
Não publique evidências ao vivo de vítimas ou amostras de malware. Após validação interna e autorização, pacotes de indicadores defensivos podem ser compartilhados com o Shadowserver. Envios ao URLhaus devem ser limitados a URLs verificadas de forma independente como URLs ativas de entrega de malware; URLs históricas ou não verificadas não devem ser enviadas como ativas.
Todos os testes usam fixtures estáticos e não realizam nenhuma atividade de rede:
make validate
Isso verifica sintaxe Bash, consistência de esquema/CSV/JSON de IOC, detecção de fixtures, saída legível por máquina e higiene do repositório. shellcheck é usado quando instalado.
Revise CONTRIBUTING.md antes de propor indicadores ou mudanças de detecção. Relate problemas de segurança de forma privada conforme descrito em SECURITY.md. Licenciado sob Apache-2.0; consulte LICENSE.