Comment le Centre canadien pour la cybersécurité utilise l’IA de pointe pour accélérer la rétro-ingénierie des maliciels

Introduction aux travaux du Centre de la sécurité des télécommunications Canada liés à l'intelligence artificielle en cyberdéfense

Cet article technique est le deuxième d'une série consacrée aux travaux du laboratoire d'IA de pointe. Pour en savoir plus sur le laboratoire d'IA de pointe, consultez notre premier article : Comment le Centre canadien pour la cybersécurité a utilisé l'IA de pointe pour accélérer l'ingénierie des détections. La série présente les résultats des recherches du laboratoire, notamment les applications potentielles de l'IA de pointe en cyberdéfense, les limites de ces technologies, ainsi que les considérations liées à leur utilisation efficace, sécuritaire et responsable.

Ce deuxième article porte sur la rétro-ingénierie des maliciels, soit le processus consistant à déconstruire un maliciel sans disposer de son code source d'origine afin d'aider les responsables de la cyberdéfense à comprendre son fonctionnement et son objectif. À mesure que les cybermenaces continuent d'évoluer et que les organisations traitent des volumes croissants de données, l'IA pourrait appuyer certains aspects de ce travail.

En s'appuyant sur des scénarios de test, l'article examine comment le projet pilote a utilisé l'IA pour transformer des échantillons de maliciels inconnus en produits de renseignement validés. L'évaluation a examiné comment l'IA pouvait aider les analystes dans des activités telles que le triage, l'ingénierie des détections et la production de rapports. Tout au long du projet pilote, une supervision humaine est demeurée au cœur du processus : les analystes ont orienté les enquêtes, validé les constats et examiné les évaluations d'attribution.

Sur cette page

• Aperçu : Fonctionnement du pipeline de rétro-ingénierie des maliciels alimenté par l'IA
• Échantillon de maliciel 1 : Analyse d'un chargeur dissimulé
• Échantillon de maliciel 2 : Un programme d'installation inconnu résistant à l'analyse
• Résultats et avantages opérationnels
• Prochaines étapes de l'utilisation de l'IA de pointe par le Centre pour la cybersécurité

Aperçu : Fonctionnement du pipeline de rétro-ingénierie des maliciels alimenté par l'IA

Dans le cadre du projet pilote, le Centre pour la cybersécurité a utilisé des modèles d'IA de pointe pour mettre en place un pipeline automatisé de rétro-ingénierie des maliciels. Le pipeline a été conçu pour transformer des échantillons de logiciels malveillants inconnus en produits de renseignement validés, tout en réduisant au minimum l'intervention humaine.

Pour les échantillons évalués, les produits de renseignement comprenaient des rapports d'analyse, un mappage avec MITRE ATT&CK, des règles de détection YARA, des signatures réseau et des extracteurs de configuration prêts à être déployés dans Assemblyline 4, l'outil de détection et d'analyse de maliciels du Centre pour la cybersécurité.

Dans le cadre de ce projet pilote, Mythos a été doté des mêmes outils que ceux utilisés par une ou un spécialiste de la rétro-ingénierie, notamment :

• un désassembleur et un décompilateur
• le corpus du Centre pour la cybersécurité contenant des dizaines de milliers de règles de détection YARA
• des décompilateurs .NET et Python
• des cadres logiciels d'émulation de processeur

Concrètement, Mythos coordonnait plusieurs outils spécialisés et marquait des arrêts à des étapes clés afin de vérifier les résultats avant de poursuivre l'analyse. Cela a contribué à garantir que les résultats produits par le système étaient étayés par des éléments observables et que toutes les détections proposées fonctionnaient comme prévu.

Mythos a ensuite coordonné ces outils par l'intermédiaire d'une couche d'orchestration dotée de points de contrôle, qui appliquait deux mesures de protection :

1. Chaque affirmation factuelle figurant dans un rapport devait pouvoir être reliée à un résultat d'outil vérifiable.
2. Chaque artéfact de détection devait être validé à l'aide de l'échantillon réel et évalué par rapport à un corpus plus vaste avant d'être enregistré sur disque, afin de garantir qu'il identifie de façon fiable l'artéfact visé tout en réduisant au minimum les détections non souhaitées.

Figure 1 : Pipeline complet de rétro-ingénierie des maliciels

Pipeline complet de rétro-ingénierie des maliciels - Description détaillée

La figure présente le flux de travaux automatisé de rétro-ingénierie, depuis l'ingestion de l'échantillon jusqu'à la vérification manuelle. La figure présente les différentes étapes du pipeline : la classification et le triage à l'aide du corpus de règles YARA, l'acheminement vers un parcours d'analyse natif, .NET ou de scripts, l'analyse approfondie en parallèle dans six domaines techniques, l'extraction des charges utiles et la réanalyse récursive des étapes récupérées, puis la génération et la validation des artéfacts. La figure montre comment des mécanismes de validation déterministes encadrent le modèle à chacune des étapes du processus avant que les artéfacts ne soient soumis à l'examen des analystes.

Le pipeline commence par l'ingestion d'échantillons de maliciels soumis directement au Centre pour la cybersécurité. Les cas d'essai suivants illustrent comment ce flux de travaux a été appliqué en pratique.

Échantillon de maliciel 1 : Analyse d'un chargeur dissimulé

Le premier échantillon de maliciel démontre comment le pipeline a pris en charge un cas de rétro-ingénierie particulièrement complexe.

Maliciels

Le premier échantillon a été conçu pour rendre difficile la récupération de son contenu caché. Il combinait un mécanisme de chiffrement peu courant à plusieurs couches d'obscurcissement, ce qui obligeait le pipeline à reconstituer la façon dont le maliciel générait ses clés avant de pouvoir révéler la charge utile dissimulée.

Cet échantillon de maliciel était un chargeur développé en Go (Golang) et traité à l'aide d'un compilateur d'obscurcissement. Il protégeait sa charge utile au moyen d'un modèle que ses chaînes de caractères internes décrivaient comme « PQC-PE-AES256GCM ». L'algorithme d'encapsulation de clés post-quantique (ML-KEM-768) était utilisé pour dériver les clés servant à chiffrer 48 segments au moyen d'AES-256-GCM, tandis que le matériel de chiffrement sous-jacent était lui-même fractionné, mélangé et masqué.

Remarque : Dans ce contexte, la cryptographie post-quantique ne procurait vraisemblablement aucun avantage opérationnel significatif à la sécurité opérationnelle du logiciel malveillant. Son objectif probable était d'accroître la complexité de l'analyse en obligeant les responsables de la défense à comprendre et à reproduire un processus inhabituel d'encapsulation de clés et de déchiffrement avant de pouvoir récupérer la charge utile.

Triage YARA, classification et acheminement

Tous les échantillons sont analysés à l'aide de l'ensemble du corpus YARA du Centre pour la cybersécurité, qui contient des dizaines de milliers de règles compilées. Ce triage est appliqué non seulement à chaque échantillon reçu, mais également à chaque charge utile récupérée, puisque les étapes de traitement subséquentes sont tout aussi susceptibles de correspondre à une famille de maliciels connue que le fichier qui l'a distribuée.

Cette étape initiale de triage est essentielle, car une correspondance avec le corpus peut changer de façon significative l'ampleur de l'effort d'analyse et procurer trois avantages immédiats :

1. Une identité de travail : une correspondance associée à une famille permet de rattacher l'échantillon à l'ensemble des connaissances que le Centre pour la cybersécurité possède déjà sur cette famille de maliciels. Si un extracteur existant permet de récupérer la configuration de commande et contrôle, l'analyse peut être conclue en quelques minutes, ce qui permet d'orienter l'échantillon vers les outils déjà établis plutôt que de recourir à une analyse manuelle.
2. Points de départ fondés sur des preuves : chaque règle comprend les décalages des chaînes de caractères ou des motifs d'octets qui ont produit une correspondance. Puisque la règle documente les caractéristiques de la famille de maliciels qu'elle a été conçue pour détecter, ces décalages fournissent des points de départ concrets pour les activités de validation et d'analyse.
3. Éléments probants négatifs utiles : même les correspondances imparfaites fournissent des renseignements utiles. Si un échantillon déclenche une règle associée à une famille, mais que les autres éléments probants ne concordent pas, cet écart devient une hypothèse précise à examiner.

Ensemble, ces résultats contribuent à transformer des enquêtes ouvertes en analyses ciblées, fondées sur des preuves vérifiables.

Le triage YARA permet de transformer les premiers constats en hypothèses ciblées pouvant être mises à l'épreuve, plutôt que d'obliger les analystes à examiner un échantillon à partir de zéro. Dans ce cas, ni l'échantillon d'origine ni les charges utiles récupérées ne correspondaient à une famille de maliciels connue dans le corpus YARA du Centre pour la cybersécurité; le flux de travaux est donc passé à une analyse complète.

Analyse approfondie par l'IA et extraction de la charge utile

Pour récupérer la charge utile dissimulée, le modèle devait d'abord comprendre la logique du maliciel, puis reproduire de manière sécuritaire uniquement les parties de son comportement nécessaires à la génération des clés de déchiffrement appropriées. Les étapes suivantes décrivent comment il a combiné l'analyse du code et l'émulation contrôlée pour y parvenir.

Le modèle a utilisé le décompilateur pour analyser le code dissimulé du chargeur. Il a identifié le modèle cryptographique en analysant la structure du code plutôt qu'en recherchant des constantes connues, puis a reconstitué la chaîne de dérivation des clés.

L'analyse statique a finalement atteint du matériel de chiffrement que le logiciel malveillant ne générait qu'au moment de son exécution. Pour résoudre ce problème, l'agent a créé un environnement d'émulation personnalisé d'unité centrale de traitement (UCT) pour l'environnement d'exécution Go. Il a ensuite exécuté le processus de dérivation nécessaire et recueilli les clés générées ainsi que la séquence des segments chiffrés.

Comme le maliciel avait été délibérément modifié pour résister à l'analyse, son exécution intégrale dans l'environnement d'émulation n'était pas possible. Le système a plutôt traité chaque problème individuellement, en préservant les fonctions nécessaires au déchiffrement tout en simulant de façon sécuritaire les parties moins importantes du programme.

L'émulation d'un binaire Go dissimulé constitue souvent un processus itératif guidé par les analystes. Chaque exécution pouvait échouer dans différentes fonctions d'exécution, ce qui nécessitait des cycles répétés d'analyse des plantages, d'émulation des fonctionnalités et de réexécution. Dans ce cas, l'agent a automatisé ce processus en créant la boucle d'autoamélioration suivante autour de son environnement d'émulation :

• lorsqu'un plantage survenait, l'agent utilisait le désassembleur pour localiser la fonction contenant l'instruction à l'origine de l'erreur, la substituait par un élément de remplacement, puis relançait l'exécution de l'échantillon;
• une liste de fonctions protégées empêchait toute modification de la logique de dérivation des clés. Si un plantage survenait dans une fonction protégée, l'agent l'interprétait comme un indice qu'une fonction appelante en amont avait fourni une entrée non valide et substituait alors cette fonction par un élément de remplacement, plutôt que la fonction ciblée
• les fonctions de l'environnement d'exécution ayant une sémantique réelle étaient mises en œuvre fidèlement plutôt que substituées par des éléments de remplacement simplifiés, puisqu'elles pouvaient générer des clés plausibles, mais incorrectes
• chaque valeur enregistrée faisait l'objet d'une dérivation indépendante au moyen d'une implémentation Python distincte avant d'être utilisée par les étapes subséquentes de l'analyse
• si la même fonction était à l'origine de plantages répétés, la boucle était interrompue et le cas était transmis à une ou un analyste

Figure 2 : La boucle d'autoamélioration simplifiée

La boucle d'autoamélioration simplifiée - Description détaillée

La figure illustre un flux de travaux itératif d'émulation dans lequel un plantage accompagné d'une adresse fautive déclenche une recherche dans le désassembleur à partir de l'environnement Unicorn (itération N), ce qui mène soit à la création d'un nouvel élément de remplacement, soit à celle d'un élément de remplacement appliqué à une fonction appelante en amont lorsque la fonction concernée se situe sur un chemin protégé de dérivation des clés. Une étape décisionnelle détermine ensuite si une capture a été effectuée; dans l'affirmative, les clés et la séquence des segments chiffrés sont vérifiées au moyen d'une implémentation Python pure; dans le cas contraire, le système vérifie si la même fonction a provoqué un plantage à deux reprises. Si c'est le cas, l'exécution est interrompue et le dossier est envoyé à un niveau supérieur à une ou un analyste; sinon, le processus passe à l'itération suivante.

Cette étape était importante, car la dérivation des clés de l'échantillon dépendait du résultat de sa logique anti-débogage. Le simple contournement de ces vérifications permettait à l'émulation de se poursuivre, mais produisait une clé plausible, quoiqu'incorrecte.

Au cours du projet pilote, le modèle et l'environnement d'agent d'analyse des maliciels ont établi la relation entre les résultats des mécanismes anti-débogage et le matériel de chiffrement dérivé. L'environnement a ensuite été ajusté de manière à préserver le comportement requis plutôt qu'à le contourner. Cette approche a ensuite été intégrée au pipeline d'évaluation en tant que capacité réutilisable pour les échantillons dont les mécanismes anti-analyse influencent le déchiffrement ou la récupération de la charge utile.

Les clés et la séquence des segments chiffrés récupérées grâce à l'émulation ont ensuite été utilisées pour créer un extracteur de charge utile pour le chargeur. En reproduisant hors du maliciel le flux de travaux de déchiffrement de l'échantillon, l'extracteur a pu récupérer statiquement la charge utile intégrée.

Détections proposées, validation et résultats

Au cours de l'évaluation, les résultats produits par l'extracteur ont été comparés à une charge utile précédemment récupérée en mémoire vive au moyen d'un débogage manuel réalisé par une ou un analyste. La charge utile de 195 Ko récupérée de manière statique correspondait exactement, octet pour octet, à la version récupérée manuellement.

Les essais réalisés sur des échantillons apparentés ont indiqué que cette technique fonctionnait pour cinq versions distinctes de cette famille de maliciels. Chaque étape récupérée était ensuite réinjectée dans le pipeline afin de faire l'objet d'une nouvelle analyse et d'un nouveau balayage. Ce processus a permis d'identifier la famille de maliciels ACR Stealer et d'établir un lien entre ce nouveau chargeur et des activités malveillantes déjà observées.

Par conséquent, une série d'éléments livrables a été produite puis examinée par une ou un analyste avant d'être transmise à un client ou mise en production :

• un rapport technique complet comprenant un mappage avec MITRE ATT&CK
• des règles YARA pour le chargeur et ses artéfacts de distribution
• un extracteur de configuration et de charge utile conçu pour le Centre pour la cybersécurité et intégré à sa plateforme automatisée d'analyse de maliciels au moyen du cadre MACO de source ouverte

Figure 3 : Résultats de l'extracteur de charge utile Gatestomp

Résultats de l'extracteur de charge utile Gatestomp - Description détaillée

L'image montre une capture d'écran de l'interface « ConfigExtractor » affichant des renseignements sur le chargeur Gatestomp ainsi qu'une description faisant référence à un analyseur de configuration PQC-PE-AES256GCM. Dans la partie inférieure, une section de type JSON intitulée Other data répertorie une charge utile sous l'entrée binaries, accompagnée de données encodées et d'une liste decoded_strings contenant notamment des chemins d'accès de fichiers système Windows, tels que ntdll.dll et wmsxml3.dll. Dans l'ensemble, l'interface illustre comment l'analyseur met en évidence à la fois des attributs de haut niveau et des artéfacts de bas niveau afin d'aider les spécialistes de la rétro-ingénierie à valider l'identification de la famille, à confirmer les caractéristiques de chiffrement et du mécanisme de protection, et à orienter leurs recherches sur les menaces à partir des indicateurs décodés.

Échantillon de maliciel 2 : Un programme d'installation inconnu résistant à l'analyse

Le deuxième échantillon de maliciel démontre la capacité du pipeline à reconstituer rapidement la chaîne de distribution, en évitant de se laisser distraire par la taille de l'échantillon, ses signatures et son contenu leurre.

Maliciels

Cet échantillon de maliciel reposait sur trois programmes d'installation surdimensionnés, signés de manière légitime, conçus pour ressembler à des logiciels commerciaux ordinaires et pour détourner les efforts d'analyse automatisée. Chaque programme d'installation :

• avait une taille variant entre 76 Mo et 175 Mo
• était doté d'une signature Authenticode Microsoft légitime
• comprenait une structure d'apparence légitime, des environnements d'exécution intégrés et de grandes quantités de contenu leurre

La fonctionnalité malveillante était minime, mais délibérément dissimulée.

Triage YARA, classification et acheminement

Comme indiqué précédemment, tous les échantillons sont analysés à l'aide de l'ensemble du corpus YARA du Centre pour la cybersécurité, qui contient des dizaines de milliers de règles compilées. Ce triage est appliqué non seulement à chaque échantillon reçu, mais également à chaque charge utile récupérée, puisque les étapes de traitement subséquentes sont tout aussi susceptibles de correspondre à une famille de maliciels connue que le fichier qui l'a distribuée.

Cette étape initiale de triage est essentielle, car une correspondance avec le corpus peut changer de façon significative l'ampleur de l'effort d'analyse et procurer trois avantages immédiats :

1. Une identité de travail : Une correspondance associée à une famille permet de rattacher l'échantillon à l'ensemble des connaissances que le Centre pour la cybersécurité possède déjà sur cette famille de maliciels. Si un extracteur existant permet de récupérer la configuration de commande et contrôle, l'analyse peut être conclue en quelques minutes, ce qui permet d'orienter l'échantillon vers les outils déjà établis plutôt que de recourir à une analyse manuelle.
2. Points de départ fondés sur des preuves : Chaque règle comprend les décalages des chaînes de caractères ou des motifs d'octets qui ont produit une correspondance. Puisque la règle documente les caractéristiques de la famille de maliciels qu'elle a été conçue pour détecter, ces décalages fournissent des points de départ concrets pour les activités de validation et d'analyse.
3. Éléments probants négatifs utiles : Même les correspondances imparfaites fournissent des renseignements utiles. Si un échantillon déclenche une règle associée à une famille, mais que les autres éléments probants ne concordent pas, cet écart devient une hypothèse précise à examiner.

Ensemble, ces résultats contribuent à transformer des enquêtes ouvertes en analyses ciblées, fondées sur des preuves vérifiables.

Le triage initial a permis de déterminer que les fichiers étaient des documents composites OLE et des programmes d'installation MSI, plutôt que des exécutables traditionnels. En l'absence de toute correspondance avec une famille de maliciels dans l'ensemble du corpus YARA, l'échantillon a été considéré comme inconnu et acheminé vers une analyse complète.

Analyse approfondie par l'IA et extraction de la charge utile

Pour le deuxième échantillon, la principale tâche consistait à isoler la petite portion de code malveillant d'un important volume de fichiers d'apparence légitime et d'éléments de remplissage. Plutôt que d'examiner chaque fichier en profondeur, le pipeline a suivi la structure du programme d'installation afin de déterminer quels composants étaient réellement exécutés.

L'analyse a permis de reconstituer statiquement la chaîne de distribution. Chaque programme d'installation MSI, créé à l'aide d'un outil d'empaquetage couramment accessible, contenait une archive Cabinet (CAB) intégrée dans un flux de données OLE. L'extraction de l'archive a produit de 105 à 144 fichiers représentant entre 137 Mo et 231 Mo de données non compressées, dont la presque totalité correspondait à du contenu leurre, notamment :

• un script de lancement d'une seule ligne
• un environnement d'exécution Python complet et légitime intégré
• un script d'entrée camouflé sous l'apparence d'un fichier texte anodin.

Le script d'entrée constituait l'élément distinctif de cette famille de maliciels. Dissimulée dans des pages de texte de remplissage, une seule ligne se décodait, d'abord depuis le Base64 puis depuis l'UTF-32, pour produire un téléchargeur de huit lignes.

Le téléchargeur récupérait du contenu à partir d'une adresse URL au moyen d'un canal de protocole TLS sans vérifier le certificat, attendait un intervalle prédéfini, puis exécutait la réponse obtenue. Cette courte séquence est devenue le principal point d'intérêt de l'évaluation, puisqu'elle révélait la capacité malveillante fondamentale de l'échantillon.

L'auteur de menace a misé sur les éléments suivants :

• l'achat d'un certificat de signature de code
• un corpus de 100 fichiers leurres
• des centaines de mégaoctets de contenu de remplissage
• un environnement d'exécution intégré dont la conception visait à rendre difficile l'analyse détaillée, tant par les outils automatisés que par l'analyste humain

Le défi ne résidait pas dans la complexité de la chaîne de distribution, mais dans le volume de contenu qui l'entourait. Le modèle a suivi directement la structure du programme d'installation à partir des éléments suivants :

• du programme d'installation à l'archive
• de l'archive au script de lancement
• du script de lancement au fichier qu'il exécutait

Une fois arrivée à cette étape, la ligne cachée est ressortie clairement, car elle constituait le seul contenu qui se décodait en une charge utile significative. Dans le cadre de cette évaluation, le flux de travaux a complété le parcours structurel et le processus de décodage en moins d'une seconde par échantillon.

Figure 4 : Une seule ligne parmi les leurres

Une seule ligne parmi les leurres - Description détaillée

La figure montre, à gauche, une reconstitution du script d'entrée de cette famille, où plusieurs pages de texte de remplissage composé de mots issus d'un dictionnaire entourent une unique ligne encodée mise en évidence. À droite, elle présente le comportement du téléchargeur de huit lignes révélé par le décodage de cette ligne, sans toutefois divulguer le code lui-même : importation de bibliothèques standard, désactivation de la vérification des certificats TLS, récupération de contenu à partir d'une infrastructure contrôlée par l'auteur de menace, attente pendant un intervalle fixe, puis exécution de la réponse obtenue. La légende souligne l'asymétrie à laquelle sont confrontés les responsables de la défense : repérer manuellement cette ligne exige l'extraction d'une archive de plusieurs centaines de mégaoctets, alors que l'extracteur la récupère et la décode de façon structurelle en quelques millisecondes.

Chaque étape récupérée a de nouveau été analysée au moyen du corpus du Centre pour la cybersécurité. Toutefois, l'infrastructure de commande et contrôle n'était plus active, ce qui a empêché l'observation de l'étape récupérée à partir du serveur. Plutôt que de spéculer sur cette étape, le rapport l'a classée comme inconnue.

Validation, examen par les analystes et mise en production

Une fois la chaîne de distribution reconstituée, le défi suivant consistait à identifier des caractéristiques suffisamment stables pour permettre une détection fiable par les responsables de la défense. L'analyse s'est donc concentrée sur les comportements essentiels au fonctionnement du maliciel, plutôt que sur des détails que la développeuse ou le développeur pouvait facilement modifier d'une version à l'autre.

La comparaison des trois échantillons a montré que le générateur modifiait de façon aléatoire presque toutes les caractéristiques qu'un analyste pourrait utiliser à des fins d'attribution. Le seul artéfact constant observé dans l'ensemble des versions était l'expression « decoy padding » (contenu de remplissage leurre), ce qui lui a valu le nom Lexiloader, dérivé du mot « lexique ». Toutefois, la logique de détection ne reposait pas uniquement sur le nom ou sur le contenu de remplissage leurre. Elle reposait plutôt sur des caractéristiques qui ne pouvaient pas être modifiées d'une version à l'autre sans revoir l'ingénierie de la chaîne de distribution elle-même, notamment :

• le mécanisme de téléchargement suivi de l'exécution
• la désactivation délibérée de la vérification des certificats TLS
• la séquence de décodage du texte qui transforme une unique ligne dissimulée dans le contenu de remplissage en code exécutable

Environ trois heures après la réception de l'échantillon, le pipeline pilote a produit une série de livrables. La production manuelle du même ensemble de livrables aurait normalement exigé un effort considérable de la part des analystes :

• un extracteur complet de configuration prêt à être intégré au Cadre d'analyse automatisée des maliciels - Chaîne de montage (Assemblyline 4), ne nécessitant qu'une analyse syntaxique au moyen de la bibliothèque standard de la structure OLE, l'extraction d'une archive et une seule opération de décodage
• des contrôles automatisés fondés sur des résultats de référence validés afin de confirmer que l'extracteur récupérait systématiquement la même configuration et la même charge utile à partir de chaque échantillon
• une validation menée sur les trois échantillons au moyen de résultats de référence validés, produisant à la fois la configuration commande et contrôle extraite et le chargeur intermédiaire décodé comme artéfacts enfants afin qu'ils soient automatiquement soumis à un nouveau balayage dans Assemblyline
• trois règles YARA candidates couvrant le porteur, le chargeur intermédiaire et une variante observée indépendante du vecteur de distribution, chacune ayant réussi la validation des règles YARA du Centre pour la cybersécurité sans erreur ni avertissement
• un rapport technique complet comprenant un mappage avec MITRE ATT&CK
• des règles YARA couvrant le porteur, le chargeur intermédiaire décodé et une variante indépendante du vecteur de distribution
• un extracteur de configuration et de charge utile conçu pour le Centre pour la cybersécurité et intégré à sa plateforme automatisée d'analyse de maliciels au moyen du cadre MACO de source ouverte

Figure 5 : Résultats obtenus par l'extracteur Lexiloader

Résultats obtenus par l'extracteur Lexiloader - Description détaillée

Cette figure présente les résultats produits par un extracteur de configuration Lexiloader au sein de la plateforme Assemblyline d'analyse de maliciels. L'extracteur a identifié la famille de maliciels, récupéré les indicateurs réseau de commande et contrôle et décodé un téléchargeur Python intégré de première étape, en affichant l'URL associée, le nom d'hôte, les paramètres de communication ainsi que les métadonnées de la charge utile extraite. La configuration récupérée est présentée dans un format structuré comprenant la charge utile décodée, la méthode d'extraction, le hachage cryptographique ainsi que les détails du processus de mise en place du chargeur. Les résultats démontrent la capacité du système à récupérer et à décoder automatiquement les données de configuration du maliciel, afin d'appuyer les activités subséquentes d'analyse et de détection.

Les règles demeurent à l'étape des essais en attendant leur mise en production. Dans le cadre de cette évaluation, environ cinq heures de travail de l'agent ont permis de produire un volume de travail estimé équivalent à environ une semaine d'efforts d'analyse conventionnels. L'évaluation structurelle initiale, consistant à déterminer que les échantillons ne correspondaient à aucune famille présente dans le corpus et à reconstituer leur chaîne de distribution, a été réalisée en six minutes grâce à des vérifications déterministes effectuées dès la réception des échantillons.

Résultats et avantages opérationnels

Une rétro-ingénierie manuelle aussi approfondie peut nécessiter plusieurs jours de travail de la part d'une ou un analyste, voire plusieurs semaines dans le cas d'échantillons complexes. Au cours de la période d'évaluation, le pipeline a mené à bien cinq analyses complexes touchant quatre familles distinctes de maliciels en environ 46 heures.

L'évaluation a démontré les gains d'efficacité les plus marqués lorsque l'environnement de l'agent d'analyse des maliciels ramenait à quelques minutes d'analyse assistée par des outils des tâches qui auraient autrement exigé plusieurs heures d'intervention spécialisée. Ces résultats ont été observés dans plusieurs échantillons distincts. Parmi les autres faits saillants du projet pilote, on peut notamment citer :

• Échantillon de maliciel 3 : récupération complète d'une chaîne d'attaque PowerShell en cinq étapes, sans exécuter le code de l'auteur de menace. Le modèle a réduit 217 Ko de code grandement dissimulé à 15 Ko de code source lisible, ce qui a permis la récupération statique des étapes ultérieures qui auraient échappé à une analyse traditionnelle dans un environnement de bac à sable.
• Échantillon de maliciel 4 : établissement d'un lien entre deux échantillons de chargeur stéganographique et une même exécution du générateur grâce à une analyse au niveau des octets. Les deux échantillons ont été entièrement déconstruits au moyen d'une chaîne de décodage en quatre étapes, permettant la récupération des 31 modules internes du chargeur ainsi que des configurations complètes de commande et contrôle de la charge utile.
• Échantillon de maliciel 5 : identification d'une famille de maliciels jusque-là non nommée en moins de six minutes, après que quatre vérifications structurelles indépendantes ont contredit l'étiquette associée aux échantillons. L'approche privilégiait des vérifications peu coûteuses et déterministes :
  • identification du format de fichier (fichiers MSI signés)
  • un mécanisme de contrôle de la signature de code reposant sur neuf octets dans l'extracteur de configuration de la famille existante
  • des tests YARA bidirectionnels consistant à appliquer les règles de la famille identifiée aux porteurs et aux charges utiles décompressées, puis à effectuer l'opération inverse
  • une anomalie comportementale observée dans l'environnement de bac à sable, signalée dès la réception de l'échantillon par l'analyste

Dans l'ensemble, le projet pilote laisse entendre que l'IA de pointe peut contribuer à accélérer certaines étapes de l'analyse des maliciels et à soutenir la production en temps opportun de renseignements de grande qualité. L'évaluation a également démontré que les composantes les plus importantes étaient les mécanismes de protection entourant le modèle, lesquels avaient été conçus et encadrés par des analystes expérimentées et expérimentés. En automatisant certaines composantes mécaniques du processus de rétro-ingénierie, le projet pilote a permis aux analystes de consacrer moins de temps aux tâches répétitives et davantage de temps :

• à la création, à l'examen et à l'approbation de produits de renseignement
• à l'exploration de questions liées aux campagnes d'activité malveillante, souvent reportées en raison des exigences opérationnelles
• à transformer les leçons apprises de l'analyse en améliorations durables du pipeline

Prochaines étapes de l'utilisation de l'IA de pointe par le Centre pour la cybersécurité

La capacité continue de gagner en maturité, et les leçons apprises de chaque enquête sont intégrées à une bibliothèque réutilisable de compétences d'agent. Cela permet aux améliorations mises au jour dans le cadre d'une enquête de renforcer les performances du pipeline lors des enquêtes subséquentes.

De plus, les extracteurs de configuration et de charge utile validés sont intégrés à Assemblyline 4, ce qui permet l'analyse automatisée des charges utiles au moyen de flux de travaux éprouvés d'analyse de maliciels.

Le Centre pour la cybersécurité continuera de communiquer ses constatations à l'ensemble de la communauté des responsables de la défense par l'intermédiaire de partenariats établis et de contributions à des projets de source ouverte.