Skip to content

EXE oder DLL im Browser analysieren – ohne Ausführung

Statische Triage von Windows-Executables mit dem kostenlosen PE Parser: Dateien oder ZIP laden, Indikatoren lesen, Builds vergleichen, exportieren.

Veröffentlicht am Aktualisiert am 4 Min. Lesezeit

Kurz gesagt. Der PE Parser liest Windows-Executables so wie pestudio, PE-bear oder Detect It Easy – Header, Importe, Ressourcen, Signatur, Strings –, aber in einem Browser-Tab, für einen ganzen Stapel Dateien auf einmal und ohne etwas hochzuladen oder auszuführen. Hier eine 15-minütige Triage mit dem eingebauten synthetischen Beispiel.

Schritt 1: Dateien laden

Öffnen Sie die Startseite und ziehen Sie Ihre Dateien, einen Ordner oder ein ZIP hinein. Executables werden an ihrem MZ-Header erkannt, daher wird auch eine in .dat umbenannte Payload gefunden. Jede Datei wird von Rust-Code, der nach WebAssembly kompiliert ist, in einem eigenen Web Worker geparst: Nichts verlässt den Rechner und nichts wird ausgeführt. Zum Mitmachen klicken Sie auf Beispiel laden: fünf harmlose Dateien aus einem fiktiven Angriff – zwei Builds von m64.exe, eine signierte m64core.dll und eine kleine .NET-Anwendung SyncConfig.exe, deren Code aus einem einzigen ret besteht, dazu wupd.exe, ein echter mit UPX gepackter Build eines Programms, das nur eine Begrüßung ausgibt.

Schritt 2: Batch-Tabelle durchsehen

Der Arbeitsbereich öffnet sich im Vollbild (Esc zum Verlassen). Die Tabelle zeigt eine Zeile pro Datei: Typ, Kompilierzeit, Größe, Imphash, Anzahl der Indikatoren und Erkennungen. Sortieren Sie nach Ansehen. Die beiden m64.exe-Builds teilen sich einen Imphash und sind als Familie 1 markiert – dasselbe Tool, zweimal gebaut, im Abstand von neun Tagen (Imphash und Co.).

Sind mehrere Dateien geladen, filtert die Leiste Zeitraum nach Kompilier-, Debug- oder Signaturzeit; der Dichtestreifen zeigt, wann die Dateien gebaut wurden, und der Zeitraum wird in der URL der Seite gespeichert, sodass ein Link dieselbe Ansicht wieder öffnet.

Schritt 3: Datei öffnen und Indikatoren lesen

Klicken Sie auf C/ProgramData/Intel/m64.exe. Der Überblick zeigt die Identität (x64, GUI, Entry Point in .text), Hashes mit Kopier-Buttons, den PDB-Pfad C:\build\m64\Release\m64.pdb und die Zeitstempel. Das Banner zählt Indikatoren mit hoher und mittlerer Priorität. Der Tab Indikatoren erläutert jeden einzelnen – importierte Injection-APIs, eine schreibbare und ausführbare UPX1-Section mit einer Entropie nahe 8, ein TLS-Callback, 4 KB angehängte Daten hinter der letzten Section, OriginalFilename = synchelper.exe bei einer Datei namens m64.exe. Jeder Eintrag erklärt, warum er einen Blick wert ist und wann er normal ist.

Schritt 4: Signatur, Sections und Importe prüfen

  • Sections: Rechte, Roh- und virtuelle Größe, Entropiebalken pro Section (gepackte Executables erkennen).
  • Importe: pro DLL, mit Verhaltens-Tags; WS2_32.dll Ordinal 115 wird als WSAStartup angezeigt.
  • Ressourcen: Versionsinformationen, Manifest, Icon, String-Tabelle, Dialogtitel.
  • Strings: ASCII und UTF-16 mit Offsets und Kategorien – das Beispiel enthält IP-Adressen aus dem Dokumentationsbereich, .example-URLs, einen Run-Key-Pfad und einen harmlosen Base64-kodierten PowerShell-String, dekodiert zu Write-Output 'synthetic sample'.
  • Signatur: Öffnen Sie m64core.dll. Der Hash stimmt, die signierten Attribute stimmen und die RSA-Signatur ist gültig – aber das Zertifikat ist selbstsigniert und identifiziert damit niemanden (Authenticode offline).
  • Payloads: Öffnen Sie wupd.exe. Die Datei ist mit UPX gepackt, also dekomprimiert das Tool sie als Daten (nichts wird ausgeführt) und fügt wupd.exe!upx hinzu, das rekonstruierte Programm mit seinen echten Importen und seinem Compiler. Sein Overlay versteckt außerdem eine XOR-kodierte DLL: Der Tab Payloads zeigt, dass es Byte für Byte m64core.dll ist – Dropper und abgelegte Datei, verknüpft.
  • Header und Verzeichnisse: rohe Felder von DOS-, COFF- und Optional Header, Datenverzeichnisse, zu Visual-Studio-Releases dekodierte Rich-Header-Einträge, Debug, TLS, Load Configuration und Relocations.

Schritt 5: Verwandte Builds vergleichen

Die Ansicht Vergleichen stellt zwei Dateien nebeneinander: Header-Felder, Sections (gleich, geändert, nur in einer Datei), Importe, Exporte und Ressourcen sowie die TLSH-Distanz. Die beiden m64.exe-Builds haben identische Importe, aber unterschiedlichen Code und unterschiedliche Daten.

Schritt 6: Exportieren

Das Menü Exportieren bietet eine Inventar-CSV (Hashes, Zeiten, Signierer, Indikatoren; geschützt gegen Formula Injection), den vollständigen JSON-Bericht, eine Liste im sha256sum-Format für Threat-Intelligence-Abfragen, Importe und Exporte sowie Strings. Exporte folgen der aktuellen Ansicht und dem Zeitraum, und der Zeitraum erscheint in den Dateinamen.

Das Tool arbeitet rein statisch: UPX entpackt es selbst, andere Packer müssen anderswo entpackt werden, Zertifikatsketten werden nicht validiert, und Indikatoren sind Hinweise, keine Urteile.

Verwandte Artikel

Was bei der Triage einer verdächtigen EXE, DLL oder eines Treibers zählt: Header, Sections, Importe, Ressourcen, Signatur und Overlay.
Verdächtige EXE-, DLL- und SYS-Dateien von einem Windows-Host oder Image finden und kopieren, ohne sie auszuführen: PowerShell, Velociraptor, Images.
Wo eine Windows-Executable ihre Zeiten speichert, welchen man trauen kann, wie sich Reproducible Builds und Timestomping zeigen – und wie man sie nutzt.