Este artículo hace hincapié en la importancia de los permisos de lectura por defecto en la seguridad de Active Directory (AD), que a menudo se descuida. El bosque de AD no es sólo un límite de seguridad, sino que también debe considerarse como el rango de acceso de un intruso y la evaluación de seguridad de los objetos de AD después de conseguir entrar en la red de una organización. La eliminación de permisos de lectura específicos por defecto es una medida de bajo riesgo que aumenta la dificultad de los intrusos para llevar a cabo el reconocimiento y planificar sus próximos pasos. Comprender la lógica integrada del mecanismo de protección de Microsoft para las cuentas más privilegiadas del directorio es crucial para entender las ventajas e inconvenientes de este mecanismo.
En este documento se explica cómo ajustar el mecanismo de protección eliminando los permisos de lectura por defecto de riesgo para mejorar la seguridad de AD. Además, el documento aborda el problema de la deuda de configuración errónea en la mayoría de las infraestructuras de AD y cómo arreglar los permisos de los objetos que alguna vez formaron parte de un grupo privilegiado pero que ya no lo son. En última instancia, proteger AD restringiendo la visibilidad de los objetos y los permisos de lectura generales es fundamental para reducir la superficie de ataque de AD y mejorar su postura de seguridad.
Restricción del reconocimiento y los movimientos laterales
Un bloqueo adecuado tiene un impacto directo en lo difícil -o fácil- que resulta para los intrusos utilizar Active Directory (AD) contra usted durante la fase de reconocimiento de un ataque.
Como se muestra en la Figura 1, esta fase se produce después de que un usuario malintencionado establece un punto de apoyo en su red corporativa, normalmente engañando a sus empleados a través de correos electrónicos de phishing o sitios web maliciosos especiales. En esta fase, el intruso suele haberse apoderado únicamente de la cuenta AD de un usuario normal autenticado (es decir, cualquier cuenta de empleado sin privilegios que no administre el AD de su empresa). Puede que piense que un usuario sin privilegios no es una amenaza para la seguridad de su empresa, pero ¿cuánto tiempo permanecerá un intruso sin privilegios? Al principio, los intrusos utilizan vulnerabilidades conocidas del sistema operativo (SO) o controladores en puntos finales insuficientemente parcheados para elevar sus privilegios locales y obtener así rápidamente acceso administrativo en el cliente comprometido. Esto les permite desactivar otras protecciones que puedan existir en el cliente, descargar más malware y establecer un sistema de mando y control que suele permitir el acceso remoto directo de otros miembros de la banda. El siguiente objetivo sería moverse lateralmente a otros clientes, realizando un reconocimiento adecuado con el objetivo de comprometer una cuenta de administrador de dominio para finalmente obtener el dominio del dominio.
No obstante, el verdadero objetivo del intruso está claro: alcanzar y extraer sus datos empresariales sensibles para ponerle bajo presión. Mejor aún, aumentar esa presión cifrando tantos sistemas de su entorno como sea posible, incluidos todos los servidores, sus copias de seguridad y las copias de seguridad de esas copias. A estas acciones les sigue una amigable nota de rescate, solicitando un pago en Bitcoin en unas pocas horas o días, y prometiendo que tras el pago recibirás una clave de descifrado y tus datos sensibles definitivamente no serán liberados al mejor postor en la Dark Web. ¿Pagaría usted? En el mejor de los casos, no tendrá que responder a esa pregunta. En su lugar, habrá puesto su esfuerzo en impedir que los intrusos alcancen su objetivo, se apoderen de su AD y destruyan su empresa. El primer paso es dificultar a cualquier intruso la localización de sus usuarios privilegiados y la lectura de datos sensibles de su AD.
El bloqueo de AD puede marcar la diferencia
Un "bloqueo" de AD suele referirse a cambios de permisos en el directorio (es decir, cambiar algunos de los permisos predeterminados). Desgraciadamente, estos permisos son demasiado abiertos y revelan demasiada información almacenada en AD a los delincuentes. Los usuarios típicos y las aplicaciones de negocio rara vez necesitan esta información, por lo que la eliminación de algunos permisos en AD le acerca mucho más a la mejor práctica general de seguridad de TI: el modelo de mínimo privilegio, en el que se concede a los usuarios sólo los permisos que necesitan para hacer su trabajo. Para cualquier cambio de permisos en AD, sin embargo, siempre hay que sopesar los pros y los contras de cómo esos cambios podrían afectar a sus aplicaciones empresariales. Después de todo, un AD perfectamente seguro que no sea compatible con sus aplicaciones empresariales no le servirá de nada. Lo ideal es disponer de un entorno de pruebas sólido que contenga no sólo un bosque de AD de prueba (configurado igual que su AD de producción), sino también una copia de las aplicaciones empresariales más importantes que utiliza. Este entorno le permite probar el impacto de cualquier cambio de permisos en AD antes de implementarlo en producción.
En cualquier caso, los cambios de permisos deben planificarse cuidadosamente (véase la Figura 2). La buena noticia es que revertir a los permisos originales es bastante fácil (por ejemplo, si sus pruebas pasaron por alto algunos artefactos). La documentación de los permisos que está cambiando en AD es fundamental para poder deshacer dichos cambios. Una herramienta de auditoría AD adecuada puede hacer esto por usted, manteniéndole en un lugar seguro.
Sus objetos con privilegios son un objetivo clave para los intrusos
Si debe elegir un área específica para comenzar un bloqueo de su AD, la primera opción debería ser claramente sus cuentas y grupos privilegiados. Estos son sus grupos de administradores de empresa y de dominio y sus miembros, pero también aquellos otros grupos especiales como operadores de cuentas, operadores de servidores, etc. y sus miembros. En un AD correctamente configurado, ninguna de sus aplicaciones empresariales utilizará esos grupos y cuentas privilegiados. Estas aplicaciones tampoco necesitan realizar una búsqueda de protocolo ligero de acceso a directorios (LDAP) como "quién es miembro del grupo de administradores del dominio" para funcionar. Por lo tanto, este bloqueo de AD suele ser una tarea de bajo riesgo. AD utiliza el atributo "adminCount" en los objetos para marcar aquellos que considera "privilegiados"; los objetos correspondientes tienen este atributo establecido en 1. Para saber qué grupos considera privilegiados su AD, puede ejecutar una simple consulta LDAP con el siguiente filtro:1
(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))
Esta consulta busca sólo grupos de seguridad, específicamente aquellos que están marcados con un '1' en su atributo adminCount. Utilice su método de consulta LDAP favorito; por ejemplo, DSQUERY:
dsquery * domainroot “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”
o PowerShell:
Get-ADObject -LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648) (admincount=1))”
o el filtro LDAP directamente en la Consola de administración de Microsoft (MMC) de Usuarios y equipos de AD, con la opción de búsqueda personalizada/avanzada (véase la figura 3). Los resultados en su dominio pueden ser diferentes, especialmente si ha anidado otros grupos en esos grupos privilegiados predeterminados, aunque sea temporalmente. Los resultados también dependen de la versión del sistema operativo de sus controladores de dominio AD y de cómo haya actualizado entre versiones. Pero lo ideal es que su lista no se desvíe demasiado de este valor predeterminado. Si es así, es posible que tenga que realizar algunas tareas de limpieza (de las que hablaremos más adelante). En primer lugar, es importante comprender qué significa el atributo adminCount y de dónde procede, así como algunos aspectos básicos del comportamiento y el diseño de AD.
La delegación detallada de permisos fue la piedra angular del éxito de AD
Cuando Microsoft diseñó AD hace más de 23 años, añadió potentes capacidades de delegación de permisos, hasta en cada atributo de los objetos del directorio. La base de esta capacidad era almacenar permisos independientes, denominados descriptor de seguridad o lista de control de acceso (ACL), para cada objeto de AD como parte del propio objeto (almacenados en el atributo nTSecurityDescriptor ). El modelo de seguridad de AD permitía heredar permisos a lo largo de todo un árbol de unidades organizativas (OU) para configurar permisos de forma eficiente sin tener que establecerlos por separado en todos los objetos. Pero el modelo también permitía establecer permisos explícitos directamente en un objeto (por ejemplo, otra OU, usuario o grupo) (véase la Figura 4). Los permisos explícitos de ese objeto podían mezclarse con los permisos heredados o podían bloquear los permisos heredados del objeto padre.
Esta flexibilidad permitió incluso a las empresas más grandes utilizar un directorio de TI central y global que podía delegar tareas de asistencia importantes en otros equipos. En la época en que se diseñó AD, era habitual contar con equipos de asistencia independientes en cada país en el que operaba una empresa. Esos equipos realizaban tareas de soporte clásicas, como restablecer la contraseña de una cuenta de usuario en su región, añadir objetos informáticos o incluso añadir usuarios a grupos según fuera necesario para el funcionamiento de la empresa. Mediante la delegación de permisos en el nivel de OU adecuado (p. ej., OU=PHX,OU=US, DC=mycompany,DC=com) y la herencia de permisos en toda la rama de la OU a los objetos pertinentes (p. ej., usuario, equipo, grupo), los miembros de un grupo AD del servicio de asistencia correspondiente podían realizar todas las tareas de asistencia necesarias para los usuarios, equipos y grupos de cualquiera de las sub- OU. Esta capacidad no requería que los miembros del grupo tuvieran permiso para administrar el propio servicio AD. En otras palabras, el personal del servicio de asistencia no era miembro del grupo de administradores de dominio y no podía cambiar la configuración de AD, promover nuevos controladores de dominio (DC) ni iniciar sesión en los controladores de dominio de AD.
Los usuarios del servicio de asistencia con permisos específicos delegados en AD se denominan administradores de datos de AD, mientras que las cuentas realmente privilegiadas, como los administradores de dominio, se conocen como administradores de servicios de AD. Pero, ¿qué ocurre si una cuenta de administrador de dominio "real" se encuentra en una sub-OU a la que el personal del servicio de asistencia tiene derechos para restablecer las contraseñas de los usuarios? O peor aún, ¿qué ocurre si alguien no concede permisos al servicio de asistencia técnica en el nivel de sub-OU adecuado, sino que lo hace en la raíz del dominio? Sin un mecanismo de protección adicional en AD para evitar que un administrador de datos, como una cuenta de helpdesk, realice cualquier cambio (como restablecer la contraseña) en un administrador de servicio, como una cuenta de administrador de dominio o cualquier otra cuenta o grupo privilegiado, la seguridad general de cualquier implementación de AD estaría en un estado calamitoso. Cualquier personal de helpdesk delegado podría comprometer fácilmente todo el AD.
SDPROP: la función integrada de protección de AD
La protección de esos objetos AD privilegiados es exactamente el trabajo del proceso de propagación de descriptores de seguridad (SDPROP). Este proceso se ejecuta periódicamente (cada 60 minutos de forma predeterminada o según se configure) en cada emulador de controlador de dominio primario (PDCE) de cada dominio de un bosque de AD y busca todos los objetos con privilegios en el dominio de AD correspondiente. SDPROP no sólo comprueba la pertenencia a los grupos predeterminados (como los administradores de dominio), sino que sigue cualquier grupo anidado en esos grupos privilegiados y los marca a ellos y a sus miembros como "privilegiados". Como puedes añadir usuarios, grupos e incluso objetos informáticos a esos grupos privilegiados, cualquiera de esos objetos se tiene en cuenta durante el análisis. Advertencia importante: los objetos deben ser locales al mismo dominio que el grupo privilegiado para que SDPROP los tenga en cuenta, por lo que no espere la misma protección para los usuarios añadidos desde otro dominio.
Para cada objeto con privilegios que encuentra SDPROP, el proceso compara el nTSecurityDescriptor del objeto con una plantilla de permisos especial que se reserva exclusivamente para proteger esos objetos con privilegios. Esta plantilla concede una serie de permisos, pero lo más importante es que garantiza que sólo los administradores, los administradores de dominio y los administradores de empresa pueden cambiar la contraseña de las cuentas privilegiadas. Si el proceso SDPROP encuentra una desviación entre los permisos de los objetos que encuentra y los de la plantilla, sustituye el nTSecurityDescriptor del objeto correspondiente por el de la plantilla y, a continuación, actualiza el atributo adminCount del objeto con un "1".
Entre bastidores: AdminSDHolder
La plantilla de permisos especiales que SDPROP copia en sus objetos privilegiados es configurable. Es el nTSecurityDescriptor(permissions) del objeto AdminSDHolder de tu dominio. Este nombre debería sonarte: es literalmente el objeto 'admin security descriptor holder', un objeto contenedor ubicado en el contenedor system de cada dominio(CN=AdminSDHolder,CN=System,DC=myco mpany,DC=com). Los permisos predeterminados establecidos en AdminSDHolder son comparativamente restrictivos con respecto a los cambios en los objetos. Eso es lo que cabría esperar de unos permisos que se van a estampar en todos los grupos y usuarios con privilegios de su AD. La lista de permisos de muestra de la Figura 5 proviene de una implementación reciente de un laboratorio de pruebas en Windows Server 2019 que no contiene servidores Exchange. Si tiene Exchange en su entorno, encontrará más permisos añadidos a esta plantilla. Después de todo, los desarrolladores de Exchange habían considerado "poseer" el AD para su aplicación. Por ahora, tenga en cuenta que los siguientes permisos se estampan en todos sus objetos privilegiados en el dominio AD respectivo. Y lo que es más importante, puede ver que esta lista de control de acceso (ACL) no tiene habilitada la herencia. En otras palabras, la ACL bloquea la herencia de los permisos establecidos en un objeto padre (OU), incluidos los permisos de restablecimiento de contraseña del servicio de asistencia técnica comentados anteriormente. De esta manera, la combinación de SDPROP y AdminSDHolder protege sus cuentas más privilegiadas de permisos mal configurados en su AD.
Técnicamente, puede eliminar algunos grupos de administradores predeterminados en AD para que el proceso SDPROP no los considere privilegiados, en concreto los grupos de operadores de cuentas, operadores de servidores, operadores de impresión y operadores de copias de seguridad. De este modo, los miembros no se sobrescribirían con los permisos del objeto AdminSDHolder. Sin embargo, debido a que cada grupo tiene su propio riesgo con respecto a la elevación de privilegios en AD, no se recomienda esta configuración. Vale la pena proteger estos grupos, o incluso mejor, no utilizarlos en primer lugar. Para obtener más información sobre cómo excluir (o volver a incluir) estos grupos del proceso SDPROP, consulte el artículo "Seguridad de Active Directory: Understanding the AdminSDHolder Object'.2
Función del atributo AdminCount
El atributo adminCount en sí no tiene ninguna relevancia real para la seguridad. Es una simple característica de soporte que le permite utilizar más fácilmente una consulta LDAP para determinar qué permisos de objetos han sido reemplazados por los permisos establecidos en esa plantilla especial, como se mostró anteriormente. Tenga en cuenta que una vez que elimine un usuario, grupo o equipo de un grupo privilegiado, dejará de ser privilegiado. El proceso SDPROP escribe el identificador de evento 4780 en el registro de eventos de seguridad del controlador de dominio primario (PDC) al sellar los permisos AdminSDHolder en objetos con privilegios y actualizar dichos objetos con el atributo adminCount (establecido en 1). Sin embargo, ni revierte esos cambios una vez que un objeto deja de tener privilegios, ni escribe ningún evento en el registro de eventos para informarle de que ya no los considera privilegiados. Por ejemplo, cuando añades temporalmente a alguien al grupo de administradores del dominio y el proceso SDPROP se ejecuta antes de que elimines al usuario, ese usuario seguirá teniendo la configuración nTSecurityDescriptor bloqueada y estará marcado con adminCount=1. Lo mismo ocurre con cualquier objeto. Lo ideal, entonces, es no agregar temporalmente a ningún usuario a un grupo privilegiado. Si lo ha hecho, debe limpiar los permisos y el atributo adminCount para que el usuario se configure de nuevo a su estado original. Este proceso de limpieza se describe más adelante en este documento.
Una mirada más de cerca a los permisos de AdminSDHolder
Una vez comprendidos estos conceptos, ¿está satisfecho con los permisos que se conceden a través del objeto AdminSDHolder y SDPROP a todas sus cuentas con privilegios? Si echa un vistazo más de cerca a esos permisos, incluso sin Exchange de por medio, observará algunos permisos cuestionables, como se destaca en la Figura 6, tomada de la página de configuración de seguridad avanzada del objeto AdminSDHolder, a la que se accede a través de AD users and computers o ADSI edit. ¿Qué acceso conceden esas otras entradas marcadas como "especiales" a la entidad de seguridad correspondiente en esa ACL? Desafortunadamente, el editor de seguridad estándar de AD no hace el mejor trabajo convirtiendo adecuadamente la cadena SDDL almacenada en el atributo nTSecurityDescriptor . Incluso al abrir la entrada de control de acceso (ACE) correspondiente, estos permisos especiales no suelen aparecer. Por lo tanto, debe encontrarlos directamente mediante PowerShell, a través de algo como (Get-Acl'AD:CN=AdminSDHolder,CN=System,D C=mydom,DC=local').access, o utilizando DSACLS.exe, ambos con una salida difícil de descifrar. Una herramienta comparativamente fácil, potente y a menudo olvidada para la gestión de ACL es LDP.exe, que hace un trabajo perfecto mostrando todas las ACEs con la información relevante. Siga estos pasos para mostrar completamente los permisos adecuados de su objeto AdminSDHolder: Inicie LDP.exe;
- Seleccione Conexión > Vincular (o Ctrl + B) y Vincular como el usuario actualmente conectado;
- Seleccione Ver > Árbol (o Ctrl + T) y seleccione su dominio como el BaseDN;
- En el árbol de dominios de la izquierda, vaya a Sistema > AdminSDHolder;
- Haga clic con el botón derecho en el objeto AdminSDHolder y seleccione Avanzado > Descriptor de seguridad;
- Haga clic en OK para mostrar el Descriptor de Seguridad;
La ventana resultante debería parecerse a la de la Figura 7. Si la compara con la Figura 6 del editor de seguridad estándar, podrá ver que incluso las ACEs están ordenadas en el mismo orden. Si nunca ha actualizado los permisos de AdminSDHolder con el editor de seguridad por defecto (tal y como se utiliza en AD users and computers y ADSIedit), el editor de seguridad LDP.exe le mostrará incluso las ACEs de acceso compatibles originales anteriores a Windows 2000, divididas para muchos tipos de objetos. El editor de seguridad por defecto ni siquiera puede procesar correctamente esas ACEs y simplemente las sustituye por un permiso de lectura genérico en cualquier otra actualización de la ACL; una vez actualizada con la interfaz de usuario (UI) del editor de seguridad por defecto, esas otras ACEs para este grupo se eliminan automáticamente. Esto no ocurre si el permiso AdminSDHolder (o cualquier otro) se actualiza con el editor de seguridad LDP.exe, por lo que, en general, LDP.exe es la opción más segura para trabajar al actualizar ACL críticas en AD.
Ahora puedes confirmar fácilmente que los permisos de todos y autopermisos no son preocupantes. El permiso de cambio de contraseña puede parecer peligroso, pero no indica nada más que los derechos para cambiar la contraseña de un usuario cuando se conoce la antigua de ese mismo usuario (a diferencia de restablecer contraseña, que permite a un administrador sobrescribir cualquier contraseña existente). Dicho esto, ¿cuál es el problema con las ACEs resaltadas? La cuenta MSOL_5c0317387a29 (es decir, 'MSOL_' más una cadena aleatoria), resaltada en naranja en la Figura 7, se encuentra en la mayoría de los entornos. Esta cuenta es una cuenta predeterminada que se crea automáticamente durante la configuración de la herramienta Azure AD Connect, que utiliza la cuenta para sincronizar objetos entre AD local y Azure AD. Las versiones anteriores de Azure AD Connect, al utilizar la opción de instalación exprés, añadían automáticamente la cuenta a la ACL AdminSDHolder para permitir el control de los grupos y usuarios privilegiados. Si configuró la cuenta de Azure AD Connect manualmente o utiliza una versión más reciente de la herramienta, es posible que no encuentre esta entrada.
No deberías replicar ninguna cuenta o grupo privilegiado de AD a Azure AD, ya que esto podría llevar a rutas de ataque adicionales entre los dos directorios. Si sigues esa regla, no hay ningún requisito para mantener la cuenta de sincronización con permisos de esta manera, por lo que también podría eliminar la entrada de AdminSDHolder. La cuenta de sincronización en sí, sin embargo, debe ser vista como altamente privilegiada y sensible, por lo que la eliminación de la ACL aquí no proporciona mucha reducción adicional en la superficie de ataque de AD. No ocurre lo mismo con las dos entradas resaltadas en rojo: los grupos de acceso3 y de usuarios autenticados compatibles con versiones anteriores a Windows 2000. A ambos se les conceden permisos de lectura completos sobre cualquier objeto privilegiado en AD. Esto no es lo ideal; cualquier usuario (u ordenador) de su bosque de AD puede enumerar el contenido de cualquier grupo privilegiado (por ejemplo, administradores de dominio) y enumerar las distintas pertenencias a grupos de cualquier usuario privilegiado. Así es exactamente como les gusta a los intrusos: fácil de determinar a quién perseguir en su AD y qué cuenta capturar y utilizar para realizar un pass-the-hash u otro ataque para obtener el dominio y el dominio del bosque. Lo más probable es que sus usuarios y aplicaciones empresariales nunca necesiten buscar esta información, así que ¿por qué concederla?
La respuesta es sencilla: no debe hacerlo. Elimine estos dos permisos (incluidas todas las demás ACE que puedan estar asignadas al grupo de acceso compatible con Windows 2000). Simplemente sustitúyalos por un permiso para otro grupo; por ejemplo, SVC-ADconfig- AdminSDHolder-READ. Convierta ese grupo en un grupo local de dominio para poder controlar su pertenencia cuando necesite una cuenta de servicio o un objeto informático que ejecute software que tenga derecho legítimo a leer datos de sus objetos privilegiados. El uso del tipo de grupo local de dominio le permite añadir cualquier usuario, grupo global o universal u ordenador de cualquier dominio de su bosque AD. Es posible que necesite esta capacidad para software o sistemas que utilice para supervisar o administrar su AD. Por ejemplo, si ejecuta Semperis Directory Services Protector (DSP), querrá añadir la cuenta de equipo DSP a ese grupo. De este modo, todos los demás usuarios y equipos no podrán leer nada sobre sus objetos privilegiados, lo que constituye una forma eficaz de reducir la superficie de ataque de su AD. A los intrusos simplemente se les impide enumerar los objetos apropiados. Tenga en cuenta que esta acción debe repetirse para cada dominio de su bosque de AD.
Una plantilla AdminSDHolder actualizada en el dominio raíz tendría entonces el aspecto que se muestra en la Figura 8. Para determinar el efecto que dichos cambios tendrán sobre la seguridad de su AD, debe utilizar los derechos que un intruso tendría disponibles a través de un usuario normal de dominio tanto antes como después de cambiar el permiso del objeto AdminSDHolder en su entorno de producción. Para simplificar, este ejemplo comprueba la seguridad del dominio raíz en un bosque AD, ignorando el dominio hijo. En realidad, querrá comprobar la seguridad de todos los dominios del bosque.
Uso de potentes exploradores de vulnerabilidades de AD
Puede realizar fácilmente estas sencillas comprobaciones utilizando herramientas gratuitas: la herramienta de exploración de vulnerabilidades AD Purple Knight ,4 BloodHound5 y SharpHound (la herramienta de recopilación de datos de BloodHound). Los intrusos suelen utilizar una combinación de SharpHound en la red de la víctima y BloodHound en un equipo externo para encontrar la ruta de ataque más corta hacia el grupo de administradores de dominio. Ambas exploraciones de vulnerabilidades pueden repetirse fácilmente en un entorno AD, sin ninguna configuración especial, aunque conseguir que BloodHound y sus dependencias (es decir, la base de datos NEOj4, Java JDK) funcionen puede requerir un esfuerzo considerable. Purple Knight no requiere ninguna instalación más allá de descargar y descomprimir el archivo .zip correspondiente.
Antes de ajustar AdminSDHolder
Este ejemplo realiza ambos escaneos como un usuario simple, JustArootUser. Este usuario no tiene derechos especiales de administrador en AD, pero es un usuario autenticado en el bosque AD. Este escenario imita las acciones de un intruso en su entorno AD. El primer escaneo, usando Purple Knight, muestra 29 indicadores de exposición (IOEs) - vulnerabilidades que un intruso podría usar para atacar AD (ver Figura 9). El análisis BloodHound/SharpHound enumera todas las cuentas de administrador de dominio (véase la figura 10) a las que puede acceder el usuario simple y el camino más corto para que ese usuario acceda al grupo de administradores de dominio (véase la figura 11).
Después de ajustar AdminSDHolder
Después de eliminar la ACE para los usuarios autenticados y los grupos de acceso compatibles con Windows 2000 del AdminSDHolder en el dominio raíz y añadir la ACE para el grupo SVC-ADconfig- AdminSDHolder-READ, debe esperar a que se ejecute el proceso SDPROP y actualizar sus objetos privilegiados para que sus atributos nTSecurityDescriptor se actualicen con los de la plantilla AdminSDHolder. Este proceso tarda aproximadamente una hora, pero puede activar manualmente la actualización, como se describe más adelante en el documento. Después de estas acciones, un escaneo de Purple Knight encuentra sólo 18 IOEs - 11 vulnerabilidades menos que antes (ver Figura 12). Ahora que el usuario simple ya no puede enumerar ni el grupo de administradores del dominio ni a sus miembros, un análisis BloodHound/SharpHound muestra que un intruso no podría ver a los miembros del grupo ni localizar rutas de ataque hacia ellos (véanse las figuras 13 y 14).
¿Es segura la AD?
Tenga en cuenta que las vulnerabilidades contra las cuentas privilegiadas no desaparecen del todo; simplemente no son fácilmente visibles para los atacantes. Pero encontrar los puntos débiles adecuados para atacar su AD se ha vuelto mucho más difícil. Por ejemplo, los intrusos ya no pueden ver qué usuarios con privilegios están debidamente protegidos por el grupo de usuarios protegidos, un grupo al que es conveniente que pertenezcan los administradores de dominio y otros usuarios con privilegios, ya que el grupo hace lo que su nombre indica: proteger las cuentas de varios vectores de ataque, como los ataques pass-the-hash. Con el bloqueo, los intrusos ya no pueden planificar una ruta de ataque detallada hacia sus cuentas más privilegiadas y deben encontrar otras formas de comprometer su AD. Estas formas suelen ser más complejas. Si se dispone de una supervisión adecuada de la cuenta de usuario y de los puntos finales, este tipo de ataques pueden activar una alarma temprana para el equipo del centro de operaciones de seguridad (SOC). Una combinación de herramientas como Microsoft Defender for Identity, Semperis Directory Services Protector y SentinalOne XDR le llevará bastante lejos en este ámbito.
Aun así, este bloqueo de permisos no significa que pueda renunciar a otras buenas prácticas de seguridad. Todavía debe tomarse en serio la jerarquización de su infraestructura AD. Como mínimo, esto significa que sus cuentas más privilegiadas nunca inicien sesión en ningún sistema que no sean los controladores de dominio (u otros sistemas de Nivel 0 de alta confianza). Ocultar el acceso a sus cuentas privilegiadas es sólo un aspecto de este tipo de jerarquización administrativa y aborda específicamente las técnicas de reconocimiento utilizadas por los atacantes como se describe en el marco MITRE ATT&CK.6
También hay que tener en cuenta que el escaneo Purple Knight todavía detectó otras vulnerabilidades potenciales, incluso después del bloqueo del AdminSDHolder. IOEs como 'Non-default principals with DC Sync rights on the domain' o 'Domain trust to a third-party domain without quarantine', todavía se encontraban a través de los permisos estándar para usuarios autenticados en otros objetos del dominio - y todavía podían ser usados por intrusos para planear ataques.
Aún no has terminado...
Ahora que ha creado el grupo SVC- ADconfig-AdminSDHolder-READ, aún debe añadir al grupo las cuentas adecuadas que desea volver a habilitar para la lectura de objetos con privilegios. Estas cuentas incluyen cuentas de servicio con privilegios bajos para herramientas de seguridad y gestión y, en un bosque multidominio, los administradores de dominio de otros dominios. Por ejemplo, la Figura 15 muestra la vista del administrador de dominio de un dominio hijo de los objetos raíz del bosque. Esta cuenta, que dependía de los permisos de usuarios autenticados en AdminSDHolder, ya no tiene derechos para leer los grupos privilegiados del dominio raíz.
Este problema se soluciona fácilmente añadiendo el grupo de administradores del dominio hijo (global) al grupo local SVC-ADconfig- AdminSDHolder-READ del dominio raíz. Una vez que bloquee el dominio secundario, tendrá que repetir esta tarea para añadir el grupo de administradores del dominio raíz al grupo del dominio secundario, o bien puede convertir el grupo especial AdminSDHolder en un grupo universal en el dominio raíz, utilizarlo en todas las plantillas AdminSDHolder del bosque y añadirle todos los grupos de administradores de dominio. Tú eliges. No hace falta decirlo: no habilite la herencia en la propia plantilla AdminSDHolder. Si lo hiciera, invalidaría toda la función. También tenga en cuenta que al igual que puede utilizar AdminSDHolder para bloquear su AD mediante la eliminación de permisos, los intrusos también pueden utilizar el objeto para obtener persistencia en un AD comprometido. Para ello, un intruso primero crea un usuario discreto y lo esconde en algún lugar de la estructura de su OU. A continuación, asigna a este usuario el permiso para restablecer las contraseñas de usuario en la plantilla AdminSDHolder. SDPROP hace el resto, permitiendo al intruso mantener el control. Claramente, usted querrá monitorear continuamente esta plantilla por cambios. Por último, como se mencionó anteriormente, es necesario limpiar los restos de los administradores y grupos de administradores que puede haber generado a lo largo de los años.
Limpieza de Objetos Privilegiados: Búsqueda de objetos mal configurados
Los siguientes pasos le permitirán localizar y limpiar los objetos que AD consideraba privilegiados (y que, por tanto, "selló" mediante SDPROP actualizando su ACL y estableciendo el atributo adminCount en "1"), pero que ya no son miembros de ningún grupo privilegiado:
- Mark all existing groups with admincount=1 via the telephoneNumber attribute (or some other unused attribute) so that you can more easily locate these groups again in a later stage of the clean-up: Get-ADObject-LDAPfilter “(&(groupType:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))”| Set-ADObject -Replace @ {telephoneNumber=“adminCount- Check-20220730”};
- Borra la configuración actual del atributo adminCount para todos los grupos encontrados previamente: Get- ADObject -LDAPfilter "(&(group Type:1.2.840.113556.1.4.803:= 2147483648)(admincount=1))" | Set- ADObject -Clear "adminCount";
- Asegúrese de que el proceso SDPROP actualizará todos los objetos relevantes: SDPROP realizará una actualización sólo en los objetos relevantes cuando se produzca un cambio en la ACL en el destino o en AdminSDHolder. La forma más sencilla de asegurarse de que SDPROP realizará su magia es añadir manualmente una ACE falsa (por ejemplo, Permitir "Operadores de copia de seguridad" a "Objeto de lista") en AdminSDHolder y, a continuación, eliminar la ACE después de la comprobación;
- Fuerza la ejecución de SDPROP.
Puede esperar hasta 60 minutos para que se ejecute el proceso SDPROP (es decir, esperar a que la programación predeterminada active la operación). O puede forzar al DC con la función PDCE FSMO a que inicie el proceso SDPROP en su comando, enviando el comando RunProtectAdminGroupsTask al RootDSE de su dominio. El método más sencillo es utilizar LDP.exe como usuario con privilegios de administrador del dominio: eligiendo la opción "ejecutar como administrador" al iniciarlo y, a continuación:
- Ejecute LDP.exe, eligiendo la opción Ejecutar como administrador ;
- Seleccione Conexión > Conectar e introduzca el DC con rol de emulador PDC en su dominio;
- Pulse Ctrl + B o seleccione Conexión > Vincular para vincularse como el usuario actualmente conectado;
- Pulse Ctrl + M o seleccione Examinar > Modificar para iniciar una operación de modificación;
- Deje DN: en blanco e introduzca RunProtectAdminGroupsTask como Atributo y 1 como Valor;
- Seleccione Operación AÑADIR y, a continuación, haga clic en Intro o pulse Alt + E;
- Cuando vea la entrada [Add] RunProtectAdminGroupsTask:1 en la Lista de entradas de la ventana Modificar (consulte la Figura 16), haga clic en el botón Run para ejecutar la operación y ejecutar el proceso SDPROP.
- Espera a que el proceso SDPROP termine de procesarse. Puedes comprobar que
el atributo adminCount=1 devuelve a los objetos conocidos que esperas (por ejemplo, los miembros directos de tu grupo de administradores de dominio) o comprobar tu registro de eventos de seguridad en el PDCE y validar que no se generan más eventos con ID 4780 (categoría de tarea: gestión de cuentas de usuario). Estos eventos muestran qué objetos se han restablecido mediante el proceso SDPROP. - Comprueba qué grupos no han sido actualizados utilizando la bandera anterior y añadiendo un filtro para aquellos grupos, donde adminCount no esté establecido a '1': Get- ADObject-LDAPfilter “(&(groupType: 1.2.840.113556.1.4.803:=2147483648)(telephoneNumber=adminCount-Check-20220730)(!(adminCount=1)))”;
- El resultado del último filtro son los objetos que querrás limpiar pronto. Todavía contienen la ACL de la configuración AdminSDHolder en el momento en que eran un grupo privilegiado, lo que también significa que no heredan ningún permiso que pueda haber establecido en el nivel OU;
- Repita el mismo procedimiento con el equipo y las cuentas de usuario. Es probable que no desee utilizar el atributo telephoneNumber como su AdminSDHolder-check-flag temporal en los objetos de usuario; tal vez ya no se utilice facsimileTelephoneNumber . El filtro LDAP adecuado para encontrar a los usuarios con privilegios sería: (&(objectClass=user) (objectCategory=person) (admincount=1));
- Elimine la ACE falsa del objeto AdminSDHolder después de determinar sus objetos de limpieza.
Limpieza de Objetos Privilegiados: Restablecimiento de las ACL en objetos mal configurados
Utilizar PowerShell para restaurar las ACL en los objetos relevantes es un poco más complicado. No existe un equivalente sencillo en PowerShell a la opción "restaurar valores predeterminados" disponible en la interfaz de usuario de configuración de seguridad avanzada de los objetos de AD. Estos valores predeterminados se almacenan en el esquema de AD, concretamente en el atributo defaultSecurityDescriptor de la clase de objeto correspondiente. Al hacer clic en la opción de restaurar valores predeterminados en la interfaz de usuario de seguridad, los permisos de clase adecuados se leen desde el esquema y luego se aplican de nuevo en el objeto. Si sólo tiene unos pocos objetos mal configurados, este método puede ser la forma más fácil de solucionarlos. Pero, ¿y si tiene muchos objetos de este tipo en varias ubicaciones?
Una opción es utilizar la herramienta DSACLS con la opción /resetDefaultDACL , que restablece la seguridad del objeto a sus valores predeterminados definidos en el esquema; sin embargo, mezclar herramientas PowerShell y CLI puede resultar complicado. Y aunque Microsoft no ha creado un equivalente en PowerShell para procesar un restablecimiento directo de ACL a su valor predeterminado, puede utilizar el cmdlet Get-ACL para obtener la ACL de otro objeto de la misma clase y, a continuación, estampar esa ACL en objetos mal configurados mediante el cmdlet Set-ACL. Básicamente, puede copiar y pegar ACL de un objeto a otro mediante los comandos Get-ACL y Set-ACL de PowerShell. Dado que el defaultSecurityDescriptor del esquema también se lee y se utiliza en la creación de cualquier objeto nuevo de una clase específica, puede crear un objeto ficticio para copiar la ACL. El objeto puede ser incluso un objeto desactivado, ya que su estado no forma parte de la ACL.
Lamentablemente, no se puede pasar la salida del cmdlet Get-ADObject al cmdlet Set-ACL, ya que este último debe recibir la ruta del objeto en un formato específico: el nombre distinguido (DN) del objeto precedido de "AD:". Por lo tanto, debe recorrer la lista de objetos devuelta por Get-ADObject, formar la ruta adecuada para utilizarla con Set-ACL y, a continuación, ejecutar el comando correspondiente en el bucle. El siguiente script de PowerShell restablecerá las ACL de los objetos de clase de usuario a las de una cuenta ficticia recién creada denominada DefaultUserACL. (El atributo facsimileTelephoneNumber se marcó previamente para ayudar a localizar las cuentas mal configuradas).
#Set path for ACLing to AD
Set-Location AD:
#Grab ACL objects from a sample user- account (e.g. newly created account)
$DefaultAcl = (Get-Acl “AD:CN= DefaultUserACL,OU=MyOU,DC=mydo m,DC=local”)
#query for the old AdminCount objects that must get their permissions reset $OldAdminCountObjects =
Get-ADObject -LDAPfilter
“(&(objectClass=user)
(objectCategory=person)(facsimile TelephoneNumber=adminCount- Check-20220730)(!(adminCount=1)))”
#work through every object, grab the DN, create the proper ACL-DN-Path and set sample ACL on object
ForEach ($Object in $$OldAdminCountObjects){
$ACLpath = “AD:” + $Object. distinguishedName
write-host “Resetting permissions on”,
$ACLpath
Set-Acl -Path $ACLpath -AclObject
$DefaultAcl#update flag of object
Set-ADObject -Identity $Object.
distinguishedName -Replace
@{facsimileTelephoneNumber=“ACL was reset 20220730”}
}
Cuando adapte el script para grupos u ordenadores, asegúrese de cambiar al filtro LDAP apropiado con el atributo que eligió para ayudarle a localizar esos objetos. Si lo prefiere, puede omitir la creación de esos objetos ficticios y utilizar la misma lógica de bucle para ejecutar las herramientas DSACLS, utilizando el nombre distinguido del objeto y la opción /resetDefaultDACL . Cualquiera de los dos métodos le ayudará a limpiar correctamente los objetos antiguos y privilegiados de su AD.
La seguridad de AD requiere una atención continua
El objetivo de este documento es ayudarle a comprender las ventajas de las funciones de seguridad integradas AdminSDHolder y SDPROP de AD, que protegen los objetos con más privilegios dentro de su AD, y cómo puede bloquear estos objetos aún más para mejorar la protección, con la intención de combatir la fase de reconocimiento de un ataque. Cuanto más difícil se lo pongas a los intrusos para llegar a tus objetos más privilegiados, mejor. Como se ha descrito, este método de endurecimiento debe ir acompañado de una clasificación adecuada de sus cuentas administrativas y de una supervisión activa de su AD y de sus endpoints. La seguridad de su AD siempre ha sido importante, y el continuo aumento de los ataques de ransomware subraya esta necesidad.
Recursos
1. Mueller, R. y Geelen, P. (septiembre de 2020 [noviembre de 2011]), 'Active Directory: LDAP Syntax Filters', Microsoft, disponible en https://social.technet. microsoft.com/wiki/contents/articles/5392.active- directory-ldap-syntax-filters.aspx (consultado el 25 de septiembre de 2022).
2. Smith, R. (enero de 2018), 'Active Directory Security: Understanding the AdminSDHolder Object', Petri, disponible en https://petri.com/ active-directory-security-understanding- AdminSDHolder-object (consultado el 25 de septiembre de 2022).
3. Grillenmeier, G. (noviembre de 2021), "Understanding the Risks of Pre-Windows 2000 Compatibility Settings in Windows 2022", Semperis, disponible en https://www.semperis.com/blog/security-risks- pre-windows-2000-compatibility-windows-2022/ (consultado el 25 de septiembre de 2022).
4. Purple Knight, «Descubrir vulnerabilidades de Active Directory antes de que lo hagan los atacantes», disponible en https://www.semperis.com/purple-knight (consultado el 25 de septiembre de 2022).
5. GitHub, 'BloodHound 4.2.0 - Azure Refactor', disponible en https://github.com/BloodHoundAD (consultado el 25 de septiembre de 2022).
6. MITRE ATT&CK, "Reconnaissance", disponible en https://attack.mitre.org/tactics/TA0043 (consultado el 25 de septiembre de 2022).
