capa v4 : lancer un .NET plus large

Nous sommes ravis d’annoncer la version 4.0 de capa avec prise en charge de l’analyse des exécutables .NET. Cet outil open source identifie automatiquement les fonctionnalités des programmes à l’aide d’un ensemble de règles extensible. L’outil prend en charge à la fois le triage des logiciels malveillants et l’ingénierie inverse approfondie. Si vous n’avez jamais entendu parler de capa auparavant ou si vous avez besoin d’un rappel, consultez notre premier article de blog. Vous pouvez télécharger les binaires autonomes capa v4.0 à partir de la page de publication du projet et consulter le code source sur GitHub.

capa 4.0 ajoute de nouvelles fonctionnalités majeures qui étendent sa capacité à analyser et à raisonner sur les programmes. Ce billet de blog couvre les améliorations suivantes incluses dans capa 4.0 :

• Un nouveau backend d’analyse qui prend en charge les exécutables .NET, vous permettant d’analyser les familles de logiciels malveillants tels que Dark Crystal RAT et JUNKMAIL/DoubleZero.

• Une nouvelle portée d’analyse limite l’évaluation des règles à des instructions individuelles, permettant aux auteurs de règles d’inspecter les combinaisons spécifiques de mnémoniques et d’opérandes utilisées dans les programmes.

• Clarification du processus de publication de l’ensemble de règles, y compris le balisage des versions majeures des règles, afin que vous puissiez facilement mettre à jour même si vous exécutez une version obsolète de capa.

• Une collection de changements avec rupture qui permettent à capa de s’exécuter plus rapidement et de représenter plus de types de résultats.

Prise en charge .NET

capa v4.0 est la première version à prendre en charge l’analyse des exécutables .NET. Avec cette nouvelle fonctionnalité, nous avons mis à jour 49 règles existantes et ajouté 22 nouvelles règles pour capturer les fonctionnalités dans les fichiers .NET. Lisez la suite pour comprendre comment nous avons étendu capa avec la prise en charge de .NET.

Contributions open source

L’ajout de la prise en charge de .NET à capa a permis à l’équipe FLARE de contribuer à des projets d’analyse .NET open-source. Nous avons fusionné les nouvelles fonctionnalités et les mises à jour de dnfile, une bibliothèque Python qui analyse les métadonnées trouvées dans les exécutables .NET. Nous avons également publié dncil, une bibliothèque Python qui désassemble les instructions CIL (Common Intermediate Language). dncil analyse les en-têtes de méthodes gérées, les instructions CIL et les gestionnaires d’exceptions, exposant les données via une API orientée objet pour vous aider à créer rapidement des outils d’analyse CIL à l’aide de la bibliothèque.

Extraction de fonctionnalités .NET

.NET est une plate-forme permettant de créer des applications gérées exécutées par le Common Language Runtime (CLR). Ces applications peuvent être écrites dans des langages de haut niveau, notamment C#, VB.NET et F#, et sont compilées en instructions CIL de bas niveau. Ces instructions CIL sont incluses dans le fichier .NET avec les métadonnées utilisées par le CLR pour les exécuter. La figure 1 montre un exemple de méthode « Hello World » compilée de C# vers CIL.

capa analyse les fonctionnalités des métadonnées et des instructions CIL stockées dans les exécutables .NET. Par exemple, capa utilise dnfile pour analyser le .NET MethodDef table de métadonnées qui décrit toutes les méthodes gérées définies dans un fichier .NET. Chaque entrée de table inclut le décalage du corps de la méthode contenant ses instructions CIL. capa utilise ensuite dncil pour désassembler chaque corps de méthode et extrait les caractéristiques des instructions CIL. La figure 2 montre une répartition des fonctionnalités capa extraites de notre exemple de méthode “Hello World”.

capa adresse les fonctionnalités .NET à l’aide de leur jeton de méthode et de leur décalage d’instruction, par exemple, token(0x6000001)+0x6. Cela aide les rétro-ingénieurs à naviguer rapidement et à inspecter des méthodes intéressantes à l’aide d’outils d’analyse .NET tels que dnSpy.

La figure 3 montre le code C# décompilé des pistes Mandiant du malware .NET en tant que DOTWRAP. Ce code masque la fenêtre de la console et lit les données d’un fichier nommé config.txt.

La figure 4 montre les fonctionnalités capa extraites de l’exemple de code ci-dessus (cette sortie peut être obtenue via le script d’assistance scripts/show-features.py). Le lecteur avide reconnaîtra peut-être namespace, class, api, stringet number Caractéristiques.

Avec un simple ajout de System.IO.File::ReadAllLines Appel API à une règle existante, capa détecte maintenant le read file on Windows capacité dans l’exemple de logiciel malveillant DOTWRAP (voir Figure 5).

Comme le montre la figure 5, capa extrait également les deux appels d’API kernel32.GetConsoleWindow et user32.ShowWindow. Il s’agit de fonctions natives de l’API Windows appelées à partir du code géré de la porte dérobée à l’aide d’une technologie appelée Platform Invoke (P/Invoke). Le net ImplMap La table de métadonnées décrit les fonctions natives qui peuvent être appelées à partir du code managé à l’aide de P/Invoke. Chaque entrée de table mappe une méthode gérée (MemberForwarded) à une fonction native. La fonction native peut être exécutée en appelant son MemberForwarded méthode et P/Invoke gère les détails.

capa lit le ImplMap table à chaîner MemberForwarded méthodes à leurs fonctions natives. Cela permet de détecter les fonctionnalités natives implémentées dans le code managé. Donc, ici, nous pouvons nous appuyer sur une règle existante pour détecter le masquage de fenêtre via les fonctions natives de Windows. La figure 6 montre la correspondance capa pour notre exemple de code.

Dans la version 4, capa extrait et analyse les types de fonctionnalités suivants à partir de fichiers .NET :

• namespace par exemple, System.IO
• class par exemple, System.IO.File
• api et import par exemple, System.IO.File::Delete
• function-name par exemple, HelloWorld::Main
• number
• chaîne de caractères

Nous avons également ajouté deux nouvelles caractéristiques pour détecter les exécutables .NET contenant à la fois du code managé et non managé (natif) et des appels de code managé vers du code natif, respectivement :

• mode mixte
• unmanaged call

Travaux futurs sur .NET

Au fur et à mesure que nous écrivons des règles spécifiques à .NET et effectuons plus de recherches, nous prévoyons d’étendre et d’améliorer la prise en charge des fonctionnalités .NET dans les futures versions. Si vous rencontrez des fonctionnalités manquantes ou avez des idées pour de bons ajouts, veuillez ouvrir une discussion dans notre GitHub dépôt.

Portée des instructions

Nous avons ajouté une nouvelle portée qui limite l’évaluation des règles aux instructions individuelles. Avec cette règle, les auteurs peuvent faire correspondre des combinaisons spécifiques de mnémoniques d’instructions et d’opérandes. La syntaxe de règle mise à jour de capa inclut également une nouvelle operand caractéristique qui spécifie number et offset valeurs pour les opérandes. Cela permet aux auteurs de règles de spécifier le flux de données depuis une source ou vers une destination, comme le déplacement de données depuis une structure ou la comparaison avec une constante.

La figure 7 montre un exemple d’utilisation du nouveau instruction portée et operator fonctionnalité pour détecter de manière plus fiable le calcul de la somme de contrôle Adler32. Notez à quel point il est beaucoup plus clair que le shr l’instruction doit utiliser le numéro 0xF comme sa source d’exploitation. Cela permet à capa de faire correspondre les capacités avec plus de précision et rend les règles plus faciles à comprendre pour les lecteurs humains. Avec ces changements, nous avons supprimé le support précédemment pris en charge /x32 et /x64 saveurs de number et operand Caractéristiques.

Processus de publication des règles et autres modifications

Lorsque nous introduisons de nouvelles fonctionnalités et des changements de rupture dans capa, les règles peuvent devenir incompatibles avec une certaine version ou notre branche de développement actuelle. Pour expliquer cela, nous avons ajouté une documentation clarifiante qui aide les utilisateurs à identifier la bonne branche de règles pour leur version de capa respective. En bref, les utilisateurs doivent utiliser la branche des règles de correspondance correspondant à la version majeure de capa utilisée. Autrement dit, utilisez les règles v3 pour la version v3 de capa et les règles v4 pour la version v4 de capa.

capa nécessite maintenant Python 3.7 ou plus récent. Si vous construisez au-dessus de capa, sachez également que nous avons mis à jour le format de gel pour stocker les fonctionnalités extraites et le document de résultats JSON pour stocker et échanger les résultats de capa. De plus, la représentation interne des adresses a changé afin que l’outil puisse désormais exprimer un contexte supplémentaire, par exemple, des jetons et des décalages .NET.

Contribuant

Nous sommes impatients de voir comment les nouvelles fonctionnalités de capa soutiennent davantage la communauté et vous encourageons à y contribuer. Toute forme de commentaires, d’idées et de demandes d’extraction est la bienvenue. Ouvrez simplement un problème ou consultez le document de contribution pour commencer.

Les règles sont à la base de l’algorithme d’identification de capa. Si vous avez des idées de règles, veuillez ouvrir un ticket ou encore mieux soumettre une pull request à capa-rules. De cette façon, tout le monde peut bénéficier des connaissances collectives de notre communauté d’analyse des logiciels malveillants.

Conclusion

Les dernières améliorations ajoutent la prise en charge de l’analyse exécutable .NET à capa et rendent ses règles encore plus expressives. La version capa 4.0 comprend également des corrections de bogues, de nouvelles fonctionnalités, des améliorations des formats de sérialisation des résultats gelés et JSON, et plus de 60 règles nouvelles et mises à jour. Consultez le journal des modifications de capa pour tous les détails de la mise à jour.