Minacce invisibili, soluzioni visibili.

Cascata di eccezioni da opcode disallineati (MOEW)

PoC di cascata SEH a 3 stadi (benigno, x86/Wow64)

TL;DR: Questo PoC dimostra una cascata di Structured Exception Handling (SEH) a 3 stadi causata da una deliberata esecuzione disallineata in blocchi di byte grezzi la cui prima istruzione valida è una div reg che genera un fault con divisore zero. Ogni stadio di eccezione installa il successivo handler SEH, innesca una nuova divisione per zero disallineata ed esegue un payload osservabile benigno prima di ripristinare la catena SEH originale e terminare in modo pulito.

1. Panoramica

MOEW (Misaligned Opcode Exception Waterfall) è un campione di ricerca difensiva che mostra un'esecuzione controllata multi-stadio guidata da eccezioni su Windows x86/Wow64. Dimostra:

• Manipolazione manuale della catena SEH tramite fs:[0]
• Disallineamento deliberato in sequenze di byte realizzate a mano (blob1, blob2, blob3)
• Handler SEH concatenati a stadi
• Ricorsione multi-fault attraverso:
  • KiUserExceptionDispatcher
  • RtlDispatchException
  • Handler personalizzati in spazio utente
• Un percorso di terminazione pulito che ripristina la catena SEH originale

Tutti i payload sono benigni:

• Stadio 1: Avvia Blocco note
• Stadio 2: Scrive un file marcatore in %TEMP%
• Stadio finale: Avvia Calcolatrice

Il PoC è volutamente reso innocuo. Nessun dato viene crittografato, modificato o distrutto.

2. Caratteristiche

• Ricorsione SEH completamente deterministica attraverso 3 handler a stadi
• Blocchi di byte x86 naked con molteplici percorsi di decodifica validi
• div disallineato a offset controllati (ECX/EDX/EBX = 0)
• Contatore globale per stadio per logging e tracing
• Completo ripristino della testa della catena SEH originale (ORIGINAL_SEH)
• Rust nightly + assembly inline + funzioni naked
• “Payload” benigni ma visibili per telemetria e test con debugger

3. Requisiti di Ambiente

3.1 Architettura

• Solo x86 (32 bit)
• Compilato con il toolchain MSVC
• Funziona anche su Windows 64 bit in WoW64

3.2 Rust Nightly

Il PoC usa funzionalità solo-nightly:

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

Installa i componenti necessari:

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

3.3 Disabilitare SAFESEH

Poiché il PoC installa handler SEH personalizzati che non sono presenti nella tabella SAFESEH, è necessario istruire il linker per disabilitare la validazione SAFESEH.

Crea .cargo/config.toml:

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

4. Istruzioni di Build

Compila il binario:

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

L'output si trova in:

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

5. Esecuzione del PoC

Esegui:

seh_waterfall.exe

Flusso di controllo atteso:

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

Artefatti visibili:

• notepad.exe si avvia (Stadio 1)
• Viene creato %TEMP%\moew_stage2.txt (Stadio 2)
• calc.exe si avvia (handler finale)

6. Analisi Tecnica

6.1 Struttura dei Record SEH

Su Windows a 32 bit, i record SEH formano una lista concatenata memorizzata in fs:[0]:

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

Ogni handler usa la firma SEH standard:

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

6.2 Stato Globale

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

Usato per:

• Contare la profondità di ricorsione degli handler
• Ripristinare la testa SEH originale al termine della cascata

7. Logica degli Stadi

Stadio 0 — Configurazione Iniziale del Frame

1. Salva fs:[0] come ORIGINAL_SEH.
2. Costruisce un record SEH che punta all'handler dello Stadio 1.
3. Sovrascrive fs:[0] con questo nuovo record.
4. Si disallinea in blob1 + 5, che decodifica come div ecx (dopo aver impostato ECX = 0).

Stadio 1 — Primo Handler SEH

1. Avvia notepad.exe.
2. Costruisce un record SEH per l'handler dello Stadio 2 e lo concatena in cima.
3. Si disallinea in blob2 + 3 → div edx (con EDX = 0).

Stadio 2 — Secondo Handler SEH

1. Scrive %TEMP%\moew_stage2.txt.
2. Installa l'handler finale sulla catena SEH.
3. Si disallinea in blob3 + 3 → div ebx (con EBX = 0).

Handler Finale — Terminazione

1. Avvia calc.exe.
2. Ripristina ORIGINAL_SEH in fs:[0].
3. Esce dal processo in modo pulito tramite process::exit(0).

8. Blob di Fault Disallineati

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
    }
}

• Decodifica allineata: mov eax, 0x10; div ecx; ret
• Disallineato a +5: div ecx (con 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
    }
}

• Decodifica allineata: push ebp; mov ebp, esp; div edx; ret
• Disallineato a +3: div edx (con 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
    }
}

• Decodifica allineata: push ebx; mov ebx, eax; div ebx; ret
• Disallineato a +3: div ebx (con EBX = 0 → #DE)

9. Pipeline delle Eccezioni

Ogni stadio in fault rientra nella pipeline delle eccezioni in modalità utente di Windows:

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

Tipica visualizzazione nel debugger:

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

La cascata è interamente guidata da veri fault hardware e dispatch SEH; non vengono usate eccezioni sintetiche o finte.

10. Output del File Marcatore

Il file scritto nello Stadio 2 appare così:

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

La sua presenza in %TEMP% serve come semplice prova osservabile che lo Stadio 2 è stato eseguito tramite la catena SEH.

11. Note di Sicurezza

• Il PoC è benigno e destinato solo alla ricerca difensiva.
• Nessuna persistenza, modifica del registro o crittografia.
• Tutte le eccezioni vengono catturate e gestite.
• La catena SEH originale viene ripristinata prima della terminazione.

12. Sviluppi Futuri

Le estensioni potenziali includono:

• Regole YARA e comportamentali per cascate SEH e pattern di eccezioni ricorsive.
• Mappatura dei segnali ETW / EDR per fault hardware a stadi.
• Diagrammi grafici dell'evoluzione della catena SEH nel tempo.
• Confronto affiancato con catene di eccezioni di malware reali.

13. Codice Sorgente Completo

L'implementazione completa del PoC è disponibile in questo repository (vedi src/main.rs).

14. Licenza

Questo progetto è pensato per ricerca difensiva e formazione. Copyright <2025>

Con la presente viene concessa l'autorizzazione, a titolo gratuito, a chiunque ottenga una copia di questo software e dei relativi file di documentazione (il “Software”), di utilizzare il Software senza alcuna restrizione, inclusi, senza limitazione, i diritti di utilizzare, copiare, modificare, fondere, pubblicare, distribuire, concedere in sublicenza e/o vendere copie del Software, e di permettere alle persone a cui il Software è fornito di fare altrettanto, alle seguenti condizioni:

L'avviso di copyright qui sopra e questo avviso di autorizzazione dovranno essere inclusi in tutte le copie o porzioni sostanziali del Software.

IL SOFTWARE È FORNITO “COSÌ COM'È”, SENZA GARANZIA DI ALCUN TIPO, ESPRESSA O IMPLICITA, INCLUSO MA NON LIMITATO ALLE GARANZIE DI COMMERCIABILITÀ, IDONEITÀ PER UN PARTICOLARE SCOPO E NON VIOLAZIONE. IN NESSUN CASO GLI AUTORI O I TITOLARI DEL COPYRIGHT SARANNO RESPONSABILI PER QUALSIASI RIVENDICAZIONE, DANNO O ALTRA RESPONSABILITÀ, SIA IN UN'AZIONE DI CONTRATTO, ILLECITO O ALTRO, DERIVANTE DA, FUORI O IN CONNESSIONE CON IL SOFTWARE O L'USO O ALTRE OPERAZIONI NEL SOFTWARE.

15. Campione Reale vs. PoC: Corruzione SEH, Comportamento della Cascata e Impatto sulla Telemetria

15.1 Comportamento del Campione Reale: Corruzione Intenzionale della SEH

Il campione MOEW reale che ha ispirato questo PoC non ripristinava fs:[0] al termine dell'esecuzione. Al contrario, il suo stadio finale:

1. Sovrascriveva la testa della catena SEH (fs:[0]) con NULL o con un puntatore a memoria non valida.
2. Innescava un'ultima eccezione disallineata, garantendo un fault hardware.
3. Costringeva Windows a percorrere una catena SEH non valida o troncata.
4. Faceva sì che RtlDispatchException incontrasse un puntatore a handler non valido.
5. Provocava un crash in cui:
   • EIP/RIP puntava a memoria non appartenente a un'immagine (heap, stack o regione anonima).
   • Il modulo in fault non poteva essere risolto e appariva come unknown.
   • Anche il percorso in fault appariva come unknown.
6. Produceva firme Windows Error Reporting (WER) non attribuibili a nessun modulo caricato.
7. Registrava eventi Application Error del Visualizzatore eventi con offset di fault privi di significato.
8. Produceva una telemetria EDR dominata da:
   • chiamate ripetute a KiUserExceptionDispatcher,
   • transizioni SEH ricorsive,
   • un crash terminale anomalo privo di attribuzione al modulo.

Questo passaggio di corruzione SEH distruttiva serve allo scopo anti-forense principale del campione: cancellare la catena causale e produrre un crash terminale non attribuibile.

15.2 Comportamento del PoC: Ripristino Pulito della SEH Senza Crash Terminale

A differenza del campione reale, questo PoC:

• Cattura la testa SEH originale durante lo Stadio 0:

  root@kitploit:~

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

• Ripristina la testa SEH originale nell'handler finale:

  root@kitploit:~

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

• Termina in modo pulito tramite process::exit(0) invece di innescare un fault non gestito.

Di conseguenza, il PoC:

• Non lascia una catena SEH corrotta.
• Non produce un'eccezione finale non gestita.
• Non genera:
  • report di crash WER,
  • voci Application Error 1000 nel Visualizzatore eventi,
  • firme “faulting module: unknown”,
  • disposition di eccezione non valide,
  • o record SEH pendenti.

Tuttavia—in modo critico—il PoC non elimina il comportamento di degradazione della telemetria guidata dalle eccezioni di MOEW.

15.3 Degradazione della Telemetria Condivisa sia dal Campione Reale che dal PoC

Il PoC degrada davvero la telemetria nello stesso modo fondamentale:

• Innesca deliberatamente molteplici fault hardware disallineati.

• Produce molteplici eccezioni first-chance in rapida successione.

• Costringe Windows a eseguire ripetutamente:

  root@kitploit:~

  KiUserExceptionDispatcher
  RtlDispatchException
      → custom handler
      → misaligned blob
      → hardware fault
  

• Genera call stack non lineari e dominate dalle eccezioni.

• Distorce la ricostruzione del flusso di controllo in debugger e EDR instradando l'esecuzione attraverso:

  • handler SEH ricorsivi,
  • percorsi di decodifica disallineati,
  • indirizzi non allineati alle funzioni,
  • confini di istruzioni parziali.

Pertanto il PoC riproduce fedelmente:

• il pattern a cascata ricorsiva,
• la macchina a stati guidata dalle eccezioni,
• il comportamento di ingresso tramite opcode disallineati,
• e l'offuscamento del flusso di controllo,

…evitando però il crash finale distruttivo.

Questo rende il PoC ideale per strumentazione e ricerca senza invocare l'intero payload anti-forense.

15.4 Perché il PoC è Adatto alla Ricerca Difensiva

Poiché il PoC preserva il comportamento complessivo di MOEW meno il crash da corruzione SEH, è:

• Sicuro da eseguire ripetutamente in ambienti di laboratorio.
• Deterministico e stabile.
• Adatto a:
  • analisi di pipeline EDR,
  • ricerca sulla telemetria,
  • formazione per incident response,
  • test del comportamento dei debugger,
  • confronto affiancato con campioni malevoli reali.

Il PoC modella la cascata di eccezioni (l'essenza di MOEW) rimuovendo al contempo la firma distruttiva finale. Dimostra che la degradazione della telemetria deriva non solo dalla corruzione SEH, ma dal modello stesso di flusso di controllo guidato dalle eccezioni.

15.5 Riepilogo

Questa sezione formalizza le differenze comportamentali mantenendo chiaro lo scopo del PoC: dimostrare la cascata MOEW in una forma sicura e adatta alla ricerca, senza il crash finale anti-forense.