Erkennung des “nächsten” Cyberangriffs im Stil von SolarWinds

Cyber Security News

Der SolarWinds-Angriff, der durch den Einsatz der Sunburst-Malware erfolgreich war, schockierte die Cybersicherheitsbranche. Dieser Angriff erreichte Persistenz und war in der Lage, interne Systeme lange genug zu umgehen, um Zugriff auf den Quellcode des Opfers zu erhalten.

Aufgrund der weitreichenden SolarWinds-Implementierungen waren die Täter auch in der Lage, viele andere Organisationen zu infiltrieren und nach geistigem Eigentum und anderen Vermögenswerten zu suchen.

Zu den Mitopfern gehören: US-Regierung, Auftragnehmer der Regierung, Unternehmen der Informationstechnologie und NGOs. Terabytes an Daten von 18.000 Kunden wurden gestohlen, nachdem eine trojanisierte Version der SolarWinds-Anwendung in den internen Strukturen der Clients installiert wurde.

Betrachtet man die technischen Fähigkeiten der Malware, so war dieser spezielle Angriff ziemlich beeindruckend. Eine bestimmte Datei mit dem Namen SolarWinds.Orion.Core.BusinessLayer.dll ist eine von SolarWinds digital signierte Komponente des Orion-Software-Frameworks.

Die Bedrohungsakteure installierten eine Backdoor, die über HTTP mit Servern von Drittanbietern kommuniziert. Nach einer anfänglichen Ruhephase von bis zu zwei Wochen ruft sie Befehle, so genannte “Jobs”, ab und führt sie aus. Dazu gehören die Fähigkeit, Dateien zu übertragen, Dateien auszuführen, das System zu profilieren, den Computer neu zu starten und Systemdienste zu deaktivieren.

Wie könnte man also die Organisation vor Sunburst oder einem ähnlichen Angriff schützen? Angriffe über die Lieferkette haben den Vorteil, dass sie unter dem Deckmantel einer vertrauenswürdigen dritten Partei einen ersten Fuß fassen können. Von da an entwickeln sie sich wie jeder andere Angriff, und sie können entdeckt werden, wenn man weiß, wo man suchen muss.

Entwicklung von SIEM-Regeln, am Beispiel des SolarWinds-Angriffs

Beginnen wir mit Sigma-Regeln; diese schaffen eine Art gemeinsame Sprache, um Qualitätsabfragen zu erstellen und zu teilen, unabhängig von dem SIEM, das Ihre Organisation verwendet. Die Cymulate-Plattform erstellt Sigma-Regeln, mit denen Sie diese Abfragen in Ihr SIEM laden können. Dies ermöglicht es den Security Operations Teams, die Elemente zu erstellen, die zur Erkennung zukünftiger Angriffe benötigt werden. Wie Sie unten in den 3 Beispielen sehen können, ist die Sigma-Regel die gleiche, jedoch ist die benutzerdefinierte Abfrage speziell für die Sprache dieses SIEMs. Mit einem Klick auf eine Schaltfläche können Sie zu Ihrem bevorzugten SIEM wechseln.

Beispiel 1: Splunk:

[Blocked Image: https://thehackernews.com/images/-2IMblMaOei8/YHV0ADMjEWI/AAAAAAAAA8M/pG-I0qFcdRIr_PO7MDhom0RCJWxDhkljwCLcBGAsYHQ/s0/1.jpg]

Beispiel 2: Qradar:

[Blocked Image: https://thehackernews.com/images/-iMIEyQdCxHs/YHV0AwOIRpI/AAAAAAAAA8U/M9pPCHmJY2k4i5Tn8Z0kDBdh7wUig7UkwCLcBGAsYHQ/s0/3.jpg]

Beispiel 3: Azure Sentinel:

[Blocked Image: https://thehackernews.com/images/-maEvLf3Da_E/YHV0Amoq8mI/AAAAAAAAA8Q/F4LUEy7ycs87i5od_yV5QsWmzYVUry2AACLcBGAsYHQ/s0/2.jpg]

Obwohl Sigma-Regeln hauptsächlich für Abfragen konzipiert sind, kann man sie verwenden, um eine vollständige Anti-Angriffs-Kette SIEM oder EDR-Regel zu erstellen. Im Fall des SolarWinds Sunburst Angriffs und vieler anderer Angriffe sind Cymulate Sigma Regeln Abfragen, die nach den IOBs des Angriffs suchen. Jede Sigma-Regel wird das SIEM nach einem IOB einer Stufe des Angriffs abfragen.

Wenn die IOBs aus den Sigma-Regeln kombiniert werden, können sie eine spezifische Regel für das Zielsystem ergeben – etwas, das mit einem hohen Maß an Sicherheit den Angriff aufzeigen kann, ohne das “Rad neu zu erfinden”. Alle erforderlichen IOBs sind vorhanden – in den Sigma-Regeln – man muss nur die Hand ausstrecken und sie nehmen.

Schauen wir uns den konkreten Fall eines nachgebauten SolarWinds-Angriffs auf der Windows-Plattform an und jagen ihn gemeinsam.

Jagd auf SolarWinds unter Microsoft Windows

Die Cymulate-Plattform bietet uns die Möglichkeit, den Supply-Chain-Angriff zu replizieren, der mit dem Export eines Exchange-Server-Postfachs beginnt. Die nachfolgenden Stufen des Angriffs, die in der Cymulate Plattform zur Verfügung stehen, um den Angriff zu simulieren, sind im Screenshot zu sehen.

Das erste Ereignis wird von Windows nicht ausgelöst, aber es wird in verschiedene Netzwerkprotokolle geschrieben. Da das Ereignis selbst nicht sehr spezifisch sein kann, belassen wir es als optional zur Einordnung in eine allgemeine Regel. Lassen Sie uns fortfahren.

[Blocked Image: https://thehackernews.com/images/-M1gSTkgheTo/YHV04F3_1QI/AAAAAAAAA8k/1H0ZSPDTb3kVK7NG8lOKmmZGhuEW5C67QCLcBGAsYHQ/s0/4.jpg]

Das nächste Ereignis im Angriff ist das Herunterladen von Inhalten mit PowerShell. Ein solches Ereignis kann mit den Windows-Ereignis-IDs 4103 und 4104 überwacht werden, die auch den tatsächlich ausgeführten Code anzeigen können, aber wir wollen uns nicht auf eine bestimmte Methode beschränken, denn, seien wir ehrlich: PowerShell ist nicht das einzige Tool, das ein Angreifer verwenden kann.

Allen Tools gemeinsam ist, dass beim Herunterladen von Inhalten ein Objekt im System erstellt wird, und dafür gibt es eine Windows-Ereignis-ID 4663 mit einem Indikator der Zugriffsmaske 0x1 oder, wenn Sie Sysmon verwenden, die Ereignis-ID 11.

Unten ist ein allgemeiner Screenshot einer 4663 Event ID mit den relevanten Feldern hervorgehoben. Dies ist das Ereignis, das die Cymulate Sigma Regel erkennt, und es ist auch die erste IOB in der Regel, die wir erstellen werden. Mehr zu dieser Event ID finden Sie hier.

[Blocked Image: https://thehackernews.com/images/-lx1rd0O0H8o/YHV087SRXYI/AAAAAAAAA8o/uVpeOehduQwNeIdsJeXjTg5PE5NpOUdgwCLcBGAsYHQ/s0/hack.jpg]

Als nächstes folgt die nächste Stufe des Angriffs: Task Scheduler: Das Maskieren von Tasks, die auf dem Windows-Sperrbildschirm ausgelöst werden, um eine Seitwärtsbewegung zu ermöglichen. Auch hier ist es irrelevant, welche Tasks genau maskiert werden; wichtig ist, dass es Windows-Ereignis-IDs gibt, die uns helfen, diese Kette von Ereignissen zu identifizieren.

Die Ereignis-IDs sind:

4698 – Aufgabe erstellt

4700 – Geplante Aufgabe aktiviert.

4702 – Geplante Aufgabe aktualisiert.

4699 – Geplante Aufgabe entfernt.

Relevant für uns ist natürlich 4698, da diese Meldung erscheint, wenn eine neue Aufgabe erstellt wird. Ereignisse zum Aktualisieren, Aktivieren und/oder Entfernen einer Aufgabe sind eine gute Erweiterung, aber optional. Persönlich würde ich empfehlen, eine Option 4699 hinzuzufügen, da immer die Möglichkeit besteht, dass der Angreifer die Aufgabe nach der Fertigstellung entfernen möchte, um seine Spuren zu verwischen.

Was wir also für minimale Anforderungen wollen, ist 4698 mit einem Satz spezifischer Regexe im Feld “Befehl” im Ereignis, die z. B. mit bekannten ausführbaren Typen übereinstimmen:

– ‘.exe’ – ‘.py – ‘.ps1’ – ‘.msi – ‘.msp’ – ‘.mst’ – ‘.ws’ – ‘.wsf’ – ‘.vb’ – ‘.vbs’ – ‘.jst’ – ‘.cmd’ – ‘.cpl’

Für komplexe Fälle können reguläre Ausdrücke, wie die folgenden, verwendet werden: – ‘^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)?$’ -‘^([A-Za-z0-9 /]{4})*([A-Za-z0-9 /]{3}=|[A-Za-z0-9 /]{2}==)?$’

Achten Sie besonders auf die letzten beiden IOBs (Regexe): diese passen auf ein base64-Muster. Obwohl “Geplanter Task” einen String als Eingabe erhält, ist es möglich, darin eine verschleierte/verschlüsselte Form eines Befehls zu schreiben. Zum Beispiel “python” als Befehl und “base64.b64decode(some base64 payload)” als Argument, wodurch Ihr Task effektiv zu einem “Dekodierungswerkzeug für base64-Nutzdaten” wird.

Noch einmal, alle Indikatoren können in den Sigma-Regeln gefunden werden, die von Cymulate geliefert werden. Der Einfachheit halber werden wir diese Liste und andere kommende Listen von IOB’s einfach “relevante IOB-Liste” nennen. Unten sehen Sie die allgemeine Ansicht der Ereignis-ID 4698 beim Erstellen einer neuen Aufgabe.

[Blocked Image: https://thehackernews.com/images/-rth1B19vjDU/YHV1RAuJ5GI/AAAAAAAAA80/2oPqU37Rw586v8ch6ruewKznVU0TZq2xwCLcBGAsYHQ/s0/5.jpg]

So, jetzt haben wir zwei Ereignisse in der Kette abgedeckt. Diese sollten auf demselben Rechner und mit demselben Benutzernamen auftreten. Danach wird der Prozess in Ihrem Task ausgeführt, was zu einer Ereignis-ID von 4688 mit dem Namen des Erstellerprozesses führt: TaskScheduler oder TaskScheduler.dll oder taskeng.exe (je nach der von Ihnen verwendeten Version von Build), und der neue Prozessname hat eine dieser IOBs in der Liste der ausführbaren Dateien. In diesem Stadium sieht unsere Regel also wie folgt aus:

(4663 + Zugriffsmaske 0x1)🡪 (4698 und relevante IOB-Liste)🡪 (4688+Liste des relevanten Creator-Prozessnamens + Liste der relevanten IOBs als Teil des neuen Prozessnamens)

OR

4663 + Zugriffsmaske 0x1 oder Sysmon 11)🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe))]

Das Zeichen 🡪 steht für die Operation “gefolgt von”.

Die nächste Stufe des Angriffs ist das Ausführen der DLL-Datei mit rundll32. Dies ist eine einfache IOB, die übrigens auch in einem vorherigen Schritt ausgeführt werden kann. In diesem speziellen Fall ist es 4688+rundll.32

Der nächste Schritt ist ADFind : Enumerating an AD Group using ADFind Masqueraded as csrss.exe. Dieser Schritt ist ein wenig trickreich. Bei diesem Schritt tarnt ein Angreifer sein Aufzählungstool als eine legitime Datei. Bevor dies jedoch geschehen kann, muss die illegitime Datei irgendwo auf einem Ihrer Laufwerke (vorzugsweise im Systemordner) mit dem legitimen Namen abgelegt werden.

In diesem speziellen Fall ist es csrss.exe, aber es gibt eine ganze Reihe von Dateinamen, die z. B. für den gleichen Zweck verwendet werden könnten:

– ‘svchost.exe’. – rundll32.exe. – services.exe. – powershell.exe. – regsvr32.exe. – spoolsv.exe

– lsass.exe. – smss.exe. – csrss.exe. – conhost.exe. – wininit.exe. – winlogon.exe. – explorer.exe

– taskhost.exe. – Taskmgr.exe. – sihost.exe – RuntimeBroker.exe – smartscreen.exe.

Auch hier brauchen Sie nicht nach allen zu suchen, sie sind bereits in der entsprechenden Sigma-Regel enthalten.

Unten sehen Sie ein Beispiel für eine mögliche Sigma-Regel für diesen speziellen Schritt, die das Erstellen einer Datei mit einem der oben angegebenen Namen erkennt. Aber mit einem Hash, der sich vom Original unterscheidet. Unabhängig davon, ob eine Systemdatei überschrieben oder ein neuer Pfad erstellt wird, führt dies immer noch zu einer Ereignis-ID 4663 (oder Sysmon-Ereignis-ID 11), und einer der unten aufgeführten Namen wird in der Nutzlast gefunden.

[Blocked Image: https://thehackernews.com/images/-2n_X_ZJeOE8/YHV1ugMQPLI/AAAAAAAAA88/e0X979HIsy0b4OhxNPwq5EAgk3ort_Y9QCLcBGAsYHQ/s0/6.jpg]

Die Arbeit mit Systemdateien erfordert ebenfalls einen privilegierten Zugriff, so dass es unweigerlich zu einer Privilegienerweiterung kommt, die ebenfalls mit einer Ereignis-ID von 4688 (Dateizugriff) und einem Token-Elevation-Typ von %%1936 bzw. %%1937 dokumentiert wird, die für System- bzw. Administratorzugriff stehen.

Unten sehen Sie einen Screenshot der 4688 Event ID mit hervorgehobenen relevanten Feldern.

[Blocked Image: https://thehackernews.com/images/-CQtK-jAdvUs/YHV17Ld6ruI/AAAAAAAAA9A/TiRvJ5H3oZAQtPFs-iK9aGCYnr5MBD09QCLcBGAsYHQ/s0/7.jpg]

Optional könnten Sie nach der Ereignis-ID 4672 mit einer der Zeichenfolgen für die Privilegieneskalation suchen, aber das Ereignis der Privilegieneskalation kann in jedem Schritt des Angriffs auftreten. Wir empfehlen hierfür eine separate Regel, die mit der von uns erstellten Regel korreliert sein sollte.

Lassen Sie uns einen Blick auf unsere Regel in diesem Stadium werfen:

(4663 + Zugriffsmaske 0x1 oder Sysmon 11)🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe)) 🡪 (4688 and rundll32) 🡪 (4663 or Sysmon 11 + generic list of system files) 🡪 (4688 and 1 of files in list and Token Elevation Type (%%1936 OR %%1937))]

Der nächste Schritt ist “Execute base64-encoded PowerShell from Windows Registry”. Was hier passiert, ist, dass ein Angreifer einen verschleierten Code ausführt, der zuvor in einen Registry-Wert geschrieben wurde. Wie Sie verstehen können, muss er dazu einen neuen Registrierungswert erstellen oder einen vorhandenen ändern.

Ein Windows-Ereignis mit der ID 4657 und einem Wert, der dem base64-Muster entspricht (das mit Regexen identifiziert werden kann, die wir bereits in einem vorangegangenen Schritt gesehen haben), kann helfen, diesen Schritt zu identifizieren. Das Ereignis kann als Operation Type “Existing registry value modified” oder “Creating new registry value” enthalten. Alle IOBs können, wie bereits erwähnt, den mitgelieferten Sigma-Regeln entnommen werden.

Dieses Ereignis kann Ihnen weitere wertvolle Informationen anzeigen, wie z. B.:

1) Welche Taste war beteiligt.

Das Format ist: REGISTRYHIVEPATH wobei:

HIVE:

  • HKEY_LOCAL_MACHINE = REGISTRYMACHINE
  • HKEY_CURRENT_USER = REGISTRYUSER[USER_SID], wobei [USER_SID] die SID des aktuellen Benutzers ist.
  • HKEY_CLASSES_ROOT = REGISTRYMACHINESOFTWAREClasses
  • HKEY_USERS = REGISTRYUSER
  • HKEY_CURRENT_CONFIG = REGISTRYMACHINESYSTEMControlSet001Hardware-ProfileAktuell

2) Was ist der verursachende Prozess.3) Was ist der alte Wert und der neue Wert.

Nachfolgend sehen Sie eine allgemeine Darstellung der Ereignis-ID 4657.

Unter Berücksichtigung möglicher Zeitrahmen, da der gesamte Vorgang wahrscheinlich per Skript ausgeführt wird, können wir mit Sicherheit sagen, dass die Schritte 2-6 bei Erfolg nicht länger als 5 Sekunden dauern werden. Die gesamte Kette bis zur Ausführung des in der Registry gespeicherten Codes könnte nicht länger als 10 Minuten dauern.

[Blocked Image: https://thehackernews.com/images/-Zrdi1lCrNgU/YHV2KH_NMvI/AAAAAAAAA9I/_CMsepRDV7kVT7gt3sorL8UDmZQttXCGwCLcBGAsYHQ/s0/8.jpg]

Nachdem wir diese Variablen hinzugefügt haben, haben wir eine Kette von Ereignissen, die korreliert werden können: Das alles hat seinen Ursprung auf einem Rechner. Es wird als derselbe Benutzer gestartet. Die Betriebsregel sieht dann wie folgt aus:

{

(4663 + Zugriffsmaske 0x1 oder Sysmon 11)🡪 [ (4698 + relevant IOB list) 🡪

(4688+(TaskScheduler.dll or taskeng.exe)) 🡪

(4688 and rundll32) 🡪

(4663 or Sysmon 11 + generic list of system files) 🡪

(4688 and 1 of files in list and Token Elevation Type(%%1936 OR %%1937))🡪 (4657 +New value created OR existing value modified+ base64 matching pattern in value in time frame up to 5s)]

im Zeitfenster von 10 Min.

}

Wenn Sie nun diese SIEM- oder EDR-Regel mit den von Cymulate bereitgestellten Sigma-Regeln erstellt haben und einen Alarm davon sehen, ist die Wahrscheinlichkeit groß, dass Sie gerade den SolarWinds-Angriff erleben.

Wenn Sie immer noch Zweifel haben, können Sie immer noch einige optionale Stufen hinzufügen und die Regel durch zwei weitere Stufen erweitern. Diese sind Exchange Server Mailbox Export Cleanup und Exchange Exfiltration using basic HTTP Request, beziehungsweise.

Obwohl Windows keine eingebaute Ereignis-ID für HTTP/S-Anfragen hat, wird es immer {4660 auf Mailbox🡪 (HTTP-Anfrage + 4663 von Dateiname.zip/rar/tar/anderes)} geben. Um ein Ereignis von HTTP/S-Requests zu erhalten, können hier zusätzliche Systeme, z. B. ein System zur Analyse des Netzwerkverkehrs, helfen.

Optimieren Sie Ihre Sicherheitsabläufe mit Cymulate und Sigma Rules

Wie Sie bei der Aufschlüsselung dieses speziellen Angriffs gesehen haben, können Sie IOBs in Sigma Rules verwenden. Dies wird Ihren Sicherheitsoperationen helfen, zu hinterfragen, zu bewerten, zu messen und zu optimieren. Dies kann durch die Cymulate Plattform in allen Bereichen leicht erreicht werden. Die Schritte, die in diesem Artikel gezeigt werden, sollen bei der Optimierung helfen und eine Anleitung geben, wie man einen Angriff vom Typ SolarWinds verhindern kann. Wie Sie an der Cymulate-Plattform gesehen haben, kann ein Szenario, ob einfach oder komplex, bei der Optimierung Ihrer SIEM- oder EDR-Regeln helfen. Dies wird die Sicherheit Ihrer Organisation gegen die anspruchsvollsten Bedrohungen mit geringem Aufwand verbessern.

Wir wünschen Ihnen eine gute Jagd!

Und wie man in den Hungerspielen sagt: “Mögen die Chancen immer zu Ihren Gunsten stehen.”

Dieser Artikel wurde von Michael Ioffe, Senior Security Researcher bei Cymulate, geschrieben.

Fanden Sie diesen Artikel interessant? Folgen Sie THN auf Facebook, Twitter und LinkedIn, um weitere exklusive Inhalte zu lesen, die wir veröffentlichen.

Einige Teile dieses Artikels stammen aus:
thehackernews.com