XDR: Analyse eines mehrstufigen Angriffs mit Ngrok

Originalbeitrag von Aprilyn Borja, Abraham Camba, Khristoffer Jocson, Ryan Maglaque, Gilbert Sison, Jay Yaneza

Einer der Hauptvorteile einer Endpoint Detection and Response (EDR)-Sicherheitslösung besteht darin, dass sie so genannten Blue Teams (Sicherheitsmitarbeiter, die für die Instandhaltung und Analyse der Verteidigungsmechanismen des Unternehmensnetzwerks zuständig sing) die benötigten Einsichten liefern, um einen Sicherheitsvorfall bereits frühzeitig zu erkennen und einzugrenzen. Die Innovationen in der Sicherheitstechnologie werden häufig von einer entsprechenden Entwicklung bei den Tools und Techniken begleitet, die böswillige Akteure einsetzen. Das Trend Micro ™ Managed XDR Team musste kürzlich einen Vorfall bei einem Kunden lösen, der gezeigt hat, wie ein böswilliger Akteur mit bestimmten Techniken in einem Angriff die Analyse des Ablaufs erschwerte.

Im Juli 2020 stieß das Team von Trend Micro über die Endpunktsicherheitslösung Trend Micro Apex One ™ auf das folgende verdächtige Ereignis in der Umgebung eines Kunden:

Process: c:\windows\system32\reg.exe CommandLine: REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v <value> /t REG_SZ /d „\“c:\Windows\system32\<random name>\““ /f

Es war auffällig, dass erstens der Name des Wertes der erstellten Registry nach dem Muster eines bestimmten Sicherheitsanbieters gestaltet war. Zweitens gab es einen Fehler (oder vielleicht war es Absichtl) in der Schreibweise des Registry-Namens. Schließlich gab es noch die zufällig benannte ausführbare Datei im Systemverzeichnis. Betrachtet man all dies im Zusammenhang, so ließ der Alert die Alarmglocken schrillen.

Es zeigte sich, dass die ausführbare Datei einen Keylogger darstellte, der die Maus- und Tastenbewegungen an ein Gmail-Konto schickte. Das Team fand hartkodierte Informationen in der Binärdatei, die belegen, dass diese speziell für die Zielorganisation erstellt wurde. Darüber hinaus zeigte die Datei auch, dass die Angreifer bereits Informtionen über die Organisation hatten.

Die Durchsuchung der Records und Ereignisse über den Dateinamen des Keyloggers und Hash ergab folgende Erkenntnisse:

Datei-Events: Die Datei wurde entweder über Netzwerkfreigaben oder über den Einsatz eines Exploits den Kernel betreffend abgelegt.

Events mit Befehlszeilen-Parametern: Der Angreifer war in der Lage, einen Service zu erstellen, der eine Reihe von cmd.exe-Prozesse anstößt, um einen Persistenzmechanismus zu aufzubauen.

Registry-Daten: Es gab Einträge, die die Befehlszeilen-Parameter umfassten, die an reg.exe weiter gegeben wurden. Das erklärt auch die vielen cmd.exe-Prozesse.

Daraufhin drangen die Sicherheitsforscher tiefer vor und fanden heraus, dass es eine Komponente geben musste, die mit der Außenwelt kommunizierte – eine Kopie von ngrok, einem Softwareprogramm, über das eine interne Maschine nach draußen sichtbar ist, indem der Verkehr über die ngrok-Website geroutet wird. Ist das Tool auf zwei Maschinen vorhanden, so sind diese beiden extern sichtbar. Trend Micro hat bereits beschrieben, wie ngrok für bösartige Zwecke missbraucht werden kann.

Die genaueren technischen Details zur Analyse liefert der Originalbeitrag.

Simulieren eines Angriffs

Um die Funktionsweise des Angriffs zu verstehen, simulierte das Team eine solche Attacke und installierten ngrok auf einer der Maschinen (Maschine A), die weder von außen sichtbar noch zugänglich war.

Ngrok kann jeden offenen IP-Port innerhalb des internen Netzwerks, der für Maschine A (einschließlich sich selbst) zugänglich ist, im Internet exponieren. Im Beispiel exponierte ngrok eine weitere Maschine (Maschine B) 192.168.19.129:445 über den ngrok-Server. So konnte das Sicherheitsteam auf 192.168.19.129:445 über 2.tcp.ngrok.io:14139 zuzugreifen. Mithilfe des Smbexec-Dienstmoduls des Impacket Toolkits und der Anmeldedaten von Maschine B ließen sich von einer externen Maschine einfache Ping-Befehle an Maschine B senden.

Bild 1. Über eine externe Maschine lässt sich ein ping-Befehl an Maschine B senden.

Das daraus resultierende Verhalten war ähnlich dem in der Umgebung des Kunden, wo zufällig benannte Service-Einträge erstellt und dann gelöscht wurden. Die Befehle wurden ausgeführt, ohne dass eine Binärdatei auf dem Zielcomputer abgelegt werden musste.

Weil die Befehle als Dienst ausgeführt wurden, läuft er zudem mit erhöhten Privilegien. Da der Netzwerkverkehr über den ngrok-Dienst getunnelt wurde, war der Befehls- und Kontrollserver effektiv verborgen. Solange der Angreifer die von ngrok zugewiesene öffentliche Adresse kennt, kann er sich von überall und jederzeit mit dem kompromittierten Endpunkt verbinden.

Auch wenn nicht zu erwarten war, dass die Simulation die Aktionen des Angreifers vollständig wiedergeben würde, lieferte sie doch wertvolle Hinweise darauf, wie der Angriff möglicherweise abgelaufen war.

Im Falle der Simulation war es erforderlich, ngrok auf dem internen Rechner zu installieren, es bedurfte der Domäne und des Ports des ngrok-Servers sowie eines Administratorkontos. Es ist davon auszugehen, dass der Angreifer alle drei besaß, und sie schienen lange genug präsent gewesen zu sein, um bestimmte Details über die Umgebung zu ermitteln. Sie waren auch in der Lage, ein hochprivilegiertes Konto zu kompromittieren. Insoweit passt die von dem Team durchgeführte Simulation zu den Angriffseigenschaften.

EDR als Antwort

Bild 2. Root Cause-Analyseablauf einer typischen Backdoor Shell

Shell.exe startet cmd.exe, das dann das Tool zur Ausführung des angegebenen Befehls startet. Das Bild zeigt auch, wie das von ihr installierte Tool – wie Toola.exe – gestartet wird. Diese Art von Diagramm ist unkompliziert und macht es leicht, verdächtige Objekte zu identifizieren und den grundlegenden Ablauf eines Angriffs zu bestimmen.

Bei diesem Vorfall beginnt die Ursachenanalyse mit services.exe und endet mit dem ausgeführten Werkzeug oder Befehl. Es gab keine Hinweise darauf, dass jemals ein mehrstufiges Tool verwendet wurde, das andere Tools ablegt, und aufgrund des Zugriffs, den die Angreifer in diesem Modell hatten, ist es sehr wahrscheinlich, dass sie kein solches Tool benötigten. Die Maschinen waren zugänglich, so dass die Angreifer jedes Werkzeug ausführen konnten, das sie brauchten, ohne sich clevere Mechanismen zur Installation der Binärdatei ausdenken zu müssen (wie z.B. das seitliche Verschieben von einer Maschine auf eine andere). Zum Beispiel legten die Angreifer die Keylogger-Datei über den Server-Message-Block (SMB) ab und gaben einen separaten Befehl aus, um seinen Persistenzmechanismus zu schaffen.

Aussagekräftige Root Cause-Analyseabläufe sind schwer zu bekommen, weil alles mit services.exe beginnt (oder einem anderen Windows-Prozess, wenn eine Datei abgelegt wird), wobei jeweils ein Befehl bzw. ein Werkzeug ausgeführt wird. Der resultierende Ablauf ähnelt eher einem „Baum“ mit services.exe in der Mitte, wobei jeder Zweig einen Befehl darstellt, der über services.exe ausgeführt wird.

Die Analyse zeigt, dass die bei dem Angriff verwendete Technik für die Sicherheitsforscher sehr hinderlich dabei ist, die Abfolge der Ereignisse über ein kurzes Diagramm zusammenzusetzen. Bestimmte Funktionen von EDR sind jedoch für den Umgang mit Vorfällen wie diesem ausgelegt.

Abhilfe durch verdächtige Events

Verdächtige Ereignisse sind wirksame Auslöser für eine EDR-Lösung, und die Fähigkeit, mithilfe derselben Lösung Abhilfe zu schaffen, ist ideal für Sicherheitsteams. Bei diesem Vorfall nutzte Trend Micro Managed XDR die Apex One-Funktionen, um die Bedrohung mit derselben Software-Suite sowohl zu untersuchen als auch zu entschärfen.

Untersuchung über Log Events

Konventionelle Incident Response-Methoden erfordern oftmals den Einsatz eines Tools, um Beweise von einem verdächtigen Host zu erhalten. Bei dieser Untersuchung wurde alles durch die Auswertung der vom EDR protokollierten Ereignisse durchgeführt. Für die Untersuchung war keine Speicher- oder Disk-Image-Erfassung erforderlich, was bedeutet, dass die von EDR gesammelten Daten ausreichten, um festzustellen, wie ähnliche Angriffe funktionieren. Die chronologische Reihenfolge der Befehle wurde den Zeitstempeln der Ereignisse entnommen. Selbst ohne das selbsterklärende Diagramm, das EDR erstellt, ist es immer noch möglich, festzustellen, wie der Angriff stattgefunden hat.

Neue Alerts

EDR ermöglicht die mühelose Erstellung von Warnmeldungen, um eine Untersuchung auszulösen. In diesem Fall können neue Alerts immer dann erstellt werden, wenn services.exe cmd.exe startet und wenn %comspec% in einen Autostart-Registry-Eintrag geschrieben wird. Das kann für künftige Threat-Verfolgungsfähigkeiten für Blue Teams hilfreich sein.

Trend Micro-Lösungen

The Trend Micro XDR schützt E-Mails, Endpunkte, Server, Cloud-basierte Workloads und Netzwerke mithilfe funktionsstarker KI- und Sicherheits-Analytics, um Daten zu korrelieren. Die Lösung liefert ein optimiertes Set Alerts über eine einzige Konsole. Damit können Unternehmen schnell Bedrohungen erkennen und deren Auswirkungen zeitnah eindämmen.

Trend Micro Managed XDR bietet kenntnisreiches Bedrohungs-Monitoring, Korrelation und Analysen durch erfahrene Cybersicherheitsexperten, und das im Rahmen eines 24/7-Service, über den Kunden Erkennung, Analyse und Response aus einer einzigen Quelle erhalten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.