AsyncRAT et ses forks : détecter plus vite avec l’IA

En cybersécurité, le vrai danger n’est pas toujours « le malware »… mais sa descendance. AsyncRAT, un cheval de Troie d’accès distant (RAT) open source apparu en 2019, illustre parfaitement ce phénomène : ses capacités de base sont connues (vol d’identifiants, capture d’écran, keylogging), mais sa nature modulaire et son code accessible ont produit un écosystème tentaculaire de forks. Résultat : une même “famille” se fragmente en dizaines de variantes, chacune ajoutant des plugins, des techniques d’évasion, et juste assez de différences pour compliquer la détection.

Dans notre série « Intelligence artificielle dans la cybersécurité », AsyncRAT est un cas d’école. Il montre pourquoi les approches traditionnelles (hash, signatures figées, règles statiques) se font régulièrement distancer, et comment l’IA appliquée au renseignement sur les menaces peut, au contraire, remettre de l’ordre dans ce labyrinthe : classification automatique, regroupement par similarité, détection comportementale, et cartographie de l’évolution des forks.

Ce qui suit n’est pas un simple résumé technique : c’est une grille de lecture utile pour des équipes SOC, des RSSI et des responsables IT qui veulent réduire le temps de détection et limiter l’impact quand un fork d’AsyncRAT débarque via phishing, faux installateurs ou scripts.

Pourquoi AsyncRAT est un “problème IA” avant d’être un problème malware

AsyncRAT est un excellent exemple d’une réalité que beaucoup d’organisations sous-estiment : l’open source a abaissé le coût d’entrée pour industrialiser du malware. Dès qu’un framework est public, des acteurs peu expérimentés peuvent le recompiler, le reconfigurer, le packer, changer quelques chaînes et publier un « nouveau » RAT en quelques heures.

Le point clé : la menace n’évolue pas seulement dans le temps, elle évolue en branches. Vous ne faites pas face à « AsyncRAT », mais à un arbre généalogique qui comprend des forks très déployés (comme DcRat et VenomRAT) et des variantes plus exotiques, parfois même “blagueuses”, qui finissent malgré tout utilisées en production contre de vraies victimes.

L’IA devient centrale ici pour une raison simple : la classification à grande échelle. Quand les variantes se multiplient, le tri manuel explose. Les outils d’analyse augmentés par IA peuvent :

• regrouper automatiquement des échantillons par similarité de code, de configuration et de comportement,
• détecter des “traits de famille” malgré l’obfuscation,
• prioriser les branches les plus actives en s’appuyant sur la télémétrie.

Une phrase que je répète souvent aux équipes : “Les attaquants itèrent plus vite que vos signatures.” Contre les forks, il faut des modèles qui apprennent les invariants.

AsyncRAT : une base simple, une propagation incontrôlée

AsyncRAT, écrit en C#, propose un ensemble de fonctionnalités “classiques” pour un RAT : exécution de commandes, collecte de données, vol d’identifiants, surveillance de l’utilisateur. Sa popularité vient moins de son génie technique que de deux choix structurants :

1. Code public et modifiable : chacun peut forker et publier sa variante.
2. Architecture à plugins : on ajoute des capacités sans toucher au cœur (exfiltration, ransomware, webcam, etc.).

Côté héritage, AsyncRAT semble influencé par un autre RAT C# plus ancien (Quasar), notamment via des classes cryptographiques similaires pour le chiffrement/déchiffrement de configuration. Pour la défense, cela illustre un point opérationnel : les réutilisations de composants (crypto, sérialisation, routines réseau) créent des signatures “structurelles” plus stables que les artefacts superficiels (noms de fichiers, chaînes visibles, icônes).

Le piège : confondre “variantes” et “nouvelles menaces”

Dans un SOC, on tombe souvent dans l’un de ces deux extrêmes :

• Tout regrouper (“c’est du AsyncRAT, on connaît”) → on rate des plugins nouveaux (ex. ransomware, patch AMSI/ETW).
• Tout séparer (“nouveau hash = nouvelle menace”) → on sature la file d’incidents, on perd le fil des campagnes.

L’approche la plus efficace est intermédiaire : regrouper par lignée, et distinguer ensuite par capacité (plugins) et techniques d’évasion. C’est précisément là que l’IA aide : elle automatise le regroupement, puis met en évidence ce qui change réellement.

DcRat et VenomRAT : quand le fork devient plus dangereux que l’original

La réalité du terrain est claire : certaines branches dominent le volume d’attaques. Les analyses de télémétrie montrent que DcRat et VenomRAT font partie des forks les plus présents dans les campagnes observées.

DcRat : sérialisation efficace, évasion Windows, plugins “impact”

DcRat se distingue par un package fonctionnel et une logique d’évasion plus agressive. Trois éléments méritent l’attention côté défense :

• Sérialisation MessagePack : des échanges plus compacts, souvent plus rapides à traiter et parfois plus difficiles à inspecter si vos outils réseau sont limités.
• Patching AMSI et ETW : l’attaquant cherche à réduire la visibilité côté Windows (scripts scannés, traces d’événements). En clair : votre EDR voit moins de choses si l’attaque réussit.
• Système anti-process : terminaison de processus associés aux outils de diagnostic/sécurité (gestionnaire de tâches, moteurs AV, outils d’analyse). C’est un signal comportemental fort.

Point souvent négligé : DcRat apporte aussi des plugins “fun stuff” (CD tray, mouvement de souris, blocage clavier…). Ça semble anecdotique, mais en pratique, ce genre d’actions produit des indicateurs comportementaux très distinctifs. Bien exploités, ils peuvent nourrir des modèles de détection.

DcRat peut également inclure un plugin de type ransomware (chiffrement AES-256). C’est le scénario à redouter : un RAT sert d’accès initial, puis bascule en impact.

VenomRAT : un “super-set” de fonctionnalités

VenomRAT apparaît comme une variante très chargée en fonctionnalités, avec un client similaire à AsyncRAT mais un périmètre suffisamment large pour être traité comme une menace autonome. Pour les équipes de défense, cela renforce une idée simple : ne pas se limiter au nom de famille. Ce qui compte est le triptyque :

1. capacité (plugins),
2. évasion,
3. chaîne d’infection (packers, scripts, loaders).

Cartographier un labyrinthe de forks : ce que l’IA fait mieux que nous

Identifier un fork d’AsyncRAT “à la main” est faisable… mais pas à l’échelle. Les analystes utilisent souvent des indices comme :

• le champ Version dans la configuration,
• un Salt réutilisé dans la crypto,
• un certificat embarqué (CN/OU) pour l’authentification C2,
• et en dernier recours, l’inspection de code.

Ces méthodes marchent, mais elles reposent sur un défaut récurrent des attaquants : ils oublient d’effacer leurs traces. Dès qu’un acteur est plus rigoureux, la défense doit passer à un niveau supérieur.

Ce que l’IA peut automatiser (et fiabiliser)

Dans une approche moderne de threat intelligence augmentée par IA, on combine plusieurs couches :

1. Classification ML de familles/variants

   • embeddings de fonctions (similarité de code),
   • regroupement (clustering) d’échantillons,
   • détection d’anomalies pour repérer une nouvelle branche.

2. Analyse NLP des chaînes et configs

   • extraction automatique de paramètres de configuration,
   • normalisation des champs et comparaison inter-échantillons,
   • détection de motifs réutilisés (mêmes structures, mêmes valeurs “par défaut”).

3. Corrélation comportementale EDR/SIEM

   • séquences d’événements (processus → injection/patch → persistance → C2),
   • détection de “killswitch” défensifs (tentatives d’arrêt d’outils sécurité),
   • scoring de risque par environnement (poste utilisateur vs serveur).

La meilleure détection des forks repose sur des invariants : structure de config, logique réseau, comportements Windows. Les noms de fichiers, eux, changent tous les jours.

Variantes exotiques : pourquoi elles comptent malgré “moins de 1%”

Les forks moins courants sont utiles à étudier parce qu’ils annoncent souvent les tendances de demain : nouveaux plugins, nouveaux angles d’attaque, nouvelles méthodes d’obfuscation.

NonEuclid RAT : des plugins qui élargissent l’attaque

NonEuclid se démarque par des plugins inattendus, allant du gadget (screamer) à des fonctions franchement opérationnelles :

• Propagation via USB / infection de fichiers (WormUsb.dll) : un mécanisme qui contamine des exécutables et peut se diffuser via supports amovibles ou répertoires utilisateurs.
• Brute force distribué (Brute.dll) : l’idée est simple et efficace : utiliser un parc de machines compromises pour contourner des limitations basées sur IP.
• Clipper (cliper.dll) : surveillance du presse-papiers pour remplacer des adresses crypto, et collecte d’éléments ressemblant à des cartes bancaires.
• “Antivirus” de fortune : suppression de fichiers via correspondance MD5. Dans un conflit entre malwares, ce type de plugin peut servir à éliminer un concurrent.

Côté IA, ces plugins sont intéressants car ils créent des signatures comportementales très spécifiques (surveillance presse-papiers, scan de disques, modifications de PE, accès géolocalisation). Même si le code change, le comportement reste détectable.

JasonRAT : obfuscation et ciblage géographique

JasonRAT illustre une tendance fréquente : l’auteur investit plus dans l’obfuscation “artisanale” (noms de variables, chaînes encodées façon Morse étendu) que dans des innovations fonctionnelles. Pour la défense, ça confirme que :

• l’analyse statique pure a ses limites,
• la détection doit privilégier les patterns d’exécution (processus, API, persistance, réseau).

XieBroRAT : vol d’identifiants navigateur et intégration d’outils

Avec des plugins orientés vol d’identifiants navigateur et interaction avec d’autres frameworks (ex. connexions “reverse” vers des serveurs d’attaque), on voit une hybridation : AsyncRAT sert de plateforme, et l’attaquant branche des outils existants. L’IA aide ici à repérer des “assemblages” récurrents : mêmes bibliothèques intégrées, mêmes chaînes d’outils post-exploitation.

Mesures concrètes : réduire l’exposition aux forks d’AsyncRAT

La défense efficace contre AsyncRAT (et surtout ses forks) tient à une discipline simple : couper la chaîne avant que les plugins ne s’installent. Voici ce qui marche en pratique.

1) Passer d’une logique “signature” à une logique “comportement”

Priorisez des règles/alertes sur :

• tentatives de désactivation de composants de sécurité (AMSI/ETW, arrêt de processus sécurité),
• accès anormal aux identifiants et cookies, capture écran/clavier,
• surveillance du presse-papiers et patterns de remplacement,
• exécution d’assemblies .NET depuis des emplacements utilisateurs.

2) Exploiter l’IA pour le triage et la corrélation

Dans un SOC, l’IA est surtout rentable quand elle réduit le bruit :

• déduplication intelligente des alertes liées à une même campagne,
• regroupement automatique par lignée (AsyncRAT → DcRat-like → Venom-like),
• priorisation par impact potentiel (présence de plugins “ransomware”, “brute force”, “USB spreader”).

3) Mettre en place une “hygiène” anti-RAT réaliste

• durcissement PowerShell et scripts (contrôles d’exécution, journalisation),
• filtrage des pièces jointes et des exécutables “déguisés” (faux installateurs),
• segmentation : un poste utilisateur compromis ne doit pas voir l’admin interne,
• contrôle des périphériques amovibles si votre contexte le justifie.

Mon avis : si votre stratégie repose encore principalement sur des IOC statiques, vous aurez toujours un temps de retard sur les forks. L’IA n’est pas un gadget ici, c’est un multiplicateur de capacité.

Ce que ce cas dit de 2026 : la menace va se “personnaliser”

Fin 2025, on voit déjà une dynamique claire : la combinaison open source + modularité + automatisation favorise la personnalisation rapide. La prochaine marche logique, c’est l’industrialisation de forks “sur mesure” : obfuscation adaptée à la cible, plugins choisis selon le secteur, et chaînes d’infection localisées.

Dans la série « Intelligence artificielle dans la cybersécurité », AsyncRAT rappelle une règle : la vitesse appartient à ceux qui automatisent l’analyse. L’IA permet de suivre l’arbre des forks, de détecter les invariants, et de transformer une masse d’échantillons en décisions exploitables : bloquer, isoler, investiguer, prioriser.

Si vous deviez choisir un prochain pas concret, ce serait celui-ci : évaluer votre capacité à classifier et corréler automatiquement les variantes (config, comportement, réseau) plutôt que de courir après des noms. La question utile n’est pas “est-ce AsyncRAT ?”, mais : “à quelle branche appartient-il, et quel impact maximum peut-il déclencher chez nous ?”