CVE-2025-20393 est un problème de sécurité de gravité maximale lié aux déploiements de Cisco AsyncOS dans les pays suivants Passerelle Cisco Secure Email Gateway (SEG) et Cisco Secure Email and Web Manager (SEWM). Le risque principal n'est pas subtil : les attaquants peuvent exécuter des commandes système arbitraires avec les privilèges de l'administrateur (root) sur les appareils concernés, et il est prouvé qu'il s'agit d'un problème de santé publique. déjà exploitées dans la nature. (NVD)
Du point de vue d'un défenseur, cela se situe au pire endroit possible. Les appliances SEG/SEWM ont tendance à être fiables, semi-opaques et opérationnellement "spéciales" - elles sont souvent patchées plus lentement que les serveurs de base, surveillées de manière moins complète et bénéficient d'une large portée dans les flux de courrier et les réseaux de gestion. Lorsqu'un appareil périphérique devient un hôte contrôlé par un attaquant, il ne s'agit pas simplement d'un autre incident de point d'extrémité, mais d'un point de pivot.
Cet article se concentre sur ce qui est réellement important pour les ingénieurs en sécurité purs et durs : les conditions d'exposition, le savoir-faire après la compromission, les idées de détection des signaux élevés et les mesures de confinement pragmatiques que vous pouvez exécuter même lorsqu'un correctif n'est pas encore disponible.
Quel type de vulnérabilité est CVE-2025-20393 ?
Au niveau de la classification, la NVD enregistre CVE-2025-20393 en tant que CWE-20 : Validation incorrecte des données d'entrée, avec un Vecteur de base CVSS v3.1 indiquant une attaque par le réseau, sans privilèges requis, sans interaction de l'utilisateur et avec un impact total sur la compromission. (NVD)
En termes pratiques, de nombreuses sources résument l'impact comme suit : exécution de commandes à distance, sans authentification, avec les privilèges de l'administrateur (root) sur le système d'exploitation sous-jacent d'un appareil concerné. (Blog de Cisco Talos)
NVD présente également une mise à jour de CISA KEV : Date d'ajout : 2025-12-17 ; Date d'échéance : 2025-12-24ainsi que les actions requises pour appliquer les mesures d'atténuation du fournisseur ou cesser l'utilisation si les mesures d'atténuation ne sont pas disponibles. (NVD)
Produits concernés et conditions réelles d'exposition
La nuance qui importe : alors que les versions d'AsyncOS sont largement impliquées, l'exploitation observée est concentrée dans une version d'AsyncOS. sous-ensemble limité d'appareils avec configurations non standard-spécifiquement où Quarantaine de spams est activé et exposé à l'internet. (BleepingComputer)
Plusieurs rapports soulignent que La quarantaine de spam n'est pas activée par défautet les guides de déploiement n'exigent pas que le port associé soit exposé à l'internet, ce qui signifie que de nombreux environnements ne deviendront vulnérables qu'à la suite de choix de configuration, de dérives ou d'une exposition "temporaire" devenue permanente pour des raisons de commodité. (Help Net Security)
Si vous devez trier l'impact, ne devinez pas. Votre première tâche consiste à répondre à deux questions à l'aide de preuves :
- Utilisons-nous SEG ou SEWM (physique ou virtuel) ?
- Spam Quarantine ou l'interface de gestion web sont-ils accessibles depuis des réseaux non fiables ?
Si la réponse à ces deux questions est "oui", traitez l'affaire comme un incident jusqu'à preuve du contraire.
Pourquoi cette CVE est dangereuse d'un point de vue opérationnel : chaîne d'intrusion et outils observés
Cisco Talos attribue l'activité (avec confiance modérée) à un acteur de la menace de type chinois qu'ils identifient comme étant UAT-9686et note que la campagne est en cours depuis au moins deux ans. fin novembre 2025Cisco a pris conscience de l'importance de la 10 décembre 2025. (Blog de Cisco Talos)
Ce qui intéresse le défenseur, c'est ce qui se passe après l'accès initial. Talos décrit une chaîne d'outils conçue pour la persistance, le tunneling et la lutte contre la criminalistique :
- AquaShell: une porte dérobée légère en Python intégrée dans un fichier existant au sein d'un serveur web basé sur Python. Il écoute passivement les POST HTTP non authentifié qui contiennent des données spécialement élaborées, décode le contenu et exécute des commandes dans le shell du système. Talos indique qu'il est placé à
/data/web/euq_webui/htdocs/index.py. (Blog de Cisco Talos) - AquaPurge: supprime les lignes de journal contenant des mots-clés spécifiques dans les fichiers journaux spécifiés, à l'aide de
egrepfiltrer le style pour garder des lignes "propres" et les écrire en retour. (Blog de Cisco Talos) - AquaTunnel: un binaire Go compilé basé sur ReverseSSHutilisé pour créer une connexion SSH inversée vers l'infrastructure de l'attaquant. (Blog de Cisco Talos)
- Ciseau: outil de tunnelage open-source prenant en charge les tunnels TCP/UDP sur une connexion unique basée sur HTTP, utile pour le proxy et le pivotement par le biais d'un dispositif périphérique. (Blog de Cisco Talos)
Ce point est important car il modifie votre position de réponse. Lorsque le cahier des charges de l'acteur comprend des implants de persistance et la manipulation des journaux, vous devez supposer une cécité partielle des journaux locaux et prévoir de vous fier à télémétrie externe (journaux de pare-feu, journaux de proxy, NetFlow, journaux DNS) pour vérifier si l'appareil a communiqué avec l'infrastructure de l'attaquant.

Les COI à signaux élevés et ce qu'il faut en faire
Talos a publié des exemples de hachages SHA-256 pour des outils (AquaTunnel, AquaPurge, Chisel) et un petit ensemble d'adresses IP associées à la campagne, et renvoie à un dépôt GitHub pour l'ensemble des CIO. (Blog de Cisco Talos)
L'approche pratique d'un ingénieur consiste à traiter les COI comme des accélérateurs de triage rapideet non une preuve définitive :
- Résultat positif sur le hash de l'outil ou l'IP connue : escalade immédiate, conservation des preuves, ouverture d'un dossier fournisseur et planification de la reconstruction/restauration.
- Résultat négatifLe fait de ne pas être en mesure d'effectuer des contrôles de comportement et d'intégrité (parce que les acteurs changent d'infrastructure et qu'AquaShell peut ne pas être identique au niveau du hachage pour toutes les victimes) n'est pas une raison suffisante pour vous dédouaner. (Blog de Cisco Talos)
Vous trouverez ci-dessous des exemples de contrôles "sûrs" que vous pouvez effectuer sans déclencher d'exploitation.
1) Contrôle de l'intégrité des fichiers (point de départ)
# Vérifier l'horodatage et les permissions pour le fichier de l'interface web mentionnée par Talos
stat /data/web/euq_webui/htdocs/index.py
# Hacher le fichier et le comparer à votre ligne de base connue (si vous en avez une)
sha256sum /data/web/euq_webui/htdocs/index.py
# Si vous conservez des sauvegardes/des instantanés de configuration, comparez les versions
diff -u /path/to/known-good/index.py /data/web/euq_webui/htdocs/index.py || true
Talos désigne explicitement ce chemin comme l'emplacement où AquaShell est placé. (Blog de Cisco Talos)
2) Balayage du COI sortant dans les journaux externes (recommandé)
# Exemple : grep pour les IP connues dans les journaux exportés (remplacez les chemins par votre télémétrie)
grep -RIn --binary-files=without-match \N -e "172\N.233\N.67\N.176|172\N.237\N".
-E "172\\.233\\.67\\.176|172\\.237\\.29\\.147|38\\.54\\.56\\.95"
/var/log 2>/dev/null | head -n 200
Les adresses IP ci-dessus sont publiées par Talos comme étant associées à la campagne. (Blog de Cisco Talos)
3) Chasse "POST inhabituel" (meilleur effort, ne pas surcharger)
# Recherche de l'activité POST du web touchant le modèle de chemin mentionné (si des journaux existent)
-E "POST|/euq_webui/|/htdocs/index\\.py" \N- /var/log 2>/dev/null | /var/log 2>/dev/null | /var/log 2>/dev/null
/var/log 2>/dev/null | head -n 200
Selon Talos, le comportement d'AquaShell repose sur des requêtes HTTP POST non authentifiées transportant un contenu de commande codé. (Blog de Cisco Talos)
Exposition et priorité : un tableau de décision prêt à être utilisé sur le terrain
| Situation | Probabilité de compromis | Priorité | Action immédiate |
|---|---|---|---|
| Quarantaine de spams activée et internet accessible | Très élevé | P0 | Supprimer l'exposition dès maintenant ; suivre les mesures d'atténuation des vendeurs ; chasser les COI |
| Interface de gestion web accessible par internet | Haut | P0 | Supprimer l'exposition dès maintenant ; restreindre aux hôtes de confiance/VPN ; conservation des journaux |
| Non exposé à l'internet, mais accessible à partir de vastes réseaux de partenaires/fournisseurs | Moyen | P1 | Réduire la portée de l'ACL ; valider la segmentation ; rechercher les anomalies |
| Entièrement interne, strictement limité, contrôles administratifs stricts | Plus bas | P2 | Suivi des mises à jour des avis ; intégrité de base ; renforcement des contrôles |
Cet ordre de priorité correspond au consensus public : l'exploitation est observée principalement dans les endroits suivants La quarantaine de spams est activée et exposée et en configurations non standard. (BleepingComputer)
Atténuations lorsqu'il n'y a pas encore de correctif
En date du résumé de runZero (mis à jour le 17 décembre 2025), il n'y a actuellement pas de version corrigée disponibleet le fournisseur recommande de désactiver la fonction Quarantaine de spams et en isolant les systèmes vulnérables derrière des contrôles d'accès au réseau. (runZero)
La couverture de BleepingComputer décrit également Cisco conseillant aux administrateurs de restreindre l'accès (limiter l'accès à l'internet, restreindre aux hôtes de confiance, placer les appareils derrière des pare-feu), ainsi que l'hygiène opérationnelle comme la conservation des journaux, la séparation des fonctions de traitement du courrier et de gestion, et l'utilisation de méthodes d'authentification fortes. (BleepingComputer)
L'objectif stratégique est simple : réduire la surface d'attaque plus rapidement que l'attaquant ne peut l'analyser et l'exploiter.
Une séquence d'atténuation pratique que les équipes peuvent mettre en œuvre dès aujourd'hui :
- Supprimer l'exposition à l'internet à Spam Quarantine et à toutes les surfaces de gestion.
- Restreindre l'accès à la gestion à une liste d'autorisation restreinte (VPN + bastion uniquement).
- Des rôles distinctsLe plan de gestion ne doit pas être le même plan d'exposition que le traitement du courrier. (BleepingComputer)
- Conserver les journaux et la télémétrie externe avant de faire pivoter quoi que ce soit - Talos documente l'outil de purge des billes (AquaPurge), il faut donc supposer que les artefacts locaux peuvent être incomplets. (Blog de Cisco Talos)
- Exécuter des contrôles d'intégrité sur le chemin de l'interface web mentionné par Talos et rechercher l'outil tunnel. (Blog de Cisco Talos)
- Si vous avez des indicateurs de compromis, ouvrir un dossier Cisco TAC (Cisco et la couverture recommandent cette voie pour la validation des compromis et la réponse). (BleepingComputer)
Reconstruction ou "nettoyage sur place" : soyez honnête sur la réalité de l'électroménager
Les ingénieurs en sécurité détestent le mot "reconstruction" parce qu'il est perturbateur, mais les dispositifs périmétriques sont uniques : lorsque la persistance est intégrée dans les composants web et que l'intégrité des journaux est suspecte, vous pouvez passer des jours à "nettoyer" et toujours laisser une porte dérobée derrière vous.
Les rapports publics font état de la position de Cisco selon laquelle, en cas de compromission confirmée, la reconstruction des appareils est actuellement la seule option viable pour supprimer le mécanisme de persistance. (Help Net Security)
Traiter les termes "atténué" et "éradiqué" comme des états différents. L'atténuation ferme la porte. L'éradication prouve que l'attaquant n'est plus à l'intérieur.
Où les flux de sécurité pilotés par l'IA peuvent-ils être utiles ?
Si votre environnement comporte plusieurs instances SEG/SEWM dans différentes régions, la partie la plus difficile est rarement l'atténuation elle-même - c'est la coordination et la trace des preuves : quelles instances sont exposées, quels boutons de configuration ont été modifiés, quels journaux ont été conservés, si les connexions sortantes correspondent aux CIO publiés, et à quoi ressemble la posture de sécurité finale.
C'est là qu'une plateforme pilotée par l'IA peut réellement apporter une valeur ajoutée sans prétendre être magique :
- Automatiser la vérification de l'exposition ("la quarantaine de spam est-elle accessible depuis des réseaux non fiables ?") selon un calendrier précis
- Convertir les IOC publiés en chasses répétées à travers le SIEM, les journaux de pare-feu et la télémétrie des points d'accès.
- Produire un rapport d'incident fondé sur des preuves, auquel le RSSI et l'ingénieur peuvent faire confiance
Si vous utilisez déjà Penligent pour l'automatisation de la sécurité, la solution est simple : construire un runbook répétable qui valide les éléments suivants vérification de la configuration, de la joignabilité et de la télémétrie et émet un ensemble structuré de preuves pour la RI. Le meilleur résultat n'est pas l'"exploitation de l'IA", mais la réduction des angles morts et la prise de décisions plus rapides et plus sûres.
Références
https://nvd.nist.gov/vuln/detail/CVE-2025-20393
https://www.cve.org/CVERecord?id=CVE-2025-20393
https://blog.talosintelligence.com/uat-9686
https://www.runzero.com/blog/cisco-secure-email-gateway
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
https://cwe.mitre.org/data/definitions/20.html
https://github.com/Fahrj/reverse-ssh

