L’attaquant utilise un vrai logiciel de téléassistance : comment faire la différence ?

Le logiciel est connu, son installation semble normale et la personne au téléphone affirme travailler pour le support. Cela suffit-il à autoriser une prise en main ? Non : la légitimité d’un produit ne prouve ni l’identité de l’opérateur ni son droit à intervenir. La téléassistance doit être rattachée à une mission vérifiable.

Le fait récent : plusieurs accès pour conserver la main

Le 29 septembre 2026, Microsoft a publié une analyse de campagnes de phishing abusant de MSP360 RMM pour installer ScreenConnect et disposer de canaux d’accès redondants. Cette utilisation malveillante ne signifie pas que ces produits sont intrinsèquement malveillants ni que chaque installation est compromise. Lire l’analyse Microsoft.

Le sujet dépasse ces noms commerciaux. Beaucoup d’organisations utilisent une plateforme de gestion distante, parfois plusieurs à la suite de rachats, de migrations ou de contrats prestataires. Sans inventaire, l’équipe sécurité peut difficilement savoir si un nouvel agent correspond à un déploiement prévu ou à une prise de contrôle.

RMM et téléassistance : de quoi parle-t-on ?

RMM désigne la supervision et la gestion à distance. Selon le produit et sa configuration, un agent peut permettre de surveiller un poste, de déployer des logiciels, de lancer des actions d’administration ou d’ouvrir une session. Certaines fonctions restent disponibles sans qu’un utilisateur accepte chaque intervention.

La téléassistance interactive répond à un autre besoin courant : aider une personne à résoudre un problème. Les deux usages peuvent se recouper. Pour décider de ce qui est autorisé, il faut donc connaître les capacités effectivement activées. La présence d’une icône rassurante ou d’une signature numérique ne répond pas à cette question.

Trois preuves à demander avant une intervention

La première est l’identité de l’intervenant. Utilisez le numéro du support déjà enregistré ou le portail interne. Un appel entrant, même avec un nom affiché familier, ne suffit pas. La deuxième est le motif : un ticket, une demande attendue et un périmètre précis. La troisième est le moyen : outil approuvé, console de gestion connue et procédure de fin d’intervention.

Un salarié ne doit pas devoir analyser un certificat ou un nom de processus pour se protéger. L’organisation doit lui fournir une règle praticable : « Je confirme l’intervention par notre canal habituel avant d’installer un outil ou de partager mon écran. » Le support doit accepter cette vérification, même dans une situation pressante.

Ce que le SOC doit pouvoir distinguer

Une alerte « outil de téléassistance détecté » a peu de valeur sans contexte. Nous recommandons de rapprocher l’installation des changements planifiés, de l’identité qui l’a déclenchée, du poste et du rattachement de gestion. Une activité inhabituelle sur un serveur sensible demande un examen différent d’un déploiement annoncé sur des postes pilotes.

Les sources disponibles peuvent inclure l’inventaire logiciel, la création de services, les processus, les connexions réseau et les journaux de la console RMM. Leur présence et leur qualité doivent être vérifiées. Un agent déclaré installé dans un outil d’inventaire n’est pas nécessairement une preuve qu’il fonctionne ou qu’il appartient à la bonne organisation.

Testez une installation approuvée sur un poste de laboratoire et vérifiez sa visibilité de bout en bout. Le résultat attendu est une trace exploitable avec un responsable capable de conclure. Toute automatisation de blocage doit tenir compte des interventions légitimes et prévoir un retour contrôlé ; couper un accès de maintenance critique sans contexte peut créer un incident supplémentaire.

Réagir à une prise en main suspecte

Si vous êtes l’utilisateur, interrompez l’échange et contactez votre support par un moyen connu. Décrivez ce que vous avez installé, accepté ou montré. Suivez la procédure interne pour la déconnexion du poste. N’accordez pas une nouvelle session à la personne qui prétend venir corriger la première.

L’équipe de réponse doit limiter l’accès, préserver les traces utiles et établir les actions réalisées. Elle peut devoir examiner les comptes créés, les tâches planifiées, les outils supplémentaires et les ressources atteintes depuis le poste. Il faut également considérer les secrets affichés ou saisis pendant la session.

La désinstallation d’un agent ne suffit donc pas à conclure. Le dossier d’incident doit préciser les points d’entrée neutralisés et les vérifications de persistance effectuées. Quand la confiance dans le poste ne peut pas être rétablie, la reconstruction peut faire partie de la réponse décidée par les équipes compétentes.

Un contrôle à intégrer aux contrats prestataires

Demandez une liste explicite des outils autorisés et des consoles qui les administrent. Faites préciser les sous-traitants, la traçabilité, la durée des accès et la procédure d’urgence. L’entreprise doit savoir comment interrompre un accès sans dépendre d’un unique interlocuteur absent.

Lors d’une fin de mission, vérifiez aussi les agents de gestion distante. Révoquer un compte VPN ne supprime pas forcément un autre canal d’administration. Un inventaire partagé, une validation des changements et une revue périodique des exceptions apportent une protection plus concrète qu’une interdiction générale impossible à faire respecter.

Sources et références

Sources consultées le 19 octobre 2026. Les schémas et grilles de préparation sont des propositions pédagogiques de Kenawek, à adapter au contexte de l’organisation.

• Microsoft, abus des outils RMM, 29 septembre 2026