Si vous venez d’apprendre qu’un outil d’assistance pourrait avoir été le point d’entrée de l’attaquant, la première heure détermine ce que vous pouvez préserver, l’ampleur que vous pouvez limiter et si vous conservez des options forensiques. Cet article fournit un playbook concis et priorisé pour la réponse aux incidents d’accès distant durant cette première heure — quoi faire, quoi collecter et quelles décisions comptent.

À qui cela s’adresse et ce que cet article apporte

Rédigé pour les équipes IT, SOC et les gestionnaires d’incidents qui exploitent déjà des outils de support à distance (TeamViewer, AnyDesk, RDP, Tenvo, etc.). Ce n’est pas un manuel forensic complet — c’est une checklist opérationnelle, courte, à exécuter durant la première heure lorsque le canal de support est le vecteur suspect. Vous y trouverez une séquence de triage priorisée, des artefacts concrets à capturer, des contrôles indicateurs rapides, des actions de confinement qui évitent de détruire des preuves, et une checklist de communication concise.

Triage immédiat : checklist priorisée (0–60 minutes)

Ne paniquez pas ; agissez dans l’ordre. La rapidité compte plus que l’ingéniosité. Suivez les étapes dans l’ordre — sauter la préservation pour bloquer immédiatement tout rend les investigations plus difficiles.
Identifiez les sessions et utilisateurs suspectés. Qui a initié la session de support ? Quel compte, nom d’utilisateur ou appareil technicien apparaît dans les journaux du support ? Notez les horodatages (UTC) et les session IDs avant de modifier quoi que ce soit.
Préservez d’abord les journaux et preuves. Récupérez les journaux du serveur d’accès distant, les journaux de relais et tout enregistrement de session. Si l’outil est géré dans le cloud, exportez immédiatement les journaux depuis la console d’administration. Au besoin, prenez un instantané du système support (mémoire, disque) après l’export.
Isoler, ne pas détruire. Mettez l’endpoint compromis en quarantaine du reste du réseau (VLAN, port de switch ou blocage via firewall hôte) mais évitez d’éteindre sauf si nécessaire. Vous voulez préserver les processus, la mémoire et les connexions réseau ouvertes pour l’analyse forensic.
Bloquez l’accès supplémentaire de façon sélective. Révoquez ou désactivez le compte de support spécifique ou l’empreinte d’appareil utilisée par la session suspecte. Ne révoquez pas massivement tous les comptes de support sauf si vous acceptez l’impact opérationnel.
Renouvelez les identifiants et secrets exposés à cet appareil. Changez les mots de passe, les API keys et les comptes de service auxquels l’hôte compromis ou la session avait accès — mais consignez précisément chaque changement pour les enquêteurs.
Prévenez les parties prenantes et créez un canal d’incident. Informez votre responsable incidents, le service juridique/compliance et le CISO. Utilisez un canal d’incident pré-approuvé (chat ou ticket) et désignez un incident commander unique pour éviter les actions dupliquées.

Que collecter et préserver (liste d’éléments de preuve)

Collecter les bons artefacts dans la première heure préserve les options pour déterminer la cause racine et l’ampleur. Priorisez les exports que vous pouvez faire à distance et de façon non-destructive.

Journaux du logiciel d’accès à distance : horodatages d’ouverture/fermeture de session, session IDs, IPs des pairs connectés, IDs utilisateur/appareil, indicateur d’utilisation de relais, et tout enregistrement de session.
Journaux d’authentification : journaux IdP, journaux de push/ticket MFA, et tout journal SSO montrant l’activité du compte de support horodatée avec les événements de session.
Journaux et mémoire de l’endpoint : Windows Event Log (Security and System), Linux /var/log/auth.log et syslog, listes de processus, et image mémoire si possible.
Captures réseau : PCAPs depuis le port de switch de l’endpoint, le firewall en amont ou un TAP. Capturez au moins 60–120 seconds autour des horaires de session connus si une capture continue n’est pas disponible.
Journaux d’audit du relais/fournisseur : si la session est passée par un relais géré, exportez les journaux de connexion du fournisseur de relais et les régions/POPs utilisés.
Copies de configuration et politiques : configuration actuelle de l’outil de support, listes de contrôle d’accès, appartenances de groupe, comptes admin locaux et changements de politiques récents.

Win: wevtutil qe Security /q:"*[System[(EventID=4624)]]" /f:text > log_4624.txt
Linux: sudo journalctl --since '2026-10-13 09:00:00' --until '2026-10-13 10:00:00' > auth-window.log
Network: sudo tcpdump -i any -s 0 -w suspect.pcap host 198.51.100.23

Comment déterminer si l’outil de support a été le point d’entrée

Une session de support suspecte n’équivaut pas systématiquement à une compromission initiale. Ces contrôles aident à établir si la session était un outil post‑compromis, le vecteur initial, ou une négligence bénigne.

Horaire de la session vs heure de détection. Si la session a démarré avant la première détection (alerte AV, création de compte, ou processus suspect), elle est plus susceptible d’avoir été le vecteur.
Anomalies d’identifiants. Recherchez de nouvelles empreintes d’appareil, de nouvelles API keys, ou un compte de support créé récemment. Vérifiez si la session a utilisé SSO ou un utilisateur/mot de passe direct et si le MFA a été contourné ou non utilisé.
Relais vs connexion directe pair-à-pair. Déterminez si le client s’est connecté en peer-to-peer (NAT hole-punch) ou via un relais. Avec la plupart des outils, un fallback vers un relais signifie que le point de terminaison du relais a une visibilité sur le trafic de session — capturez ces journaux de relais et les endpoints de connexion.
Activité latérale concurrente. Si la session de support corrèle avec des connexions latérales, escalades de privilèges ou vol d’identifiants dans les minutes qui suivent, la session a probablement joué un rôle dans le mouvement de l’attaquant.
Signes d’abus de l’outil. Cherchez l’utilisation de CLI, des transferts de fichiers initiés pendant la session, le démarrage de shells à distance, ou des commandes téléchargeant des exécutables. Ce sont des indicateurs clairs.

Actions de confinement qui préservent les preuves

Le confinement durant la première heure est un compromis : il faut arrêter l’activité de l’attaquant sans détruire des preuves volatiles. Privilégiez des actions ciblées et réversibles.

Désactivez précisément le compte de support ou le certificat d’appareil. La plupart des outils permettent de révoquer un certificat client ou de désactiver un utilisateur. Révoquez la crédential compromise plutôt que de réinstaller ou d’effacer l’endpoint.
Bloquez le trafic de contrôle à distance vers/depuis l’endpoint au bord du réseau. Appliquez une ACL ou une règle de microsegmentation ciblée sur l’IP de l’endpoint et les IPs de relais connues de l’outil. Ne nettoyez pas l’hôte pour l’instant.
Quarantaine des hôtes affectés. Déplacez-les vers un VLAN isolé ou coupez leur uplink. Conservez un chemin de gestion si vous devez encore exécuter des commandes forensic.
Préservez le disque et la mémoire si vous suspectez un malware actif. Si une mémoire vive vivante est nécessaire, effectuez un RAM dump maintenant. Sinon, prenez au moins une image disque avant toute réinstallation.
Renouvelez les crédentiels en consignant les actions. Faites tourner les secrets des services affectés mais journalisez chaque changement de façon claire. Les enquêteurs ont besoin d’une chronologie des changements et des raisons.

Communications : qui prévenir, et que dire

Des communications claires et rapides réduisent la confusion. Utilisez votre matrice de notification d’incident et gardez les messages factuels et courts. Évitez les formulations spéculatives ("nous avons été compromis") tant que ce n’est pas confirmé.

Interne : responsable incidents, SOC, IT ops, juridique/protection des données, RH (si des données d’employés sont impliquées) et votre sponsor exécutif.
Externe : contact support du fournisseur de relais géré ou du SaaS (ouvrez un ticket d’incident et exportez les journaux), prestataires gérés, et votre conseil en cas de violation si des données réglementées peuvent être affectées.
Clients : uniquement après avoir défini l’ampleur. Préparez des modèles pré-approuvés pour "nous enquêtons" et pour les notifications post-mitigation conformes aux exigences réglementaires.
Régulateurs : si vous êtes soumis à des obligations de notification (GDPR, HIPAA, PCI), informez rapidement le service juridique et respectez vos délais de notification.

Décidez vite : relais géré vs auto‑hébergement pour la reprise

Si l’incident montre que l’opérateur du relais pouvait voir le trafic de session, cela affecte le risque et les preuves. Pour la plupart des équipes, un relais géré (Tenvo’s multi-region managed relay by default) est le bon choix : il supprime la maintenance d’astreinte des relais, centralise les journaux et fournit un basculement multi‑région. Tenvo propose des clients natifs pour Windows/macOS/Linux, un client navigateur en beta publique, et un relais géré avec des paliers Free $0 / Lite $2.99/mo / Pro $7.99/mo.

L’auto‑hébergement n’est approprié que si vous avez une exigence écrite interdisant l’infrastructure tierce (résidence des données, règle de conformité ou réseau isolé). L’auto‑hébergement ajoute un coût opérationnel : vous devenez responsable de la disponibilité du relais, du renouvellement des certificats, de la garde des clés et des patchs. Si vous envisagez l’auto‑hébergement après un incident, lisez les compromis de l’auto‑hébergement dans Bureau à distance auto-hébergé : le guide honnête 2026 avant de vous engager.

Vérifications techniques et commandes à exécuter ensuite (indicateurs rapides)

Ces contrôles rapides fournissent des indicateurs immédiats d’activité d’attaquant. Exécutez-les depuis l’endpoint (si c’est sûr) ou depuis une station forensic avec une image préservée.

Windows : Event IDs — Authentication : 4624 (logon), 4625 (failed logon), 4672 (special privileges), 4688 (process creation). Vérifiez les journaux PowerShell pour des scripts suspects (4104) et Sysmon (si déployé) pour des processus parents distants.
Linux : sudo /var/log/auth.log pour les sessions sudo/ssh ; vérifiez la liste des processus (ps auxww) et last -f /var/log/wtmp pour les connexions récentes.
Réseau : tcpdump ou tshark pour les connexions entre l’endpoint et les IPs de relais connues. Recherchez des transferts sortants inhabituels, du DNS via des résolveurs non classiques, et des sessions TLS persistantes.
Artefacts applicatifs : session IDs de l’outil de support, journaux de transfert de fichiers, et entrées de transfert clipboard. Exporte z‑les avant de désinstaller le client.

Après le confinement : remédiation et durcissement (24–72 heures suivantes)

Une fois que vous avez contenu et capturé les preuves, exécutez la remédiation et supprimez les persistances de l’attaquant.

Réimagez les hôtes affectés à partir d’une image « golden » vérifiée sauf si l’hôte doit rester disponible pour des analyses forensic en cours.
Réémettez tous les identifiants et clés accessibles depuis l’hôte compromis ; faites tourner les comptes de service, clés SSH et tokens.
Imposez une authentification renforcée pour les outils de support : exigez SSO + MFA, allowlists par appareil, et des gates d’approbation de session. Voir MFA pour accès distant : TOTP, push, passkeys, hardware pour comparer les méthodes.
Renforcez la journalisation et la rétention pour faciliter les enquêtes futures. Voir les bonnes pratiques pratiques de journalisation dans Journalisation d’audit pour bureau à distance.
Effectuez un balayage complet des identifiants (mots de passe partagés en chat, identifiants sauvegardés, mots de passe de navigateur) et imposez une fenêtre de changement d’identifiants.

Leçons apprises et où investir

Une fois l’incident clos, réalisez un post‑mortem court focalisé sur la cause racine et les lacunes opérationnelles. Les investissements typiques qui réduisent à la fois le risque et le temps de confinement incluent :

Restreindre les privilèges des outils de support au minimum nécessaire et appliquer des élévations just‑in‑time.
MFA adaptatif et listes d’autorisation par appareil pour les clients de support.
Enregistrement automatique des sessions et exports d’audit immuables vers un SIEM externe.
Processus clairs d’offboarding et de révocation d’appareils — voir Checklist de désaffectation d’accès distant pour une liste prête à l’emploi.
Tester régulièrement les runbooks d’incident dans des exercices tabletop ciblés sur les scénarios d’accès distant.

Notes finales sur la confiance et la vérité sur les relais

Soyez explicite dans votre équipe : une connexion directe peer‑to‑peer est chiffrée de bout en bout entre les deux appareils, mais lorsque le trafic bascule vers un relais, le TLS se termine au niveau de ce relais. Cela signifie que l’organisation qui opère le relais peut accéder au trafic de session si elle le souhaite ou si elle y est contrainte. Ne supposez pas que les relais sont invisibles — construisez des contrôles et des exports de journaux en conséquence. Si vous voulez un modèle de menace plus approfondi pour les outils de bureau à distance, notre analyse technique est utile : Le bureau à distance est-il sûr ? Un modèle de menace honnête.

Où obtenir de l’aide et lien de téléchargement

Si vous avez besoin d’un relais géré avec journaux centralisés et basculement multi‑région, le relais géré de Tenvo est la recommandation par défaut sauf exigence écrite imposant l’auto‑hébergement. Pour une reprise pratique, préservez les preuves, ouvrez des tickets auprès de votre fournisseur de relais immédiatement et suivez la checklist de triage ci‑dessus. Quand vous êtes prêt, téléchargez les clients ou réalisez une migration contrôlée depuis votre outil actuel sur Télécharger Tenvo.

Réponse à un incident d’accès distant : checklist pour la première heure