Active Directory (AD) es un producto de Microsoft diseñado para ayudar a los administradores de red a administrar los permisos de los usuarios dentro de una organización. Se instala en un servidor Windows, convirtiéndolo en un controlador de dominio encargado de administrar los entornos empresariales y realizar acciones como almacenar todos los permisos de los usuarios. cuentas de usuario, sus contraseñas y permisos, y gestionar la autenticación de usuarios.
Con el tiempo, el mundo se está moviendo cada vez más hacia la adopción de la nube, y Microsoft también ha estado presionando a las organizaciones para que cambien hacia entornos basados en la nube para lograr una experiencia más optimizada y moderna. de gestión de identidadesLa solución de Microsoft para el entorno de dominio basado en la nube es Entra IDAmplía las capacidades de AD local a la nube, lo que proporciona una solución sólida para administrar identidades y accesos para aplicaciones basadas en la nube. Para permitir una integración perfecta con los sistemas heredados compatibles, Microsoft presentó Entra ID Conectar. Esta herramienta permite a las organizaciones vincular sus instalaciones locales Active Directory (AD) entorno con Entra ID, creando un “entorno híbrido unido”.
A través de la Entra ID Conectar permite a las organizaciones sincronizar usuarios y datos de directorio desde su AD local a la nube. Esto permite a los usuarios acceder a los servicios en la nube mientras usan las mismas credenciales que para sus sistemas locales. Una característica interesante Entra ID Connect admite la reescritura de contraseñas, en la que los cambios de contraseñas realizados en la nube se sincronizan con el AD local, lo que garantiza una gestión de identidades uniforme en ambos entornos. Este modelo híbrido garantiza que las organizaciones puedan mantener un sistema de identidad unificado mientras operan en infraestructuras locales y en la nube.
Las diferencias en la gestión de permisos entre sistemas heredados Active Directory y Entra ID puede provocar brechas de seguridad en el proceso de sincronización entre los dos productos.
Análisis profundo de la gestión de permisos
Gestión de permisos en Active Directory funciona de tal forma que en cada entorno existen varios grupos de seguridad privilegiados por defecto con permisos elevados para realizar cambios. Cuando queremos otorgarle estos permisos a un usuario en específico, simplemente lo agregamos al grupo. Por ejemplo, el grupo “Administrador de Dominio” otorga privilegios a todos los usuarios dentro de él. Otro método para definir permisos para usuarios o grupos es a través de la ACL (Lista de Control de Acceso). Esta lista existe para cada objeto en AD y especifica los permisos para cada entidad. Este mecanismo permite asignar permisos a un usuario regular para realizar modificaciones, incluso a objetos que pertenecen a usuarios con privilegios de alto nivel, como los Administradores de Dominio.
Sin embargo, en Entra ID (anteriormente Azure AD), no hay grupos de seguridad de forma predeterminada. En su lugar, utiliza un mecanismo RBAC (Control de acceso basado en roles). Esto significa que hay muchos tipos de roles, cada uno de los cuales define diferentes permisos de usuario. También puede asignar un rol a un grupo y todos los miembros de ese grupo heredarán los mismos permisos. Pero esta opción no incluye los grupos definidos de forma predeterminada, como Active Directory.
Entonces, ¿cuál es la diferencia entre los dos mecanismos? En Entra, se proporciona una protección contra modificaciones cuando un usuario recibe permisos privilegiados por asignación de rol o grupo. En AD heredado, descubrimos que no todos los grupos confidenciales están protegidos contra modificaciones. De hecho, ciertos grupos confidenciales se tratan como débiles cuando se trata de Entra ID Conectar sincronización.
En Entra, siempre que un usuario recibe un rol privilegiado, se le otorga automáticamente protección contra modificaciones. Solo un usuario con privilegios de nivel superior o un nivel de rol equivalente puede realizar cambios, lo que impide que cualquier otro usuario con un nivel de rol inferior lo haga. Esto significa que el usuario no tiene que ser miembro de un grupo de seguridad para estar protegido; simplemente asignarle un rol privilegiado es suficiente para brindarle cierto nivel de protección, a diferencia de AD.
Por ejemplo, en la jerarquía de Roles de administrador within Entra ID, Administrador de contraseñas El rol otorga a los usuarios la capacidad de restablecer contraseñas. Sin embargo, a pesar de estar categorizado como administrador, este rol se considera uno de los más bajos en la jerarquía administrativa. Como resultado, los administradores de contraseñas solo pueden restablecer contraseñas para usuarios regulares o usuarios que tengan el mismo rol de administrador. No tienen autoridad para restablecer contraseñas de usuarios de nivel superior. Roles de administrador, como administradores globales u otros cuentas privilegiadas, manteniendo un límite de seguridad claro entre los distintos roles de administrador. Esta estructura jerárquica garantiza que los roles más sensibles estén protegidos contra cambios de contraseña no autorizados.
¿Cómo se produce la sincronización?
El proceso de sincronización entre AD local y Entra ID Se puede dividir en dos partes principales:
- Sincronización de identidades desde las instalaciones locales a Entra ID
- Escritura diferida de contraseña desde Entra ID A las instalaciones locales
Parte 1: Sincronización desde las instalaciones locales a Entra ID
Entra ID Conectar crea una cuenta de servicio usuario llamado MSOL después de los primeros 8 bytes del identificador de instalación. Este usuario tiene capacidades potentes que pueden ser equivalentes a un controlador de dominio. El permiso "Replicar todos los cambios del directorio" permite al usuario realizar una sincronización de DC y extraer todos los atributos del objeto, incluidas las credenciales del cliente; en otras palabras, su hash NT. Debido a los amplios permisos otorgados a este usuario en todo el directorio, puede acceder y leer información sobre los usuarios en grupos protegidos. Esto se debe a que los permisos proporcionados permiten al usuario operar con privilegios similares a los de un controlador de dominio. En consecuencia, incluso si el usuario no está explícitamente incluido en la ACL de un grupo, aún conserva la capacidad de recuperar el hash NT de los miembros del grupo. Este permiso permite el lado local del proceso de sincronización y se administra mediante el protocolo remoto del servicio de replicación de directorios, que funciona sobre el transporte RPC. El mismo protocolo se utiliza para realizar el ataque DCSync. El agente de sincronización local envía toda la información y los atributos del usuario a Entra ID a través del puerto 443. Una vez que Entra recibe estos datos, los procesa y completa los detalles necesarios dentro de su entorno, completando así el proceso de sincronización inicial.
Parte 2: Escritura diferida de contraseñas Entra ID A las instalaciones locales
La segunda parte del proceso de sincronización se lleva a cabo cuando se habilita la reescritura de contraseñas en Entra AD Connect. Esta función permite la sincronización de contraseñas desde la nube al entorno local, de modo que cuando un usuario cambia su contraseña en la nube, el cambio también se refleja en el entorno local. Esto garantiza una sincronización precisa entre los dos entornos, que es una de las principales razones para conectarlos: permitir que los usuarios inicien sesión con la misma contraseña en todas las aplicaciones y entornos de la organización.
Cuando se inicia una acción de restablecimiento de contraseña para un usuario en Entra ID, el sistema primero busca el nombre de usuario para verificar que exista en Entra IDSi se descubre al usuario, se realiza una comprobación de permisos para ver si la persona que intenta restablecer la contraseña tiene un rol que le permite realizar esta acción. Si el usuario tiene los permisos necesarios, Entra ID Envía el nombre de usuario y la nueva contraseña al Entra Service Bus.
El agente de sincronización que se ejecuta en las instalaciones recupera esta información. Dado que el usuario MSOL creado por Entra Connect tiene permisos de DS Sync pero solo para lectura, no utiliza el protocolo RPC para restablecer la contraseña. En su lugar, realiza una solicitud LDAP para localizar al usuario correspondiente en Active Directory e intenta actualizar la contraseña con la solicitud utilizando la operación “IADsUser.ChangePassword”.
En esta etapa, se realiza una comprobación de seguridad crucial: cuando el controlador de dominio (DC) recibe la solicitud LDAP, Active Directory El sistema de permisos verifica si el usuario que intenta cambiar la contraseña tiene los permisos necesarios para restablecer la contraseña del usuario de destino. Esto se hace examinando la ACL del usuario de destino. Si el usuario MSOL no tiene el permiso "Restablecer contraseña" sobre la entidad, se envía un error a Entra ID, lo que indica que la actualización de la contraseña falló debido a permisos insuficientes. Si está presente el permiso “Restablecer contraseña”, el cambio de contraseña se completó correctamente.
La brecha de seguridad
Durante el proceso de sincronización, noté que no hay una cobertura completa de qué usuarios pertenecen a grupos privilegiados o tienen permisos más altos. En consecuencia, en el entorno de Entra, estos usuarios no reciben automáticamente el mismo estado privilegiado que reciben en las instalaciones. De manera predeterminada, los usuarios híbridos no reciben la misma protección que los roles privilegiados en Entra durante la sincronización inicial, a menos que el administrador de red asigne manualmente estos privilegios y protecciones dentro de la red. Entra ID.
Al comprender las capacidades de sincronización entre los dos entornos y la capacidad de sincronizar las credenciales desde Entra a las instalaciones locales, surge la pregunta: ¿cuáles son los riesgos potenciales involucrados?
El riesgo principal es obtener permisos elevados en AD local a través de un rol de administrador débil en Entra. Mientras está en AD, un usuario puede recibir permisos privilegiados, pero no necesariamente pertenecer a un grupo protegido, lo que lo deja expuesto a ataques. El mismo riesgo existe en este flujo de ataque:
Una vez que un atacante obtiene el control de un Entra ID Los usuarios con el rol de Administrador de contraseñas asignado pueden aprovechar su permiso de restablecimiento de contraseña para elevar sus permisos, incluso si no tienen un usuario local. Al restablecer la contraseña de un usuario con permisos de AD elevados, como un usuario del grupo Administradores de DNS, podrían obtener el control de la cuenta y potencialmente aumentar los privilegios dentro del dominio local.
Todo lo que el atacante necesita hacer es iniciar sesión con la cuenta de usuario correcta, que tenga al menos el rol de Administrador de contraseñas. Entra IDNo importa si usan la interfaz en https://entra.microsoft.com or https://portal.azure.comUna vez que inician sesión, seleccionan el usuario local de destino y simplemente restablecen su contraseña. Esto le permite al atacante iniciar sesión en el entorno local con la cuenta cuya contraseña cambiaron.
Es importante tener en cuenta que si el usuario objetivo es parte de un grupo protegido en el entorno local, el ataque fallará.
Esto se debe a que la administración de permisos para usuarios protegidos en las instalaciones impide que un usuario realice cambios. Entra ID Conectar la cuenta a los usuarios de esos grupos protegidos. En un entorno local, los grupos protegidos se pueden identificar examinando la adminCount atributo del grupo. Si el adminCount Si el atributo está establecido en “1”, indica que el grupo se considera protegido. Estos grupos protegidos siguen una plantilla de permisos fija que se aplica periódicamente. Cada hora, se activa un mecanismo de protección en Active Directory ejecuta un proceso que verifica si los permisos del grupo en el ACL Coincidir con los permisos definidos en la plantilla. Si hay una discrepancia, el proceso restablece los permisos para que coincidan con la plantilla.
Este proceso es gestionado por un mecanismo llamado Propiedad SD (Propagador de descriptores de seguridad) y la plantilla de permisos se conoce como Soporte SD de administrador.
Escenarios de ataque que explotan esta debilidad
Administradores en la sombra
Administradores en la sombra son usuarios que pueden restablecer la contraseña a un administrador pero que no pertenecen a ningún grupo de administradores. Dado que tanto en las instalaciones Active Directory y Entra ID Si se trata a estos administradores de la sombra como usuarios normales (sin protección especial por parte de grupos de usuarios privilegiados), un atacante puede aprovechar su capacidad para restablecer la contraseña de un usuario privilegiado en Entra. Esto significa que el atacante también puede restablecer la contraseña de ese usuario en el entorno local.
Este escenario proporciona a los atacantes una vía clara para escalar privilegios y expandir su control en la red, aprovechando los permisos elevados del usuario comprometido.
Grupo de administración de DNS
Otro ejemplo es el grupo de administradores de DNS. Los administradores de DNS administran componentes críticos de la infraestructura de red, específicamente servidores DNS. Dado que el grupo de administradores de DNS está configurado como un grupo privilegiado sin protección adicional en las instalaciones, un atacante podría restablecer fácilmente la contraseña de un miembro del grupo de administradores de DNS a través de Entra. Esto le daría control total sobre esa cuenta en el entorno local.
Con el control de una cuenta de administrador de DNS, el atacante podría interrumpir significativamente las operaciones de la red. Podría modificar los registros DNS para redirigir el tráfico de red interno, realizar Hombre en el medio (MITM) ataques redirigiendo el tráfico a través de servidores que controlan o alterando la configuración de DNS para enviar a los usuarios a sitios web maliciosos.
Propietarios del creador de directivas de grupo
Los propietarios de creadores de directivas de grupo son otro ejemplo de un grupo que podría ser un grupo privilegiado sin protección adicional. Los miembros de este grupo pueden modificar los objetos de directiva de grupo (GPO) que hayan creado. Si un atacante obtiene acceso a una cuenta de este grupo, puede aprovechar sus permisos para modificar los GPO existentes que pueden incluir scripts o configuraciones dañinos, como scripts que podrían robar credenciales o instalar malware.
Grupo de editores de certificados
Editores de certificados El grupo es otro ejemplo de un grupo privilegiado que no siempre recibe la atención necesaria en materia de seguridad. A los miembros de este grupo se les concede la capacidad de publicar certificados para Active Directory, que desempeña un papel clave en la organización. Infraestructura de clave pública (PKI). Si un atacante obtiene acceso a una cuenta que forma parte de la Editores de certificados grupo, pueden emitir o manipular certificados, lo que genera graves riesgos de seguridad.
Por ejemplo, el atacante podría publicar un certificado malicioso o no autorizado para hacerse pasar por usuarios o servicios confiables, lo que les permite realizar ataques MITM, descifrar comunicaciones seguras o eludir autenticación controles. El atacante también podría aumentar los privilegios mediante la emisión de certificados para cuentas con privilegios elevados, como administradores de dominio, lo que provocaría un compromiso total del dominio.
Mitigación de ataques
1. Cuando utilice una configuración de identidad híbrida, siempre compare los permisos entre su entorno local y Entra. Además, asegúrese de que los usuarios privilegiados que solo existen en Entra y no tienen cuentas correspondientes en el entorno local no reciban permisos de restablecimiento de contraseña. Esto ayuda a evitar el acceso externo no autorizado y el control sobre su entorno.
2. Al configurar la sincronización entre servidores locales Active Directory (AD) y Entra IDEs fundamental verificar siempre los permisos asignados a los grupos privilegiados en su entorno local. En concreto, debe asegurarse de que estos grupos no tengan permisos innecesarios para cambiar contraseñas.
Si observa que los miembros de grupos privilegiados pueden cambiar sus contraseñas, tiene dos opciones para solucionar este problema:
- Eliminar manualmente los permisos: puede ajustar manualmente los permisos para cada grupo privilegiado para eliminar la capacidad de cambiar contraseñas.
- Aproveche la plantilla AdminSDHolder: Alternativamente, puede modificar la adminCount atributo de los grupos privilegiados para que sea igual a “1”, protegiéndolos así.
AdminSDHolder es una plantilla de seguridad en Active Directory que define y aplica permisos de seguridad para los miembros de grupos protegidos. Al agregar los grupos privilegiados a esta plantilla, puede eliminar automáticamente sus permisos de cambio de contraseña.
