Patrones de nombres de cuentas Active Directory

Qué indican realmente los nombres de cuenta comunes

La expresión patrones de nombres de cuentas active directory describe una heurística de nomenclatura, no una prueba de contraseñas. Una cuenta habilitada llamada admin, test o temp merece una revisión de su propietario y exposición. Su nombre no revela su contraseña, no demuestra que sea débil ni establece que alguien la haya atacado. Esta distinción se deriva directamente de la implementación de PASSWORD_COMMON_PATTERNS en public/internal/audit/detectors/ad/password/common-patterns.go:26.

Un nombre genérico puede facilitar la inclusión de una identidad en una lista de posibles objetivos. Es una inferencia sobre la selección de candidatos, no una clasificación medida de las primeras elecciones de los atacantes. La antigua referencia de Microsoft sobre el cambio de nombre de Administrator describe un beneficio modesto al cambiar ese nombre conocido, junto con la limitación de su SID conocido. No valida una clasificación universal de admin, test y temp ni los quince patrones del colector.

Por tanto, la pregunta útil es: ¿qué hace esta identidad, quién es su responsable y qué controles protegen sus rutas reales de autenticación? Trate el hallazgo como una cola de revisión. Un nombre de servicio descriptivo puede facilitar operaciones legítimas; un nombre de aspecto personal también puede ocultar una gestión deficiente de credenciales. El detector no distingue estos casos porque examina nombres en lugar de secretos o actividad.

Cómo funciona el password spraying

La guía de Microsoft para clasificar ataques de password spraying describe un conjunto pequeño de contraseñas comunes probado en muchas cuentas. Esto difiere de probar repetidamente muchas contraseñas contra una sola identidad. La nomenclatura de cuentas concierne a la lista de objetivos; el password spraying concierne a los intentos de autenticación. Un inventario de nombres coincidentes establece lo primero, no lo segundo.

El manual de investigación de password spraying también distingue el compromiso de la contraseña del compromiso de la cuenta. Un atacante puede descubrir una contraseña correcta mientras la MFA impide el acceso. Los investigadores deben examinar las autenticaciones correctas e interrumpidas, los resultados de MFA y la actividad posterior, en lugar de interpretar cada fallo del inicio de sesión final como prueba de que la contraseña siguió siendo desconocida.

La cadena de ataque que debe investigarse

Una investigación defendible sigue la progresión documentada en esos manuales de Microsoft: identificar cuentas candidatas y rutas de autenticación, correlacionar intentos sospechosos, determinar si se aceptó una contraseña y examinar el acceso resultante. Los nombres genéricos pueden orientar el primer paso. No aportan pruebas para los restantes. Una actividad lenta y de baja intensidad puede mantenerse por debajo de los umbrales de bloqueo; la ausencia de bloqueo no permite descartarla automáticamente.

Para el mecanismo general, la enumeración de usuarios, la detección y los controles en ambos entornos, consulte nuestra guía de password spraying en Active Directory y Entra ID. Este artículo se centra en el predicado exacto de nomenclatura, sus suposiciones erróneas y las pruebas necesarias para resolver un hallazgo sobre nombres.

Ninguna lista de nombres contiene todos los objetivos de spraying. Revise identidades ajenas a estos patrones cuando la telemetría de autenticación lo justifique. A la inversa, no etiquete cada cuenta coincidente como comprometida: el proceso de clasificación de Microsoft exige explícitamente separar la actividad maliciosa de los falsos positivos.

Medir las cuentas y su política efectiva

1. Crear un inventario sin recopilar secretos

Los siguientes comandos son ejemplos documentados o adaptaciones de parámetros para un administrador autorizado. No se ejecutaron contra un dominio para este artículo. Utilice el módulo ActiveDirectory, los permisos de directorio adecuados y el contexto de dominio o servidor previsto. contoso.com y los nombres de cuenta son ilustrativos; verifique el destino antes de usar un comando de modificación.

Get-ADUser documenta el filtrado, la recuperación de cuentas habilitadas y la solicitud de propiedades adicionales. Este filtro defensivo adapta esas capacidades a los trece nombres completos, una subcadena y un sufijo del colector. La lista procede del detector, no de un ejemplo de Microsoft que avale esos nombres como prueba de contraseñas débiles.

Get-ADUser -Filter 'Enabled -eq $true -and (SamAccountName -eq "admin" -or SamAccountName -eq "administrator" -or SamAccountName -eq "test" -or SamAccountName -eq "user" -or SamAccountName -eq "guest" -or SamAccountName -eq "temp" -or SamAccountName -eq "default" -or SamAccountName -eq "support" -or SamAccountName -eq "service" -or SamAccountName -eq "backup" -or SamAccountName -eq "demo" -or SamAccountName -eq "sa" -or SamAccountName -eq "dba" -or SamAccountName -like "*password*" -or SamAccountName -like "*123")' -Properties DisplayName,Enabled

DisplayName facilita aquí la revisión humana. No participa en el detector. Una cuenta cuyo nombre para mostrar es Test pero cuyo sAMAccountName es alex.smith no queda seleccionada por el patrón test. En cambio, User123 coincide con el sufijo, aunque no coincida con la expresión de nombre completo user. Estos ejemplos siguen las reglas de coincidencia del código.

Registre el propietario, la finalidad de la cuenta, sus dependencias y la decisión de revisión junto con el inventario. Antes de comparar un recuento local con un resultado del colector, concilie el alcance del directorio, el momento de recopilación, el estado habilitado y el comportamiento de coincidencia. No suponga que la lista breve de nombres de un hallazgo representa toda su población.

2. Leer la política del dominio

Este comando adapta el ejemplo 3 de Get-ADDefaultDomainPasswordPolicy a un dominio ilustrativo:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com

Revise MinPasswordLength, ComplexityEnabled, PasswordHistoryCount, LockoutThreshold, LockoutDuration y LockoutObservationWindow. Son pruebas de política. El nombre de la cuenta no aporta ningún valor para ellas. Leer la política del dominio tampoco establece si un usuario seleccionado tiene un Password Settings Object resultante diferente.

3. Inventariar las políticas detalladas

Utilice el filtrado documentado por Get-ADFineGrainedPasswordPolicy para recuperar los objetos de política:

Get-ADFineGrainedPasswordPolicy -Filter *

Inspeccione AppliesTo y Precedence, además de la configuración real. La guía de Microsoft sobre políticas de contraseñas detalladas indica que estas políticas se aplican a objetos de usuario y grupos de seguridad globales. No se aplican directamente a una OU. Por tanto, ubicar una cuenta genérica en una OU administrativa no establece por sí solo una política efectiva de contraseñas más fuerte.

4. Comprobar la política resultante del usuario seleccionado

Este comando adapta el ejemplo de identidad de Get-ADUserResultantPasswordPolicy:

Get-ADUserResultantPasswordPolicy -Identity test

Este cmdlet recupera el PSO resultante del usuario. Un PSO asignado directamente al usuario tiene prioridad sobre los PSO heredados mediante grupos de seguridad globales. Si varios PSO se aplican directamente, gana entre ellos el valor de precedencia más bajo; los PSO vinculados a grupos solo se comparan cuando ninguno se aplica directamente. Si no se aplica ningún PSO, evalúe la política predeterminada del dominio. Un resultado de PSO vacío no mide la fortaleza de la contraseña.

Nuestra guía de seguridad de contraseñas de Active Directory examina otras seis dimensiones: indicadores de caducidad, debilidad de la política, indicadores de contraseña no requerida, secretos expuestos en descripciones, WDigest y NTLMv1, junto con FGPP y gestión de cuentas de servicio. Son distintas de este predicado de nomenclatura. No sustituya la revisión de esos controles por la desaparición de un hallazgo de nombres ni copie valores de demostración como referencia de seguridad.

Detección: correlacionar 4625, 4740 y 4771

Recopilar los sistemas y campos adecuados

Construya las pruebas en torno a la ruta de autenticación. El evento 4625 se registra en el equipo donde se produce el inicio de sesión fallido; puede ser un controlador de dominio, un servidor miembro o una estación de trabajo. Recopilar solo un DC no garantiza la cobertura de todos los inicios de sesión fallidos. Compruebe la cobertura de Audit Logon y Audit Account Lockout según las subcategorías documentadas del evento.

Para las cuentas de dominio, incluya los registros Security de los DC para el evento 4740, en Audit User Account Management, y el evento 4771, en Audit Kerberos Authentication Service. Microsoft documenta que 4771 aparece únicamente en DC y está ausente cuando la cuenta no requiere preautenticación Kerberos.

Interpretar con precisión los códigos de fallo

La referencia de supervisión de 4625 identifica 0xC000006A como una contraseña incorrecta o mal escrita, 0xC0000064 como un nombre de cuenta incorrecto o mal escrito y 0xC000006D como un nombre de usuario o información de autenticación incorrectos. Su documentación identifica 0xC0000234 como una cuenta bloqueada. Conserve Status y SubStatus; no reduzca la investigación a una sola etiqueta genérica de fallo.

Para 4771, 0x18 es KDC_ERR_PREAUTH_FAILED: información de preautenticación no válida, con una contraseña incorrecta documentada como causa. 0x6 es KDC_ERR_C_PRINCIPAL_UNKNOWN, que significa que no se encontró el cliente en la base de datos Kerberos. 0x12 es KDC_ERR_CLIENT_REVOKED, que significa que las credenciales del cliente han sido revocadas. No equipare automáticamente 0x12 solo con el bloqueo ni trate estos códigos como intercambiables con los campos de estado de 4625.

Estas distinciones ayudan a separar los intentos con nombres desconocidos de los intentos con contraseñas incorrectas y de las consecuencias del bloqueo. Siguen sin revelar la contraseña candidata. Una regla de correlación basada en estos eventos no puede demostrar que se envió un mismo secreto a todas las cuentas.

Correlacionar el comportamiento y comprobar la explicación

Un diseño editorial de detección consiste en agrupar fallos por ventana temporal y origen, contar cuentas objetivo distintas y unir esas identidades al inventario de nombres. Establezca una referencia local antes de elegir una ventana o un umbral de alerta. Es un diseño que debe implementar y validar, no una consulta copiada de Microsoft ni un umbral medido para su entorno.

Compare el patrón con los errores esperados de usuarios y los servicios que reintentan una credencial antigua. Amplíe la búsqueda cuando varíen los orígenes y examine después los inicios de sesión correctos o interrumpidos y la actividad posterior inusual. Los manuales de spraying de Microsoft respaldan la correlación de cronología, origen, cuenta y actividad posterior. Una campaña puede mantenerse por debajo del umbral de bloqueo, por lo que exigir 4740 dejaría una laguna de detección.

En un entorno híbrido, incluya los registros de inicio de sesión y MFA de Entra y los del proveedor de identidad federado cuando corresponda. El manual de investigación explica que la ubicación de los registros depende de si la autenticación es administrada o federada. Una contraseña aceptada seguida de MFA fallida merece investigación incluso si no hubo acceso final a la aplicación. Un informe de nombres de cuenta sin hallazgos no puede resolver ese incidente.

Corrección: resolver la finalidad, la exposición y los controles (Remediation)

1. Revisar cada identidad con su responsable

Utilice un registro de revisión para distinguir identidades humanas, compartidas, de prueba, de servicio, integradas y de recuperación. Esta clasificación es una recomendación operativa, no algo que calcule la regex. Pregunte qué sigue requiriendo la cuenta, quién puede usarla, qué rutas de autenticación la aceptan y qué depende de su nombre o credenciales actuales.

Priorice el acceso humano atribuible y documente excepciones, responsables y fechas de caducidad para necesidades temporales. Revise los privilegios por separado: support no establece permisos de asistencia técnica y backup no establece a qué recursos puede acceder la cuenta. El código de nomenclatura no incluye un predicado de pertenencia a grupos ni de privilegios.

Para las pruebas, la guía de Microsoft sobre entornos de prueba de Entra trata sobre tenants dedicados o recursos y registros de aplicaciones correctamente aislados. Es un procedimiento para aplicaciones Entra, no una receta de despliegue de AD nativo. Aplicar su principio de aislamiento a identidades de prueba AD es una recomendación de gobierno: defina un límite de pruebas y un ciclo de vida apropiados para su dominio.

2. Retirar cuentas innecesarias tras revisar las dependencias

Para una cuenta ordinaria confirmada como innecesaria, verifique primero con su responsable los servicios dependientes, tareas programadas, aplicaciones y mecanismos de recuperación. Después planifique una deshabilitación específica. Este comando adapta el ejemplo 1 de Disable-ADAccount a una identidad de prueba ilustrativa ya revisada:

Disable-ADAccount -Identity test

No introduzca el inventario de nombres en una operación masiva de deshabilitación. El filtro no permite saber si una identidad es esencial para la operación. Un cambio de nombre planificado es otra posible acción administrativa, después de comprobar quién consume el nombre actual. El siguiente comando utiliza los parámetros de identidad y SamAccountName documentados por Set-ADUser:

Set-ADUser -Identity test -SamAccountName app-validation

Esto cambia el nombre de cuenta SAM. No cambia la contraseña, no reduce permisos, no impone MFA ni demuestra que la cuenta ya no sea detectable. Elija nombres que aporten claridad operativa y responsabilidad; reducir el recuento de regex no justifica suficientemente un cambio de nombre.

3. Conservar la función de recuperación del Administrator integrado

Un Administrator habilitado coincide con el detector porque no existe ninguna excepción por SID ni por cuenta integrada. Determine qué cuenta está revisando antes de decidir retirarla. No deshabilite a ciegas el Administrator integrado del dominio porque aparezca en la lista de nombres.

La guía de Microsoft sobre el Administrator integrado reserva su uso para la construcción inicial y una posible recuperación ante desastres. La página retiró explícitamente su antigua recomendación de deshabilitación porque la recuperación de bosque utiliza esta cuenta, incluido el inicio de sesión sin un servidor de catálogo global. En su lugar describe restricciones y auditoría del uso, restablecimientos de contraseña y cambios de cuenta.

Aplique las restricciones mediante un plan de recuperación revisado y el alcance documentado. La página advierte contra vincular su GPO de restricciones al nivel de dominio, porque puede volver inutilizable Administrator durante la recuperación. No extienda las afirmaciones históricas de bloqueo de la antigua página de cambio de nombre de Administrator a una afirmación no verificada sobre todas las versiones y configuraciones de Windows.

4. Usar gMSA para servicios AD e identidades administradas para Azure

Para servicios Windows que usan usuarios de dominio ordinarios, evalúe una migración a gMSA donde se admita. La documentación de Microsoft sobre cuentas de servicio de Windows Server describe la gestión automática de contraseñas y una identidad de servicio compartida entre varios servidores. Revise la compatibilidad del servicio, los hosts autorizados para recuperar credenciales, los permisos de recursos y los SPN antes de migrar. Esta recomendación aborda la gestión de credenciales de servicio, no toda cuenta humana con un nombre coincidente.

Para cargas de trabajo Azure, la guía de Microsoft sobre cuentas de servicio en la nube favorece las identidades administradas cuando sea posible y las entidades de servicio cuando sea necesario, frente a cuentas de servicio Entra basadas en usuarios. Mantenga esta elección de identidad en la nube separada de un despliegue de gMSA AD.

Cuando una aplicación requiere realmente credenciales compartidas, la guía de Entra para compartir cuentas describe un SSO basado en contraseña que intermedia el acceso mediante identidades individuales. Los usuarios no necesitan recibir la contraseña compartida; los administradores pueden revocar el acceso, exigir MFA y revisar los registros de inicio de sesión. La rotación de contraseña depende del soporte de la aplicación. Es una opción específica de acceso a aplicaciones, no un remedio universal para inicios de sesión AD compartidos.

5. Verificar FGPP, bloqueo y MFA en las rutas reales

Seleccione la configuración de contraseñas y bloqueo según la población de cuentas y el riesgo, y verifique después la política resultante con los comandos de inventario anteriores. FGPP puede diferenciar políticas para usuarios y grupos de seguridad globales. No despliegue el ejemplo de Microsoft LockoutThreshold=0 solo porque aparezca en una demostración: la sintaxis de políticas y las recomendaciones de seguridad tienen finalidades distintas.

La referencia del umbral de bloqueo de cuentas describe el equilibrio entre resistencia a intentos de adivinación y denegación de servicio mediante bloqueos deliberados. Su análisis de la referencia Windows utiliza diez intentos no válidos como posible punto de partida, explícitamente sin un umbral universal. Revise conjuntamente el umbral, la duración, la ventana de restablecimiento, las operaciones de desbloqueo y la supervisión.

El bloqueo inteligente de Entra es un control distinto del bloqueo de AD DS. Distingue ubicaciones conocidas y desconocidas y realiza un seguimiento de hashes recientes de contraseñas incorrectas; el seguimiento de hashes no está disponible con autenticación de paso a través. Para PTA, Microsoft indica un umbral Entra inferior, un umbral AD DS al menos dos o tres veces mayor y una duración Entra más larga. Verifique su modo de autenticación y configuración real en lugar de copiar un ejemplo como regla universal.

Exija MFA en rutas expuestas compatibles y revise la autenticación heredada como recomienda el manual de investigación de spraying. Una política MFA de Entra no hace que las rutas tradicionales de autenticación AD requieran MFA automáticamente. Cuando la telemetría establezca el compromiso de una contraseña o cuenta, siga la respuesta a incidentes, incluidos cambios de credenciales y revocación adecuada de sesiones/tokens, en lugar de cerrar el caso después de cambiar el nombre de una cuenta.

Cómo detecta EtcSec este problema

El control de etc-collector es PASSWORD_COMMON_PATTERNS, categoría Password, gravedad High. Su Detect() comienza en public/internal/audit/detectors/ad/password/common-patterns.go:26; las quince expresiones exactas se declaran en las líneas 28–44:

(?i)^admin$
(?i)^administrator$
(?i)^test$
(?i)^user$
(?i)^guest$
(?i)^temp$
(?i)^default$
(?i)^support$
(?i)^service$
(?i)^backup$
(?i)^demo$
(?i)password
123$
(?i)^sa$
(?i)^dba$

La implementación recorre los usuarios recopilados y excluye únicamente las cuentas Disabled. Convierte SAMAccountName a minúsculas y comprueba estas expresiones. Trece coinciden con nombres completos; password coincide en cualquier posición y 123$ con el final. Por tanto, admin01, test1, temp-user y svc-sql no quedan seleccionados solo por esos nombres; resetPasswordHelp y User123 sí.

Añade una cuenta en la primera expresión coincidente e interrumpe el bucle interno. Una cuenta que coincide con varias expresiones solo contribuye una vez. No hay ninguna exención basada en SID/RID, OU, grupo privilegiado, finalidad de servicio o lista de permitidos en esta implementación.

Count incluye todos los usuarios habilitados coincidentes. Details.affectedAccountNames contiene como máximo diez nombres, incluso sin IncludeDetails. Por tanto, diez nombres mostrados no significan que solo existan diez cuentas coincidentes. AffectedEntities se añade cuando se solicitan detalles y el recuento es positivo; el hallazgo se devuelve incluso a cero.

El detector no lee displayName, ninguna contraseña ni ningún hash de contraseña. No mide la entropía de contraseñas, no realiza autenticación, no evalúa la política de bloqueo ni MFA y no inspecciona actividad para demostrar un intento o éxito de spraying. Su texto descriptivo sugiere riesgo de contraseñas predeterminadas, pero esas sugerencias no son predicados del código.

Validar el resultado

Repita el mismo inventario y las lecturas de política efectiva después de los cambios aprobados. Documente las excepciones conservadas y los requisitos de recuperación, y confirme con los responsables que los servicios y aplicaciones siguen funcionando. Revise los registros de autenticación pertinentes para detectar actividad sospechosa restante siguiendo la guía de investigación de Microsoft.

Cierre cada revisión con el resultado que realmente establece: identidad innecesaria retirada, dependencia migrada, política efectiva verificada o excepción conservada con justificación. La nomenclatura, la política de contraseñas, la aplicación del acceso y las pruebas de ataque responden a preguntas diferentes. Una revisión de nombres completada debe aclarar esas respuestas sin afirmar que una regex ha probado un secreto.