Detecciones

Permisos de aplicación peligrosos que afectan al inquilino

HIGH

Idioma:

Descripción

Microsoft expone las API a través de aplicaciones en Entra ID para permitir que las aplicaciones de terceros realicen acciones en Microsoft Entra ID, Microsoft 365 (O365), la nube de Azure, etc. Los “permisos de API” protegen el acceso a estas API, que solo deben estar a disposición de las entidades de servicio que los necesitan. La aprobación de permisos se denomina “asignación del rol de aplicación” o “concesión de consentimiento”.

Ciertos permisos de algunas API de Microsoft (consulte a continuación) pueden representar una amenaza grave a la totalidad del inquilino de Microsoft Entra, ya que una entidad de servicio con estos permisos se torna muy potente, a la vez que es más discreta que un usuario con un rol de administrador potente, como un administrador global. Si un atacante se aprovecha de esto, podría saltarse la autenticación multifactor (MFA) y resistir los restablecimientos de contraseña de los usuarios.

Los permisos, cuando son legítimos, aumentan la superficie de ataque del inquilino. Cuando no son legítimos, pueden tratarse de un intento malintencionado de aplicar el método de escalamiento de privilegios o de persistencia.

Hay dos tipos de permisos de API en Microsoft Entra ID, como se describe en la documentación de Microsoft Información general sobre los permisos y el consentimiento:

  • Permisos de aplicación: este indicador de exposición examina este primer tipo; consulte el indicador de exposición relacionado “Permisos de aplicación peligrosos que afectan a los datos” para ver las amenazas a los datos confidenciales del entorno. El consentimiento proviene de los administradores y los permisos se aplican a todo el inquilino. Microsoft los describe de la siguiente forma:

Los permisos de aplicación se usan por las aplicaciones que se ejecutan sin necesidad de que un usuario inicie sesión. Por ejemplo, las aplicaciones que se ejecutan como servicios en segundo plano o los demonios. Los permisos de aplicación pueden ser aceptados solo por un administrador.

  • Permisos delegados: consulte el indicador de exposición relacionado “Permisos delegados peligrosos que afectan al inquilino”.

Este indicador de exposición (IoE) solo informa acerca de las entidades de servicio, ya que los permisos de API solo se aplican a las entidades de servicio, no a los usuarios.

Este IoE hace un seguimiento de los siguientes permisos peligrosos que permiten acceder a Microsoft Graph API y la versión heredada de Azure AD Graph API:

  • AdministrativeUnit.ReadWrite.All: permite a los atacantes quitar un Administrador global de una unidad administrativa de administración restringida (RMAU) para luego restablecer la contraseña si se combina con otros permisos.
  • Application.ReadWrite.All: permite a los atacantes inyectar credenciales de autenticación en aplicaciones con privilegios más elevados, lo que permite el acceso no autorizado hasta un Administrador global a través de la suplantación de identidad.
  • Application.ReadWrite.OwnedBy: es igual a Application.ReadWrite.All, pero se aplica únicamente a las entidades de servicio que son propiedad de la entidad de servicio informada.
  • AppRoleAssignment.ReadWrite.All: permite a los atacantes otorgarse a sí mismos el permiso RoleManagement.ReadWrite.Directory.
  • DeviceManagementConfiguration.ReadWrite.All: permite a los atacantes vulnerar dispositivos administrados por Intune mediante la implementación de scripts de administración malintencionados, tal como lo describe Mandiant en (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments (texto en inglés). Esto puede permitir el escalamiento de privilegios hasta el Administrador global si un administrador usa un dispositivo administrado por Intune.
  • DeviceManagementRBAC.ReadWrite.All: permite a los atacantes asignar roles privilegiados de Intune a una cuenta que controlan, lo que les permite ejecutar comandos arbitrarios en dispositivos de Intune, como se describe en DeviceManagementConfiguration.ReadWrite.All.
  • Directory.ReadWrite.All: permite a los atacantes agregarse a sí mismos como miembros de grupos a los que no se les pueden asignar roles, lo que les permitiría obtener privilegios en la nube de Azure. Esto puede permitirles obtener acceso adicional a los recursos de Azure, lo que puede llevar a un escalamiento de privilegios hasta el Administrador global en Entra ID (por ejemplo, a través de identidades administradas) o incluso a Administradores de dominio en Active Directory (por ejemplo, a través de VM de controlador de dominio alojadas en Azure).
  • EntitlementManagement.ReadWrite.All: permite a los atacantes actualizar la política de asignación de un paquete de acceso que otorga el rol Administrador global, lo que les permite solicitar el rol sin aprobación.
  • Group.ReadWrite.All: es igual a Directory.ReadWrite.All
  • GroupMember.ReadWrite.All: es igual a Directory.ReadWrite.All
  • Organization.ReadWrite.All: permite a los atacantes agregar un certificado raíz de confianza a Entra ID y autenticarse como cualquier usuario, incluidos aquellos asignados al Administrador global. Esto exige que la autenticación basada en certificados (CBA) esté habilitada o, si no lo está, el permiso Policy.ReadWrite.AuthenticationMethod para habilitar la CBA de antemano.
  • Policy.ReadWrite.AuthenticationMethod: permite a los atacantes habilitar el método de autenticación Pase de acceso temporal (TAP), que es un requisito previo para explotar el permiso UserAuthenticationMethod.ReadWrite.All cuando se combina con este. Como alternativa, permite a los atacantes habilitar la autenticación basada en certificados (CBA) para explotar el permiso Organization.ReadWrite.All.
  • Policy.ReadWrite.PermissionGrant: permite a los atacantes crear una política de concesión de permisos para una entidad de servicio controlada, lo que otorga el permiso RoleManagement.ReadWrite.Directory y habilita la explotación.
  • PrivilegedAccess.ReadWrite.AzureADGroup: permite a los atacantes agregar una cuenta de usuario controlada como miembro de un grupo asignado al rol Administrador global.
  • PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup: es igual a PrivilegedAccess.ReadWrite.AzureADGroup.
  • PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup: permite a los atacantes hacer que una cuenta de usuario controlada sea elegible para un grupo asignado al rol Administrador global y luego activar la membresía para escalar privilegios.
  • RoleAssignmentSchedule.ReadWrite.Directory: permite a los atacantes asignar el rol Administrador global a una cuenta de usuario controlada mediante la creación de una asignación de rol de PIM activa.
  • RoleEligibilitySchedule.ReadWrite.Directory: permite a los atacantes hacer que una cuenta de usuario controlada sea elegible para el rol Administrador global y luego activarla para escalar privilegios.
  • RoleManagement.ReadWrite.Directory: permite a los atacantes elevarse a sí mismos hasta el rol Administrador global.
  • RoleManagementPolicy.ReadWrite.AzureADGroup: permite a los atacantes quitar asignaciones de roles de grupo y restricciones de activación, como requisitos de MFA o aprobación de administradores, para aprovechar PrivilegedAccess.ReadWrite.AzureADGroup, PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup o PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup y seguir la misma ruta que esos permisos en un inquilino con configuraciones de PIM estrictas.
  • RoleManagementPolicy.ReadWrite.Directory: permite a los atacantes quitar asignaciones de roles de Entra y restricciones de activación, como requisitos de MFA o aprobación de administradores, para aprovechar RoleAssignmentSchedule.ReadWrite.Directory o RoleEligibilitySchedule.ReadWrite.Directory y seguir la misma ruta que esos permisos en un inquilino con configuraciones de PIM estrictas.
  • User.DeleteRestore.All: permite a los atacantes eliminar todas las cuentas de usuario del inquilino, por lo que deja de estar disponible, para luego exigir un rescate para restaurar una de las cuentas de emergencia. Si bien no permite el escalamiento hasta Administrador global, interrumpe el acceso.
  • User.EnableDisableAccount.All: permite a los atacantes deshabilitar todas las cuentas de usuario del inquilino, por lo que deja de estar disponible, para luego exigir un rescate para restaurar una de las cuentas de emergencia. Si bien no permite el escalamiento hasta Administrador global, interrumpe el acceso.
  • User.ReadWrite.All: permite a los atacantes editar propiedades confidenciales de una cuenta de usuario controlada, como “Id. de empleado” y “Departamento”, para convertirla en miembro de un grupo dinámico (consulte el IoE correspondiente) con permisos privilegiados de Azure asignados. Luego, pueden aprovechar los recursos de Azure para finalmente escalar hasta Administrador global.
  • User-PasswordProfile.ReadWrite.All: es igual a Directory.ReadWrite.All
  • UserAuthenticationMethod.ReadWrite.All: permite a los atacantes generar un Pase de acceso temporal (TAP) y tomar el control de cualquier cuenta de usuario del inquilino. Si el TAP aún no está habilitado, deben combinar esto con Policy.ReadWrite.AuthenticationMethod para habilitar el TAP como método de autenticación en el inquilino (consulte el IoE correspondiente).

Este IoE también hace un seguimiento de este permiso peligroso de la API del “servicio de sincronización de Microsoft Entra AD”:

  • ADSynchronization.ReadWrite.All: permite que los atacantes llamen a la API de sincronización sin documentar, lo que les permite modificar cuentas de usuario híbridas y restablecer sus contraseñas.

Las aplicaciones legítimas con estos permisos peligrosos solicitan un acceso que puede ser excesivamente amplio. Esto también puede indicar un ataque de phishing denominado “concesión de consentimiento ilícito”, en el que un atacante logra obtener el consentimiento de un administrador.

De manera predeterminada, este IoE ignora las entidades de servicio deshabilitadas porque los atacantes no pueden usarlas de inmediato.

Referencias externas:

Solución

Para empezar, establezca si la entidad de servicio informada que tiene el permiso es legítima. Tenga en cuenta que, desde el punto de vista técnico, un ataque de phishing puede suplantar el nombre para mostrar. Si la entidad de servicio parece pertenecer a un proveedor de software conocido, pídale que confirme que el identificador de la aplicación informada le pertenece. Si la entidad de servicio es ilegítima y falsifica un nombre de aplicación conocido, debe llevar a cabo un análisis forense.

  • Si la entidad de servicio es legítima:
    • Identifique el propietario y el rol para evaluar si realmente necesita estos permisos peligrosos.
      • Si se trata de una aplicación interna, evalúe sus funcionalidades y reduzca los permisos según el principio de privilegios mínimos, como se describe en la sección Consentimiento y autorización de la documentación de Microsoft Graph API. En esta guía se especifican los permisos mínimos necesarios para cada API.
      • Si se trata de una aplicación de terceros, solicite al proveedor que disminuya los permisos necesarios o que, al menos, documente el motivo por el cual son necesarios.
    • Como medida de defensa profunda, si tiene las licencias Premium de Identidades de carga de trabajo necesarias, considere usar Acceso condicional para las identidades de carga de trabajo. Esto le permite restringir las entidades de servicio de alto riesgo a ubicaciones de confianza conocidas y limitar el acceso en función de inicios de sesión de riesgo.

Los * permisos de aplicación siempre requieren el consentimiento del administrador. Capacite a estos administradores en la detección de aplicaciones sospechosas y permisos confidenciales, incluidos los permisos de aplicación para todo el inquilino. Esto debe formar parte de un esfuerzo más amplio de gobierno de las aplicaciones.

  • Quite un permiso si cree que es ilegítimo. Tenable recomienda guardar primero las pruebas, en caso de que tenga pensado llevar a cabo una investigación forense más exhaustiva. El portal de Microsoft Entra tiene una característica dedicada para revisar los permisos concedidos a aplicaciones empresariales.

Además, Microsoft publicó dos guías sobre cómo llevar a cabo una investigación de la concesión de consentimiento de la aplicación y sobre la detección y corrección de concesiones de consentimiento ilícitas.

Asegúrese de quitar el permiso peligroso de la entidad de servicio (que se encuentra en el menú “Aplicaciones empresariales” del portal), en lugar de quitarlo de la aplicación (que se encuentra en el menú “Registros de aplicaciones”). Quitarlo de la aplicación solo elimina la solicitud de permiso y no afecta la asignación real del permiso.

En particular para el permiso DeviceManagementConfiguration.ReadWrite.All, puede usar directivas de acceso para requerir varias aprobaciones administrativas. Este enfoque garantiza que la creación o la modificación de scripts de administración requieran la validación por parte de otra cuenta, lo que reduce el riesgo de que una única aplicación introduzca cambios malintencionados.

Finalmente, habilite los registros de actividad de Graph API para capturar información detallada sobre los eventos de Graph API, lo que ayudará a su SOC o SIEM a detectar actividades sospechosas o llevar a cabo investigaciones forenses en caso de ataque. Además, supervise los inicios de sesión de las entidades de servicio y configure alertas para comportamientos sospechosos, en particular para las entidades de servicio de alto riesgo señaladas aquí.

Detalles del indicador

Nombre: Permisos de aplicación peligrosos que afectan al inquilino

Nombre en clave: DANGEROUS-APPLICATION-PERMISSIONS-AFFECTING-THE-TENANT

Gravedad: High

Tipo: Microsoft Entra ID Indicator of Exposure

Información de MITRE ATT&CK: