Contraseñas en descripciones de AD: detección y corrección

Las contraseñas en descripciones de AD parecen inofensivas porque se ven como simples notas operativas. En muchos entornos, sin embargo, terminan siendo un atajo para guardar contraseñas de onboarding, valores de reseteo para terceros, secretos de cuentas de servicio, comentarios de traspaso o recordatorios que nunca deberían existir en texto claro. En cuanto una contraseña cae en el atributo description, deja de ser una nota privada y pasa a ser un dato del directorio que puede consultarse, exportarse, sincronizarse y copiarse mucho después de que la tarea original haya terminado.

Eso es exactamente lo que convierte PASSWORD_IN_DESCRIPTION en un problema práctico. Un atacante no necesita romper un hash, hacer password spraying ni esperar a un clic de phishing si ya hay un secreto válido o fácil de adivinar dentro de LDAP. Incluso cuando la contraseña exacta ya no sirve, el texto alrededor suele revelar patrones de reseteo, convenciones de naming, huecos de ownership o malos hábitos operativos que facilitan el siguiente paso del ataque.

Además, este hallazgo rara vez aparece solo. Los entornos que toleran contraseñas en atributos del directorio suelen mostrar al mismo tiempo resets informales, identidades privilegiadas obsoletas, cuentas de servicio sin dueño claro y poca visibilidad sobre cambios de atributos. Por eso conviene tratarlo como un síntoma de un modelo operativo débil, no solo como un problema de higiene de contenido.

Contraseñas en descripciones de AD: qué significa este hallazgo

PASSWORD_IN_DESCRIPTION significa que uno o varios campos Descripción de Active Directory contienen material sensible relacionado con una contraseña o pistas claras sobre el secreto. Puede tratarse de la contraseña completa, de un valor temporal de incorporación, de una parte del secreto que facilita el guessing, de una nota que indica que la credencial no se ha rotado o de comentarios operativos del tipo password temporal configurada para el nuevo empleado.

En muchas organizaciones todo empieza con una excepción aparentemente razonable. El equipo de soporte resetea un usuario y deja el valor unas horas en la descripción. Un administrador anota que la contraseña de una cuenta de servicio no se cambió durante una transición. Un equipo de proyecto escribe los datos de acceso de un proveedor en el directorio porque es más rápido que actualizar el ticket. La intención es comodidad; el resultado es un secreto en texto claro en uno de los repositorios más replicados del entorno.

El impacto depende mucho del tipo de cuenta afectada. Una contraseña temporal en una cuenta de pruebas con poco valor ya es un fallo de seguridad, pero el riesgo crece de forma importante cuando la descripción pertenece a una cuenta de servicio, a un administrador, a una cuenta de emergencia o a una identidad con acceso a correo, VPN, administración remota o automatización.

Cómo funciona

Los atacantes explotan esta debilidad con enumeración estándar del directorio. Tras conseguir cualquier punto de apoyo inicial en el dominio, consultan usuarios, servicios y equipos con la descripción rellena y filtran cadenas que parezcan credenciales, notas de reset o comentarios administrativos. No hace falta ningún exploit. Con permisos de lectura LDAP y algo de método suele bastar.

Ejemplos típicos:

• Temp password: Winter2026!
• cuenta VPN creada, valor inicial enviado por teléfono
• svc_sql transferida al equipo B, contraseña sin cambios
• no deshabilitar, la copia de seguridad depende de esta cuenta, pass = ...
• usuario de nueva incorporación reseteado antes de llegar, cambio obligatorio al primer inicio

Aunque la contraseña exacta ya no sea válida, la nota sigue siendo útil para el atacante. Puede confirmar que la cuenta pertenece a una función sensible, que las contraseñas temporales siguen un patrón predecible, que la propiedad de una cuenta de servicio es confusa o que los equipos siguen tratando secretos fuera de los canales aprobados.

Los campos Descripción tampoco se quedan dentro de AD. A menudo terminan copiados en exportaciones de administración, conectores IAM, paneles de soporte, snapshots de auditoría, CMDB o herramientas de inventario. Eso amplía la exposición mucho más allá de quienes leen directamente el directorio.

Este punto importa porque el acceso inicial necesario para enumerar LDAP no tiene por qué ser sofisticado. Una cuenta de usuario obtenida por reutilización de contraseña, robo de sesión o una vía parecida a las descritas en Ataques NTLM Relay puede ser suficiente para empezar a buscar notas útiles. Si a continuación aparece un secreto de servicio o una cuenta sobreprivilegiada, el camino hacia un compromiso más profundo se acorta mucho.

Dónde aparece en entornos reales

La forma más útil de entender este problema es verlo como el subproducto de momentos operativos muy comunes. Los campos Descripción filtran contraseñas sobre todo allí donde los equipos trabajan con presión o no disponen de un proceso más seguro.

Onboarding y cuentas de terceros

Las contraseñas temporales aparecen con frecuencia en procesos de alta y cambio de rol. Se prepara una cuenta por adelantado, se genera un valor de reset y alguien lo escribe en la descripción mientras espera a que el usuario llame, llegue a la oficina o confirme la recepción. Si nadie tiene ownership claro sobre la limpieza posterior, la nota puede permanecer mucho tiempo tras el primer inicio de sesión.

Las cuentas de proveedores y terceros son aún más delicadas porque su ciclo de vida suele estar repartido entre RR. HH., compras, TI local y el equipo de proyecto. Cuando nadie controla el proceso completo, el campo Descripción se convierte en una libreta improvisada de accesos.

Resets del helpdesk y urgencias de soporte

Cuando un usuario pierde acceso justo antes de una reunión, soporte puede resetear la contraseña, dejar el valor en la descripción y pasar al siguiente ticket. En algunos equipos ese atajo termina normalizándose. El problema no es solo la contraseña concreta expuesta, sino la idea implícita de que AD es un sitio aceptable para dejar secretos durante la gestión operativa.

Traspasos de cuentas de servicio

Las cuentas de servicio son una fuente clásica de notas peligrosas porque cuesta rotarlas sin romper nada. Cuando cambia la responsabilidad entre equipos, la nota puede incluir la contraseña actual, una pista sobre la aplicación que la usa o un comentario de que se decidió no rotarla para evitar una caída. Eso combina los dos peores elementos: almacenamiento en claro y un secreto que nadie quiere tocar.

El riesgo aumenta aún más si esa cuenta aparece también en los escenarios descritos en Kerberoasting: ataques contra cuentas de servicio o si pertenece al conjunto de cuentas privilegiadas obsoletas en AD que nadie se atreve a deshabilitar porque quizá todavía dependan de algún proceso.

Cuentas privilegiadas y cuentas de emergencia

Las cuentas de emergencia deberían estar sometidas al mayor nivel de disciplina del entorno. En la práctica, a veces acumulan notas informales porque muy poca gente sabe cómo se usan. Comentarios como contraseña guardada en caja fuerte, cambiada el trimestre pasado o, peor aún, el propio valor, crean una vía directa hacia acceso de alto impacto.

Objetos equipo y notas de admin local

Algunos equipos guardan en la descripción de los equipos información de build o referencias sobre administración local. Aunque la intención sea puramente inventario, cualquier contraseña o pista de reutilización puede facilitar movimiento lateral, especialmente si el mismo secreto local se comparte en muchos sistemas.

El patrón siempre es el mismo: el campo Descripción termina sustituyendo a una bóveda, a un ticket o a un runbook. La debilidad es por tanto técnica y de proceso al mismo tiempo.

Cadena de ataque

Una cadena de ataque realista es muy simple:

1. El atacante compromete un equipo o una cuenta de bajo privilegio.
2. Enumera los objetos de AD con la descripción rellena.
3. Filtra palabras como password, pwd, pass, temp, reset, service, welcome, meses, estaciones o referencias a VPN y onboarding.
4. Valida las credenciales recuperadas contra correo, VPN, SMB, RDP, administración remota o aplicaciones de negocio.
5. A partir de ahí pivota hacia grupos privilegiados, delegaciones, caminos de servicio o reutilización de credenciales.

La fuerza de esta debilidad está en que reduce incertidumbre. Un ataque de credenciales normal parte con muchas preguntas: qué cuentas están activas, cuáles importan, a qué sistemas llegan, cómo se eligen las contraseñas y dónde hay procesos débiles. Las descripciones suelen responder a varias de esas preguntas de una sola vez.

Escenarios frecuentes:

• una nota de onboarding expone una contraseña temporal que sigue funcionando en Microsoft 365 y VPN porque nunca se forzó el cambio al primer login;
• la descripción de una cuenta de servicio revela tanto el secreto como el owner de la aplicación, lo que ayuda después en ingeniería social;
• una nota sobre una cuenta de emergencia confirma que está fuera de los controles habituales;
• una identidad privilegiada obsoleta conserva una referencia antigua a su contraseña y nunca se deshabilitó por miedo a romper dependencias.

La situación empeora si ya existen los patrones recogidos en Seguridad de contraseñas en Active Directory: resets informales, mal control del ciclo de vida, cuentas de servicio heredadas y ausencia de revisiones sistemáticas sobre dónde acaban los secretos.

Detección

La detección empieza por el alcance. No conviene limitarse a usuarios habilitados. Una revisión útil debe cubrir:

• usuarios habilitados;
• usuarios deshabilitados pero con uso reciente;
• cuentas admin y cuentas de emergencia;
• cuentas de servicio;
• cuentas de terceros y de onboarding;
• cuentas genéricas o compartidas;
• objetos equipo en los que se guarden notas operativas.

Un primer barrido de PowerShell suele encontrar la primera ola de exposición:

Get-ADUser -LDAPFilter '(description=*)' -Properties description, Enabled, PasswordLastSet, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, Description

Después conviene ampliar la búsqueda con patrones, no solo con la palabra password. En un entorno hispanohablante tiene sentido mezclar variantes en inglés y español:

$pattern = '(?i)(password|contrasena|clave|pwd|pass\s*=|temp|temporal|inicial|reset|bienvenida|verano|invierno|primavera|otono|vpn)'

Get-ADUser -LDAPFilter '(description=*)' -Properties description, Enabled, PasswordLastSet, LastLogonDate |
  Where-Object { $_.Description -match $pattern } |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, Description

Si también se usan descripciones en objetos equipo:

Get-ADComputer -LDAPFilter '(description=*)' -Properties description |
  Where-Object { $_.Description -match $pattern } |
  Select-Object Name, Description

La meta no es contar descripciones no vacías, sino separar notas operativas inocuas de entradas que indiquen manejo de secretos en texto claro. El triage debe buscar:

• una contraseña exacta o una candidata muy plausible;
• una referencia a un reset que todavía pueda ser válida;
• una pista sobre el formato del secreto;
• notas de ownership que indiquen falta de rotación durante mucho tiempo;
• referencias a sistemas sensibles como copias de seguridad, VPN, finanzas o administración de identidad.

Un modelo sencillo de priorización sería:

La detección también debe salir del directorio. Si el campo Descripción se sincroniza a otros sistemas, la exposición vive allí también. Hay que revisar:

• herramientas de IAM y aprovisionamiento;
• exportaciones del service desk;
• CMDB o bases de inventario;
• copias de seguridad y snapshots de auditoría;
• scripts que extraen datos de usuarios para administración.

También conviene comprobar si los cambios de atributos están monitorizados. Cuando el auditing de objetos de directorio está activado, eventos como 5136 pueden ayudar a identificar modificaciones del campo Descripción. Si se correlacionan con eventos de reset y con la guía de Monitorización de seguridad AD: eventos que importan, permiten ver no solo la exposición actual sino también el proceso que la vuelve a introducir.

Y cada hallazgo debería venir con preguntas de decisión:

• ¿la cuenta sigue habilitada?;
• ¿tiene privilegios o los hereda?;
• ¿la contraseña se rotó después de escribir la nota?;
• ¿la cuenta se autenticó recientemente y desde qué hosts?;
• ¿el mismo secreto podría haberse reutilizado en otro sistema?;
• ¿la nota revela un problema de proceso que afecta a otras cuentas gestionadas por el mismo equipo?

Sin esa capa de triage, se borra texto pero no se responde a la pregunta importante: si el secreto expuesto ya se utilizó o ya se propagó a otros sitios.

Remediation y pasos prioritarios

La remediación debe manejarse como un flujo de compromiso, no como un simple arreglo de formato. Si aparece una contraseña en una descripción, la suposición segura es que el secreto está expuesto y debe rotarse.

La respuesta mínima es:

1. eliminar la contraseña o la pista del campo Descripción;
2. resetear o rotar el secreto afectado;
3. revisar dónde más podría haberse reutilizado ese mismo valor;
4. investigar la actividad reciente de autenticación de la cuenta;
5. arreglar el proceso que llevó el secreto a AD.

En cuentas de usuario, eso suele implicar forzar un cambio de contraseña, revisar si la cuenta accedió recientemente a correo, VPN, escritorio remoto o SaaS, y comprobar si la nota también revelaba un patrón temporal reutilizado en otros casos. Si la cuenta es privilegiada, conviene revisar grupos, delegaciones y oportunidades de movimiento lateral abiertas durante la ventana de exposición.

En cuentas de servicio, la remediación es más delicada porque los equipos suelen retrasar la rotación por miedo a romper producción. La respuesta correcta no es dejar el secreto donde está, sino inventariar dependencias y rotar con cuidado. Eso incluye revisar:

• servicios Windows;
• tareas programadas;
• pools de IIS;
• scripts y jobs de automatización;
• conectores de aplicaciones y middleware;
• credenciales almacenadas en pipelines o ficheros de configuración.

Siempre que sea posible, conviene mover estas identidades a enfoques gestionados como gMSA en lugar de mantener un modelo que depende de secretos estáticos conocidos por varias personas.

Si el objeto afectado está obsoleto o no tiene ownership claro, contener puede significar deshabilitar primero y validar dependencias después. En muchos casos es más seguro que conservar una credencial dudosa solo porque nadie sabe con certeza quién la usa. Ese mismo problema de ownership aparece en Comparativa de herramientas de auditoría de seguridad AD.

La otra mitad de la remediación es de proceso. Los equipos necesitan una alternativa explícita a escribir secretos dentro de AD. Normalmente eso implica:

• una bóveda o un flujo aprobado para compartir contraseñas temporales;
• referencias de ticket en lugar de secretos en las notas del directorio;
• puntos de control de limpieza tras onboarding y resets de soporte;
• revisión de propietarios de cuentas de servicio durante los traspasos;
• límites sobre quién puede escribir notas en cuentas sensibles;
• formación clara para dejar establecido que un atributo de directorio no es un secret store.

Un control simple y útil consiste en revisar de forma recurrente las descripciones rellenadas y escalar de inmediato cualquier entrada con patrones plausibles de contraseña. Eso hace visible el problema antes del siguiente ciclo formal de auditoría.

Por último, borrar el texto no elimina la exposición. El valor puede haber sido leído, exportado, replicado o respaldado. Por eso la rotación y la validación de uso son obligatorias. Si la nota describía una contraseña reutilizada, el incidente puede extenderse desde AD hacia VPN, admins locales, aplicaciones de negocio o scripts que todavía confían en esa credencial.

Cómo lo detecta EtcSec

EtcSec identifica cuentas cuya descripción contiene material que parece una contraseña, notas de reset o texto operativo que apunta a manejo de secretos en claro. El hallazgo gana mucho valor cuando se correlaciona con privilegio, antigüedad de la contraseña, actividad reciente, falta de ownership y caminos de ataque que convertirían un único secreto recuperado en avance real para un atacante.

Ese contexto importa porque no todas las exposiciones tienen la misma urgencia. Una nota temporal en una cuenta deshabilitada y de poco valor sigue siendo un problema, pero no pesa igual que una cuenta de servicio activa ligada a infraestructura o una identidad privilegiada con permisos permanentes.

Conclusión

Las contraseñas guardadas en los campos Descripción son una pequeña comodidad para los equipos y un riesgo desproporcionado para la defensa. Exponen secretos en un directorio que los atacantes ya saben enumerar y suelen delatar debilidades más profundas en el ciclo de vida de cuentas, los procesos de soporte y la gestión de credenciales de servicio.

Por eso este hallazgo debe tratarse a la vez como exposición de secreto y como fallo de proceso: eliminar la nota, rotar la contraseña, revisar por dónde pudo circular ese valor y cerrar el flujo que permitió escribirla.

Lecturas relacionadas

• Seguridad de contraseñas en Active Directory
• Monitorización de seguridad AD: eventos que importan
• Cuentas privilegiadas obsoletas en AD
• Kerberoasting: ataques contra cuentas de servicio
• Ataques NTLM Relay
• Comparativa de herramientas de auditoría de seguridad AD
• Caminos de ataque de AD a Domain Admin
• Abuso de ACL y DCSync