Microsoft expone las API en Entra ID para permitir que las aplicaciones de terceros realicen acciones en los servicios de Microsoft en nombre de los usuarios (lo que se denomina “permisos delegados”). Algunos permisos pueden representar una amenaza grave a la totalidad del inquilino de Microsoft Entra.

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 <a href="https://learn.microsoft.com/es-es/entra/identity-platform/permissions-consent-overview">Información general sobre los permisos y el consentimiento</a>:
<ul>
<li>Permisos de aplicación: consulte el indicador de exposición relacionado “Permisos de aplicación peligrosos que afectan al inquilino”.</li>
<li>Permisos delegados: este indicador de exposición examina este segundo tipo, consulte el indicador de exposición relacionado “Permisos delegados peligrosos que afectan a los datos” para ver las amenazas a los datos confidenciales del entorno. El consentimiento proviene de los usuarios o administradores en nombre de toda la organización. Tenga en cuenta que estos permisos limitan la capacidad de la aplicación de realizar acciones en función del privilegio del usuario que inició sesión (es decir, la intersección del permiso con el nivel de privilegio del usuario). Por lo tanto, el nivel de peligrosidad de estos permisos delegados depende de los permisos reales del usuario de la aplicación, según se describe en <a href="https://learn.microsoft.com/es-es/security/zero-trust/develop/developer-strategy-delegated-permission">Developing delegated permissions strategy</a> (texto en inglés). Ejemplo: Si un usuario normal delegó el permiso “Group.ReadWrite.All”, en realidad permite que la aplicación modifique solo los grupos que el usuario puede editar, no todos los grupos. Microsoft los <a href="https://learn.microsoft.com/es-es/security/operations/incident-response-playbook-app-consent#delegated-permissions-vs-application-permissions">describe</a> de la siguiente forma:</li>
</ul>
<blockquote>
Los permisos delegados se usan por las aplicaciones que tienen un usuario que ha iniciado sesión y que, además, pueden recibir consentimiento del administrador o el usuario.
</blockquote>
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 <a href="https://learn.microsoft.com/es-es/graph/overview">Microsoft Graph API</a> y la versión heredada de <a href="https://learn.microsoft.com/es-es/graph/migrate-azure-ad-graph-overview">Azure AD Graph API</a>:
<ul>
<li><code>AdministrativeUnit.ReadWrite.All</code>: permite a los atacantes quitar un Administrador global de una <a href="https://learn.microsoft.com/es-es/entra/identity/role-based-access-control/admin-units-restricted-management">unidad administrativa de administración restringida (RMAU)</a> para luego restablecer la contraseña si se combina con otros permisos.</li>
<li><code>Application.ReadWrite.All</code>: 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.</li>
<li><code>Application.ReadWrite.OwnedBy</code>: es igual a <code>Application.ReadWrite.All</code>, pero se aplica únicamente a las entidades de servicio que son propiedad de la entidad de servicio informada. Tenga en cuenta que normalmente no está disponible como permiso delegado.</li>
<li><code>AppRoleAssignment.ReadWrite.All</code>: permite a los atacantes otorgarse a sí mismos el permiso <code>RoleManagement.ReadWrite.Directory</code>.</li>
<li><code>DeviceManagementConfiguration.ReadWrite.All</code>: 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 <a href="https://cloud.google.com/blog/topics/threat-intelligence/abusing-intune-permissions-entra-id-environments/">(In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments</a> (texto en inglés). Esto puede permitir el escalamiento de privilegios hasta el Administrador global si un administrador usa un dispositivo administrado por Intune.</li>
<li><code>DeviceManagementRBAC.ReadWrite.All</code>: 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 <code>DeviceManagementConfiguration.ReadWrite.All</code>.</li>
<li><code>Directory.ReadWrite.All</code>: 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).</li>
<li><code>Domain.ReadWrite.All</code>: permite que los atacantes agreguen un dominio federado y se autentiquen como cualquier usuario, incluso como Administrador global, a la vez que evaden los requisitos de contraseña y MFA.</li>
<li><code>EntitlementManagement.ReadWrite.All</code>: 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.</li>
<li><code>Group.ReadWrite.All</code>: es igual a <code>Directory.ReadWrite.All</code></li>
<li><code>GroupMember.ReadWrite.All</code>: es igual a <code>Directory.ReadWrite.All</code></li>
<li><code>Organization.ReadWrite.All</code>: 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 <a href="https://learn.microsoft.com/es-es/entra/identity/authentication/concept-certificate-based-authentication">autenticación basada en certificados (CBA)</a> esté habilitada o, si no lo está, el permiso <code>Policy.ReadWrite.AuthenticationMethod</code> para habilitar la CBA de antemano.</li>
<li><code>Policy.ReadWrite.AuthenticationMethod</code>: permite a los atacantes habilitar el método de autenticación <a href="https://learn.microsoft.com/es-es/entra/identity/authentication/howto-authentication-temporary-access-pass">Pase de acceso temporal (TAP)</a>, que es un requisito previo para explotar el permiso <code>UserAuthenticationMethod.ReadWrite.All</code> cuando se combina con este. Como alternativa, permite a los atacantes habilitar la <a href="https://learn.microsoft.com/es-es/entra/identity/authentication/concept-certificate-based-authentication">autenticación basada en certificados (CBA)</a> para explotar el permiso <code>Organization.ReadWrite.All</code>.</li>
<li><code>Policy.ReadWrite.PermissionGrant</code>: permite a los atacantes crear una <a href="https://learn.microsoft.com/es-es/graph/api/permissiongrantpolicy-post-includes?view=graph-rest-1.0&amp;tabs=http">política de concesión de permisos</a> para una entidad de servicio controlada, lo que otorga el permiso <code>RoleManagement.ReadWrite.Directory</code> y habilita la explotación.</li>
<li><code>PrivilegedAccess.ReadWrite.AzureADGroup</code>: permite a los atacantes agregar una cuenta de usuario controlada como miembro de un grupo asignado al rol Administrador global.</li>
<li><code>PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup</code>: es igual a <code>PrivilegedAccess.ReadWrite.AzureADGroup</code>.</li>
<li><code>PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup</code>: 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.</li>
<li><code>RoleAssignmentSchedule.ReadWrite.Directory</code>: 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.</li>
<li><code>RoleEligibilitySchedule.ReadWrite.Directory</code>: permite a los atacantes hacer que una cuenta de usuario controlada sea elegible para el rol Administrador global y luego activarla para escalar privilegios.</li>
<li><code>RoleManagement.ReadWrite.Directory</code>: permite a los atacantes elevarse a sí mismos hasta el rol Administrador global.</li>
<li><code>RoleManagementPolicy.ReadWrite.AzureADGroup</code>: 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 <code>PrivilegedAccess.ReadWrite.AzureADGroup</code>, <code>PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup</code> o <code>PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup</code> y seguir la misma ruta que esos permisos en un inquilino con configuraciones de PIM estrictas.</li>
<li><code>RoleManagementPolicy.ReadWrite.Directory</code>: 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 <code>RoleAssignmentSchedule.ReadWrite.Directory</code> o <code>RoleEligibilitySchedule.ReadWrite.Directory</code> y seguir la misma ruta que esos permisos en un inquilino con configuraciones de PIM estrictas.</li>
<li><code>User.DeleteRestore.All</code>: 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.</li>
<li><code>User.EnableDisableAccount.All</code>: 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.</li>
<li><code>User.ReadWrite.All</code>: 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.</li>
<li><code>User-PasswordProfile.ReadWrite.All</code>: es igual a <code>Directory.ReadWrite.All</code></li>
<li><code>UserAuthenticationMethod.ReadWrite.All</code>: permite a los atacantes generar un <a href="https://learn.microsoft.com/es-es/entra/identity/authentication/howto-authentication-temporary-access-pass">Pase de acceso temporal (TAP)</a> y tomar el control de cualquier cuenta de usuario del inquilino. Si el TAP aún no está habilitado, deben combinar esto con <code>Policy.ReadWrite.AuthenticationMethod</code> para habilitar el TAP como método de autenticación en el inquilino (consulte el IoE correspondiente).</li>
</ul>
Este IoE también hace un seguimiento de <a href="https://www.tenable.com/blog/despite-recent-security-hardening-entra-id-synchronization-feature-remains-open-for-abuse">este permiso peligroso</a> de la API del “servicio de sincronización de Microsoft Entra AD”:
<ul>
<li><code>ADSynchronization.ReadWrite.All</code>: 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.</li>
</ul>
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:
<ul>
<li><a href="https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48">Andy Robbins - Azure Privilege Escalation via Azure API Permissions Abuse</a> (texto en inglés)</li>
<li><a href="https://posts.specterops.io/directory-readwrite-all-is-not-as-powerful-as-you-might-think-c5b09a8f78a8">Andy Robbins - Directory.ReadWrite.All Is Not As Powerful As You Might Think</a> (texto en inglés)</li>
<li><a href="https://csandker.io/2022/11/10/Untangling-Azure-II-Privileged-Access.html">Carsten Sandker - Untangling Azure Active Directory Permissions II: Privileged Access</a> (texto en inglés)</li>
<li><a href="https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/">Dirk-jan Mollema - Azure AD privilege escalation - Taking over default application permissions as Application Admin</a> (texto en inglés)</li>
<li><a href="https://github.com/emiliensocchi/azure-tiering/tree/main/Microsoft%20Graph%20application%20permissions#-tier-0-family-of-global-admins">Emilien Socchi - Tier 0 permissions</a> (texto en inglés) (consúltelo para obtener más detalles, incluidas las justificaciones de explotabilidad)</li>
<li><a href="https://m365internals.com/2021/07/24/everything-about-service-principals-applications-and-api-permissions/">Huy Kha - Everything about Service Principals, Applications, and API Permissions</a> (texto en inglés)</li>
<li><a href="https://www.inversecos.com/2021/10/how-to-backdoor-azure-applications-and.html">Lina Lau - How to Backdoor Azure Applications and Abuse Service Principals</a> (texto en inglés)</li>
<li><a href="https://cloud.google.com/blog/topics/threat-intelligence/abusing-intune-permissions-entra-id-environments/">Mandiant Red Team - (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments</a> (texto en inglés)</li>
<li><a href="https://youtu.be/jMOFWVOm-Y4?t=2229">Marius Solbakken Mellum - Surprising ways to escalate privileges in Entra ID</a> (texto en inglés)</li>
<li><a href="https://winsmarts.com/how-to-grant-admin-consent-to-an-api-programmatically-e32f4a100e9d">Sahil Malik - How to grant admin consent to an API programmatically</a> (texto en inglés)</li>
<li><a href="https://learningbydoing.cloud/blog/audit-ms-graph-app-role-assignments/">Stian A. Strysse - What's lurking in your Microsoft Graph app role assignments?</a> (texto en inglés)</li>
</ul>

Initial Access (texto en inglés)

Phishing (texto en inglés)

Persistence (texto en inglés)

Cloud Application Integration (texto en inglés)

Credential Access (texto en inglés)

Steal Application Access Token (texto en inglés)

Lateral Movement (texto en inglés)

Use Alternate Authentication Material: Application Access Token (texto en inglés)

Permisos delegados peligrosos que afectan al inquilino

Contar con un proceso de administración de cuentas sano exige supervisar las asignaciones a roles con privilegios.

Cuando un administrador o usuario avanzado dejan la empresa o cambian de puesto, quíteles los privilegios de inmediato. Para comenzar, deshabilite la cuenta y, luego, quítele la asignación de los roles con privilegios para evitar la reactivación accidental y asegurarse de que solo las cuentas autorizadas conserven el acceso privilegiado. Esto también permite que otros administradores verifiquen rápidamente que solo las cuentas legítimas tengan roles privilegiados.

Cuenta deshabilitada asignada a rol privilegiado

Los usuarios sin privilegios inactivos plantean riesgos de seguridad, ya que los atacantes pueden aprovecharse de ellos para obtener acceso no autorizado. Sin una supervisión y desactivación periódicas, estos usuarios obsoletos crean puntos de entrada potenciales para actividades malintencionadas al expandir la superficie de ataque.

Nota: Este IoE se basa en las licencias de Microsoft Entra ID P1 o P2 para acceder a los datos necesarios. Si el inquilino no tiene la licencia necesaria (p. ej., Entra ID gratis), este IoE no devolverá ningún hallazgo.
Un usuario inactivo es una cuenta de usuario que ha permanecido inactiva al no completar ningún inicio de sesión correcto durante un período específico (90 días de manera predeterminada, pero se puede personalizar mediante una opción).
Los usuarios inactivos pueden introducir los siguientes riesgos de seguridad y complicaciones operativas:
<ul>
<li>Como objetivos potenciales para los atacantes si estas cuentas tienen contraseñas débiles o que no se han cambiado, lo que facilita una vulneración. Por ejemplo, una <a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">alerta de CISA</a> informó lo siguiente:</li>
</ul>
<blockquote>
también se han dirigido campañas a cuentas inactivas pertenecientes a usuarios que ya no trabajan en una organización víctima, pero cuyas cuentas permanecen en el sistema.
</blockquote>
<ul>
<li>Un aumento en la superficie de ataque del inquilino de Entra al crear vulnerabilidades potenciales. Por ejemplo, la misma <a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">alerta de CISA</a> informó lo siguiente:</li>
</ul>
<blockquote>
Luego de un restablecimiento de contraseñas obligatorio para todos los usuarios durante un incidente, también se observó que los agentes de SVR iniciaron sesión en cuentas inactivas y siguieron las instrucciones para restablecer la contraseña. Esto permitió que los agentes recuperaran el acceso luego de las actividades de expulsión en respuesta ante incidentes.
</blockquote>
<ul>
<li>Acceso a personas que ya no lo necesitan, como exempleados o becarios que nunca han utilizado esta cuenta.</li>
<li>Desperdicio de recursos, como licencias. La identificación, desactivación o eliminación periódicas de usuarios inactivos permite a las organizaciones optimizar la asignación de recursos y ahorrar costos innecesarios.</li>
</ul>
Además, tenga en cuenta el IoE relacionado “Usuario sin privilegios no utilizado nunca”, que detecta todos los usuarios que se crearon anteriormente, pero que no se usaron nunca.
Consulte también el IoE relacionado, “Usuario privilegiado inactivo”, para los usuarios privilegiados.
Nota:
<ol>
<li>Este IoE se basa en la propiedad <code>lastSuccessfulSignInDateTime</code> de la propiedad <code>signInActivity</code> de los objetos de usuario. Su ventaja radica en informar únicamente los inicios de sesión correctos con el fin de evitar interrupciones debido a intentos fallidos, a diferencia de la propiedad <code>lastSignInDateTime</code>. La propiedad <code>lastSuccessfulSignInDateTime</code> está disponible desde diciembre de 2023.</li>
<li>Para acceder al tipo de recurso <code>signInActivity</code>, <a href="https://learn.microsoft.com/es-es/graph/api/resources/user?view=graph-rest-beta#:~:text=Details%20for%20this%20property%20require%20a%20Microsoft%20Entra%20ID%20P1%20or%20P2%20license%20and%20the%20AuditLog.Read.All%20permission">necesita una licencia de Microsoft Entra ID P1 o P2</a> para cada inquilino. De lo contrario, este IoE no puede detectar usuarios inactivos y, por lo tanto, omite todo el análisis.</li>
<li>Dado que esta propiedad permanece sin rellenar para los usuarios que nunca han iniciado sesión o que iniciaron sesión por última vez <a href="https://learn.microsoft.com/es-es/graph/api/resources/signinactivity?view=graph-rest-beta#:~:text=Effective%20December%201%2C%202023">antes de diciembre de 2023</a>, los datos necesarios para evaluar el intervalo no están disponibles. En consecuencia, Tenable Identity Exposure no puede detectar correctamente la última fecha de inicio de sesión, lo que puede generar falsos positivos.</li>
</ol>

Valid Accounts: Cloud Accounts (texto en inglés)

Usuario sin privilegios inactivo

Los usuarios privilegiados inactivos plantean riesgos de seguridad, ya que los atacantes pueden aprovecharse de ellos para obtener acceso no autorizado. Sin una supervisión y desactivación periódicas, estos usuarios obsoletos crean puntos de entrada potenciales para actividades malintencionadas al expandir la superficie de ataque.

Nota: Este IoE se basa en las licencias de Microsoft Entra ID P1 o P2 para acceder a los datos necesarios. Si el inquilino no tiene la licencia necesaria (p. ej., Entra ID gratis), este IoE no devolverá ningún hallazgo.
Un usuario inactivo es una cuenta de usuario que ha permanecido inactiva al no completar ningún inicio de sesión correcto durante un período específico (90 días de manera predeterminada, pero se puede personalizar mediante una opción).
Los usuarios inactivos pueden introducir los siguientes riesgos de seguridad y complicaciones operativas:
<ul>
<li>Como objetivos potenciales para los atacantes si estas cuentas tienen contraseñas débiles o que no se han cambiado, lo que facilita una vulneración. Por ejemplo, una <a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">alerta de CISA</a> informó lo siguiente:</li>
</ul>
<blockquote>
también se han dirigido campañas a cuentas inactivas pertenecientes a usuarios que ya no trabajan en una organización víctima, pero cuyas cuentas permanecen en el sistema.
</blockquote>
<ul>
<li>Un aumento en la superficie de ataque del inquilino de Entra al crear vulnerabilidades potenciales. Por ejemplo, la misma <a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">alerta de CISA</a> informó lo siguiente:</li>
</ul>
<blockquote>
Luego de un restablecimiento de contraseñas obligatorio para todos los usuarios durante un incidente, también se observó que los agentes de SVR iniciaron sesión en cuentas inactivas y siguieron las instrucciones para restablecer la contraseña. Esto permitió que los agentes recuperaran el acceso luego de las actividades de expulsión en respuesta ante incidentes.
</blockquote>
<ul>
<li>Acceso a personas que ya no lo necesitan, como exempleados o becarios que nunca han utilizado esta cuenta.</li>
<li>Desperdicio de recursos, como licencias. La identificación, desactivación o eliminación periódicas de usuarios inactivos permite a las organizaciones optimizar la asignación de recursos y ahorrar costos innecesarios.</li>
</ul>
Además, tenga en cuenta el IoE relacionado “Usuario privilegiado no utilizado nunca”, que detecta todos los usuarios que se crearon anteriormente, pero que no se usaron nunca.
El riesgo es mayor para los usuarios privilegiados. Consulte también el IoE relacionado, “Usuario sin privilegios inactivo”, para los usuarios sin privilegios.
Nota:
<ol>
<li>Este IoE se basa en la propiedad <code>lastSuccessfulSignInDateTime</code> de la propiedad <code>signInActivity</code> de los objetos de usuario. Su ventaja radica en informar únicamente los inicios de sesión correctos con el fin de evitar interrupciones debido a intentos fallidos, a diferencia de la propiedad <code>lastSignInDateTime</code>. La propiedad <code>lastSuccessfulSignInDateTime</code> está disponible desde diciembre de 2023.</li>
<li>Para acceder al tipo de recurso <code>signInActivity</code>, <a href="https://learn.microsoft.com/es-es/graph/api/resources/user?view=graph-rest-beta#:~:text=Details%20for%20this%20property%20require%20a%20Microsoft%20Entra%20ID%20P1%20or%20P2%20license%20and%20the%20AuditLog.Read.All%20permission">necesita una licencia de Microsoft Entra ID P1 o P2</a> para cada inquilino. De lo contrario, este IoE no puede detectar usuarios inactivos y, por lo tanto, omite todo el análisis.</li>
<li>Dado que esta propiedad permanece sin rellenar para los usuarios que nunca han iniciado sesión o que iniciaron sesión por última vez <a href="https://learn.microsoft.com/es-es/graph/api/resources/signinactivity?view=graph-rest-beta#:~:text=Effective%20December%201%2C%202023">antes de diciembre de 2023</a>, los datos necesarios para evaluar el intervalo no están disponibles. En consecuencia, Tenable Identity Exposure no puede detectar correctamente la última fecha de inicio de sesión, lo que puede generar falsos positivos.</li>
</ol>

Usuario privilegiado inactivo

Las cuentas de invitado son identidades externas que pueden representar un riesgo de seguridad cuando tienen asignados roles privilegiados. Esto otorga privilegios sustanciales dentro del inquilino a personas ajenas a la organización.

<a href="https://learn.microsoft.com/es-es/entra/external-id/what-is-b2b">B2B collaboration</a> es una funcionalidad de Microsoft Entra ID que permite a los usuarios invitar a otros usuarios para que colaboren con la organización. Estas cuentas de invitado, también llamadas “identidades externas”, obtienen acceso de forma predeterminada como lo <a href="https://learn.microsoft.com/es-es/entra/fundamentals/users-default-permissions#member-and-guest-users">describe Microsoft</a>:
<blockquote>
Pueden administrar su propio perfil, cambiar su propia contraseña y recuperar cierta información sobre otros usuarios, grupos y aplicaciones. Sin embargo, no pueden leer toda la información del directorio.
Por ejemplo, los usuarios invitados no pueden enumerar la lista de todos los usuarios, grupos y otros objetos del directorio. Es posible agregar invitados a roles de administrador, lo que les concede permisos completos de lectura y escritura. Los invitados también pueden invitar a otros invitados.
</blockquote>
Por definición, los roles privilegiados tienen privilegios elevados. Las cuentas de invitado que tienen un rol privilegiado asignado plantean un riesgo de seguridad y aumentan significativamente la superficie de ataque del inquilino. Esto resulta de especial preocupación, ya que las cuentas de invitado pueden tener políticas de seguridad más débiles, lo que las hace más susceptibles a ser vulneradas. Además, la asignación de roles privilegiados a usuarios invitados genera una menor trazabilidad, lo que dificulta supervisar y auditar sus actividades. En el peor de los casos, dichas asignaciones pueden incluso indicar una vulneración, ya que los agentes maliciosos a menudo explotan las cuentas de invitado para obtener acceso no autorizado y moverse lateralmente dentro del entorno.
Supervise con atención estas cuentas de invitado y asegúrese de no asignarles roles privilegiados.
En <a href="https://learn.microsoft.com/es-es/entra/fundamentals/configure-security#guests-are-not-assigned-high-privileged-directory-roles">Configuración de Microsoft Entra para aumentar la seguridad</a>, Microsoft también recomienda que los invitados no tengan asignados roles de directorio con privilegios elevados.

Valid Accounts: Default Accounts (texto en inglés)

Reconnaissance (texto en inglés)

Gather Victim Network Information (texto en inglés)

Active Scanning (texto en inglés)

Privilege Escalation (texto en inglés)

Account Manipulation: Additional Cloud Roles (texto en inglés)

Cuenta de invitado con un rol con privilegios

La MFA ofrece a las cuentas una protección sólida frente a contraseñas débiles o vulneradas. Según las prácticas recomendadas y las normas de seguridad, lo aconsejable es habilitar la MFA, en especial cuando se trata de cuentas con privilegios. Las cuentas que no tienen registrado ningún método de MFA no pueden beneficiarse de esta característica.

Nota: Este IoE se basa en las licencias de Microsoft Entra ID P1 o P2 para acceder a los datos necesarios. Si el inquilino no tiene la licencia necesaria (p. ej., Entra ID gratis), este IoE no devolverá ningún hallazgo.
La autenticación multifactor (MFA), conocida anteriormente como autenticación en dos fases (2FA), ofrece a las cuentas una protección sólida frente a contraseñas débiles o vulneradas. Según las prácticas recomendadas y las normas de seguridad, lo aconsejable es habilitar la MFA, en especial cuando se trata de cuentas con privilegios.
Cuando un atacante obtiene por cualquier método la contraseña de un usuario privilegiado, la MFA solicita un factor o paso adicional (como un código de una aplicación móvil que vence tras un plazo determinado, un token físico, un rasgo biométrico, etc.) para bloquear la autenticación.
Este indicador de exposición le avisa cuando una cuenta no tiene registrado ningún método de MFA o si se exige la MFA sin registrar ningún método, lo que puede permitir que los atacantes que cuenten con una contraseña registren sus propios métodos de MFA y generen un riesgo de seguridad. Sin embargo, este indicador de exposición no puede informar si Microsoft Entra ID exige la MFA o no, ya que las directivas de acceso condicional pueden exigir la MFA según criterios dinámicos.
También puede usar las características “<a href="https://learn.microsoft.com/es-es/entra/identity/authentication/howto-authentication-methods-activity">Actividad de los métodos de autenticación</a>” e “<a href="https://learn.microsoft.com/es-es/entra/identity/authentication/howto-mfa-reporting">Informes de MFA</a>” en Entra ID.
Consulte también el indicador de exposición relacionado, “MFA faltante para cuenta sin privilegios”, si se trata de cuentas sin privilegios.
Los usuarios deshabilitados se ignoran, ya que los atacantes no pueden aprovecharse de ellos de inmediato y también debido a una limitación de Microsoft Graph API, que informa un estado de MFA incorrecto para los usuarios deshabilitados.

Account Manipulation (texto en inglés)

Brute Force: Password Guessing (texto en inglés)

Brute Force: Password Spraying (texto en inglés)

Brute Force: Credential Stuffing (texto en inglés)

Modify Authentication Process: Multi-Factor Authentication (texto en inglés)

MFA faltante para cuenta privilegiada

Las cuentas de usuario sin privilegios que no se utilizan nunca son vulnerables a ataques, ya que a menudo evaden la detección de las medidas defensivas. Además, sus contraseñas predeterminadas potenciales las convierten en objetivos prioritarios de los atacantes.

Nota: Este IoE se basa en las licencias de Microsoft Entra ID P1 o P2 para acceder a los datos necesarios. Si el inquilino no tiene la licencia necesaria (p. ej., Entra ID gratis), este IoE no devolverá ningún hallazgo.
Un usuario no utilizado nunca es una cuenta de usuario que se creó en Entra ID y que no se autenticó correctamente durante una cierta cantidad de días (90 días de manera predeterminada, pero se puede personalizar) desde su creación.
Aumentan la superficie de ataque por diversos motivos, entre otros:
<ul>
<li>Una cuenta de puerta trasera que permite el acceso a personas que ya no lo necesitan, como exempleados o becarios que nunca han utilizado esta cuenta.</li>
<li>Uso continuado de la contraseña predeterminada, lo que deja expuesta la cuenta a un mayor riesgo de vulneración. Por ejemplo, una <a href="https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a">alerta de CISA</a> informó lo siguiente:<blockquote>
también se han dirigido campañas a cuentas inactivas pertenecientes a usuarios que ya no trabajan en una organización víctima, pero cuyas cuentas permanecen en el sistema
</blockquote>
</li>
</ul>
 y:
<blockquote>
Luego de un restablecimiento de contraseñas obligatorio para todos los usuarios durante un incidente, también se observó que los agentes de SVR iniciaron sesión en cuentas inactivas y siguieron las instrucciones para restablecer la contraseña. Esto permitió que los agentes recuperaran el acceso luego de las actividades de expulsión de respuesta ante incidentes.
</blockquote>
<ul>
<li>Desperdicio de recursos, como licencias. La identificación, desactivación o eliminación periódicas de usuarios innecesarios permite a las organizaciones optimizar la asignación de recursos y ahorrar costos innecesarios.</li>
</ul>
Además, considere el IoE “Usuario inactivo” relacionado, que identifica a todos los usuarios previamente activos que desde entonces se han vuelto inactivos.
Consulte también el IoE relacionado, “Usuario privilegiado no utilizado nunca”, para los usuarios privilegiados.
Nota:
<ol>
<li>Este IoE se basa en la propiedad <code>lastSuccessfulSignInDateTime</code> de la propiedad <code>signInActivity</code> de los objetos de usuario. Su ventaja radica en informar únicamente los inicios de sesión correctos con el fin de evitar interrupciones debido a intentos fallidos, a diferencia de la propiedad <code>lastSignInDateTime</code>. La propiedad <code>lastSuccessfulSignInDateTime</code> está disponible desde diciembre de 2023.</li>
<li>Para acceder al tipo de recurso <code>signInActivity</code>, <a href="https://learn.microsoft.com/es-es/graph/api/resources/user?view=graph-rest-beta#:~:text=Details%20for%20this%20property%20require%20a%20Microsoft%20Entra%20ID%20P1%20or%20P2%20license%20and%20the%20AuditLog.Read.All%20permission">necesita una licencia de Microsoft Entra ID P1 o P2</a> para cada inquilino. De lo contrario, este IoE no puede detectar usuarios que nunca se usaron y, por lo tanto, omite todo el análisis.</li>
<li>Dado que esta propiedad permanece sin rellenar para los usuarios que nunca han iniciado sesión o que iniciaron sesión por última vez <a href="https://learn.microsoft.com/es-es/graph/api/resources/signinactivity?view=graph-rest-beta#:~:text=Effective%20December%201%2C%202023">antes de diciembre de 2023</a>, los datos necesarios para evaluar el intervalo no están disponibles. En consecuencia, Tenable Identity Exposure no puede detectar correctamente la última fecha de inicio de sesión, lo que puede generar falsos positivos.</li>
</ol>

Usuario sin privilegios no utilizado nunca

Permitir que todos los usuarios unan sin restricciones dispositivos al inquilino de Entra abre la puerta a que agentes maliciosos introduzcan dispositivos fraudulentos en el sistema de identidad de la organización y les ofrece un punto de apoyo para vulneraciones adicionales.

De manera predeterminada, Microsoft Entra ID concede a todos los usuarios de Entra el derecho a registrar sus dispositivos en el inquilino como <a href="https://learn.microsoft.com/es-es/entra/identity/devices/concept-directory-join">dispositivos unidos</a> a Microsoft Entra. Esta opción denominada <a href="https://learn.microsoft.com/es-es/entra/identity/devices/manage-device-identities#configure-device-settings">Los usuarios pueden unir dispositivos a Microsoft Entra</a> permite que cualquier usuario que haya iniciado sesión complete el proceso de unión. Si un agente malicioso vulnera la cuenta de un usuario normal, puede explotar este flujo de trabajo para inscribir una estación de trabajo fraudulenta que controle completamente. El dispositivo aparece en Entra ID con la víctima como propietario, hereda las políticas de <a href="https://learn.microsoft.com/es-es/windows/client-management/azure-active-directory-integration-with-mdm">gestión de dispositivos móviles (MDM)</a> de referencia de ese usuario y proporciona al atacante un punto de apoyo persistente y de confianza dentro del entorno.
Si bien la unión de dispositivos puede desencadenar verificaciones adicionales, como la autenticación multifactor (MFA), de manera predeterminada no se exige en el momento de la inscripción. Es decir, un atacante que tenga solo una contraseña robada puede inscribir un dispositivo desde cualquier lugar. Si hay errores de configuración en Microsoft Intune o las políticas de acceso condicional, el dispositivo fraudulento puede marcarse automáticamente como conforme, de modo que se cumplen las condiciones de acceso que suprimen más desafíos de autenticación. Una vez marcado como conforme, el atacante puede acceder de manera silenciosa a los recursos de la nube que están detrás de la autenticación de Entra ID sin tener que enfrentarse a ninguna solicitud de MFA.
El equipo de respuesta ante incidentes de Microsoft documentó <a href="https://www.microsoft.com/es-es/security/blog/2023/12/05/microsoft-incident-response-lessons-on-preventing-cloud-identity-compromise/#poor-device">vulneraciones del mundo real</a> en las que una cuenta comprometida mediante phishing se usó para unir un dispositivo fraudulento, saltarse verificaciones de cumplimiento con errores de configuración y filtrar datos confidenciales de los buzones de correo de Microsoft 365. Estos casos ponen de manifiesto cómo unas opciones de unión de dispositivos demasiado permisivas pueden ampliar drásticamente el radio de ataque de la vulneración de una sola cuenta.
Esta opción permisiva también autoriza que los empleados inscriban libremente dispositivos Windows y macOS personales (“traiga su propio dispositivo” o BYOD, por sus siglas en inglés), lo que infla el inventario de dispositivos de la organización y dificulta la detección de dispositivos malintencionados o no autorizados en esta dispersión de dispositivos sin administrar.
De manera predeterminada, cada usuario puede registrar hasta 50 dispositivos, lo que significa que una sola cuenta vulnerada puede hospedar decenas de puntos de conexión controlados por atacantes sin que se desencadenen las alertas. Estas uniones controladas por usuarios tienen lugar fuera de los flujos de aprovisionamiento seguro, como el <a href="https://learn.microsoft.com/es-es/autopilot/self-deploying">modo de autoimplementación de Windows Autopilot</a>, de forma que se omiten la certificación de hardware y otras medidas de protección de incorporación de las que depende el acceso condicional para comprobar la confianza de los dispositivos.

Account Manipulation: Device Registration (texto en inglés)

Usuarios con permiso para unir dispositivos

Los administradores tienen privilegios elevados y pueden representar riesgos de seguridad cuando su número es elevado, dado que la superficie de ataque aumenta. Esta también es una señal de que no se respeta el principio de privilegios mínimos.

Por definición, los administradores tienen privilegios elevados. Cuando su número es elevado, pueden representar riesgos de seguridad, ya que esto aumenta la superficie de ataque al haber una mayor probabilidad de que un administrador se vea vulnerado. Esta también es una señal de que no se respeta el principio de privilegios mínimos.
Las personas asignadas a estos roles deben examinarse, capacitarse y estar justificadas de manera cuidadosa.
De manera predeterminada, los usuarios y las entidades de servicio deshabilitados no se tienen en cuenta (aunque este parámetro se puede cambiar) porque los atacantes no pueden usarlos de inmediato.

Detecciones

Indicadores de exposición

HIGH

LOW

LOW

MEDIUM

HIGH

HIGH

LOW

LOW

HIGH