Entwicklertools · Base64-Encoder und -Decoder
So dekodieren Sie einen verdächtigen Base64 PowerShell-Befehl, ohne ihn auszuführen
· Warum es wichtig ist
base64 Sicherheit
Angreifer nutzen Base64, um Skripte vor gelegentlicher Inspektion zu verbergen. Dieser Beitrag zeigt, wie man eine -EncodedCommand-Nutzlast dekodiert, ohne sie auszuführen, warum die Ausgabe in einem UTF-8-Decoder möglicherweise seltsam aussieht und worauf man achten muss.
Die geplante Aufgabe mit einem 2,000-Zeichenargument – wo codierte Befehle auftauchen und warum sie ein Warnsignal darstellen
Ein Systemadministrator entdeckt eine geplante Aufgabe mit einem 2,000-character -EncodedCommand-Argument, das verdächtig aussieht. Die Aufgabe wird unter einem Dienstkonto mit hohen Berechtigungen ausgeführt.
Die Versuchung, den Befehl in PowerShell einzufügen und auszuführen, um zu sehen, was er bewirkt, ist gefährlich; Wenn der Befehl bösartig ist, gefährdet seine Ausführung das System. Der sicherere Ansatz besteht darin, Base64 lokal zu dekodieren und die Ausgabe als Text zu lesen, bevor Sie entscheiden, ob etwas ausgeführt werden soll. In diesem Beitrag wird erläutert, wie Sie PowerShell-Befehle sicher dekodieren, ohne sie auszuführen, warum die Ausgabe in einem standardmäßigen UTF-8-Decoder möglicherweise verstümmelt aussieht und worauf Sie achten müssen, um zu beurteilen, ob ein Befehl sicher oder verdächtig ist.
Dekodieren, niemals ausführen – die Regel, die die Analyse sicher hält und warum ein reiner Browser-Decoder gut geeignet ist
Die wichtigste Erkenntnis ist, dass PowerShell die UTF-16LE-Codierung für -EncodedCommand verwendet, nicht UTF-8, sodass jedes zweite Byte eine Null ist, die Standardtools als Nullterminatoren interpretieren. Die Regel für die Analyse verdächtigen Codes ist einfach: Dekodieren, niemals ausführen. Dies gilt für Base64-codierte Befehle, komprimierte Skripte, Skripte aus nicht vertrauenswürdigen Quellen und alles in einer Kette unbekannter Codierung. Das Ausführen eines Skripts ist der Punkt, an dem es kein Zurück mehr gibt. Sobald es ausgeführt wird, wurden Änderungen am System vorgenommen, der Zugriff wurde gewährt und Daten wurden herausgefiltert.
Durch das Dekodieren und Lesen des Skripts als Text können Sie es vor dem irreversiblen Schritt bewerten. Die zweite Regel besteht darin, ein Tool zu verwenden, das lokal ausgeführt wird und keine Netzwerkanfragen stellt. Ein browserbasierter Decoder ist ideal, da er portabel ist, keine zusätzliche Software erfordert und die verdächtige Nutzlast auf Ihrem Gerät speichert, ohne sie auf einen Server hochzuladen. Wenn es sich bei dem Tool um ein Tool handelt, das Beiträge an einen Remote-Decoder-Dienst sendet, verwenden Sie es nicht. Die Nutzlast wird dann diesem Dienst ausgesetzt. Der PowerShell-Parameter -EncodedCommand akzeptiert eine Base64-Zeichenfolge, die bei der Dekodierung ein PowerShell-Skript enthält.
Warum die dekodierten Bytes anders aussehen als UTF-8-Text – überprüfen Sie das UTF-16LE-Bytemuster im Hexadezimalformat, anstatt dieses UTF-8-Texttool zu bitten, es zu interpretieren
PowerShell verwendet hierfür jedoch keine UTF-8-Kodierung; es verwendet UTF-16LE (Little-Endian UTF-16). In UTF-16 wird jedes ASCII-Zeichen als zwei Bytes dargestellt: der Zeichencode, gefolgt von einem Nullbyte. Der Buchstabe A ist 41 00 im Hexadezimalformat. Der Buchstabe B ist 42 00. Eine Zeichenfolge wie Hello erscheint als 48 00 65 00 6C 00 6C 00 6F 00 in UTF-16LE-Bytes. Wenn es Base64-kodiert ist, enthält das Ergebnis die kodierte Form aller dieser Bytes, einschließlich aller Nullen. Die Dekodierung mit einem standardmäßigen UTF-8-Decoder erzeugt verstümmelten Text oder schneidet beim ersten Null-Byte ab, da UTF-8 Null-Bytes als String-Abschlusszeichen behandelt.
Die Ausgabe sieht aus wie H e l o statt Hello, mit scheinbar zufälligen Zeichen oder fehlendem Text. Ein ausgearbeitetes Beispiel zeigt das Problem und die Lösung. Angenommen, ein PowerShell-Befehl codiert die einfache Zeichenfolge „Write-Host Hello“. PowerShell UTF-16LE kodiert dies in Bytes einschließlich aller Nullen, Base64 kodiert die Bytes und erzeugt eine lange Zeichenfolge wie VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Kopieren Sie diese Zeichenfolge in den Base64-Encoder und -Decoder in Ihrem Browser und klicken Sie auf „Dekodieren“. Der Standarddecoder versucht, das Ergebnis als UTF-8-Text zu interpretieren und erzeugt aufgrund der eingebetteten Nullen eine beschädigte oder abgeschnittene Ausgabe.
Arbeitsbeispiel: Dekodierung eines harmlosen Beispiel-codierten Befehls – Lesen des Textes über die verschachtelten Null-Bytes hinaus
Die Lösung besteht darin, stattdessen die Hex-Ansicht zu verwenden. Wechseln Sie zur Hex-Ansicht und Sie sehen die Bytes: 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. Das Lesen dieser Bytes als UTF-16LE-Paare ergibt W-r-i-t-e---K-o-s-h---H-e-l-l-o-. Mit etwas Erfahrung können Sie UTF-16LE-Hex direkt lesen oder die Bytes in eine Datei schreiben und sie mit einem lokal ausgeführten PowerShell- oder Python-Skript dekodieren.
Der praktische Ansatz besteht darin, das Muster zu notieren und zu bedenken, dass PowerShell UTF-16LE verwendet. Wenn Sie PowerShell -EncodedCommand im Browser dekodieren und die Ausgabe falsch aussieht, sehen Sie sich die Hex-Ansicht anstelle der Textansicht an. Die Hex-Ansicht zeigt jedes Byte einzeln. Jedes ASCII-Zeichen besteht aus zwei Bytes mit einer Null dazwischen. Wenn die Bytes bösartige Befehle wie New-AdminAccount, Reverse-DNS-Lookups oder den Export von Sicherheitsanmeldeinformationen buchstabieren, ist der Befehl verdächtig. Wenn die Bytes etwas Harmloses wie eine Verzeichnisliste oder ein einfaches Skript darstellen, ist der Befehl wahrscheinlich harmlos.
Verschachtelte Kodierung und Komprimierung – Base64 innerhalb von Base64 und GZIP-Streams, die Sie nicht als Text lesen können
Die Hex-Ansicht ist schwerer zu lesen als reiner Text, aber sicherer als das Raten anhand einer beschädigten UTF-8-Ausgabe. Verschachtelte Kodierung und Komprimierung erhöhen die Komplexität der Malware-Analyse. Ein PowerShell-Befehl könnte eine andere Base64-Zeichenfolge Base64-kodieren oder ein Skript mit gzip komprimieren und dann das Ergebnis Base64-kodieren. In einem verschachtelten Szenario dekodieren Sie das äußere Base64, lesen das Ergebnis und stellen fest, dass es selbst Base64 ist. Dekodieren Sie auch das und fahren Sie fort, bis Sie lesbaren Text oder ein Binärformat finden, das Sie nicht interpretieren können. Gzip und andere Komprimierungsformate beginnen mit magischen Bytes (1F 8B für gzip), die in der Hex-Ansicht sichtbar sind.
Wenn Sie Base64 dekodieren und die Hex-Ansicht mit 1F 8B beginnt, handelt es sich bei den Bytes um einen komprimierten Stream, der eine Dekomprimierung erfordert. Der Base64-Encoder und -Decoder zeigt Ihnen das Hex und hilft Ihnen, diese Muster zu identifizieren, ohne etwas auszuführen. Komprimierte oder weiter codierte Nutzdaten sind verdächtig, da sie Verschleierungsebenen hinzufügen.
Was für einen Vorfallbericht aufgezeichnet werden soll – der entschlüsselte Text, die Quelle und Hashes und nicht die Nutzlast selbst
Legitime Befehle erfordern selten mehrere Codierungsschritte. Die Erfassung von Erkenntnissen für einen Vorfallbericht erfordert Disziplin und Genauigkeit. Notieren Sie den genauen Base64-String, den Sie analysiert haben, wo und wann Sie ihn gefunden haben. Wenn Sie es entschlüsselt und verdächtige Befehle gefunden haben, beschreiben Sie die Befehle, fügen Sie jedoch noch nicht das vollständige Skript in den Bericht ein. Das Skript kann kompliziert oder lang sein.
Fügen Sie einen Hash (SHA-256) des dekodierten Skripts hinzu, damit der Befund überprüft und nachverfolgt werden kann. Wenn der Befehl eindeutig böswillig ist oder bekannte Ausnutzungstechniken verwendet, beziehen Sie die Teams für die Reaktion auf Vorfälle und die Sicherheit ein, bevor Sie Maßnahmen ergreifen. Führen Sie den Befehl niemals selbst aus, um zu sehen, was er bewirkt. Wenn Vorfallhelfer es zu Testzwecken ausführen müssen, tun sie dies in einer Sandbox-Umgebung, in der etwaige Schäden eingedämmt werden. Ihre Aufgabe ist es, das Risiko aus sicherer Entfernung zu entschlüsseln und einzuschätzen. Dieser Artikel deckt nicht den gesamten Umfang der Malware-Analyse, Sandbox-Umgebungen oder Angriffszuordnung ab.
Was hiervon nicht abgedeckt wird: Sandbox-Ausführung, Malware-Analysetools und Attribution
Das sind Themen für Sicherheitsexperten und Incident-Response-Teams. Der Anwendungsbereich konzentriert sich hier eng auf die sichere Dekodierung eines codierten PowerShell-Befehls, ohne ihn auszuführen, sodass Sie das Skript lesen und beurteilen können, ob es sich lohnt, es weiter zu untersuchen. Die Base64-Codierung dient der Verschleierung, nicht dem Schutz. Jeder, der über die Codierung und einen Decoder verfügt, kann das Skript extrahieren. Angreifer nutzen Base64, um der grundlegenden Erkennung zu entgehen und gelegentliche Inspektionen zu verhindern, und nicht, um ihre Absicht vor der Analyse zu verbergen. Ein entschlüsselter PowerShell-Befehl, der ein Remote-Skript abruft und ausführt, ist schädlich, unabhängig davon, ob Sie ihn selbst oder ein Sicherheitstool entschlüsseln.
Der praktische nächste Schritt nach der Entschlüsselung eines verdächtigen Befehls besteht darin, ihn dem zuständigen Team zu melden. Wenn es sich um Ihr eigenes System handelt, stellen Sie fest, ob und von wem die Aufgabe absichtlich erstellt wurde. Überprüfen Sie das Erstellungsdatum und das Konto, das es geplant hat. Wenn die Aufgabe nicht autorisiert ist, deaktivieren Sie sie, bewahren Sie die Details für forensische Zwecke auf und untersuchen Sie, wie der Angreifer die Berechtigung zum Erstellen der Aufgabe erlangt hat. Wenn der Befehl Netzwerkanforderungen oder Persistenzmechanismen wie Registrierungsänderungen oder die Erstellung geplanter Aufgaben enthält, ist er mit ziemlicher Sicherheit bösartig.
Fazit: Base64 ist Verschleierung, kein Schutz – wie der Base64-Encoder und -Decoder die Nutzlast lokal dekodiert, ohne dass sie jemals Ihren Computer verlässt
Wenn es legitime Verwaltungsfunktionen ausführt und die Erstellungsdetails normal sind, handelt es sich möglicherweise um ein legitimes Verwaltungsskript, das zufällig aus Gründen der Sicherheitsrichtlinie oder der Integration mit einem größeren Automatisierungstool codiert wurde. Führen Sie es nicht so oder so aus; Lassen Sie Ihre Beurteilung des entschlüsselten Textes Ihre Entscheidung beeinflussen. Die sichere Dekodierung verdächtiger Base64-PowerShell-Befehle folgt einem unkomplizierten Prozess. Verwenden Sie den Base64-Encoder und -Decoder, um die Zeichenfolge zu dekodieren, ohne sie hochzuladen oder etwas auszuführen. Schauen Sie sich die Hex-Ansicht an, um zu verstehen, was die Bytes darstellen.
Wenn Sie UTF-16LE-Muster (verschachtelte Null-Bytes) sehen, denken Sie daran, dass PowerShell UTF-16LE verwendet, und lesen Sie entsprechend. Identifizieren Sie verdächtige Muster wie Netzwerkanfragen, Rechteerweiterungen oder Persistenzmechanismen. Notieren Sie die Details für Ihren Vorfallbericht genau, einschließlich der ursprünglichen Base64-Zeichenfolge und ihres Hashs. Führen Sie den Befehl niemals selbst aus; Überlassen Sie dies den Einsatzkräften in einer kontrollierten Umgebung. Vertrauen Sie Ihrer lokalen Dekodierung und Ihrer Einschätzung des Klartextes und lassen Sie sich bei Ihrer nächsten Aktion davon leiten.