AsyncRAT et ses forks : pourquoi l’IA doit guider la défense

AsyncRAT est devenu un symbole d’un problème très concret en cybersécurité : un malware “pas si impressionnant” peut quand même provoquer un chaos industriel dès lors qu’il est open source et facile à cloner. Depuis sa publication en 2019, ce RAT (Remote Access Trojan) a donné naissance à une galaxie de forks — certains très actifs (DcRat, VenomRAT), d’autres plus “gadget” mais tout de même observés dans la nature.

Ce qui change la donne pour les équipes SOC, ce n’est pas l’existence d’un énième cheval de Troie. C’est la vitesse à laquelle l’écosystème se ramifie, et la difficulté à distinguer un clone paresseux d’un dérivé doté d’évasion avancée (contournement AMSI/ETW, anti-process, plugins ransomware, etc.). Dans notre série « Intelligence artificielle dans la cybersécurité », AsyncRAT est un cas d’école : cartographier des variants à grande échelle est précisément un travail taillé pour l’IA.

AsyncRAT : l’effet “open source” appliqué au crime

AsyncRAT n’est pas redoutable parce qu’il est sophistiqué ; il l’est parce qu’il est reproductible. Un code accessible, des fonctionnalités standard (keylogging, capture d’écran, vol d’identifiants) et une architecture modulaire : c’est une recette parfaite pour multiplier les versions.

La filiation technique évoque aussi un phénomène récurrent : les familles se réécrivent plus qu’elles ne se forkent réellement. AsyncRAT partage des éléments (notamment des classes de cryptographie et paramètres) avec des projets antérieurs comme Quasar RAT (présent depuis 2015). Pour la défense, ça signifie une chose : se baser uniquement sur le nom de famille n’aide pas à prévoir le comportement, car les briques circulent d’un dépôt à l’autre.

Pourquoi ce point compte pour la détection

Quand un framework circule librement :

• les signatures “statiques” deviennent fragiles (renommage de variables, recompilation, packing) ;
• les indicateurs changent vite (C2, certificats, “salt” de chiffrement) ;
• le time-to-weaponize baisse : un acteur moyen peut déployer un RAT “acceptable” en quelques heures.

Ce contexte pousse vers une détection orientée comportement, enrichie par l’IA pour classer, corréler et prioriser.

Le labyrinthe des forks : quand la taxonomie devient un enjeu opérationnel

Le vrai défi, c’est la gestion de la diversité. Les forks s’empilent, se copient entre eux et réintroduisent des fonctions déjà vues ailleurs. Les plus répandus, souvent observés au centre des campagnes, sont DcRat et VenomRAT. Autour, une longue traîne de variantes moins courantes peut pourtant introduire une capacité “surprise” (propagation USB, brute force distribué, interaction avec des outils post-exploitation, etc.).

DcRat : la “version entreprise” du RAT

DcRat illustre une évolution classique : optimiser la communication et durcir l’évasion.

• Sérialisation via MessagePack : échanges plus efficaces et structurés.
• Évasion : patching AMSI et ETW (réduction de la visibilité côté Windows).
• Anti-process : arrêt de processus “gênants” (gestionnaire des tâches, outils d’analyse, composants de sécurité).
• Plugins : webcam, micro, vol de tokens, et même des modules “troll”.
• Plugin ransomware : chiffrement AES-256 avec clé fournie au moment de l’exécution du plugin.

Mon avis : ce n’est pas le “ransomware” qui est le plus dangereux ici, c’est l’assemblage “RAT + évasion + extensibilité”. La compromission initiale devient une plateforme, et la charge utile finale (vol, fraude, extorsion) peut changer à la demande.

VenomRAT : une surcouche dense, proche d’une famille à part

VenomRAT est souvent considéré comme une menace autonome tant les fonctionnalités s’accumulent. Pourtant, ses similarités côté client le rattachent à la sphère AsyncRAT. C’est typique des forks matures : le tronc commun reste, mais l’outillage périphérique explose.

Les forks “blague” : pas si inoffensifs

Des projets ouvertement humoristiques (ex. SantaRAT, BoratRAT) existent, parfois présentés comme des copies assumées. Le piège, côté défense, est de les sous-estimer : même un fork “mème” peut être utilisé dans une vraie attaque, ne serait-ce que pour l’accès initial, l’intimidation, ou la diversion.

Reconnaître un fork : ce que l’IA fait mieux que l’humain

Identifier rapidement la variante est utile, mais pas pour “coller une étiquette” : pour accélérer la réponse. Quels plugins sont probables ? Quelle persistance ? Quel niveau d’évasion ? Quel risque de mouvement latéral ?

Les analystes disposent de plusieurs “marqueurs” côté client :

1. Champ Version dans la configuration (souvent parlant… quand il n’est pas vide). Une grande majorité des échantillons incluent une valeur exploitable.
2. Paramètres de chiffrement / Salt : un détail fréquemment oublié lors du copier-coller.
3. Certificat embarqué pour authentifier le serveur C2 : le décodage peut révéler un CN/OU réutilisé d’un fork précédent.
4. Analyse manuelle du code (quand tout le reste a été nettoyé).

Où l’IA apporte un gain immédiat

L’IA est particulièrement efficace sur trois tâches, souvent chronophages en SOC :

• Clustering de variantes : regrouper automatiquement des binaires “proches” malgré l’obfuscation légère (renommage, réordonnancement, compilation différente).
• Corrélation multi-signal : relier configuration, patterns réseau, empreintes de certificats, et comportements d’exécution.
• Priorisation : distinguer un clone basique d’un fork qui ajoute contournement AMSI/ETW ou un module d’impact (type chiffrement).

Phrase à retenir : la valeur de l’IA n’est pas de “deviner le nom du RAT”, mais d’estimer le risque et la trajectoire probable de l’attaque.

Variantes exotiques : pourquoi la “longue traîne” mérite de l’attention

Les forks rares représentent peu de volume, mais ils testent des idées. Et les idées efficaces finissent souvent dans des forks plus diffusés.

NonEuclid RAT : des plugins qui changent le scénario d’attaque

NonEuclid se démarque par des plugins inhabituels. Certains sont anecdotiques (jump scare, lecture audio), d’autres sont opérationnellement préoccupants :

• Propagation et infection de binaires (type “WormUsb”) : insertion d’un stub qui exécute d’abord la charge utile, puis le programme original. C’est un mécanisme très utile pour l’attaquant : persistance “par usage”, propagation et camouflage.
• Brute force SSH/FTP : tentative distribuée depuis un parc de machines compromises. C’est une façon simple de contourner des limites basées sur l’IP.
• Clipper crypto : surveillance du presse-papiers et remplacement d’adresses de portefeuille.
• “Antivirus” par hash : suppression de fichiers EXE correspondant à une liste de MD5 (outil parfait pour supprimer un concurrent… ou un agent de sécurité mal identifié).

Pour une organisation, ça se traduit par des risques très concrets : fraude financière, propagation via supports amovibles, rebond vers des serveurs exposés (SSH/FTP), et destruction ciblée de fichiers.

JasonRAT : obfuscation “artistique”, objectif très pratique

JasonRAT illustre une réalité : l’obfuscation n’a pas besoin d’être “élite” pour coûter cher en temps d’analyse. Nommage ésotérique, chaînes brouillées (jusqu’à une variante de code Morse), et ajout de ciblage géographique : on est sur de la friction, destinée à ralentir le triage et la rétro-ingénierie.

XieBroRAT : localisation et intégration d’outils open source

XieBroRAT montre deux tendances fortes :

• localisation (pour faciliter l’adoption par certaines communautés) ;
• assemblage d’outils empruntés à l’open source (vol d’identifiants navigateur, interaction avec des frameworks post-exploitation, etc.).

La leçon : les forks ne réinventent pas tout ; ils intègrent vite ce qui marche.

Détection et réponse : un plan d’action “IA + hygiène” réaliste

La bonne stratégie n’est pas de chasser chaque fork ; c’est d’empêcher AsyncRAT (et consorts) de garder la main. Voici ce que je recommande en pratique, surtout pour les environnements Windows hétérogènes.

1) Miser sur le comportement, pas sur le nom

Visez des détections orientées :

• exécution anormale de .NET dans des contextes utilisateurs (AppData, Temp) ;
• création de persistance (clé Run, tâches planifiées) ;
• capture d’écran, accès webcam/micro, hooks clavier ;
• accès massif aux navigateurs et dépôts d’identifiants ;
• tentative de neutralisation d’outils (arrêt de processus, altération de télémétrie).

L’IA peut renforcer ces règles en réduisant les faux positifs (profilage par poste, par groupe métier, par horaires) et en détectant des combinaisons d’événements rares.

2) Traquer les signaux “faibles” qui révèlent une lignée

Même quand les attaquants nettoient, des invariants restent :

• structures de configuration ;
• schémas de chiffrement ;
• artefacts de certificats ;
• patterns de communication C2.

Un modèle de corrélation (graphes, similarité, clustering) permet de relier un nouvel échantillon à une campagne avant même d’avoir tout désassemblé.

3) Préparer la réponse aux plugins (pas seulement au RAT)

Posez-vous une question simple : si le RAT est là, quel plugin arrive ensuite ? Les réponses typiques :

• vol de sessions / tokens (messageries, outils collaboratifs) ;
• reconnaissance (inventaire machine, réseau) ;
• impact (chiffrement, suppression) ;
• rebond (brute force, outils post-exploitation).

En SOC, j’ai vu que cette approche “par trajectoire” améliore la réponse : on isole plus vite les actifs critiques, on surveille les comptes sensibles, et on limite les dégâts.

4) Fin 2025 : pourquoi le sujet devient plus pressant

En cette fin d’année 2025, beaucoup d’organisations figent des changements pendant les congés, alors que les attaquants, eux, continuent. Les périodes de sous-effectif sont idéales pour des RAT modulaires : un accès initial discret, puis activation progressive de plugins.

C’est aussi là que l’IA aide vraiment : automatiser le triage, regrouper les alertes, réduire le temps entre le premier signal et l’isolement.

Ce que AsyncRAT nous apprend sur l’IA en cybersécurité

AsyncRAT et ses forks montrent une vérité simple : la défense doit suivre un rythme industriel, alors que l’analyse manuelle est artisanale. On ne gagnera pas en “lisant plus de rapports”, mais en combinant une bonne hygiène de sécurité (durcissement, contrôle d’exécution, EDR bien configuré) avec une couche IA capable de comprendre les relations entre échantillons, infrastructures et comportements.

Si vous ne deviez retenir qu’une idée : cartographier les forks, c’est utile ; cartographier les comportements, c’est vital. La prochaine itération d’AsyncRAT (ou d’un autre framework open source) ne sera peut-être pas “plus intelligente”. Elle sera juste plus rapide à se multiplier.

Et chez vous : votre détection est-elle prête à reconnaître une lignée de menaces… ou seulement un hash déjà connu ?