Outils d'accès distant : forensic d'AnyDesk et TeamViewer

Les logiciels commerciaux d'accès à distance et de RMM sont devenus un classique des intrusions : ils sont signés, tolérés par les EDR, passent les pare-feux en HTTPS et offrent un bureau complet à l'opérateur. Ce guide vous montre comment prouver qu'un outil a été installé ou exécuté, extraire les ID, IP et horodatages de session des journaux propres à chaque produit, retrouver les transferts de fichiers et distinguer l'usage d'un attaquant du support IT normal. Il complète le guide RDP, PsExec et WinRM, consacré aux techniques natives de Windows.

Pour une référence condensée des emplacements de fichiers, consultez la fiche outils d'accès à distance.

Pourquoi l'abus de RMM passe inaperçu

Les attaquants utilisent ces outils de trois façons : déposer un binaire portable après l'accès initial, installer un agent complet rattaché à leur propre compte pour la persistance, ou détourner une plateforme RMM que la victime utilise déjà. Le troisième cas est le plus difficile, car chaque binaire, service et flux réseau est légitime. Ce qui change, c'est le compte, le tenant ou la session de l'autre côté.

Cela oriente l'enquête. La question n'est pas seulement « AnyDesk est-il présent ? » mais « quelle instance, rattachée à qui, utilisée depuis où, par quel utilisateur local, et pour déplacer quels fichiers ? ». La plupart des réponses se trouvent dans des journaux texte écrits par l'outil lui-même, pas dans les journaux d'événements Windows.

Traces d'installation et d'exécution

Commencez par les traces génériques que laisse tout programme. Elles donnent une date de première apparition et un chemin, ce qui indique déjà s'il s'agit d'un déploiement IT ou d'un dépôt ponctuel.

• Services. La plupart des outils installent un service pour survivre au redémarrage et gérer les invites UAC. Le 7045 du journal System enregistre le nom du service et le chemin de l'image ; la clé se trouve sous HKLM\SYSTEM\CurrentControlSet\Services\ (voir services). Noms courants : AnyDesk, TeamViewer, ScreenConnect Client (<id>), SplashtopRemoteService, AteraAgent et RustDesk, mais l'installateur ou l'attaquant peut les personnaliser.
• Programmes installés. Les installations MSI écrivent des événements MsiInstaller (1033, 11707) dans le journal Application, ainsi que des entrées sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall et son équivalent WOW6432Node. La fiche programmes installés liste les champs utiles, dont InstallDate et InstallLocation.
• Prefetch et Amcache. Un AnyDesk.exe portable lancé depuis Downloads ou C:\Users\Public y apparaît même sans installation. Amcache fournit le SHA1, à comparer avec la version publiée par l'éditeur, et Prefetch le nombre d'exécutions et les dernières dates d'exécution.
• Téléchargements du navigateur. L'historique des téléchargements et le flux Zone.Identifier de l'installateur donnent l'URL source. Un téléchargement depuis le site de l'éditeur en pleine nuit, par un utilisateur qui n'en a jamais eu besoin, est une piste sérieuse. Voir forensic des navigateurs Windows.
• Création de processus. Le 4688 ou l'événement 1 de Sysmon montre le parent. Un installateur RMM lancé depuis cmd.exe sous un compte de service, ou depuis un « download cradle » PowerShell, ne correspond pas à la façon dont l'IT déploie ses logiciels.

# Services pointant vers des outils d'accès à distance courants
Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -match 'AnyDesk|TeamViewer|ScreenConnect|Splashtop|Atera|RustDesk|ConnectWise' } |
  Select-Object Name, StartMode, State, PathName

# Installations de services dans le journal System
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Where-Object { $_.Message -match 'AnyDesk|TeamViewer|ScreenConnect|Splashtop|Atera|RustDesk' } |
  Select-Object TimeCreated, Message

Artefacts par outil

Les détails ci-dessous correspondent aux versions couramment rencontrées. Les éditeurs renomment, déplacent et reformatent leurs journaux d'une version à l'autre : validez sur une installation de test de la même version dès qu'un constat compte.

AnyDesk

• Emplacements : C:\ProgramData\AnyDesk\ pour le service installé, %APPDATA%\AnyDesk\ côté utilisateur et pour les exécutions portables.
• ad_svc.trace / ad.trace : journaux de trace verbeux. Les lignes relatives aux sessions entrantes contiennent souvent l'ID AnyDesk distant et l'IP distante, adresse de relais ou pair direct. Cherchez des chaînes du type « Incoming session », « Logged in from » ou « External address » plutôt qu'un format exact.
• connection_trace.txt : une ligne par connexion entrante, avec date, heure, méthode d'authentification (par exemple User pour une invite acceptée, Passwd pour un mot de passe d'accès sans surveillance, Token pour une session mémorisée) et ID AnyDesk distant. Une connexion Passwd sans surveillance à 3 h du matin est un schéma de persistance classique.
• Configuration : system.conf et service.conf contiennent l'ID AnyDesk local et des paramètres comme l'accès sans surveillance ; user.conf les préférences de l'utilisateur. Un mot de passe d'accès sans surveillance défini récemment est un grand classique des attaquants.
• Transfert de fichiers : le journal de trace enregistre l'activité de transfert, et certaines versions écrivent aussi un file_transfer_trace.txt dédié. Considérez les deux comme facultatifs.

TeamViewer

• Connections_incoming.txt dans le dossier d'installation (par exemple C:\Program Files\TeamViewer\) : ID TeamViewer distant, nom affiché, heures de début et de fin, utilisateur Windows local, type de connexion (contrôle à distance ou transfert de fichiers) et GUID de session. C'est l'artefact TeamViewer le plus utile.
• Connections.txt sous %APPDATA%\TeamViewer\ : connexions sortantes initiées depuis cette machine, utile quand elle a servi de rebond.
• Fichier journal : TeamViewer<version>_Logfile.log dans le dossier d'installation (les anciennes versions intègrent le numéro de version majeure dans le nom), plus des copies _OLD après rotation. Il contient des détails sur les participants et des lignes de transfert nommant les fichiers envoyés ou écrits. La formulation varie selon les versions : cherchez largement « file », « Write » et « Download ».
• Registre : HKLM\SOFTWARE\TeamViewer (ou WOW6432Node) contient le ClientID local et les paramètres ; un déploiement géré montre généralement un rattachement à un compte d'entreprise.

ScreenConnect (ConnectWise Control)

• Service et dossier : ScreenConnect Client (<id de 16 caractères hexadécimaux>) dans C:\Program Files (x86)\ ou C:\Program Files\. L'id dérive de l'instance serveur : deux id différents sur une même machine signifient deux serveurs ScreenConnect différents.
• system.config / user.config dans le dossier du client : hôte et port du relais que le client contacte. Si l'instance est illégitime, c'est le serveur de l'attaquant.
• Journal Application : le client écrit des événements sous une source portant le nom du service. Les messages décrivent la connexion et la déconnexion d'un participant nommé, les transferts de fichiers et les commandes lancées via la toolbox ou le backstage. C'est rare parmi les outils RMM, et très précieux.
• Fichiers transférés et éléments de toolbox : ils atterrissent souvent sous C:\Windows\Temp\ScreenConnect\<version>\ ou un chemin temporaire similaire, souvent avec leur nom d'origine.
• Côté serveur : si la victime héberge le serveur, sa base de sessions (SQLite dans App_Data) et ses journaux web enregistrent chaque session et chaque opérateur. Collectez-les avant qu'on ne patche ou reconstruise le serveur.

Splashtop

• Service de streaming SplashtopRemoteService ; journaux comme SPLog.txt dans le dossier Splashtop Remote Server de Program Files (x86). Noms et dossiers varient selon l'édition (Business, SOS, intégration Atera).
• Les entrées incluent le début et la fin de session, le compte ou l'appareil distant et parfois l'IP du pair.

Atera

• Service AteraAgent dans C:\Program Files\ATERA Networks\AteraAgent\, avec les paquets téléchargés dans ses sous-dossiers.
• HKLM\SOFTWARE\ATERA Networks\AlphaAgent contient des valeurs comme AccountId et IntegratorLogin, l'adresse e-mail du compte Atera auquel l'agent s'est enregistré. Un e-mail inconnu ici vaut presque un aveu.
• Atera délègue le contrôle à distance interactif à des outils intégrés (Splashtop, AnyDesk) : vérifiez aussi leurs artefacts.

RustDesk

• Open source, auto-hébergeable et de plus en plus vu en intrusion. Configuration et journaux utilisateur sous %APPDATA%\RustDesk\ (config\RustDesk.toml, RustDesk2.toml, log\), et profil du service sous C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\ sur une installation typique.
• RustDesk2.toml peut contenir un custom-rendezvous-server et un relais : un serveur d'ID ou de relais géré par l'attaquant est un indicateur fort.
• Le dossier peers liste les ID distants auxquels ce client s'est connecté.

Quick Assist (Assistance rapide)

• Intégré à Windows et désormais distribué comme application du Store (quickassist.exe). Il a été détourné dans des campagnes de vishing où l'appelant se fait passer pour le support.
• Il journalise très peu en local. Appuyez-vous sur Prefetch ou le dossier du paquet pour l'exécution, sur SRUM pour l'usage réseau par application (voir forensic SRUM), sur la télémétrie de création de processus et sur ce que l'utilisateur a lancé juste après la session.

Traces réseau et pare-feu

Les journaux locaux sont bien plus solides lorsqu'ils sont recoupés avec des traces réseau.

• Règles et journaux du pare-feu. Les installateurs ajoutent souvent des règles entrantes. Leur création apparaît dans Microsoft-Windows-Windows Firewall With Advanced Security/Firewall (2004 sur les anciennes versions, 2097 sur les récentes), et pfirewall.log enregistre les connexions autorisées si la journalisation était active. Voir journaux du pare-feu Windows.
• Audit WFP. Le 5156 du journal Security (connexion autorisée) nomme l'application, l'adresse et le port distants, si l'audit « Filtering Platform Connection » est actif. Bruyant, mais décisif.
• Sysmon 3 et 22 : connexions réseau et requêtes DNS par processus. Les domaines de relais des éditeurs (*.net.anydesk.com, *.teamviewer.com, un hôte de relais ScreenConnect, *.splashtop.com) et les ports RustDesk 21115 à 21119 sont de bons pivots.
• Données périmétriques : journaux proxy, DNS et NetFlow confirment la chronologie et révèlent des sessions sur des machines dont les journaux locaux ont été supprimés.

La plupart des outils passent par des relais de l'éditeur. L'IP d'un journal peut donc être celle d'un relais, pas de l'opérateur. Les connexions directes entre pairs sont l'exception et méritent d'être mises en avant quand vous en trouvez.

Si une capture réseau existe (tap, capture EDR ou sortie pktmon convertie en pcapng), PCAP Parser l'ouvre dans le navigateur et liste conversations, requêtes DNS et SNI TLS, ce qui suffit souvent à confirmer les domaines relais RMM contactés pendant la session.

Attribution des sessions

Pour chaque session, construisez une ligne : outil, machine locale, ID distant, nom affiché ou compte distant, IP distante (en précisant s'il s'agit d'un relais), utilisateur local, début, fin, et ce qui s'est passé entre les deux.

• Les ID distants (AnyDesk, TeamViewer, RustDesk) sont des identifiants stables. Le même ID chez plusieurs victimes constitue un lien fort, et les éditeurs peuvent les résoudre sur réquisition.
• Le tenant ou le compte (IntegratorLogin d'Atera, hôte de relais ScreenConnect, rattachement TeamViewer à une entreprise) indique si l'instance appartient bien à votre organisation.
• Utilisateur local et session : corrélez le début de session avec les 4624 de la machine (un type 2 ou 7 peut suivre un accès sans surveillance, selon la façon dont l'outil gère le bureau) et avec les artefacts utilisateur. Les outils tournant en SYSTEM agissent sur le bureau actif : vérifiez qui était connecté à ce moment.
• Ce qui a été fait : processus créés dans l'arborescence de l'outil, nouveaux fichiers dans Downloads, Temp ou sur le bureau, et journaux PowerShell. Une arborescence de processus enracinée sous AnyDesk.exe ou le client ScreenConnect trahit une activité interactive de l'opérateur.

Traces de transfert de fichiers

Les transferts de fichiers sont l'endroit où les outils RMM laissent le plus souvent filtrer des preuves de préparation ou d'exfiltration.

• Journaux des outils : lignes du journal TeamViewer, trace AnyDesk ou file_transfer_trace.txt, événements du journal Application et dossier temporaire de ScreenConnect.
• Système de fichiers : nouveaux fichiers dont la date de création tombe dans la fenêtre de session. Analysez la $MFT et le journal USN sur cette fenêtre et regardez quel processus les a écrits.
• Presse-papiers : plusieurs outils synchronisent le presse-papiers, qui peut transporter des commandes ou de petits fichiers. L'historique du presse-papiers vaut le coup d'œil s'il est activé.

Référence par outil

MITRE ATT&CK suit ce comportement sous T1219. Les versions récentes la nomment Remote Access Tools avec des sous-techniques, et T1219.002 (Remote Desktop Software) est celle qui correspond à ces produits.

Usage IT légitime ou intrusion ?

Établissez une référence avec l'équipe IT avant de conclure :

• Quel produit et quelle méthode de déploiement l'IT utilise, et quel tenant ou compte. Tout le reste est suspect par défaut.
• Chemin d'installation : les installations gérées atterrissent dans Program Files. Les binaires portables dans Downloads, AppData, des sous-dossiers de ProgramData ou C:\Users\Public viennent rarement de l'IT.
• Horaires : des sessions hors des heures du support, ou juste après une connexion suspecte, méritent un examen approfondi.
• Configuration : accès sans surveillance activé sur un poste qui n'en a jamais eu besoin, mot de passe défini peu après l'installation, ou serveur de relais personnalisé.
• Empilement : deux ou trois outils différents installés à quelques minutes d'intervalle, c'est un attaquant qui se prémunit contre une suppression, jamais une pratique de helpdesk.

Pièges

• Prendre l'IP journalisée pour celle de l'opérateur. La plupart des sessions passent par des relais. Écrivez « adresse de relais » dans le rapport sauf si vous démontrez une connexion directe.
• Se fier à un seul journal. Les journaux de trace tournent et les attaquants les suppriment. Recoupez avec Prefetch, les journaux d'événements, Sysmon et le système de fichiers.
• Rater la copie portable. Beaucoup d'enquêtes ne vérifient que les programmes installés. Les binaires portables écrivent leurs journaux dans l'AppData de l'utilisateur, pas dans ProgramData.
• Supposer des formats stables. Un parseur écrit pour une version d'AnyDesk ou de TeamViewer peut manquer des lignes sans bruit sur une autre. Faites aussi un grep du texte brut.
• Oublier le RMM légitime. Si l'attaquant a utilisé la plateforme de l'entreprise, les traces locales paraissent normales. Il vous faut le journal d'audit de la console RMM, hébergé dans le cloud de l'éditeur ou sur le serveur RMM.
• Ignorer les fuseaux horaires. Certains journaux sont en heure locale, d'autres en UTC. Calez-les sur un événement connu avant de les fusionner dans une chronologie.

Checklist de la démarche

1. Inventoriez les outils d'accès à distance sur chaque machine du périmètre : services, programmes installés, Prefetch, Amcache et binaires portables dans les dossiers utilisateur.
2. Pour chaque instance, notez la version, le chemin et la date d'installation, et le compte, tenant ou relais associé.
3. Collectez journaux et configuration de l'outil dans ProgramData et dans l'AppData de chaque utilisateur, plus le journal Application pour ScreenConnect.
4. Construisez un tableau des sessions : ID distant, nom distant, IP distante (relais ou directe), utilisateur local, début, fin.
5. Cartographiez l'activité dans chaque fenêtre de session : arborescences de processus sous l'outil, nouveaux fichiers, PowerShell, accès aux identifiants. Voir forensic de l'accès aux identifiants si des outils comme Mimikatz apparaissent.
6. Confirmez avec les traces réseau : journaux du pare-feu, 5156, Sysmon 3/22, proxy et DNS.
7. Comparez avec la référence IT et classez chaque instance comme autorisée, suspecte ou malveillante.
8. Recherchez les mêmes ID, tenants, hashes et hôtes de relais sur tout le parc, et placez l'ensemble dans la super timeline de l'incident.