# Malware-Analyse {{#include ../../banners/hacktricks-training.md}} ## Forensik-CheatSheets [https://www.jaiminton.com/cheatsheet/DFIR/#](https://www.jaiminton.com/cheatsheet/DFIR/) ## Online-Dienste - [VirusTotal](https://www.virustotal.com/gui/home/upload) - [HybridAnalysis](https://www.hybrid-analysis.com) - [Koodous](https://koodous.com) - [Intezer](https://analyze.intezer.com) - [Any.Run](https://any.run/) ## Offline-Antivirus- und Erkennungstools ### Yara #### Installation ```bash sudo apt-get install -y yara ``` #### Regeln vorbereiten Verwende dieses Skript, um alle yara malware rules von github herunterzuladen und zusammenzuführen: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\ Erstelle das _**rules**_ Verzeichnis und führe das Skript aus. Dadurch wird eine Datei namens _**malware_rules.yar**_ erstellt, die alle yara malware rules enthält. ```bash wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py mkdir rules python malware_yara_rules.py ``` #### Scan ```bash yara -w malware_rules.yar image #Scan 1 file yara -w malware_rules.yar folder #Scan the whole folder ``` #### YaraGen: Auf malware prüfen und yara rules erstellen Du kannst das Tool [**YaraGen**](https://github.com/Neo23x0/yarGen) verwenden, um yara rules aus einer Binärdatei zu generieren. Sieh dir diese Tutorials an: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/) ```bash python3 yarGen.py --update python3.exe yarGen.py --excludegood -m ../../mals/ ``` ### ClamAV #### Installation ``` sudo apt-get install -y clamav ``` #### Scan ```bash sudo freshclam #Update rules clamscan filepath #Scan 1 file clamscan folderpath #Scan the whole folder ``` ### [Capa](https://github.com/mandiant/capa) **Capa** erkennt potenziell bösartige **Fähigkeiten** in ausführbaren Dateien: PE, ELF, .NET. Es findet daher Dinge wie Att\&ck-Taktiken oder verdächtige Fähigkeiten wie: - check for OutputDebugString error - run as a service - create process Holen Sie es sich im [**Github repo**](https://github.com/mandiant/capa). ### IOCs IOC bedeutet Indicator Of Compromise. Ein IOC ist eine Menge von **Bedingungen, die** bestimmte potenziell unerwünschte Software oder bestätigte **Malware** identifizieren. Blue Teams verwenden diese Art von Definition, um **nach dieser Art von bösartigen Dateien** in ihren **Systemen** und **Netzwerken** zu suchen.\ Das Teilen dieser Definitionen ist sehr nützlich, denn wenn Malware auf einem Computer identifiziert und ein IOC für diese Malware erstellt wird, können andere Blue Teams es nutzen, um die Malware schneller zu identifizieren. Ein Tool zum Erstellen oder Ändern von IOCs ist [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\ Sie können Tools wie [**Redline**](https://www.fireeye.com/services/freeware/redline.html) verwenden, um **nach definierten IOCs auf einem Gerät zu suchen**. ### Loki [**Loki**](https://github.com/Neo23x0/Loki) ist ein Scanner für einfache IOCs.\ Die Erkennung basiert auf vier Erkennungsmethoden: ``` 1. File Name IOC Regex match on full file path/name 2. Yara Rule Check Yara signature matches on file data and process memory 3. Hash Check Compares known malicious hashes (MD5, SHA1, SHA256) with scanned files 4. C2 Back Connect Check Compares process connection endpoints with C2 IOCs (new since version v.10) ``` ### Linux Malware Detect [**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) ist ein Malware-Scanner für Linux, veröffentlicht unter der GNU GPLv2-Lizenz, der für die Bedrohungen in gemeinsam genutzten Hosting-Umgebungen entwickelt wurde. Er nutzt Threat-Daten aus network edge intrusion detection systems, um Malware zu extrahieren, die aktiv in Angriffen eingesetzt wird, und erzeugt Signaturen zur Erkennung. Zusätzlich stammen Threat-Daten auch aus user submissions über die LMD checkout-Funktion und aus malware community resources. ### rkhunter Werkzeuge wie [**rkhunter**](http://rkhunter.sourceforge.net) können verwendet werden, um das Dateisystem auf mögliche **rootkits** und Malware zu überprüfen. ```bash sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress] ``` ### FLOSS [**FLOSS**](https://github.com/mandiant/flare-floss) ist ein Tool, das versucht, obfuskierte Strings in ausführbaren Dateien mit verschiedenen Techniken zu finden. ### PEpper [PEpper ](https://github.com/Th3Hurrican3/PEpper)prüft einige grundlegende Dinge in der ausführbaren Datei (Binärdaten, Entropie, URLs und IPs, einige Yara-Regeln). ### PEstudio [PEstudio](https://www.winitor.com/download) ist ein Tool, das Informationen zu Windows-Executables wie imports, exports, headers liefert, prüft außerdem virus total und findet potenzielle Att\&ck techniques. ### Detect It Easy(DiE) [**DiE**](https://github.com/horsicq/Detect-It-Easy/) ist ein Tool, um zu erkennen, ob eine Datei **encrypted** ist und außerdem **packers** findet. ### NeoPI [**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) ist ein Python-Skript, das eine Vielzahl von **statistical methods** nutzt, um **obfuscated** und **encrypted** content in Text-/Script-Dateien zu erkennen. Der Zweck von NeoPI ist, bei der **detection of hidden web shell code** zu unterstützen. ### **php-malware-finder** [**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) versucht so gut wie möglich, **obfuscated**/**dodgy code** zu erkennen sowie Dateien, die **PHP**-Funktionen verwenden, die oft in **malwares**/webshells vorkommen. ### Apple Binary Signatures Beim Überprüfen eines **malware sample** solltest du immer die **Signatur** der Binary prüfen, da der **developer**, der sie signiert hat, bereits mit **malware** in Verbindung stehen könnte. ```bash #Get signer codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier" #Check if the app’s contents have been modified codesign --verify --verbose /Applications/Safari.app #Check if the signature is valid spctl --assess --verbose /Applications/Safari.app ``` ## Erkennungstechniken ### File Stacking Wenn du weißt, dass ein Ordner mit den **Dateien** eines Webservers **zu einem bestimmten Datum zuletzt aktualisiert** wurde, **prüfe** das **Datum**, an dem alle **Dateien** im **Webserver** erstellt und geändert wurden. Wenn ein Datum **verdächtig** ist, untersuche diese Datei. ### Baselines Wenn die Dateien eines Ordners **nicht verändert worden sein sollten**, kannst du die **Hashes** der **Originaldateien** des Ordners berechnen und mit den **aktuellen** vergleichen. Alles, was verändert wurde, ist **verdächtig**. ### Statistische Analyse Wenn die Informationen in Logs gespeichert sind, kannst du **Statistiken prüfen, z. B. wie oft jede Datei eines Webservers aufgerufen wurde**, da eine web shell zu den am häufigsten aufgerufenen gehören könnte. --- ### Android in-app native telemetry (no root) Auf Android kannst du nativen Code im Prozess der Ziel-App instrumentieren, indem du vor der Initialisierung anderer JNI-Libs eine kleine Logger-Library preloadest. Das ermöglicht frühe Einsicht in natives Verhalten ohne systemweite Hooks oder Root. Ein verbreiteter Ansatz ist SoTap: lege libsotap.so für die richtige ABI in das APK und injiziere einen System.loadLibrary("sotap")-Aufruf früh (z. B. statischer Initializer oder Application.onCreate), und sammle dann Logs aus internen/externen Pfaden oder als Logcat-Fallback. Siehe die Seite zum Android native reversing für Setup-Details und Log-Pfade: {{#ref}} ../../../mobile-pentesting/android-app-pentesting/reversing-native-libraries.md {{#endref}} --- ## Deobfuskation dynamischer Control-Flow (JMP/CALL RAX Dispatchers) Moderne Malware-Familien missbrauchen stark Control-Flow Graph (CFG) Obfuskation: statt eines direkten jump/call berechnen sie das Ziel zur Laufzeit und führen ein `jmp rax` oder `call rax` aus. Ein kleiner *Dispatcher* (typischerweise neun Instruktionen) setzt das finale Ziel abhängig von den CPU-`ZF`/`CF` Flags und zerstört damit vollständig die statische CFG-Rekonstruktion. Die Technik – demonstriert vom SLOW#TEMPEST loader – lässt sich mit einem dreistufigen Workflow umgehen, der nur auf IDAPython und dem Unicorn CPU-Emulator basiert. ### 1. Lokalisieren Sie jeden indirekten jump / call ```python import idautils, idc for ea in idautils.FunctionItems(idc.here()): mnem = idc.print_insn_mnem(ea) if mnem in ("jmp", "call") and idc.print_operand(ea, 0) == "rax": print(f"[+] Dispatcher found @ {ea:X}") ``` ### 2. Dispatcher-Bytecode extrahieren ```python import idc def get_dispatcher_start(jmp_ea, count=9): s = jmp_ea for _ in range(count): s = idc.prev_head(s, 0) return s start = get_dispatcher_start(jmp_ea) size = jmp_ea + idc.get_item_size(jmp_ea) - start code = idc.get_bytes(start, size) open(f"{start:X}.bin", "wb").write(code) ``` ### 3. Emuliere es zweimal mit Unicorn ```python from unicorn import * from unicorn.x86_const import * import struct def run(code, zf=0, cf=0): BASE = 0x1000 mu = Uc(UC_ARCH_X86, UC_MODE_64) mu.mem_map(BASE, 0x1000) mu.mem_write(BASE, code) mu.reg_write(UC_X86_REG_RFLAGS, (zf << 6) | cf) mu.reg_write(UC_X86_REG_RAX, 0) mu.emu_start(BASE, BASE+len(code)) return mu.reg_read(UC_X86_REG_RAX) ``` Führe `run(code,0,0)` und `run(code,1,1)` aus, um die *false* und *true* branch targets zu erhalten. ### 4. Einen direkten jump / call zurückpatchen ```python import struct, ida_bytes def patch_direct(ea, target, is_call=False): op = 0xE8 if is_call else 0xE9 # CALL rel32 or JMP rel32 disp = target - (ea + 5) & 0xFFFFFFFF ida_bytes.patch_bytes(ea, bytes([op]) + struct.pack('