Términos sensibles en description de Active Directory: DA y admin

Los términos sensibles en description de Active Directory pueden revelar qué identidades merecen más atención, aunque el texto no contenga ninguna contraseña. Esta guía separa una revisión manual amplia de las etiquetas DA, admin y privileged de los cinco patrones implementados por etc-collector, y después explica cómo inventariar, limpiar y volver a comprobar cada descripción.

Qué revelan los términos sensibles en description de Active Directory

Una descripción como domain admin — backup operator expresa la finalidad de una cuenta. La inferencia de seguridad es que un lector podría utilizar esa información para preseleccionar posibles objetivos. No demuestra que la cuenta tenga realmente derechos administrativos. El ejemplo es ficticio: no es una observación en producción ni un ataque confirmado.

La misma distinción se aplica a DA, las notas de acceso de emergencia y las etiquetas de servicio. Un revisor podría interpretarlas como pistas sobre el rol de una identidad, pero la terminología local importa. admin puede referirse a tareas administrativas ajenas a TI. service client puede describir un departamento empresarial. Una descripción antigua puede mantenerse tras un cambio de funciones. Pregunte al propietario qué significa el texto antes de tratarlo como prueba de privilegios actuales.

Este artículo aborda la identificación de objetivos sin un secreto. Para contraseñas exactas, valores temporales o pistas sobre credenciales, siga el procedimiento de exposición de contraseñas, rotación e investigación en los campos de descripción de AD. Eliminar una etiqueta de rol y responder a una credencial expuesta son tareas distintas; descubrir un secreto cambia la respuesta necesaria.

Utilice un registro de revisión que distinga el texto observado, su interpretación y las pruebas que aún faltan. Por ejemplo, registre por separado «la descripción contiene privileged» y «el propietario confirmó que es una identidad administrativa». Mantenga abierto un caso sin resolver cuando se desconozca al propietario. No convierta una coincidencia léxica en una afirmación de que la cuenta está comprometida, elude la MFA o pertenece a Domain Admins.

Cómo funciona el acceso de lectura a description

La guía de Microsoft sobre cuentas y grupos privilegiados explica que las ACL suelen conceder a Authenticated Users acceso a la información general de los objetos. Su sección de permisos incluye explícitamente las propiedades generales de los usuarios. Esto respalda revisar la exposición de description con una identidad autenticada ordinaria, en lugar de suponer que solo los administradores pueden ver el campo. Autenticado no significa anónimo, y el permiso de lectura no implica permiso de edición.

La documentación histórica de atributos confidenciales también describe el acceso de lectura predeterminado a los atributos y el papel de READ_PROPERTY. El acceso real depende de los permisos efectivos del objeto. Un cambio local de permisos puede alterar lo que recibe un lector; verifique el despliegue en lugar de suponer que todos los objetos siguen los valores predeterminados.

La referencia del esquema de description identifica el atributo LDAP como description, con searchFlags=0x00000000 y systemFlags=0x00000010. Sus observaciones distinguen las descripciones de valor único de las clases gestionadas por SAM, incluidos los principales de seguridad, de los posibles valores múltiples en otras clases. Una revisión ampliada de objetos debe conservar esos valores, en lugar de suponer que toda descripción es una única cadena de una cuenta de usuario.

Para comparar la exposición de forma útil, elija un objeto conocido con el campo rellenado y realice la misma lectura delimitada con un lector ordinario y un revisor autorizado. Registre la identidad utilizada, el controlador de dominio, la base de búsqueda, la hora y cualquier error. Es un procedimiento de medición recomendado, no una afirmación de que esas pruebas se hayan realizado aquí. Guarde el material de revisión en una ubicación con acceso controlado; una tarea de limpieza no debe convertirse en una nueva lista de identidades sensibles ampliamente compartida.

Detección

Paso 1 — Inventariar las descripciones de usuario rellenadas

Los comandos siguientes están adaptados de Microsoft Learn, utilizando los parámetros documentados de Get-ADUser y Get-ADObject. No se han ejecutado contra un directorio para este artículo. Sustituya el DN y el servidor de ejemplo, utilice el módulo ActiveDirectory y seleccione el lector cuyo acceso quiera medir. Cada bloque es una medición independiente.

Empiece por las descripciones de usuario rellenadas:

Get-ADUser -LDAPFilter '(description=*)' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Solicitar -Properties description pide el atributo; no concede acceso. Trate una respuesta vacía como algo que debe investigarse. Compruebe el alcance, los permisos y si se devuelve un objeto conocido con el campo rellenado antes de declarar que el directorio no contiene descripciones sensibles.

Paso 2 — Separar las cuentas habilitadas y deshabilitadas

El ejemplo 5 de Get-ADUser de Microsoft utiliza la prueba LDAP bit a bit del bit 2 de userAccountControl para excluir las cuentas deshabilitadas. El inventario siguiente añade la condición de description y utiliza la forma NOT entre paréntesis documentada en la sintaxis de filtros de búsqueda LDAP de Microsoft:

Get-ADUser -LDAPFilter '(&(description=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Para la revisión complementaria, conserve la prueba de bit sin negación:

Get-ADUser -LDAPFilter '(&(description=*)(userAccountControl:1.2.840.113556.1.4.803:=2))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Esto separa el estado de la cuenta, no sus privilegios reales. Mantenga los objetos deshabilitados en la cola de limpieza y revise sus descripciones antes de cualquier reactivación prevista. No interprete el indicador de deshabilitación como prueba de que nadie puede leer el objeto o de que se han invalidado todas las sesiones históricas.

Paso 3 — Revisar las coincidencias léxicas y las etiquetas locales más amplias

Una preselección por subcadenas puede facilitar la primera revisión:

Get-ADUser -LDAPFilter '(|(description=*admin*)(description=*privileged*))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Esta preselección LDAP no equivale a las regex del colector. Revise el inventario original de descripciones rellenadas para buscar DA, break-glass, service, abreviaturas locales y términos en otros idiomas. De lo contrario, una consulta estrecha puede ocultar precisamente las etiquetas que el ejercicio manual pretende evaluar.

Los patrones exactos del colector se definen en accounts/privileged/domain-admin-description.go:35–41, con respecto a public/internal/audit/detectors/ad/:

(?i)domain\s*admin
(?i)enterprise\s*admin
(?i)administrator
(?i)admin\s*account
(?i)privileged

Los cinco ignoran mayúsculas y minúsculas. No tienen límites de palabra ni anclajes de inicio o fin, y \s* permite cero espacios en blanco. Por tanto, domainadmin coincide con el primer patrón y unprivileged con el último. Este último puede describir lo contrario de lo que espera el revisor; examine el valor completo en lugar de tratar la subcadena coincidente como un veredicto.

Estos resultados se desprenden de los patrones del código fuente; no son resultados comunicados de una auditoría en vivo. Mantenga tres conclusiones separadas: el texto coincidente, la finalidad confirmada por el propietario y el acceso verificado de forma independiente. Esa separación permite explicar un falso positivo sin fingir que el inventario ampliado está completo.

Paso 4 — Ampliar los objetos y supervisar los cambios

Si las descripciones de otras clases de objetos están dentro del alcance, utilice un inventario separado:

Get-ADObject -LDAPFilter '(description=*)' -Properties description -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Incluye cualquier clase de objeto devuelta que tenga una descripción rellenada. Es una ampliación manual más allá de los dos detectores de usuarios, no una prueba de que su cobertura automática incluya esos objetos. Conserve los valores múltiples de description cuando el esquema los permita.

Para supervisar la reintroducción de texto, la referencia de Microsoft del Event ID 5136 documenta las modificaciones del directorio. Configure Audit Directory Service Changes y una SACL Write adecuada para los objetos y atributos supervisados. Seleccione eventos donde AttributeLDAPDisplayName=description; examine el actor, el objeto y el valor. Cuando estén disponibles tanto los eventos Value Deleted como Value Added, correlaciónelos mediante OpCorrelationID y el mismo objeto y atributo.

La ausencia de un evento 5136 no demuestra que nadie leyera el texto anterior. Estos eventos de cambio y el inventario de postura responden a preguntas diferentes: qué hay escrito ahora y qué modificación auditada se produjo.

Remediación (Remediation)

Paso 1 — Acordar la información de sustitución

Para una divulgación que solo indique el rol, el procedimiento recomendado es trasladar el contexto sensible a un inventario o runbook con controles de acceso adecuados. Pida al propietario que apruebe lo que debe permanecer en AD. Una referencia opaca como Managed record INV-01234 puede conservar un punto de referencia operativo sin nombrar el privilegio ni el procedimiento de emergencia. El sistema referenciado también debe controlar el acceso; ocultar el nombre de un registro no constituye autorización.

Defina ejemplos de formulaciones aceptables e inaceptables con el equipo que aprovisiona las cuentas. Incluya las etiquetas locales que los controles automatizados no detectan. Revise las plantillas del servicio de asistencia, las instrucciones de traspaso y quién puede editar las descripciones para que la misma nota no se restaure en la siguiente tarea de mantenimiento. Tome una decisión por objeto en lugar de vaciar indiscriminadamente todas las descripciones rellenadas.

Paso 2 — Previsualizar y confirmar un cambio de campo

Estos ejemplos adaptan los parámetros Clear, Description, WhatIf y Confirm documentados de Set-ADUser. El ejemplo 4 vacía específicamente description. Elija la eliminación o la sustitución para la cuenta seleccionada.

Previsualice la eliminación:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -WhatIf

Tras la aprobación del propietario, solicite confirmación para la eliminación real:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -Confirm

Como alternativa, previsualice una sustitución neutra:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -WhatIf

Después confirme esa sustitución por separado:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -Confirm

-WhatIf no aplica el cambio ni demuestra la compatibilidad de las aplicaciones. Conserve la identidad del objeto seleccionado y la acción aprobada en el registro del cambio, y después verifique el valor escrito. Estos comandos son ejemplos documentados, no un script global de remediación ni un informe de limpieza completada.

Paso 3 — Evitar atajos de confidencialidad no admitidos

Si se consideran restricciones locales de lectura, encargue primero una revisión de permisos efectivos y dependencias. Las páginas de Microsoft sobre permisos y atributos confidenciales explican las ACE, la herencia y las comprobaciones de lectura; no validan una receta universal de ACL para este despliegue. Añadir un lector dedicado no elimina una concesión amplia ya existente. No retire globalmente el acceso de lectura de Authenticated Users sin auditar los consumidores y la delegación.

Prefiera almacenar la información operativa confidencial en un sistema de referencia protegido. Una extensión del esquema o un modelo de permisos rediseñado requiere su propio proyecto probado. Limpiar las descripciones reduce una pista; no sustituye la reducción de privilegios ni oculta todas las demás propiedades del directorio.

Validación después de la limpieza

Utilice la lectura Identity documentada de Get-ADObject para inspeccionar el objeto seleccionado después de la escritura autorizada:

Get-ADObject -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Properties description -Server 'dc01.corp.example'

El registro de aceptación recomendado debe indicar si el valor previsto está presente, si el propietario puede utilizar la referencia protegida y si las herramientas legítimas siguen funcionando. Vuelva a comprobar el inventario con el mismo lector y alcance utilizados inicialmente. Tenga en cuenta la replicación entre controladores de dominio al comparar servidores de directorio y conserve la identidad del DC para que las lecturas distintas puedan investigarse en lugar de descartarse.

Valide las etiquetas más amplias, además de las coincidencias regex. Un resultado automatizado sin hallazgos tras sustituir domain admin por DA dejaría intacta la pista para seleccionar objetivos. Por el contrario, una frase aprobada que contenga unprivileged puede seguir siendo una coincidencia léxica cuyo contexto sea benigno. Registre esa decisión explícitamente; no afirme que toda coincidencia restante representa un acceso peligroso ni que todo resultado negativo demuestra una formulación segura.

Los derechos reales necesitan una revisión independiente. La validación de la deriva del acceso privilegiado examina las pertenencias efectivas, las rutas de ACL delegadas y los derechos de replicación frente a una línea base. Utilice ese procedimiento cuando una descripción sugiera acceso administrativo. Cambiar la descripción en sí no demuestra que se hayan reducido los derechos de la cuenta.

Por último, verifique la configuración de supervisión de cambios con un cambio de prueba aprobado y compruebe que los datos 5136 esperados lleguen al proceso de revisión. Revise cualquier nueva formulación sensible con su propietario. Si se descubre un secreto durante la validación, derívelo al procedimiento de exposición de credenciales en lugar de cerrar el caso tras editar el campo. Defina el responsable de la próxima revisión para que las descripciones de las identidades deshabilitadas también se comprueben antes de su reactivación.

Cómo detecta EtcSec este problema

Las dos implementaciones de etc-collector revisadas para este artículo operan sobre data.Users y la cadena Description recopilada. Ambas omiten las descripciones vacías y se detienen tras el primer patrón reconocido para un usuario. Utilizan las mismas cinco regex, aunque seleccionan poblaciones opuestas según el estado de la cuenta.

El predicado de las cuentas habilitadas está en las líneas 47–61 del primer archivo; el de las cuentas deshabilitadas, en las líneas 43–57 del segundo. Sus hallazgos cuentan los usuarios afectados. Solo se adjuntan entidades de detalle cuando IncludeDetails es true y hay al menos un usuario afectado, en las líneas 72–74 y 68–70 respectivamente.

Ninguno de los dos Detect() lee memberOf, verifica derechos reales, busca contraseñas ni analiza eventos del directorio. Por tanto, el identificador DOMAIN_ADMIN_IN_DESCRIPTION describe una comprobación de exposición léxica, no una prueba de que un usuario afectado pertenezca a Domain Admins. Los valores High/Low son clasificaciones de política del colector, no resultados de ataques medidos ni valoraciones de severidad de Microsoft.

Trate estos hallazgos como entradas para la revisión: inspeccione el texto, confirme la finalidad con el propietario, limpie el campo aprobado y vuelva a ejecutar la comprobación delimitada. Un hallazgo léxico negativo no demuestra la ausencia de etiquetas sensibles, y eliminar una etiqueta no demuestra la eliminación de privilegios.