Unsichtbare Bedrohungen, sichtbare Lösungen.

Misaligned Opcode Exception Waterfall (MOEW)

3‑stufiger SEH-Waterfall-PoC (harmlos, x86/Wow64)

TL;DR: Dieser PoC demonstriert eine 3‑stufige Kaskade der strukturierten Ausnahmebehandlung (SEH), die durch absichtliche fehlausgerichtete Ausführung in rohe Byte-Blobs verursacht wird, deren erste gültige Anweisung ein auslösendes div reg mit einem Divisor von Null ist.
Jede Ausnahmestufe installiert den nächsten SEH-Handler, löst eine neue fehlausgerichtete Division‑durch‑Null aus und führt eine harmlose, beobachtbare Nutzlast aus, bevor die ursprüngliche SEH-Kette wiederhergestellt und sauber beendet wird.

1. Übersicht

MOEW (Misaligned Opcode Exception Waterfall) ist eine defensive Forschungsprobe, die kontrollierte, ausnahmegetriebene mehrstufige Ausführung auf x86/Wow64-Windows demonstriert. Sie zeigt:

• Manuelle SEH-Kettenmanipulation über fs:[0]
• Absichtliche Fehlausrichtung in handgefertigte Byte-Sequenzen (blob1, blob2, blob3)
• Stufenweise verkettete SEH-Handler
• Mehrfach-Fehlerrekursion über:
  • KiUserExceptionDispatcher
  • RtlDispatchException
  • Benutzerdefinierte Benutzermodus-Handler
• Einen sauberen Beendigungspfad, der die ursprüngliche SEH-Kette wiederherstellt

Alle Nutzlasten sind harmlos:

• Stufe 1: Startet Notepad
• Stufe 2: Schreibt eine Markierungsdatei nach %TEMP%
• Endstufe: Startet den Rechner

Der PoC ist absichtlich entschärft. Es werden keine Daten verschlüsselt, verändert oder zerstört.

2. Features

• Vollständig deterministische SEH-Rekursion durch 3 gestufte Handler
• Nackte x86-Byte-Blobs mit mehreren gültigen Dekodierungspfaden
• Fehlausgerichtetes div an kontrollierten Offsets (ECX/EDX/EBX = 0)
• Pro Stufe ein globaler Zähler für Logging und Tracing
• Vollständige Wiederherstellung des ursprünglichen SEH-Kopfes (ORIGINAL_SEH)
• Rust Nightly + Inline-Assembly + Naked-Funktionen
• Harmlose, aber sichtbare „Nutzlasten” für Telemetrie und Debugger-Tests

3. Umgebungsanforderungen

3.1 Architektur

• Nur x86 (32‑Bit)
• Kompiliert mit der MSVC-Toolchain
• Läuft auch auf 64‑Bit-Windows unter WoW64

3.2 Rust Nightly

Der PoC verwendet nur in Nightly verfügbare Features:

#![feature(asm_experimental_arch)]
#![feature(naked_functions)]

Installieren Sie die erforderlichen Komponenten:

rustup toolchain install nightly
rustup target add i686-pc-windows-msvc --toolchain nightly

3.3 SAFESEH deaktivieren

Da der PoC benutzerdefinierte SEH-Handler installiert, die nicht in der SAFESEH-Tabelle enthalten sind, muss der Linker angewiesen werden, die SAFESEH-Validierung zu deaktivieren.

Erstellen Sie .cargo/config.toml:

[target.i686-pc-windows-msvc]
rustflags = [
  "-C", "link-arg=/SAFESEH:NO",
]

4. Build-Anleitung

Binärdatei bauen:

cargo +nightly build --target i686-pc-windows-msvc --release

Die Ausgabe befindet sich unter:

target\i686-pc-windows-msvc\release\seh_waterfall.exe

5. Ausführen des PoC

Ausführen:

seh_waterfall.exe

Erwarteter Kontrollfluss:

Stage 0 → misaligned blob1 → Stage 1 handler
Stage 1 → misaligned blob2 → Stage 2 handler
Stage 2 → misaligned blob3 → Final handler
Final  → restore SEH       → exit

Sichtbare Artefakte:

• notepad.exe wird gestartet (Stufe 1)
• %TEMP%\moew_stage2.txt wird erstellt (Stufe 2)
• calc.exe wird gestartet (Endstufe)

6. Technische Aufschlüsselung

6.1 SEH-Record-Layout

Unter 32‑Bit-Windows bilden SEH-Records eine verkettete Liste, die unter fs:[0] gespeichert ist:

#[repr(C)]
struct SehRec {
    next: *mut SehRec,
    handler: usize,
}

Jeder Handler verwendet die Standard-SEH-Signatur:

extern "system" fn handler(
    record: *mut u8,
    frame: *mut u8,
    context: *mut u8,
    dispatcher: *mut u8,
) -> i32

6.2 Globaler Zustand

static STAGE_COUNTER: AtomicU32 = AtomicU32::new(0);
static mut ORIGINAL_SEH: *mut SehRec = std::ptr::null_mut();

Wird verwendet, um:

• die Rekursionstiefe des Handlers zu zählen
• den ursprünglichen SEH-Kopf am Ende des Waterfalls wiederherzustellen

7. Stufenlogik

Stufe 0 — Initiale Frameeinrichtung

1. fs:[0] als ORIGINAL_SEH speichern.
2. Einen SEH-Record erstellen, der auf den Stufe‑1-Handler zeigt.
3. fs:[0] mit diesem neuen Record überschreiben.
4. Fehlausrichtung in blob1 + 5, das als div ecx dekodiert (nachdem ECX = 0 gesetzt wurde).

Stufe 1 — Erster SEH-Handler

1. notepad.exe starten.
2. Einen SEH-Record für den Stufe‑2-Handler erstellen und oben in die Kette einhängen.
3. Fehlausrichtung in blob2 + 3 → div edx (mit EDX = 0).

Stufe 2 — Zweiter SEH-Handler

1. %TEMP%\moew_stage2.txt schreiben.
2. Den Endhandler in die SEH-Kette einhängen.
3. Fehlausrichtung in blob3 + 3 → div ebx (mit EBX = 0).

Endhandler — Beendigung

1. calc.exe starten.
2. ORIGINAL_SEH in fs:[0] wiederherstellen.
3. Den Prozess sauber über process::exit(0) beenden.

8. Fehlausgerichtete Fehler-Blobs

8.1 blob1

#[unsafe(naked)]
pub extern "C" fn blob1() {
    naked_asm! {
        ".byte 0xB8, 0x10, 0x00, 0x00, 0x00", // mov eax, 0x10
        ".byte 0xF7, 0xF1",                   // div ecx
        ".byte 0xC3",                         // ret
        ".byte 0x90, 0x90, 0x90",             // nop padding
    }
}

• Ausgerichtete Dekodierung: mov eax, 0x10; div ecx; ret
• Fehlausgerichtet bei +5: div ecx (mit ECX = 0 → #DE)

8.2 blob2

#[unsafe(naked)]
pub extern "C" fn blob2() {
    naked_asm! {
        ".byte 0x55",                         // push ebp
        ".byte 0x8B, 0xEC",                   // mov ebp, esp
        ".byte 0xF7, 0xF2",                   // div edx
        ".byte 0xC3",                         // ret
        ".byte 0x90, 0x90, 0x90",             // nop padding
    }
}

• Ausgerichtete Dekodierung: push ebp; mov ebp, esp; div edx; ret
• Fehlausgerichtet bei +3: div edx (mit EDX = 0 → #DE)

8.3 blob3

#[unsafe(naked)]
pub extern "C" fn blob3() {
    naked_asm! {
        ".byte 0x53",                         // push ebx
        ".byte 0x8B, 0xD8",                   // mov ebx, eax
        ".byte 0xF7, 0xF3",                   // div ebx
        ".byte 0xC3",                         // ret
        ".byte 0x90, 0x90, 0x90",             // nop padding
    }
}

• Ausgerichtete Dekodierung: push ebx; mov ebx, eax; div ebx; ret
• Fehlausgerichtet bei +3: div ebx (mit EBX = 0 → #DE)

9. Ausnahme-Pipeline

Jede ausgelöste Stufe tritt erneut in die Windows-Benutzermodus-Ausnahme-Pipeline ein:

KiUserExceptionDispatcher
    → RtlDispatchException
        → SEH chain walk (fs:[0])
            → MOEW handler

Typische Debugger-Ansicht:

seh_waterfall!blobX+offset
ntdll!KiUserExceptionDispatcher
ntdll!RtlDispatchException
seh_waterfall!stageN_handler

Der Waterfall wird vollständig durch echte Hardwarefehler und SEH-Dispatch angetrieben; es werden keine synthetischen oder gefälschten Ausnahmen verwendet.

10. Ausgabe der Markierungsdatei

Die in Stufe 2 geschriebene Datei sieht folgendermaßen aus:

MOEW Stage 2 Marker
-------------------
This file was written by the Stage 2 SEH handler
as a benign demonstration payload.

Ihre Präsenz in %TEMP% dient als einfacher, beobachtbarer Beweis, dass Stufe 2 über die SEH-Kette ausgeführt wurde.

11. Sicherheitshinweise

• Der PoC ist harmlos und nur für defensive Forschung gedacht.
• Keine Persistenz, keine Registrierungsänderungen, keine Verschlüsselung.
• Alle Ausnahmen werden abgefangen und behandelt.
• Die ursprüngliche SEH-Kette wird vor der Beendigung wiederhergestellt.

12. Zukünftige Erweiterungen

Mögliche Erweiterungen umfassen:

• YARA- und Verhaltensregeln für SEH-Waterfalls und rekursive Ausnahmemuster.
• ETW-/EDR-Signalzuordnung für gestufte Hardwarefehler.
• Grafische Diagramme der SEH-Kettenentwicklung über die Zeit.
• Direkter Vergleich mit realen Schadsoftware-Ausnahmeketten.

13. Vollständiger Quellcode

Die vollständige PoC-Implementierung ist in diesem Repository verfügbar (siehe src/main.rs).

14. Lizenz

Dieses Projekt ist für defensive Forschung und Bildung gedacht. Copyright <2025>

Hiermit wird jeder Person, die eine Kopie dieser Software und der zugehörigen Dokumentationsdateien (die „Software”) erhält, kostenlos die Erlaubnis erteilt, uneingeschränkt mit der Software zu handeln, einschließlich und ohne Einschränkung der Rechte zur Nutzung, zum Kopieren, Ändern, Zusammenführen, Veröffentlichen, Verteilen, Unterlizenzieren und/oder Verkaufen von Kopien der Software, und Personen, denen die Software bereitgestellt wird, dies unter den folgenden Bedingungen zu gestatten:

Der obige Urheberrechtshinweis und dieser Genehmigungshinweis müssen in allen Kopien oder wesentlichen Teilen der Software enthalten sein.

DIE SOFTWARE WIRD „OHNE GEWÄHR” BEREITGESTELLT, OHNE JEGLICHE AUSDRÜCKLICHE ODER IMPLIZITE GEWÄHRLEISTUNG, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT, DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND DER NICHTVERLETZUNG VON RECHTEN DRITTER. IN KEINEM FALL SIND DIE AUTOREN ODER URHEBERRECHTSINHABER FÜR ANSPRÜCHE, SCHÄDEN ODER ANDERE HAFTUNG VERANTWORTLICH, SEI ES AUS VERTRAG, UNERLAUBTER HANDLUNG ODER ANDERWEITIG, DIE AUS ODER IM ZUSAMMENHANG MIT DER SOFTWARE ODER DER NUTZUNG ODER ANDEREN GESCHÄFTEN MIT DER SOFTWARE ENTSTEHEN.

15. Echtes Sample vs. PoC: SEH-Korruption, Waterfall-Verhalten und Telemetrie-Auswirkungen

15.1 Verhalten des echten Samples: Absichtliche SEH-Korruption

Das reale MOEW-Sample, das diesen PoC inspirierte, stellte fs:[0] am Ende der Ausführung nicht wieder her. Stattdessen:

1. Überschrieb der SEH-Kopf (fs:[0]) mit entweder NULL oder einem Zeiger auf ungültigen Speicher.
2. Löste eine letzte fehlausgerichtete Ausnahme aus, wodurch ein Hardwarefehler garantiert wurde.
3. Erzwang, dass Windows die ungültige oder abgeschnittene SEH-Kette durchläuft.
4. Bewirkte, dass RtlDispatchException auf einen ungültigen Handler-Zeiger stößt.
5. Führte zu einem Absturz, bei dem:
   • EIP/RIP in Nicht-Image-Speicher zeigte (Heap, Stack oder anonymer Bereich).
   • Das fehlerverursachende Modul nicht aufgelöst werden konnte und als unknown erschien.
   • Der fehlerverursachende Pfad ebenfalls als unknown erschien.
6. Erzeugte Windows Error Reporting (WER)-Signaturen, die keinem geladenen Modul zuordenbar waren.
7. Protokollierte Application Error-Ereignisse in der Ereignisanzeige mit bedeutungslosen Fehler-Offsets.
8. Erzeugte EDR-Telemetrie, die dominiert wurde von:
   • wiederholten KiUserExceptionDispatcher-Aufrufen,
   • rekursiven SEH-Übergängen,
   • einem finalen anomalen Absturz ohne Modul-Zuordnung.

Dieser destruktive SEH-Korruptionsschritt dient dem primären Zweck der forensischen Gegenmaßnahmen des Samples: die kausale Kette zu löschen und einen nicht zuordenbaren Endabsturz zu erzeugen.

15.2 Verhalten des PoC: Saubere Wiederherstellung von SEH ohne Endabsturz

Anders als das echte Sample:

• Erfasst der PoC den ursprünglichen SEH-Kopf während Stufe 0:

  root@kitploit:~

  asm!("mov {old}, fs:[0]", old = out(reg) old_head);
  ORIGINAL_SEH = old_head;
  

• Stellt der PoC den ursprünglichen SEH-Kopf im Endhandler wieder her:

  root@kitploit:~

  asm!("mov fs:[0], {p}", p = in(reg) ORIGINAL_SEH);
  

• Beendet der PoC sauber über process::exit(0), anstatt einen unbehandelten Fehler auszulösen.

Dadurch:

• Hinterlässt der PoC keine korrupte SEH-Kette.
• Erzeugt der PoC keine finale unbehandelte Ausnahme.
• Erzeugt der PoC keine:
  • WER-Absturzberichte,
  • Application Error 1000-Einträge in der Ereignisanzeige,
  • „faulting module: unknown“-Signaturen,
  • ungültige Ausnahmedispositionen,
  • oder verwaiste SEH-Records.

Entscheidend ist jedoch: Der PoC eliminiert das ausnahmegetriebene Telemetrie-Degradationsverhalten von MOEW nicht.

15.3 Telemetrie-Degradation, die sowohl das echte Sample als auch der PoC teilen

Der PoC degradiert die Telemetrie in der Tat absolut auf dieselbe grundlegende Weise:

• Er löst absichtlich mehrere fehlausgerichtete Hardwarefehler aus.

• Er erzeugt mehrere First-Chance-Exceptions in schneller Folge.

• Er zwingt Windows, wiederholt auszuführen:

  root@kitploit:~

  KiUserExceptionDispatcher
  RtlDispatchException
      → custom handler
      → misaligned blob
      → hardware fault
  

• Er erzeugt nichtlineare, ausnahmedominierte Aufrufstapel.

• Er verzerrt die Kontrollfluss-Rekonstruktion in Debuggern und EDR, indem die Ausführung durch folgendes geleitet wird:

  • rekursive SEH-Handler,
  • fehlausgerichtete Dekodierungspfade,
  • nicht funktionsausgerichtete Adressen,
  • partielle Befehlsgrenzen.

Somit reproduziert der PoC getreu:

• das rekursive Waterfall-Muster,
• die ausnahmegetriebene Zustandsmaschine,
• das Verhalten des fehlausgerichteten Opcode-Einstiegs,
• und die Kontrollfluss-Verschleierung,

…während der destruktive Endabsturz vermieden wird.

Das macht den PoC ideal für Instrumentierung und Forschung, ohne die vollständige Nutzlast der forensischen Gegenmaßnahmen auszulösen.

15.4 Warum der PoC für defensive Forschung geeignet ist

Da der PoC das Gesamtverhalten von MOEW minus des SEH-Korruptionsabsturzes bewahrt, ist er:

• Sicher wiederholt in Laborumgebungen ausführbar.
• Deterministisch und stabil.
• Geeignet für:
  • EDR-Pipeline-Analyse,
  • Telemetrieforschung,
  • Incident-Response-Schulungen,
  • Debugger-Verhaltenstests,
  • den direkten Vergleich mit echten Schadproben.

Der PoC modelliert den Exception-Waterfall (das Wesen von MOEW), während die finale destruktive Signatur entfernt wird. Er zeigt, dass Telemetrie-Degradation nicht nur aus SEH-Korruption entsteht, sondern bereits aus dem ausnahmegetriebenen Kontrollflussmodell selbst.

15.5 Zusammenfassung

Dieser Abschnitt formalisiert die Verhaltensunterschiede, während der Zweck des PoC klar bleibt: den MOEW-Waterfall in einer sicheren, forschungsfreundlichen Form ohne den anti-forensischen Endabsturz zu demonstrieren.