Toolkit di risposta agli incidenti incentrato sul rilevamento per gli amministratori di Zimbra che indagano sulla CVE-2026-73570. Cerca nei log gli indicatori di exploit, esamina le posizioni di persistenza e raccoglie bundle di prove con timestamp senza alterare lo stato dell'host.
Strumenti di incident response incentrati sul rilevamento e sulla preservazione delle prove per gli amministratori Zimbra che indagano su un sospetto sfruttamento di CVE-2026-73570.
[!CAUTION] Questo è un progetto comunitario indipendente, non un oracolo di compromissione del fornitore. Il checker è in sola lettura e riporta le prove per gravità; non può dimostrare che un host sia pulito. Se la compromissione del root è confermata o credibilmente sospettata, trattare l'host come non affidabile: preservare le prove, contenerlo, ruotare i segreti da un sistema pulito e ricostruire su una piattaforma supportata.
Service status change: localhost e sintassi sospetta di shell/download.Zimbra.jsp.gs-dbus, processi falsi, IRC/PowerBots, cron, rc.local, chiavi SSH, sudo, file temporanei e connessioni outbound attive.Non sfrutta, recupera payload, contatta infrastruttura IOC, rimuove artefatti, invia dati, ispeziona il contenuto della casella di posta o sostituisce l'analisi forense. L'assenza di risultati può significare log mancanti/ruotati, persistenza inattiva, permessi insufficienti, una variante non riconosciuta o raccolta dopo la pulizia da parte dell'attaccante.
Eseguire sull'host Zimbra da una sessione amministrativa affidabile. Preferire la raccolta delle prove prima di un'indagine approfondita perché il lavoro su sistemi live può modificare lo stato volatile e i tempi di accesso.
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
I codici di uscita del checker sono:
| Codice | Significato |
|---|---|
| 0 | Nessun risultato medio/alto/critico (non prova di sicurezza) |
| 1 | Uno o più risultati medi |
| 2 | Uno o più risultati alti o critici |
| 64 | Utilizzo non valido |
L'output del checker utilizza le categorie INFO, MEDIUM, HIGH e CRITICAL. Non comprime deliberatamente prove sfumate in un singolo flag COMPROMISED. Un report JSON viene scritto solo quando viene richiesto --json. I controlli sui file possono essere testati contro un fixture isolato con --root; i controlli live su processi e rete vengono quindi saltati.
Il collector crea una directory con modalità 0700 e un archivio compresso accanto ad essa, registra i metadati di raccolta e scrive manifest SHA-256. Legge i file sospetti solo per calcolarne l'hash e non li mette in quarantena, tronca, cambia permessi, elimina o esegue. Il bundle risultante può contenere hostname sensibili, nomi utente, estratti di log, configurazione, indirizzi IP e chiavi pubbliche: mantenerlo crittografato, con controllo degli accessi e fuori da questo repository.
Gli indicatori sono separati in:
Vedere IOCS.md, iocs.csv e iocs.json. Nessun campione di malware o prove specifiche della vittima sono inclusi. Nessun URL di payload è stato contattato durante lo sviluppo; lo stato degli URL è storico/non verificato a meno che una terza parte affidabile non stabilisca diversamente in modo indipendente.
Le prove sanificate supportano questa catena di lavoro:
Tentativo di injection di comandi SMTP
-> esecuzione come zimbra
-> persistenza JSP
-> inventario/ricognizione del sistema
-> distribuzione GSocket
-> gs-dbus / [kcached]
-> bot IRC Perl
-> possibile escalation a root o persistenza
Questa è una catena derivata dall'incidente, non un comportamento universale della CVE. Nell'insieme di prove sanificate, download/esecuzione come account di servizio, una shell interattiva, una configurazione Nginx controllata dall'attaccante avviata da root, processi root gs-dbus/[kcached] e persistenza root oraria sono direttamente corroborati. I meccanismi esatti di escalation dei privilegi, la timeline di distribuzione JSP, ogni ramo del payload, l'identità dell'operatore e l'attribuzione rimangono lacune dipendenti dalle prove. Vedere docs/triage.md.
Non pubblicare prove live della vittima o campioni di malware. Dopo la validazione interna e l'autorizzazione, i pacchetti di indicatori difensivi possono essere condivisi con Shadowserver. Le segnalazioni a URLhaus dovrebbero essere limitate a URL verificati in modo indipendente come URL attivi di distribuzione di malware; gli URL storici o non verificati non dovrebbero essere segnalati come attivi.
Tutti i test utilizzano fixture statici e non eseguono alcuna attività di rete:
make validate
Questo controlla la sintassi Bash, la coerenza dello schema IOC/CSV/JSON, il rilevamento dei fixture, l'output leggibile dalla macchina e l'igiene del repository. shellcheck viene utilizzato quando installato.
Rivedere CONTRIBUTING.md prima di proporre indicatori o modifiche al rilevamento. Segnalare i problemi di sicurezza privatamente come descritto in SECURITY.md. Concesso in licenza sotto Apache-2.0; vedere LICENSE.