Sunburst-Backdoor mit Splunk aufspüren

TL;DR:Dieser Blog enthält einige sofort umsetzbare Anleitungen dazu, wie ihr Splunk Core und Splunk Enterprise Security einsetzen könnt, um euer Netzwerk auf Aktivitäten der Sunburst Backdoor-Malware, die über die SolarWinds Orion-Software verbreitet wurde, zu überprüfen und vor allem auch vor dieser Bedrohung zu schützen. Das Splunk Security Research-Team hat bereits einige weitere Anleitungen in englischer Sprache veröffentlicht, welche in Kürze für euch auch auf Deutsch verfügbar sein werden. Hinweis: Selbst wenn ihr eventuell bösartige Netzwerkaktivitäten feststellt, muss dies nicht heißen, dass euer Netzwerk kompromittiert ist. Wie immer gilt, dass alles sorgfältig geprüft werden sollte.

Sunburst-Backdoor – Kurze Einführung

Im Dezember 2020 veröffentlichte FireEye einen Bericht zur so genannten "Sunburst Backdoor”. Ich kann euch nur wärmstens empfehlen, dieses geniale Whitepaper mit eingehenden Analysen zu lesen. Hier die Basics: Hacker nutzten eine legitime DLL der SolarWinds Orion-Software als Trojaner und speisten sie in den Update-Zyklus der Solarwinds-Kunden ein. Nach der Infizierung ermöglicht diese mit dem Trojaner geschaffene Backdoor den Angreifern, sich lateral im Netzwerk ihrer Opfer zu bewegen und kritische Daten zu stehlen.

FireEye konnte (Stand heute) globale Aktivitäten feststellen, die mindestens bis zum Frühjahr 2020 zurückreichen und auf viele unterschiedliche Branchen abzielten. Im Zusammenhang mit der kürzlich von der US-Cybersicherheitsagentur CISA veröffentlichten Notfalldirektive 21-01hielten wir es für unbedingt notwendig, unseren Kunden eine schnelle Antwort mit allgemeinen Hinweisen zu geben, die euch bei der Erkennung und dem Schutz eurer Netzwerke hilft. Das Research-Team von Splunk wird das Szenario in unseren Laboren analysieren und anschließend noch detailliertere, spezieller zugeschnittene Erkennungsmethoden bereitstellen.

Das solltet ihr wissen

Laut dem FireEye-Bericht wurde dieser Angriff von hochprofessionellen Angreifern durchgeführt, die ihre Ziele sorgfältig auswählten, ihre Angriffsinfrastruktur an den geografischen Standort anpassten und sogar die Namen der angreifenden Hosts auf die Opfer abstimmten, um den Datenverkehr besser zu verschleiern. Da bei dem Angriff ein vertrauenswürdiger Softwarepartner wie Solarwinds Orion genutzt wurde, konnten die Angreifer die Position von Solarwinds im Netzwerk nutzen, um sich lateral über lokale und Cloud-basierte Infrastrukturen auszubreiten und dadurch Daten zu erfassen und zu exfiltrieren.

Die Sunburst-Backdoor ist zwar ein hochentwickelter Angriffsvektor, doch im Grunde handelt es sich dabei dennoch nur um einen Trojaner mit Lateral Movement in einem Netzwerk. Ihr könnt daher viele eurer typischen Netzwerkverteidigungstechniken und Incident Response-Methoden sofort einsetzen. Wenn ihr zufällig wisst, auf welchen Hosts in eurem Netzwerk SolarWinds Orion läuft, beginnt ihr die Jagd am besten bei diesen Hosts, da die Angreifer genau hier ansetzen. Die Sunburst-Backdoor sollte ihre Wirkung nur auf diesen Hosts entfalten. Die zusätzliche Bedrohung besteht jedoch in Seitwärtsbewegungen aus den Orion-Hosts heraus, wobei gängige Verfahren oder von Orion abgegriffene Anmeldeinformationen verwendet werden.

Erkennung in Splunk Enterprise Security

Ein Ereignis wie Sunburst ist ein guter Zeitpunkt, um sich nochmal unseren Blog „How Do I Add COVID (or Any) Threat Intelligence From the Internet to Splunk Enterprise Security?“ zu Gemüte zu führen, in dem es darum geht, wie man Bedrohungsinformationen schnell zu Splunk Enterprise Security (ES) hinzufügt. Ihr ersetzt hier einfach die „COVID“-Bedrohungslisten durch „SUNBURST“-Bedrohungslisten. Dieser Blog hilft euch, euer Splunk SIEM mit den aktuell von FireEye veröffentlichten Kompromittierungsindikatoren (IOCs) zu aktualisieren und Erkennungsergebnisse zu erhalten, falls künftig Hosts infiziert werden.

Mein Kollege Shannon Davis hat bereits mehrere Dateien mit lokalen Bedrohungsinformationen zusammengestellt, die ihr mit den oben beschriebenen Verfahren in ES einspeisen könnt!

IOCs: DNS, Hashes und IPs

Sehen wir uns zunächst die IOCs an, die FireEye freundlicherweise in seinem GitHub-Repo veröffentlicht hat. Ihr könntet sie jetzt durchgehen, viele „OR“-Anweisungen schreiben und euren DNS durchsuchen. Allerdings habe ich bereits einige schnelle Lookup-Dateien erstellt, die ihr verwenden könnt. Dies ist besonders hilfreich, da diese IOCs langsam immer zahlreicher und ausführlicher werden. Nutzt die Tipps aus meinen früheren Blogbeiträgen „Lookup Before You Go-Go...Hunting“ und „Hunting COVID Themed Attacks with IOCs“. Ich habe außerdem ein paar Lookup-Dateien in einem GitHub-Repo bereitgestellt, die ihr euch unabhängig von den Blogs anschauen könnt. Bitte beachtet: Die Lookup-Dateien basieren auf dem von FireEye oder anderen Anbietern veröffentlichten Material, sind aber in jedem Fall ein guter Anfang.

Ihr könnt beispielsweise anhand der Erläuterungen in den oben genannten Blogs oder mithilfe meines Github-Repositorys Lookup-Tabellen erstellen. Wenn ihr dann eine Suche wie die folgende durchführt, findet ihr Hosts, die mit den bis jetzt entdeckten Domänen kommuniziert haben.

index=main sourcetype=stream:*
| lookup sunburstDOMAIN_lookup Domain AS query
| search isBad=TRUE
| stats VALUES(query) AS "Sunburst" by src_ip

Ändert die Suchabfrage und Lookup-Datei einfach auf den Typ von IOC ab, den ihr sucht (Domänen, IPs oder Hashes).

Findet ihr Datenverkehr zu diesen IPs oder Domänen, solltet ihr euch die von FireEye veröffentlichtenSnort-Alerts genau ansehen. Wenn ihr Firewall- oder Proxy-Datenverkehr in Logs erfasst, könnt ihr eure kompromittierten Hosts vielleicht näher identifizieren, indem ihr nach Datenverkehr sucht, bei dem folgende Zeichenfolgen in der URL vorkommen:

/swip/upd/SolarWinds.CortexPlugin.Components.xml
swip/Upload.ashx
/swip/upd/

Seitwärtsbewegung (Lateral Movement)

Sobald die Angreifer über die trojanisierte DLL Zugriff auf das Netzwerk haben, können sie entdeckt werden, wenn sie sich seitwärts bewegen, um Informationen zu finden und zu exfiltrieren. Wir haben zwar noch keine Logs gesehen, können aber ziemlich sicher davon ausgehen, dass sie noch den Gesetzen des Netzwerkverkehrs folgen. Mit dem superpraktischen Tool Splunk Security Essentials (SSE) habe ich verschiedene Suchen in diese PDF-Datei exportiert. Ihr könnt diese Suchen entweder unverändert nutzen oder als Anregung für eigene Suchen verwenden. Ich empfehle euch dringend, jeden verdächtigen Datenverkehr von oder zu SolarWinds-Rechnern in eurem Netzwerk zu untersuchen.

Sysmon und Named Pipe

Es findet sich auch ein interessantes Schmankerl im veröffentlichten FireEye-Bericht: die Existenz einer Named Pipe. Wenn ihr Sysmon und Splunk einsetzt, solltet ihr euch die Event-Codes 17 und 18 und die Named Pipe „583da945-62af-10e8-4902-a8f205c72b2e“ ansehen. Die Suche könnte z. B. so aussehen:

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" 
(EventCode=17 OR EventCode=18) PipeName=583da945-62af-10e8-4902-a8f205c72b2e

Was Sysmon- und Splunk-Abfragen angeht, liefert hier auch die Community großartige Beiträge – es war uns allerdings noch nicht möglich, alle Vorschläge zu testen. Googelt einfach ein bisschen, vielleicht werdet ihr ja fündig!

Azure Active Directory

Microsoft hat festgestellt, dass die Angreifer, die die Sunburst-Backdoor nutzen, mit ihrer lateralen Bewegung auf das Azure-AD der Opfer abzielen. Dazu werden entweder abgegriffene Administratorkennwörter oder gefälschte SAML-Token verwendet. Glücklicherweise seid ihr hier dank Splunk (und dem ausgefuchsten Ryan Lait) gut aufgestellt! Wenn ihr eure Azure-Daten in Splunk erfasst habt, könnt ihr wichtige Einblicke in die Aktivitäten erhalten, die die Angreifer möglicherweise unternommen haben. 

Die Azure Active Directory-Auditdaten, die das Microsoft Azure Add-On für Splunk sammelt, können dazu beitragen, einige von den Angreifern genutzte Techniken aufzudecken. Diese Auditlogs erfassen jede Interaktion zwischen Benutzern und Ressourcen innerhalb von Azure. Hier sind ein paar Beispielsuchen, die ihr zum Aufspüren nutzen könnt:

Monitoring auf Änderungen bei App-Registrierungen und Dienstprinzipalen:
Neue Dienstprinzipale:

sourcetype="azure:aad:audit" activityDisplayName="Add service principal" 
| stats values(activityDisplayName) AS Action, values(initiatedBy.user.userPrincipalName) 
AS UPN, values(targetResources{}.displayName) AS Target,
values(targetResources{}.modifiedProperties{}.displayName) AS "Modified Resources",
values(targetResources{}.modifiedProperties{}.oldValue) AS "Old Values",
values(targetResources{}.modifiedProperties{}.newValue) AS "New Values" by correlationId 
| fields - correlationId

Zu Apps oder Dienstprinzipalen hinzugefügte Anmeldeinformationen und Zertifikate:

sourcetype="azure:aad:audit" activityDisplayName="Add service principal credentials"

Zu Apps oder Dienstprinzipalen hinzugefügte Berechtigungen und Rollenzuweisungen:

sourcetype="azure:aad:audit" activityDisplayName="Add app role assignment to service principal" OR 
activityDisplayName="Add delegated permission grant" OR activityDisplayName="Add application" 
| stats  values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName) 
AS Target, values(targetResources{}.modifiedProperties{}.displayName) AS "Modified Resources", 
values(targetResources{}.modifiedProperties{}.oldValue) AS "Old Values", 
values(targetResources{}.modifiedProperties{}.newValue) 
AS "New Values" by correlationId activityDisplayName
| fields - correlationId

Verwendet diese Suche für die Untersuchung von Benutzern, die sensible Berechtigungen zu App-Registrierungen hinzufügen. #ReadMailInAllMailboxes

Apps, die durch Änderungen mandantenfähig gemacht werden:

sourcetype="azure:aad:audit" activityDisplayName="Update application" operationType=Update 
result=success targetResources{}.modifiedProperties{}.displayName=AvailableToOtherTenants 
| table activityDateTime initiatedBy.user.userPrincipalName, 
targetResources{}.displayName additionalDetails{}.value

Änderungen an benutzerdefinierten Azure AD-Domänen:

sourcetype="azure:aad:audit"  activityDisplayName="Add unverified domain" OR 
activityDisplayName=*domain* | stats values(activityDisplayName) AS 
Action, values(initiatedBy.user.userPrincipalName) AS UPN, values(targetResources{}.displayName) 
AS Target, values(targetResources{}.modifiedProperties{}.displayName) 
AS "Modified Resources", values(targetResources{}.modifiedProperties{}.oldValue) 
AS "Old Values", values(targetResources{}.modifiedProperties{}.newValue) 
AS "New Values" by correlationId 
| fields - correlationId

Prüft auch, ob die Microsoft Azure-App für Splunk weitere Suchen und vordefinierten Security-Content für Azure-Daten bereitstellt.

VPS-Hosts

Derzeit wird angenommen, dass die Angreifer geographisch relevante Virtual Private Server (VPS) für den Zugriff auf die Netzwerke ihrer Opfer genutzt haben (also Hosts, deren IP-Adressen aus dem Land des Opfers stammen). Es gibt zwar keine endgültige Liste dieser IPs, doch wir empfehlen unseren Kunden, den von außen ins Netzwerk fließenden Datenverkehr daraufhin zu überprüfen, ob unbekannte IP-Adressen seit Frühjahr 2020 auf die Systeme (und zwar besonders SolarWinds-Geräte) zugegriffen haben.

TSTAT-Suchen (aktualisiert!)

Splunker auf der ganzen Welt arbeiten daran, die Sunburst-Aktivitäten aufzuspüren. Dabei haben viele unserer Kunden festgestellt, dass unsere oben angegebenen Schnellsuchen nicht skalierbar waren, und versuchten deshalb, durch die Verwendung von TSTATS, mit dem Volumen in ihren Datenmodellen fertig zu werden. Mein Kollege Don hat eine Reihe von Abfragen zusammengestellt, die nützlich UND skalierbar sind. Hier ist zu beachten, dass ihr CIM-konforme Daten in Datenmodellen benötigt, um diese Suchen ausführen zu können.

Aufspüren böswilliger Domänen im Network Resolution Datenmodell
Diese Suche durchsucht die DNS-Daten im Network Resolution Datenmodell und verwendet dabei die oben erwähnte Lookup-Datei sunburstDOMAIN_lookup. Wenn es euch lieber ist, könnt ihr die untergeordnete Suche auch entfernen und nur nach der avsvmcloud[.]com-Domäne suchen, um den primären IOC zu entdecken.

| tstats summariesonly=true earliest(_time) as earliest latest(_time) as latest count as total_conn values(DNS.query) as query from datamodel=Network_Resolution where

    [| inputlookup sunburstDOMAIN_lookup

    | rename Domain as DNS.query

    | table DNS.query] OR DNS.query=*avsvmcloud.com by DNS.src DNS.vendor_product DNS.record_type DNS.message_type

| sort earliest

| eval earliest=strftime(earliest, "%c"), latest=strftime(latest, "%c")

Aufspüren böswilliger IP-Adresse im Datenmodell für den Netzwerkverkehr
Diese Suche durchsucht das Netzwerkverkehr-Datenmodell mithilfe der oben angesprochenen Lookup-Dateien sunburstIP_lookup. 

| tstats summariesonly=true earliest(_time) as earliest latest(_time) as latest count as total_conn values(All_Traffic.dest) as dest from datamodel=Network_Traffic where

    [| inputlookup sunburstIP_lookup

    | rename IP as All_Traffic.dest

    | table All_Traffic.dest] by All_Traffic.src All_Traffic.vendor_product

| sort earliest

| eval earliest=strftime(earliest, "%c"), latest=strftime(latest, "%c")

MITRE ATT&CK

Die Kollegen von FireEye waren so nett, ihre Ergebnisse in MITRE ATT&CK bereitzustellen. Genau wie oben im Fall der lateralen Bewegung, habe ich Splunk Security Essentials durchsucht und das gesamte Material extrahiert, das ich im Zusammenhang mit den beobachteten Taktiken und Methoden finden konnte. Das dabei entstandene PDF-Dokument ist zwar ziemlich groß, aber hoffentlich auch ziemlich hilfreich. Wenn ihr euch auf eure eigene SSE-Instanz beschränken möchtet, findet ihr hier die exakten Suchen, die ihr euch anschauen solltet (ich habe alles, was ich für nützlich hielt, zum PDF-Dokument hinzugefügt – ihr solltet also mal einen Blick darauf werfen):

• Bösartiger Powershell-Prozess – codierter Befehl
• Anomale Audit-Trail-Aktivitäten festgestellt
• Tor Traffic
• Häufung von Angriffs-Tools nach Dateiname
• Häufung von Angriffs-Tools nach SHA1-Hash
• sc.exe ändert Windows-Dienste
• Verbotener Service entdeckt
• Verbotener Prozess entdeckt
• Anomaler neuer Service
• Anormal hohe Zahl von Endpunktänderungen durch den Benutzer
• Erste Ausführung eines Windows-Diensts
• Prozesse mit Doppelgänger-Dateinamen (Schreibfehler)
• SMB-Datenverkehr gestattet
• Anomaler neuer Prozess
• Hohe Zahl von Prozessen
• Verbotener Service entdeckt
  

Abschließende Bemerkung

Wir haben uns bemüht, diesen Blog kurz und knackig zu halten. Die beschriebenen Informationen stammen aus unseren bestehenden Produkten wie SSE, ESCU, bereits zuvor durchgeführten Recherchen und zum Teil aus der SPL-Feder solch toller Splunker wie Shannon Davis und Ryan Lait. Die meisten (wenn nicht alle) der obigen Analysen und IOCs basieren auf den Blogs von FireEye und Microsoft zu diesem Thema. Wie bereits erwähnt, wird unser Threat Research-Team aktuellere Informationen und zusätzliche Erkennungsmethoden veröffentlichen, sobald mehr Details (und Daten) zur Verfügung stehen.

^{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Using Splunk to Detect Sunburst Backdoor.}

----------------------------------------------------
Thanks!
Splunk