La superficie de ataque olvidada: cuentas invitado Azure en tu tenant

¿Qué son las cuentas invitado de Azure?

Las cuentas invitado de Azure Entra ID (colaboración B2B) permiten que usuarios externos -socios, contratistas, proveedores, auditores- accedan a tus recursos de Microsoft 365 sin tener una cuenta en tu tenant. Las cuentas invitado se autentican a través de su tenant de origen, pero obtienen acceso a tus recursos según los permisos que les asignes.

Las cuentas invitado son una función legítima y ampliamente utilizada. El problema es la gobernanza. Las organizaciones invitan a usuarios externos para proyectos de corto plazo y nunca los eliminan. La configuración de invitaciones se deja en sus valores predeterminados, lo que permite que cualquier usuario del tenant -incluidos los invitados existentes- invite a cualquiera. No se exige MFA a los invitados. El resultado es una población creciente de identidades externas con distintos niveles de acceso -muchas olvidadas, algunas pertenecientes a personas que dejaron su organización hace años.

Cómo funciona

Las cuentas invitado se diferencian de las cuentas miembro en dos aspectos clave:

1. La autenticación ocurre en el tenant de origen del invitado - no controlas sus políticas de MFA, requisitos de contraseña ni su postura de seguridad. Aun así, puedes obligarlo a pasar por tu propio MFA: de forma predeterminada, la configuración de acceso entre tenants no confía en las reivindicaciones de MFA o de dispositivo de otras organizaciones de Microsoft Entra, por lo que tu política de Acceso Condicional sigue aplicándose. Lo que no puedes hacer es heredar ninguna garantía de cómo su tenant de origen lo autenticó.
2. La gobernanza del ciclo de vida es opcional - Entra ID sí cuenta con un mecanismo nativo que elimina invitados automáticamente (Revisiones de acceso con Aplicar automáticamente los resultados al recurso, y Bloquear el inicio de sesión durante 30 días y luego eliminar al usuario del tenant como acción sobre los invitados denegados), pero está desactivado de forma predeterminada y requiere una suscripción a Microsoft Entra ID Governance o Entra ID P2. Un tenant que nunca lo activa no tiene ninguna baja automática.

Los derechos de invitación están abiertos de forma predeterminada. El comportamiento documentado por Microsoft es que "todos los usuarios de tu organización, incluidos los usuarios invitados de colaboración B2B, pueden invitar a usuarios externos a la colaboración B2B" - por lo que no se trata solo de tus miembros: un invitado existente puede invitar al siguiente, sin supervisión ni aprobación de TI. En organizaciones con colaboración B2B activa, es habitual encontrar cientos de cuentas invitado, con un porcentaje significativo sin actividad en el último año.

La cadena de ataque

Paso 1: enumerar cuentas invitado

# signInActivity necesita AuditLog.Read.All Y una licencia Entra ID P1/P2.
# Directory.Read.All por sí solo devuelve los invitados pero no sus datos de inicio de sesión.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"

# Listar todas las cuentas invitado con su fecha de último inicio de sesión.
# -All es obligatorio: sin él solo se obtiene la primera página (máx. 500 cuando
# se selecciona signInActivity) y el resto de invitados se pierden silenciosamente.
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity,createdDateTime" |
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object LastSignIn

# Encontrar invitados inactivos durante 180+ días.
# signInActivity NO se devuelve por defecto: si se omite -Property, todos los invitados
# parecen no haber iniciado sesión nunca, por lo que este filtro los abarca a todos.
$cutoff = (Get-Date).AddDays(-180)
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity" |
  Where-Object { $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff }

Paso 2: explotar la configuración de invitación sin restricciones

Si los derechos de invitación de invitados no están restringidos, cualquier cuenta miembro comprometida puede invitar identidades externas controladas por el atacante para obtener acceso persistente:

# Usar una cuenta miembro comprometida para invitar a una identidad externa controlada por el atacante
# Permiso delegado de mínimo privilegio: User.Invite.All
New-MgInvitation `
  -InvitedUserEmailAddress "[email protected]" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage $false

Paso 3: acceder a recursos sin MFA

Si los invitados no están sujetos a una política de Acceso Condicional que exija MFA, una cuenta invitado comprometida ofrece acceso directo a todos los recursos compartidos sin verificación adicional: archivos de SharePoint, canales de Teams, contenido de OneDrive. El peor caso es un invitado que además posee un rol de directorio de Entra, donde una confianza B2B entre tenants totalmente abierta se convierte en un camino hacia Administrador Global -consulta Rol de administrador invitado en Entra y confianza B2B entre tenants: cómo los usuarios externos llegan a Administrador Global.

Paso 4: movimiento lateral a través de recursos compartidos

Las cuentas invitado suelen tener acceso a contenido compartido sensible que puede exfiltrarse directamente. Documentos de proyecto, contratos, datos de clientes: todo visible para los invitados con los permisos adecuados. La pertenencia a grupos es el camino más directo: un invitado añadido a un grupo privilegiado anidado o asignable a roles hereda mucho más que acceso a archivos, como se explica en Grupos privilegiados anidados en Entra ID, grupos asignables a roles e invitados en grupos de seguridad.

Paso 5: persistir mediante cuentas olvidadas

Las cuentas invitado obsoletas persisten indefinidamente. Un atacante que compromete una cuenta invitado olvidada obtiene un acceso persistente y de baja visibilidad que rara vez se revisa o revoca.

Detección

Eventos del registro de auditoría de Entra ID

Estos son los nombres de actividad tal como aparecen en el registro de auditoría de Microsoft Entra. Los inicios de sesión de invitados no son eventos de auditoría: se encuentran en los registros de inicio de sesión, que son una fuente distinta.

Consultas de detección SIEM (Elastic)

Los nombres de campo siguientes siguen la integración de Elastic Azure Logs.

Invitaciones de invitados (KQL):

azure.auditlogs.operation_name: "Invite external user"

El evento de auditoría registra quién invitó (initiated_by), no los roles de directorio de esa persona: la integración expone initiated_by.user.id, .displayName, .ipAddress y .userPrincipalName, y nada más. Por lo tanto, "invitaciones desde cuentas sin privilegios de administrador" debe resolverse comparando el UPN del iniciador con los titulares actuales de roles de administrador, no mediante un simple filtro sobre un campo roles.

Cuentas invitado accediendo a portales de administración (KQL):

azure.signinlogs.properties.user_type: "Guest" AND
azure.signinlogs.properties.app_display_name: ("Azure Portal" OR "Microsoft Azure Management")

Invitaciones masivas de invitados (>5 en 1 hora) - ES|QL: KQL solo filtra; no tiene ningún rol en la agregación, transformación u ordenación de datos, por lo que una regla de ráfaga no puede escribirse en KQL en absoluto. Usa ES|QL:

FROM logs-azure.auditlogs-*
| WHERE azure.auditlogs.operation_name == "Invite external user"
| STATS invites = COUNT(*)
    BY inviter = azure.auditlogs.properties.initiated_by.user.userPrincipalName,
       window = DATE_TRUNC(1 hour, @timestamp)
| WHERE invites > 5

Remediación

1. Restringir los derechos de invitación

Entra ID > External Identities > External collaboration settings:
Guest invite settings: "Only users assigned to specific admin roles can invite"

Con esta configuración, solo los titulares del rol Administrador de usuarios o Invitador de invitados pueden enviar invitaciones, lo que crea un rastro de auditoría y evita el abuso de invitaciones. Ten en cuenta lo que no es: restringe quién puede invitar, no añade un flujo de aprobación. Si necesitas aprobaciones, antepone al acceso de invitados paquetes de acceso de administración de derechos con aprobadores designados.

2. Exigir MFA para los usuarios invitados

Conditional Access Policy:
Name: Require MFA - Guest Users
Users > Include > Select users and groups > Guest or external users:
  select every applicable type (B2B collaboration guest users,
  B2B collaboration member users, B2B direct connect users,
  Local guest users, Service provider users, Other external users)
Target resources > Include: All resources (formerly 'All cloud apps')
Access controls > Grant: Require multifactor authentication
Enable policy: On

No existe una única casilla "Todos los invitados y usuarios externos": debes elegir los tipos de usuario externo que quieres cubrir. Dado que la configuración de confianza entre tenants no confía en el MFA del tenant de origen de forma predeterminada, los invitados cumplen esta política realizando MFA contra tu tenant.

3. Eliminar cuentas invitado obsoletas

# Eliminar un usuario requiere un ámbito de escritura - User.DeleteRestore.All es el
# de mínimo privilegio. AuditLog.Read.All es lo que hace legible signInActivity.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","User.DeleteRestore.All"

$cutoff = (Get-Date).AddDays(-90)

# -All y -Property no son opcionales aquí. Sin -Property, los datos de inicio de sesión
# están ausentes, todos los invitados coinciden con la prueba $null, y este script elimina
# a toda la población de invitados.
$staleGuests = Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "id,displayName,userPrincipalName,signInActivity" |
  Where-Object {
    $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff
  }

Write-Host "Found $($staleGuests.Count) stale guest accounts"

# Exportar y revisar la lista antes de eliminar nada; luego quitar -WhatIf.
$staleGuests | Select-Object DisplayName, UserPrincipalName,
  @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Export-Csv .\stale-guests.csv -NoTypeInformation

$staleGuests | ForEach-Object {
  Remove-MgUser -UserId $_.Id -WhatIf
}

Un invitado eliminado de esta forma permanece recuperable durante 30 días antes de que Microsoft Entra ID lo elimine de forma permanente.

4. Configurar revisiones de acceso trimestrales

Entra ID > ID Governance > Access reviews:
Create recurring quarterly reviews for all guest accounts
Reviewers: Resource owners or group owners
Auto apply results to resource: Enable
If reviewers don't respond: Remove access
Action to apply on denied guest users:
  Block from signing in for 30 days then remove user from the tenant

Las dos últimas líneas son lo que convierte una revisión en una baja real: eliminar solo el acceso deja el objeto invitado en el tenant. La acción de eliminar la cuenta B2B está disponible cuando la revisión se dirige a equipos y grupos seleccionados; no se ofrece en la revisión "Todos los grupos de Microsoft 365 con usuarios invitados". Licencias: las revisiones de acceso requieren una suscripción a Microsoft Entra ID Governance o Microsoft Entra Suite; algunas capacidades funcionan con Entra ID P2.

5. Implementar niveles de acceso para invitados

Usa la administración de derechos de Entra ID para automatizar el ciclo de vida de los invitados con fechas de caducidad automáticas. Al igual que las revisiones de acceso, es una capacidad de Microsoft Entra ID Governance y se licencia por separado de Entra ID P1.

Cómo lo detecta EtcSec

EtcSec audita la gobernanza de cuentas invitado en cada análisis de Azure, identificando riesgos de proliferación y accesos sin control.

GUEST_INVITATION_UNRESTRICTED marca los tenants cuya política de invitación de invitados sigue abierta a todos -el valor predeterminado- en lugar de estar restringida a un conjunto controlado de invitadores. Esa es la causa raíz de la proliferación descontrolada de invitados.

GUEST_NO_MFA_REQUIRED marca los tenants donde los usuarios invitados no están sujetos a una política de Acceso Condicional que exija MFA, dejando a las identidades externas con una autenticación más débil que la de los usuarios internos.

GUEST_STALE_90_DAYS enumera las cuentas invitado habilitadas cuyo último inicio de sesión registrado tiene más de 90 días de antigüedad, ofreciendo una lista priorizada para la revisión de acceso y la limpieza. Los invitados que nunca han iniciado sesión son un caso distinto y se reportan por separado mediante GUEST_NEVER_SIGNED_IN.

Preguntas frecuentes

¿Las cuentas invitado de Azure son un riesgo de seguridad por defecto? Las cuentas invitado en sí no son inherentemente riesgosas, pero una mala gobernanza crea un riesgo significativo. Los principales problemas son: ausencia de exigencia de MFA para los invitados, derechos de invitación sin restricciones y cuentas obsoletas que nunca se eliminan. Un programa de invitados bien gobernado es de bajo riesgo; uno sin gestionar se convierte en una superficie de ataque importante.

¿Con qué frecuencia debo revisar las cuentas invitado? Microsoft no publica una única periodicidad obligatoria: las Revisiones de acceso de Entra ID pueden programarse semanal, mensual, trimestral o anualmente, y el intervalo adecuado depende de la sensibilidad de los recursos compartidos. Trimestral es la línea base de EtcSec. Las Revisiones de acceso pueden automatizar el resultado con eliminación automática por falta de respuesta, lo que mantiene el proceso manejable incluso en tenants grandes; requiere una suscripción a Entra ID Governance o Entra ID P2.

¿Se puede usar una cuenta invitado para pivotar dentro de la organización? Sí. Un invitado con acceso a Teams puede ver todos los mensajes y archivos de esos canales. Si el invitado también tiene acceso a SharePoint, puede leer y potencialmente exfiltrar documentos. El daño está acotado por los permisos del invitado, pero los invitados obsoletos con permisos excesivos son extremadamente comunes en la práctica.

Prioridades de revisión

Cuentas invitado Azure: la superficie de ataque olvidada de tu tenant debe tratarse como una exposición real dentro de tu tenant de Entra ID y Azure, no como una configuración aislada. Empieza definiendo el perímetro de revisión: qué administradores, invitados, entidades de servicio, registros de aplicaciones, exclusiones de políticas y cuentas de emergencia (break-glass) se ven afectados, de qué flujos de trabajo de negocio dependen, qué privilegios exponen y qué excepciones de emergencia se añadieron con el tiempo. Ese paso de delimitación evita una remediación superficial, porque el síntoma técnico suele ser más pequeño que el radio de impacto operativo. Al documentar la ruta completa desde la configuración hasta el privilegio, el equipo puede priorizar los cambios que reducen el riesgo rápidamente sin romper el acceso en producción. Esto también crea una línea base defendible para la validación posterior y ofrece a la dirección una explicación clara de por qué el problema importa ahora.

Controles adyacentes a revisar

Cuando los atacantes llegan a tu tenant de Entra ID y Azure, rara vez se detienen en el primer punto débil. En torno a Cuentas invitado Azure: la superficie de ataque olvidada de tu tenant, suelen comprobar si la ruta expuesta puede encadenarse con autenticación heredada, gobernanza de invitados débil, consentimiento de aplicaciones demasiado amplio, cuentas de emergencia obsoletas y roles que nunca se revisaron. Esto significa que los defensores deben revisar no solo la debilidad principal, sino cada dependencia cercana que convierte el acceso en persistencia o escalada de privilegios. Confirma qué identidades, roles, permisos y supuestos de confianza podrían ser reutilizados por un operador motivado. Si una corrección cierra solo un objeto mientras deja intactas las rutas de privilegio adyacentes, el riesgo efectivo apenas cambia. Una revisión disciplinada de las oportunidades de encadenamiento es lo que convierte este tema en un ejercicio práctico de endurecimiento, en lugar de una simple casilla que se marca una sola vez.

Evidencia y telemetría a recopilar

Una respuesta sólida a Cuentas invitado Azure: la superficie de ataque olvidada de tu tenant necesita evidencia que puedan revisar tanto los equipos de ingeniería como los de detección. Recopila registros de inicio de sesión, registros de auditoría, cambios en la asignación de roles, eventos de consentimiento, cambios en las credenciales de aplicaciones y señales de inicio de sesión de riesgo; compara los cambios recientes con las ventanas de mantenimiento conocidas y aísla las cuentas o sistemas que cambiaron de comportamiento sin una razón de negocio clara. Usa esa evidencia para responder tres preguntas: cuándo apareció la ruta de riesgo, quién todavía puede usarla y si existe una exposición similar en otra parte de tu tenant de Entra ID y Azure. Una buena revisión de telemetría también te ayuda a separar la deuda técnica heredada del uso indebido activo. Esa distinción importa, porque el plan de remediación para una configuración incorrecta obsoleta es distinto del plan para una ruta que ya muestra actividad similar a la de un atacante o excepciones de política repetidas.

Cuentas invitado Azure: validación antes del cierre

Una revisión sólida de las cuentas invitado de Azure debe terminar con evidencia de producción, no con la suposición de que la ruta de riesgo desapareció. Antes de cerrar el hallazgo, vuelve a comprobar las asignaciones de roles, el alcance de las políticas, los permisos de las aplicaciones o la configuración de invitados, la evidencia de inicio de sesión, auditoría o riesgo del tenant real, y la ruta de excepción que podría recrear silenciosamente la exposición. Confirma que el estado más seguro se aplica al alcance que realmente importa: la OU de producción, la asignación de rol efectiva, la ruta de la aplicación o la ruta de confianza y delegación que un atacante realmente explotaría. Registra al propietario técnico, la dependencia de negocio y la condición de reversión para que la próxima revisión pueda determinar si el estado más seguro se mantuvo.

Usa una lista de verificación breve para el cierre:

• verifica que el estado de riesgo haya desaparecido desde el punto de vista del atacante, no solo en una captura de pantalla del administrador
• conserva una exportación o muestra de registro de antes/después que demuestre que el alcance afectado cambió
• documenta al propietario y la decisión de excepción si el control no pudo aplicarse por completo

Para la exposición adyacente, contrasta el resultado con Registros de aplicaciones de Azure: apps sobreprivilegiadas en el tenant, Endurecimiento del tenant de Azure: corrige la configuración predeterminada insegura, Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica de revisión, y Cumplimiento de AD y Azure: NIS2, ISO 27001, CIS Controls. La misma brecha de control suele reaparecer en rutas de identidad cercanas, brechas de registro o permisos delegados, razón por la cual el paso final de validación importa tanto como el hallazgo inicial.

Cuentas invitado Azure: evidencia a conservar para el próximo ciclo de revisión

El siguiente revisor no debería tener que reconstruir el caso de memoria. Conserva la evidencia que originalmente justificó el hallazgo, la prueba de que el cambio se aplicó y la nota que explica por qué el estado final es aceptable. Para este tema, la evidencia más útil suele combinar la exportación del tenant o la captura de pantalla que muestra el alcance afectado, la evidencia de inicio de sesión, auditoría o política que demuestra que el control ya se aplica, y la nota de propietario, aprobación y excepción para el estado final. Ese paquete compacto hace que las revisiones trimestrales o posteriores a un cambio sean mucho más rápidas y ayuda a explicar si el problema se eliminó, se redujo o se aceptó formalmente.

Si un cambio posterior de administración, política o aplicación reabre la ruta, esta evidencia histórica también facilita demostrar qué se desvió. Eso es lo que convierte a las cuentas invitado de Azure de una comprobación puntual en un proceso de aseguramiento repetible.

Fuentes

• Microsoft Learn - Configure external collaboration settings (alcance predeterminado de invitación, opciones de invitación de invitados, rol Invitador de invitados)
• Microsoft Learn - List users (Microsoft Graph) (signInActivity requiere Entra ID P1/P2 y AuditLog.Read.All)
• Microsoft Learn - Get-MgUser y Remove-MgUser
• Microsoft Learn - Manage guest access with access reviews y What are access reviews? (aplicación automática, licencias)
• Microsoft Learn - Cross-tenant access overview (las reivindicaciones de MFA del tenant de origen no son de confianza por defecto)
• Microsoft Learn - Conditional Access: target resources y users and groups
• Microsoft Learn - Entra audit log activity reference (nombres de actividad de usuarios invitados)
• Elastic - Azure exported fields y KQL

Lecturas relacionadas

Revisa este tema junto con Brechas de Acceso Condicional en Entra ID: qué configuraciones incorrectas dejan una exposición real, Endurecimiento del tenant de Azure: corrige la configuración predeterminada insegura, Acceso privilegiado en Azure: demasiados administradores globales, Registros de aplicaciones de Azure: apps sobreprivilegiadas en el tenant, y Azure Identity Protection: bloqueo de credenciales filtradas. Esas publicaciones adyacentes muestran cómo las mismas debilidades de identidad suelen encadenarse en una evaluación real, en lugar de aparecer como hallazgos aislados.

• Brechas de Acceso Condicional en Entra ID: qué configuraciones incorrectas dejan una exposición real
• Endurecimiento del tenant de Azure: corrige la configuración predeterminada insegura
• Acceso privilegiado en Azure: demasiados administradores globales
• Registros de aplicaciones de Azure: apps sobreprivilegiadas en el tenant
• Azure Identity Protection: bloqueo de credenciales filtradas

Usar esas referencias mantiene la discusión de remediación centrada en la ruta de ataque completa en lugar de en una única brecha de control.

Lista de verificación de validación

Antes de cerrar la revisión, vuelve a ejecutar las mismas comprobaciones que expusieron el problema y confirma que la ruta de riesgo ya no existe desde la perspectiva del atacante. Verifica las identidades, privilegios, rutas de herencia y controles compensatorios relevantes en producción, no solo en staging o en la documentación. Registra al propietario técnico, la dependencia de negocio esperada y la evidencia que demuestra que la nueva configuración es a la vez más segura y operativamente sostenible. Ese paso final de validación es lo que mantiene el artículo anclado en cómo los equipos realmente reducen el riesgo de identidad.

Confirmar los controles del ciclo de vida de invitados en la práctica

La remediación de cuentas invitado debe incluir una revisión de quién patrocina a los usuarios externos, cómo se recertifica el acceso y qué rutas de colaboración siguen creando identidades invitadas de larga duración con permisos amplios. Los programas más resilientes combinan restricciones de invitación, revisiones de acceso periódicas y comprobaciones de titularidad, de modo que el acceso de invitados permanezca ligado a una necesidad de negocio real en lugar de persistir indefinidamente después de que el proyecto haya terminado.