Menaces invisibles, solutions visibles.

Cascade d'exceptions par opcodes désalignés (MOEW)

PoC de cascade SEH en 3 étapes (bénin, x86/WoW64)

TL;DR : Ce PoC démontre une cascade de gestion structurée des exceptions (SEH) en 3 étapes provoquée par une exécution volontairement désalignée dans des blobs d'octets bruts dont la première instruction valide est un div reg fautif avec un diviseur à zéro.
Chaque étape d'exception installe le gestionnaire SEH suivant, déclenche une nouvelle division par zéro désalignée et exécute une charge utile bénigne observable avant de restaurer la chaîne SEH d'origine et de se terminer proprement.

1. Vue d'ensemble

MOEW (Misaligned Opcode Exception Waterfall) est un échantillon de recherche défensive qui illustre une exécution multi-étapes contrôlée par exceptions sur Windows x86/WoW64. Il démontre :

• Manipulation manuelle de la chaîne SEH via fs:[0]
• Désalignement volontaire dans des séquences d'octets façonnées à la main (blob1, blob2, blob3)
• Gestionnaires SEH enchaînés par étapes
• Récursion multi-fautes via :
  • KiUserExceptionDispatcher
  • RtlDispatchException
  • Gestionnaires personnalisés en mode utilisateur
• Un chemin de terminaison propre qui restaure la chaîne SEH d'origine

Toutes les charges utiles sont bénignes :

• Étape 1 : lance Bloc-notes
• Étape 2 : écrit un fichier marqueur dans %TEMP%
• Étape finale : lance Calculatrice

Le PoC est volontairement désamorcé. Aucune donnée n'est chiffrée, modifiée ou détruite.

2. Fonctionnalités

• Récursion SEH entièrement déterministe à travers 3 gestionnaires en étapes
• Blobs d'octets x86 naked avec plusieurs chemins de décodage valides
• div désaligné à des offsets contrôlés (ECX/EDX/EBX = 0)
• Compteur global par étape pour la journalisation et le traçage
• Restauration complète de la tête SEH d'origine (ORIGINAL_SEH)
• Rust nightly + assembleur inline + fonctions naked
• « Charges utiles » bénignes mais visibles pour la télémétrie et les tests de débogueur

3. Configuration requise

3.1 Architecture

• x86 (32 bits) uniquement
• Compilé avec la chaîne d'outils MSVC
• S'exécute également sur Windows 64 bits sous WoW64

3.2 Rust nightly

Le PoC utilise des fonctionnalités exclusives à nightly :

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

Installez les composants nécessaires :

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

3.3 Désactiver SAFESEH

Étant donné que le PoC installe des gestionnaires SEH personnalisés qui ne sont pas présents dans la table SAFESEH, l'éditeur de liens doit être configuré pour désactiver la validation SAFESEH.

Créez .cargo/config.toml :

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

4. Instructions de compilation

Compilez le binaire :

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

Le résultat se trouve à :

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

5. Exécution du PoC

Exécutez :

seh_waterfall.exe

Flux de contrôle attendu :

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

Artéfacts visibles :

• notepad.exe se lance (étape 1)
• %TEMP%\moew_stage2.txt est créé (étape 2)
• calc.exe se lance (gestionnaire final)

6. Détails techniques

6.1 Structure d'un enregistrement SEH

Sur Windows 32 bits, les enregistrements SEH forment une liste chaînée stockée à fs:[0] :

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

Chaque gestionnaire utilise la signature SEH standard :

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

6.2 État global

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

Utilisé pour :

• Compter la profondeur de récursion des gestionnaires
• Restaurer la tête SEH d'origine à la fin de la cascade

7. Logique des étapes

Étape 0 — Mise en place initiale du cadre

1. Sauvegarder fs:[0] dans ORIGINAL_SEH.
2. Construire un enregistrement SEH pointant vers le gestionnaire de l'étape 1.
3. Remplacer fs:[0] par ce nouvel enregistrement.
4. Exécuter en désalignement dans blob1 + 5, qui se décode comme div ecx (après avoir défini ECX = 0).

Étape 1 — Premier gestionnaire SEH

1. Lancer notepad.exe.
2. Construire un enregistrement SEH pour le gestionnaire de l'étape 2 et l'ajouter en tête de chaîne.
3. Exécuter en désalignement dans blob2 + 3 → div edx (avec EDX = 0).

Étape 2 — Second gestionnaire SEH

1. Écrire %TEMP%\moew_stage2.txt.
2. Installer le gestionnaire final sur la chaîne SEH.
3. Exécuter en désalignement dans blob3 + 3 → div ebx (avec EBX = 0).

Gestionnaire final — Terminaison

1. Lancer calc.exe.
2. Restaurer ORIGINAL_SEH dans fs:[0].
3. Quitter le processus proprement via process::exit(0).

8. Blobs de défauts désalignés

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

• Décodage aligné : mov eax, 0x10; div ecx; ret
• Désaligné à +5 : div ecx (avec 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
    }
}

• Décodage aligné : push ebp; mov ebp, esp; div edx; ret
• Désaligné à +3 : div edx (avec 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
    }
}

• Décodage aligné : push ebx; mov ebx, eax; div ebx; ret
• Désaligné à +3 : div ebx (avec EBX = 0 → #DE)

9. Pipeline d'exceptions

Chaque étape fautive rentre à nouveau dans le pipeline d'exceptions en mode utilisateur de Windows :

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

Vue typique du débogueur :

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

La cascade est entièrement pilotée par de véritables défauts matériels et la distribution SEH ; aucune exception synthétique ou factice n'est utilisée.

10. Contenu du fichier marqueur

Le fichier écrit à l'étape 2 ressemble à :

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

Sa présence dans %TEMP% sert de preuve simple et observable que l'étape 2 s'est exécutée via la chaîne SEH.

11. Notes de sécurité

• Le PoC est bénin et réservé à la recherche défensive.
• Aucune persistance, modification du registre ou chiffrement.
• Toutes les exceptions sont interceptées et gérées.
• La chaîne SEH d'origine est restaurée avant la terminaison.

12. Améliorations futures

Les extensions potentielles incluent :

• Règles YARA et comportementales pour les cascades SEH et les schémas d'exceptions récursifs.
• Cartographie des signaux ETW / EDR pour les défauts matériels par étapes.
• Diagrammes graphiques de l'évolution de la chaîne SEH au fil du temps.
• Comparaison côte à côte avec les chaînes d'exceptions de malwares réels.

13. Code source complet

L'implémentation complète du PoC est disponible dans ce dépôt (voir src/main.rs).

14. Licence

Ce projet est destiné à la recherche défensive et à l'éducation. Copyright <2025>

Permission est accordée, gratuitement, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le « Logiciel »), de traiter le Logiciel sans restriction, y compris sans limitation les droits d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et/ou vendre des copies du Logiciel, et de permettre aux personnes auxquelles le Logiciel est fourni de le faire, sous réserve des conditions suivantes :

L'avis de copyright ci-dessus et cet avis de permission doivent être inclus dans toutes les copies ou parties substantielles du Logiciel.

LE LOGICIEL EST FOURNI « EN L'ÉTAT », SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER LES GARANTIES DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN USAGE PARTICULIER ET D'ABSENCE DE CONTREFAÇON. EN AUCUN CAS LES AUTEURS OU TITULAIRES DU COPYRIGHT NE POURRONT ÊTRE TENUS RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGE OU AUTRE RESPONSABILITÉ, QUE CE SOIT DANS UNE ACTION DE CONTRAT, DÉLIT OU AUTRE, DÉCOULANT DE, OU EN RELATION AVEC LE LOGICIEL OU L'UTILISATION OU D'AUTRES OPÉRATIONS DU LOGICIEL.

15. Échantillon réel vs PoC : corruption SEH, comportement de cascade et impact sur la télémétrie

15.1 Comportement de l'échantillon réel : corruption volontaire de la SEH

L'échantillon MOEW réel qui a inspiré ce PoC ne restaurait pas fs:[0] à la fin de l'exécution.
Au lieu de cela, sa dernière étape :

1. Écrasait la tête SEH (fs:[0]) avec NULL ou un pointeur vers une mémoire invalide.
2. Déclenchait une dernière exception désalignée, garantissant un défaut matériel.
3. Forçait Windows à parcourir une chaîne SEH invalide ou tronquée.
4. Amenait RtlDispatchException à rencontrer un pointeur de gestionnaire invalide.
5. Entraînait un crash où :
   • EIP/RIP pointait vers une mémoire hors image (tas, pile ou région anonyme).
   • Le module fautif ne pouvait pas être résolu et apparaissait comme unknown.
   • Le chemin fautif apparaissait également comme unknown.
6. Produisait des signatures Windows Error Reporting (WER) non attribuables à un module chargé.
7. Journalisait des événements Application Error de l'Observateur d'événements avec des offsets de faute sans signification.
8. Produisait une télémétrie EDR dominée par :
   • des appels répétés à KiUserExceptionDispatcher,
   • des transitions SEH récursives,
   • un crash final anormal sans attribution de module.

Cette étape destructrice de corruption SEH sert l'objectif anti-forensique principal de l'échantillon :
effacer la chaîne causale et produire un crash terminal non attribuable.

15.2 Comportement du PoC : restauration propre de la SEH sans crash terminal

Contrairement à l'échantillon réel, ce PoC :

• Capture la tête SEH d'origine à l'étape 0 :

  root@kitploit:~

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

• Restaure la tête SEH d'origine dans le gestionnaire final :

  root@kitploit:~

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

• Se termine proprement via process::exit(0) au lieu de déclencher une faute non gérée.

Par conséquent, le PoC :

• Ne laisse pas une chaîne SEH corrompue.
• Ne produit pas d'exception finale non gérée.
• Ne génère pas :
  • de rapports de crash WER,
  • d'entrées Application Error 1000 dans l'Observateur d'événements,
  • de signatures « module fautif : inconnu »,
  • de dispositions d'exception invalides,
  • ni d'enregistrements SEH pendants.

Cependant — point crucial — le PoC n'élimine pas le comportement de dégradation de la télémétrie pilotée par exceptions de MOEW.

15.3 Dégradation de télémétrie partagée par l'échantillon réel et le PoC

Le PoC dégrade bel et bien la télémétrie de la même manière fondamentale :

• Il déclenche délibérément plusieurs défauts matériels désalignés.

• Il produit plusieurs exceptions de première chance en succession rapide.

• Il force Windows à exécuter de manière répétée :

  root@kitploit:~

  KiUserExceptionDispatcher
  RtlDispatchException
      → custom handler
      → misaligned blob
      → hardware fault
  

• Il génère des piles d'appels non linéaires, dominées par les exceptions.

• Il fausse la reconstruction du flux de contrôle dans les débogueurs et l'EDR en routant l'exécution à travers :

  • des gestionnaires SEH récursifs,
  • des chemins de décodage désalignés,
  • des adresses non alignées sur les fonctions,
  • des frontières d'instructions partielles.

Ainsi, le PoC reproduit fidèlement :

• le schéma de cascade récursive,
• la machine à états pilotée par exceptions,
• le comportement d'entrée par opcodes désalignés,
• et l'obfuscation du flux de contrôle,

…tout en évitant le crash final destructeur.

Cela rend le PoC idéal pour l'instrumentation et la recherche sans invoquer la charge utile anti-forensique complète.

15.4 Pourquoi le PoC convient à la recherche défensive

Parce que le PoC préserve le comportement global de MOEW moins le crash de corruption SEH, il est :

• Sûr à exécuter de manière répétée dans des environnements de laboratoire.
• Déterministe et stable.
• Adapté pour :
  • l'analyse des pipelines EDR,
  • la recherche sur la télémétrie,
  • la formation à la réponse aux incidents,
  • les tests de comportement des débogueurs,
  • la comparaison côte à côte avec de véritables échantillons malveillants.

Le PoC modélise la cascade d'exceptions (l'essence de MOEW) tout en supprimant la signature destructrice finale.
Il démontre que la dégradation de la télémétrie provient non seulement de la corruption SEH, mais aussi du modèle de flux de contrôle piloté par exceptions lui-même.

15.5 Résumé

Cette section formalise les différences comportementales tout en gardant l'objectif du PoC clair :
démontrer la cascade MOEW sous une forme sûre et adaptée à la recherche, sans le crash final anti-forensique.