Configuraciones híbridas de identidad mal configuradas
En las siguientes subsecciones, presentamos detalles sobre los diferentes escenarios que involucran configuraciones híbridas de identidad mal configuradas que podrían llevar a comprometer Microsoft Entra ID. Servicios de Federación de Directorio Activo comprometidos u otros sistemas de identidad federada equivalentes
Servicios de federación de Active Directory o sistemas de identidad federados equivalentes comprometidos
La configuración de identidades híbridas de cada organización es única, y muchas organizaciones utilizan un proveedor de identidades federadas cuando los usuarios se autentican en aplicaciones en la nube, como Microsoft 365. Estos proveedores de identidades federadas permiten la autenticación de los usuarios. Aunque un porcentaje significativo de organizaciones se ha pasado ahora a la autenticación nativa de la nube en Microsoft Entra ID, estos proveedores de identidad federada, como AD FS y otros proveedores de identidad de terceros, siguen utilizándose.
Microsoft IR considera que los proveedores de identidad federada presentan un punto ciego administrativo dentro de las organizaciones. La identidad híbrida puede ser arquitectónicamente complicada con muchas piezas cambiantes, lo que a menudo se presta a la supervisión operativa. Asegurar estos sistemas de identidad híbridos es complejo, especialmente las soluciones heredadas, y una sola configuración errónea puede llevar a un compromiso significativo de todo el plano de identidad de una organización.
Los proveedores de identidades federadas son uno de los objetivos favoritos de algunos actores de estados-nación: estos actores entienden que si pueden comprometer el plano de identidad de nivel 0, pueden permanecer en un entorno sin ser detectados durante largos periodos de tiempo y hacerse con el control de todas las identidades. Microsoft ha publicado blogs sobre los sofisticados ciberataques contra AD FS, como MagicWeb. También se profundizó en esta táctica en la serie Microsoft IR Cyberattack.
Microsoft IR también se ha visto involucrado en múltiples incidentes en los que el Token Signing Certificate (TSC) fue robado de servidores de federación locales. Utilizando este certificado robado, los atacantes podían falsificar sus propios tokens SAML y autenticarse con éxito en Microsoft Entra ID. Con este certificado, un actor de amenaza puede autenticarse exitosamente como cualquier usuario en el tenant con cualquier reclamo sin requerir las credenciales del usuario.
Recomendaciones
- Microsoft IR recomienda firmemente pasar a la autenticación nativa de Microsoft Entra ID y desmantelar AD FS (u otros proveedores de identidad federados) siempre que sea posible. Esto reduce la complejidad general del plano de identidad de la organización y facilita la protección de las identidades.
- Si debe utilizar proveedores de identidad federados, es importante protegerlos y supervisarlos adecuadamente.
- Para las organizaciones que utilizan AD FS, asegúrese de que esté instalado el cliente Microsoft Entra Connect Health. Este cliente correlaciona múltiples Event IDs de AD FS y enriquece los datos de inicio de sesión de Microsoft Entra ID con esa información. Esto puede ayudar a crear reglas de detección y caza de amenazas y servir como una valiosa fuente de datos forenses en el caso de un compromiso. Asegúrese de que el registro apropiado está habilitado para AD FS y que esos registros se envían a un SIEM como Microsoft Sentinel, donde se pueden crear reglas de detección, tanto para el usuario como para el compromiso a nivel de sistema, incluyendo el robo de certificados. Si un atacante puede robar el certificado de firma de token de AD FS, puede falsificar sus propios tokens para autenticarse en Entra ID. En estos casos, el Entra ID alertará sobre anomalías con el emisor del token. Si su solución MFA actual está integrada a AD FS, considere el uso de opciones MFA nativas integradas, especialmente resistentes al phishing, disponibles en Entra ID.
- Para las organizaciones con Microsoft Defender for Identity y Microsoft Defender for Endpoint, asegúrese de que los agentes están desplegados en AD FS. Ambos productos tienen capacidades específicas para detectar ciberataques contra AD FS.
- En el caso de otros proveedores de identidades federadas, asegúrese de que esos servicios están configurados de acuerdo con las mejores prácticas y de que tanto la telemetría de inicio de sesión de los usuarios como los eventos de auditoría a nivel de sistema se envían a un SIEM central. Los actores de amenazas pueden permanecer en los entornos, especialmente en los sistemas de identidad, durante meses o años antes de ser detectados, por lo que es importante que los registros clave se conserven durante un largo periodo de tiempo. Esto ayuda a los equipos de respuesta a comprender cómo se obtuvo el acceso inicial y garantizar el desalojo completo del actor de la amenaza del entorno.
Sistemas de identidad complejos
Los sistemas de identidad modernos son complejos y han cambiado significativamente a medida que ha evolucionado la forma de trabajar. Las organizaciones pueden tener varios proveedores de identidad, proveedores de AMF de terceros, sistemas personalizados diseñados para la incorporación y la salida de usuarios y otros sistemas interconectados. Todos estos sistemas forman una cadena de confianza de extremo a extremo que es un objetivo atractivo para los actores de amenazas. Cuanto más complejos son estos sistemas, más difícil resulta protegerlos adecuadamente. Las organizaciones pueden tener dispositivos de red que completan la autenticación 802.1x, sistemas personalizados de gobernanza de identidades que gestionan el ciclo de vida de los usuarios, autoridades de certificación y dispositivos HSM. Cada sistema requiere parches y gestión de vulnerabilidades, supervisión y mantenimiento suficientes y conocimientos humanos para garantizar una configuración segura. Además, la gestión de certificados y credenciales en todos estos sistemas añade más complejidad.
Por ejemplo, AD FS es de confianza para emitir tokens para los usuarios. Otros sistemas, como Microsoft Entra ID, aceptan esos tokens y autorizan a los usuarios a los que representan. Si AD FS se ve comprometido, la legitimidad de esos tokens queda en entredicho. Cada sistema debe estar adecuadamente protegido y supervisado para garantizar una confianza total, ya que el compromiso de un solo sistema podría llevar al compromiso de todos ellos.
Si un usuario inicia sesión en Microsoft 365 y la autenticación se realiza a través de un proveedor de identidades ajeno a Microsoft y, a continuación, otro proveedor proporciona la MFA, se añade una complejidad significativa al flujo de autenticación. Por ejemplo, diferentes sistemas pueden ser responsables de la validación de contraseñas, la comprobación de certificados, la realización de MFA y la emisión de tokens; puede tratarse de sistemas locales, plataformas ajenas a Windows o soluciones en la nube de terceros. En estas situaciones, cada sistema que forma parte de este flujo de autenticación confía en los demás.
Por ejemplo, Microsoft IR trabajó con una organización que sufrió una vulneración a nivel de inquilino de Microsoft Entra ID. Una vez finalizada la investigación, se determinó que se había puesto en peligro un servidor local orientado a Internet, que carecía de MFA o de controles de acceso adecuados. Ese servidor ejecutaba un software personalizado diseñado para sincronizar usuarios entre varios sistemas empresariales. Una vez que el autor de la amenaza consiguió acceder al servidor, descubrió las credenciales de una cuenta de servicio de nivel de administrador global. Los servidores que alojan aplicaciones de identidad y servicios de integración clave a menudo no se rigen por las mismas normas de seguridad que los controladores de dominio, lo que reduce significativamente la seguridad de todo el plano de identidad.
Una mala configuración o un descuido administrativo en cualquiera de estos sistemas interconectados conduce a una disminución de los controles de seguridad generales. Si Microsoft Entra ID está configurado para descargar MFA a un proveedor de MFA de terceros y ese MFA está mal configurado, Microsoft Entra ID seguirá confiando en la telemetría y la configuración de ese servicio.
Recommendaciones
- Es crucial comprender todos los sistemas que forman su plano de identidad y cómo la autenticación y la autorización fluyen entre ellos. Comprenda qué sistemas son responsables de qué cargas de trabajo dentro de su cadena de confianza de identidad.
- Trate todo el sistema de autenticación como nivel 0, ya que el compromiso de un solo enlace dentro de él puede conducir a un compromiso completo.
- Garantizar que todos los sistemas están configurados de acuerdo con las mejores prácticas y que la configuración colectiva está aplicando las políticas implementadas según lo esperado.
- Para todos los sistemas que forman su plano de identidad, asegúrese de que se dispone de suficientes registros y de que los datos se conservan durante un largo periodo de tiempo, preferiblemente 2 años o más. El registro debe incluir los eventos de inicio de sesión de los usuarios, la actividad administrativa y los cambios de configuración. Disponer de un registro suficiente no sólo ayuda a detectar posibles ciberataques, sino que también puede alertar sobre cambios en cualquier sistema individual que puedan reducir la postura de seguridad general y, en caso de incidente, servir como fuente de información forense.
- Siempre que sea posible, simplifique los mecanismos de autenticación y autorización en su entorno. Esto ayuda a reducir la superficie de ataque de la identidad comprometida. Con cada sistema adicional, aumenta la sobrecarga de asegurar esos sistemas y aumenta la posibilidad de una mala configuración o compromiso de uno de ellos.
Cuentas de servicio sincronizadas comprometidas
En el mundo de las identidades híbridas, la mayoría de los usuarios y grupos se sincronizan desde el Directorio Activo local con Microsoft Entra ID. Esto es necesario para permitir a los usuarios acceder a los recursos de la nube mediante el mismo conjunto de credenciales utilizadas en las instalaciones. Sin embargo, en los compromisos vistos por Microsoft IR, las cuentas utilizadas para gestionar Microsoft Entra ID, como los administradores globales, también se han sincronizado con Microsoft Entra ID desde las instalaciones. El personal suele utilizar las mismas credenciales para gestionar ambos entornos.
Si Active Directory se ve comprometido y las credenciales para estas cuentas son encontradas por un actor de amenaza, esto les permite pasar fácilmente a Microsoft Entra ID, ampliando el alcance del compromiso. Las cuentas de servicio sincronizadas son particularmente vulnerables a la explotación. Microsoft IR ve con frecuencia cuentas de servicio utilizadas para gestionar tanto Active Directory local como Microsoft Entra ID como objetivo de los actores de amenazas. Estas cuentas generalmente tienen un alto nivel de privilegio en Microsoft Entra ID (a menudo Administrador Global) pero no están sujetas a los mismos controles como MFA o Microsoft Entra Privileged Identity Management (PIM).
Microsoft IR ha participado en numerosas investigaciones en las que el compromiso del Directorio Activo local condujo al compromiso del arrendatario de Microsoft Entra. Los actores de amenazas a veces descubren credenciales de cuentas en texto claro debido a una mala gestión de las credenciales en un entorno local. Si el actor de la amenaza ya tiene un punto de apoyo en el entorno local, a menudo no se aplican controles como MFA, ya que estas redes se consideran «de confianza».
Recomendaciones
- Microsoft IR recomienda encarecidamente que las cuentas utilizadas para administrar Microsoft Entra ID sean nativas de Microsoft Entra ID utilizando autenticación gestionada y no se sincronicen desde Active Directory local. Esto reduce el alcance del compromiso si Active Directory se ve comprometido al evitar que un actor de amenaza aproveche las mismas credenciales para comprometer Microsoft Entra ID. Encontrará orientaciones específicas para proteger Microsoft 365 de ciberataques locales en https://aka.ms/protectm365 y https://aka.ms/securitysteps.
- Cualquier cuenta que tenga privilegios en el Directorio Activo local, como los Administradores de Dominio y los respectivos grupos como Administradores de Dominio, deben ser completamente excluidos de ser sincronizados con Microsoft Entra ID.
- Las credenciales de las cuentas de servicio que interactúan con Microsoft Entra ID y Active Directory deben almacenarse de forma segura, y no en texto claro donde sean fácilmente recuperables por un actor de amenazas.
- Las cuentas privilegiadas no deben excluirse de las políticas de acceso condicional de Microsoft Entra, independientemente de la ubicación de la red. Estas cuentas deben mantenerse siempre con los más altos estándares de seguridad, específicamente el uso de Privileged Identity Management y credenciales resistentes al phishing como FIDO2, incluso para «break glass accounts».
- Las cuentas de servicio que requieren privilegios tanto en el Directorio Activo local como en Microsoft Entra ID deben tener controles técnicos específicos aplicados a ellas. Esto puede incluir acceso condicional que bloquee el acceso desde ubicaciones o direcciones IP no aprobadas, reglas de detección específicas y supervisión para alertar sobre actividades anómalas con estas cuentas.
