¿Qué son las Shadow Credentials?
Shadow Credentials es el nombre usado por la comunidad de Active Directory para un camino de ataque que abusa de material de autenticación basado en claves en una cuenta, normalmente mediante el atributo msDS-KeyCredentialLink. Lo importante no es el nombre. Lo importante es que un principal puede recibir una ruta adicional de autenticación con clave pública separada de su contraseña.
En una implementación legítima, msDS-KeyCredentialLink se usa con Windows Hello for Business y con escenarios relacionados de Key Trust. Microsoft documenta que, en determinadas implementaciones híbridas de Windows Hello for Business, la clave pública del usuario puede sincronizarse desde Microsoft Entra ID hacia Active Directory y escribirse en el atributo msDS-KeyCredentialLink del objeto de usuario. Microsoft también documenta el comportamiento Key Trust para Kerberos PKINIT: un KDC que usa Active Directory como base de cuentas debe confirmar que la cuenta tiene la misma clave pública en msDS-KeyCredentialLink.
Un caso de abuso de Shadow Credentials existe cuando un atacante o administrador no autorizado puede agregar o conservar una key credential inesperada en un objeto de usuario o equipo, y después usar la clave privada correspondiente para autenticarse como esa cuenta mediante un flujo basado en claves. No es password spraying, Kerberoasting, DCSync ni un Golden Ticket. Se parece más a una ruta de persistencia e impersonación basada en ACL: el objeto de directorio de la cuenta fue modificado para que una clave distinta pueda satisfacer las comprobaciones de autenticación.
Este artículo usa el término Shadow Credentials porque es ampliamente reconocido por defensores y auditores de Active Directory. La documentación de Microsoft suele describir los mecanismos subyacentes como Windows Hello for Business, Key Trust, PKINIT y msDS-KeyCredentialLink. Esa diferencia importa: el atributo por sí mismo no es malicioso. Un valor no nulo de msDS-KeyCredentialLink puede ser normal en entornos que usan Windows Hello for Business, flujos relacionados con FIDO o funciones de confianza por clave. El objetivo defensivo es identificar key credentials no autorizadas, huérfanas, inesperadas o presentes en cuentas privilegiadas, no borrar todos los valores a ciegas.
Para el contexto más amplio de rutas de ataque de identidad, consulta Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin y Auditar la seguridad de Active Directory: checklist práctica. Shadow Credentials pertenece a la misma familia de problemas porque la causa raíz suele ser una capacidad excesiva de escritura sobre un objeto de identidad.
Cómo funciona msDS-KeyCredentialLink
Almacenamiento legítimo de key credentials
msDS-KeyCredentialLink almacena datos de key credential en un objeto de Active Directory. Microsoft Open Specifications describe KEYCREDENTIALLINK_BLOB como la estructura almacenada en la parte binaria del atributo DN-Binary msDS-KeyCredentialLink. Microsoft también documenta restricciones para agregar valores en objetos de equipo, incluyendo que la parte binaria debe ser un KEYCREDENTIALLINK_BLOB bien formado, que el uso debe ser KEY_USAGE_NGC y que el origen debe ser KEY_SOURCE_AD para esa operación documentada sobre cuentas de equipo.
Esa especificación sobre objetos de equipo no debe generalizarse a todos los escenarios sobre objetos de usuario. Para objetos de usuario, la fuente operativa más clara es la documentación de Windows Hello for Business: después de que un usuario aprovisiona una credencial de Windows Hello for Business en ciertos entornos híbridos, la clave pública del usuario puede sincronizarse hacia AD y escribirse en msDS-KeyCredentialLink. La guía de soporte de Microsoft también proporciona un script para enumerar objetos de usuario con valores no nulos de msDS-KeyCredentialLink y extraer campos como Source, Usage, DeviceID y KeyID.
Ruta de autenticación Key Trust
El lado de autenticación se basa en criptografía de clave pública. RFC 4556 define PKINIT como criptografía de clave pública para el intercambio inicial de autenticación Kerberos. La documentación PKCA de Microsoft describe cómo Windows implementa PKINIT y Key Trust. En un caso de Key Trust, el KDC puede buscar una cuenta por clave pública, y las implementaciones que usan Active Directory deben confirmar que la misma clave pública está presente en msDS-KeyCredentialLink.
En lenguaje defensivo práctico, el atributo le da a AD una forma de asociar una cuenta con material de clave que puede usarse para autenticación. La clave privada debe permanecer protegida en el dispositivo legítimo o en el contenedor de credenciales. La clave pública es lo que AD puede usar para validar que el intento de autenticación corresponde a una clave esperada. Si se agrega una clave no autorizada a una cuenta de alto valor, la cuenta obtiene una ruta adicional de autenticación que los defensores pueden no detectar durante revisiones normales de contraseñas.
Los resets de contraseña no son suficientes
Por eso Shadow Credentials es diferente de una compromisión basada en contraseña. Un reset de contraseña atiende una contraseña robada. No necesariamente elimina de la cuenta un valor key credential no autorizado. Microsoft documenta que el inicio de sesión y desbloqueo de Windows Hello for Business usan una clave o certificado, y que cambiar la contraseña de la cuenta de usuario no afecta ese comportamiento de inicio de sesión o desbloqueo. Para respuesta a incidentes, eso significa que la rotación de contraseña puede ser necesaria pero insuficiente si el objeto de cuenta aún contiene material de clave no autorizado.
Por qué Key Trust cambia el modelo de ataque
El endurecimiento tradicional de Active Directory suele centrarse en contraseñas, exposición NTLM, tickets de servicio Kerberos y pertenencia a grupos privilegiados. Esos temas siguen siendo importantes, pero Key Trust introduce una pregunta distinta: ¿quién puede modificar el objeto de cuenta o el material de clave asociado con la cuenta?
Si un usuario o servicio tiene permiso efectivo para escribir msDS-KeyCredentialLink, o puede cambiar la DACL o el propietario del objeto para obtener esa capacidad de escritura, el riesgo ya no es solo el inicio de sesión en la cuenta. Pasa a ser control del objeto de identidad. Windows Event 4662 destaca Write Property, WRITE_DAC y WRITE_OWNER como tipos de acceso importantes para monitorizar en objetos AD. Esos derechos no son automáticamente maliciosos, pero sobre usuarios privilegiados, cuentas de servicio, controladores de dominio u OU de administración merecen mucha más atención.
También por eso Shadow Credentials es un problema de ruta de ataque. El punto inicial puede ser un grupo de helpdesk delegado, una cuenta de servicio con derechos amplios sobre objetos, un permiso heredado en una OU o una delegación administrativa obsoleta. El estado final puede ser una ruta persistente de autenticación contra una cuenta privilegiada. Si el defensor revisa solo pertenencia a grupos, puede perder el permiso a nivel de objeto que hizo posible la ruta. El anidamiento de grupos también puede ocultar quién recibe efectivamente control delegado, así que revisa Anidamiento de Grupos AD: Rutas Ocultas a DA cuando intervienen permisos heredados.
Compáralo con Delegacion Kerberos: no restringida, restringida y RBCD. El abuso de delegación depende de configuraciones de delegación y relaciones de identidad de servicio. Shadow Credentials depende de material de clave y control de escritura sobre el objeto. Ambos temas son cercanos a Kerberos, pero no son el mismo modo de fallo y no deben mezclarse en un artículo genérico de Kerberos.
Prerrequisitos para el abuso
Un escenario de Shadow Credentials generalmente requiere todas estas condiciones:
| Condición | Significado defensivo |
|---|---|
| Una cuenta objetivo soporta una ruta relevante de autenticación basada en claves | El entorno usa o acepta Key Trust, autenticación respaldada por certificados o patrones de Windows Hello for Business que dependen de validación de clave pública. |
| Un principal no autorizado puede agregar o preservar material key credential | El permiso peligroso puede ser escritura directa sobre el atributo o control más amplio del objeto que permite llegar a esa escritura. |
| El atacante controla la clave privada correspondiente | AD almacena el lado público. La autenticación solo funciona si el cliente puede probar posesión de la clave privada correspondiente. |
| La actividad no se detecta ni se remedia | El valor permanece en el objeto y puede sobrevivir a una limpieza limitada a contraseñas. |
Lo que no es una vulnerabilidad por sí mismo
Estos prerrequisitos deben leerse con cuidado. La presencia de Windows Hello for Business no significa que el entorno sea vulnerable por sí misma. La presencia de msDS-KeyCredentialLink no significa compromiso por sí misma. El riesgo aparece cuando los permisos del objeto de cuenta, el inventario de key credentials y la telemetría de autenticación muestran que se agregó o se está usando una key credential inesperada.
Matiz sobre objetos de equipo
Los objetos de equipo merecen una nota aparte. Microsoft documenta domain-joined device public key authentication y explica que los dispositivos Windows modernos pueden aprovisionar una clave pública vinculada a su cuenta de equipo cuando lo soporta un controlador de dominio Windows Server 2016 o posterior. Eso significa que los defensores deben esperar material de clave legítimo en algunas cuentas de equipo. El control no es cero key credentials en todas partes. El control es propiedad correcta, mapeo esperado de dispositivos y capacidad de escritura restringida.
Matiz sobre cuentas privilegiadas
Las cuentas privilegiadas requieren un estándar más estricto. La guía de Microsoft sobre dual enrollment de Windows Hello for Business describe permisos de Key Admins sobre msDS-KeyCredentialLink y consideraciones de AdminSDHolder para usuarios y grupos privilegiados protegidos. Es una señal fuerte para defensores: cualquier workflow que permita intencionalmente inicio de sesión basado en claves para identidades privilegiadas debe estar documentado, acotado y monitorizado, porque toca la misma superficie de control que un atacante intentaría abusar.
La cadena de ataque
Un modelo defensivo seguro de la cadena de ataque se ve así:
| Etapa | Qué ocurre | Qué deben verificar los defensores |
|---|---|---|
| 1. Descubrimiento de permisos | El atacante identifica una cuenta u OU donde puede afectar atributos o el descriptor de seguridad del objeto objetivo. | Revisar permisos efectivos sobre usuarios de alto valor, cuentas de equipo, cuentas de servicio y OU de administración. |
| 2. Agregado de key credential | Se agrega un valor key credential inesperado a msDS-KeyCredentialLink. | Monitorizar Event 5136 para el LDAP display name msDS-KeyCredentialLink, especialmente operaciones Value Added. |
| 3. Autenticación basada en claves | El atacante intenta autenticarse con la clave privada correspondiente a la clave pública agregada. | Correlacionar eventos 4768, patrones de preautenticación PKINIT o tipo smart card, hosts origen y sensibilidad de la cuenta. |
| 4. Movimiento lateral o persistencia | La cuenta se usa para acceso, escalada o persistencia mientras una rotación de contraseña por sí sola puede no eliminar la ruta por clave. | Eliminar key credentials no autorizadas, corregir permisos del objeto y validar que no continúa autenticación basada en claves inesperada. |
El artículo no proporciona intencionalmente comandos de explotación específicos de herramientas. Los defensores no necesitan una ruta de explotación copiable para entender el fallo de control. El punto clave es que una modificación de objeto de directorio puede crear una ruta de autenticación que la higiene normal de contraseñas no elimina.
Esta cadena también explica por qué Shadow Credentials suele aparecer junto a otros riesgos AD. Una cuenta privilegiada obsoleta, una ACL heredada peligrosa o un modelo de delegación débil pueden crear las condiciones para la escritura de key credential. Para exposición de cuentas, consulta Cuentas Obsoletas y Sobreprivilegiadas en AD. Para contexto de persistencia Kerberos, compara con la mecánica diferente de Ataque Golden Ticket — Deteccion & Remediacion.
Detección
La detección de Shadow Credentials debe ser basada en correlación. Ningún evento Windows aislado prueba la técnica completa. Una detección útil combina evidencia de modificación de directorio, contexto de permisos sobre objetos, comportamiento de autenticación e inventario legítimo de Windows Hello for Business.
| Señal | Fuente | Qué puede probar | Limitación |
|---|---|---|---|
Valor msDS-KeyCredentialLink agregado o cambiado | Event 5136, Directory Service Changes | El atributo del objeto cambió, y el evento puede exponer LDAP display name, tipo de operación, DN del objeto y correlation ID. | No prueba que el cambio sea malicioso. Un enrollment WHfB o flujos de dispositivo pueden ser legítimos. |
| Escritura sobre objetos sensibles | Event 4662, SACL en objetos AD | Un principal realizó o intentó operaciones como Write Property, WRITE_DAC o WRITE_OWNER sobre objetos o propiedades monitorizadas. | Requiere auditoría y cobertura SACL correctas. Sin SACLs, la evidencia puede faltar. |
| Solicitud de TGT con preautenticación de estilo clave pública | Event 4768 en controladores de dominio | Se solicitó un TGT; el evento expone el tipo de preautenticación y campos relacionados con certificados en escenarios relevantes. | Es telemetría de autenticación, no prueba de que se agregó una clave maliciosa. Correlacionar con 5136/4662 y contexto de cuenta. |
| Inventario de key credentials no nulas | Consulta AD o parsing al estilo soporte Microsoft | Qué usuarios tienen valores msDS-KeyCredentialLink y qué muestran campos como source, usage, DeviceID y KeyID. | El inventario debe compararse con registros conocidos de WHfB/FIDO/enrollment de dispositivos. |
| Permisos efectivos inesperados | Revisión ACL AD | Qué usuarios, grupos o servicios pueden escribir el atributo o cambiar la seguridad del objeto. | Los hallazgos de permisos son exposición, no evidencia de explotación. |
Telemetría de modificación de directorio
Para 5136, Microsoft recomienda monitorizar el campo LDAP Display Name al seguir modificaciones de un atributo AD específico. Para este tema, el nombre relevante es msDS-KeyCredentialLink. Prioriza eventos Value Added, luego correlaciona por DN del objeto, cuenta que realizó el cambio, estación origen cuando esté disponible y operaciones de directorio cercanas con el mismo correlation ID.
Para 4662, prioriza usuarios de alto valor, grupos privilegiados, OU de administración, cuentas de servicio y objetos de equipo que representen infraestructura sensible. Microsoft destaca tipos de acceso como Write Property, WRITE_DAC y WRITE_OWNER como importantes de monitorizar. Para una búsqueda de Shadow Credentials, son especialmente relevantes cuando implican un objeto de identidad privilegiado o un property GUID mapeado a msDS-KeyCredentialLink.
Correlación de autenticación
Para 4768, trata el evento como contexto de autenticación. Microsoft documenta que 4768 se genera cuando el KDC emite un TGT y que el evento incluye un campo Pre-Authentication Type. Los tipos asociados con autenticación smart card o de clave pública pueden ayudar a identificar patrones de autenticación basada en claves, pero deben correlacionarse con cambios de directorio y comportamiento esperado de inicio de sesión. Si una cuenta privilegiada muestra de pronto autenticación basada en claves después de una modificación inesperada del atributo, la historia combinada es mucho más fuerte que cualquiera de los eventos por separado.
Preguntas de inventario
Una búsqueda práctica debe responder estas preguntas:
- ¿Qué usuarios privilegiados, cuentas de servicio y cuentas de equipo tienen valores no nulos de
msDS-KeyCredentialLink? - ¿Son valores esperados para una implementación documentada de Windows Hello for Business, FIDO o autenticación de dispositivos?
- ¿Cada entrada corresponde a un dispositivo conocido, usuario esperado, KeyID esperado y source esperado?
- ¿Quién puede escribir el atributo o cambiar la DACL o el propietario del objeto?
- ¿Se agregaron valores key credential poco antes de autenticación Kerberos inusual o actividad administrativa?
Para cobertura más amplia de eventos, usa Supervision Seguridad AD: Event IDs y SIEM como checklist complementaria, pero mantén específica la correlación de Shadow Credentials. La monitorización Kerberos genérica no basta.
Remediación
La remediación debe ser dirigida. Limpiar msDS-KeyCredentialLink a ciegas en todo el dominio puede romper escenarios legítimos de Windows Hello for Business o autenticación de dispositivos. El enfoque más seguro es validar propiedad, eliminar valores no autorizados y corregir los permisos que permitieron que el valor apareciera.
Inventario y triaje
Empieza por inventario. Enumera usuarios y equipos con valores no nulos de msDS-KeyCredentialLink, luego parsea los valores en campos como Source, Usage, DeviceID y KeyID cuando sea posible. La guía de soporte de Microsoft muestra este tipo de análisis para objetos de usuario y explica que el certificado coincidente debería encontrarse en el almacén personal de certificados del usuario en el equipo con el identificador de dispositivo correspondiente. En un entorno gestionado, ese inventario también debería compararse con registros de dispositivos Microsoft Entra, registros de enrollment de Windows Hello for Business y el proceso de acceso privilegiado.
Después separa lo esperado de lo inesperado. Los valores esperados deben mapearse a usuarios, dispositivos y diseños de autenticación conocidos. Los valores inesperados incluyen entradas en cuentas que no deberían usar autenticación basada en claves, entradas que no mapean a un dispositivo aprobado, entradas agregadas por un principal no aprobado, entradas que aparecen después de actividad administrativa sospechosa o valores encontrados en cuentas privilegiadas sin un proceso documentado de dual enrollment o workstation privilegiada.
Eliminar solo valores no autorizados
Para entradas confirmadas como no autorizadas, elimina del objeto el valor específico no autorizado. No dependas solo del reset de contraseña. El reset puede seguir siendo necesario si la cuenta también fue comprometida de otra forma, pero por sí solo no prueba que el material de autenticación basado en claves haya sido eliminado de AD.
Corregir la ruta de permisos
Después de limpiar valores, corrige permisos. Revisa derechos directos y heredados que permitan escribir msDS-KeyCredentialLink, escribir propiedades amplias del objeto, cambiar la DACL o cambiar el propietario del objeto. Elimina delegaciones amplias de cuentas privilegiadas, OU de administración, OU de cuentas de servicio y cuentas de equipo cuando no sean necesarias. Si un workflow de helpdesk o automatización necesita gestionar legítimamente enrollment de Windows Hello for Business, acótalo de forma estricta y monitorízalo explícitamente.
Para cuentas privilegiadas, revisa Key Admins y grupos relacionados. La documentación de Microsoft sobre dual enrollment describe permisos de Key Admins sobre msDS-KeyCredentialLink y consideraciones de AdminSDHolder para cuentas protegidas. Si se permite enrollment de Windows Hello for Business para cuentas privilegiadas, documenta qué dispositivos están aprobados, qué cuentas están permitidas y cómo se autorizan nuevos valores key credential. Si no está permitido, las cuentas privilegiadas no deberían acumular key credentials silenciosamente.
Finalmente, endurece el modelo operativo. Usa administración por niveles o aislamiento administrativo equivalente para que estaciones de menor confianza y grupos delegados amplios no puedan modificar objetos de identidad de alto valor. Mantén la administración de identidades privilegiadas separada de cuentas de productividad diaria. Revisa periódicamente rutas de ataque, porque este problema normalmente se debe a una cadena de derechos, no a una sola pertenencia obvia a grupo.
Validación después de la limpieza
La validación debe probar tanto la limpieza como la recuperación del control.
| Paso de validación | Criterio de éxito |
|---|---|
| Ejecutar de nuevo el inventario de key credentials | Solo permanecen valores msDS-KeyCredentialLink esperados, y cada uno mapea a un usuario, dispositivo, source, usage y KeyID documentado. |
| Revalidar permisos de objeto | Ningún principal no autorizado puede escribir el atributo, escribir propiedades amplias, cambiar DACL o cambiar propietario en cuentas de alto valor. |
| Revisar 5136 después de la limpieza | No ocurren operaciones Value Added inesperadas para msDS-KeyCredentialLink en cuentas privilegiadas o equipos sensibles. |
| Revisar 4662 después de la limpieza | La actividad Write Property y security descriptor en objetos monitorizados coincide con workflows admin aprobados. |
| Revisar 4768 después de la limpieza | La autenticación basada en claves para cuentas sensibles ocurre solo desde usuarios, dispositivos y escenarios esperados. |
| Probar flujos legítimos WHfB/FIDO | Los usuarios aprobados aún pueden iniciar sesión donde la organización depende intencionalmente de Key Trust. |
Si un incidente involucró una cuenta privilegiada, la validación también debe incluir revisión de actividad posterior. Revisa inicios de sesión administrativos, cambios de membresía de grupos, cambios de configuración de servicios, ediciones GPO, nuevos certificados y cualquier movimiento posterior que pudiera haber usado la identidad recuperada. Shadow Credentials puede ser el método de acceso, pero no necesariamente el objetivo final.
Cómo EtcSec detecta exposición relacionada
EtcSec no debería etiquetar este artículo con un tipo de vulnerabilidad inexacto si el catálogo no contiene una entrada directa para Shadow Credentials o msDS-KeyCredentialLink. La exposición relacionada aun así encaja con el modelo de auditoría de Active Directory de EtcSec: permisos peligrosos sobre objetos, exposición de cuentas privilegiadas, rutas ACL heredadas y brechas de monitorización alrededor de cambios de objetos AD.
En la práctica, una revisión EtcSec puede ayudar a identificar las condiciones que hacen viable este camino de ataque: principals con control excesivo de escritura sobre objetos de usuario o equipo, cuentas privilegiadas no aisladas, rutas ACL peligrosas hacia identidades administrativas y brechas de monitorización sobre cambios de directorio. Ese es el encuadre correcto. Shadow Credentials no es una debilidad Kerberos genérica; es una ruta de abuso de Key Trust creada por control de objetos.
Controles relacionados
Los controles de Shadow Credentials deben estar vinculados a la propiedad de identidades, no solo a la monitorización Kerberos.
| Control | Por qué importa |
|---|---|
Inventariar msDS-KeyCredentialLink en usuarios y equipos | Establece qué rutas de autenticación basadas en claves existen antes de un incidente. |
| Restringir acceso de escritura a atributos key credential | Impide que principals no autorizados agreguen nuevo material de autenticación. |
Monitorizar 5136 en msDS-KeyCredentialLink | Captura cambios a nivel de atributo cuando Directory Service Changes auditing y SACLs están configurados. |
| Monitorizar 4662 en objetos de identidad sensibles | Expone operaciones Write Property, DACL y ownership cuando existen SACLs. |
| Correlacionar 4768 con cambios de directorio | Ayuda a conectar autenticación basada en claves con modificaciones recientes de objetos. |
| Proteger cuentas privilegiadas con aislamiento administrativo | Reduce la probabilidad de que una compromisión de menor nivel pueda modificar objetos de identidad de alto valor. |
| Revisar Key Admins y comportamiento AdminSDHolder | Evita que rutas legítimas de administración WHfB se conviertan en rutas descontroladas de escritura de claves privilegiadas. |
Estos controles también respaldan endurecimiento AD más amplio. Si estás construyendo una revisión estructurada, combina este artículo con Auditar la seguridad de Active Directory: checklist práctica y prioriza primero objetos de identidad privilegiados y OU sensibles.
Referencias primarias
- Microsoft Learn: How Windows Hello for Business works
- Microsoft Open Specifications: MS-PKCA Key Trust
- Microsoft Open Specifications: MS-PKCA Introduction
- RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos
- Microsoft Open Specifications: MS-ADTS KEYCREDENTIALLINK_BLOB
- Microsoft Open Specifications: MS-ADTS msDS-KeyCredentialLink
- Microsoft Learn: Scripts to view certificate information in msDS-KeyCredentialLink
- Microsoft Learn: Event 5136, directory service object modified
- Microsoft Learn: Event 4662, operation performed on an object
- Microsoft Learn: Event 4768, Kerberos TGT requested
- Microsoft Learn: Domain-joined device public key authentication
- Microsoft Learn: Windows Hello for Business dual enrollment
