Détection du malware Supernova : SolarWinds, épisode 2

Pour résumer : Supernova expose la plateforme Orion de SolarWinds à une attaque via un webshell en mémoire. Il faut appliquer un correctif, et les détections ci-dessous peuvent faciliter l’identification des activités malveillantes.

Alors que les entreprises reprenaient leur souffle et commençaient à se détendre pendant les fêtes, un retournement de situation inattendu s’est manifesté dans l’affaire des intrusions « Sunburst » sur la plateforme Orion de SolarWinds.

Chronologie de Supernova

Le 15 décembre, GuidePoint Security a publié son analyse d’un webshell .NET appelé « Supernova », révélé au départ lors de l’investigation initiale de FireEye. Deux jours plus tard, Palo Alto Networks apportait à son tour sa propre analyse de Supernova. Le 18 décembre, Microsoft a publié un rapport complet sur le « Solorigate », le DLL compromis de la chaîne logistique exploité par l’intrusion Sunburst, signalée par FireEye. Sous la section « Autres logiciels malveillants découverts », Microsoft évoque le malware Supernova découvert au cours de ses recherches, ainsi que l’hypothèse selon laquelle, puisque le malware ne se conforme pas à d’autres aspects de l’attaque Sunburst, Supernova pourrait provenir d’un autre groupe APT !

Le 24 décembre, SolarWinds a publié sa première note de sécurité couvrant à la fois Sunburst et Supernova. Cette note de sécurité a depuis été mise à jour plusieurs fois au fil de l’apparition de nouvelles informations. Supernova, explique SolarWinds, semble séparé de l’attaque Sunburst : le logiciel malveillant aurait exploité une vulnérabilité de la plateforme Orion. Cette nouvelle vulnérabilité et le malware associé offrent aux adversaires une autre méthode d’accès. DHS CISA a actualisé ses premières directives afin de prendre en compte ce nouveau vecteur.

En nous appuyant sur ces nouvelles recherches (et je vous fais vraiment la version abrégée, croyez-moi), nous allons nous pencher sur Supernova, pour comprendre de quoi il s’agit et comment il est exploité. Nous allons également aborder différentes méthodes de détection en utilisant des modèles de données et du SPL pour identifier les adversaires exploitant ce vecteur d’attaque.

Supernova, qu’est-ce c’est ?

Supernova a été identifié pour la première fois au cours de l’analyse de Sunburst, l’intrusion dans la plateforme Orion de SolarWinds. Au cours de cette première analyse, des règles Yara Supernova ont été créées parallèlement à d’autres éléments de Sunburst parce que l’on a pensé, dans un premier temps, qu’il s’agissait de la même intrusion. D’après la nouvelle hypothèse selon laquelle Supernova est une attaque distincte de Sunburst, FireEye a retiré les règles Yara de son dépôt GitHub mais les règles d’origine sont toujours accessibles.

Supernova exploite ce qui était une vulnérabilité zero-day pour installer un DLL .NET converti en cheval de Troie. Il est important de souligner que ce DLL n’est pas numériquement signé, contrairement au DLL Sunburst, et c’est l’une des raisons pour lesquelles plusieurs chercheurs pensent qu’il provient d’un autre acteur menaçant utilisant une vulnérabilité pour charger son code malveillant sur les systèmes exposés.

Le malware qui est chargé est un webshell. La technique MITRE ATT&CK T1505 est employée par les adversaires pour ouvrir une backdoor sur les serveurs web et établir un accès persistant aux systèmes. Si vous souhaitez approfondir le sujet, voici une excellente introduction aux webshells par Acunetix. Allez-y, je vous attends ici. Ce qui fait toute la fourberie de ce webshell, c’est qu’il est fait pour s’exécuter en mémoire : il est donc plus difficile à détecter et complexifie les enquêtes des analystes après la faille. J’ai bien dit « plus difficile », pas « impossible ».

Que puis-je faire ?

SolarWinds a continué d’actualiser sa note de sécurité qui présente à la fois les attaques Sunburst et Supernova, ainsi que les versions concernées de leur logiciel. Des correctifs sont disponibles pour ces deux problèmes. Et d’ailleurs, selon le correctif appliqué, il est possible de traiter simultanément Sunburst et Supernova ! 

Comment puis-je détecter Supernova dans mon environnement ?

Si vous avez lu jusqu’ici, vous savez au moins que Supernova et Sunburst sont deux problèmes distincts et vous allez sans doute prendre des mesures. Voici quelques détections qui peuvent s’avérer utiles dans votre environnement.

Les lecteurs de ce blog peuvent utiliser Splunk Enterprise ou Splunk Enterprise Security. Si n’importe qui peut utiliser des modèles de données, je suis bien conscient que tout le monde ne le fait pas. C’est pourquoi les détections ci-dessous sont fournies à la fois en SPL et sous une forme utilisant les modèles de données et la commande tstats. L’utilisation de la commande tstats produit globalement de meilleures performances de recherche. Si vous n’utilisez pas les modèles de données, la recherche en SPL devrait être utile car les critères de recherche s’appliquent également. Toutefois, les noms de champs peuvent varier en fonction des types de source de votre environnement, qui ne sont pas forcément ceux des exemples ci-dessous. 

Ce sont des recherches assez larges mais on peut les affiner selon l’adresse IP ou d’autres attributs. Une bonne gestion des actifs permettra également d’isoler plus facilement les systèmes à explorer. Si vous n’utilisez pas tstats et les modèles de données dans vos recherches et que vous voulez simplement utiliser le SPL, n’oubliez pas d’utiliser index=<insert index names> pour réduire la recherche aux seuls indexes qui contiennent les événements concernés.

CERT/CC a émis une nouvelle alerte de vulnérabilité de l’API SolarWinds Orion le 26décembre. En partant du principe que vous avez un détecteur de vulnérabilité récente intégrant cette dernière alerte et que vous importez les données de détection des vulnérabilités dans Splunk pour renseigner le modèle de données de vulnérabilités, cette recherche pourrait potentiellement mettre au jour des systèmes vulnérables.

| tstats count from datamodel=Vulnerabilities.Vulnerabilities where 
Vulnerabilities.cert=VU#843464 OR Vulnerabilities.cert=843464 OR 
Vulnerabilities.cve=CVE-2020-10148 groupby Vulnerabilities.dest 
Vulnerabilities.dvc Vulnerabilities.signature Vulnerabilities.vendor_product _time span=1s

La recherche SPL va dépendre de la source d’événements, qu’il s’agisse de Nessus, Qualys ou autre, mais elle peut être aussi simple que cela, dès lors que le fournisseur de vulnérabilité utilise CERT/CC ou CVE.

index= 
sourcetype= (VU#843464 OR 843464 OR CVE-2020-10148)

L’empreinte de cette intrusion est limitée en raison de l’absence de webshell sur le disque, mais il existe des hashes de fichier pour le DLL .NET converti en cheval de Troie. VirusTotal a actuellement 59 moteurs qui le détectent. Les noms des signatures peuvent également être interrogés, mais ils varient selon votre fournisseur d’antivirus.

Selon la façon dont vous identifiez les événements du système de fichier, la recherche suivante peut vous aider à identifier si les hashes du fichier associés au DLL troyen ont été inscrits sur le disque. Notez que cela dépendra des événements collectés et inscrits dans le modèle de données Point de terminaison.

| tstats count from datamodel=Endpoint.Filesystem where 
Filesystem.file_name=*logoimagehandler.ashx* OR 
Filesystem.file_hash=C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 
OR Filesystem.file_hash=75af292f34789a1c782ea36c7127bf6106f595e8 OR 
Filesystem.file_hash=56ceb6d0011d87b6e4d7023d7ef85676 groupby 
Filesystem.file_name Filesystem.file_path Filesystem.dest 
Filesystem.file_hash Filesystem.vendor_product Filesystem.user _time span=1s

Pour ceux qui utilisent Sysmon, rechercher le code d’événement 11 (FileCreate) peut également être utile pour déterminer si et quand le DLL a été inscrit sur le disque.

index= 
sourcetype=xmlwineventlog:microsoft-windows-sysmon/operational EventCode=11 
file_name=*logoimagehandler.ashx* 
| table _time host Image Computer TargetFilename

Au minimum, la recherche de ces trois hashes (SHA256, SHA1 et MD5) offrira un bon point de départ pour déterminer si le malware est présent dans vos systèmes SolarWinds Orion.

SHA256 : C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71
SHA1 : 75af292f34789a1c782ea36c7127bf6106f595e8
MD5 : 56ceb6d0011d87b6e4d7023d7ef85676

Si vous recherchez des DLL situés dans un processus spécifique, le code d’événement Sysmon 7 (Image loaded) peut également servir à rechercher les invocations du DLL .NET converti en troyen.

index=
sourcetype=xmlwineventlog:microsoft-windows-sysmon/operational EventCode=7 
(file_name=*logoimagehandler.ashx* OR 
SHA256=C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 OR 
SHA1=75af292f34789a1c782ea36c7127bf6106f595e8 OR 
MD5=56ceb6d0011d87b6e4d7023d7ef85676)
| table _time Image ImageLoaded Computer

SentinelOne a également publié un article de blog développant une preuve de concept qui utilise la même technique que Supernova pour compiler du .NET en mémoire. Ils ont compris que CSC.exe et CVTRES.exe sont créés en tant que processus enfants pendant l’exécution. N’oubliez pas que c’est une tactique de chasse qui ne doit pas être déployée en tant que signature dans votre SIEM. Comme beaucoup d’applications .NET peuvent faire la même chose, je tiens à prévenir que ce n’est pas un indicateur de compromission, mais il peut être intéressant d’effectuer une recherche de ce type pour déterminer si des assemblages .NET sont compilés puis rechercher les opérations supplémentaires se produisant immédiatement à la suite de ce comportement sur des systèmes vulnérables.

| tstats count from datamodel=Endpoint.Processes where
Processes.process_exec=cvtres.exe Processes.parent_process_exec=csc.exe 
groupby Processes.process_exec Processes.process_id Processes.process 
Processes.parent_process_exec Processes.parent_process 
Processes.parent_process_id Processes.dest Processes.user 
Processes.vendor_product _time span=1s

index=
sourcetype=xmlwineventlog:microsoft-windows-sysmon/operational EventCode=1 
CommandLine=*cvtres.exe* ParentCommandLine=*csc.exe*
| table _time CommandLine ParentCommandLine User host ProcessId ParentProcessId

Comme le webshell se trouve dans la mémoire, c’est dans des événements de trafic web ou réseau que vous avez le plus de chance de le trouver. Le blog de Guidepoint propose des pseudo-requêtes qui peuvent être adaptées pour Stream for Splunk, Bro/Zeek ou d’autres jeux de données contenant des informations sur les paramètres et noms de fichiers http et URI. Même en l’absence de données de points de terminaison, si vous disposez de données sur le trafic web ou réseau, ces recherches peuvent servir de point de départ. Comme nous l’avons indiqué plus tôt, si vous n’utilisez pas Splunk for Stream, vous pouvez adapter le SPL à votre propre source de données.

| tstats count from datamodel=Web.Web where
web.url=*logoimagehandler.ashx*codes* OR
Web.url=*logoimagehandler.ashx*clazz* OR
Web.url=*logoimagehandler.ashx*method* OR
Web.url=*logoimagehandler.ashx*args* groupby Web.src Web.dest Web.url
Web.vendor_product Web.user Web.http_user_agent _time span=1s

index= sourcetype=stream:http 
(url=*logoimagehandler.ashx*codes* OR Web.url=*logoimagehandler.ashx*clazz*
OR Web.url=*logoimagehandler.ashx*method* OR
Web.url=*logoimagehandler.ashx*args*)
| table _time src_ip src_port dest_ip dest_port url transport status

| tstats count from datamodel=Web.Web where Web.http_content_type=text/plain
Web.dest=(insérez ici votre IP SolarWinds, nous recherchons le trafic entrant)
Web.url=*logoimagehandler.ashx* groupby Web.src Web.dest Web.url
Web.vendor_product Web.user Web.http_user_agent _time span=1s

index= sourcetype=stream:http
dest_ip=(insérez ici votre IP SolarWinds, nous recherchons le trafic entrant) 
url=*logoimagehandler.ashx*
| table _time src_ip src_port dest_ip dest_port url transport status

Je comprends bien que personne n’avait envie de terminer l’année et d’en commencer une nouvelle en s’attaquant à une nouvelle vulnérabilité et au code malveillant qui l’exploite aussi tôt après Sunburst, mais j’espère que cela vous aidera à lancer vos détections plus rapidement pendant que votre organisation corrige ses systèmes SolarWinds vulnérables.

^{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}