Quand les permissions d’assistance à distance deviennent un chemin d’attaque

Illustration TechiesJournal de la séquence décrite dans l’article. La plupart des ordinateurs apparaissent estompés, car les éléments disponibles n’établissent pas que chaque terminal a été atteint, et l’image ne montre pas combien l’ont été.

L’incident BeyondTrust d’août 2026 a montré comment des attaquants pouvaient se servir d’une plateforme d’assistance à distance compromise pour atteindre des systèmes internes au moyen de fonctions d’administration légitimes. Il illustre pourquoi sécuriser une plateforme de gestion à distance ne revient pas à sécuriser chacun des ordinateurs qu’elle gère.

L’attaquant n’a pas eu besoin d’exploiter chaque terminal

Les plateformes d’assistance à distance permettent aux équipes informatiques d’administrer des ordinateurs, de résoudre des problèmes et d’accéder à des systèmes dans toute l’organisation. Un technicien de support peut se connecter à l’ordinateur portable d’un employé, analyser la panne d’une application ou transférer un fichier de diagnostic. Un administrateur d’infrastructure peut utiliser la même plateforme pour gérer des serveurs.

Ces fonctions sont utiles parce que les organisations peuvent gérer l’accès à distance depuis un système central. Ce système devient aussi chargé de décider qui peut se connecter à quelles machines et quelles actions sont autorisées pendant une session.

En août 2026, des attaquants ont exploité une vulnérabilité de BeyondTrust Remote Support, une plateforme d’administration à distance destinée aux entreprises. Cette vulnérabilité, CVE-2026-102764, tenait à une validation insuffisante de l’origine des messages dans un composant interne, ce qui permettait, sous certaines conditions, des opérations non autorisées sur des fichiers. Source : BeyondTrust Security Advisory BT26-05.

La vulnérabilité offrait un premier point d’entrée dans les appliances concernées (les serveurs ou machines virtuelles qui exécutent la plateforme). Mais l’enquête de Mandiant a documenté autre chose que cette exploitation initiale.

Après avoir compromis la plateforme, les attaquants ont modifié des permissions d’administration de l’assistance à distance, ouvert des sessions vers des terminaux internes et utilisé la fonction de transfert de fichiers intégrée au produit pour obtenir des documents, notamment des inventaires logiciels.

Les accès aux terminaux examinés par l’enquête sont passés par la plateforme d’assistance à distance. Mandiant n’a pas fait état d’une vulnérabilité distincte exploitée sur chaque ordinateur de destination pour ouvrir ces sessions.

C’est le problème technique central : une fois maîtres d’une plateforme autorisée à accéder aux systèmes internes, les attaquants pouvaient détourner ses fonctions existantes de gestion à distance. Source : Google Threat Intelligence Group et Mandiant, ARMORY CASTLE Exploits BeyondTrust, 15 octobre 2026.

Pourquoi les plateformes d’assistance à distance portent une responsabilité de sécurité différente

Les plateformes d’assistance à distance se placent entre les administrateurs informatiques et les systèmes qu’ils gèrent. La plateforme authentifie le personnel de support, conserve les connexions d’accès à distance configurées et applique les permissions qui déterminent quels systèmes ce personnel peut atteindre.

Dans BeyondTrust Remote Support, un Jump Item représente une connexion d’accès à distance configurée vers un système. Un Jump Item contient ou référence les informations nécessaires pour établir cette connexion. Selon son type, il peut faire intervenir un Jump Client, un Jumpoint ou d’autres paramètres de connexion.

Les Jump Items peuvent être regroupés en Jump Groups, ce qui permet aux organisations de séparer les connexions par équipe, par site ou par responsabilité opérationnelle.

Prenons une organisation fictive avec deux groupes : les postes de travail des employés et les serveurs de production. Son équipe de support (help desk) peut être autorisée à se connecter aux postes de travail, tandis que l’accès aux serveurs de production est réservé aux administrateurs d’infrastructure. Les deux équipes peuvent s’authentifier avec succès sur la même plateforme Remote Support. Leur autorisation d’atteindre les systèmes gérés peut malgré tout différer.

Comment fonctionnent les permissions des Jump Items

BeyondTrust utilise des Jump Item Roles pour définir les actions que les utilisateurs peuvent effectuer avec les Jump Items. Ces permissions peuvent inclure le lancement de sessions, la création ou la suppression de Jump Items et la modification des paramètres de connexion ou des politiques associées.

L’accès effectif ne dépend pas forcément d’un seul paramètre. La documentation versionnée de BeyondTrust décrit des attributions de rôles par utilisateur individuel, par politique de groupe et par relation entre utilisateurs et Jump Groups. Lorsque plusieurs Jump Item Roles s’appliquent, l’attribution la plus spécifique l’emporte.

Par exemple, un rôle général d’utilisateur peut autoriser des opérations d’assistance à distance, tandis qu’une attribution plus spécifique pour un Jump Group donné restreint l’accès aux connexions de ce groupe. Pour établir l’accès effectif d’un utilisateur, un administrateur doit examiner les attributions applicables plutôt que de s’en tenir au rôle général de l’utilisateur.

Cet article emploie le terme Jump Item Roles, celui qui figure dans l’enquête de Mandiant et dans la documentation BeyondTrust Remote Support correspondante. Les organisations doivent interpréter les détails de configuration en fonction de la version et de l’édition du produit qu’elles ont installées. Source : BeyondTrust Remote Support v24.3, Jump Item Roles.

Lancer une session ne revient pas à contrôler le terminal

La permission de lancer une session d’assistance à distance n’est qu’une partie de l’autorisation. Un utilisateur peut être en mesure d’ouvrir une connexion tout en restant limité par la politique de session configurée. L’ordinateur cible a aussi ses propres privilèges de système d’exploitation et ses propres contrôles de sécurité.

Il faut donc distinguer trois permissions :

• La permission de se connecter à la plateforme Remote Support.
• L’autorisation d’ouvrir une session via un Jump Item donné.
• Les privilèges permettant d’effectuer des opérations sur l’ordinateur distant.

Les actions possibles pendant une session dépendent de la configuration de la connexion, des politiques applicables, des identifiants disponibles et des privilèges sur le terminal. Cette distinction compte pour interpréter l’intrusion.

Ce que les attaquants ont modifié dans Remote Support

L’intrusion a commencé par la compromission de l’appliance. Mandiant a documenté un webshell malveillant (un petit script qui permet à un attaquant d’exécuter des commandes sur un serveur via son interface web), une élévation aux privilèges root (le contrôle total du système d’exploitation de l’appliance) et des mécanismes destinés à conserver l’accès. Ces constats expliquent comment les attaquants ont pris le contrôle de l’environnement d’exécution de l’appliance.

L’étape suivante a visé l’application Remote Support elle-même. Mandiant a observé les attaquants utiliser des identifiants d’administrateur compromis pour accéder à son portail d’administration web. Les enquêteurs ont relevé un événement user_changed dans lequel deux champs de rôle ont changé :

Les champs de rôle modifiés dans l’événement user_changed relevé

Champ relevé	Rôle précédent	Nouveau rôle
Default Jump Item Role	No Access	Administrator
Teams Jump Item Role	No Access	Administrator

Les deux changements ont été enregistrés comme le passage de l’ID de rôle 1 à l’ID de rôle 3.

Il s’agit de champs distincts de la configuration Remote Support du compte. Il ne faut pas les confondre avec une attribution de rôle spécifique entre un utilisateur et un Jump Group.

Dans l’entrée de journal de Mandiant, les deux champs sont jump_item_role:default et jump_item_role:teams, et Mandiant décrit ce changement comme une élévation des permissions sur les Jump Items locaux et les équipes (Team). La page Jump Item Roles de la v24.3 ne décrit pas ces deux champs ; ils semblent donc correspondre à un paramètre de rôle général et à un paramètre lié aux équipes. D’autres attributions plus spécifiques peuvent toujours influer sur l’autorisation effective disponible pour une connexion donnée.

Les changements observés établissent donc que les permissions applicatives du compte administrateur ont été étendues. Ils ne prouvent pas, à eux seuls, un accès sans restriction à chaque Jump Item. Mandiant décrit ce changement comme l’octroi d’une autorisation permanente et sans restriction de lancer des sessions à distance vers les systèmes de la liste de Jump Items de l’appliance, et ce sont les sessions et les transferts de fichiers documentés qui prouvent ce qui a effectivement été fait.

Mandiant a ensuite observé les attaquants ouvrir des sessions d’assistance à distance vers des terminaux internes. Les éléments de preuve relient des changements réels de l’autorisation d’administration à l’utilisation ultérieure des fonctions d’accès à distance de la plateforme.

Les attaquants ne se contentaient plus de commandes exécutées via le système d’exploitation de l’appliance compromise. Ils utilisaient aussi l’application conçue pour administrer d’autres systèmes. Source : Mandiant, abus de sessions administrateur BeyondTrust.

Comment des sessions à distance légitimes sont devenues un chemin d’accès

Remote Support conserve des connexions vers les systèmes qu’une organisation a déjà configurés pour l’administration. Le personnel autorisé utilise ces connexions pour le dépannage, la maintenance et le transfert de fichiers.

Après les changements de permissions, Mandiant a observé les attaquants utiliser cette infrastructure pour atteindre des terminaux internes. Les attaquants ont tiré parti de la capacité de la plateforme de gestion à ouvrir des sessions, au lieu d’installer un mécanisme d’accès à distance distinct sur chaque machine cible.

Ce que les enquêteurs ont observé sur les terminaux internes

Mandiant a documenté des sessions d’assistance à distance vers des systèmes internes. Pendant ces sessions, les attaquants ont utilisé les fonctions intégrées de BeyondTrust pour demander l’accès au système de fichiers distant. Ils ont ensuite utilisé la fonction native de transfert de fichiers pour télécharger des documents sensibles, notamment des inventaires logiciels.

Il s’agit d’activités observées, et pas seulement de conséquences possibles de permissions élargies.

La fonction de transfert de fichiers était en elle-même légitime. Les équipes de support peuvent s’en servir pour collecter des journaux (logs), récupérer des éléments de diagnostic ou livrer les fichiers nécessaires au dépannage. Dans cet incident, un opérateur non autorisé a utilisé cette fonction pour sortir des informations de terminaux internes.

Le logiciel a rempli la fonction technique prévue. Le problème, c’est que l’opérateur qui l’utilisait n’était pas autorisé.

Ce que les preuves n’établissent pas

L’enquête ne démontre pas que chaque terminal enregistré dans l’inventaire de Jump Items de l’appliance a été atteint. Elle n’établit pas non plus que les attaquants ont obtenu des privilèges d’administrateur du système d’exploitation sur chaque terminal qu’ils ont atteint.

Les sessions, l’accès au système de fichiers et les transferts de documents observés démontrent une activité non autorisée en aval, sans qu’il soit nécessaire d’aller jusqu’à ces affirmations plus larges. L’accès par session à distance et le contrôle complet du système d’exploitation d’une cible restent deux constats différents.

Les quatre frontières de sécurité en jeu

L’incident a touché plusieurs couches de contrôle, chacune avec une responsabilité différente.

Les quatre frontières de sécurité en jeu dans l’incident

Frontière de sécurité	Ce qu’elle régit	Portée observée
Hôte de l’appliance	Fichiers, services et privilèges du système d’exploitation	Les attaquants ont obtenu un accès de niveau root
Administration de Remote Support	Comptes, rôles et configuration de l’application	Les attaquants ont étendu des permissions d’administration
Session à distance	Connexions et activités de support autorisées	Les attaquants ont ouvert des sessions et transféré des fichiers
Terminal cible	Privilèges locaux et contrôles de sécurité du terminal	Des terminaux internes ont été atteints. Une compromission administrative généralisée n’a pas été établie

Compromettre une frontière peut ouvrir des possibilités d’abuser d’une autre. Cela ne prouve pas automatiquement que toutes les autres frontières ont aussi cédé.

Dans ce cas, Mandiant a documenté à la fois des changements de permissions d’administration et l’utilisation ultérieure des fonctions d’assistance à distance. C’est ce qui établit le lien entre la compromission de l’appliance et l’activité non autorisée sur les systèmes internes.

Une voie distincte à travers l’appliance

Les enquêteurs ont aussi découvert une voie qui ne dépendait pas des sessions Remote Support ordinaires. Mandiant a identifié BARECLAW, un outil de tunnelisation réseau sur mesure installé sur l’appliance compromise. L’outil pouvait relayer du trafic réseau via un proxy SOCKS5 transporté sur des connexions WebSocket, une façon de faire passer des connexions réseau relayées par une connexion web.

Les attaquants ont aussi modifié la configuration HAProxy de l’appliance. HAProxy est un proxy inverse : il reçoit les requêtes entrantes et les transmet à des services internes configurés. En modifiant ses règles de routage, les attaquants ont dirigé les requêtes arrivant par un chemin web désigné vers le composant de tunnelisation. Cela offrait une autre voie de communication à travers l’appliance compromise.

Selon notre lecture, contrairement à une connexion Remote Support normale, ce trafic ne dépendait pas du lancement d’une session par un opérateur via un Jump Item.

Cette différence compte lors de l’enquête sur l’activité. Les enregistrements de session de l’application peuvent établir quelles connexions gérées ont été utilisées dans les processus Remote Support habituels. Mais, selon notre lecture, le trafic qui passe par un outil de tunnelisation installé par l’attaquant peut ne pas apparaître comme une session d’assistance ordinaire.

Mandiant a documenté les deux mécanismes. Ses conclusions publiques n’établissent pas qu’ils ont atteint le même ensemble de terminaux. Source : Mandiant, constats sur BARECLAW et HAProxy.

Ce que les organisations peuvent vérifier après ce type de compromission

L’enquête BeyondTrust offre une méthode pratique pour retracer les conséquences de permissions d’assistance à distance non autorisées. Le point de départ n’est pas seulement de savoir si l’appliance était vulnérable. C’est ce qui a changé dans l’application de gestion, et ce qui s’est passé ensuite.

D’abord, établir le changement d’administration.

Examinez les comptes concernés, les Jump Item Roles, les attributions de Jump Groups et les politiques de groupe. Identifiez le compte à l’origine du changement, les permissions modifiées et si l’action avait un objectif opérationnel autorisé. Dans l’incident étudié, les preuves clés comprenaient un événement user_changed montrant deux champs de rôle passés de No Access à Administrator.

Ensuite, établir quelles sessions ont suivi.

Examinez les terminaux atteints, les identités à l’origine de ces connexions et leur chronologie par rapport aux changements de permissions inattendus. Un changement de rôle ne prouve pas qu’une session à distance a eu lieu. Les preuves de session fournissent le maillon suivant.

Puis examiner ce qui s’est produit pendant ces sessions.

Les enregistrements utiles peuvent porter sur l’accès au système de fichiers, les transferts de fichiers natifs et l’activité de configuration des sessions. L’enquête de Mandiant a relié des sessions à distance à des transferts de documents observés.

Enfin, identifier les terminaux qui nécessitent une investigation.

Un terminal qui figure dans l’inventaire de la plateforme n’est pas automatiquement compromis. En revanche, un terminal atteint par une session non autorisée devient pertinent pour l’enquête et doit être évalué à l’aide des enregistrements d’activité disponibles et des preuves recueillies sur le terminal.

Le parcours d’investigation qui en résulte est le suivant :

Changement de rôle inattendu → session à distance → accès ou transfert de fichiers → terminal touché.

Il s’agit d’une manière de relier les preuves. Elle ne suppose pas que chaque étape s’est produite dans chaque environnement.

L’activité au niveau de l’hôte doit aussi être examinée lorsque l’appliance elle-même a été compromise. Dans l’incident BeyondTrust, les attaquants ont supprimé des fichiers journaux et mis en place un mécanisme de tunnelisation distinct. Les enregistrements conservés uniquement sur l’appliance compromise peuvent donc être incomplets.

Des journaux collectés de manière indépendante, la télémétrie des terminaux et les enregistrements réseau peuvent aider à corroborer les constats, sans qu’aucune de ces sources soit réputée offrir une visibilité complète.

Corriger la vulnérabilité initiale traite le point d’entrée documenté. Cela n’établit pas quelles connexions de support légitimes un attaquant a utilisées auparavant. La question plus large de la remise en état est abordée dans un article connexe de TechiesJournal, « Corrigé » ne veut pas dire « sain » : que faire après la correction d’un équipement de bordure exploité (en anglais).

L’objectif ici est plus étroit : comprendre quelles permissions de gestion à distance ont changé, quelles connexions ont été utilisées et ce qui s’est passé sur les systèmes que ces connexions ont atteints.

La frontière de sécurité va au-delà du serveur de gestion

Les plateformes d’assistance à distance sont utiles parce qu’elles offrent aux organisations un moyen central d’administrer de nombreux systèmes. Leurs contrôles d’accès déterminent qui peut utiliser ces connexions et quelles activités sont autorisées.

L’enquête BeyondTrust a montré comment des attaquants ayant compromis la plateforme de gestion pouvaient aussi abuser de ces fonctions légitimes. Mandiant a documenté des changements de rôles d’administration, des sessions d’assistance à distance non autorisées et l’utilisation du transfert de fichiers natif pour obtenir des informations depuis des terminaux internes. Les enquêteurs ont aussi trouvé une voie de tunnelisation réseau distincte à travers l’appliance compromise.

La leçon n’est pas que les outils d’assistance à distance sont dangereux par nature.

C’est que la sécurité des terminaux gérés dépend en partie de l’intégrité de la plateforme autorisée à s’y connecter.

Lorsque cette plateforme est compromise, l’examen du seul serveur de gestion ne permet pas d’en établir les conséquences. Les organisations doivent aussi déterminer quelles permissions ont changé, quelles sessions ont été ouvertes et ce qui s’est passé sur les systèmes que ces sessions ont atteints.

Pour aller plus loin

Recherches examinées le 21 octobre 2026 et revérifiées le 22 octobre 2026. Cet article porte sur l’autorisation dans l’assistance à distance et l’accès en aval, plutôt que sur l’ensemble du processus de réponse aux vulnérabilités.

Sources de l’enquête et de l’éditeur

• ARMORY CASTLE Exploits BeyondTrust, Google Threat Intelligence Group et Mandiant, 15 octobre 2026 : l’enquête d’origine, qui décrit les changements d’administration, les sessions d’assistance à distance, les transferts de fichiers et la tunnelisation.
• BeyondTrust Security Advisory BT26-05, BeyondTrust, 15 octobre 2026 : description officielle de la vulnérabilité, versions concernées et mesures d’atténuation pour CVE-2026-102764.
• ARMORY CASTLE and BT26-05: What Security Teams Need to Know, BeyondTrust, 15 octobre 2026 : enquête de l’éditeur, chronologie de la réponse et informations de confinement.
• BeyondTrust Remote Support v24.3, Jump Item Roles, documentation produit de BeyondTrust, consultée le 21 octobre 2026 : explique l’accès aux Jump Items, l’attribution des rôles et leur ordre de priorité. L’intrusion observée est établie séparément par Mandiant.

Les organisations qui évaluent leur exposition possible doivent consulter les avis de sécurité BeyondTrust en vigueur et leurs propres procédures de réponse aux incidents. L’intrusion documentée publiquement n’établit pas que chaque installation ou chaque terminal géré a été compromis.

À lire aussi sur TechiesJournal

• « Corrigé » ne veut pas dire « sain » : que faire après la correction d’un équipement de bordure exploité (en anglais), TechiesJournal, octobre 2026 : analyse connexe expliquant pourquoi corriger une vulnérabilité ne fait pas automatiquement disparaître une compromission existante.
• Quand une application cloud de confiance devient un chemin d’attaque (en anglais), pour un autre cas où des attaquants ont utilisé l’accès légitime d’une application de confiance au lieu d’attaquer chaque cible.