Tim Beasley Consultor sénior de respuesta ante incidentes

Bienvenidos de nuevo a nuestro análisis sobre los grupos de Active Directory que, aunque no «parezcan» peligrosos, en realidad lo son. Como expliqué en nuestra primera entrega, los atacantes no necesitan tener privilegios de administrador de dominio para causar un daño real, y no siempre buscan grupos con ese tipo de privilegios elevados tan evidentes.

«Operadores de cuentas» es un grupo de AD que mucha gente subestima porque no incluye la palabra «admins». Precisamente por eso se pasa por alto con tanta frecuencia.

Una idea errónea muy extendida es que el grupo «Operadores de cuentas» no supone un riesgo grave, ya que se supone que sus miembros no pueden modificar grupos protegidos, como el de «Administradores de dominio».

Esa suposición es , en el mejor de los casos, incompleta y, en el peor, peligrosa.
Además, en determinadas circunstancias resulta falsa.

La cuestión principal no es que el grupo «Operadores de cuentas» sea un grupo administrativo directamente de «máximo nivel» (aunque lo tratamos como tal). El verdadero problema es que otorga un amplio control sobre las identidades en todo el dominio, y en Active Directory, las identidades equivalen a privilegios.


¿Qué pueden hacer realmente los operadores de cuentas?

De forma predeterminada, los miembros del grupo «Operadores de cuentas» pueden crear, modificar y eliminar objetos de usuario, de grupo y de equipo en gran parte del dominio. En muchos entornos, esto incluye la capacidad de:

  • Restablecer contraseñas
  • Activar o desactivar cuentas
  • Editar nombres de entidades de servicio (SPN)
  • Gestionar la pertenencia a grupos no protegidos
  • Crear nuevas cuentas de usuario

Se ha restringido deliberadamente a los operadores de cuentas la posibilidad de modificar directamente los grupos y cuentas protegidos controlados por AdminSDHolder, incluidos los administradores de dominio, los administradores de empresa, los administradores de esquema y el grupo «Administradores» integrado en los controladores de dominio.

Sin embargo, esas restricciones no eliminan las vías de ataque que un actor malintencionado experto puede utilizar tras comprometer a un miembro de Account Operators.

Ese es el punto clave que los defensores deben asimilar: «Account Operators» no es un rol de administrador delegado inofensivo.
Se trata de un amplificador de privilegios situado directamente sobre el plano de identidad.


¿Por qué el grupo de los «operadores de cuentas» se vuelve tan peligroso tan rápidamente?

Si un atacante consigue las credenciales de un operador de cuenta, no necesita añadirse al grupo «Administradores del dominio» para empezar a sacar provecho.

He visto cómo creaban usuarios controlados por los atacantes, restablecían contraseñas de cuentas privilegiadas sin protección, manipulaban indirectamente la pertenencia a grupos, añadían SPN para configurar ataques de «kerberoasting» y abusaban de la creación de objetos informáticos para llevar a cabo ataques de delegación, como la delegación restringida basada en recursos.

Esto es importante porque muchas de las vías de ataque más realistas contra las empresas no requieren acceder primero a los grupos más valiosos, los llamados «joyas de la corona». Solo necesitan las identidades adecuadas, los grupos delegados adecuados y las vías de autenticación adecuadas durante el tiempo justo para poder cambiar de objetivo.

En otras palabras, los «operadores de cuentas» proporcionan a un atacante acceso de escritura distribuido en toda la estructura de identidades. Eso suele ser más que suficiente para pasar de «sin muchos privilegios» a «te tengo en mis manos».


Posibles vías de abuso tras el compromiso de los operadores de cuentas

Una vía evidente es la creación de cuentas por la puerta trasera. Un atacante puede crear un nuevo usuario y, a continuación, incorporarlo a grupos con privilegios o semiprivilegiados que pueda controlar, incluidos grupos con vías de escalada ocultas que, a menudo, se supervisan con mucha menos rigurosidad que los «Domain Admins». Además, este enfoque le permite descubrir el anidamiento de grupos dentro de los grupos con privilegios, lo que facilita una mayor escalada y persistencia.

Otra vía habitual es la actividad de restablecimiento de contraseñas, ya sea de forma selectiva o masiva. Los operadores de cuentas pueden restablecer las contraseñas de la mayoría de los usuarios del dominio, incluidas las cuentas de servicio, las identidades de aplicaciones y los usuarios administrativos no protegidos. En manos de un actor malintencionado, esto supone un acceso operativo inmediato y una posible interrupción de la actividad empresarial.

Una tercera vía es el uso indebido de SPN y el «kerberoasting». Si un atacante puede modificar los atributos de una cuenta y añadir SPN, puede crear nuevos objetivos susceptibles de sufrir un «kerberoasting» o hacer que las cuentas existentes sean vulnerables sin que el «ataque» resulte evidente.

Una cuarta vía consiste en aprovechar cuentas que, aunque no están protegidas, siguen siendo valiosas. Muchas organizaciones siguen contando con administradores delegados, cuentas de servicio heredadas y grupos anidados que no están protegidos por AdminSDHolder. Restablecer las contraseñas o modificar los atributos de esos objetos puede ser suficiente para obtener privilegios superiores.

Y luego está uso indebido de una cuenta informática. Dado que los operadores de cuentas suelen poder crear objetos del sistema y controlar lo que crean, pueden facilitar ataques que impliquen MachineAccountQuota y la delegación con restricciones basadas en recursos. Esto abre la puerta a la suplantación de identidad y a la escalada de privilegios sin tener que acceder nunca directamente al grupo «Domain Admins».

¿Nos estamos divirtiendo ya?


Un matiz sobre AdminSDHolder que los defensores no deberían pasar por alto

Aquí es donde la conversación se vuelve aún más incómoda.

En teoría, los operadores de cuentas no deberían poder modificar grupos protegidos como «Administradores de dominio» o «Administradores de empresa».

En la práctica, esa protección no se aplica de forma continua. Se encarga de ello el proceso «Security Descriptor Propagator», conocido comúnmente como SDProp, que aplica la lista de control de acceso (ACL) de AdminSDHolder a los objetos protegidos en un ciclo periódico. De forma predeterminada, ese ciclo se ejecuta aproximadamente cada 60 minutos.

El intervalo predeterminado de 60 minutos de SDProp es importante. Entre una ejecución y otra, los «objetos protegidos» pueden desviarse temporalmente del descriptor de seguridad previsto. Si los permisos se han desviado, si los derechos heredados o delegados aún no se han corregido por completo, o si un objeto recién creado o modificado no ha sido vuelto a marcar, un atacante podría tener una oportunidad efímera de aprovechar esa brecha antes de que SDProp vuelva a aplicar la ACL protegida.

Esto significa que es posible que un atacante no necesite mantener una pertenencia persistente a un grupo protegido. Es posible que solo necesite tiempo suficiente dentro de ese intervalo predeterminado de 60 minutos para añadir un sujeto controlado, iniciar una sesión con privilegios, extraer secretos, crear cuentas de puerta trasera o establecer persistencia en otro lugar antes de que SDProp elimine las pruebas evidentes a nivel de ACL o de pertenencia. Incluso podría tener tiempo para restablecer una cuenta de administrador recién creada.

60 minutos es mucho tiempo para un ciberdelincuente con experiencia.

Esto supone un grave problema de detección para los responsables de la seguridad, ya que da lugar a la posibilidad de que se produzcan derechos de acceso privilegiados de muy corta duración, seguidos de actividades privilegiadas realizadas desde una cuenta que, cuando los investigadores la examinen posteriormente, quizá ya no parezca tener privilegios.

La conclusión clave es que la protección de AdminSDHolder es «eventualmente consistente», no en tiempo real, y que la programación predeterminada de SDProp de 60 minutos es la brecha que un atacante intenta aprovechar.


¿Qué deben supervisar los responsables de la seguridad para detectar el uso indebido por parte de los «operadores de cuentas»?

Si quieres detectar un uso indebido por parte de los operadores de cuentas, empieza por analizar la actividad relacionada con el ciclo de vida de las identidades. La creación de nuevas cuentas, la activación de cuentas, el restablecimiento de contraseñas y los cambios en las cuentas son señales clave cuando los lleva a cabo un miembro de este grupo. Entre los eventos relevantes se incluyen los códigos 4720, 4722, 4723, 4724 y 4738.

A continuación, vigila de cerca los cambios en la pertenencia a grupos, especialmente las incorporaciones a grupos delegados inusuales, grupos anidados o grupos con privilegios que rara vez se utilizan. En este contexto, son importantes eventos como el 4728, el 4732 y el 4756; además, en el escenario de «ventana corta», también debes correlacionar los patrones de incorporación y eliminación rápidas con los eventos 4729, 4733 y 4757.

También debes supervisar los cambios en los SPN y otras modificaciones de los atributos de los directorios. Evento 5136 es importante para situaciones inesperadas servicePrincipalName modificaciones, cambios en los atributos relacionados con la delegación, tales como msDS-AllowedToActOnBehalfOfOtherIdentity, así como otros cambios sospechosos en objetos recién creados o modificados.

Por último, establece una referencia de comportamiento.

  • ¿Cuántos usuarios suele crear al día un miembro del equipo de operadores de cuentas?
  • ¿Cuántos restablecimientos de contraseña suelen realizar?
  • ¿Quiénes son los destinatarios habituales?

Las detecciones de alta fiabilidad comienzan cuando se produce una desviación respecto a esa línea de referencia.


¿Qué se puede hacer al respecto?

La respuesta más adecuada es sencilla: vaciar el grupo.

Si no existe ninguna razón operativa válida para utilizar «Operadores de cuenta» (lo cual ocurre casi SIEMPRE), elimina los miembros y mantén el grupo vacío. Si aún así necesitas una administración delegada, utiliza la delegación personalizada en las unidades organizativas (OU) y los objetos específicos que realmente requieran gestión.

Si no es posible eliminar inmediatamente la pertenencia al grupo, trátala con mucha más cautela de lo que suelen hacer la mayoría de las organizaciones en la actualidad.

  • Aplicar la clasificación administrativa por niveles
  • Impedir el inicio de sesión interactivo en los controladores de dominio y los servidores críticos
  • Denegar el inicio de sesión local siempre que sea posible

También deberías reducir las posibilidades de que se haga un uso indebido de los objetos informáticos reforzando MachineAccountQuota (preferiblemente a cero) cuando proceda, y restringir quién puede crear nuevas cuentas de usuario.

Además, supervisa de forma explícita las áreas que permiten una escalada de privilegios en un intervalo de tiempo breve o de forma indirecta: cambios en los grupos con privilegios, cambios en las delegaciones, modificaciones de los SPN y cambios en las ACL de AdminSDHolder y los grupos protegidos.


Reconsiderar los riesgos de los operadores de cuentas

El grupo «Account Operators» es peligroso porque otorga un amplio control sobre los objetos que definen el acceso, la confianza y la autenticación en Active Directory.

Si se compromete la identidad de un operador de cuentas, este puede crear nuevos sujetos, restablecer contraseñas, manipular grupos, configurar el «kerberoasting», hacer un uso indebido de la delegación, establecer persistencia y, en las condiciones adecuadas, aprovechar el retraso incorporado en la protección de AdminSDHolder.

Por eso, los defensores con experiencia deberían dejar de considerar a los operadores de cuentas como un puesto de soporte obsoleto y empezar a tratarlo como lo que realmente es: un acceso sin privilegios con múltiples vías de escalación… también conocido como Nivel 0.

La identidad es el perímetro… protégela.

Hasta la próxima…Sigue la conversación sobre los operadores de cuentas en LinkedIn.

Y si necesitas ayuda de expertos para detectar y subsanar las brechas de seguridad de tu Active Directory, solicita una Evaluación de seguridad de Active Directory. Estamos a su disposición.


Para saber más