6.1 Malware-Analyse und ihre Wirkung
Reverse Engineering heißt, etwas auseinanderzunehmen, um zu verstehen, wie es funktioniert. In der Malware-Analyse liefert es die Grundlage für Detection-Signaturen und für das Verständnis der Techniken, die Malware-Autoren einsetzen. Ein zentraler Baustein ist die Extraktion von Indikatoren: netzwerkbasiert (Kommunikationsmuster, C2-Adressen) oder hostbasiert (Dateinamen, Registry-Keys). Sie sind der Fingerabdruck der Malware und werden zu Detection-Signaturen.
6.1 a Statische Analyse im Detail
Statische Analyse untersucht Malware, ohne sie auszuführen — sicher, schnell und der übliche erste Schritt.
File Fingerprinting
Kryptografische Hashes (MD5, SHA-256) identifizieren die Datei eindeutig und ermöglichen den Abgleich mit Malware-Datenbanken.
Signature Analysis
Vergleich mit einer Datenbank bekannter Malware-Signaturen.
String Extraction
Eingebettete URLs, Dateipfade und Befehle geben Hinweise auf Funktion und Herkunft.
Disassembly
Maschinencode wird in lesbare Assembler-Instruktionen übersetzt.
Packer Identification
Erkennt Packer und Obfuskation — die Voraussetzung für weitere Analyse.
Code Analysis
Detaillierte Untersuchung von Assembler oder Quellcode, um Logik, versteckte Fähigkeiten und Payloads offenzulegen.
Praxis: Metadaten und Hashes
$ exiftool suspicious_file.exe
File Name: suspicious_file.exe
File Size: 1.2 MB
File Type: Win32 EXE
Time Stamp: 2023:06:15 14:30:22+02:00
PE Type: PE32
Subsystem: Windows GUI
Was verraten die Metadaten?
Eine für 32-Bit-Windows kompilierte ausführbare Datei, erstellt am 15. Juni 2023. Das Kompilierungsdatum ist besonders wertvoll: Es hilft, Malware-Kampagnen zu verfolgen und neue Varianten zu identifizieren.
$ sha256sum suspicious_file.exe
560d94675723166bf0cfa13a932836263c52a4ad16e0c670e89efdeb62391526 suspicious_file.exe
PS> Get-FileHash -Algorithm SHA256 suspicious_file.exe | Format-List
Algorithm : SHA256
Hash : 560D94675723166BF0CFA13A932836263C52A4AD16E0C670E89EFDEB62391526
Path : C:\path\to\suspicious_file.exe
Der Hash wird anschließend bei VirusTotal geprüft: Hash einfügen, Ergebnisse mehrerer Engines vergleichen, Einordnung ableiten. Findet ein Tool wie Detect It Easy zusätzlich einen Packer (z. B. UPX), muss vor der weiteren statischen Analyse entpackt werden — was mitunter dynamische Techniken erfordert.
6.1 b Dynamische Analyse im Detail
Auch Verhaltensanalyse genannt: Die Malware wird in einer kontrollierten Umgebung ausgeführt und ihr Verhalten in Echtzeit beobachtet. Voraussetzung ist eine saubere VM (VMware, VirtualBox) mit einem typischen Ziel-OS wie Windows 10 und einem Snapshot des sauberen Zustands.
Process Monitoring
ProcMon und Process Explorer (Sysinternals) zeigen Interaktionen mit Dateisystem, Registry und Netzwerk in Echtzeit.
Network Analysis
Wireshark, tcpdump oder Network Monitor erfassen den Traffic und decken Kommunikationsmuster und C2-Server auf.
API Call Tracing
API Monitor oder ProcMon im API-Modus zeigen, welche Windows-API-Funktionen mit welchen Parametern aufgerufen werden.
Memory Analysis
Volatility, Rekall und Memoryze finden versteckte Prozesse, injizierten Code und andere Artefakte im Speicher.
Systemänderungen
RegShot, Autoruns und Registry Explorer decken neue Dateien, Registry-Änderungen (besonders Autostart) und neue Prozesse auf.
Sandboxen
Cuckoo, ANY.RUN, Joe Sandbox und VMRay bündeln diese Techniken in einer automatisierten Analyse-Pipeline.
Der Malware-Analyse-Prozess
- 1
Sichere Analyseumgebung vorbereiten
Isoliertes Lab mit Virtualisierung, konfigurierter Netzwerktrennung und installierten Analyse-Tools — realitätsnah, aber sicher.
- 2
Samples beschaffen
Aus verlässlichen Quellen, unter Wahrung von Integrität und Sicherheit; Bösartigkeit vor der Analyse verifizieren.
- 3
Statische Erstanalyse
Dateityp bestimmen, Metadaten extrahieren, IoCs identifizieren, Bedrohungsgrad einschätzen und Analysetiefe planen.
- 4
Tiefe Statik & Reverse Engineering
Disassembler und Decompiler einsetzen; Kontrollfluss, Algorithmen, Verschlüsselung, Exploits und Persistenz verstehen.
- 5
Dynamische Analyse
Ausführung im Lab; Systemänderungen und Netzwerkkommunikation mit externen Servern und C2-Infrastruktur verfolgen.
- 6
Dokumentation
Verhalten, Code-Erkenntnisse und Anomalien festhalten; IoCs wie Hashes, IP-Adressen und Domains dokumentieren.
- 7
Detection & Mitigation entwickeln
Signaturen erstellen, Patches und Konfigurationsänderungen empfehlen, Ergebnisse mit Stakeholdern und Community teilen.
6.2 Unpacking, Decrypting und Deobfuscation
Das Zusammenspiel der drei Schutzschichten
Typischer Aufbau moderner Malware
- Payload verschlüsseln — etwa mit AES
- Code obfuskieren — die Routinen für Entschlüsselung und Ausführung verschleiern
- Executable packen — z. B. mit UPX komprimieren und die Struktur verändern
- Ausführung: Der Stub entpackt, der obfuskierte Code läuft, entschlüsselt die Payload und führt sie aus
Für Analysten heißt das: erst entpacken, dann deobfuskieren, dann entschlüsseln — in genau dieser Reihenfolge.
Unpacking: statisch und dynamisch
Statisches Unpacking
Untersucht die gepackte Datei ohne Ausführung. Verräterische Zeichen:
- Hohe Entropie in Sektionen (Maß für Zufälligkeit → Kompression oder Verschlüsselung)
- Auffällig wenige Imports oder Sektionen
- Verdächtige Sektionsnamen wie
UPX0,UPX1
Tools: PEiD, Exeinfo PE zur Packer-Erkennung, danach das passende Entpack-Tool (z. B. UPX selbst).
Dynamisches Unpacking
Die Malware wird in VM oder Sandbox ausgeführt und entpackt sich selbst im Speicher — nötig bei kundenspezifischen Packern, die statische Tools nicht erkennen.
- Debugger wie x64dbg oder OllyDbg nutzen
- Breakpoints auf Speicherfunktionen setzen:
VirtualAlloc,VirtualProtect - Bis zum Original Entry Point (OEP) laufen lassen
- Entpackten Code mit Scylla aus dem Speicher sichern
Bei fortgeschrittener Malware kombiniert man beides: statisch den Packer bzw. Stub identifizieren, dann dynamisch durch den Entpackvorgang steppen und mit Memory-Breakpoints den entpackten Code abgreifen. Process Hacker und Process Monitor helfen beim Beobachten der Speicherallokationen.
Decrypting: XOR und stärkere Verfahren
Viele Samples verschlüsseln Strings mit einfachem XOR — bitweise Operation, die 1 liefert, wenn die Eingaben unterschiedlich sind. XOR ist beliebt, weil es rechnerisch billig und reversibel ist: Zweimal mit demselben Schlüssel angewendet ergibt es wieder das Original. So verschwinden URLs, Pfade und Befehle aus dem Blickfeld einfacher String-Suchen.
def xor_decrypt(data, key):
return ''.join(chr(ord(char) ^ key) for char in data)
decrypted_url = xor_decrypt(
[chr(c) for c in [104, 100, 105, 100, 102, 100, 106, 112, 110, 43, 102, 106, 104]], 5)
print("The decrypted URL is:", decrypted_url)
# Ausgabe: The decrypted URL is: malicious.com
Kommt starke Kryptografie ohne Implementierungsfehler zum Einsatz, wird es deutlich schwerer: Analysten müssen die Verschlüsselungsroutinen reverse-engineeren, um an die Schlüssel zu kommen — per Code-Analyse (Ghidra, IDA Pro) oder indem sie die Schlüssel zur Laufzeit im Speicher abgreifen.
Obfuskations-Techniken
Control Flow Flattening
Die logische Reihenfolge des Codes wird aufgebrochen und umstrukturiert — der Programmablauf ist kaum noch nachvollziehbar.
Instruction Substitution & Reordering
Instruktionen werden durch äquivalente ersetzt oder umsortiert; bekannte Muster verschwinden.
Junk Code Insertion
Bedeutungslose Instruktionen blähen den Code auf und erschweren das Parsen durch statische Tools.
Data Obfuscation
Strings und Ressourcen (API-Namen, URLs, Dateinamen) werden verschlüsselt oder kodiert und erst zur Laufzeit entschlüsselt.
Name Obfuscation
Variablen und Funktionen erhalten bedeutungslose Namen, Symbolinformationen werden entfernt.
Deobfuscation in der Praxis
Beispiel: obfuskierter Python-Code
import base64
def GHI_jkl(n):
abc = lambda x: False if x <= 1 else True
def def_ghi(x):
for y in range(2, x):
if x % y == 0: return False
return True
return abc(n) and def_ghi(n)
encoded_string = base64.b64decode('MTc=').decode('utf-8')
num = int(encoded_string)
def is_prime(n):
if n <= 1:
return False
for i in range(2, n):
if n % i == 0:
return False
return True
number = 17 # 'MTc=' war Base64 für 17
Drei Schritte: sprechende Namen wiederherstellen, kodierte Strings dekodieren, den Kontrollfluss vereinfachen. Tools wie IDA Pro und Ghidra helfen beim Entfernen von Junk-Instruktionen.
6.3 Debugging-Techniken
Zentrale Techniken
Breakpoints setzen
Software-Breakpoints (INT3) sind einfach, aber erkennbar; Hardware-Breakpoints (Register DR0–DR7) verändern den Code nicht und sind schwer zu entdecken.
Memory Dumping
Speicherbereiche sichern — insbesondere Code-Sektionen mit den eigentlichen Programminstruktionen. Die Dumps lassen sich anschließend mit Disassembler oder Decompiler statisch analysieren.
API-Hooking
Eigener Code wird an definierten Punkten eingeklinkt — meist bei OS-Interaktionen. So lassen sich Parameter beobachten, Daten manipulieren oder Aufrufe ganz verhindern.
Plugins & Skripte
Automatisieren wiederkehrende Aufgaben — etwa Memory-Breakpoints, die bei Zugriff auf bestimmte Speicherregionen anhalten (z. B. verdächtige Schreibvorgänge).
Kernel-Mode-Debugging
Für Rootkits und Treiber: Debugger an den Kernel anhängen, Breakpoints setzen, Low-Level-Code analysieren. Standardwerkzeug unter Windows ist WinDbg.
Ausführungsfluss ändern
Variablenwerte anpassen oder Sprünge umleiten, um alternative Codepfade zu erzwingen — nützlich bei bedingten Payloads.
Werkzeuge im Vergleich
| Tool | Typ | Stärken | Grenzen |
|---|---|---|---|
| OllyDbg | User-Mode-Debugger, kostenlos | Intuitiv und effizient; Einzelschritt, Breakpoints, Speicherinspektion, Ablaufmanipulation | Kein Decompiler, keine Graph-View |
| x64dbg | Open-Source-Debugger | 32- und 64-Bit, starker Disassembler, Graph-View, Plugins | Windows-only |
| IDA Pro | Disassembler mit Debugger | Graph-View, Hex-Rays-Decompiler, sehr mächtig | Kommerziell und teuer |
| Ghidra | Disassembler/Decompiler | Kostenlos, Decompiler auf IDA-Niveau | Gewöhnungsbedürftige Oberfläche |
| Binary Ninja | Disassembler/Debugger | Einfache Bedienung, starkes Scripting | Kommerziell |
| WinDbg | Kernel-Mode-Debugger | Einziger Weg zu Rootkits und Treibern auf Kernel-Ebene | Komplex, Fehler können das System zum Absturz bringen |
6.4 Control Flow Analysis
Ein Programm besteht aus einer Folge von Instruktionen — aber es führt sie selten linear aus. Bedingungen und Schleifen bestimmen den Ablauf. Die Kontrollflussanalyse (CFA) zeigt, wie ein Programm zwischen Instruktionen und Funktionen wechselt.
Warum Kontrollflussanalyse?
Ausführungspfade verstehen
Alle möglichen Wege durch das Programm werden kartiert — die operative Logik der Malware wird sichtbar.
Schlüsselfunktionen finden
Payload-Auslieferung, Exfiltrationsroutinen und C2-Kommunikationsprotokolle lassen sich gezielt lokalisieren.
Obfuskation aufdecken
Durch genaues Verfolgen des Kontrollflusses lassen sich Verschleierungsschichten abtragen.
Bessere Erkennung bauen
Erkannte Muster in bösartigen Ausführungspfaden fließen in verhaltensbasierte Detection-Algorithmen ein.
Techniken
Statisch
- Disassembly mit IDA Pro, Ghidra oder Radare2 — Funktionsaufrufe, bedingte Sprünge und Schleifen nachvollziehen
- Control Flow Graphs — Vogelperspektive auf die Programmlogik, macht Obfuskation und kritische Entscheidungspunkte sichtbar
- Decompilation mit Hex-Rays oder Ghidra — rekonstruiert hochsprachlichen Pseudocode aus dem Binary
Dynamisch
- Debugger-Tracing mit WinDbg, OllyDbg oder GDB — Instruktion für Instruktion durch die Ausführung
- Emulation & Sandboxing — Cuckoo und Co. verfolgen Systemaufrufe, Netzwerkverkehr und Dateisysteminteraktionen und zeigen den Kontrollfluss im Kontext des Betriebssystems
- Besonders wertvoll, um bedingtes Verhalten aufzudecken, das statisch nicht sichtbar wird
6.5 Library- und Systemcalls
Library- und Systemcalls sind vom Betriebssystem bereitgestellte Funktionen, über die Programme Dienste des Kernels anfordern — Hardwarezugriff, Prozesssteuerung, Kommunikation. Sie sind das Fenster zum tatsächlichen Verhalten der Malware.
API-Monitoring
API-Monitoring fängt die API-Aufrufe einer laufenden Anwendung ab und protokolliert sie — Interaktionen mit Dateisystem, Netzwerk, Registry und Systemdiensten. Werkzeuge: API Monitor, Process Monitor, die Sysinternals Suite. So werden Reihenfolge und Kontext der Systeminteraktionen nachvollziehbar.
Häufig analysierte Systemaufrufe
| Kategorie | Aufrufe | Bedeutung in der Analyse |
|---|---|---|
| Dateioperationen | CreateFile, ReadFile, WriteFile |
Zugriff auf sensible Dateien, Änderung von Systemkonfigurationen, Anlegen neuer Dateien zur Payload-Speicherung. Auffällig: Zugriffe auf Systemdateien oder Dateien an ungewöhnlichen Orten. |
| Spurenverwischung | DeleteFile, MoveFile |
Löschen von Logs und temporären Dateien, Verschieben von Payloads — auch als Baustein fileless Techniken (Code wandert in den Speicher). Timing und Ziel dieser Aufrufe verraten den Lebenszyklus der Malware. |
| Netzwerkkommunikation | socket, connect, send, recv |
Aufbau von C2-Kanälen, Datenexfiltration oder Verbreitung auf weitere Systeme. |