Cuidado con las políticas de sincronización entre inquilinos de Azure AD demasiado permisivas

Las técnicas de movimiento lateral han sido durante años un componente crítico de los ataques tradicionales a la red, permitiendo a los grupos de ransomware llegar a los controladores de dominio y desplegar sus ataques paralizantes y altamente perturbadores, a los grupos de ciberespionaje lograr la persistencia y acceder a los sistemas que contienen propiedad intelectual sensible, y a los grupos de ciberdelincuentes saltar a segmentos sensibles de la red para llegar a los cajeros automáticos y otros sistemas financieros. Con el despliegue acelerado de redes híbridas que combinan infraestructura local y en la nube, los atacantes están buscando nuevas tácticas para lograr el movimiento lateral en estos nuevos entornos. 

Una de estas técnicas ha sido ideada y documentada recientemente por investigadores de la empresa de seguridad Vectra AI y consiste en abusar de una función de Azure Active Directory (AD) denominada sincronización entre inquilinos (CTS o Cross-Tenant Synchronization) que permite a las organizaciones sincronizar usuarios y grupos entre diferentes instancias de Azure AD para que esos usuarios obtengan acceso a aplicaciones de Microsoft y de otras empresas vinculadas a diferentes inquilinos o tenants. 

Esta es una característica útil para corporaciones multinacionales o conglomerados empresariales donde sus sucursales locales o diferentes negocios podrían estar operando en diferentes inquilinos de Azure AD, pero algunos de sus usuarios necesitan acceder a aplicaciones o recursos de una sucursal diferente o empresa hermana. 

"Este vector de ataque permite a un atacante que opera en un inquilino comprometido abusar de una configuración de sincronización entre inquilinos mal configurada y obtener acceso a otros inquilinos conectados o implementar una configuración CTS falsa para mantener la persistencia dentro del inquilino", dijeron los investigadores de Vectra AI en su nuevo informe. "No hemos observado el uso de esta técnica en el ecosistema, pero dado el abuso histórico de una funcionalidad similar, presentamos detalles para que los defensores entiendan cómo se presentaría el ataque y cómo monitorear su ejecución". 

Abuso de relaciones de confianza y configuraciones débiles de Azure AD 

La CTS funciona permitiendo a un inquilino de origen sincronizar usuarios en uno de destino. Esto se hace a través de peticiones push desde el inquilino de origen y basándose en políticas de acceso entre inquilinos (CTA) configuradas en ambos lugares. 

Por ejemplo, para poder sincronizar usuarios, el inquilino de origen debe tener una política de acceso de salida hacia el inquilino de destino y el inquilino de destino debe tener una política de acceso de entrada que permita la sincronización de usuarios del inquilino de origen. Un inquilino de origen también puede tener una política de acceso entrante entre inquilinos y ser a su vez un objetivo para los usuarios sincronizados de otro inquilino, creando una red de enlaces de sincronización entre inquilinos. 

Al igual que con todas las técnicas de movimiento lateral, el abuso de CTS implica un supuesto compromiso de credenciales privilegiadas dentro de un inquilino. Para que un ataque funcione, tanto el inquilino de origen como el de destino deben tener licencias Azure AD Premium P1 o P2 para que CTS esté disponible. El atacante necesita tener acceso a una cuenta con rol de administrador de seguridad para configurar políticas de acceso entre inquilinos, un rol de administrador de identidad híbrida para cambiar la configuración de sincronización entre inquilinos, o un rol de administrador de nube o administrador de aplicaciones para asignar nuevos usuarios a una configuración CTS existente. Por lo tanto, dependiendo de las políticas de acceso entre inquilinos y de la configuración del CTS existentes en un inquilino, así como de los privilegios obtenidos por el atacante, existen diferentes formas en las que se puede abusar de esto para el movimiento lateral o la persistencia. 

En el ataque de prueba de concepto de Vectra AI, se asume que el inquilino ya tiene políticas de acceso entre inquilinos configuradas. En primer lugar, el atacante utilizaría el shell de comandos admin para listar todos los inquilinos con los que el inquilino actual tiene políticas de acceso. A continuación, procedería a revisar cada una de las políticas para identificar un inquilino para el que exista una política de salida. Esto significa que el inquilino actual está configurado para sincronizar usuarios en ese inquilino de destino. 

El siguiente paso sería localizar el ID de la aplicación que se ejecuta dentro del inquilino comprometido y que es responsable de realizar la sincronización para poder modificar su configuración. Los investigadores de Vectra crearon y publicaron un script PowerShell que automatiza todo el proceso. 

"No hay una forma directa de encontrar la aplicación de sincronización CTS vinculada al inquilino objetivo", dijeron los investigadores. "El atacante puede tratar de validar las credenciales con el inquilino de destino para, en última instancia, encontrar la aplicación que aloja el trabajo de sincronización con el inquilino de destino. Se puede hacer a través de un módulo simple". 

Después de identificar la aplicación de sincronización, el atacante puede añadir la cuenta comprometida para la que ya tiene credenciales al ámbito de sincronización o puede revisar el ámbito de sincronización de la aplicación, que, por ejemplo, podría indicar que todos los usuarios de un grupo en particular se están sincronizando en el inquilino de destino. Entonces podrían intentar añadir directa o indirectamente su usuario comprometido a ese grupo. 

Además de utilizar un inquilino comprometido como fuente de movimiento lateral, el CTS también puede utilizarse como puerta trasera para mantener la persistencia en un inquilino comprometido. Por ejemplo, el atacante podría crear una política de acceso cruzado entrante en el inquilino víctima para permitir que un inquilino externo bajo su control sincronice usuarios en él. También podría activar la opción de ‘consentimiento automático del usuario’ para que no se pidiera consentimiento al usuario sincronizado. 

El resultado sería que el atacante podría sincronizar nuevos usuarios de su inquilino externo en el inquilino víctima en cualquier momento en el futuro para acceder a los recursos, incluso si pierden el acceso a la cuenta inicial que comprometieron. 

Cómo defenderse contra la sincronización entre inquilinos comprometida 

Dado que esta técnica presupone la existencia de una cuenta comprometida, las organizaciones deben aplicar prácticas de seguridad estrictas y supervisar las cuentas, especialmente aquellas con privilegios administrativos. Los inquilinos que tengan activado el CTS deben evitar las políticas de acceso entrante entre inquilinos que permitan sincronizar todos los usuarios, grupos o aplicaciones de un inquilino de origen. 

"Implemente una configuración de CTA entrante menos inclusiva, como definir explícitamente las cuentas (si es posible) o los grupos que pueden obtener acceso a través de CTS", dijeron los investigadores de Vectra AI. "Combine la política de CTA con políticas de acceso condicional adicionales para evitar accesos no autorizados".