Office-Malware-Forensik-Labor — REMnux-Statikanalyse

Statische Analyse zweier bösartiger Office-Dateien, vollständig innerhalb einer isolierten REMnux-VM durchgeführt. Es wurde nie etwas ausgeführt — nur inspiziert.

Einrichtung

• REMnux-VM, keine freigegebenen Ordner mit dem Host
• Werkzeuge: sha256sum, file, unzip und die oletools-Suite (oleid, olevba, oledump, mraptor)
• Beide Proben von MalwareBazaar (abuse.ch) bezogen

Probe 1: Bösartiges Word-Dokument (.docx)

SHA-256: 68e82279bff55cf3b9f1f22ec4a165b1b1245a359f7e8d86664b2541d8f8d3fe

Was ich gefunden habe:

• Eine Datei innerhalb des docx (nste.xml) war tatsächlich Rich-Text-Format-Daten, die sich als XML ausgaben — eine Diskrepanz, die für sich genommen bereits ein Warnsignal ist
• Ein eingebettetes Objekt war eine 196 KB große VBS-ausführbare Datei (419876.vbs)
• Ein weiteres eingebettetes Objekt entsprach CVE-2017-11882 — ein bekannter Equation-Editor-Exploit, der allein durch das Öffnen der Datei ausgeführt wird, ohne dass Makros erforderlich sind

Urteil: Bösartig. Dies ist ein echtes weaponisiertes Dokument, das eine bekannte RCE nutzt, um eine ausführbare Datei abzulegen.

Probe 2: Bösartige Excel-Datei (.xlsx)

SHA-256: dc65419ba5d83b980d7018198a14209fa2f5ebf6f99d47bfe9f586852087befe

Was ich gefunden habe:

• Die Datei war verschlüsselt (passwortgeschützt), was normalerweise Makroinhalte vor AV-Scannern verbirgt
• Sie enthielt 4 VBA-Module, aber alle 4 kamen leer zurück — mraptor meldete „Macro OK" ohne AutoExec/Write/Execute-Flags
• Ein Arbeitsblatt war ausgeblendet
• Es befanden sich hex-kodierte Zeichenketten in einem XLM-Makro-Stream alten Stils, getrennt von der VBA-Ebene
• Das Dekodieren dieser Zeichenketten brachte weder Shellcode noch eine Download-URL zutage — nur einige Typbibliotheks-Identifikatoren

Urteil: Verdächtig, aber nicht schlüssig. Die Verschlüsselung, das ausgeblendete Blatt und die obfuskierten Zeichenketten sehen alle nach Verschleierungstaktiken aus, aber ich konnte keine tatsächlich aktive Nutzlast in der VBA-Ebene bestätigen. Die eigentliche Nutzlast könnte in der Legacy-XLM-Makro-Ebene liegen (die ich nicht vollständig zurückentwickelt habe), oder es könnte sich um eine unvollständige/Vorbereitungs-Probe handeln.

Schritte, die ich befolgt habe

1. Jede Datei hashen (SHA-256) für die Beweiskette
2. Den echten Dateityp mit file prüfen und mit der Dateiendung vergleichen
3. oleid für einen schnellen Überblick über Verschlüsselung/Makros/externe Links ausführen
4. oledump ausführen, um jedes eingebettete Objekt aufzulisten
5. olevba ausführen, um etwaigen VBA-Quellcode zu extrahieren und zu dekodieren
6. mraptor ausführen, um auf automatisch ausgeführtes Makroverhalten zu prüfen

Was dies zeigt

• Wie man eine Dateityp-Diskrepanz erkennt, die zur Umgehung der Erkennung genutzt wird
• Wie CVE-2017-11882 ganz ohne Makros funktioniert
• Wie man Makroverhalten tatsächlich überprüft, statt es aus oberflächlichen Indikatoren anzunehmen
• Warum Verschlüsselung + ausgeblendete Blätter + obfuskierte Zeichenketten nicht automatisch „bestätigt bösartig" bedeuten — manchmal sind die Beweise nicht schlüssig, und das sollte man klar sagen

Quellen

• CVE-2017-11882: Microsoft Equation Editor RCE
• oletools: https://github.com/decalage2/oletools
• MalwareBazaar: https://bazaar.abuse.ch
• REMnux-Dokumentation: https://docs.remnux.org

Autor

Mofolorunsho Adeleke GitHub: https://github.com/Mo200909