Tools sind ein wesentlicher Bestandteil moderner Cyberangriffe und daher auch in Red Teaming Projekten. Die Open-Source-Community ist dabei Fluch und Segen zugleich – sie entwickelt und teilt frei Tools, die viele mühsame manuelle Schritte automatisieren. Diese Tools werden sowohl von Verteidigern als auch Angreifern eingesetzt. Viele dieser Tools entsprechen heutzutage einem De-facto-Standard für bestimmte Arten von Angriffen, beispielsweise Tools wie SharpHound. Natürlich kennen Verteidiger diese Tools ebenfalls und stufen sie dementsprechend als verdächtig ein. Daher werden sie von modernen AV/EDR-Lösungen in der Regel blockiert. Um sie dennoch verwenden zu können, kommen Obfuscation- und Evasion-Techniken ins Spiel. Dieser Artikel zeigt, wie wir diesen Obfuscation- und Evasion-Prozess automatisiert haben.

Einführung

Dieses Kapitel gibt eine Einführung in die Malware Obfuscation und erläutert, warum sie in heutigen Red Team Projekten relevant und notwendig ist. Zusätzlich wird erklärt, was Obfuscation und Evasion sind, wie dies auf einem hohen Level funktioniert und was uns dazu veranlasst hat, den Obfuscation-Prozess zu automatisieren. Im Verlauf dieses Artikels wird der Begriff Malware allgemein verwendet und schliesst offensive Security-Tools und Frameworks ein, die häufig in Red Team Projekten eingesetzt werden.

Warum Obfuscation (und Evasion) in Red Team Projekten wichtig ist

Wie oben erwähnt, ist der Einsatz von bekannten Tools notwendig, um manuelle Arbeit zu automatisieren und damit die Kosten für Kunden minimal zu halten und dennoch eine dedizierte Lösung für jeden Kunden zu haben. Die individuelle Entwicklung von Tools für jedes Projekt ist weder praktisch noch kosteneffizient, kann aber auf Wunsch oder unter besonderen Umständen Sinn ergeben. Entsprechend ist die Wiederverwendung von bekannten Open-Source-Tools unerlässlich. Da der Quellcode der meisten dieser Tools öffentlich verfügbar ist, können Verteidiger sie leicht erkennen und dementsprechend reagieren. Die Reaktionen können von der Blockierung bis zur Isolierung der Bedrohung reichen. Die Erkennung selbst hat sich erheblich weiterentwickelt – angefangen bei Anti Virus (AV) Systemen bis hin zu modernen Endpoint Detection and Response (EDR) Lösungen, welche Systeme durch den Einsatz verschiedener Erkennungstechniken schützen. Um diese bekannten Tools dennoch einsetzen zu können, muss das Konzept der Evasion angewendet werden. Wir haben hierzu bereits einen Artikel über die Umgehung von AV Systemen veröffentlicht. Dieser ist zwar keine Voraussetzung für diesen Artikel, dient jedoch als wertvolle Ergänzung.

Was ist Evasion und Obfuscation und wie wird es angewendet

Evasion kombiniert verschiedene Techniken, um einer Erkennung von Malware durch Sicherheitslösungen zu entgehen. Diese Techniken umfassen beispielsweise Sandbox-Evasion, das Deaktivieren verschiedener Erkennungsfunktionen, aber auch Obfuscation (Verschleierung zu Deutsch). Obfuscation beschreibt Techniken, die Attribute von Malware so verändern, dass sie von einem AV/EDR-System nicht mehr erkannt wird. Diese Attributveränderungen können dazu führen, dass die Malware ihre Signaturen verändert, ihr Verhalten anpasst oder sogar ihren eigenen Code dynamisch modifiziert. Die gewählte Obfuscation-Technik hängt in der Regel von der im Zielsystem eingesetzten Sicherheitslösung und deren Erkennungsmethoden ab. Beispiele für solche Verschleierungen könnten das Verschlüsseln von Teilen des Codes mit anschliessender Entschlüsselung zur Laufzeit, das Verändern des Kontrollflusses der Malware oder das Hashen von Funktionsnamen und deren Auflösung zur Laufzeit mittels einer Lookup-Tabelle sein. Da diese Techniken wertvoller sind, wenn sie nicht bekannt sind, neigt die Community dazu, nicht alles zu teilen. Dennoch gibt es grossartige Bücher, Artikel und Fachbeiträge zu EDR-Evasion. Die folgenden werden empfohlen, ohne hier weiter in die Tiefe zu gehen:

• MITRE ATT&CK Technik T1027
• Evasive Malware (Buch Kyle Cucci, 2024)
• Evading EDR (Buch Matt Hand, 2024)
• MalDevAcademy (Online-Plattform)

Hürden der manuellen Obfuscation

Manuelle Obfuscation umfasst viele iterative Schritte. Um Malware ordnungsgemäss zu verschleiern und sicherzustellen, dass sie einer Erkennung entgeht, sind vor allem bei weit verbreiteten und bekannten Open-Source-Tools wie SharpHound oder Seatbelt selbst bereits verschleierte Varianten häufig noch erkennbar. Dies liegt daran, dass Verteidiger nicht nur die originalen Tools, sondern auch deren gängige verschleierte Varianten mit Signaturen versehen. Nach einer Erkennung muss die nächste Obfuscation-Methode ausprobiert werden. Dies ist frustrierend und zeitaufwändig, besonders bei Kundenprojekten mit begrenzten Zeitbudgets. Daher haben wir uns zum Ziel gesetzt, diesen Prozess durch eine Malware Obfuscation CI/CD-Pipeline zu automatisieren. Das wird im folgenden Kapitel genauer erläutert.

Umsetzung

Um eine nützliche Pipeline zu erstellen, wurden Anforderungen definiert. Das stellt sicher, dass die Pipeline, insbesondere in ihrer Anfangsphase, die relevantesten Anwendungsfälle abdeckt. Die folgenden Anforderungen wurden festgelegt.

• Die Pipeline muss die Obfuscation von mindestens C#/.NET und PowerShell-Skripten unterstützen
• Die Pipeline soll einem modularen Ansatz folgen, um einfache Modifikationen und Erweiterungen um andere Programmtypen, Obfuscation- und Evasion-Methoden sowie zusätzliche Obfuscation-Skripte, Tools und Erkennungslösungen nachrüsten zu können
• Verschleierte Malware muss gegen AV/EDR-Lösungen validiert werden
• Verschleierte Malware, die die AV/EDR-Validierung besteht, wird automatisch in das interne Repository für den Einsatz übertragen
• Obfuscation muss auf Arbeitskopien durchgeführt werden, die Originaldateien dürfen nicht verändert werden
• Falls möglich, sollen Tests durchgeführt werden, um festzustellen, ob die Obfuscation die Malware beschädigt hat
• Die Pipeline muss sämtliche Aktivitäten protokollieren, um eine Rekonstruktion der durchgeführten Aktionen pro Pipeline-Durchlauf zu ermöglichen
• Nutzung, Einrichtung und Fehlerbehebung der Pipeline müssen dokumentiert werden

Vorgehen

Basierend auf den festgelegten Anforderungen wurde zunächst ein minimales Konzept der Pipeline erarbeitet. Wie bereits erwähnt, wurde entschieden, eine Continuous Integration und Continuous Delivery/Deployment (CI/CD) Pipeline zu verwenden. Dabei handelt es sich um eine Software-Entwicklungspraxis, die verschiedene Phasen wie Build, Test und Release des Entwicklungszyklus automatisiert. Diese Pipelines entstammen der DevOps-Bewegung. Eine ausführliche Erklärung zu CI/CD-Pipelines ist bei GeeksForGeeks zu finden.

Basierend auf den Anforderungen und dem Konzept wurden die Architektur und die Tools für diese Pipeline ausgewählt, sowie bestimmte Konfigurationsentscheidungen getroffen. Anschliessend wurde ein Pipeline-Ablauf erarbeitet. Die folgenden Unterkapitel erläutern die Ergebnisse dieser Schritte auf einem hohen Level.

Konzept

Um die Iterationen der Malware-Obfuscation in eine Pipeline zu überführen, muss der Prozess in einzelne reproduzierbare Schritte zerlegt werden. Jeder dieser Schritte benötigt einen klar definierten Input und Output. Zudem sollte sich jeder Schritt auf eine spezifische Aufgabe konzentrieren. Dies ermöglicht Modularität, da ein einzelner Schritt einfacher angepasst werden kann als ein gesamtes Programm. Die übergeordneten erforderlichen Schritte sind:

1. Repository auf eine Obfuscation-Maschine übertragen
2. Malware in ein Arbeitsverzeichnis kopieren
3. Malware-Kopien verschleiern
4. Verschleierte Malware validieren
   1. Falls erkannt, Obfuscation wiederholen
   2. Falls nicht erkannt, verschleierte Malware in das interne Repository übertragen

Pipeline-Architektur, Tools und Konfiguration

Zunächst mussten die einzusetzenden Tools ausgewählt werden. Wie bereits erläutert, war CI/CD der bevorzugte Ansatz, mit Gitea als Plattform der Wahl. Gitea ist eine Open-Source-Alternative zu GitHub, die CI/CD-Funktionalität über den Gitea Act Runner integriert. Der Act Runner muss auf einem Zielsystem installiert werden, um die Software bereitzustellen und mit ihr zu interagieren. Windows wurde als Betriebssystem des Zielsystems gewählt, da der Grossteil der in Red Team Projekten eingesetzten Malware auf Windows-Systeme abzielt. Um die Malware zu kompilieren und zu transformieren, kann der Act Runner entweder Docker-Container bereitstellen oder direkt auf dem Hostsystem ausgeführt werden. Die direkte Ausführung auf dem Host wurde gewählt, da die Unterstützung von Windows Docker-Containern in unserem Setup unzuverlässig war. Der Act Runner musste auf dem Windows-System installiert und bei der Gitea-Instanz registriert werden.

Weitere Tools umfassen Malware-Obfuscation-Tools wie CodeCepticon oder yetAnotherObfuscator sowie Erkennungslösungen wie DefenderCheck, Yara oder THOR Lite. Diese müssen auf dem Windows-System installiert und entsprechend konfiguriert werden. Da DefenderCheck und andere Tools auf Windows Defender angewiesen sind, bleibt dieser aktiviert. Jedoch sollten Ausnahmen für das Malware-Repository und die Transformationsordner erstellt werden. Zusätzlich muss die Funktion Automatic Sample Submission von Microsoft Defender deaktiviert werden, da sonst das Risiko besteht, dass die neu verschleierte Malware unmittelbar von Microsoft identifiziert werden kann.

Pipeline Ablauf Übersicht

Der folgende übergeordnete Pipeline-Ablauf wurde etabliert:

Der Prozess beginnt mit der Gitea Actions Pipeline auf der Gitea-Weboberfläche. Alle Schritte der Pipeline sind in der Datei .gitea/workflows/runner.yaml dokumentiert. Diese YAML-Datei enthält jeden Schritt, wo die Schritte ausgeführt werden sollen, sowie die für das Pullen und Pushen benötigten Secrets. Die verwendete Datei wird in diesem Artikel nicht geteilt. Für diese Implementierung wurde das manuelle Auslösen der Pipeline gegenüber einer automatischen Planung bevorzugt. Beim manuellen Start können einige optionale Parameter eingegeben werden. Solche Parameter umfassen die zu wählende Build-Architektur oder ob alle Malware-Dateien verschleiert werden sollen.

Zunächst wird das aktuelle Repository mit der Malware gepullt. Anschliessend werden einige Verfügbarkeitsprüfungen durchgeführt, um sicherzustellen, dass alle benötigten Programme wie Compiler, Erkennungslösungen und Obfuscation-Tools vorhanden sind. Dann startet die erste Schleife. Diese erste Schleife ist ein dedizierter Schritt, der prüft, ob jede Malware-Datei erfolgreich kompiliert und ob sie bereits von den Erkennungslösungen erkannt wird. Falls eine Kompilierung erforderlich ist und fehlschlägt, sind wahrscheinlich Fehler in der Malware vorhanden, die vor der Obfuscation behoben werden sollten. Falls die Malware nicht erkannt wird, besteht technisch gesehen keine Notwendigkeit zur Obfuscation. Dies kann durch den der Pipeline übergebenen Parameter geändert werden. Der gesamte Prozess wird für alle verfügbaren Malware-Dateien wiederholt. Alle Malware-Dateien, die einer Obfuscation bedürfen, werden in ein Obfuscation-Verzeichnis kopiert. Anschliessend wird die Eignung der Malware für die Obfuscation geprüft. Bei einigen Malware-Dateien sind bekannte Fehler im Zusammenhang mit Obfuscation vorhanden. Diese Fälle sollten erkannt und die betroffene Malware aus der Warteschlange entfernt werden.

Als nächstes startet eine weitere Schleife, die Obfuscation und Validierung versucht. Beide im selben Schritt auszuführen vermeidet den Overhead der Kommunikation zwischen einzelnen Schritten. Falls beim Start der Pipeline keine spezifischen Parameter gesetzt wurden, beginnt die Schleife mit der ersten Malware-Datei im Obfuscation-Verzeichnis. Diese wird mit der ersten Technik verschleiert und direkt gegen die Erkennungslösung getestet. Die verwendete Technik wird durch den Zähler j repräsentiert. Die Obfuscation-Runde wird durch den Zähler i repräsentiert. Da eine Obfuscation-Technik nicht immer dieselbe Ausgabe produziert, kann es sinnvoll sein, dieselbe Technik auf einer frischen Kopie der Datei zu wiederholen. Dieser Ansatz wurde von Pavel Tsakalidis in seinem Vortrag über CodeCepticon vorgeschlagen. Dieselbe Obfuscation-Technik wird bis zu fünfmal wiederholt. Anschliessend wird eine andere Technik angewendet, j wird erhöht und i auf eins zurückgesetzt. Falls fünf Techniken fehlschlagen, markiert die Pipeline die Malware als fehlgeschlagen und fährt fort. Falls die Obfuscation erfolgreich war, kopiert die Pipeline die verschleierte Malware zusammen mit unterstützenden Dateien, wie einer Mapping-Datei für Funktionsnamen, in den Gitea-Repository-Ordner. Sobald alle Malware-Dateien verarbeitet wurden, wird das Gitea-Repository gepusht und Bereinigungsaufgaben werden ausgeführt, um das System auf den nächsten Durchlauf vorzubereiten.

Limitierungen

Es ist wichtig zu beachten, dass diese Pipeline ihre Limitierungen und Schwächen hat. Es gibt zwei wesentliche Schwachstellen einer solchen Pipeline; fehlerhafter Code und Erkennung nach der Obfuscation.

Das grössere Problem besteht darin, dass der Malware-Code nach der Obfuscation beschädigt sein kann und daher nicht mehr verwendet werden kann. Zusätzlich ist es nicht möglich zu verifizieren, dass jede verschleierte Malware wie beabsichtigt funktioniert, da bestimmte Malware spezifische Voraussetzungen wie beispielsweise eine Active Directory-Umgebung benötigt. Darüber hinaus wären Testfälle für jede Malware-Datei sehr spezifisch und müssten mit jeder Aktualisierung der Malware angepasst werden.

Das kleinere Problem ist die Erkennung der Malware auch nach der Obfuscation. Dies kann sehr häufig vorkommen und ist auch der Grund, warum eine Validierung in den Pipeline-Ablauf integriert wurde. Selbst nach erfolgreicher Umgehung der Erkennung während der Validierung kann eine verschleierte Malware aus verschiedenen Gründen erkannt werden, beispielsweise durch ein EDR-System mit mehr Kontext oder durch eine manuelle Untersuchung und die Hinzufügung neuer Signaturen. Dies ist einfach zu beheben, da die Pipeline einfach erneut ausgeführt werden kann, um eine neue verschleierte Variante zu erzeugen.

Ein alternativer Ansatz , basierend auf Azure DevOps, wurde von Chester Adams dokumentiert.

Fazit

Die Pipeline ist etabliert und hat den manuellen Aufwand für unsere Tester erheblich reduziert, erfordert von Zeit zu Zeit noch manuelle Überprüfungen, Anpassungen und Fehlerbehebungen, insbesondere bei komplexer oder sehr gezielter Malware. Mit der Zeit und Erfahrung wird sich dies weiter verbessern. Es ist geplant, die Pipeline mit weiteren Obfuscation-Techniken und Tools, granulareren Obfuscation-Optionen für spezifische Payloads, einer Sandbox-Integration sowie weiteren Erkennungslösungen, Code-Signing, mehrschichtiger Obfuscation und der Unterstützung weiterer Betriebssysteme und Architekturen zu erweitern.

Dank der Durchführung von Red- und Purple Team Projekten konnte die Resilienz, gegen gezielte und ausgeklügelte Cyberangriffe, unserer Kunden nachweislich erhöht werden. Zu Teilen auch Dank der Etablierung der in diesem Artikel umschriebenen Obfuscation Pipeline.

Über den Autor

Yann Santschi hat eine Systemtechnikerlehre bei SIX abgeschlossen und danach bei einer der Big Four Consulting Firmen als Cyber Security Consultant gearbeitet. Er macht gegenwärtig seinen Bachelor in Information and Cyber Security mit dem Major in Attack Specialist and Penetration Testing an der HSLU. Sein Fokus liegt auf Webapplikationen, Netzwerksicherheit und Social Engineering.

Links

• https://about.gitea.com/
• https://attack.mitre.org/techniques/T1027/
• https://blog.xpnsec.com/building-modifying-packing-devops/
• https://docs.gitea.com/usage/actions/act-runner
• https://github.com/0xb11a1/yetAnotherObfuscator
• https://github.com/GhostPack/Seatbelt
• https://github.com/SpecterOps/SharpHound
• https://github.com/matterpreter/DefenderCheck
• https://github.com/sadreck/Codecepticon
• https://maldevacademy.com/
• https://nostarch.com/evading-edr
• https://nostarch.com/evasive-malware
• https://virustotal.github.io/yara/
• https://www.geeksforgeeks.org/devops/what-is-ci-cd/
• https://www.nextron-systems.com/thor-lite/
• https://www.scip.ch/?labs.20230413
• https://www.youtube.com/watch?v=zIeBD4GsnFg