Objectifs

Cette semaine, Z2A m’a fourni un sample d’un implant BruteRatel C4 à analyser.

BruteRatel C4 est un C2 utilisé et développé pour de l’Adversary Simulation et du Pentest et est relativement nouveau dans le milieu des outils de Red Teaming comparé à Cobalt Strike.

BRC4 est réputé pour être indétectable par les EDR grâce à des techniques avancées (Détection des hooks, syscalls au lieu des appels API, communications via DoH..)

Mais un bon outil pour des entreprises de Red Teaming reste un bon outil dans les mains d’un attaquant. Bon nombre de versions de BRC4 ont fuité et ont permis à des acteurs malveillants de déployer des implants.

Ce sont ces implants que j’ai analysé lors du challenge, ou les objectifs étaient les suivants :

1. Identifier l’emplacement de la configuration et développer un extracteur de configuration pour extraire les informations.

2. Développer une règle YARA pour détecter la première couche, en se basant sur des motifs binaires.

3. (Bonus) Améliorer l’extracteur de configuration pour extraire et décrypter la prochaine étape.

Extraction de la config

Ce fichier est le stage 1 d’un implant BRC4. Son but est de déchiffrer le prochain stage et de lui fournir la configuration.

Tout se passe sur la stack, ce qui crée un binaire contenant des millions d’opérations. Malgré cela, la configuration apparaît en clair dans la toute première stack string :

En regardant un autre sample de la même “campagne”, on se rend compte d’un fonctionnement similaire :

On peut ainsi créer un simple script pour extraire la configuration contenant l’IP du C2, son port, ainsi que les identifiants du panel d’administration ! Le premier sample apparaît comme étant volé à la société d’audit Deloitte.

Ce script se positionne à l’offset ou est stocké la configuration et extrait 512 bytes puis l’extrait à nouveau avec une regex:

Règle de détection YARA

Une règle de détection YARA permet, en se basant sur plusieurs paramètres, de reconnaitre certains malwares. C’est un outil très puissant utilisé pour de la Threat Intelligence.

Pour créer une règle Yara efficace, il faut repérer des patterns dans différents samples permettant de les identifier. Cela peut être des strings, des fonctions, ou dans notre cas, des bytes.

J’ai remarqué 2 stack strings identiques dans les 2 binaires :

Ces strings ne sont pas exploitables en tant que tels, IDA reconnait les stack strings mais ils ne sont pas détectables par la commande strings ou yara. J’ai ainsi extrait les bytes pour créer une séquence de détection :

Bonus

Etant donné la relative facilité de ce challenge, il y avait une étape facultative consistant à déchiffrer le second stage de l’implant.

BRC4 utilise du API hashing pour ne pas dévoiler son fonctionnement. Voici la fonction permettant de résoudre une API.

Cette fonction est simple, elle applique un ROR13 sur chaque lettre de l’API, puis ajoute le résultat au hash au fur et à mesure. Avec cet algorithme compris, j’ai ainsi pu créer une liste de hash et les comparer avec ceux présents dans le binaire.

En utilisant IDAPython, j’ai commenté automatiquement les résolutions de fonctions pour afficher leurs noms respectifs :

Une fois les fonctions résolues, il était plus simple de comprendre le mécanisme d’unpacking du stage 2.

Le programme va :

• Allouer un premier chunk mémoire pour son code

• Allouer un second chunk pour stocker la configuration

• Créer un thread afin de lancer le stage 2 (qui s’avère être un shellcode)

Afin d’extraire ce shellcode, j’ai utilisé qiling qui est un émulateur poussé permettant de suivre et modifier l’exécution d’un programme à sa guise, sans aucune répercussions réelles.

Pour récupérer le shellcode, il faut simplement lire le contenu de la mémoire après le premier appel. J’ai également intercepté le paramètre lpStartAddress de la fonction CreateThread pour obtenir le point d’entrée du second stage:

Tout cela est ensuite enregistré dans un fichier .bin permettant de poursuivre l’analyse.