Entra ID configuración de usuario predeterminada del tenant restringe el registro de aplicaciones, la creación de grupos y el acceso al centro de administración

Entra ID configuración de usuario predeterminada del tenant restringe el registro de aplicaciones, solo después de que un administrador la modifica

Entra ID configuración de usuario predeterminada del tenant restringe el registro de aplicaciones, la creación de grupos y la navegación por el centro de administración — pero solo una vez que un administrador los modifica. Hasta que alguien lo hace, la línea base documentada para un usuario miembro ordinario es deliberadamente generosa, y la mayoría de los tenants nunca la revisan.

Microsoft es explícito sobre lo que puede hacer un simple usuario miembro. La referencia de permisos predeterminados indica que «los usuarios miembro pueden registrar aplicaciones, gestionar su propia foto de perfil y número de teléfono móvil, cambiar su propia contraseña e invitar a invitados B2B. Estos usuarios también pueden leer toda la información del directorio (con algunas excepciones)». La misma página indica, bajo Grupos, que los usuarios miembro pueden «Crear grupos de seguridad» y «Crear grupos de Microsoft 365»; bajo Aplicaciones, que pueden «Registrar (crear) nuevas aplicaciones» y «Enumerar la lista de todas las aplicaciones»; y bajo Roles y ámbitos, que pueden «Leer todos los roles administrativos y sus membresías» (Permisos de usuario predeterminados).

Esa es la parte incómoda. Las dos condiciones previas que hacen posible el phishing de consentimiento OAuth y el reconocimiento de directorio no son capacidades exóticas de atacante — son configuraciones del tenant. Cuatro interruptores cierran la mayor parte de la brecha, y ninguno requiere una actualización de licencia.

Cómo funciona: cuatro interruptores, tres objetos distintos

El centro de administración de Microsoft Entra presenta esto como una lista ordenada bajo Configuración de usuario y Configuración de grupo. Por debajo, estos valores se almacenan en tres lugares sin relación entre sí, y por eso los audits parciales los pasan por alto.

Los dos primeros viven en el singleton authorizationPolicy, válido para todo el tenant. Microsoft Graph documenta allowedToCreateApps como correspondiente a «la configuración Los usuarios pueden registrar aplicaciones en el menú Configuración de usuario», y allowedToCreateSecurityGroups como correspondiente a «la configuración Los usuarios pueden crear grupos de seguridad en los centros de administración de Microsoft Entra, la API o PowerShell» (defaultUserRolePermissions). El mismo objeto también contiene allowedToCreateTenants, allowedToReadOtherUsers, allowedToReadBitlockerKeysForOwnedDevice y permissionGrantPoliciesAssigned.

La creación de grupos de Microsoft 365 vive en otro lugar completamente distinto: la configuración EnableGroupCreation dentro de la plantilla Group.Unified, cuyo «valor predeterminado es true» (Información general sobre la configuración de grupos).

El cuarto interruptor es el más delicado, y se trata en su propia sección más abajo.

La cadena de ataque

Paso 1 — Obtener una cuenta ordinaria

Ningún rol, ningún consentimiento de administrador, ninguna escalada de privilegios. El password spraying, el robo de tokens por parte de un adversario intermediario (adversary-in-the-middle) o el device code phishing terminan todos en el mismo sitio: una sesión como usuario miembro estándar. Todo lo que sigue es aquello a lo que esa sesión tiene derecho de forma predeterminada.

Paso 2 — Mapear el directorio desde dentro

Los usuarios miembro pueden enumerar todos los usuarios y contactos, todos los grupos, todos los dispositivos y todas las aplicaciones, y leer todos los roles administrativos y sus membresías. En la práctica, esto significa que un atacante con una sola sesión ordinaria puede listar todos los administradores globales del tenant, identificar qué cuentas son solo en la nube, y elegir objetivos — sin tocar jamás una sola superficie de administración.

Paso 3 — Registrar una aplicación y añadirle una credencial

Con allowedToCreateApps en su valor predeterminado, la cuenta crea un registro de aplicación. Microsoft documenta la consecuencia: «cuando un usuario registra una aplicación, se le añade automáticamente como propietario de la aplicación». Los propietarios pueden entonces actualizar applications.credentials, entre otras propiedades.

Ese es el punto de pivote. Añadir un secreto o certificado controlado por el atacante a una aplicación o a un service principal está catalogado por MITRE ATT&CK como T1098.001 — Account Manipulation: Additional Cloud Credentials, que indica que «los adversarios pueden añadir credenciales para service principals y aplicaciones además de las credenciales legítimas existentes en Azure / Entra ID. Estas credenciales incluyen tanto claves x509 como contraseñas». Una credencial en un objeto de aplicación no está vinculada a la contraseña del usuario comprometido, por lo que restablecer esa contraseña no expulsa al atacante.

La aplicación todavía necesita permisos para ser útil, y ahí es donde entra en juego el lado del consentimiento del tenant: «de forma predeterminada, todos los usuarios pueden dar su consentimiento a aplicaciones para permisos que no requieren consentimiento del administrador» (Configurar cómo dan su consentimiento los usuarios a las aplicaciones). Cubrimos esa mitad del problema en detalle en OAuth consent phishing: cómo las aplicaciones maliciosas evitan el robo de contraseñas y en Permisos peligrosos de Graph API en el app registration de Entra.

Paso 4 — Crear un grupo que nadie gobierna

La creación de grupos de autoservicio no es, por sí misma, una escalada de privilegios — un grupo nuevo no da acceso a nada. El daño es de gobernanza. Un usuario miembro que crea un grupo normalmente se añade a sí mismo como propietario, con derechos sobre groups.members y groups.owners — con una excepción documentada: para los grupos de seguridad creados en el portal de Azure, Microsoft señala que el «propietario no se asigna automáticamente en la creación del grupo». Microsoft también señala que «los grupos de seguridad creados mediante autoservicio a través del portal Mis grupos están disponibles para que se unan todos los usuarios, ya sea con aprobación del propietario o auto-aprobados» (Configurar la administración de grupos de autoservicio).

El resultado es un directorio con miles de grupos cuya propiedad no significa nada, en el que un grupo controlado por un atacante es indistinguible del resto — hasta que un administrador le concede a ese grupo acceso a una aplicación, un sitio o una exclusión de Acceso condicional.

Por qué el interruptor del centro de administración es fricción, no un control

Este es el interruptor que más a menudo se reporta como «reforzado» y el que más se malinterpreta. La propia documentación de Microsoft incluye una advertencia sobre la tabla: la configuración Restringir el acceso al portal de administración de Microsoft Entra «limita el acceso a un conjunto de páginas del centro de administración visitadas habitualmente. No es una medida de seguridad».

El detalle merece una lectura atenta. Establecerlo en Sí «añade una capa de fricción a la navegación casual» al restringir a los no administradores la carga de páginas visitadas con frecuencia, como el inicio, la vista general del tenant y la lista de usuarios. Pero Microsoft indica que «no bloquea el acceso programático a los datos de Microsoft Entra a través de PowerShell, la API de Microsoft Graph, u otras herramientas como Visual Studio», que «no se aplica a los usuarios con un rol administrativo», y que «la mayoría de las páginas del centro de administración siguen siendo accesibles si el usuario tiene un enlace directo (profundo)».

Cada paso de la cadena de ataque anterior pasa por Microsoft Graph. Ninguno se ve afectado por este interruptor.

Hay una segunda consecuencia para los auditores: a diferencia de las otras tres configuraciones, esta no tiene ninguna propiedad en el recurso authorizationPolicy. Su lista de propiedades documentada — tanto en v1.0 como en beta — contiene defaultUserRolePermissions, guestUserRoleId, allowInvitesFrom, blockMsolPowerShell y similares, y nada para el acceso al portal de administración. Si la línea base de su tenant afirma leer esta configuración desde Graph, verifique qué está leyendo realmente.

🚨 Peligro: no cuente el interruptor del portal como un control compensatorio para un registro de aplicaciones abierto. La recomendación de Microsoft es usar una directiva de Acceso condicional dirigida a la API Windows Azure Service Management para bloquear el acceso no administrativo a los endpoints de gestión de Azure.

Detección

Lea el estado real en lugar del renderizado del centro de administración. Tres de los cuatro parámetros se pueden recuperar con ámbitos de solo lectura; el cuarto — el interruptor del centro de administración — no tiene ninguna propiedad que leer, por la razón indicada arriba.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
$policy.defaultUserRolePermissions

$settings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupSettings"
$settings.value

Un tenant que nunca ha sido reforzado devuelve algo parecido a esto, con una colección groupSettings vacía:

{
  "allowedToCreateApps": true,
  "allowedToCreateSecurityGroups": true,
  "allowedToCreateTenants": true,
  "allowedToReadOtherUsers": true,
  "permissionGrantPoliciesAssigned": ["managePermissionGrantsForSelf.microsoft-user-default-legacy"]
}

Combine la lectura de configuración con el registro de auditoría. Estos nombres de actividad son exactos, y todos son accesibles en el registro de auditoría de Microsoft Entra:

Fuente de cada nombre de actividad: la referencia de actividades del registro de auditoría de Microsoft Entra.

De aquí se derivan dos detecciones prácticas. Primero, alerte sobre Add application o Add service principal cuando el principal que lo origina no posee ningún rol de directorio — en un tenant con una población de desarrolladores controlada, eso debería ser una lista corta. Segundo, alerte sobre Update authorization policy sin condiciones; hay muy pocas razones legítimas para que esa directiva cambie, y un atacante que alcance el rol de Administrador de roles con privilegios la usará para reabrir lo que usted cerró. Si su tenant no retiene estos registros el tiempo suficiente para investigar, corrija eso primero — vea Retención de registros de Entra ID y configuración de diagnóstico.

Remediación

1. Cierre los permisos del rol de usuario predeterminado. El ejemplo de PowerShell de Microsoft para desactivar la creación de aplicaciones sirve de base; las dos propiedades adicionales están documentadas en el mismo objeto.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$params = @{
    defaultUserRolePermissions = @{
        allowedToCreateApps           = $false
        allowedToCreateSecurityGroups = $false
        allowedToCreateTenants        = $false
    }
}

Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Establecer allowedToCreateTenants en $false restringe la creación de tenants al rol Tenant Creator. Esto importa más de lo que parece: Microsoft señala que «de forma predeterminada, el usuario que crea un tenant de Microsoft Entra recibe automáticamente el rol de Administrador global», y el evento se registra como Create Company.

2. Cierre la creación de grupos de Microsoft 365 y delegúela. Esto requiere un objeto groupSettings creado a partir de la plantilla Group.Unified, porque un tenant predeterminado no tiene ninguno. Obtenga primero el id de la plantilla de su propio tenant con GET https://graph.microsoft.com/v1.0/groupSettingTemplates en lugar de codificarlo directamente.

{
  "templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
  "values": [
    { "name": "EnableGroupCreation", "value": "false" },
    { "name": "GroupCreationAllowedGroupId", "value": "<object-id-of-your-approved-creators-group>" }
  ]
}

GroupCreationAllowedGroupId está documentado como «el identificador del grupo de seguridad cuyos miembros pueden crear grupos de Microsoft 365 incluso cuando EnableGroupCreation está en false» — esa es su vía de escape, y no requiere ninguna licencia P1.

3. Ajuste la gestión de grupos de autoservicio. En el centro de administración, en Grupos → Configuración general, establezca Los usuarios pueden crear grupos de seguridad en los portales de Azure, la API o PowerShell y Los usuarios pueden crear grupos de Microsoft 365 en los portales de Azure, la API o PowerShell en No. Microsoft es explícito sobre la vía de escape: «si desea permitir que algunos, pero no todos sus usuarios, creen grupos, puede asignarles un rol que pueda crear grupos, como Administrador de grupos». Conozca el límite del interruptor vecino antes de confiar en él — Restringir la capacidad de los usuarios para acceder a las funciones de grupo en el Panel de acceso «solo restringe el acceso a la información de grupo en Mis grupos. No restringe el acceso a la información de grupo mediante otros métodos, como las llamadas a la API de Microsoft Graph o el centro de administración de Microsoft Entra».

4. Sustituya el interruptor del centro de administración por un control real. Establézcalo en Sí si quiere la fricción, pero implemente el control que Microsoft realmente recomienda: una directiva de Acceso condicional dirigida a la API Windows Azure Service Management que bloquee el acceso no administrativo a los endpoints de gestión de Azure. Verifíquela primero en modo solo informe — vea Acceso condicional en modo solo informe, exclusiones obsoletas.

5. Verifique, y tenga cuidado con las dos trampas. Vuelva a ejecutar el bloque de detección anterior y confirme que cada valor cambió. Dos comportamientos documentados podrían, de lo contrario, hacerle creer que el cambio falló o tuvo éxito cuando no fue así:

• La configuración de grupo «puede tardar hasta 15 minutos en surtir efecto».
• «Esta configuración es para usuarios y no afecta a los service principals. Por ejemplo, si tuviera un service principal con permiso para crear grupos, incluso si establece esta configuración en No, el service principal aún podría crear grupos».

Ese segundo punto es la razón por la que este refuerzo debe ir acompañado de un inventario de aplicaciones. Cerrar la creación por parte del usuario mientras se dejan service principals con permisos excesivos no resuelve el problema, solo lo desplaza — vea Aplicaciones de Azure sobreprivilegiadas en su tenant y la línea base de endurecimiento del tenant Azure más amplia.

Cómo lo detecta EtcSec

EtcSec divide esta superficie en cuatro hallazgos distintos en cada auditoría de Azure, en lugar de agruparlo todo en una puntuación vaga de «endurecimiento del tenant». Los cuatro se reportan con severidad media.

• AZ_APP_REGISTRATION_OPEN — Registro de aplicaciones abierto a todos los usuarios: se activa cuando authorizationPolicy → defaultUserRolePermissions.allowedToCreateApps devuelve true. Este se lee directamente desde Microsoft Graph.
• AZ_SELF_SERVICE_GROUPS_OPEN — Creación de grupos de autoservicio abierta: se activa cuando el tenant no tiene ninguna restricción de creación de grupos — que es donde se encuentra un tenant predeterminado, ya que EnableGroupCreation permanece en true hasta que existe un objeto Group.Unified.
• AZ_GROUP_SELF_SERVICE — Gestión de grupos de autoservicio sin restricciones: el mismo estado sin restricciones evaluado desde el lado de los grupos — grupos sin gobernanza, y una propiedad que no significa nada.
• AZ_ADMIN_PORTAL_ACCESS_OPEN — Acceso al portal de administración sin restricciones: se activa a menos que el tenant esté registrado como restringiendo el acceso al centro de administración solo a administradores. Se reporta como higiene de configuración, no como un límite de seguridad, en línea con la propia advertencia de Microsoft.

Mantenerlos separados importa porque la corrección difiere según el hallazgo: uno es una actualización de authorizationPolicy, dos requieren crear primero un objeto groupSettings, y el cuarto es una directiva de Acceso condicional. Para la secuencia completa, vea Cómo auditar la seguridad de Microsoft Entra ID.