Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
SilentMoonwalk — PoC-Implementierung eines vollständig dynamischen Call-Stack-Spoofers | Kitploit
Tools/GitHubGitHub/klezvirus/silentmoonwalk
ExploitationReverse EngineeringBinäranalyseRed TeamingPayload-Entwicklung
GitHubklezvirus/silentmoonwalk

SilentMoonwalk

PoC-Implementierung eines vollständig dynamischen Call-Stack-Spoofers

Repository anzeigen
985113vor 2 JahrenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

SilentMoonwalk

PoC-Implementierung eines vollständig dynamischen Call-Stack-Spoofers

TL;DR

SilentMoonwalk ist eine PoC-Implementierung eines vollständig dynamischen Call-Stack-Spoofers, der eine Technik implementiert, um den ursprünglichen Aufrufer aus dem Call-Stack zu entfernen, indem ROP verwendet wird, um das Unwinding vom Kontrollfluss zu desynchronisieren.

Autoren

Diese PoC ist das Ergebnis einer gemeinsamen Forschung zum Thema Stack-Spoofing. Die Autoren der Forschung sind:

  • KlezVirus
  • Waldo-IRC
  • Trickster0

Ich möchte betonen, dass diese Arbeit ohne die Arbeit von Waldo-IRC und Trickster0 unmöglich gewesen wäre, die beide zu den frühen Phasen der PoC und zur Forschung hinter der PoC beigetragen haben.

Übersicht

Dieses Repository demonstriert eine PoC-Implementierung zum Spoofen des Call-Stacks beim Aufruf beliebiger Windows-APIs.

Dieser Versuch wurde inspiriert von diesem Twitter-Thread und diesem Twitter-Thread, in denen Sensei namazso zeigte und vorschlug, den Stack-Unwinding-Ansatz mit einer ROP-Kette zu erweitern, um sowohl das Unwinding vom echten Kontrollfluss zu desynchronisieren als auch den ursprünglichen Stack danach wiederherzustellen.

Diese PoC versucht, etwas Ähnliches wie oben zu tun, und verwendet einen Desync-Stack, um den ursprünglichen Aufrufstapel vollständig zu verbergen, wobei auch die EXE-Imagebasis daraus entfernt wird. Bei der Rückkehr wird ein ROP-Gadget aufgerufen, um den ursprünglichen Stack wiederherzustellen. Im Code wird dieser Prozess 10 Mal in einer Schleife wiederholt, wobei bei jeder Iteration unterschiedliche Frames verwendet werden, um die Stabilität zu beweisen.

Unterstützte Modi

Das Tool unterstützt derzeit 2 Modi, wobei einer eigentlich ein falscher Patch für einen nicht funktionierenden Pop-RBP-Frame ist, der erkannt wurde, und funktioniert, indem der aktuelle RSP verschoben und zwei gefälschte Frames zum Aufrufstapel hinzugefügt werden. Da es mit synthetischen Frames arbeitet, bezeichne ich diesen Modus als "SYNTHETIC".

Wenn der Frame ausgewählt wird, der durch Poppen des RBP-Registers vom Stack entlädt, könnte das Tool einen ungeeigneten Frame auswählen, was zu einem abrupt abgeschnittenen Aufrufstapel führt, wie unten zu sehen.

Windows 10 Call Stack - Cut

Synthetischer Aufrufstapel-Modus

Eine alberne Lösung für das Problem wäre es, zwei gefälschte Frames zu erstellen und sie wieder mit dem abgeschnittenen Aufrufstapel zu verknüpfen. Dies würde eine Art scheinbar legitimen Aufrufstapel erzeugen, selbst ohne einen geeigneten Frame, der durch Aufrufen von POP RBP entlädt, aber:

  • Sie würden den Vorteil der Desync-Technik verlieren
  • Der Stack wäre immer noch entladbar
  • Der resultierende Aufrufstapel könnte auf den ersten Blick legitim erscheinen, würde aber wahrscheinlich eine strenge Prüfung nicht bestehen

Das Ergebnis des _synthetischen Spoofs kann im folgenden Bild beobachtet werden:

Windows 10 Call Stack - Apparently Legit, non unwoundable - getchar

Abbildung 1: Windows 10 - Scheinbar legitimer, nicht entladbarer Aufrufstapel, bei dem das EXE-Modul vollständig entfernt wurde (Aufruf der parameterlosen Funktion getchar)

Hinweis: Dieser Betriebsmodus ist standardmäßig deaktiviert. Um diesen Modus zu aktivieren, ändern Sie CALLSTACK_TYPE auf 1

Desync-Stack-Modus

Dieser Modus ist die richtige Lösung für das obige Problem, wobei der ungeeignete Frame einfach durch einen anderen, geeigneten ersetzt wird.

Windows 10 Call Stack - Legit, unwoundable - MessageBoxExA

Abbildung 2: Windows 10 - Legitimer, entladbarer Aufrufstapel, bei dem das EXE-Modul vollständig entfernt wurde (Aufruf der 4-Parameter-Funktion MessageBoxA)

Hilfsprogramm

Im Repository finden Sie auch ein kleines Hilfsprogramm zur Inspektion von Laufzeitfunktionen, das nützlich sein kann, um Laufzeitfunktionseinträge zu analysieren.

root@kitploit:~
UnwindInspector.exe -h

 Unwind Inspector v0.100000

 Mandatory args:
   -m <module>: Target DLL
   -f <function>: Target Function
   -a <function-address>: Target Function Address

Beispielausgabe:

root@kitploit:~
UnwindInspector.exe -m kernelbase -a 0x7FFAAE12182C
[*] Using function address 0x7ffaae12182c

  Runtime Function (0x000000000000182C, 0x00000000000019ED)
  Unwind Info Address: 0x000000000026AA88
    Version: 0
    Ver + Flags: 00000000
    SizeOfProlog: 0x1f
    CountOfCodes: 0xc
    FrameRegister: 0x0
    FrameOffset: 0x0
    UnwindCodes:
    [00h] Frame: 0x741f - 0x04  - UWOP_SAVE_NONVOL     (RDI, 0x001f)
    [01h] Frame: 0x0015 - 0x00  - UWOP_PUSH_NONVOL     (RAX, 0x0015)
    [02h] Frame: 0x641f - 0x04  - UWOP_SAVE_NONVOL     (RSI, 0x001f)
    [03h] Frame: 0x0014 - 0x00  - UWOP_PUSH_NONVOL     (RAX, 0x0014)
    [04h] Frame: 0x341f - 0x04  - UWOP_SAVE_NONVOL     (RBX, 0x001f)
    [05h] Frame: 0x0012 - 0x00  - UWOP_PUSH_NONVOL     (RAX, 0x0012)
    [06h] Frame: 0xb21f - 0x02  - UWOP_ALLOC_SMALL     (R11, 0x001f)
    [07h] Frame: 0xf018 - 0x00  - UWOP_PUSH_NONVOL     (R15, 0x0018)
    [08h] Frame: 0xe016 - 0x00  - UWOP_PUSH_NONVOL     (R14, 0x0016)
    [09h] Frame: 0xd014 - 0x00  - UWOP_PUSH_NONVOL     (R13, 0x0014)
    [0ah] Frame: 0xc012 - 0x00  - UWOP_PUSH_NONVOL     (R12, 0x0012)
    [0bh] Frame: 0x5010 - 0x00  - UWOP_PUSH_NONVOL     (RBP, 0x0010)

Bauen

Um die PoC zu bauen und ein ähnliches Verhalten wie im Bild zu beobachten, stellen Sie sicher, dass Sie:

  • GS deaktivieren (/GS-)
  • Code-Optimierung deaktivieren (/Od)
  • Whole Program Optimization deaktivieren (/GL entfernen)
  • Größen- und Geschwindigkeitspräferenz deaktivieren (/Os, /Ot entfernen)
  • Intrinsic aktivieren, falls nicht bereits aktiviert (/Oi)

Vorherige Arbeiten

Es lohnt sich, frühere Arbeiten zu diesem Thema zu erwähnen, die die Grundlage für diese Arbeit bildeten.

  • Return Address Spoofing: Originaltechnik und Idee von Namaszo. Jede andere mir bekannte PoC wurde darauf aufgebaut.
  • YouMayPasser: Diese erstaunliche Arbeit von Arash ist die erste ordentlich durchgeführte Erweiterung der Return-Address-Spoofing-PoC von Namaszo.
  • VulcanRaven: Ein Call-Stack-Spoofer, der das Spoofing durch synthetisches Erstellen eines Thread-Stacks durchführt, der einen anderen echten Aufrufstapel spiegelt.
  • Unwinder: Eine sehr schöne Rust-PoC-Implementierung eines Call-Stack-Spoofers, der durch das Parsen von Unwind-Code-Informationen arbeitet, um Frames im Aufrufstapel zu ersetzen.

Danksagungen

  • Großer Dank an waldo-irc und trickster0, die mit mir an dieser Forschung zusammengearbeitet haben. Ich verdanke ihnen alles.
  • Die gesamte Anerkennung für die Idee dahinter gebührt namaszo, den ich persönlich für ein Genie halte. Er hat diese PoC vor der Veröffentlichung auch gegengeprüft, daher ein riesiges Dankeschön an ihn.

Hinweise

  • [NUR SYNTHETISCHER STACK]: Aufgrund einer Einschränkung in der Art und Weise, wie ich die Gadgets finde, beträgt die maximale Anzahl von Argumenten derzeit 8 (es ist TRIVIAL, zu modifizieren und weitere Parameter hinzuzufügen, aber ich habe mich nicht darum gekümmert).
  • [NUR DESYNC-STACK]: Aufgrund einer Einschränkung bei der Einrichtung des Spoofers beträgt die maximal unterstützte Anzahl von Argumenten derzeit 4.
  • Die Tests hierfür waren recht begrenzt. Es könnte Ausnahmen geben, die mir derzeit nicht bekannt sind.
  • Das Entladen unter Beteiligung von 128-Bit-Registern wurde nicht getestet.
  • Das Aufrufen von Funktionen, die 128-Bit-Register verwenden, wird offiziell nicht unterstützt.
Tool herunterladen