Detén el robo de credenciales: la configuración de Windows que nadie habilita

febrero 20, 2026 • febrero 20, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

La mayor parte del robo de credenciales en Windows no es magia. Es fontanería. Los atacantes no necesitan “hacks” de película cuando tus endpoints almacenan en silencio secretos reutilizables en lugares diseñados para la comodidad, no para redes hostiles.

La configuración que cambia la economía para los atacantes es Windows Defender Credential Guard. No es nueva. No es exótica. Simplemente… rara vez se activa de forma consistente. Y por eso sigue apareciendo en informes post-incidente como un detector de humo que falta: solo te das cuenta después del incendio.

La configuración: Credential Guard (y qué hace realmente)

Credential Guard es el intento de Microsoft de evitar que Windows sea un buffet de secretos reutilizables. Específicamente, utiliza Virtualization-Based Security (VBS) para aislar secretos de modo que, incluso si un atacante logra admin en la máquina, sea más difícil extraerlos y reproducirlos.

Sin Credential Guard, el Local Security Authority Subsystem Service (LSASS) es tanto el portero como la barra. Autentica usuarios y también mantiene material de credenciales en proceso. Si un actor malicioso puede volcar la memoria de LSASS (o forzarla vía drivers firmados, privilegios de depuración o juegos con tokens), a menudo puede recolectar:

Hashes NTLM (combustible para Pass-the-Hash)
Tickets Kerberos Ticket Granting Tickets (combustible para Pass-the-Ticket)
Credenciales de dominio en caché (combustible para cracking offline)
A veces incluso secretos en texto plano, según la configuración y componentes de autenticación heredados

Con Credential Guard, las partes sensibles se mueven a un entorno protegido (isolated user mode) respaldado por el hipervisor. LSASS aún puede solicitar operaciones de autenticación, pero no mantiene las joyas de la corona de una forma que sea fácil de raspar.

¿Es Credential Guard perfecto? No. Nada lo es. Es un control que aumenta el coste para el atacante y reduce el radio de daño. En seguridad en producción, ese es todo el trabajo.

Lo que Credential Guard no hace

No soluciona contraseñas débiles, cuentas con permisos excesivos ni “Domain Admins por todas partes”.
No evita el phishing que captura credenciales antes de que lleguen a tu máquina.
No impide que un atacante conectado haga daño como ese usuario.
No hace que la autenticación heredada sea mágicamente segura; a menudo la rompe (lo cual es una característica, no un bug).

Por qué nadie la habilita (y por qué eso no es una excusa válida)

Credential Guard se ignora por tres razones: miedo, inercia y “compatibilidad”. La mayoría de organizaciones tiene al menos una aplicación crítica antigua, un cliente VPN de un proveedor obsoleto o un complemento de autenticación “especial” que se actualizó por última vez cuando la gente aún discutía si el Wi‑Fi se impondría.

Así que los equipos hacen lo que hacen bajo presión de entrega: evitan cambios que puedan generar tickets. Mantienen la superficie de credenciales del endpoint amplia porque “siempre ha funcionado así”.

Mientras tanto, los atacantes automatizan el robo de credenciales. No necesitan respetar el horario de tu mesa de ayuda. Operan a velocidad máquina.

Aquí está la verdad incómoda: la compatibilidad es un problema solucionable; el robo de credenciales a escala es un problema que puede acabar con el negocio. Tu objetivo es encontrar el pequeño número de endpoints y flujos de trabajo que realmente no pueden funcionar con Credential Guard, aislarlos y dejar de fingir que toda la empresa debe ser insegura por su culpa.

Broma #1: Si tu estrategia de seguridad depende de “nadie obtendrá admin local”, tengo un puente para venderte—pago aceptado en hashes NTLM.

Qué detienes en realidad: LSASS, hashes, tickets y reproducción

Credential Guard apunta a un segmento muy específico y muy común del kill-chain: reproducción de credenciales post-compromiso y movimiento lateral. El patrón se ve así:

Acceso inicial (phishing, exploit en navegador, credenciales VPN robadas, RDP expuesto, macro maliciosa—elige tu veneno).
Escalada de privilegios local o robo de tokens para obtener integridad alta.
Volcar credenciales desde LSASS (o coaccionar material de autenticación) y reutilizarlas.
Moverse lateralmente a servidores de archivos, RDP a escritorios, atacar AD, conseguir más credenciales y escalar hasta dominación del dominio.

Credential Guard hace el paso 3 materialmente más difícil al aislar secretos, limitar lo que LSASS expone y reducir el valor de herramientas de “volcar y listo”.

Vale la pena destacar las partes que siguen apareciendo en incidentes:

Pass-the-Hash (PtH)

Los hashes NTLM son reutilizables en demasiados lugares. Si puedes obtener el hash de una cuenta privilegiada, a menudo puedes autenticarte sin conocer la contraseña. Credential Guard reduce la disponibilidad de esos hashes en LSASS.

Pass-the-Ticket (PtT)

Los tickets Kerberos pueden reproducirse. Si los atacantes pueden extraer material de tickets, pueden suplantar usuarios y servicios. Credential Guard reduce la exposición de secretos de concesión de tickets.

WDigest y proveedores de credenciales heredados

Windows ha mantenido comportamientos de autenticación heredados por compatibilidad. Algunos de esos comportamientos son básicamente “almacenar secretos de forma que resulta cómoda para los atacantes”. Quieres eliminarlos.

Exposición de credenciales por RDP

RDP no es malvado. Pero permitir que usuarios con privilegios hagan RDP a endpoints de baja confianza es como donar credenciales de admin a la primera muestra de malware que tenga suerte. Credential Guard ayuda, pero también lo hacen Remote Credential Guard y un diseño sensato de estaciones de trabajo administrativas.

Datos e historia que explican el desorden actual

Los controles de seguridad tienen más sentido cuando entiendes por qué existen los valores por defecto débiles. Aquí algunos puntos concretos—contexto histórico, no nostalgia:

LSASS ha sido un objetivo de alto valor durante décadas porque es donde Windows realiza la autenticación y donde se acumula material de credenciales durante el uso normal.
“Pass-the-Hash” cobró atención general a finales de los 2000, y siguió siendo relevante porque NTLM perduró en empresas como una impresora sin parchar: siempre presente, silenciosamente crítica.
WDigest fue diseñado por compatibilidad con esquemas de autenticación más antiguos; el problema es que la compatibilidad a veces significa “manejo más fácil en texto plano”. Las versiones modernas de Windows endurecieron los valores por defecto, pero las actualizaciones y la deriva de políticas mantienen vivo el riesgo.
Credential Guard llegó en la era de Windows 10 Enterprise / Windows Server 2016, ligado a VBS y aislamiento por hipervisor—seguridad integrada en la plataforma en lugar de añadida.
La virtualización se convirtió en el límite de seguridad porque el límite clásico del SO fallaba ante drivers de kernel, privilegios de admin y raspado de memoria; el hipervisor es más difícil de manipular que un proceso en modo usuario.
Las herramientas de ataque se profesionalizaron: lo que antes era una habilidad de nicho se convirtió en marcos de trabajo de “un clic” que extraen credenciales rápida y silenciosamente.
“Proteger LSASS” (RunAsPPL) precede a la adopción general de Credential Guard; muchas organizaciones habilitaron PPL sin completar el trabajo, dejando otro material de credenciales todavía accesible.
La guía moderna de Microsoft asume cada vez más “asume compromiso”, enfocándose en minimizar la exposición de credenciales en lugar de fingir que los endpoints nunca se comprometerán.

Guía rápida de diagnóstico

Cuando sospechas exposición por robo de credenciales—o estás preparando el despliegue y quieres saber qué fallará—no vagues. Empieza con un bucle cerrado: verifica requisitos de plataforma, verifica que el control esté realmente en ejecución y luego identifica dependencias heredadas.

1) Comprueba primero: ¿Credential Guard está realmente activado?

Busca el estado de VBS y el estado de ejecución de Credential Guard.
Si está “configurado” pero no “en ejecución”, tienes un problema de plataforma/prerrequisitos (firmware, virtualización, políticas, conflictos de drivers).

2) Comprueba segundo: ¿Sigues filtrando credenciales vía configuraciones heredadas?

WDigest, uso de NTLM, logones en caché y configuraciones de delegación “convenientes”.
Si sigues permitiendo NTLM en todas partes, Credential Guard ayuda pero dejas una puerta lateral abierta.

3) Comprueba tercero: ¿Los administradores inician sesión en los lugares equivocados?

Las cuentas privilegiadas en estaciones de usuarios son un incidente esperando invitación de calendario.
Arregla flujos: estaciones de administración (PAWs/SAWs), Remote Credential Guard y separación clara de roles.

4) Comprueba cuarto: ¿Estás bloqueando las técnicas comunes de volcado?

LSASS PPL, reglas de Attack Surface Reduction (ASR), control de drivers y protección contra manipulación de EDR.
Si no puedes impedir que se cargue un driver firmado vulnerable, tu historia de aislamiento es más débil de lo que parece.

Tareas prácticas: 12+ comprobaciones con comandos, salidas y decisiones

Estas son tareas para “hacer en una máquina”. Cada una incluye un comando realista, qué significa la salida y qué decisión tomar después. Ejecútalas en una sesión de PowerShell elevada salvo que se indique lo contrario. El prompt en los bloques es fijo por diseño.

Tarea 1: Comprobar si Credential Guard está en ejecución (WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

Qué significa: El array numérico lista servicios de seguridad que están corriendo bajo Device Guard/VBS. Comúnmente, 1 indica Credential Guard y 2 indica Hypervisor-protected Code Integrity (HVCI), aunque los mapeos exactos pueden variar según la build.

Decisión: Si no ves los valores esperados, Credential Guard no está en ejecución. Pasa a verificación de prerrequisitos y políticas (Tareas 2–4).

Tarea 2: Comprobar si VBS está habilitado (WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, RequiredSecurityProperties, AvailableSecurityProperties | Format-List"
VirtualizationBasedSecurityStatus : 2
RequiredSecurityProperties       : {1}
AvailableSecurityProperties      : {0, 1, 2, 3}

Qué significa: VirtualizationBasedSecurityStatus típicamente: 0=desactivado, 1=configurado pero no en ejecución, 2=en ejecución. Las propiedades requeridas/disponibles indican si el hardware/firmware soportan el modelo de seguridad.

Decisión: Si el estado es 1, probablemente necesitas un reinicio, virtualización en firmware o remediación de drivers. Si es 0, la política no está aplicada.

Tarea 3: Verificar que el hipervisor Hyper-V esté presente (system info)

cr0x@server:~$ powershell -NoProfile -Command "systeminfo | Select-String -Pattern 'Hyper-V Requirements|A hypervisor has been detected|Virtualization' -Context 0,1"
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

Qué significa: Virtualización en firmware y SLAT son necesarios para muchos escenarios VBS. Si “Virtualization Enabled In Firmware: No”, estás fuera de juego.

Decisión: Si la virtualización está deshabilitada, planifica un cambio en BIOS/UEFI y una ventana de mantenimiento. Si falta SLAT, ese hardware no será buen candidato para VBS.

Tarea 4: Confirmar política de Credential Guard en el registro

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard' /v EnableVirtualizationBasedSecurity & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v LsaCfgFlags"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
    EnableVirtualizationBasedSecurity    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    LsaCfgFlags    REG_DWORD    0x1

Qué significa: Estos valores reflejan comúnmente la configuración de VBS y Credential Guard. LsaCfgFlags puede indicar deshabilitado/habilitado con o sin bloqueo UEFI según las decisiones de la organización.

Decisión: Si la política está establecida pero WMI dice “no en ejecución”, diagnostica prerrequisitos (drivers, estado del hipervisor, Secure Boot, reinicio requerido).

Tarea 5: Comprobar si LSASS se ejecuta como Protected Process Light (PPL)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Name lsass | Select-Object Name,Id,Path | Format-List"
Name : lsass
Id   : 628
Path : C:\Windows\System32\lsass.exe

Qué significa: PowerShell no muestra directamente PPL. Esta tarea confirma la ruta del proceso y la sanidad antes de comprobar el registro y eventos en el siguiente paso.

Decisión: Si lsass no está en la ruta esperada, trátalo como sospechoso e investiga inmediatamente.

Tarea 6: Verificar la configuración “RunAsPPL” para LSASS

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v RunAsPPL"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    RunAsPPL    REG_DWORD    0x1

Qué significa: RunAsPPL=1 habilita LSASS como protected process light, lo que bloquea muchas técnicas de volcado en modo usuario a menos que el atacante tenga trucos a nivel kernel.

Decisión: Si es 0 o falta, inclúyelo en tu baseline. Credential Guard y PPL son complementarios; no elijas uno y des por terminado el trabajo.

Tarea 7: Comprobar uso de WDigest (riesgo de exposición en texto plano)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
    UseLogonCredential    REG_DWORD    0x0

Qué significa: 0 generalmente indica que WDigest no está almacenando credenciales de inicio de sesión de forma que exponga texto plano. 1 es una bandera roja salvo que exista una necesidad heredada muy específica.

Decisión: Si es 1, arréglalo mediante política y audita qué aplicaciones lo fuerzan. Si alguien “lo necesita”, que lo demuestre y aísla ese sistema.

Tarea 8: Identificar uso de NTLM en el endpoint (eventos locales)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 30 | Where-Object {$_.Properties[10].Value -like 'NTLM*'} | Select-Object -First 5 | ForEach-Object { $_.Properties[5].Value + ' ' + $_.Properties[10].Value }"
jdoe NTLMv2
svc_backup NTLMv2
jdoe NTLMv2

Qué significa: Se muestran logones recientes usando NTLM. El parseo de eventos varía; la idea es encontrar si NTLM sigue activo en flujos de trabajo.

Decisión: Si NTLM es común para cuentas administrativas o acceso a servidores, tienes un acelerador de movimiento lateral. Planifica restricciones de NTLM y migra servicios a Kerberos cuando sea posible.

Tarea 9: Comprobar el conteo de logones en caché (exposición de caché de credenciales offline)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount"
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

Qué significa: Windows cachea un número de inicios de sesión de dominio anteriores para uso offline. Números más altos significan más material en caché valioso para atacar en laptops robadas.

Decisión: Redúcelo donde el negocio lo permita (especialmente para usuarios privilegiados) y combínalo con BitLocker y controles fuertes de dispositivo. No rompas a usuarios en movilidad sin piloto.

Tarea 10: Verificar preparación para Remote Credential Guard (capacidad cliente/servidor RDP)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SecurityLayer,UserAuthentication | Format-List"
SecurityLayer      : 2
UserAuthentication : 1

Qué significa: Las configuraciones indican negociación de seguridad RDP y NLA. No es una comprobación completa de Remote Credential Guard, pero es una señal rápida de que no estás ejecutando RDP completamente descubierto.

Decisión: Si NLA está desactivado, actívalo. Luego diseña acceso administrativo para usar Remote Credential Guard o hosts jump endurecidos.

Tarea 11: Confirmar estado de Secure Boot (a menudo requerido para modos bloqueados)

cr0x@server:~$ powershell -NoProfile -Command "Confirm-SecureBootUEFI"
True

Qué significa: Secure Boot está habilitado. Algunos modos de despliegue de Credential Guard (especialmente con bloqueo UEFI) asumen Secure Boot para mayor resistencia a la manipulación.

Decisión: Si es false, decide si aceptas “configurado pero más fácil de manipular” o planifica habilitar Secure Boot. Para endpoints privilegiados, planifícalo.

Tarea 12: Comprobar si estás en una VM (y si VBS es soportado allí)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Model,Manufacturer"
Model        Manufacturer
-----        ------------
Virtual Machine Microsoft Corporation

Qué significa: Este host está virtualizado. El soporte de VBS/Credential Guard en VMs depende de tu hipervisor, versión y características (virtualización anidada, vTPM, etc.).

Decisión: Si servidores críticos son VMs, valida que el hipervisor soporte las características de seguridad que estás exigiendo. No “requieras VBS” y luego lo despliegues en una plataforma que no pueda ejecutarlo.

Tarea 13: Detectar configuraciones de delegación potencialmente peligrosas en cuentas (consulta AD desde host admin)

cr0x@server:~$ powershell -NoProfile -Command "Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | Select-Object SamAccountName,TrustedForDelegation | Sort-Object SamAccountName | Select-Object -First 5"
SamAccountName TrustedForDelegation
------------- --------------------
svc_app01     True
svc_legacy02  True

Qué significa: Las cuentas confiables para delegación pueden aumentar el impacto del robo de credenciales y el abuso de tickets.

Decisión: Audita por qué existe cada una. Prefiere delegación restringida y patrones de autenticación modernos. Si no sabes por qué existe, esa es tu respuesta.

Tarea 14: Confirmar estado de reglas ASR relevantes para robo de credenciales (Defender)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids | Select-Object -First 5"
D4F940AB-401B-4EFC-AADC-AD5F3C50688A
9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

Qué significa: Las reglas ASR están configuradas. Aún necesitas mapear GUIDs a la intención de la regla en tu estándar, pero esto indica si el endpoint está siquiera en el juego.

Decisión: Si no usas ASR, Credential Guard por sí solo deja abiertos otros caminos de robo de credenciales (volcados scriptados, comportamientos de procesos sospechosos). Planifica ASR en modo auditoría y luego aplícalo.

Tarea 15: Confirmar configuraciones de volcado de fallos (evitar “ups escribimos LSASS a disco”)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v CrashDumpEnabled & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v DumpFile"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    CrashDumpEnabled    REG_DWORD    0x2

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    DumpFile    REG_EXPAND_SZ    %SystemRoot%\MEMORY.DMP

Qué significa: Los volcados de kernel/memoria pueden contener material sensible dependiendo del contexto del crash y las herramientas. Esto no es “Credential Guard apagado” malo, pero sí un riesgo de manejo de datos.

Decisión: Asegura que los volcados estén protegidos (ACLs, cifrado en reposo, acceso limitado) y que tu proceso de incidente trate los volcados como alta sensibilidad.

Tres mini-historias corporativas del mundo real

Mini-historia 1: El incidente causado por una suposición errónea

Una empresa mediana tenía un EDR sólido y un orgulloso ritmo de parches. Su suposición era simple: “Si Defender y EDR están instalados en todas partes, el volcado de credenciales será detectado.” Trataron el robo de credenciales como un problema de detección, no de exposición.

Una campaña de phishing llegó a una estación de trabajo de finanzas. El malware inicial no hizo nada sofisticado. Esperó a un token de admin local (alguien de TI se conectó por control remoto para “arreglar Outlook”), luego usó ese privilegio para intentar acceder a LSASS. El EDR bloqueó una técnica de volcado conocida. Todos respiraron. Ticket cerrado.

Dos días después, un servidor de archivos mostró patrones de acceso extraños. Luego un controlador de dominio. El atacante no necesitó volcar LSASS de la forma “ruidosa”. Usó caminos alternativos: suplantación de tokens, material en caché y reproducción de credenciales usando la plomería incorporada de Windows. No eran más rápidos que el equipo azul. Solo eran más pacientes.

El postmortem fue doloroso porque los controles “estaban presentes”, pero los secretos seguían accesibles. Credential Guard no se había habilitado porque “escuchamos que rompe algunos VPN”. Eso fue cierto para un puñado de endpoints, no para 18,000.

La reparación no fue heroica. Desplegaron Credential Guard primero a usuarios estándar, luego a TI, y finalmente a una capa de estaciones de trabajo administrativas diseñadas cuidadosamente. El mayor cambio fue cultural: las cuentas admin dejaron de iniciar sesión en endpoints aleatorios. El movimiento favorito del atacante—tomar un hash privilegiado de una estación—dejó de ser fiable.

Mini-historia 2: La optimización que salió mal

Una compañía global tenía obsesión por el rendimiento. Optimizaron tiempos de arranque y acceso remoto a escala. Parte de esa optimización incluía mantener el caché de credenciales generoso (“los usuarios viajan”), permitir NTLM ampliamente (“shares heredados”) y dejar un puñado de políticas de conveniencia porque reducían llamadas a la mesa de ayuda.

Entonces activaron Credential Guard para un grupo piloto de desarrolladores. Un pequeño conjunto de flujos remotos se ralentizó. Algunos handshakes de autenticación antiguos fallaron. La conclusión ruidosa fue: “Credential Guard causa problemas.” La realidad silenciosa fue: “Hemos dependido de retrocesos inseguros como optimizaciones de rendimiento.”

En lugar de arreglar la cadena de dependencias, retrocedieron. Seis meses después, un atacante aterrizó en una estación de dev, raspó lo que pudo y usó movimiento lateral basado en NTLM para alcanzar un servidor de build. Desde ahí manipularon artefactos, y la respuesta al incidente se convirtió en un problema de cadena de suministro de software—costoso, con daño reputacional y lento de revertir.

Después, la “optimización” pasó a llamarse por lo que era: una deuda técnica de seguridad con interés compuesto. Reintrodujeron Credential Guard, pero esta vez lo emparejaron con remediación: migrar servicios a Kerberos, restringir el alcance de NTLM y usar hosts jump endurecidos para caminos administrativos. El rendimiento fue aceptable. El retroceso inseguro había sido el verdadero cuello de botella—solo que no era el medido en los dashboards.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización sanitaria mantenía una línea base estricta de endpoints. No era glamoroso. Era un montón de políticas de grupo, VBS donde era posible, Credential Guard aplicado en la mayoría de endpoints y una regla estricta: las cuentas privilegiadas solo inician sesión en estaciones de acceso privilegiado. También mantuvieron una pequeña lista de excepciones para sistemas que no podían soportar VBS, y esos se aislaron como material radiactivo.

Siguieron siendo golpeados por malware. A todos les pasa. La diferencia fue lo que el malware no pudo hacer. Aterrizó en un PC de estación de enfermería, obtuvo acceso a nivel usuario e intentó moverse lateralmente. Encontró poco que reutilizar. No había credenciales de admin presentes. El material de credenciales era menos accesible. Las rutas obvias de PtH y PtT eran poco fiables.

El atacante pivotó a comportamiento oportunista de ransomware. El radio de daño fue feo pero contenido: un subconjunto de escritorios y un par de shares. Los controladores de dominio se mantuvieron limpios. Los sistemas clínicos centrales siguieron en línea. La organización tuvo una semana mala en lugar de un mes catastrófico.

La revisión post-incidente fue casi aburrida: “La línea base funcionó como diseñada.” Ese es el objetivo. La fiabilidad no son fuegos artificiales; es la ausencia de sorpresa.

Listas de verificación / plan paso a paso (despliegue que no colapsará tu mesa de ayuda)

Credential Guard no es una casilla. Es un despliegue. Hazlo como lo haría un SRE: por etapas, medible, reversible cuando proceda y con bucles de retroalimentación cerrados.

Paso 1: Inventario y segmentación de endpoints (no hiervas el océano)

Modelo Tier 0/1/2: controladores de dominio e infraestructura de identidad; niveles de servidor; endpoints de usuario.
Identifica endpoints que deben soportar autenticación heredada (sistemas de proveedores, clientes VPN antiguos, drivers de hardware especiales).
Crea un “anillo de excepción” con controles compensatorios (aislamiento de red, inicios de sesión administrativos restringidos, políticas EDR más estrictas).

Paso 2: Habilitar prerrequisitos limpiamente

Virtualización en firmware habilitada.
Secure Boot activado donde sea factible (especialmente en endpoints privilegiados).
Higiene de drivers: eliminar o actualizar drivers de kernel incompatibles.

Paso 3: Piloto por anillos

Anillo 0: portátiles del equipo de seguridad TI y algunos power users amigables.
Anillo 1: población estándar de usuarios.
Anillo 2: estaciones de trabajo de desarrolladores (a menudo la pila de autenticación más desordenada).
Anillo 3: estaciones de acceso privilegiado y hosts jump.

Paso 4: Emparejar con los controles aburridos que lo hacen efectivo

Habilitar LSASS PPL (RunAsPPL) donde se soporte.
Deshabilitar el caché en texto plano de WDigest (verificar que permanezca deshabilitado).
Usar reglas de Attack Surface Reduction (empezar en auditoría y luego aplicar).
Reducir huella de NTLM; restringir dónde puede usarse.
Separar identidades administrativas y restringir dónde pueden iniciar sesión las cuentas privilegiadas.

Paso 5: Monitorizar y aplicar

Reportar estados “configurado pero no en ejecución”.
Rastrear dispositivos en excepción y justificar periódicamente su estado.
Alertar sobre accesos sospechosos a LSASS y material de credenciales.

Paso 6: Documentar los modos de fallo que reportarán los usuarios

Clientes VPN antiguos que intentan enganchar proveedores de autenticación.
Plugins SSO heredados.
Middleware de tarjetas inteligentes o herramientas de seguridad con drivers obsoletos.

Broma #2: Lo único más permanente que una excepción temporal es una excepción temporal que “solo necesita un trimestre más”.

Errores comunes: síntoma → raíz → solución

1) “Credential Guard está habilitado por política, pero no está en ejecución.”

Síntoma: WMI muestra estado de VBS “configurado” o “apagado”, y SecurityServicesRunning está vacío.

Raíz: Virtualización en firmware ausente, desajuste en Secure Boot, drivers incompatibles o falta de reinicio tras habilitar.

Solución: Valida virtualización en firmware (Tarea 3), Secure Boot (Tarea 11) y remedia conflictos de drivers. Reinicia. Si estás en VMs, confirma soporte del hipervisor (Tarea 12).

2) “Después de habilitar, el VPN/SSO se rompió.”

Síntoma: Bucle de solicitudes de autenticación, SSO falla o un cliente no se conecta.

Raíz: Proveedores de credenciales heredados, ganchos de autenticación o drivers no compatibles con aislamiento VBS.

Solución: Actualiza el cliente, migra a un método de autenticación soportado o aísla ese flujo a hosts jump endurecidos. No hagas rollback global—crea un anillo de excepción con controles compensatorios.

3) “RDP a servidores ahora pide credenciales diferente / la automatización falló.”

Síntoma: Scripts que dependen de credenciales almacenadas fallan; el administrador se queja de prompts extra.

Raíz: Dependías de patrones de delegación de credenciales que son arriesgados por diseño.

Solución: Usa Remote Credential Guard donde corresponda, migra la automatización a identidades gestionadas/servicio principal, y deja de incrustar secretos reutilizables en scripts.

4) “El EDR dice que el acceso a LSASS fue bloqueado; los usuarios reportan fallos aleatorios de apps.”

Síntoma: Una herramienta de seguridad bloquea un proceso de leer LSASS; un “gestor de contraseñas” o “agente de monitorización” se queja.

Raíz: Una herramienta legítima (o no tan legítima) intenta acceder a comportamientos de credenciales indistinguibles de un volcado.

Solución: Elimina la herramienta o consigue una versión soportada por el proveedor que no requiera raspar LSASS. Trata “necesita leer LSASS” como un defecto de diseño, no como un requisito.

5) “Habilitamos Credential Guard, pero los atacantes aún se movieron lateralmente.”

Síntoma: Movimiento lateral mediante SMB/RDP/WinRM aún ocurrió.

Raíz: Credential Guard reduce ciertas vías de robo de credenciales; no soluciona mala higiene administrativa, privilegios excesivos, sprawl de NTLM o phishing de credenciales.

Solución: Impone modelo de estaciones administrativas, restringe NTLM, reduce membresía de admin local y endurece la gestión remota. Asume compromiso de endpoints y diseña para contención.

6) “La mesa de ayuda lo deshabilitó en algunas máquinas para arreglar un ticket—y lo olvidaron.”

Síntoma: Deriva: algunos endpoints ya no ejecutan VBS/Credential Guard.

Raíz: No hay bucle de aplicación/reporting; las excepciones no se rastrean como deuda operativa.

Solución: Monitoriza el estado de ejecución (Tareas 1–2) centralmente, aplica la política y exige excepciones con duración limitada y revisión.

Una cita para tener en la pared

Idea parafraseada — Werner Vogels: construyes sistemas asumiendo que las cosas fallarán, y los haces resilientes por diseño, no por pensamiento deseoso.

Qué evitar: la versión de “teatro de seguridad” de este control

Credential Guard suele desplegarse de una manera que queda bien en una diapositiva y hace poco en la práctica:

Habilitado en un subconjunto de endpoints sin medir el “estado de ejecución”.
Los admins siguen iniciando sesión en todas partes, así que las credenciales privilegiadas siguen aterrizando en máquinas de baja confianza.
NTLM permanece en todas partes y las excepciones se multiplican en silencio.
No hay plan para apps heredadas, así que los equipos hacen rollback al primer reclamo.

No hagas eso. Si vas a asumir el coste político y operativo de endurecer la autenticación, deberías conseguir el beneficio de seguridad.

Cómo Credential Guard cambia las matemáticas del atacante (prácticamente)

En respuesta a incidentes, siempre te preguntas: “Si tuvieron admin en una estación, ¿podrían haber tomado el dominio?” Credential Guard hace que esa pregunta sea menos aterradora porque reduce la posibilidad de que un endpoint comprometido sea una fuente de credenciales.

Pero solo funciona si lo tratas como parte de una estrategia de contención de identidad:

Reduce la presencia de credenciales: No inicies sesión con cuentas privilegiadas en dispositivos no confiables.
Reduce la reutilización de credenciales: Menos contraseñas locales compartidas, menos cuentas de servicio con amplios derechos.
Reduce la autenticación heredada: Reducir el alcance de NTLM, eliminar proveedores viejos.
Reduce la extracción: Credential Guard + LSASS PPL + EDR/ASR + control de drivers.

Esta es la visión SRE de la seguridad: controla el radio de daño, elimina puntos únicos de fallo catastrófico y mide tus controles como sistemas en ejecución, no como intenciones.

Preguntas frecuentes (FAQ)

1) ¿Credential Guard es lo mismo que “protección de LSASS”?

No. La protección de LSASS (RunAsPPL) hace más difícil que procesos lean LSASS. Credential Guard usa VBS para aislar secretos de modo que no estén en la memoria de LSASS en primer lugar. Usa ambos cuando puedas.

2) ¿Credential Guard detendrá Mimikatz?

Puede reducir significativamente lo que las herramientas comunes de volcado de credenciales pueden extraer de LSASS en sistemas correctamente configurados. No detendrá todas las técnicas post-explotación, ni detendrá el phishing. Cambia lo que está disponible para robar.

3) ¿Por qué escucho que “rompe cosas”?

Porque algún software depende del comportamiento de proveedores de credenciales heredados o de drivers de kernel que no funcionan bien con VBS. Eso es un problema de calidad de software que normalmente puedes remediar con actualizaciones, cambios de configuración o rediseño de flujos.

4) ¿Necesito Windows Enterprise?

Credential Guard está generalmente orientado a ediciones Enterprise/Education y entornos gestionados. En la práctica, lo que puedes habilitar depende de la edición del SO, la build y el enfoque de gestión. Valida frente a tu flota antes de prometer nada.

5) ¿Puedo habilitarlo en servidores?

Sí, en muchos escenarios, pero trata a los servidores como infraestructura de producción: prueba compatibilidad de drivers, herramientas de seguridad y flujos de gestión remota. Algunos servidores (especialmente antiguos o especializados) pueden necesitar excepciones con aislamiento.

6) Si uso tarjetas inteligentes o Windows Hello for Business, ¿aún lo necesito?

Sí. Una autenticación de usuario más fuerte ayuda, pero Credential Guard protege el material de credenciales derivadas y reduce oportunidades de reproducción en endpoints comprometidos.

7) ¿Cómo le demuestro a los auditores que realmente está habilitado?

No pruebes “la política está establecida”. Prueba “está en ejecución”. Usa señales WMI (Tareas 1–2) recogidas centralmente y reporta deriva. A los auditores les encanta la evidencia; a los atacantes les encanta la deriva.

8) ¿Cuál es la mayor razón por la que falla como inversión de seguridad?

El comportamiento administrativo. Si las cuentas privilegiadas siguen iniciando sesión en estaciones de usuario, puedes perder el dominio por rutas alternas. Credential Guard reduce una vía importante; no excusa mala higiene de identidad.

9) ¿Debería deshabilitar NTLM después de habilitar Credential Guard?

No como un cambio masivo. Mide el uso de NTLM primero, luego restríngelo quirúrgicamente. El objetivo es reducir NTLM donde no es necesario y contenerlo donde es inevitable.

10) ¿Vale la pena si ya tengo un EDR?

Sí. EDR es detección y respuesta. Credential Guard es reducción de exposición. Quieres ambos: menos secretos disponibles para robar y mejores probabilidades de detectar al atacante de todos modos.

Siguientes pasos que puedes hacer esta semana

Si quieres que esto sea real—no un PowerPoint de política—haz estos pasos prácticos:

Mide la realidad: Ejecuta las Tareas 1–2 en una muestra representativa. Cuenta “en ejecución” vs “configurado” vs “apagado”.
Encuentra tus bloqueadores: Para sistemas que no están en ejecución, recopila estado de virtualización en firmware (Tarea 3) y Secure Boot (Tarea 11). Identifica conflictos de drivers y agentes de proveedores.
Elimina exposiciones heredadas obvias: Asegura que WDigest esté deshabilitado (Tarea 7) y habilita LSASS PPL donde se soporte (Tarea 6).
Arregla las rutas de inicio de sesión admin: Deja de iniciar sesión con usuarios privilegiados en escritorios aleatorios. Crea una estación de acceso privilegiado/host jump.
Inicia un registro de excepciones: Cada dispositivo que no pueda ejecutar Credential Guard entra en una lista con propietario de negocio, justificación, controles compensatorios y fecha de revisión.
Despliega por anillos: Piloto, mide tipos de tickets, remedia, expande. No conviertas esto en una “sorpresa” de viernes por la noche.

El robo de credenciales es popular porque funciona. Credential Guard es impopular porque cambia valores por defecto. Precisamente por eso deberías habilitarlo: es uno de los pocos controles de Windows que reduce de forma significativa el valor de un endpoint comprometido.