ZiChat Bot PyPI malware qui utilise Zulip comme C2 et rompt la sécurité de la chaîne d'approvisionnement

Les chercheurs en cybersécurité ont détecté une campagne de chaîne d'approvisionnement PyPI qui a distribué un nouveau malware, appelé ZiChatBot, à travers trois paquets qui semblaient légitimes mais cachés un mécanisme de livraison malveillant. L'innovation technique la plus frappante est l'utilisation des API publiques d'une application de chat d'équipe comme infrastructure de commande et de contrôle (C2), au lieu des serveurs traditionnels C2, ce qui rend difficile de détecter le trafic suspect vers des domaines privés.

Les paquets, qui ont déjà été retirés de PyPI après le rapport, ont été téléchargés dans une fenêtre courte en juillet 2025 et ont eu ensemble des milliers de téléchargements. Son comportement montre une tactique de plus en plus courante : petits projets avec des fonctionnalités apparemment inoffensives qui servent de passerelle pour les goutteurs natifs dans Windows et Linux. Sur la plate-forme Windows la charge utile place et charge une DLL appelée "terminate.dll", crée la persistance dans l'enregistrement et tente de supprimer les preuves; dans Linux l'équivalent est "terminate.so" planté dans "/ tmp / obsHub / obs-check-update" avec une entrée crontab pour la persistance. Le malware exécute shellcode reçu par REST et confirme l'exécution avec un emoji coeur vers son C2 dans Zulip.

Au-delà de comment ZiChat Bot fonctionne, l'épisode a des implications stratégiques: l'utilisation de services légitimes (comme Zulip ou, dans les campagnes précédentes attribuées à des groupes similaires, Notion) comme un canal de contrôle complique la réponse, parce que le trafic semble normal et les fournisseurs publics ne sont pas conçus pour agir comme une infrastructure de menace. Cela accroît le risque pour les environnements de développement et de déploiement qui acceptent des unités externes sans contrôle fort surtout lorsque ces unités contiennent des composants binaires ou des roues compilées.

L'attribution n'est pas confirmée, bien que les analystes aient mentionné des similitudes avec une goutteuse utilisée par l'acteur appelé OceanLotus (APT32). Si elle était confirmée, elle serait compatible avec la tendance du groupe à diversifier les vecteurs au-delà du phishing traditionnel et à utiliser les techniques de la chaîne d'approvisionnement pour en étendre la portée. Qui que soit l'auteur, le vecteur est pertinent: les attaquants perfectionnent l'abus des dépôts publics.

Pour les développeurs et les équipements de sécurité, cela signifie ajuster les processus et les contrôles techniques. Les recommandations pratiques comprennent l'audit des dépendances avant de les intégrer dans des projets productifs, la méfiance à l'égard de nouveaux paquets avec peu de téléchargements qui déclarent des dépendances inattendues, et l'examen de la présence de binaires ou de roues natifs dans les paquets. Outils d'audit de l'unité tels que Pip-audit aider à identifier les vulnérabilités connues, et la page de sécurité PyPI offre des lignes directrices et des mécanismes de rapport que vous devriez savoir: https: / / pypi.org / sécurité /.

D'un point de vue opérationnel, il existe des actions concrètes de détection et de récupération : rechercher et supprimer des fichiers indicateurs tels que "terminate.dll" et "terminate.so", consulter les entrées de démarrage automatique dans le registre Windows et les chronJobs sur les serveurs Linux, et surveiller les connexions sortantes vers les API Zulip ou d'autres services tiers. Il est également prudent de générer un SBOM pour les environnements critiques, de forcer l'examen humain des changements dans les unités CI / CD, et de mettre en oeuvre des politiques pour limiter l'exécution de binaires non signés.

Les organisations devraient également renforcer leur stratégie de gouvernance de l'ensemble : exiger des signatures et 2FA pour les propriétaires de paquets critiques, limiter les permis d'installation dans des environnements sensibles et appliquer une forte isolation dans les environnements de développement afin qu'une installation accidentelle ne compromette pas l'infrastructure de production. Les ressources sur les meilleures pratiques en matière de sécurité de la chaîne d'approvisionnement logicielle se trouvent dans le guide de la chaîne d'approvisionnement de la CISA : https: / / www.cisa.gov / chaîne d'approvisionnement.

Enfin, les gestionnaires de projet open source et les gestionnaires de dépôt doivent activer les mécanismes d'examen et les alertes aux paquets de code natif ou aux comportements inhabituels. La principale leçon est que la sécurité de la chaîne d'approvisionnement nécessite une surveillance continue: les attaquants migrent rapidement vers des vecteurs qui amplifient l'impact et camouflent le trafic malveillant au sein des services légitimes. La mise en place de contrôles préventifs et de capacités de détection précoce est désormais plus cruciale que jamais.