Saltar a contenido

Next-Gen Reverse Engineering Training

Módulo 6: Kernel Exploitation - Real Microsoft Patches

Objetivo del módulo: aprender un flujo práctico para estudiar un parche real de Microsoft, construir una VM vulnerable y una VM parcheada, extraer los binarios modificados desde paquetes .msu/.cab/.psf, ubicar el driver relevante y preparar el material para hacer patch diffing de forma ordenada.

Tabla de Contenidos

  1. Caso de estudio: CVE-2024-38144
  2. Idea general del workflow
  3. Conseguir la ISO vulnerable
  4. Instalación vulnerable sin red
  5. Validar build y crear snapshot-0
  6. Descargar e instalar el parche objetivo
  7. Troubleshooting de instalación de parches
  8. Instalar el parche mensual anterior
  9. Encontrar los archivos modificados
  10. Extraer el parche .msu
  11. Trabajar con .cab, .psf y express.psf.cix.xml
  12. Ubicar ksthunk.sys
  13. Preparar binarios para patch diffing
  14. Metodología de análisis del diff
  15. Notas sobre endianess
  16. Checklist del laboratorio
  17. Glosario

Clase 1 apuntes

1. Caso de estudio: CVE-2024-38144

El módulo toma como primer caso real un parche de Microsoft:

  • CVE: CVE-2024-38144
  • Nombre: Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability
  • Componente: ksthunk.sys
  • Tipo: Elevation of Privilege local
  • Weakness: CWE-190: Integer Overflow or Wraparound
  • Fecha de publicación: 13 de agosto de 2024
  • Parche objetivo del ejemplo: KB5041585

La idea no es empezar escribiendo un exploit, sino entender qué archivo cambió, qué función cambió, qué validación agregó Microsoft y qué bug queda implícito al comparar vulnerable vs patched.

¿Por qué estudiar parches reales?

Los parches de Microsoft suelen agrupar muchas vulnerabilidades en un mismo paquete mensual. Eso obliga a trabajar con disciplina:

  • Identificar el KB correcto.
  • Conseguir una build vulnerable cercana.
  • Extraer o recuperar el archivo vulnerable y el parcheado.
  • Compararlos con herramientas como IDA Pro, BinDiff, Diaphora o bindiffing manual.
  • Confirmar que el cambio corresponde al CVE estudiado y no a otro fix del mismo mes.

2. Idea general del workflow

El flujo del módulo es:

  1. Buscar el CVE en MSRC.
  2. Identificar el KB que contiene el parche.
  3. Instalar una VM Windows vulnerable, preferentemente una build inmediatamente anterior.
  4. Deshabilitar updates para congelar el estado.
  5. Crear snapshot-0 de la VM vulnerable.
  6. Instalar el parche objetivo y crear snapshot-1.
  7. Ubicar el archivo parcheado.
  8. Restaurar snapshot-0 e instalar el parche mensual anterior si hace falta ajustar la baseline.
  9. Obtener el archivo vulnerable equivalente.
  10. Comparar ambas versiones del binario.
snapshot-0                         snapshot-1
VM vulnerable       + KB objetivo   VM parcheada
-------------       ------------>   ------------
ksthunk.sys old                    ksthunk.sys new
       \                              /
        \                            /
         \                          /
          +------ patch diff -------+

3. Conseguir la ISO vulnerable

Para estudiar un parche, la build de Windows debe ser:

  • Vulnerable.
  • Compatible con el KB que se quiere instalar.
  • Lo suficientemente cercana al parche objetivo para evitar problemas de prerequisitos.

Opciones comunes:

  • Descargar la ISO desde una suscripción de Microsoft si se tiene acceso.
  • Usar una ISO pública de Windows y llevarla hasta una build previa con updates offline.
  • Buscar una build inmediatamente anterior al parche que se quiere estudiar.

En las slides se usa como ejemplo Windows 11 23H2 con build:

Version 23H2 (OS Build 22631.3593)

Esa build aparece asociada al acumulativo de mayo de 2024:

KB5037771

La regla práctica es: la build vulnerable debe estar antes de la actualización que corrige el CVE.

4. Instalación vulnerable sin red

La instalación debe hacerse sin conexión a internet para evitar que Windows Update corrija la vulnerabilidad automáticamente.

Modo de red recomendado

  • Usar una red host-only o aislada.
  • Evitar NAT/bridged durante la instalación.
  • No iniciar sesión con una cuenta Microsoft si eso fuerza conectividad.

Bypass de requisito de red en Windows 11

En la pantalla Let's connect you to a network:

  1. Presionar Shift + F10.
  2. Ejecutar:
OOBE\BYPASSNRO
  1. La VM reinicia.
  2. Elegir la opción equivalente a I don't have internet.
  3. Crear una cuenta local.

Deshabilitar actualizaciones

El material usa Wu10Man para deshabilitar servicios de update:

La razón es simple: si Windows se actualiza solo, se pierde la build vulnerable y el laboratorio deja de ser reproducible.

5. Validar build y crear snapshot-0

Antes de tocar parches:

  1. Ejecutar winver.
  2. Confirmar edición, versión y build.
  3. Documentar el estado exacto.
  4. Crear un snapshot de la VM.

Nombre sugerido por el módulo:

snapshot-0

Ejemplo visto en las slides:

Windows 11 23H2
OS Build 22631.3593

Qué conviene anotar

Dato Ejemplo
Windows version Windows 11 23H2
Build 22631.3593
KB base KB5037771
Arquitectura x64
Red host-only / sin internet
Updates deshabilitados
Snapshot snapshot-0

6. Descargar e instalar el parche objetivo

El parche objetivo del ejemplo es:

KB5041585

En el Microsoft Update Catalog se busca el KB y se descarga el paquete que corresponda a la arquitectura y versión del sistema.

Para Windows 11 x64, las slides muestran entradas como:

2024-08 Cumulative Update for Windows 11 Version 23H2 for x64-based Systems (KB5041585)

Instalación controlada

  1. Mantener la VM sin internet.
  2. Habilitar temporalmente servicios de update desde Wu10Man si el instalador lo requiere.
  3. Ejecutar el .msu.
  4. Reiniciar.
  5. Volver a deshabilitar updates.
  6. Confirmar build con winver.
  7. Crear un snapshot de la VM parcheada.

Nombre sugerido:

snapshot-1

Este snapshot sirve para recuperar el archivo parcheado más adelante sin repetir toda la instalación.

7. Troubleshooting de instalación de parches

Un error común es que el instalador diga que el parche no aplica a esa computadora. Suele pasar cuando la ISO es demasiado vieja o cuando falta un prerequisito.

Causas comunes

Problema Causa probable Acción
El .msu no aplica ISO demasiado vieja Usar una ISO más cercana al mes del parche
Error por prerequisito Falta Servicing Stack Update Instalar el SSU requerido
Build equivocada KB de otra rama/version Revisar versión, arquitectura y canal
El sistema se actualizó solo Updates activos Restaurar snapshot y aislar red

Regla práctica

Mientras más cerca esté la ISO vulnerable del parche objetivo, menos conflictos aparecen. Idealmente se trabaja con la build inmediatamente anterior o con el acumulativo mensual anterior.

8. Instalar el parche mensual anterior

Para construir una imagen vulnerable más precisa, el módulo propone instalar el parche mensual anterior al objetivo.

En el ejemplo:

  • Parche objetivo: KB5041585 - agosto de 2024
  • Parche anterior: KB5040442 - julio de 2024

Flujo:

  1. Restaurar snapshot-0.
  2. Instalar KB5040442.
  3. Reiniciar.
  4. Deshabilitar updates.
  5. Confirmar build.
  6. Crear un snapshot adicional si se quiere preservar esta baseline.

Esto ayuda a que el diff entre vulnerable y patched sea más chico y relevante.

9. Encontrar los archivos modificados

Esta es la parte difícil del proceso. Un parche mensual contiene cambios para muchas vulnerabilidades y componentes, no solo para el CVE que se está estudiando.

Para CVE-2024-38144, las slides muestran que el archivo interesante es:

ksthunk.sys

ksthunk.sys corresponde al Kernel Streaming WOW Thunk Service Driver. El nombre ayuda a buscar dentro del paquete usando términos como:

thunk
ksthunk
Kernel Streaming WOW Thunk

Fuentes para ubicar el archivo

  • MSRC, para confirmar CVE, KB y componente.
  • Microsoft Update Catalog, para descargar el .msu.
  • Archivos instalados dentro de snapshot-0 y snapshot-1.
  • express.psf.cix.xml, para buscar nombres dentro del paquete.
  • Winbindex, para encontrar versiones históricas de binarios de Windows.

URL útil:

https://winbindex.m417z.com/

10. Extraer el parche .msu

El material renombra el parche descargado como:

update.msu

Luego lo copia a una carpeta de trabajo, por ejemplo:

C:\Users\Ricardo\Desktop\trabajo

Extraer el MSU

expand -F:* update.msu C:\Users\Ricardo\Desktop\trabajo

Si aparecen solo CABs y no PSF

expand -F:* *.cab C:\Users\Ricardo\Desktop\trabajo

El resultado puede incluir archivos como:

wsusscan.cab
onepackage.AggregatedMetadata.cab
LCUCompDB_KB5041585.xml.cab
Windows11.0-KB5041585-x64.cab
Windows11.0-KB5041585-x64.psf

11. Trabajar con .cab, .psf y express.psf.cix.xml

Microsoft usa distintos formatos para distribuir actualizaciones. En patches modernos es común encontrar:

  • .msu: contenedor de update.
  • .cab: cabinet con metadatos o payloads.
  • .psf: Patch Storage File, suele contener deltas.
  • express.psf.cix.xml: índice XML con referencias a archivos dentro del delta.

Cuando hay CAB + PSF

Si el paquete trae una combinación como:

Windows11.0-KB5041585-x64.cab
Windows11.0-KB5041585-x64.psf

el módulo recomienda usar PSFExtractor:

https://github.com/Secant1006/PSFExtractor/releases

Ejemplo de uso visto en la slide:

PSFExtractor.exe Windows11.0-KB5041585-x64.cab

Buscar en express.psf.cix.xml

Abrir el XML con Notepad++ o un editor que soporte archivos grandes y buscar:

thunk

Esto permite descubrir entradas relacionadas con ksthunk.sys.

Punto importante: el .psf puede contener deltas, no necesariamente el archivo completo. El XML sirve para identificar nombres y rutas, pero no siempre alcanza para obtener un binario final directamente usable. Una vez conocido el nombre, se puede:

  • Recuperar el archivo desde la VM vulnerable.
  • Recuperar el archivo desde la VM parcheada.
  • Descargar una versión específica desde Winbindex si está disponible.
  • Reconstruir el archivo desde el delta si se domina ese flujo, aunque el módulo no usa ese método.

12. Ubicar ksthunk.sys

Con el nombre del driver identificado, el siguiente paso es obtener dos versiones comparables:

ksthunk.sys vulnerable
ksthunk.sys patched

Desde snapshots

  1. Iniciar snapshot-0 o la baseline vulnerable.
  2. Copiar ksthunk.sys a una carpeta de análisis.
  3. Iniciar snapshot-1.
  4. Copiar la versión parcheada.
  5. Renombrar los archivos para evitar confusión.

Ejemplo:

ksthunk_22631_3593_vuln.sys
ksthunk_KB5041585_patched.sys

Rutas probables

Los drivers del sistema suelen estar bajo:

C:\Windows\System32\drivers\

Verificar metadata

En Windows se puede revisar:

  • Propiedades del archivo.
  • Firma digital.
  • Fecha de modificación.
  • File version.
  • Product version.

También sirve guardar hashes:

Get-FileHash .\ksthunk_22631_3593_vuln.sys -Algorithm SHA256
Get-FileHash .\ksthunk_KB5041585_patched.sys -Algorithm SHA256

13. Preparar binarios para patch diffing

Antes de abrir IDA/BinDiff, ordenar el material evita errores.

Estructura de carpeta recomendada

case-CVE-2024-38144\
  00-info\
    notes.md
    msrc.txt
  01-packages\
    KB5041585.msu
    KB5040442.msu
  02-binaries\
    vulnerable\
      ksthunk.sys
    patched\
      ksthunk.sys
  03-ida\
    vulnerable\
    patched\
  04-diff\

Checklist previo al diff

  • Confirmar que ambos archivos son del mismo componente.
  • Confirmar arquitectura.
  • Confirmar firma y metadata.
  • Confirmar hashes.
  • Confirmar que la versión parcheada viene del KB objetivo.
  • Confirmar que la vulnerable es anterior al KB objetivo.

Flujo con IDA y BinDiff

  1. Abrir ksthunk.sys parcheado en IDA.
  2. Esperar a que termine el análisis.
  3. Guardar la base .i64.
  4. Abrir ksthunk.sys vulnerable.
  5. Esperar análisis y guardar .i64.
  6. Ejecutar BinDiff entre ambas bases.
  7. Ordenar por funciones con similitud menor a 1.0.
  8. Revisar primero funciones pequeñas con cambios de control flow o validaciones nuevas.

14. Metodología de análisis del diff

El diff por sí solo no explica la vulnerabilidad. Solo muestra diferencias. El trabajo del reverser es interpretar esas diferencias.

Qué buscar en un patch de integer overflow

Como el CVE está asociado a CWE-190, conviene prestar atención a patrones como:

  • Nuevas comparaciones antes de una suma, multiplicación o conversión.
  • Checks de tamaño contra límites máximos.
  • Uso nuevo de helpers seguros de arithmetic.
  • Cambios de tipos signed/unsigned.
  • Condiciones nuevas antes de reservar memoria.
  • Validaciones antes de copiar buffers.
  • Caminos de error nuevos que devuelven STATUS_INVALID_PARAMETER o similar.

Ejemplo conceptual:

// Antes: cálculo directo
size = count * entry_size;

// Después: validación previa o helper seguro
if (count > MAX / entry_size) {
    return STATUS_INVALID_PARAMETER;
}
size = count * entry_size;

Este ejemplo no describe el patch real, solo el patrón típico que se busca al investigar una corrección de integer overflow/wraparound.

Preguntas guía

Pregunta Por qué importa
¿Qué función cambió? Acota la superficie real del fix
¿Qué entrada controla usuario? Permite conectar bug con superficie de ataque
¿Qué validación se agregó? Suele revelar la condición vulnerable
¿Hay cambios en tamaños o casts? Indicio fuerte en bugs CWE-190
¿El cambio afecta IOCTLs? En drivers, suele ser la ruta user-kernel
¿Qué error retorna el código nuevo? Ayuda a reconstruir el contrato esperado

Confirmar que el cambio corresponde al CVE

No alcanza con encontrar una función distinta. Un acumulativo mensual puede cambiar muchas funciones por motivos no relacionados.

Señales de buena atribución:

  • El nombre/ruta del archivo coincide con el componente del CVE.
  • La fecha y versión corresponden al KB correcto.
  • El cambio introduce validaciones coherentes con CWE-190.
  • La función modificada es alcanzable desde la superficie esperada.
  • No hay otra vulnerabilidad del mismo mes que explique mejor el cambio.

15. Notas sobre endianess

La última slide deja un recordatorio de endianess:

0x434f5245 (int, big endian)
0x45524f43 (int, little endian)

Los bytes ASCII:

43 4f 52 45 = C O R E

En little endian, un entero se almacena con el byte menos significativo primero. Por eso, si se quiere ver el texto CORE en memoria, el entero puede aparecer representado como:

0x45524f43

Esto es importante en reversing de Windows porque muchos valores de 4 bytes, como tags de pool o constantes mágicas, se ven invertidos según si se miran como bytes, string o entero.

Regla práctica

Vista Valor
Bytes en memoria 43 4f 52 45
ASCII CORE
Entero big endian 0x434f5245
Entero little endian 0x45524f43

16. Checklist del laboratorio

VM vulnerable

  • ISO correcta.
  • Sin conexión a internet.
  • Windows instalado con cuenta local.
  • Updates deshabilitados.
  • Build confirmada con winver.
  • snapshot-0 creado.

VM parcheada

  • KB objetivo descargado.
  • Arquitectura correcta.
  • Prerequisitos revisados.
  • KB instalado offline.
  • Reinicio completo.
  • Updates deshabilitados nuevamente.
  • snapshot-1 creado.

Extracción

  • .msu preservado.
  • .cab extraídos.
  • .psf procesado si aplica.
  • express.psf.cix.xml revisado.
  • ksthunk.sys identificado.

Patch diffing

  • Binario vulnerable guardado.
  • Binario parcheado guardado.
  • Hashes calculados.
  • Metadata documentada.
  • Bases IDA guardadas.
  • Diff generado.
  • Cambios atribuibles al CVE documentados.

17. Glosario

Término Descripción
MSRC Microsoft Security Response Center. Publica CVEs, severidad, productos afectados y KBs relacionados.
CVE Identificador público de una vulnerabilidad.
CWE Clasificación del tipo de debilidad. CWE-190 corresponde a integer overflow/wraparound.
KB Knowledge Base. Identificador de actualización de Microsoft, por ejemplo KB5041585.
MSU Microsoft Update Standalone Package. Contenedor instalable de updates.
CAB Cabinet file. Formato de archivo comprimido usado por Windows.
PSF Patch Storage File. Formato usado para transportar deltas de actualización.
SSU Servicing Stack Update. Actualización del componente que instala updates. Puede ser prerequisito.
LCU Latest Cumulative Update. Paquete acumulativo mensual.
Snapshot Estado guardado de una VM para volver a una build exacta.
Winbindex Servicio para buscar y descargar binarios históricos de Windows desde fuentes de Microsoft.
Patch diffing Comparación de binarios vulnerable/parcheado para inferir qué bug se corrigió.
BinDiff Herramienta de Google para comparar bases de datos de IDA.
ksthunk.sys Driver del Kernel Streaming WOW Thunk Service, componente del caso CVE-2024-38144.
WOW / WOW64 Capa de compatibilidad para ejecutar software de 32 bits en Windows de 64 bits.
Endianess Orden en que una arquitectura almacena bytes de valores multibyte. Windows x86/x64 usa little endian.

Apunte basado en el PDF Modulo_06_Kernel_Exploitation.pdf - Binary Gecko, Next-Gen Reverse Engineering Training, Módulo 6: Kernel Exploitation - Real Microsoft Patches. Se amplió con metodología de laboratorio, organización de binarios, checklist y criterios de análisis para patch diffing.