Threat Intelligence : connaître pour anticiper
29 décembre 2020
Détection de malwares par Artefacts : le cas Nanocore
Le CyberSOC d’Orange Cyberdefense expose ici ses méthodes pour détecter les malwares par Artefacts. Focus sur le cas précis de Nanocore.
Nos méthodes de détection de malwares
L’une des missions de notre CyberSOC est de détecter la présence de malwares dans le système d’information (SI) de nos clients. Il existe de nombreuses méthodes et stratégies pour atteindre cet objectif telle que la détection basée sur la Threat Intelligence qui consiste notamment à lever une alerte en cas de connexion vers un indicateur réseau (adresse IP, nom de domaine, etc.) défavorablement connus.
L’inconvénient de cette technique est qu’elle repose sur des éléments statiques et qu’il manque, même en cas de succès, d’un contexte pour qualifier l’incident. Pour pallier ce défaut, notre CyberSOC développe des règles de détection basées sur une liste de patterns ou bien, sur des comportements et modes opératoires spécifiques à certains malwares. Cette méthode permet ainsi de qualifier la menace dès la détection par le SIEM (Security Information and Event Management). Elle implique cependant d’assurer une veille permanente pour maintenir à jour cette liste et son adaptation à l’environnement spécifique des réseaux à monitorer.
Qui est Nanocore ?
Nanocore, (MITRE ATT&CK S0336), est un malware de type RAT (Remote Access Trojan) très répandu et utilisé depuis de nombreuses années par différents profils d’attaquants. “Customisable” grâce à de nombreux plugins, il est codé en « .Net » et disponible pour une vingtaine de dollars américains. Son code source a été diffusé sur différents forums spécialisés, ce qui contribue également à sa popularité.
https://web.archive.org/web/20160203201047/http://www.nanocore.io/
Distribué à l’origine comme « outil d’administration à distance », son développeur vantait les capacités d’espionnage de l’outil et promettait un support 24/7 pour un prix très attractif. Dans les faits, il est largement utilisé à des fins cybercriminelles, notamment dans des campagnes de malspam. Il est régulièrement détecté par notre CyberSOC, et fait notamment partie de l’arsenal d’Aggah.
Son auteur, Taylor Hudleston, a été arrêté par le FBI début 2017 et a été condamné à 33 mois de prison[1].
Conception d’une règle de détection
Il existe plusieurs méthodes permettant de détecter ce malware, la plus simple étant de surveiller la création d’un fichier run.dat dans le répertoire AppData\Roaming\{GUID} de l’utilisateur, comportement typique de ce malware.
Si cette méthode paraît simple et efficace, elle n’est cependant par forcément applicable à tous les contextes de nos clients. Monitorer la création de fichiers implique la présence d’un EDR, ou a minima, de Sysmon. Bien qu’ils soient de plus en plus utilisés, les journaux d’activités de ces solutions ne sont que très rarement collectés dans le SIEM, car extrêmement verbeux, et donc coûteux.
Notre équipe CyberSOC a donc réfléchi à une technique alternative se basant sur les données généralement collectées par les SIEM mais aussi les artefacts marquants générés par les activités des malwares. Le choix s’est porté sur les journaux de sécurité Windows et plus particulièrement l’évènement 4657 – A registry values was modified. Cet event enregistre toute création, modification ou suppression de valeur des clés de registres. Il faut cependant activer ce monitoring (via GPO par exemple).
En se basant sur les rapports d’exécution d’échantillons de Nanocore d’une sandbox publique, nous nous apercevons que pour tous ces échantillons, la clé de registre HKCU\Software\Microsoft\Windows\CurrentVersion\Run\TCP Monitor est créée. Elle a pour valeur le chemin vers l’exécutable tcpmon.exe. On remarque que cet exécutable est positionné dans un répertoire nommé TCP Monitor.
Cela pourrait constituer un pattern de détection. Cependant, en exécutant ces mêmes échantillons dans la sandbox développée par Orange Cyberdefense (P2A), nous nous apercevons que le nom de la clé et sa valeur diffèrent : HKCU\Software\Microsoft\Windows\CurrentVersion\Run\NAS Host ayant pour valeur le chemin vers l’exécutable nashost.exe. Le même comportement est observé : l’exécutable est également localisé dans un répertoire correspondant au nom de la clé (NAS Host).
Ce comportement a attisé notre curiosité ; notre hypothèse étant que le code du malware contient une liste de valeurs. Une fonction étant ensuite chargée de tirer une de ces valeurs en fonction d’éléments de la machine.
Rétro-ingénierie de Nanocore
Ce billet n’a pas pour objectif de détailler le reverse de Nanocore, sujet qui fait déjà l’objet de nombreuses publications, mais de se focaliser sur les fonctions permettant de comprendre comment est nommée la clé Run et sa valeur.
Une simple recherche statique sur le pattern « Monitor » nous permet d’identifier un constructeur de type Structs contenant des tableaux de variables de type String au sein desquelles nous retrouvons les différentes valeurs observées.
Le même constructeur contient également une fonction qui fait appel à ces trois variables. Cette fonction prend le Guid de la machine (Globally Unique ID – empreinte numérique unique de la machine) en paramètre et in fine, renvoie deux variables de type String dont la structure (présence d’un espace et extension .exe) correspond au nom de la clé et de sa valeur.
C’est bien cette fonction qui est appelée pour obtenir le nom de la clé et sa valeur. Elles sont liées au Guid de la machine. La fonction retourne deux variables de type String :
- String_0 correspond au nom de la clé. Elle est construite via la concaténation d’une valeur mise en majuscule du tableau String_4, suivi d’un espace puis d’une valeur du tableau String_3.
- String_1 correspond à la valeur de la clé. Elle est construite via la concaténation de la même valeur du tableau String_4 que pour String_0 puis d’une valeur du tableau String_2 suivi de .exe.
Par exemple, en partant du Guid de la sandbox de VirusTotal (e308eb5f-53cc-4bed-89c0-f9bbcc246f37), les valeurs seraient les suivantes :
- String_0 = SMTP Service
- String_1 = smtpsvc.exe
Au vu du nombre de variables contenu dans chacun de ces tableaux, il y a 138 valeurs différentes de nom de clés et de valeurs possibles. Le chemin de la clé est contenu dans un constructeur de type Class qui est en charge de l’initialisation des paramètres.
Dans cette dernière, nous notons également que le malware créé une tâche planifiée qui est généralement utilisée comme tactique d’exécution et de persistance (Mitre ATT&CK T1053).
Dans le cas présent, nous notons l’utilisation du paramètre /tn qui permet de nommer la tâche en utilisant la variable String_4. Cette dernière contient le nom de la clé Run. Le nom de la tâche planifiée correspond donc au nom de la clé Run.
Il est possible et recommandé de “loguer” la création, modifier et supprimer des tâches planifiées (EventCode 4698 – 4702 – 4699). La recherche d’une des 138 valeurs de noms de clés dans ces logs constitue également une méthode de détection de Nanocore.
Règle de détection
Via les tableaux de valeurs obtenues précédemment et un simple script, il est ainsi possible de déterminer toutes les combinaisons de valeurs possibles. Il suffit d’alimenter le SIEM avec ces différentes valeurs puis d’ajouter une règle de corrélation.
Une fois ce mécanisme en place, une alerte sera générée dès qu’un couple clé-valeur correspondant à Nanocore sera détecté. Il est bien évidemment possible d’ajouter d’autres couples de clé-valeur (associé à d’autres malwares par exemple).
L’intérêt de ce mécanisme est qu’il est simple à mettre en œuvre. De plus, l’alerte contient déjà un premier élément de qualification de l’incident en “mappant” l’événement à un nom de malware et son type.
Cet exemple de détection rappelle également l’importance du parsing et de la normalisation des logs. Si les sources de données (Sysmon et journaux d’évènement de sécurité Windows) remontent la même information, le nom des champs est différent, d’où l’importance de bien normaliser les champs.
A noter que dans le cas Splunk présenté, il aurait d’ailleurs été préférable de s’appuyer sur le datamodel Endpoint et respecter le CIM (Common Information Model) lors du parsing de ces différents logs. Les différents couples clé-valeur sont renseignés dans le lookup nommé registry_malware_pattern. La règle lève une alerte lorsqu’elle constate la création d’une clé de registre dont la valeur est présente dans ce fichier. Ce mécanisme est utilisé car il est plus simple à maintenir.
Investigation
Lors d’incidents de ce type, l’une des tâches des analystes est de détecter le ou les C2. Un moyen assez efficace pour ce faire consiste à détecter du beaconing émanant de la machine infectée. Pour cela, il faut, via les logs firewall, calculer l’intervalle de temps entre chaque triplet IP Source, IP Dest et Port Dest et conserver uniquement les IP sources qui communiquent à intervalles réguliers avec un couple IP Dest–Port Dest.
Si ce type de requête est assez simple à écrire en SPL (Search Processing Language) mais elle est consommatrice de ressources. C’est pour cela qu’il est préférable de filtrer les logs émanant uniquement de l’asset infecté.
Le graphique ci-dessus illustre le nombre de connexions vers un C2 par intervalle de temps pour une machine infectée par le RAT Houdini. Le principe est le même pour Nanocore. Dans cet exemple, la machine beacon toutes les 5-6 secondes.
Si le C2 est connu des bases de Threat Intelligence, il est également possible que le SIEM remonte une alerte pour cette connexion générant ainsi deux alertes pour le même incident. Le couplage du SIEM avec un orchestrateur (SOAR) prend ici tous son sens.
Pour ce type d’incident, nous pouvons imaginer que suite à l’alerte Nanocore, le SOAR déroule un playbook particulier en fonction du type de malware. Dans le cas présent, il peut exécuter une recherche de beaconing et ainsi enrichir l’alerte. Il va également pouvoir “merger” cette alerte avec celle de détection d’IOC. Ainsi, l’analyste disposera automatiquement de l’ensemble des informations permettant de caractériser l’incident.
Conclusion
Cet exemple illustre une technique permettant d’identifier à moindre coup la présence d’un malware. Cependant, ce mécanisme de détection doit intervenir en compléments d’autres règles, et ce pour plusieurs raisons. La principale étant qu’il est difficile et coûteux de maintenir l’exhaustivité d’une telle liste. De plus, un attaquant mature peut customiser le code source du malware (changer les valeurs) contournant ainsi ce mécanisme de détection.
Globalement, il est recommandé de surveiller la création de clés Run qui sont, en général, encore utilisées comme techniques de persistance (Mitre ATT&CK T1060). Pour les assets critiques, notamment les serveurs Active Directory, il est recommandé de surveiller et d’investiguer lors de création d’une clé de registre Run.
Si utiliser les résultats d’exécution en sandbox est un moyen simple et rapide de constituer un dictionnaire des clés-valeurs signant par malware, il faut cependant rester vigilant. Comme le démontre ce billet, ces valeurs sont parfois liées au système sur lequel le malware est exécuté. A minima, pour contourner ce problème, il est préférable d’exécuter son échantillon au sein de deux sandbox différentes. La retro-ingénierie reste cependant le moyen le plus fiable pour obtenir ces informations.
Complément d’information
Script python générant un fichier CSV contenant tous les couples nom de clés et valeurs. Le fichier CSV de sortie peut directement être importé comme lookup dans Splunk.
