Rubeus gegen YARA: Wer wird gewinnen? Entdecke den Schlüssel zur Flucht
Celia Catalán
Einführung
In Unternehmensumgebungen wird die Ausführung von Tools wie Mimikatz, Rubeus und anderen weithin bekannten Binärdateien häufig blockiert, da fortschrittliche Sicherheitsmaßnahmen wie Antiviruslösungen (AV) und EDRs implementiert sind. Diese Barrieren stellen eine erhebliche Herausforderung dar, wenn es darum geht, Sicherheitsanfälligkeiten nachzuweisen. Angesichts dieses Problems gibt es zwei Hauptansätze:
- Alternative Werkzeuge verwenden, die dieselben Ausbeutungstechniken auf andere Weise implementieren.
- Die bestehenden Werkzeuge modifizieren, um zu verhindern, dass sie erkannt werden.
Ziel
In dieser Pille konzentrieren wir uns auf den zweiten Ansatz: wie man ein Werkzeug, dessen Quellcode verfügbar ist, modifizieren kann, ohne seine Funktionalität zu beeinträchtigen. Dazu ist es wichtig, die Methoden zu verstehen, die die Erkennungssysteme verwenden, um diese Werkzeuge als bösartig zu identifizieren und zu katalogisieren. In der Regel verwenden diese Systeme zwei Hauptstrategien:
- Statische Analyse der Binärdatei: Untersucht die Datei, ohne sie auszuführen, um Muster, Signaturen und bösartige Artefakte zu identifizieren.
- Dynamische Analyse und Verhaltensüberwachung: Überwacht die laufende Binärdatei, bewertet deren Aktionen und wie sie mit dem System interagiert.
In diesem Fall konzentrieren wir uns auf die statische Analyse, die in praktischen Begriffen auf der Erkennung von Signaturen basiert. Statische Analysewerkzeuge können Binärdateien dekompilieren und nach spezifischen Mustern im Code suchen, um festzustellen, ob ein Werkzeug möglicherweise bösartig ist. Zum Beispiel können Funktionsnamen, statische Zeichenfolgen oder charakteristische Bytefolgen als verdächtig markiert werden.
Wenn wir dieses Konzept auf die Verwendung von YARA-Regeln anpassen, wird die Erklärung intuitiver. Die YARA-Regeln werden von Sicherheitsanalysten und Erkennungstools verwendet, um verdächtige Dateien anhand eines definierten Mustersatzes zu identifizieren. Diese Regeln bestehen aus:
- Hexadezimale Ketten: Definieren spezifische binäre Muster oder Bytes in der Datei
- Textketten: Identifizieren relevante Wörter oder Phrasen
- Reguläre Ausdrücke: Ermöglichen die Definition komplexerer und flexiblerer Muster.
Im Beispiel gibt es bestimmte Variablen von $a bis $d, die zunächst definiert sind und später in der Bedingung der Regel verwendet werden. Wenn $a oder $b erfüllt ist und $c oder $d erfüllt ist, wird die Regel ausgeführt und als Ergebnis der Analyse der Probe angezeigt.
Beispiel
Für das folgende Beispiel verwenden wir ein vordefiniertes Regel-Combo Yaraforge , um Rubeus zu umgehen.
Rubeus ist ein in C# geschriebenes Tool, um mit Kerberos zu interagieren und es auszunutzen, wodurch Angriffe wie Kerberoasting, ASREPRoasting, Overpass-the-Hash, Pass-the-Ticket, Missbrauch von Ressourcendelegation und Persistenz im Active Directory ermöglicht werden. Der Quellcode ist in seinem Repository zu finden. Es gibt bereits eine von dem Ersteller bereitgestellte und leicht verständliche Yara-Regel.
Wenn eine der beiden Bedingungen (definiert mit dem logischen Operator AND) nicht erfüllt ist, wird die Regel nicht ausgeführt und umgangen. Die Zeichenfolge bezieht sich auf die GUID des Standardprojekts, sodass Sie durch Erstellen einer neuen GUID und deren Änderung in den Projekteigenschaften die Regel umgehen sollten.
Um die Regeln zu kennen, die für das Rubeus-Projekt gelten, muss man Folgendes haben:
- Rubeus initial kompiliert
- Binäres YARA zur Überprüfung der Regeln
- Die Regeln von Yara Forge
Mit der folgenden Syntax wird das ursprünglich kompilierte Binary ausgeführt. Es sind vier YARA-Regeln zu sehen, die im Folgenden umgangen werden, unter Verwendung von Visual Studio mit der Funktion Suchen und Ersetzen.
Regel: FIREEYE_RT_Hacktool_MSIL_Rubeus_1
Diese Regel haben wir bereits zuvor besprochen, da sie die gleiche ist, die im Repository existiert. Durch die Änderung der GUID des Projekts mit einer anderen gültigen wird es möglich sein, diese Regel zu umgehen.
"Der GUID im Rubeus-Projektcode wird geändert. Beim erneuten Kompilieren und Starten des YARA-Regel-Scans werden wir die Erkennungsfähigkeit basierend auf dieser Regel entfernen."
Regel: SIGNATURE_BASE_HKTL_NET_GUID_Rubeus
Während der Ausführung des vorherigen Scans werden wir feststellen, dass wir nicht nur eine, sondern zwei entfernt haben, die enthalten ist. Dies liegt daran, dass diese Regel auch die GUID des Projekts zur Erkennung berücksichtigt.
Regel: ELASTIC_Windows_Hacktool_Rubeus_43F18623
Die folgende Regel hat das Ziel, die Literale der Ausgabemeldungen von Rubeus zu suchen. In diesem Fall berücksichtigt der logische Operator ODER beide Seiten, um sowohl die GUID als auch vier der zuvor definierten Literale zu erfassen. Da auf der linken Seite die GUID im geänderten Projekt für die vorherigen Regeln nicht mehr existiert, bleibt nur noch, vier der acht Literale zu entfernen. Alle diese teilen etwas Gemeinsames, den Identifikator [Y], wobei Y ein Wert zwischen *, +, X oder ! sein kann. Wenn wir die Funktion Suchen und Ersetzen verwenden, können wir all diese Werte in den Klammern ändern, um den Match mit dem Literal zu entfernen. Diese Änderung ist sicher, da die Klammern normalerweise als Dekoration in den Ausgabemeldungen verwendet werden, aber je nach Szenario muss überprüft werden, dass wir die Benutzerfreundlichkeit des Binaries nicht verlieren.
Wir wiederholen den Prozess bei den verbleibenden Symbolen, indem wir die Erkennung der YARA-Regel entfernen.
Regel: DITEKSHEN_INDICATOR_TOOL_PWS_Rubeus
Diese letzte Regel umfasst die Namen der Funktionen, die intern von Rubeus verwendet werden, sowie einige der Eingabeparameter. Im ersten Fall gibt es keine Schwierigkeiten bei der Modifikation des Codes, aber bei den Parametern muss besondere Rücksicht genommen werden, da wir Eingabeparameter ändern, die berücksichtigt werden müssen. Ein Fall ist rc4opsec, der als Abfrageparameter verwendet wird, um ein sicheres Ticket zu erstellen. Damit die Regel gebrochen wird, muss, da es sich um einen AND-Operator handelt, eines der Segmente entfernt werden, zum Beispiel, dass acht der zehn zuvor definierten Literale vorhanden sind. Mit der Modifikation von drei davon wird diese Regel nicht mehr markiert.
Wir suchen drei Literale und ändern sie mit alternativen Namen, um die Anforderungen zu erfüllen. Zum Beispiel:
Wir wiederholen diesen Prozess mit den folgenden Literalen:
- WriteUserPasswordToFile zu WriteTheUserPasswordCredentialsToFile
- rc4opsec von errec4opsec
Diese Regel wird nicht mehr ausgeführt, wodurch die Erkennungsfähigkeit der Verteidigungssysteme, die diesen Scan verwenden, entfällt.
Schlussfolgerungen
In dieser Lieferung haben wir erkundet, wie es auf einfache Weise möglich ist, Werkzeuge durch die Modifikation ihres Originalcodes zu verbergen. Dieser Ansatz zielt darauf ab, Indicators of Compromise (IOC) und typische Spuren bekannter Werkzeuge zu entfernen, die in geschützten Umgebungen oft schnell erkannt werden. In realen Szenarien ist die Komplexität jedoch viel größer, und diese grundlegenden Modifikationen sind oft unzureichend, um modernen Lösungen von Antivirus (AV) und EDR zu entkommen, aufgrund von Faktoren wie:
- Eigene Erkennungsregeln: Jedes Sicherheitsprodukt verfügt über spezifische, nicht öffentliche Regeln, was deren Umgehung erschwert.
- Dynamische Analyse: Neben den Signaturen integrieren viele EDR Verhaltensanalysen, die überwachen, wie die Tools mit dem System interagieren.
Im Folgenden listen wir einige Schlüsselpunkte und Schwierigkeiten auf, die bei der Entwicklung fortschrittlicherer Ausweichtechniken berücksichtigt werden sollten:
- Erweiterte YARA-Regeln: Einige Regeln erkennen nicht nur literale Zeichenfolgen oder spezifische Funktionen, sondern berücksichtigen auch Byte-Muster oder komplexere Strukturen (wie es der Fall ist, wenn wir dasselbe Szenario, aber mit Mimikatz verwenden).
- Eigene Regeln für Sicherheitsprodukte: Öffentlich nicht zugängliche Erkennungen erfordern umfangreiche Tests und einen iterativen Ansatz, um effektive Umgehungstechniken zu finden.
- Zusätzliche Faktoren: Über die statischen Regeln hinaus bewerten Sicherheitssysteme verdächtige Aktionen, digitale Signaturen des Binärs und Anomalien im Ausführungsfluss, weshalb die Umgehung umfassend sein muss.
Axel Losantos, Senior Offensive Security Consultant bei Zerolynx von Cybertix
