Une faille critique de BeyondTrust Remote Support a été exploitée avant qu’un correctif soit disponible. Selon Google et Mandiant, le groupe d’espionnage présumé lié à la Chine, Armory Castle, s’en est servi pour prendre le contrôle d’appareils et accéder à des identifiants stockés ou traités par le produit.
1
12
Pour les organisations qui hébergent elles-mêmes Remote Support, l’enjeu ne se limite donc pas à installer la mise à jour : il faut aussi déterminer si l’appareil a été compromis avant sa correction.
12
Ce que permettait la faille
La vulnérabilité CVE-2026-102764, notée 9,3 selon CVSS 4.0, concernait les versions non corrigées de BeyondTrust Remote Support jusqu’à la 26.2.3.
2
3
18 Elle provenait d’une validation insuffisante de l’origine des messages dans un composant interne. Un attaquant distant, sans authentification, pouvait usurper l’identité d’un composant de confiance et effectuer des opérations sur les fichiers de l’appareil.
2
18
Google et Mandiant indiquent que les intrus ont exploité la faille pour accéder aux appareils, puis élever leurs privilèges jusqu’à obtenir un accès root au système hôte. Ce niveau de contrôle pouvait leur permettre d’atteindre des identifiants conservés ou relayés par le produit, et de s’appuyer sur l’appareil pour tenter d’accéder à d’autres systèmes du réseau.
1
3
12
Les éléments rapportés sur le groupe
Google et Mandiant attribuent l’activité à Armory Castle, un acteur auparavant suivi sous le nom UNC5221.
1 Certaines sources secondaires utilisent aussi le nom Warp Panda, mais les éléments disponibles ne permettent pas d’établir indépendamment l’origine de cette appellation.
4
Les comptes rendus de l’enquête mentionnent Sawfly, décrit comme un webshell PHP, et Bareclaw, un outil de tunnellisation SOCKS5. Ces outils s’inscrivent dans une activité visant à conserver un accès et à faciliter des déplacements depuis l’appareil compromis vers d’autres parties du réseau.
28
33 Les informations disponibles ne confirment pas tous les détails attribués à la campagne : les affirmations portant sur des fichiers précis dérobés ou sur la méthode exacte d’exfiltration doivent donc être considérées avec prudence.
Chronologie : exploitation, correctif et divulgation
Les informations publiées situent l’exploitation à la fin août 2026, avant la divulgation publique de la faille. Un compte rendu date les premières activités du 29 août et indique qu’elles concernaient une instance hébergée par BeyondTrust ainsi qu’un appareil autohébergé.
1
19
BeyondTrust a publié le correctif le 8 octobre, puis indiqué que ses environnements SaaS avaient tous été mis à jour au 9 octobre. L’entreprise a divulgué la vulnérabilité le 15 octobre, dans l’avis BT26-05.
1
7
Pour les installations autohébergées, le correctif BT26-05-RS concerne les versions 24.3.1 à 26.2.3. Les installations plus anciennes doivent d’abord être mises à niveau avant de pouvoir appliquer ce correctif.
1
Mesures à prendre
- Vérifiez vos installations et leurs versions. Recensez les appareils Remote Support autohébergés et déterminez s’ils utilisaient une version non corrigée, jusqu’à 26.2.3 inclus. Ne partez pas du principe qu’une installation autohébergée a reçu la mise à jour destinée aux environnements SaaS.
1
18
- Appliquez le correctif adapté. Suivez les instructions de BeyondTrust en tenant compte de la version installée et du chemin de mise à niveau éventuellement nécessaire.
1
- Recherchez des signes de compromission. Google et Mandiant recommandent de considérer les appareils autohébergés exposés comme potentiellement compromis, compte tenu de l’accès root rapporté, de l’exposition possible d’identifiants et du risque d’accès à d’autres systèmes.
12
- Évaluez les comptes et systèmes accessibles depuis l’appareil. L’examen ne devrait pas se limiter à l’appliance : il doit aussi prendre en compte les identifiants qu’elle traite et les systèmes auxquels elle pouvait donner accès.
3
12
Installer le correctif empêche l’exploitation de cette vulnérabilité connue, mais ne permet pas à lui seul de savoir si l’appareil a été compromis avant sa mise à jour. La correction et l’évaluation d’un incident doivent donc être envisagées comme deux étapes distinctes.
1
12