Au cœur d'un voleur de session Telegram : comment un script PowerShell hébergé sur Pastebin cible les sessions de bureau et web

Par Sukant Kumar, chercheur en cybersécurité 

Un script PowerShell intitulé « Mise à jour de la télémétrie Windows » ressemble à un processus système de routine que la plupart des utilisateurs ne remettraient pas en question. C’est précisément ce sur quoi comptait l’auteur de la menace. Flare a signalé ce script hébergé sur Pastebin comme une menace de haut niveau, et notre analyse a révélé un voleur de session Telegram spécialement conçu pour cibler les données de session de bureau, les exfiltrer via l’API du bot Telegram et partager son infrastructure avec un outil de capture de session web distinct. 

Ce qui rend ce cas instructif, ce n'est pas la sophistication des outils (minimalistes), mais ce que révèlent les artefacts : deux mécanismes de collecte à différents stades de développement, des identifiants codés en dur exposant l'historique complet du bot de l'opérateur, et une piste de débogage claire, d'une première version défectueuse à une seconde version fonctionnelle. Cette fonctionnalité, découverte lors de la phase de validation, avant le déploiement opérationnel, offre un aperçu rare de la manière dont les outils de vol de session sont conçus et testés.

Méthodologie

Nous avons analysé un script PowerShell hébergé sur Pastebin, déguisé en « Mise à jour de télémétrie Windows », qui vole des données de session Telegram Desktop via l'exfiltration de données de l'API du bot Telegram. Le script collecte les métadonnées de l'hôte, notamment le nom d'utilisateur, le nom d'hôte et l'adresse IP publique, via api.ipify[.]org, puis recherche les répertoires de données de Telegram Desktop et de Telegram Desktop Beta. S'il les trouve, il interrompt le processus Telegram pour libérer les verrous de fichiers, archive les données de session dans `TEMP\diag.zip` et télécharge l'archive sur le chat de l'opérateur contrôlé par l'attaquant via le point de terminaison sendDocument de l'API du bot Telegram.

L'étude a analysé deux variantes de script publiées sur Pastebin. La version corrigée (v2) résolvait un problème d'implémentation du téléchargement multipart présent dans la version initiale (v1). L'intégration de jetons de bot dans les deux scripts a permis une analyse directe des réponses de l'API Telegram et l'extraction de l'historique des messages via Matkap. Ces analyses ont révélé plusieurs messages de bot documentant une fonctionnalité distincte de capture de sessions Telegram via le web, partageant la même infrastructure C2.

Évaluations clés du renseignement

• État de développement : La fonctionnalité a passé la validation fonctionnelle mais n'a pas encore été déployée de manière opérationnelle à grande échelle.
  • Principaux indicateurs tirés des scripts Pastebin : absence d’obfuscation, identifiants en clair, mécanisme de téléchargement défectueux de la version 1 corrigé dans la version 2, absence de persistance. Confirmation par la télémétrie du bot : adresse du collecteur local (192.168.137.131:5000) mentionnée dans les notifications du voleur de données web, extraite du corps du message du bot exporté par Matkap.
• Liaison des infrastructures : Deux mécanismes distincts de vol de session (un programme PowerShell pour ordinateur et un programme web pour navigateur) partagent un même canal Telegram (`afhbhfsdvfh_bot`). Aucune preuve d'intégration architecturale au-delà de cette infrastructure d'exfiltration partagée. 

Découverte initiale d'un voleur de données ciblant Telegram sur Pastebin

Notre première piste de renseignement provenait d'une publication Pastebin intitulée « Mise à jour de télémétrie Windows – Version corrigée », que Flare a signalée comme un script PowerShell malveillant de gravité « élevée » se faisant passer pour une mise à jour Windows conçue pour voler les données de l'application Telegram. 

Événement de haute gravité signalé sur Flare (Flare lien vers la publication, inscrivez-vous à essai gratuit (pour y accéder si vous n'êtes pas déjà client)

Résumé de l'assistance IA sur Flare décrivant la véritable intention du message Pastebin (Flare lien vers la publication, inscrivez-vous à essai gratuit (pour y accéder si vous n'êtes pas déjà client)

Le titre imite la nomenclature légitime des services de mise à jour et de télémétrie de Windows, conformément à une convention d'appellation destinée à réduire les soupçons lors d'une inspection rapide.

Publication Pastebin originale (script v2)

Le script intégrait en dur deux identifiants clés dans les trois premières lignes.

jetons de bot codés en dur

Nous avons immédiatement identifié cela comme un jeton et un identifiant de chat d'un bot Telegram. Deux pistes d'investigation se sont alors dégagées : interroger directement l'API des bots Telegram pour les recenser, et extraire les données de télémétrie C2 existantes de l'historique des messages du bot à l'aide de Matkap. Les deux approches se sont avérées fructueuses.

Analyse technique de PowerShell Desktop Stealer

Aperçu du script

L'analyse de la logique du script a révélé qu'il ne ciblait ni les identifiants ni les données du navigateur. Il recherchait spécifiquement les répertoires de session de Telegram Desktop. Les chemins cibles sont :

• appdata\Telegram Desktop\tdata
• appdata\Telegram Desktop Beta\tdata

Telegram Desktop tdonnées Ce répertoire contient les clés d'autorisation utilisées par le protocole MTProto de Telegram pour authentifier le client auprès des serveurs de Telegram. Ces clés sont :

• Longévité : Généré lors de la première connexion, ce mot de passe persiste jusqu'à sa révocation manuelle via « Sessions actives » ou son invalidation par les contrôles de sécurité de Telegram.
• Lié à l'appareil : Lié à l'installation spécifique de Telegram Desktop, mais portable si le tdonnées Le dossier a été copié.
• Indépendant des qualifications : L'accès à la session ne nécessite ni le mot de passe du compte ni la vérification par SMS après la configuration initiale.

Flux d'exécution

Étape 1 : Initialisation de l'infrastructure

Le jeton du bot et l'identifiant de conversation sont codés en dur et lisibles en clair, ce qui les rend très faciles à extraire. Cela permet de recenser les messages envoyés ou reçus par le bot via getUpdates ou d'extraire/intercepter les messages à l'aide de l'outil Matkap.

Étape 2 : Reconnaissance de l'hôte

Le script collecte le nom d'utilisateur, le nom d'hôte et l'adresse IP publique via api.ipify[.]org avant toute opération de vol. Les métadonnées intégrées à la description de l'exfiltration permettent un profilage immédiat de la victime.

Étape 3 : Énumération des cibles et porte de branchement

Le script vérifie la présence d'installations stables et bêta de Telegram Desktop dans le répertoire $appdata. Les chemins correspondants sont ajoutés au tableau $paths.

Fonction clef – la porte de branchement :

La condition `$paths.Count -gt 0` est la seule qui détermine l'exécution du script : celui-ci ne s'exécute que si au moins un chemin `tdata` existe. Dans le cas contraire, il déclenche le message « Aucune installation Telegram trouvée ».

Étape 4 : Fin du processus

Le script force l'arrêt de Telegram.exe afin de réduire les conflits de verrouillage de fichiers dans le répertoire avant l'archivage. Ce délai de deux secondes permet la fermeture du processus et la libération des descripteurs avant le début de la compression. Ce comportement, conforme à la gestion des verrouillages de fichiers par Telegram Desktop, améliore la fiabilité de l'exfiltration.

Étape 5 : archivage des données

Le script crée un fichier « diag.zip » dans le répertoire temporaire de l'utilisateur, contenant tous les dossiers tdata découverts.

Étape 6 : Exfiltration (corrigée dans la version ultérieure, c'est-à-dire la version corrigée – v2)

Le point de terminaison de l'API du bot est créé en injectant le jeton `$t` dans `api.telegram[.]org/bot$t/sendDocument`, ciblant la méthode d'envoi de fichiers de Telegram. Une charge utile `$form` est assemblée, contenant l'identifiant de conversation de l'opérateur, les métadonnées de la victime sous forme de légende (nom d'utilisateur@nom d'hôte + adresse IP) et le document « diag.zip ».

La commande `Invoke-RestMethod -Form` envoie une requête POST multipart/form-data, l'encodage requis par l'API Telegram pour la transmission de fichiers. En cas d'échec, une solution de repli `WebClient.UploadFile()` garantit que l'archive parvienne à l'opérateur, sacrifiant ainsi la légende mais préservant le fichier.

Étape 7 : nettoyage

Le script supprime le fichier diag.zip après son téléchargement afin de retirer l'artefact d'analyse forensique du disque.

Étape 8 : Balise No-Telegram (ajout v2)

Le script envoie une notification même si Telegram n'est pas installé. Il se transforme ainsi en « sondage de disponibilité de l'hôte », garantissant un retour d'information de l'opérateur à chaque exécution, quel qu'en soit le résultat.

Évolution des versions : Preuves de débogage

Version initiale (v1) : Échec du chargement

Le profil Pastebin ayant publié le script PowerShell contenait également une version initiale (v1). L'implémentation s'est avérée fondamentalement défectueuse. Le point de terminaison « sendDocument » de Telegram requiert l'encodage « multipart/form-data » pour accepter les pièces jointes. L'utilisation de « UploadFile » avec des paramètres de chaîne de requête URL et le type de contenu « application/x-www-form-urlencoded » entraîne des échecs de chargement ; l'archive « diag.zip » n'atteint jamais le bot.

Capture d'écran de la version initiale du script (v1)

Version corrigée (v2) : Corrections

• Correction du chargement multipartie : L'utilisation correcte de « Invoke-RestMethod -Form » génère un encodage « multipart/form-data » correct
• La gestion des erreurs: Bloc « try/catch » avec repli WebClient.
• Télémétrie d'exécution : La balise « No-Telegram » garantit que l'opérateur reçoit un retour d'information même lors d'une exécution sur un hôte vide.

Capture d'écran de la version corrigée du script (v2)

Évaluation analytique : Cette transition de version (v1 à v2) témoigne de tests actifs, de l'observation des défaillances, de leur diagnostic et de leur correction : un cycle de débogage caractéristique. L'opérateur a exécuté la version v1, n'a constaté aucune réception du fichier « diag.zip » dans la conversation du bot, a identifié le défaut de chargement en plusieurs parties et a publié une version corrigée.

Note comparative : Les schémas d'exfiltration de fichiers zip de sendDocument reproduisent le mécanisme documenté de Raven Stealer (NVISO, 2025). Cette technique est bien établie dans l'écosystème des voleurs d'informations ; la différence réside ici dans son champ d'application. Cet outil privilégie un ciblage exclusif via Telegram, au détriment des fonctionnalités multi-étapes.

Infrastructure des bots Telegram

Identité du bot (Réponse `/getMe`)

Éléments notables :

• Nom d'affichage du bot : « Attaquant Telegram », une auto-identification explicitement hostile, plutôt qu'une dissimulation sous couvert d'un service bénin.
• Pseudo « afhbhfsdvfh_bot », une chaîne de caractères aléatoire suggérant une génération automatisée.
• Capacité du groupe : « can_join_groups: true », ce qui signifie que le bot peut être ajouté aux discussions de groupe si l'opérateur étend la portée de diffusion ou d'accès.

État de l'infrastructure (« Réponse /getWebhookInfo »)

• Aucun webhook configuré (`url: ””`) : Le bot n'envoie aucune mise à jour à un serveur backend.
• Des mises à jour en attente indiquent que le serveur traitant les mises à jour est inactif ou absent au moment de l'analyse. La logique serveur d'origine qui traitait les messages des bots n'est plus interrogée.

Voleur de session Web : capacité observée

Analyse des preuves recueillies

Nous avons extrait plusieurs messages de notification du bot du chat opérateur 8562222339 via l'outil Matkap. Chaque message contient un aperçu JSON structuré de la capture, l'horodatage, un compteur de session incrémentiel et, dans les captures plus récentes, un indicateur de présence de la clé d'authentification et une confirmation de routage VPS.

Messages capturés via l'outil Matkap

Les données à haute valeur ajoutée se trouvent dans le « localstorage ». Dans la majorité des captures, les aperçus des messages contenaient des valeurs dc3_auth_key ou dc4_auth_key – des clés d'autorisation MTProto de 256 octets qui sont l'équivalent côté navigateur de ce que le module PowerShell extrait de tdata.

Message capturé contenant des clés d'authentification DC4

Un attaquant possédant ces clés peut reconstituer des sessions authentifiées. La notification les signale explicitement : « Contient des clés d’authentification DC4 ! »

Message capturé contenant « dcId » et une clé d'authentification « dc4_auth_key » par compte

Outre les clés d'authentification, le voleur a systématiquement capturé « account1 », un objet JSON contenant « dcId » et une « dc4_auth_key » par compte, reflétant la structure de session interne de Telegram Web.

Collecteur HTTP local

Le pirate a transmis des données par deux voies simultanées. Les données JSON complètes (y compris les valeurs complètes des clés d'authentification) ont été envoyées à un collecteur HTTP local à l'adresse http://192.168.137.131:5000. Des notifications récapitulatives tronquées ont été envoyées à la messagerie du bot.

Indicateurs de l'environnement de test

L'analyse des messages capturés et exportés suggère des tests contrôlés plutôt qu'une exploitation de victimes réelles.

• Agents utilisateurs uniformes : Les captures de tous les messages exportés contenaient une chaîne d'agent utilisateur identique. (Mozilla/5.0 (Linux; Android 10; Mobile) AppleWebKit/537.36 Chrome/120.0.0.0 Mobile Safari/537.36). Tout déploiement réel fait apparaître une diversité d'appareils dès les premières captures ; un agent utilisateur uniforme sur l'ensemble des données désigne un seul navigateur et un seul opérateur, exécutant des sessions contrôlées.
• Répétition des clés d'authentification : Au sein de chaque vague de capture, les mêmes préfixes de clés se répétaient d'une session à l'autre. Le pirate ciblait à plusieurs reprises le même navigateur authentifié, et non différentes victimes. La diversité des clés observée dans l'ensemble des données correspondait à un petit nombre de comptes de test contrôlés, et non à une propagation organique chez les victimes.
• Compteur de sessions ininterrompues : Le compteur de sessions s'est incrémenté sans interruption tout au long de la capture, sans réinitialisation ni lacune. Les déploiements des victimes sont réinitialisés pour chaque hôte ; un compteur continu reflète une session contrôlée par l'opérateur. En cours de capture, nous avons observé l'opérateur émettre des requêtes /sessions, inspectant activement les captures au fur et à mesure de leur progression. Il s'agit d'un comportement d'inspection délibéré, et non d'une simple surveillance passive d'une campagne en direct.
• Adresse du collecteur local : Le canal de transmission de la charge utile complète a été acheminé vers une adresse du réseau local. L'opérateur le qualifie de « VPS » dans sa notification, mais une adresse IP privée n'est pas routable sur Internet. Il s'agit d'une machine de test locale, et non d'une infrastructure d'exfiltration en production. L'adresse du collecteur local du canal de transmission de la charge utile complète (192.168.137[.]131:5000) a levé toute ambiguïté.
• Évaluation: L'homogénéité des agents utilisateurs, la cohérence des clés d'authentification, la faible diversité des URL et l'adresse privée du collecteur sont collectivement incompatibles avec l'activité réelle des victimes et compatibles avec les tests en boucle fermée effectués par l'opérateur sur des comptes contrôlés.

Analyse du calendrier opérationnel

La séquence ci-dessous est reconstituée à partir des messages de notification du bot extraits via l'interception Matkap de l'historique du bot de l'opérateur.

Évaluation des liens entre les infrastructures

Infrastructure partagée

Nous avons comparé les scripts PowerShell avec l'historique des messages du bot et avons trouvé des identifiants de liaison cohérents dans tous les artefacts récupérés :

• Jeton du bot : Codé en dur de manière identique dans les deux variantes de script ; présent comme identifiant actif dans chaque message de bot extrait.
• ID de chat de l'opérateur : Intégré en dur dans les deux scripts comme seul destinataire chat_id pour toutes les sorties du bot ; confirmé comme destination dans toutes les notifications extraites.
• Identité du bot : afhbhfsdvfh_bot, nom d'affichage « Attaquant Telegram », résolu via /getMe contre le jeton codé en dur.
• Association des opérateurs: Scripts PowerShell directement liés au compte Pastebin utilisé dans cette affaire ; voleur de site web attribué au même opérateur via des identifiants de bot partagés (nous n'avons pas récupéré de publication Pastebin distincte pour le composant voleur de site web).

Indépendance architecturale

Nous n'avons trouvé aucune référence croisée entre les deux outils dans les deux sens :

• Scripts PowerShell : Aucune mention du collecteur HTTP, du stockage local, de la capture de session du navigateur ni d'aucun composant de vol de données Web. Limité exclusivement à l'archivage de données et à l'exfiltration via sendDocument.
• Historique des messages du bot : Aucune référence à sendDocument, diag.zip, tdata ou à un quelconque artefact de module de bureau dans toutes les notifications extraites.
• Aucun événement « sendDocument » n'apparaît dans l'historique des messages du bot (module de bureau non observé en cours d'exécution dans la fenêtre de télémétrie).
• Voies d'exfiltration : Architecture distincte. Le client de bureau achemine « diag.zip » vers l’API du bot via « sendDocument » ; le voleur web envoie des charges utiles JSON complètes à un collecteur HTTP local et envoie séparément des notifications de résumé tronquées au chat du bot ; aucun chemin de code commun entre eux.

Il s'agit de deux mécanismes de collecte indépendants utilisant un bot Telegram partagé comme canal commun de notification et de relais de données. Cette infrastructure partagée offre un avantage aux opérateurs et permet la réutilisation des ressources.

Évaluation de la maturité opérationnelle

L'outil démontre sa fonctionnalité. La variante de script corrigée (v2) implémente correctement l'exfiltration via « sendDocument », le voleur de données Web a exécuté des sessions de capture contrôlées avec des clés d'authentification et l'infrastructure du bot est restée opérationnelle au moment de l'enquête. En revanche, il n'a pas été déployé de manière opérationnelle.

Les indicateurs qui permettent d'établir cela ne sont pas individuellement concluants, mais ils convergent sans exception dans la même direction. Les scripts ne comportent aucun mécanisme de persistance ni d'obfuscation. Ils ne contiennent aucun mécanisme d'exécution ou de distribution automatisé. L'infrastructure de collecte est locale au réseau local. En résumé, il s'agit d'une capacité en cours de validation, mais non encore utilisée.

Indicateurs d'escalade

Les éléments suivants signaleraient la transition des tests au déploiement opérationnel et devraient être considérés comme des priorités de collecte :

• Variantes PowerShell obscurcies ou encodées du script
• Rotation des jetons du bot, indiquant une prise de conscience de l'exposition et une gestion active de l'infrastructure
• Le collecteur local du réseau local a été remplacé par une adresse VPS accessible depuis Internet.
• Chargeurs automatisés récupérant des scripts à partir d'URL collées
• Diversité de l'agent utilisateur ou de la géolocalisation dans les captures du voleur de données Web, premier indicateur du trafic réel des victimes\
• Migration de l'exfiltration de bots Telegram vers une infrastructure C2 dédiée

Cartographie MITRE ATT&CK

Détection et conseils défensifs

Indicateurs comportementaux des points de terminaison

La télémétrie en ligne de commande des terminaux offre la surface de détection la plus fiable pour cet ensemble d'outils. Les scripts analysés ne contiennent aucune obfuscation et les indicateurs critiques apparaissent directement dans les arguments de ligne de commande PowerShell capturés par l'EDR.

Chaîne d'exécution typique :

1. Lancement du processus PowerShell.
2. Recherche d'adresse IP publique via api.ipify.org.
3. Énumération des hôtes ($env:USERNAME / $env:COMPUTERNAME).
4. $appdata\Telegram Desktop\tdata référence.
5. Arrêter le processus ciblant Telegram.exe.
6. Compression-Archive créant TEMP\diag.zip.
7. Appel Invoke-RestMethod / WebClient à api.telegram.org/bot*/sendDocument.
8. Supprimer l'élément ciblant TEMP\diag.zip.

Bien que chaque étape puisse se produire indépendamment, leur combinaison forme un schéma malveillant à haute fiabilité.

Les connexions à api.telegram.org provenant d'environnements de script (PowerShell, Python, curl) sont extrêmement rares dans les environnements d'entreprise légitimes et doivent être traitées immédiatement.

Contrôles au niveau du réseau

Environnements où Telegram n'est pas autorisé :

Bloquez les domaines suivants au niveau du proxy et du pare-feu :

• api.telegram.org
• web.telegram.org
• Telegram.org

Cela supprime à la fois le canal d'exfiltration de l'API du bot et la surface d'attaque Web de Telegram.

Environnements dans lesquels Telegram est autorisé :

Surveiller pour :

• Processus non liés à un navigateur communiquant avec api.telegram.org
• Telegram.exe se connecte aux points de terminaison de l'API Telegram.org/bot*

La détection d'opérations spécifiques de l'API du bot, telles que /sendDocument, nécessite une inspection TLS, car les chemins de requête et les données POST sont chiffrés.

Sans inspection TLS, fiez-vous à la télémétrie des points de terminaison plutôt qu'à l'inspection du réseau.

Protocole de réponse aux incidents

• Révocation immédiate de la session : Si vous soupçonnez que ce script a été exécuté sur votre système, fermez immédiatement toutes les sessions Telegram actives via les paramètres de l'application (Paramètres > Confidentialité et sécurité > Sessions actives > Fermer toutes les autres sessions). Modifiez votre mot de passe Telegram et activez l'authentification à deux facteurs si ce n'est pas déjà fait.
• Examen du compte : Surveillez votre compte Telegram afin de détecter toute activité non autorisée, tout message inhabituel provenant du compte concerné ou toute modification des paramètres du compte. Sachez que toute information sensible partagée précédemment via Telegram a pu être compromise ; prenez les mesures nécessaires pour sécuriser les comptes associés ou avertir les personnes concernées.

Ce que les équipes de sécurité doivent savoir sur le bot Telegram

L'analyse des scripts PowerShell publiés sur Pastebin et des données de télémétrie du bot Telegram associé révèle une capacité de détournement de session Telegram en deux étapes, actuellement en développement. Les premiers indices laissaient penser à un voleur de session potentiellement déployé, mais les preuves recueillies indiquent plutôt un opérateur encore en phase de validation fonctionnelle. Le module PowerShell pour ordinateur présente des itérations entre les versions (une routine de téléchargement incomplète dans la version initiale du script (v1) et une fonction `sendDocument` corrigée dans la version corrigée (v2)), tandis que les notifications du bot montrent des captures de session répétées, cohérentes avec des tests contrôlés. Le collecteur HTTP associé restait confiné à une adresse locale et non à une infrastructure publique.

Les deux composants sont fonctionnels. Le module de bureau cible les données de session « tdata » de Telegram Desktop, tandis que le composant web capture les valeurs MTProto dcX_auth_key depuis le stockage local de Telegram Web. Chacun de ces éléments permet la relecture de session Telegram sans nécessiter d'identifiants de compte. Aucune activité de la victime n'a été observée pendant la période de télémétrie disponible.

Des variantes de scripts obscurcies, la rotation des jetons de bot, le déplacement du collecteur vers une adresse publique ou des chargeurs automatisés extrayant des URL collées feraient passer cette évaluation du développement actif aux opérations actives.

Références et sources

1. Responsable initial du renseignement : Recherche globale Flare (flare.io)
2. Publication Pastebin originale signalée : pastebin.com/wszjwj7q
3. Version initiale du script malveillant : pastebin.com/3c1Qu0Hi
4. Script PowerShell pour la publication d'un profil Pastebin : pastebin.com/u/abihacker
5. Interception de messages de bots Telegram : monstre matkap.cti.
6. API du bot Telegram : Réponse /getMe (identité du bot)
7. API du bot Telegram : Réponse de /getWebhookInfo (état de l'infrastructure)
8. Protocole mobile MTProto (Telegram) : core.telegram.org/mtproto
9. Étude de cas du voleur de corbeaux : blog.nviso.eu/2025/12/16/the-detection-response-chronicles-exploring-telegram-abuse