Cuota de cuentas de equipo en Active Directory (ms-DS-MachineAccountQuota): el valor predeterminado que permite a cualquier usuario añadir un equipo

Cuota de cuentas de equipo en Active Directory (ms-DS-MachineAccountQuota): lo básico

La cuota de cuentas de equipo en Active Directory —el atributo ms-DS-MachineAccountQuota, almacenado en el propio objeto de dominio— tiene un valor predeterminado de 10 en cada dominio. Esto significa que cualquier usuario de dominio autenticado, sin ningún derecho administrativo delegado, puede unir hasta diez nuevas cuentas de equipo al dominio nada más instalarlo. Esto es así desde que se introdujo el atributo con Windows 2000 Server, y sigue siendo el valor predeterminado en los dominios creados hoy en día, salvo que un administrador lo haya endurecido explícitamente.

Un ingeniero de Microsoft documentó este valor predeterminado sin rodeos en el blog TechNet de la propia empresa allá por 2005: «La mayoría de vosotros conocéis el límite de 10 veces que los usuarios autenticados pueden unir equipos a un dominio», describiendo ms-DS-MachineAccountQuota como la propiedad del objeto de dominio que lo controla, editable a través de ADSI Edit. La referencia actual de Microsoft sobre políticas de seguridad para el derecho de usuario asociado Agregar estaciones de trabajo al dominio (SeMachineAccountPrivilege) confirma la misma cifra desde el lado del privilegio: «Un usuario al que se le asigna este derecho puede agregar hasta 10 estaciones de trabajo al dominio», y en los controladores de dominio este derecho se otorga por defecto al grupo Usuarios autenticados.

Por qué el valor predeterminado no cuenta toda la historia

Existe una segunda vía, independiente de la cuota, que conviene conocer antes de «corregir» este ajuste: la propia documentación de Microsoft señala que «los usuarios también pueden unir un equipo a un dominio si tienen el permiso Create Computer Objects sobre una unidad organizativa (OU) o sobre el contenedor Computers», y que los usuarios con ese permiso delegado «pueden agregar un número ilimitado de dispositivos al dominio, tengan o no el derecho de usuario Agregar estaciones de trabajo al dominio». Poner la cuota a cero no afecta en nada a una cuenta que ya tiene los derechos delegados Create Computer objects sobre una OU — ambos mecanismos deben revisarse juntos, lo que explica por qué este ajuste sigue apareciendo en las revisiones de las configuraciones de seguridad de Active Directory más comunes, años después de documentarse por primera vez.

Por qué una cuenta de equipo por autoservicio es un punto de apoyo

Una cuenta de equipo no es un objeto trivial. Es un principal de seguridad de pleno derecho, con su propio SID y una contraseña elegida por quien la crea (o generada por una herramienta) — que por defecto se ubica en el contenedor CN=Computers, cuyo propietario es el creador y no los administradores del dominio. Por sí sola no lleva ningún privilegio especial. Lo que sí proporciona es una identidad unida al dominio y totalmente controlada por el atacante — el requisito previo que falta para varias técnicas de abuso de delegación ya cubiertas en otros artículos de este catálogo, especialmente el abuso de delegación restringida basada en recursos (RBCD) y la superficie de ataque más amplia de los objetos de equipo.

Crear esta cuenta no requiere más que un usuario de dominio estándar y una cuota superior a cero. Las herramientas públicas lo convierten en una operación de una sola línea, todas documentadas en referencias de la comunidad como la página sobre MachineAccountQuota de The Hacker Recipes:

# Impacket — creacion de cuenta de equipo via SAMR
addcomputer.py -computer-name 'PWN01$' -computer-pass 'P@ssw0rd123!' \
  -dc-host dc01.corp.local corp.local/lowpriv:'Password1'

# Powermad — mismo resultado via LDAP desde un host Windows unido al dominio
New-MachineAccount -MachineAccount PWN01 -Password (ConvertTo-SecureString 'P@ssw0rd123!' -AsPlainText -Force)

bloodyAD y Certipy account create exponen la misma primitiva mediante LDAP, para operadores que prefieren una única herramienta multiplataforma. Ninguna de ellas requiere privilegios elevados — solo el valor predeterminado de 10 en ms-DS-MachineAccountQuota.

La cadena de ataque: de una cuenta de equipo gratuita al abuso de delegación

Paso 1 — Confirmar que la cuota es explotable

Una consulta LDAP rápida, anónima o autenticada, contra el objeto de dominio revela el valor vigente:

ldapsearch -x -H ldap://dc01.corp.local -D 'corp\lowpriv' -w 'Password1' \
  -b 'DC=corp,DC=local' -s base '(objectClass=domain)' ms-DS-MachineAccountQuota

Si el valor devuelto es mayor que cero, y la cuenta que ejecuta la consulta no tiene ninguna otra restricción, la creación de cuentas de equipo por autoservicio está disponible.

Paso 2 — Crear una cuenta de equipo controlada por el atacante

Con cualquiera de las herramientas mostradas antes, el atacante consume una unidad de su propia cuota para crear una cuenta de máquina. Esa única acción produce un SID de máquina con una contraseña conocida — una identidad que no existía un instante antes y que los administradores del dominio no han aprovisionado, revisado ni aprobado.

Paso 3 — Encadenar hacia el abuso de delegación

La cuenta de equipo recién creada no es, por sí misma, privilegiada — pero se convierte en la identidad controlada a través de la cual pasan las cadenas de RBCD y de relay NTLM. En los escenarios de relay, se usan técnicas de coerción (por ejemplo, la autenticación forzada de tipo PetitPotam) para retransmitir la autenticación NTLM de una víctima hacia LDAP/LDAPS en un controlador de dominio; ntlmrelayx.py de Impacket puede entonces usar su opción --delegate-access para crear una cuenta de equipo durante esa sesión retransmitida y, en el mismo paso, configurar msDS-AllowedToActOnBehalfOfOtherIdentity en el objetivo retransmitido, de modo que la nueva cuenta de equipo pueda suplantar a usuarios arbitrarios frente a él mediante S4U2Self/S4U2Proxy — convirtiendo una única autenticación retransmitida en acceso RBCD permanente. La mecánica completa del propio RBCD, así como el conjunto más amplio de formas en que se abusa de los atributos y las ACL de un objeto de equipo, se cubren en los dos artículos enlazados más arriba; la cuota de cuentas de equipo es el ajuste que proporciona al atacante el objeto de equipo que esas cadenas necesitan en primer lugar.

Detección

# Valor actual de la cuota
Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota

# Objetos de equipo creados via la via de autoservicio por cuota (mS-DS-CreatorSID relleno)
Get-ADComputer -Filter * -Properties ms-DS-CreatorSID |
    Where-Object { $_.'ms-DS-CreatorSID' } |
    Select-Object Name, DistinguishedName, ms-DS-CreatorSID

Establecer una referencia para el aprovisionamiento legítimo

Las herramientas de aprovisionamiento legítimas suelen ejecutarse con cuentas de servicio dedicadas, uniendo equipos a una OU conocida según un calendario predecible. Cualquier evento 4741 en el que SubjectUserName sea una cuenta de usuario final estándar, o en el que el objeto de equipo resultante quede fuera de esa OU, merece revisión, sea cual sea el volumen.

Remediation

1. Desactivar la cuota poniéndola a cero en todo el dominio. Este es el cambio de mayor impacto:

   Set-ADDomain -Identity corp.local -Replace @{'ms-DS-MachineAccountQuota'='0'}
   

   Verifícalo con la consulta Get-ADObject de la sección Detección.

2. Restringir y reasignar el derecho «Agregar estaciones de trabajo al dominio». Según las propias recomendaciones de seguridad de Microsoft, retíralo del grupo Usuarios autenticados en la política predeterminada de controladores de dominio, y concede SeMachineAccountPrivilege únicamente a un grupo de aprovisionamiento dedicado. La cuota por sí sola no cierra esta puerta — el derecho de usuario es el segundo control, y las propias recomendaciones de Microsoft señalan que dejarlo en Usuarios autenticados constituye una «vulnerabilidad moderada».

3. Limitar y delegar Create Computer objects de forma restringida. Concede este permiso únicamente sobre una OU dedicada a equipos, únicamente a la cuenta o grupo que realmente aprovisiona las máquinas (cuenta de servicio de imagen, SCCM, Intune Hybrid Join) — nunca a Usuarios autenticados ni Usuarios del dominio. Este permiso delegado evita la cuota por completo: el alcance importa más que la cifra.

4. Vigilar y generar una alerta con el ID de evento 4741 combinado con un mS-DS-CreatorSID relleno, especialmente en objetos de equipo que caigan fuera de tu OU de aprovisionamiento esperada.

5. Auditar y revisar de nuevo tras cada migración o nuevo despliegue de dominio. ms-DS-MachineAccountQuota se define por objeto de dominio; un dominio recién promovido o migrado reintroduce el valor predeterminado de 10 salvo que se endurezca explícitamente de nuevo.

Verificar la corrección

Tras poner la cuota a cero y reasignar el derecho de usuario, confirma que el cambio realmente se mantiene intentando unir al dominio desde una cuenta de prueba estándar, no delegada — debe fallar con un error de acceso denegado. Vuelve a ejecutar la consulta Get-ADObject de la sección Detección para confirmar el valor almacenado, ya que el retraso de propagación de las GPO puede hacer que un cambio parezca aplicado antes de haber llegado a todos los controladores de dominio.

🚨 Peligro: los administradores del dominio, así como cualquier cuenta con delegación separada de Create Computer objects, nunca están limitados por la cuota. Ponerla a 0 es necesario, pero no suficiente — combina este cambio con los cambios de derecho de usuario y delegación anteriores.

Este ajuste es exactamente el tipo de comprobación de un único atributo que tiene su lugar en una auditoría de seguridad de Active Directory recurrente en lugar de una corrección puntual, ya que vuelve silenciosamente a su valor predeterminado en cualquier dominio recién creado o migrado.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec marca un ms-DS-MachineAccountQuota que queda por encima de cero como Cuota de cuentas de equipo elevada por encima del valor predeterminado, y rastrea por separado las condiciones de explotación como Abuso de la cuota de cuentas de equipo, correlacionando el valor de cuota vigente con hallazgos de delegación y de objetos de equipo como RBCD en objeto de equipo y Abuso de RBCD, de modo que la cadena que va de «cualquier usuario puede añadir un equipo» a «cualquier usuario puede suplantar a un principal privilegiado en un host objetivo» se muestra como una sola ruta de ataque en lugar de como cuatro hallazgos sin relación.