Honeytokens y cuentas señuelo en Active Directory y Entra ID: detectar al atacante antes de que se mueva

Un atacante que acaba de entrar en una red Windows hace siempre lo mismo antes de moverse: pregunta al directorio. Quiénes son los administradores, qué cuentas tienen contraseñas antiguas, cuáles llevan asociado un nombre de servicio Kerberos y desde qué equipos inician sesión. Todo eso lo responde Active Directory a un usuario autenticado sin privilegios especiales y, en la mayoría de los entornos, sin que salte ninguna alarma, porque preguntar es una operación legítima que ocurre millones de veces al día.

Si entre esas respuestas se cuela una cuenta que parece valiosa pero no tiene ningún uso legítimo, toda interacción con ella es, por definición, actividad hostil. Esa es la idea del honeytoken, del que la cuenta señuelo es el caso más común: un activo creado para engañar cuya única función es delatar a quien lo toca. Este artículo explica qué señuelos funcionan en Active Directory y Entra ID, cómo se construyen para que pasen por auténticos, qué herramientas nativas los vigilan y dónde encajan en un programa de detección.

¿Qué es un honeytoken y por qué detecta lo que otras reglas no ven?

MITRE D3FEND cataloga la técnica como credencial señuelo (D3-DUC): una credencial creada con el fin de engañar a un adversario, acompañada de una analítica que detecta cuándo alguien la usa. La definición es corta porque el mecanismo es simple. Una regla de detección convencional busca anomalías entre millones de eventos legítimos, y por eso genera falsos positivos y exige ajuste continuo. Un señuelo invierte el problema: el activo no tiene tráfico legítimo, así que la regla es "un solo evento sobre este objeto" y la tasa de falsos positivos tiende a cero. En el glosario explicamos la diferencia con un honeypot completo.

Ese cambio de lógica tiene dos consecuencias prácticas. La primera es el coste: una cuenta de dominio y unas líneas de correlación en el SIEM cuestan una fracción de lo que cuesta afinar una detección de comportamiento. La segunda es la fidelidad: cuando el señuelo salta, el evento trae el nombre de la cuenta que lo tocó y la dirección del equipo desde el que se produjo el acceso. Eso convierte una sospecha en un punto de partida concreto para la respuesta.

¿Qué busca un atacante en Active Directory y dónde colocar el señuelo?

Sean Metcalf, autor de referencia en seguridad de Active Directory, describe la secuencia de reconocimiento que sigue un atacante con derechos de usuario normal. Primero identifica cuentas privilegiadas, a menudo mediante el atributo AdminCount, que el directorio pone a 1 en toda cuenta que haya pasado por un grupo protegido. Después filtra las que tienen contraseñas antiguas. Luego busca cuentas privilegiadas con un nombre de servicio Kerberos (SPN), porque cualquier usuario del dominio puede pedir un tique de servicio para ese SPN y tratar de romper la contraseña sin conexión. Por último, consulta sesiones de red para saber en qué estaciones de trabajo se usan las cuentas de administración.

Cada uno de esos pasos es una pregunta al directorio, y cada pregunta admite una respuesta preparada. El cebo se coloca justo donde el atacante va a mirar: una cuenta con AdminCount a 1, con contraseña de hace años y con un SPN que apunta a un servicio que no existe. Este mismo reconocimiento es el que analizamos al explicar cómo el tiering de Active Directory impide que un portátil comprometido llegue al dominio; el señuelo añade una capa de detección sobre esa arquitectura de contención.

Cuatro cuentas señuelo y honeytokens que funcionan en Active Directory y fuera de él

Una cuenta con SPN falso para cazar Kerberoasting

Es el señuelo más rentable en un dominio Windows. Metcalf lo documentó en 2017: se crea una cuenta de usuario, se le asigna un SPN único que no corresponde a ningún servicio existente (un nombre de instancia SQL inventado, por ejemplo) y se marca AdminCount a 1 para que parezca privilegiada, sin meterla en ningún grupo privilegiado (el atributo es solo cosmético) y con una contraseña larga y aleatoria que no se pueda romper sin conexión.

Como el servicio no existe, ningún proceso de negocio pedirá un tique para él. Si un controlador de dominio registra el evento 4769 con ese nombre de servicio, alguien está haciendo Kerberoasting, y el campo de dirección de cliente muestra desde dónde llegó la petición.

La ventaja frente a la detección genérica de Kerberoasting es la certeza. Filtrar los 4769 por cifrado RC4 (tipo 0x17) reduce millones de eventos a unos cientos o miles, pero sigue exigiendo criterio para separar lo raro de lo malicioso. Con el SPN falso la pregunta desaparece: una sola petición, descontados los escáneres autorizados que ya tengas identificados, basta para escalar el incidente.

Una cuenta que nunca inicia sesión para cazar password spraying

El rociado de contraseñas (password spraying) prueba una misma contraseña contra todos los usuarios y descansa antes de probar la siguiente para no bloquear cuentas. Detectarlo por correlación de fallos de inicio de sesión es ruidoso: la gente se equivoca al teclear. TrustedSec propone la alternativa en Active Directory y en Entra ID: una cuenta de una persona que nunca ha trabajado en la organización. Ningún empleado va a intentar entrar con ella, así que casi todo intento, fallido o no, procede de alguien que recorre la lista de usuarios.

Dos detalles operativos importan. En Active Directory, cuando el rociado se hace por Kerberos, el fallo puede no aparecer como 4625; hay que auditar también el 4771 (fallo de preautenticación Kerberos). En Entra ID, el registro de inicios de sesión de esa cuenta muestra el código 50126 cuando la contraseña es incorrecta. Si es correcta y la cuenta tiene MFA exigido pero ningún método registrado, aparece el 50079; si no tiene MFA exigido, ese mismo intento queda como inicio de sesión correcto (código 0). Por eso la cuenta señuelo de Entra ID no debe tener licencias ni permisos. El registro aporta además la IP y la geolocalización de origen.

Credenciales señuelo en SYSVOL: la contraseña que nadie debería leer

El tercer tipo no es una cuenta sino un dato que parece una credencial. El mismo autor sugiere crear en SYSVOL, la carpeta compartida de los controladores de dominio, un directorio con nombre de GUID que no corresponda a ningún objeto de directiva de grupo auténtico, con una entrada de auditoría (SACL) sobre él. Dentro puede ir un fichero XML con una contraseña de preferencias de directiva de grupo inventada. Ningún proceso de negocio lee una directiva que no existe; quien la abra está buscando contraseñas almacenadas en SYSVOL, una técnica clásica de escalada de privilegios.

La contraseña falsa escrita en un atributo de la cuenta, que vemos más abajo, pertenece a la misma familia.

Canarytokens fuera del dominio: claves de AWS, ficheros y la página de inicio de sesión

Los señuelos no se limitan a Active Directory. Thinkst mantiene Canarytokens, un servicio gratuito que genera, entre otros, un par de claves de API de AWS auténticas, emitidas para que su uso dispare un aviso: se dejan en un repositorio privado o en el equipo de un desarrollador y, si alguien las usa contra la API de AWS, llega la alerta. El registro de actividad de AWS impone entre 2 y 30 minutos de retraso. Hay tokens equivalentes para documentos de Word y Excel, carpetas de red, configuraciones de Kubernetes y ficheros de configuración de MCP (Model Context Protocol, el estándar que conecta herramientas con modelos de IA).

Uno de ellos merece atención especial para quien administre Microsoft 365. El token de inicio de sesión de Entra ID se instala como una hoja de estilos en la personalización de marca del inquilino. Los navegadores la cargan al mostrar la página de inicio de sesión; si el sitio que la solicita no es un dominio de Microsoft, es que alguien está sirviendo una copia de tu página desde un servidor intermedio. Es una detección directa del secuestro de sesión por adversario en el medio (AiTM), que ningún control de contraseña ve porque el usuario teclea la contraseña correcta en la página falsa.

Cómo hacer que el señuelo parezca auténtico y qué lo delata

Un atacante con experiencia comprueba la cuenta antes de atacarla, y Metcalf enumera las pistas que busca: fecha de creación reciente, ningún inicio de sesión desde la creación, contraseña nunca cambiada, ausencia de una cuenta de usuario corriente asociada al supuesto administrador, y un SPN cuyo nombre de equipo no existe en el bosque. Si la fecha de creación, el último cambio de contraseña y el último inicio de sesión coinciden, la cuenta huele a trampa.

La cuenta privilegiada falsa tiene que envejecer como las demás. Reutiliza una cuenta antigua olvidada, vaciada de grupos y permisos, en lugar de crear una nueva; si hay que restablecer su contraseña para poder usarla, la fecha de cambio pasa a ser la de hoy y la cuenta necesitará meses hasta que esa antigüedad se parezca a la de las otras cuentas de servicio, así que cuanto antes se prepare, mejor.

Inicia sesión con ella de vez en cuando con una tarea programada, para que los atributos de último acceso tengan valores creíbles. Crea la cuenta de usuario corriente que acompañaría a un administrador. Y, sobre todo, no dejes que sea la única cuenta vulnerable en un directorio por lo demás impecable: si destaca demasiado, el atacante la evita.

Ese inicio de sesión periódico obliga a dos cosas: excluirlo de las reglas por equipo y hora, y no extenderlo a la cuenta del password spraying, que no debe iniciar sesión jamás.

Hay una línea que Metcalf marca sin matices: no uses como cebo una cuenta de Domain Admins con credenciales válidas y recuperables, porque si la protección de esa cuenta no es perfecta, el señuelo se convierte en la vía de compromiso del dominio.

Hay tres opciones seguras. La primera, una contraseña aleatoria imposible de adivinar: basta con activar la opción de inicio de sesión con tarjeta inteligente, que la fija automáticamente, y desactivarla después. Con esta opción no hay inicio de sesión periódico posible y la fecha de cambio de contraseña pasa a ser la de hoy, así que la cuenta debe dejarse envejecer y pasar por olvidada.

La segunda, una contraseña falsa escrita en un atributo como la descripción, vigilando los intentos de autenticación. La tercera, una contraseña real que solo sirve en equipos concretos mediante LogonWorkstations, con la precaución de que todos los equipos listados existan en el directorio: por defecto un usuario puede unir hasta 10 equipos al dominio, y un nombre de equipo inexistente en esa lista abre una vía de escalada, porque quien pueda unir un equipo con ese nombre podrá usar la cuenta. Las dos últimas opciones admiten la tarea programada; la primera, no.

Honeytokens en Defender for Identity y Defender XDR: qué vigilan ya

Microsoft Defender for Identity incluye la etiqueta Honeytoken para usuarios y dispositivos: una autenticación de una entidad etiquetada genera una alerta, y Microsoft documenta también una alerta por consulta LDAP sobre esas entidades (la variante por SAM-R se retiró en junio de 2024, y Microsoft remite a detecciones personalizadas con consultas de búsqueda avanzada). Se configura en el portal de Defender XDR, en Configuración > Identidades, y es la vía más rápida para una organización que ya tenga el sensor desplegado en sus controladores de dominio.

Dos cautelas. Si la cuenta etiquetada es la que inicia sesión con una tarea programada, cada ejecución generará la alerta, así que hay que excluirla o reservar la etiqueta para cuentas que no inician sesión nunca. Y lo que la etiqueta no cubre es la petición de tique 4769 ni la lectura de SYSVOL; para eso hay que mantener reglas propias en el SIEM y comprobar en la documentación de alertas qué cubre la etiqueta en tu versión.

Microsoft anunció además una capacidad de engaño en Defender XDR, con generación automática de cuentas y equipos señuelo y cebos plantados en los equipos de usuario. En el momento de escribir esto, la documentación de esa función redirige a la de interrupción automática de ataques, así que comprueba el estado efectivo de la capacidad en tu inquilino antes de contar con ella.

Sin licencias adicionales, bastan cuatro reglas en el SIEM: 4769 con el nombre de servicio del señuelo, 4625 o 4771 con el nombre de la cuenta que nunca inicia sesión (y 4776 si el password spraying va por NTLM contra un miembro del dominio), 4663 sobre la carpeta GUID de SYSVOL, y en Entra ID todo registro de inicio de sesión de la cuenta señuelo.

La tercera exige activar la auditoría de sistema de archivos en los controladores de dominio y excluir las cuentas de sistema, replicación y antivirus que sí leen SYSVOL.

La dificultad está en que esas fuentes lleguen al SIEM; sobre qué registros enviar y cuáles no ya hemos escrito con detalle.

Dónde encaja el engaño en un programa de detección

Un honeytoken no sustituye a la detección por comportamiento; la complementa allí donde esta es más débil: el reconocimiento interno con derechos de usuario. Tampoco sustituye a la reducción de superficie: si el dominio sigue lleno de cuentas con SPN y contraseñas de 2012, el cebo compite con objetivos legítimos igual de fáciles.

Su sitio natural es dentro de la ingeniería de detección, con el mismo ciclo que otra analítica: hipótesis, despliegue, prueba y mantenimiento. La prueba es la parte que más se descuida. Un ejercicio de Red Team que no tropiece con ningún señuelo, o que los identifique todos, es una señal de que los cebos no engañan. El mantenimiento es continuo: los atributos de las cuentas señuelo tienen que seguir pareciendo vivos, y las cuentas hay que revisarlas cuando cambia la política de contraseñas o se migra el dominio.

La respuesta cuando salta la alerta también hay que dejarla escrita. Un evento sobre un señuelo identifica una cuenta y un equipo comprometidos con alta confianza, así que la contención puede ser inmediata: aislar el equipo, revocar sesiones de la cuenta de origen y arrancar la investigación del acceso inicial y de cualquier movimiento lateral previo. En los servicios de threat hunting y SOC gestionado de Hard2bit Cybersecurity los señuelos son de las pocas fuentes que, una vez excluidos los orígenes legítimos, tratamos como positivo confirmado sin pasar por triaje.

Límites de los honeytokens

El engaño tiene límites claros. Un actor cuidadoso comprueba los atributos que hemos descrito y, si la cuenta no encaja, la deja pasar; entonces el señuelo no detecta, pero tampoco hace daño. Quien ya tiene credenciales de administrador no necesita reconocimiento y difícilmente tocará el cebo. Los tokens de terceros dependen de que su infraestructura reciba la llamada, con los retrasos que ello implique. Y un señuelo mal protegido añade riesgo en vez de quitarlo. Con esas cautelas, las cuentas y las reglas descritas se montan en una tarde, aunque llevar las fuentes al SIEM puede costar más; no tener señuelos cuesta no saber que el reconocimiento ya ha empezado.

Hard2bit acompaña a organizaciones desde 2013 en la detección y respuesta a intrusiones en entornos Microsoft, con certificación ENS de categoría ALTA y cinco normas ISO, entre ellas la 27001:2022.

Este análisis tiene finalidad divulgativa y defensiva y refleja la información disponible en su fecha de publicación; las funciones de Microsoft Defender y de los servicios de terceros citados pueden cambiar, así que verifica siempre los detalles en la documentación oficial. Las cuentas señuelo, reglas de detección y configuraciones descritas deben validarse en un entorno de pruebas y adaptarse a tu directorio antes de llevarlas a producción; un señuelo mal protegido puede convertirse en una vía de compromiso. No sustituyen a una evaluación específica de tu entorno. Si quieres revisar la detección en tu Active Directory o Entra ID, puedes hablar con el equipo de Hard2bit.