Protección de Credenciales en Windows

Reading time: 11 minutes

Protección de Credenciales

WDigest

El WDigest protocolo, introducido con Windows XP, está diseñado para la autenticación a través del Protocolo HTTP y está habilitado por defecto en Windows XP hasta Windows 8.0 y Windows Server 2003 hasta Windows Server 2012. Esta configuración predeterminada resulta en almacenamiento de contraseñas en texto plano en LSASS (Servicio de Subsistema de Autoridad de Seguridad Local). Un atacante puede usar Mimikatz para extraer estas credenciales ejecutando:

sekurlsa::wdigest

Para activar o desactivar esta función, las claves de registro UseLogonCredential y Negotiate dentro de HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest deben estar configuradas en "1". Si estas claves están ausentes o configuradas en "0", WDigest está deshabilitado:

reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

Protección LSA (procesos protegidos PP y PPL)

Proceso Protegido (PP) y Proceso Protegido Ligero (PPL) son protecciones a nivel de kernel de Windows diseñadas para prevenir el acceso no autorizado a procesos sensibles como LSASS. Introducido en Windows Vista, el modelo PP fue creado originalmente para la aplicación de DRM y solo permitía que los binarios firmados con un certificado de medios especial fueran protegidos. Un proceso marcado como PP solo puede ser accedido por otros procesos que también sean PP y tengan un nivel de protección igual o superior, y aun así, solo con derechos de acceso limitados a menos que se permita específicamente.

PPL, introducido en Windows 8.1, es una versión más flexible de PP. Permite casos de uso más amplios (por ejemplo, LSASS, Defender) al introducir "niveles de protección" basados en el campo EKU (Uso Mejorado de Clave) de la firma digital. El nivel de protección se almacena en el campo EPROCESS.Protection, que es una estructura PS_PROTECTION con:

• Tipo (Protected o ProtectedLight)
• Firmante (por ejemplo, WinTcb, Lsa, Antimalware, etc.)

Esta estructura se empaqueta en un solo byte y determina quién puede acceder a quién:

• Valores de firmante más altos pueden acceder a los más bajos
• Los PPL no pueden acceder a los PP
• Los procesos no protegidos no pueden acceder a ningún PPL/PP

Lo que necesitas saber desde una perspectiva ofensiva

• Cuando LSASS se ejecuta como un PPL, los intentos de abrirlo usando OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION) desde un contexto de administrador normal fallan con 0x5 (Acceso Denegado), incluso si SeDebugPrivilege está habilitado.
• Puedes verificar el nivel de protección de LSASS usando herramientas como Process Hacker o programáticamente leyendo el valor EPROCESS.Protection.
• LSASS típicamente tendrá PsProtectedSignerLsa-Light (0x41), que solo puede ser accedido por procesos firmados con un firmante de nivel superior, como WinTcb (0x61 o 0x62).
• PPL es una restricción solo de espacio de usuario; el código a nivel de kernel puede eludirlo completamente.
• Que LSASS sea PPL no previene el volcado de credenciales si puedes ejecutar shellcode de kernel o aprovechar un proceso de alto privilegio con acceso adecuado.
• Configurar o eliminar PPL requiere reinicio o configuraciones de Secure Boot/UEFI, que pueden persistir la configuración de PPL incluso después de que se reviertan los cambios en el registro.

Opciones para eludir las protecciones PPL:

Si deseas volcar LSASS a pesar de PPL, tienes 3 opciones principales:

1. Usar un controlador de kernel firmado (por ejemplo, Mimikatz + mimidrv.sys) para eliminar la bandera de protección de LSASS:

2. Traer tu propio controlador vulnerable (BYOVD) para ejecutar código de kernel personalizado y deshabilitar la protección. Herramientas como PPLKiller, gdrv-loader o kdmapper hacen esto factible.
3. Robar un manejador de LSASS existente de otro proceso que lo tenga abierto (por ejemplo, un proceso de AV), luego duplicarlo en tu proceso. Esta es la base de la técnica pypykatz live lsa --method handledup.
4. Abusar de algún proceso privilegiado que te permita cargar código arbitrario en su espacio de direcciones o dentro de otro proceso privilegiado, eludiendo efectivamente las restricciones de PPL. Puedes ver un ejemplo de esto en bypassing-lsa-protection-in-userland o https://github.com/itm4n/PPLdump.

Verificar el estado actual de la protección LSA (PPL/PP) para LSASS:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL

Cuando ejecutas mimikatz privilege::debug sekurlsa::logonpasswords probablemente fallará con el código de error 0x00000005 debido a esto.

• Para más información sobre esto, consulta https://itm4n.github.io/lsass-runasppl/

Credential Guard

Credential Guard, una característica exclusiva de Windows 10 (ediciones Enterprise y Education), mejora la seguridad de las credenciales de la máquina utilizando Virtual Secure Mode (VSM) y Virtualization Based Security (VBS). Aprovecha las extensiones de virtualización de la CPU para aislar procesos clave dentro de un espacio de memoria protegido, lejos del alcance del sistema operativo principal. Este aislamiento asegura que incluso el kernel no pueda acceder a la memoria en VSM, protegiendo efectivamente las credenciales de ataques como pass-the-hash. La Local Security Authority (LSA) opera dentro de este entorno seguro como un trustlet, mientras que el proceso LSASS en el sistema operativo principal actúa meramente como un comunicador con la LSA de VSM.

Por defecto, Credential Guard no está activo y requiere activación manual dentro de una organización. Es crítico para mejorar la seguridad contra herramientas como Mimikatz, que se ven obstaculizadas en su capacidad para extraer credenciales. Sin embargo, las vulnerabilidades aún pueden ser explotadas mediante la adición de Security Support Providers (SSP) personalizados para capturar credenciales en texto claro durante los intentos de inicio de sesión.

Para verificar el estado de activación de Credential Guard, se puede inspeccionar la clave del registro LsaCfgFlags bajo HKLM\System\CurrentControlSet\Control\LSA. Un valor de "1" indica activación con UEFI lock, "2" sin bloqueo, y "0" denota que no está habilitado. Esta verificación del registro, aunque es un fuerte indicador, no es el único paso para habilitar Credential Guard. Se dispone de orientación detallada y un script de PowerShell para habilitar esta característica en línea.

reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags

Para una comprensión completa e instrucciones sobre cómo habilitar Credential Guard en Windows 10 y su activación automática en sistemas compatibles de Windows 11 Enterprise y Education (versión 22H2), visita la documentación de Microsoft.

Se proporcionan más detalles sobre la implementación de SSPs personalizados para la captura de credenciales en esta guía.

Modo RestrictedAdmin de RDP

Windows 8.1 y Windows Server 2012 R2 introdujeron varias nuevas características de seguridad, incluido el modo Restricted Admin para RDP. Este modo fue diseñado para mejorar la seguridad al mitigar los riesgos asociados con los ataques de pass the hash.

Tradicionalmente, al conectarse a una computadora remota a través de RDP, sus credenciales se almacenan en la máquina objetivo. Esto representa un riesgo de seguridad significativo, especialmente al usar cuentas con privilegios elevados. Sin embargo, con la introducción del modo Restricted Admin, este riesgo se reduce sustancialmente.

Al iniciar una conexión RDP utilizando el comando mstsc.exe /RestrictedAdmin, la autenticación a la computadora remota se realiza sin almacenar sus credenciales en ella. Este enfoque asegura que, en caso de una infección de malware o si un usuario malicioso obtiene acceso al servidor remoto, sus credenciales no se vean comprometidas, ya que no están almacenadas en el servidor.

Es importante tener en cuenta que en modo Restricted Admin, los intentos de acceder a recursos de red desde la sesión RDP no utilizarán sus credenciales personales; en su lugar, se utiliza la identidad de la máquina.

Esta característica marca un avance significativo en la seguridad de las conexiones de escritorio remoto y en la protección de información sensible de ser expuesta en caso de una violación de seguridad.

Para obtener más información detallada, visita este recurso.

Credenciales en caché

Windows asegura credenciales de dominio a través de la Autoridad de Seguridad Local (LSA), apoyando procesos de inicio de sesión con protocolos de seguridad como Kerberos y NTLM. Una característica clave de Windows es su capacidad para almacenar en caché los últimos diez inicios de sesión de dominio para garantizar que los usuarios aún puedan acceder a sus computadoras incluso si el controlador de dominio está fuera de línea—una ventaja para los usuarios de laptops que a menudo están fuera de la red de su empresa.

El número de inicios de sesión en caché es ajustable a través de una clave de registro o política de grupo específica. Para ver o cambiar esta configuración, se utiliza el siguiente comando:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

El acceso a estas credenciales en caché está estrictamente controlado, con solo la cuenta SYSTEM teniendo los permisos necesarios para verlas. Los administradores que necesiten acceder a esta información deben hacerlo con privilegios de usuario SYSTEM. Las credenciales se almacenan en: HKEY_LOCAL_MACHINE\SECURITY\Cache

Mimikatz se puede emplear para extraer estas credenciales en caché utilizando el comando lsadump::cache.

Para más detalles, la fuente original proporciona información completa.

Usuarios Protegidos

La membresía en el grupo de Usuarios Protegidos introduce varias mejoras de seguridad para los usuarios, asegurando niveles más altos de protección contra el robo y el uso indebido de credenciales:

• Delegación de Credenciales (CredSSP): Incluso si la configuración de Directiva de Grupo para Permitir delegar credenciales predeterminadas está habilitada, las credenciales en texto plano de los Usuarios Protegidos no se almacenarán en caché.
• Windows Digest: A partir de Windows 8.1 y Windows Server 2012 R2, el sistema no almacenará en caché las credenciales en texto plano de los Usuarios Protegidos, independientemente del estado de Windows Digest.
• NTLM: El sistema no almacenará en caché las credenciales en texto plano de los Usuarios Protegidos ni funciones unidireccionales NT (NTOWF).
• Kerberos: Para los Usuarios Protegidos, la autenticación Kerberos no generará claves DES o RC4, ni almacenará en caché credenciales en texto plano o claves a largo plazo más allá de la adquisición inicial del Ticket-Granting Ticket (TGT).
• Inicio de Sesión Offline: No se creará un verificador en caché para los Usuarios Protegidos al iniciar sesión o desbloquear, lo que significa que el inicio de sesión offline no es compatible con estas cuentas.

Estas protecciones se activan en el momento en que un usuario, que es miembro del grupo de Usuarios Protegidos, inicia sesión en el dispositivo. Esto asegura que se implementen medidas de seguridad críticas para proteger contra varios métodos de compromiso de credenciales.

Para obtener información más detallada, consulte la documentación oficial.

Tabla de los docs.