PowerShell-Deobfuscator
Fügen Sie einen obfuskierten PowerShell-Befehl oder ein Skript ein. Es wird Schicht für Schicht in Ihrem Browser decodiert — nichts wird hochgeladen, nichts wird ausgeführt — und das Ergebnis wird als inerter Text angezeigt, verdächtige Muster als zu prüfende Hinweise aufgelistet.
PowerShell-Obfuskierung verbirgt, was ein Skript tut, hinter Schichten: ein Base64-codiertes -EncodedCommand, gzip-Komprimierung, Zeichencodes, Zeichenkettenverkettung, der -f-Formatoperator und Backtick-Escapes — jede Schicht wird der Reihe nach abgezogen, bis lesbarer Text übrig bleibt oder der Punkt erreicht ist, an dem statisches Auflösen stoppt. Dieses Tool zieht diese Schichten eine nach der anderen ab und zeigt jeden Schritt, damit Sie sehen, was das Skript sagt, ohne es auszuführen. Wenn das Skript aus einem Windows-Ereignisprotokoll stammt, liest der EVTX-Viewer die .evtx-Datei und markiert 4104-Ereignisse; für andere Textprotokolle findet der Log-Parser die Zeilen, auf die es ankommt. Der Begleitartikel PowerShell-Skripte deobfuskieren erklärt die Schichten und den sicheren Ablauf in Prosa.
Zuletzt aktualisiert:
Ereignis 4104 (PowerShell Script Block Logging) teilt lange Skripte in nummerierte Fragmente. Fügen Sie die Fragmente ein — Header in beliebiger Reihenfolge — und sie werden nach ScriptBlockId gruppiert, nach MessageNumber sortiert und zusammengefügt. Fehlende Teile werden markiert, und der reassemblierte Text kann an den Deobfuscator geschickt werden.
🔒 Ihr Skript wird in Ihrem Browser aufgelöst und verlässt Ihr Gerät nie. Kein Konto, kein Upload, kein Serveraufruf — und nichts hier wird jemals ausgeführt.
Was mit dem Skript passiert, das Sie einfügen
Nichts verlässt Ihren Browser. Das Skript wird lokal per JavaScript auf dieser Seite aufgelöst: kein Upload, kein Serveraufruf, keine Speicherung, kein Konto. Das ist wichtig, weil ein verdächtiges Skript niemals in einen Chat eingefügt werden sollte — ein Chat könnte es ausführen, zitieren oder speichern — und niemals ausgeführt werden sollte, um zu sehen, was es tut. Schließen der Seite verwirft es.
Was ein sauberes Ergebnis NICHT beweist
Ein sauberes Ergebnis ist kein Sicherheitsbeweis. Es bedeutet, dass keine bekannte Schicht griff und kein Indikator traf — eine dynamisch gebaute Zeichenkette, eine verschlüsselte Payload oder ein Wert, der nur zur Laufzeit existiert, lässt sich statisch nicht auflösen, und ein Skript ohne Indikatoren kann trotzdem bösartig sein.
Ein Indikator ist kein Beweis für Bosheit. Download-Cradles, IEX und codierte Befehle haben legitime Verwendungen in Administration und Deployment; jeder Treffer ist ein Hinweis, der im Kontext zu prüfen ist, kein Urteil.
Führen Sie ein unbekanntes Skript niemals aus, um herauszufinden, was es tut. Decodieren Sie es inert, übergeben Sie das Ergebnis an Ihr EDR oder eine Sandbox, und behandeln Sie den decodierten Text mit demselben Misstrauen wie die codierte Form — er ist ein Beweisstück, kein Gesundheitszeugnis.
Wie das Auflösen funktioniert
Das Tool probiert acht Schichten der Reihe nach, eine pro Schritt, und wiederholt, bis keine Schicht mehr greift oder zehn Schichten abgezogen wurden: -EncodedCommand-Extraktion (Base64 nach UTF-16LE, notfalls UTF-8); ein bloßer Base64-Blob; gzip- oder Deflate-Dekomprimierung (die Eingabe darf zuerst Base64-umhüllt sein); [char]- und [char[]]-Codefolgen; Zeichenkettenverkettung über gemischte Anführungszeichen und Zeilen hinweg; der -f-Formatoperator; Entfernung von Backtick-Escapes; und eine Auflistung von ${...}- und $Variablen-Platzhaltern, die niemals aufgelöst werden, weil ihre Werte nur zur Laufzeit existieren. Jeder Schritt zeigt den Text vorher und nachher, mit Zeichenzahlen.
Was das Tool NICHT tut: Es führt niemals etwas aus — das Ergebnis ist inerter Text, und die Seite kann ihn nicht einmal versehentlich ausführen. Es kann dynamisch gebaute Zeichenketten, verschlüsselte Payloads oder Werte, die nur zur Laufzeit existieren, nicht auflösen, und es urteilt nicht, ob ein Skript sicher ist: Die Indikatoren sind Musterübereinstimmungen, und ein Skript, das jede Schicht besiegt, wird als „konnte nicht weiter aufgelöst werden" gemeldet, niemals als sauber.
Script Block Logging (Ereignis 4104) zeichnet den Skripttext auf, den PowerShell tatsächlich ausgeführt hat, aber lange Skripte werden in Fragmente von etwa 4 KB geteilt, jedes mit einer ScriptBlockId, einer MessageNumber und einer MessageTotal. Der Reassemblierungs-Tab gruppiert Fragmente nach ScriptBlockId, sortiert sie nach MessageNumber, fügt sie zusammen und markiert fehlende Teile — eine Gruppe mit 2 von 3 Teilen, bei der Teil 2 fehlt, ist unvollständig, und der fehlende Text lässt sich nicht raten. Der reassemblierte Text geht in denselben Deobfuscator.
Häufige Fragen
Warum wird das Ergebnis als inerter Text statt als ausführbares Skript gezeigt?
Weil es beim Deobfuskieren darum geht, ein verdächtiges Skript zu lesen, nicht es auszuführen. Der decodierte Text kann immer noch eine Payload herunterladen und ausführen — als inerter Text mit einem Kopier-Button können Sie ihn inspizieren, an Ihr EDR oder eine Sandbox weitergeben und riskieren niemals einen Doppelklick.
Das Tool stoppte mit „konnte nicht weiter aufgelöst werden". Was nun?
Der restliche Text verwendet eine Schicht, die dieses Tool nicht kennt, baut seine Zeichenketten zur Laufzeit, oder ist verschlüsselt — statisches Auflösen hat seine Grenze erreicht. Führen Sie es nicht aus, um es herauszufinden: Übergeben Sie die codierte Form und die Teil-Decodierung an Ihr EDR oder eine Sandbox, und behandeln Sie die unbekannte Schicht als Grund zum Misstrauen, nicht als sauberes Ergebnis.
Was mache ich mit den Indikatoren?
Behandeln Sie jeden als Frage, nicht als Antwort. Ein Download-Cradle fragt, wohin die URL zeigt und ob dieser Host erwartet wird; ein AMSI-Umgehungsmuster fragt, warum das Skript den Scanner blenden will; ein codierter Befehl fragt, was die Codierung verbarg. Prüfen Sie jeden im Kontext — in Ihrem EDR, Ihren Logs und dem Rechner, von dem das Skript kam — bevor Sie etwas entscheiden.