TL;DR: Supernova nutzt eine Schwachstelle der SolarWinds Orion-Plattform, um eine speicherinterne Webshell einzuschleusen. Diese Schwachstelle muss gepatcht werden. Die nachfolgend beschriebenen Erkennungsmethoden helfen euch zudem, Aktivitäten der Eindringlinge aufzuspüren.
Als Unternehmen sich gerade eine Verschnaufpause gönnen und in der Vorweihnachtszeit 2020 etwas herunterschalten wollten, zeichnete sich eine äußerst interessante Wendung bei den Sunburst-Eindringversuchen über SolarWinds Orion ab.
Supernova Timeline
Am 15. Dezember postete GuidePoint Security eine Analyse einer .NET-Webshell namens „Supernova“, die ursprünglich bei der ersten FireEye-Untersuchung entdeckt worden war. Zwei Tage später folgte die Supernova-Analyse von Palo Alto Networks. Am 18. Dezember veröffentlichte Microsoft einen umfassenden Bericht zu „Solorigate“, der kompromittierten Lieferketten-DLL, die Teil des erstmalig von FireEye gemeldeten Sunburst-Angriffs war. Im Abschnitt über weitere entdeckte Malware nennt Microsoft die Supernova-Malware, die bei den eigenen Nachforschungen aufgespürt wurde, und stellt dabei auch die These auf, dass Supernova von einer anderen Hackergruppe stammt, da die Malware sich von anderen Aspekten des Sunburst-Angriffs unterscheidet!
Am 24. Dezember veröffentlichte SolarWinds seinen ersten Security Advisory, in dem sowohl von Sunburst als auch Supernova die Rede war. Dieser Sicherheitshinweis wurde seither mehrmals aktualisiert, da immer wieder neuere Informationen zur Verfügung standen. SolarWinds hat frühere Aussagen revidiert und geht mittlerweile davon aus, dass es keinen Zusammenhang zwischen Supernova und den Sunburst-Angriffen gibt und Supernova eine Schwachstelle der Orion-Plattform ausnutzt. Diese neue Sicherheitslücke und die entsprechende Malware bieten Eindringlingen eine weitere Zugangsmöglichkeit. Die US-amerikanische Bundesbehörde für Cyber- und Infrastruktursicherheit DHS CISA hat ihre ursprünglichen Hinweise um diesen neuen Angriffsvektor erweitert.
Auf der Grundlage dieser neu veröffentlichten Untersuchungen (die wir hier, wohlgemerkt, extrem knapp zusammengefasst haben) sehen wir uns jetzt genauer an, was Supernova eigentlich ist und wie es eingesetzt wird. Außerdem stellen wir verschiedene Erkennungsmethoden vor, bei denen Datenmodelle und SPL eingesetzt werden, die einen Angreifer bei der Nutzung dieses Angriffsvektors aufspüren können.
Was ist Supernova?
Supernova wurde ursprünglich bei der Analyse von Sunburst, dem Angriff auf SolarWinds Orion, identifiziert. Bei dieser ersten Analyse wurden neben anderen Elementen für Sunburst auch Yara-Regeln für Supernova erstellt, da zunächst angenommen wurde, dass Supernova Teil desselben Eindringversuchs sei. Angesichts der neuen Vermutung, dass Supernova nicht mit Sunburst zusammenhängt, entfernte FireEye die Yara-Regeln aus seinem GitHub-Repo. Die ursprünglichen Regeln sind jedoch noch verfügbar.
Supernova nutzt eine so genannte Zero-Day-Schwachstelle, um eine trojanisierte .NET-DLL zu installieren. Hier ist zu beachten, dass diese DLL nicht digital signiert ist, wie es bei der Sunburst-DLL der Fall war. Dies ist einer der Gründe, warum mehrere Experten der Ansicht sind, dass es sich um einen anderen Bedrohungsakteur handelt, der eine Schwachstelle ausnutzt, um seinen bösartigen Code auf anfällige Systeme zu laden.
Die Malware, die geladen wird, ist eine Webshell. Diese MITRE ATT&CK-Methode (T1505) wird von Angreifern eingesetzt, um Webserver als Backdoor zu nutzen und sich dadurch dauerhaften Zugriff auf Systeme zu verschaffen. Falls ihr mehr darüber wissen möchtet, findet ihr hier eine hilfreiche Einführung zu Webshells von Acunetix. Diese Webshell ist besonders unangenehm, weil sie so aufgebaut ist, dass sie im Speicher ausgeführt wird. Dies macht ihre Entdeckung und auch die Durchführung weiterer Analysen nach dem Eindringen für forensische Analysten schwieriger. Schwieriger, aber nicht unmöglich.
Was kann ich tun?
SolarWinds hat seine Sicherheitshinweise weiter aktualisiert, die sich sowohl auf die Sunburst- als auch die Supernova-Probleme beziehen und die betroffenen Software-Versionen angeben. Es sind Patches für beide Probleme verfügbar. Je nachdem, welcher Patch angewandt wird, können Sunburst und Supernova sogar gleichzeitig bekämpft werden!
Wie kann ich Supernova in meiner Umgebung aufspüren?
Wenn ihr den Blogbeitrag bis hierher gelesen habt, wisst ihr jetzt, dass Supernova und Sunburst getrennte Probleme sind, und möchtet wahrscheinlich etwas unternehmen, um beide Probleme abzuwehren bzw. zu beheben. Die nachfolgend beschriebenen Erkennungsmethoden helfen euch in eurer Umgebung möglicherweise weiter.
Leser dieses Blogs verwenden wahrscheinlich Splunk Enterprise oder Splunk Enterprise Security. Es kann zwar jeder Datenmodelle nutzen, doch mir ist durchaus bewusst, dass es nicht jeder tut. Aus diesem Grund wird bei den nachfolgenden Erkennungsmethoden jeweils die Suche mit SPL, mit Datenmodellen und mit dem Befehl tstats beschrieben. Mit der Verwendung von tstats erzielt ihr eine bessere Gesamtsuchleistung. Auch wenn ihr keine Datenmodelle verwendet, sollte euch die SPL-Suche dennoch weiterhelfen, da die Suchkriterien trotzdem gelten. Es kann jedoch sein, dass sich die Feldnamen von denen in den folgenden Beispielen unterscheiden. Dies hängt von den Sourcetypen in eurer Umgebung ab.
Diese Suchen sind ziemlich breit angelegt, können aber auf der Grundlage der IP-Adresse oder anderer Attribute verfeinert werden. Gutes Asset-Management hilft, die Systeme zu isolieren, in denen gesucht werden sollte. Wenn ihr auf tstats und Datenmodelle verzichten und nur SPL für eure Suchen verwenden möchtet, dann vergesst nicht, index= zu verwenden, um die Suche auf Indizes zu beschränken, die die betreffenden Events enthalten.
| 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
Die SPL-Suche hängt von der Event-Quelle ab, also Nessus, Qualys oder andere. Wenn der Anbieter von Schwachstelleninformationen CERT/CC oder CVE einsetzt, könnte die SPL-Suche aber auch ganz einfach wie folgt lauten:
index=
Da sich die Webshell nicht auf der Festplatte befindet, werden beim Eindringen hier nur wenig Spuren hinterlassen. Es gibt jedoch Datei-Hashes für die trojanisierte .NET-DLL. VirusTotal hat derzeit 59 Engines, die die Datei erkennen. Es stehen auch Signaturnamen für die Suche zur Verfügung. Sie variieren jedoch abhängig vom Hersteller eures Antivirenprogramms.Je nachdem, wie ihr Dateisystemereignisse identifiziert, könnt ihr mit der folgenden Suche eventuell feststellen, ob die Datei-Hashes für die trojanisierte DLL auf die Festplatte geschrieben wurden. Voraussetzung hierfür ist, dass die erfassten Events in das Endpoint-Datenmodell geschrieben werden. | 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
Wenn ihr Sysmon nutzt, kann auch die Suche nach EventCode 11 (FileCreate) nützlich sein, um festzustellen, wann bzw. ob die DLL auf die Festplatte geschrieben wurde.
index=
Mit einer Suche nach diesen drei Hashes (SHA256, SHA1 und MD5) erhaltet ihr zumindest einen Ausgangspunkt, um festzustellen, ob sich die Malware auf euren Solarwinds Orion-Systemen befindet.
SHA256: C15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71 SHA1: 75af292f34789a1c782ea36c7127bf6106f595e8 MD5: 56ceb6d0011d87b6e4d7023d7ef85676
Wenn ihr nach DLLs sucht, die bei einem bestimmten Prozess geladen werden, könnt ihr mit Sysmon Event Code 7 (Image loaded) auch nach der trojanisierten .NET-DLL suchen, die aufgerufen wird.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 hat ebenfalls einen Blogbeitrag veröffentlicht, in dem ein Proof-of-Concept entwickelt wird, bei dem dieselbe Methode wie bei Supernova für die speicherinterne Kompilierung von .NET verwendet wird. Dabei zeigte sich, dass CSC.exe und CVTRES.exe bei der Ausführung als untergeordnete Prozesse erstellt werden. Beachtet hierbei bitte, dass diese Taktik zum Aufspüren dient, nicht zum Bereitstellen als Signatur mit eurem SIEM. Da viele .NET-Apps dies verursachen können, möchte ich hier anmerken, dass dies kein Kompromittierungsindikator ist. Es kann sich jedoch lohnen, eine derartige Suche durchzuführen, um erst einmal festzustellen, ob .NET-Assemblies kompiliert werden, und dann nach weiteren Aktivitäten zu suchen, die auf potenziell gefährdeten Systemen direkt nach diesem Verhalten auftreten.
| 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=
Da die Webshell im Speicher angesiedelt ist, stellen Ereignisse wie Web- oder Netzverkehr die beste Möglichkeit dar, sie zu finden. Im Blog von Guidepoint findet ihr eine Pseudoabfrage, die für die Verwendung mit Stream for Splunk, Bro/Zeek oder anderen Datensets, die Informationen zu HTTP- und URI-Dateinamen und -Parametern enthalten, angepasst werden kann. Selbst wenn keine Endpoint-Daten vorliegen, es jedoch Daten zu Web- oder Netzwerkverkehr gibt, können solche Suchen als Ausgangspunkt dienen. Wie bereits erwähnt, könnt ihr die SPL an eure spezifische Datenquelle anpassen, falls ihr nicht mit Splunk for Stream arbeitet.| 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=
| tstats count from datamodel=Web.Web where Web.http_content_type=text/plain Web.dest=(insert your SolarWinds IP here, we are looking for inbound traffic) 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=(insert your SolarWinds IP here, we are looking for inbound traffic) url=*logoimagehandler.ashx* | table _time src_ip src_port dest_ip dest_port url transport status Mir ist klar, dass der Umgang mit einer weiteren Schwachstelle und dem damit verbundenen schädlichen Code so kurz nach Sunburst wahrscheinlich nicht die Art und Weise ist, wie ihr 2020 abschließen und 2021 beginnen wolltet. Ich habe jedoch die Hoffnung, dass dies ein Schritt in die richtige Richtung ist, um eure Erkennungsmethoden aufzurüsten, während euer Unternehmen seine potenziell gefährdeten SolarWinds-Systeme patcht.
Da die Webshell im Speicher angesiedelt ist, bietet Web- oder Netzverkehr die beste Möglichkeit, sie zu finden. Im Blog von Guidepoint findet ihr eine Pseudoabfrage, die für die Verwendung mit Stream for Splunk, Bro/Zeek oder anderen Datensets, die Informationen zu HTTP- und URI-Dateinamen und Parametern enthalten, angepasst werden kann. Selbst wenn keine Endpoint-Daten vorliegen, es jedoch Daten zu Web- oder Netzwerkverkehr gibt, können solche Suchen als Ausgangspunkt dienen. Wie bereits erwähnt, könnt ihr die SPL an eure spezifische Datenquelle anpassen, falls ihr nicht mit Splunk for Stream arbeitet.
| 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=(insert your SolarWinds IP here, we are looking for inbound traffic) 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=(insert your SolarWinds IP here, we are looking for inbound traffic) url=*logoimagehandler.ashx* | table _time src_ip src_port dest_ip dest_port url transport status
Mir ist klar, dass wahrscheinlich niemand begeistert ist, wenn er sich so kurz nach Sunburst mit einer weiteren Schwachstelle und dem damit verbundenen böswilligen Code abgeben muss, sondern dass wir alle den Jahreswechsel eher besinnlich begehen wollten. Ich habe jedoch die Hoffnung, dass dies ein Schritt in die richtige Richtung ist, um eure Erkennungsmethoden aufzurüsten, während euer Unternehmen seine potenziell gefährdeten SolarWinds-Systeme patcht.
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Detecting Supernova Malware: SolarWinds Continued.
----------------------------------------------------
Thanks!
Splunk
