Détection-first incident-response toolkit pour les administrateurs Zimbra enquêtant sur CVE-2026-73570. Recherche dans les journaux les indicateurs d'exploitation, examine les emplacements de persistance et collecte des bundles de preuves horodatés sans modifier l'état de l'hôte.
Aides à la réponse aux incidents pour les administrateurs Zimbra, axées sur la détection et la préservation des preuves, lors de l'investigation d'une exploitation suspectée de CVE-2026-73570.
[!CAUTION] Il s'agit d'un projet communautaire indépendant, pas d'un oracle de compromission du fournisseur. Le vérificateur est en lecture seule et rapporte les preuves par gravité ; il ne peut pas prouver qu'un hôte est sain. Si une compromission root est confirmée ou crédiblement suspectée, traitez l'hôte comme non fiable : préservez les preuves, contenez-le, faites pivoter les secrets depuis un système sain, et reconstruisez sur une plateforme prise en charge.
Service status change: localhost et les syntaxes suspectes de shell/téléchargement.Zimbra.jsp.gs-dbus, processus factices, IRC/PowerBots, cron, rc.local, clés SSH, sudo, fichiers temporaires, et connexions sortantes actives.Il n'exploite pas, ne récupère pas de charges utiles, ne contacte pas d'infrastructure IOC, ne supprime pas d'artefacts, ne soumet pas de données, n'inspecte pas le contenu des boîtes mail, et ne remplace pas l'analyse forensique. Une absence de résultats peut signifier des journaux manquants/pivotés, une persistance inactive, des permissions insuffisantes, une variante non reconnue, ou une collecte après nettoyage par l'attaquant.
Exécutez sur l'hôte Zimbra depuis une session administrative de confiance. Privilégiez la collecte de preuves avant une investigation approfondie, car le travail sur un système en direct peut modifier l'état volatil et les temps d'accès.
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
Les codes de sortie du vérificateur sont :
| Code | Signification |
|---|---|
| 0 | Aucun résultat moyen/élevé/critique (pas une preuve de sécurité) |
| 1 | Un ou plusieurs résultats moyens |
| 2 | Un ou plusieurs résultats élevés ou critiques |
| 64 | Utilisation invalide |
La sortie du vérificateur utilise les catégories INFO, MEDIUM, HIGH, et CRITICAL. Il ne réduit délibérément pas les preuves nuancées à un seul drapeau COMPROMISED. Un rapport JSON n'est écrit que lorsque --json est demandé. Les vérifications de fichiers peuvent être testées contre un fixture isolé avec --root ; les vérifications de processus et de réseau en direct sont alors ignorées.
Le collecteur crée un répertoire en mode 0700 et une archive compressée à côté, enregistre les métadonnées de collecte, et écrit des manifestes SHA-256. Il lit les fichiers suspects uniquement pour les hacher et ne les met pas en quarantaine, ne les tronque pas, ne change pas leurs permissions, ne les supprime pas et ne les exécute pas. Le bundle résultant peut contenir des noms d'hôtes sensibles, des noms d'utilisateurs, des extraits de journaux, des configurations, des adresses IP et des clés publiques : conservez-le chiffré, avec contrôle d'accès, et hors de ce dépôt.
Les indicateurs sont séparés en :
Voir IOCS.md, iocs.csv, et iocs.json. Aucun échantillon de malware ni preuve spécifique à une victime n'est inclus. Aucune URL de charge utile n'a été contactée pendant le développement ; le statut des URL est historique/non vérifié sauf si un tiers de confiance l'établit indépendamment autrement.
Les preuves assainies soutiennent cette chaîne de travail :
Tentative d'injection de commandes SMTP
-> exécution en tant que zimbra
-> persistance JSP
-> inventaire/reconnaissance du système
-> déploiement GSocket
-> gs-dbus / [kcached]
-> bot IRC Perl
-> possible élévation de privilèges root ou persistance
Il s'agit d'une chaîne dérivée d'incident, pas d'un comportement universel de la CVE. Dans l'ensemble de preuves assani, le téléchargement/exécution en tant que compte de service, un shell interactif, une configuration Nginx contrôlée par l'attaquant lancée en root, des processus root gs-dbus/[kcached], et une persistance root horaire sont directement corroborés. Les mécanismes exacts d'élévation de privilèges, la chronologie de déploiement JSP, chaque branche de charge utile, l'identité de l'opérateur et l'attribution restent des lacunes dépendantes des preuves. Voir docs/triage.md.
Ne publiez pas de preuves de victimes en direct ni d'échantillons de malware. Après validation interne et autorisation, des packages d'indicateurs défensifs peuvent être partagés avec Shadowserver. Les soumissions URLhaus doivent être limitées aux URL vérifiées indépendamment comme URL actives de distribution de malware ; les URL historiques ou non vérifiées ne doivent pas être soumises comme actives.
Tous les tests utilisent des fixtures statiques et n'effectuent aucune activité réseau :
make validate
Cela vérifie la syntaxe Bash, la cohérence du schéma IOC/CSV/JSON, la détection des fixtures, la sortie lisible par machine et l'hygiène du dépôt. shellcheck est utilisé lorsqu'il est installé.
Consultez CONTRIBUTING.md avant de proposer des indicateurs ou des changements de détection. Signalez les problèmes de sécurité en privé comme décrit dans SECURITY.md. Sous licence Apache-2.0 ; voir LICENSE.