Amenazas Invisibles, Soluciones Visibles.

Cascada de Excepciones por Opcode Desalineado (MOEW)

PoC de Cascada SEH de 3 Etapas (Benigno, x86/Wow64)

TL;DR: Este PoC demuestra una cascada de Manejo Estructurado de Excepciones (SEH) de 3 etapas causada por ejecución desalineada deliberada dentro de blobs de bytes crudos cuya primera instrucción válida es un div reg que provoca una falta con divisor cero. Cada etapa de excepción instala el siguiente manejador SEH, provoca una nueva división por cero desalineada y ejecuta una carga útil benigna observable antes de restaurar la cadena SEH original y terminar limpiamente.

1. Descripción General

MOEW (Cascada de Excepciones por Opcode Desalineado, por sus siglas en inglés Misaligned Opcode Exception Waterfall) es una muestra de investigación defensiva que demuestra ejecución multietapa controlada y dirigida por excepciones en Windows x86/Wow64. Demuestra:

• Manipulación manual de la cadena SEH a través de fs:[0]
• Desalineación deliberada hacia secuencias de bytes artesanales (blob1, blob2, blob3)
• Manejadores SEH encadenados por etapas
• Recursión multifallo a través de:
  • KiUserExceptionDispatcher
  • RtlDispatchException
  • Manejadores personalizados en modo usuario
• Una ruta de terminación limpia que restaura la cadena SEH original

Todas las cargas útiles son benignas:

• Etapa 1: Abre el Bloc de Notas
• Etapa 2: Escribe un archivo marcador en %TEMP%
• Etapa Final: Abre la Calculadora

El PoC está intencionalmente desactivado. No se cifra, modifica ni destruye ningún dato.

2. Características

• Recursión SEH totalmente determinista a través de 3 manejadores por etapas
• Blobs de bytes x86 naked con múltiples rutas de decodificación válidas
• div desalineado en offsets controlados (ECX/EDX/EBX = 0)
• Contador global por etapa para registro y trazado
• Restauración completa de la cabecera SEH original (ORIGINAL_SEH)
• Rust nightly + ensamblador en línea + funciones naked
• Cargas útiles («payloads») benignas pero visibles para telemetría y pruebas con depuradores

3. Requisitos del Entorno

3.1 Arquitectura

• Solo x86 (32 bits)
• Compilado con el toolchain de MSVC
• También se ejecuta en Windows de 64 bits bajo WoW64

3.2 Rust Nightly

El PoC utiliza características exclusivas de nightly:

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

Instala los componentes necesarios:

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

3.3 Deshabilitar SAFESEH

Dado que el PoC instala manejadores SEH personalizados que no están presentes en la tabla SAFESEH, es necesario indicar al enlazador que deshabilite la validación SAFESEH.

Crea .cargo/config.toml:

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

4. Instrucciones de Compilación

Compila el binario:

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

La salida se encuentra en:

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

5. Ejecución del PoC

Ejecuta:

seh_waterfall.exe

Flujo de control esperado:

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

Artefactos visibles:

• Se lanza notepad.exe (Etapa 1)
• Se crea %TEMP%\moew_stage2.txt (Etapa 2)
• Se lanza calc.exe (manejador final)

6. Desglose Técnico

6.1 Estructura del Registro SEH

En Windows de 32 bits, los registros SEH forman una lista enlazada almacenada en fs:[0]:

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

Cada manejador utiliza la firma SEH estándar:

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

6.2 Estado Global

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

Se utiliza para:

• Contar la profundidad de recursión del manejador
• Restaurar la cabecera SEH original al final de la cascada

7. Lógica de Etapas

Etapa 0 — Configuración Inicial del Marco

1. Guarda fs:[0] como ORIGINAL_SEH.
2. Construye un registro SEH que apunte al manejador de la Etapa 1.
3. Sobrescribe fs:[0] con este nuevo registro.
4. Desalinea hacia blob1 + 5, que se decodifica como div ecx (después de establecer ECX = 0).

Etapa 1 — Primer Manejador SEH

1. Lanza notepad.exe.
2. Construye un registro SEH para el manejador de la Etapa 2 y lo encadena encima.
3. Desalinea hacia blob2 + 3 → div edx (con EDX = 0).

Etapa 2 — Segundo Manejador SEH

1. Escribe %TEMP%\moew_stage2.txt.
2. Instala el manejador final en la cadena SEH.
3. Desalinea hacia blob3 + 3 → div ebx (con EBX = 0).

Manejador Final — Terminación

1. Lanza calc.exe.
2. Restaura ORIGINAL_SEH en fs:[0].
3. Sale del proceso limpiamente mediante process::exit(0).

8. Blobs de Fallo Desalineados

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

• Decodificación alineada: mov eax, 0x10; div ecx; ret
• Desalineado en +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
    }
}

• Decodificación alineada: push ebp; mov ebp, esp; div edx; ret
• Desalineado en +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
    }
}

• Decodificación alineada: push ebx; mov ebx, eax; div ebx; ret
• Desalineado en +3: div ebx (con EBX = 0 → #DE)

9. Canalización de Excepciones

Cada etapa con fallo vuelve a entrar en la canalización de excepciones en modo usuario de Windows:

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

Vista típica en el depurador:

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

La cascada está impulsada por completo por fallos de hardware reales y despacho de SEH; no se utilizan excepciones sintéticas ni falsas.

10. Salida del Archivo Marcador

El archivo escrito en la Etapa 2 tiene este aspecto:

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

Su presencia en %TEMP% sirve como prueba simple y observable de que la Etapa 2 se ejecutó a través de la cadena SEH.

11. Notas de Seguridad

• El PoC es benigno y exclusivamente para investigación defensiva.
• Sin persistencia, modificación del registro ni cifrado.
• Todas las excepciones se capturan y manejan.
• La cadena SEH original se restaura antes de la terminación.

12. Mejoras Futuras

Las posibles extensiones incluyen:

• Reglas YARA y de comportamiento para cascadas SEH y patrones de excepciones recursivas.
• Mapeo de señales ETW / EDR para fallos de hardware por etapas.
• Diagramas gráficos de la evolución de la cadena SEH a lo largo del tiempo.
• Comparación lado a lado con cadenas de excepciones de malware del mundo real.

13. Código Fuente Completo

La implementación completa del PoC está disponible en este repositorio (consulta src/main.rs).

14. Licencia

Este proyecto está destinado a la investigación defensiva y la educación. Copyright <2025>

Por la presente se concede permiso, de forma gratuita, a cualquier persona que obtenga una copia de este software y de los archivos de documentación asociados (el «Software»), para tratar el Software sin restricción, incluidos, sin limitación, los derechos de usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y/o vender copias del Software, y de permitir a las personas a quienes se les proporcione el Software hacer lo mismo, sujeto a las siguientes condiciones:

El aviso de copyright anterior y este aviso de permiso deberán incluirse en todas las copias o partes sustanciales del Software.

EL SOFTWARE SE PROPORCIONA «TAL CUAL», SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O IMPLÍCITA, INCLUIDAS, ENTRE OTRAS, LAS GARANTÍAS DE COMERCIABILIDAD, IDONEIDAD PARA UN FIN PARTICULAR Y NO INFRACCIÓN. EN NINGÚN CASO LOS AUTORES O TITULARES DEL COPYRIGHT SERÁN RESPONSABLES DE CUALQUIER RECLAMO, DAÑO U OTRA RESPONSABILIDAD, YA SEA EN UNA ACCIÓN CONTRACTUAL, EXTRACONTRACTUAL O DE OTRO TIPO, QUE SURJA DE, O EN RELACIÓN CON, EL SOFTWARE O EL USO U OTROS TRATOS EN EL SOFTWARE.

15. Muestra Real vs. PoC: Corrupción del SEH, Comportamiento de la Cascada e Impacto en la Telemetría

15.1 Comportamiento de la Muestra Real: Corrupción Intencional del SEH

La muestra real de MOEW que inspiró este PoC no restauraba fs:[0] al final de la ejecución. En su lugar, su etapa final:

1. Sobrescribía la cabecera SEH (fs:[0]) con NULL o un puntero a memoria no válida.
2. Provocaba una última excepción desalineada, garantizando un fallo de hardware.
3. Obligaba a Windows a recorrer una cadena SEH no válida o truncada.
4. Hacía que RtlDispatchException encontrara un puntero de manejador no válido.
5. Daba lugar a un bloqueo en el que:
   • EIP/RIP apuntaba a memoria fuera de la imagen (heap, pila o región anónima).
   • El módulo con el fallo no se podía resolver y aparecía como unknown.
   • La ruta del fallo también aparecía como unknown.
6. Producía firmas de Windows Error Reporting (WER) que no eran atribuibles a ningún módulo cargado.
7. Registraba eventos Application Error en el Visor de eventos con offsets de fallo sin significado.
8. Producía telemetría EDR dominada por:
   • llamadas repetidas a KiUserExceptionDispatcher,
   • transiciones recursivas de SEH,
   • un bloqueo anómalo final sin atribución de módulo.

Este paso destructivo de corrupción del SEH cumple el propósito antiforense principal de la muestra: borrar la cadena causal y producir un bloqueo terminal no atribuible.

15.2 Comportamiento del PoC: Restauración Limpia del SEH Sin Bloqueo Terminal

A diferencia de la muestra real, este PoC:

• Captura la cabecera SEH original durante la Etapa 0:

  root@kitploit:~

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

• Restaura la cabecera SEH original en el manejador final:

  root@kitploit:~

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

• Termina limpiamente mediante process::exit(0) en lugar de provocar un fallo no manejado.

Como resultado, el PoC:

• No deja una cadena SEH corrupta.
• No produce una excepción final no manejada.
• No genera:
  • informes de bloqueo de WER,
  • entradas Application Error 1000 en el Visor de eventos,
  • firmas de «faulting module: unknown»,
  • disposiciones de excepción no válidas,
  • ni registros SEH colgantes.

Sin embargo—y esto es crucial—el PoC no elimina el comportamiento de degradación de telemetría impulsada por excepciones de MOEW.

15.3 Degradación de la Telemetría Compartida por la Muestra Real y el PoC

El PoC definitivamente sí degrada la telemetría de la misma manera fundamental:

• Provoca deliberadamente múltiples fallos de hardware desalineados.

• Produce múltiples excepciones de primera oportunidad en rápida sucesión.

• Obliga a Windows a ejecutar repetidamente:

  root@kitploit:~

  KiUserExceptionDispatcher
  RtlDispatchException
      → custom handler
      → misaligned blob
      → hardware fault
  

• Genera pilas de llamadas no lineales y dominadas por excepciones.

• Distorsiona la reconstrucción del flujo de control en depuradores y EDR al enrutar la ejecución a través de:

  • manejadores SEH recursivos,
  • rutas de decodificación desalineadas,
  • direcciones no alineadas con funciones,
  • límites de instrucciones parciales.

Por lo tanto, el PoC reproduce fielmente:

• el patrón de cascada recursivo,
• la máquina de estados impulsada por excepciones,
• el comportamiento de entrada de opcodes desalineados,
• y la ofuscación del flujo de control,

…mientras se evita el bloqueo final destructivo.

Esto hace que el PoC sea ideal para instrumentación e investigación sin invocar la carga útil antiforense completa.

15.4 Por Qué el PoC Es Adecuado para la Investigación Defensiva

Debido a que el PoC conserva el comportamiento general de MOEW menos el bloqueo por corrupción del SEH, es:

• Seguro de ejecutar repetidamente en entornos de laboratorio.
• Determinista y estable.
• Adecuado para:
  • análisis de canalizaciones EDR,
  • investigación de telemetría,
  • formación en respuesta a incidentes,
  • pruebas de comportamiento de depuradores,
  • comparación lado a lado con muestras maliciosas reales.

El PoC modela la cascada de excepciones (la esencia de MOEW) a la vez que elimina la firma destructiva final. Demuestra que la degradación de la telemetría surge no solo de la corrupción del SEH, sino del propio modelo de flujo de control impulsado por excepciones.

15.5 Resumen

Esta sección formaliza las diferencias de comportamiento manteniendo claro el propósito del PoC: demostrar la cascada de MOEW de forma segura y apta para la investigación, sin el bloqueo final antiforense.