mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-07 02:03:45 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
Translator
@@ -21,7 +21,7 @@
|
||||
|
||||
### Suscripciones de Azure
|
||||
|
||||
- Es otro **contenedor lógico donde se pueden ejecutar recursos** (VMs, DBs…) y se facturará.
|
||||
- Es otro **contenedor lógico donde se pueden ejecutar y facturar recursos** (VMs, DBs…).
|
||||
- Su **padre** es siempre un **grupo de gestión** (y puede ser el grupo de gestión raíz) ya que las suscripciones no pueden contener otras suscripciones.
|
||||
- **Confía en un solo directorio de Entra ID**
|
||||
- **Los permisos** aplicados a nivel de suscripción (o cualquiera de sus padres) son **heredados** a todos los recursos dentro de la suscripción.
|
||||
@@ -58,7 +58,7 @@ Entra ID es un servicio de **gestión de identidad y acceso basado en la nube**
|
||||
|
||||
### Servicios de Dominio de Entra (anteriormente Azure AD DS)
|
||||
|
||||
Los Servicios de Dominio de Entra amplían las capacidades de Entra ID al ofrecer **servicios de dominio gestionados compatibles con entornos tradicionales de Active Directory de Windows**. Soporta protocolos heredados como LDAP, Kerberos y NTLM, permitiendo a las organizaciones migrar o ejecutar aplicaciones más antiguas en la nube sin desplegar controladores de dominio locales. Este servicio también soporta la Política de Grupo para la gestión centralizada, haciéndolo adecuado para escenarios donde cargas de trabajo heredadas o basadas en AD necesitan coexistir con entornos modernos en la nube.
|
||||
Los Servicios de Dominio de Entra amplían las capacidades de Entra ID al ofrecer **servicios de dominio gestionados compatibles con entornos tradicionales de Windows Active Directory**. Soporta protocolos heredados como LDAP, Kerberos y NTLM, permitiendo a las organizaciones migrar o ejecutar aplicaciones más antiguas en la nube sin desplegar controladores de dominio locales. Este servicio también soporta la Política de Grupo para la gestión centralizada, haciéndolo adecuado para escenarios donde cargas de trabajo heredadas o basadas en AD necesitan coexistir con entornos modernos en la nube.
|
||||
|
||||
## Principales de Entra ID
|
||||
|
||||
@@ -105,7 +105,7 @@ Puedes consultarlos en [https://learn.microsoft.com/en-us/entra/fundamentals/use
|
||||
- **Invitados**
|
||||
- Opciones de **restricciones de acceso para usuarios invitados**:
|
||||
- **Los usuarios invitados tienen el mismo acceso que los miembros**.
|
||||
- **Los usuarios invitados tienen acceso limitado a propiedades y membresías de objetos de directorio (predeterminado)**. Esto restringe el acceso de invitados solo a su propio perfil de usuario por defecto. El acceso a información de otros usuarios y grupos ya no está permitido.
|
||||
- **Los usuarios invitados tienen acceso limitado a propiedades y membresías de objetos de directorio (predeterminado)**. Esto restringe el acceso de los invitados solo a su propio perfil de usuario por defecto. El acceso a información de otros usuarios y grupos ya no está permitido.
|
||||
- **El acceso de los usuarios invitados está restringido a propiedades y membresías de sus propios objetos de directorio** es la más restrictiva.
|
||||
- Opciones de **invitación de invitados**:
|
||||
- **Cualquiera en la organización puede invitar a usuarios invitados, incluidos invitados y no administradores (más inclusivo) - Predeterminado**
|
||||
@@ -128,7 +128,7 @@ Hay **2 tipos de grupos**:
|
||||
|
||||
Hay **2 tipos de membresías**:
|
||||
|
||||
- **Asignada**: Permite agregar manualmente miembros específicos a un grupo.
|
||||
- **Asignado**: Permite agregar manualmente miembros específicos a un grupo.
|
||||
- **Membresía dinámica**: Gestiona automáticamente la membresía utilizando reglas, actualizando la inclusión del grupo cuando cambian los atributos de los miembros.
|
||||
|
||||
### **Principales de Servicio**
|
||||
@@ -161,8 +161,8 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
|
||||
|
||||
- **No permitir el consentimiento del usuario**
|
||||
- Se requerirá un administrador para todas las aplicaciones.
|
||||
- **Permitir el consentimiento del usuario para aplicaciones de editores verificados, para permisos seleccionados (Recomendado)**
|
||||
- Todos los usuarios pueden consentir permisos clasificados como "bajo impacto", para aplicaciones de editores verificados o aplicaciones registradas en esta organización.
|
||||
- **Permitir el consentimiento del usuario para aplicaciones de editores verificados, aplicaciones internas y aplicaciones que solo solicitan permisos seleccionados (Recomendado)**
|
||||
- Todos los usuarios pueden consentir aplicaciones que solo solicitan permisos clasificados como "bajo impacto", aplicaciones de editores verificados y aplicaciones registradas en el inquilino.
|
||||
- **Permisos de bajo impacto predeterminados** (aunque necesitas aceptar para agregarlos como bajos):
|
||||
- User.Read - iniciar sesión y leer el perfil del usuario
|
||||
- offline_access - mantener acceso a datos a los que los usuarios le han dado acceso
|
||||
@@ -176,7 +176,7 @@ Una **Registración de Aplicación** es una configuración que permite a una apl
|
||||
|
||||
- Los usuarios pueden solicitar consentimiento de administrador para aplicaciones a las que no pueden consentir
|
||||
- Si **Sí**: Es posible indicar Usuarios, Grupos y Roles que pueden consentir solicitudes
|
||||
- Configura también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración
|
||||
- Configurar también si los usuarios recibirán notificaciones por correo electrónico y recordatorios de expiración
|
||||
|
||||
### **Identidad Administrada (Metadatos)**
|
||||
|
||||
@@ -184,10 +184,10 @@ Las identidades administradas en Azure Active Directory ofrecen una solución pa
|
||||
|
||||
Hay dos tipos de identidades administradas:
|
||||
|
||||
- **Asignada por el sistema**. Algunos servicios de Azure te permiten **habilitar una identidad administrada directamente en una instancia de servicio**. Cuando habilitas una identidad administrada asignada por el sistema, se crea un **principal de servicio** en el inquilino de Entra ID confiado por la suscripción donde se encuentra el recurso. Cuando se **elimina el recurso**, Azure automáticamente **elimina** la **identidad** por ti.
|
||||
- **Asignada por el usuario**. También es posible que los usuarios generen identidades administradas. Estas se crean dentro de un grupo de recursos dentro de una suscripción y se creará un principal de servicio en el EntraID confiado por la suscripción. Luego, puedes asignar la identidad administrada a una o **más instancias** de un servicio de Azure (múltiples recursos). Para las identidades administradas asignadas por el usuario, la **identidad se gestiona por separado de los recursos que la utilizan**.
|
||||
- **Asignadas por el sistema**. Algunos servicios de Azure permiten **habilitar una identidad administrada directamente en una instancia de servicio**. Cuando habilitas una identidad administrada asignada por el sistema, se crea un **principal de servicio** en el inquilino de Entra ID confiado por la suscripción donde se encuentra el recurso. Cuando se **elimina el recurso**, Azure automáticamente **elimina** la **identidad** por ti.
|
||||
- **Asignadas por el usuario**. También es posible que los usuarios generen identidades administradas. Estas se crean dentro de un grupo de recursos dentro de una suscripción y se creará un principal de servicio en el EntraID confiado por la suscripción. Luego, puedes asignar la identidad administrada a una o **más instancias** de un servicio de Azure (múltiples recursos). Para identidades administradas asignadas por el usuario, la **identidad se gestiona por separado de los recursos que la utilizan**.
|
||||
|
||||
Las Identidades Administradas **no generan credenciales eternas** (como contraseñas o certificados) para acceder como el principal de servicio adjunto a ella.
|
||||
Las identidades administradas **no generan credenciales eternas** (como contraseñas o certificados) para acceder como el principal de servicio adjunto a ellas.
|
||||
|
||||
### Aplicaciones Empresariales
|
||||
|
||||
@@ -225,15 +225,15 @@ Ejemplo:
|
||||
|
||||
## Roles y Permisos de Azure
|
||||
|
||||
- **Los roles** son **asignados** a **principales** en un **alcance**: `principal -[TIENE ROL]->(alcance)`
|
||||
- **Los roles** asignados a **grupos** son **heredados** por todos los **miembros** del grupo.
|
||||
- **Roles** son **asignados** a **principales** en un **alcance**: `principal -[TIENE ROL]->(alcance)`
|
||||
- **Roles** asignados a **grupos** son **heredados** por todos los **miembros** del grupo.
|
||||
- Dependiendo del alcance al que se asignó el rol, el **rol** podría ser **heredado** a **otros recursos** dentro del contenedor de alcance. Por ejemplo, si un usuario A tiene un **rol en la suscripción**, tendrá ese **rol en todos los grupos de recursos** dentro de la suscripción y en **todos los recursos** dentro del grupo de recursos.
|
||||
|
||||
### Roles Integrados
|
||||
|
||||
[De la documentación: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[El control de acceso basado en roles de Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) tiene varios **roles integrados de Azure** que puedes **asignar** a **usuarios, grupos, principales de servicio y identidades administradas**. Las asignaciones de roles son la forma en que controlas **el acceso a los recursos de Azure**. Si los roles integrados no satisfacen las necesidades específicas de tu organización, puedes crear tus propios [**roles personalizados de Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles).
|
||||
|
||||
**Los roles integrados** se aplican solo a los **recursos** para los que están **destinados**, por ejemplo, consulta estos 2 ejemplos de **roles integrados sobre recursos de Cómputo**:
|
||||
Los **roles integrados** se aplican solo a los **recursos** para los que están **destinados**, por ejemplo, consulta estos 2 ejemplos de **roles integrados sobre recursos de Cómputo**:
|
||||
|
||||
| [Lector de Copia de Seguridad de Disco](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Proporciona permiso al cofre de copia de seguridad para realizar copias de seguridad de disco. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
@@ -299,7 +299,7 @@ Ejemplo de JSON de permisos para un rol personalizado:
|
||||
|
||||
El Administrador Global es un rol de Entra ID que otorga **control total sobre el inquilino de Entra ID**. Sin embargo, no otorga permisos sobre los recursos de Azure por defecto.
|
||||
|
||||
Los usuarios con el rol de Administrador Global tienen la capacidad de '**elevar' a Administrador de Acceso de Usuario en el rol de Azure en el Grupo de Gestión Raíz**. Así que los Administradores Globales pueden gestionar el acceso en **todas las suscripciones y grupos de gestión de Azure.**\
|
||||
Los usuarios con el rol de Administrador Global tienen la capacidad de '**elevar' a Administrador de Acceso de Usuario en el rol de Azure en el Grupo de Gestión Raíz**. Por lo tanto, los Administradores Globales pueden gestionar el acceso en **todas las suscripciones y grupos de gestión de Azure.**\
|
||||
Esta elevación se puede hacer al final de la página: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Phishing de Aplicaciones OAuth
|
||||
|
||||
**Las Aplicaciones de Azure** están configuradas con los permisos que podrán usar cuando un usuario consienta la aplicación (como enumerar el directorio, acceder a archivos o realizar otras acciones). Tenga en cuenta que la aplicación actuará en nombre del usuario, por lo que incluso si la aplicación podría estar pidiendo permisos de administración, si el **usuario que consiente no tiene ese permiso**, la aplicación **no podrá realizar acciones administrativas**.
|
||||
**Las Aplicaciones de Azure** están configuradas con los permisos que podrán usar cuando un usuario consienta la aplicación (como enumerar el directorio, acceder a archivos o realizar otras acciones). Tenga en cuenta que la aplicación actuará en nombre del usuario, por lo que incluso si la aplicación pudiera estar pidiendo permisos de administración, si el **usuario que lo consiente no tiene ese permiso**, la aplicación **no podrá realizar acciones administrativas**.
|
||||
|
||||
### Permisos de consentimiento de la aplicación
|
||||
|
||||
@@ -21,11 +21,11 @@ Y si pueden consentir a todas las aplicaciones, pueden consentir a todas las apl
|
||||
### 2 Tipos de ataques
|
||||
|
||||
- **No autenticado**: Desde una cuenta externa, crear una aplicación con los **permisos de bajo riesgo** `User.Read` y `User.ReadBasic.All`, por ejemplo, phishing a un usuario, y podrás acceder a la información del directorio.
|
||||
- Esto requiere que el usuario phished sea **capaz de aceptar aplicaciones OAuth de un inquilino externo**.
|
||||
- Esto requiere que el usuario phished esté **capaz de aceptar aplicaciones OAuth de un inquilino externo**.
|
||||
- Si el usuario phished es un administrador que puede **consentir cualquier aplicación con cualquier permiso**, la aplicación también podría **solicitar permisos privilegiados**.
|
||||
- **Autenticado**: Habiendo comprometido un principal con suficientes privilegios, **crear una aplicación dentro de la cuenta** y **phishing** a algún **usuario privilegiado** que pueda aceptar permisos OAuth privilegiados.
|
||||
- En este caso, ya puedes acceder a la información del directorio, por lo que el permiso `User.ReadBasic.All` ya no es interesante.
|
||||
- Probablemente estés interesado en **permisos que requieren que un administrador los otorgue**, porque un usuario normal no puede dar ningún permiso a las aplicaciones OAuth, por eso necesitas **phishing solo a esos usuarios** (más sobre qué roles/permisos otorgan este privilegio más adelante).
|
||||
- Probablemente estés interesado en **permisos que requieren que un administrador los otorgue**, porque un usuario normal no puede dar a las aplicaciones OAuth ningún permiso, por eso necesitas **phishing solo a esos usuarios** (más sobre qué roles/permisos otorgan este privilegio más adelante).
|
||||
|
||||
### Los usuarios pueden consentir
|
||||
|
||||
@@ -33,8 +33,8 @@ Tenga en cuenta que necesita ejecutar este comando desde un usuario dentro del i
|
||||
```bash
|
||||
az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
|
||||
```
|
||||
- Los usuarios pueden consentir a todas las aplicaciones: Si dentro de **`permissionGrantPoliciesAssigned`** puedes encontrar: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy` entonces los usuarios pueden aceptar cada aplicación.
|
||||
- Los usuarios pueden consentir a aplicaciones de editores verificados o de tu organización, pero solo para los permisos que selecciones: Si dentro de **`permissionGrantPoliciesAssigned`** puedes encontrar: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` entonces los usuarios pueden aceptar cada aplicación.
|
||||
- Los usuarios pueden consentir todas las aplicaciones: Si dentro de **`permissionGrantPoliciesAssigned`** puedes encontrar: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy` entonces los usuarios pueden aceptar cada aplicación.
|
||||
- Los usuarios pueden consentir aplicaciones de editores verificados o de tu organización, pero solo para los permisos que selecciones: Si dentro de **`permissionGrantPoliciesAssigned`** puedes encontrar: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` entonces los usuarios pueden aceptar cada aplicación.
|
||||
- **Deshabilitar el consentimiento del usuario**: Si dentro de **`permissionGrantPoliciesAssigned`** solo puedes encontrar: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` y `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` entonces los usuarios no pueden consentir nada.
|
||||
|
||||
Es posible encontrar el significado de cada una de las políticas comentadas en:
|
||||
@@ -64,7 +64,7 @@ El ataque implica varios pasos dirigidos a una empresa genérica. Así es como p
|
||||
1. **Registro de dominio y alojamiento de la aplicación**: El atacante registra un dominio que se asemeja a un sitio de confianza, por ejemplo, "safedomainlogin.com". Bajo este dominio, se crea un subdominio (por ejemplo, "companyname.safedomainlogin.com") para alojar una aplicación diseñada para capturar códigos de autorización y solicitar tokens de acceso.
|
||||
2. **Registro de la aplicación en Azure AD**: El atacante luego registra una Aplicación Multi-Tenant en su inquilino de Azure AD, nombrándola como la empresa objetivo para parecer legítima. Configuran la URL de redirección de la aplicación para que apunte al subdominio que aloja la aplicación maliciosa.
|
||||
3. **Configuración de permisos**: El atacante configura la aplicación con varios permisos de API (por ejemplo, `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`). Estos permisos, una vez otorgados por el usuario, permiten al atacante extraer información sensible en nombre del usuario.
|
||||
4. **Distribución de enlaces maliciosos**: El atacante elabora un enlace que contiene el id del cliente de la aplicación maliciosa y lo comparte con usuarios específicos, engañándolos para que otorguen su consentimiento.
|
||||
4. **Distribución de enlaces maliciosos**: El atacante elabora un enlace que contiene el id del cliente de la aplicación maliciosa y lo comparte con usuarios específicos, engañándolos para que otorguen consentimiento.
|
||||
|
||||
## Ejemplo de ataque
|
||||
|
||||
@@ -116,18 +116,25 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \
|
||||
```
|
||||
## Otras Herramientas
|
||||
|
||||
- [**365-Stealer**](https://github.com/AlteredSecurity/365-Stealer)**:** Consulta [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer) para aprender a configurarlo.
|
||||
- [**365-Stealer**](https://github.com/AlteredSecurity/365-Stealer)**:** Consulta [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer) para aprender cómo configurarlo.
|
||||
- [**O365-Attack-Toolkit**](https://github.com/mdsecactivebreach/o365-attack-toolkit)
|
||||
|
||||
## Post-Explotación
|
||||
|
||||
### Phishing Post-Explotación
|
||||
|
||||
Dependiendo de los permisos solicitados, es posible que puedas **acceder a diferentes datos del inquilino** (listar usuarios, grupos... o incluso modificar configuraciones) y **información del usuario** (archivos, notas, correos electrónicos...). Luego, puedes usar estos permisos para realizar esas acciones.
|
||||
Dependiendo de los permisos solicitados, podrías **acceder a diferentes datos del inquilino** (lista de usuarios, grupos... o incluso modificar configuraciones) e **información del usuario** (archivos, notas, correos electrónicos...). Luego, puedes usar estos permisos para realizar esas acciones.
|
||||
|
||||
### Administrador de Aplicaciones de Entra ID
|
||||
|
||||
Si lograste comprometer de alguna manera un principal de Entra ID que puede gestionar Aplicaciones en Entra ID, y hay aplicaciones que están siendo utilizadas por los usuarios del inquilino. Un administrador podría **modificar los permisos que la aplicación está solicitando y agregar una nueva dirección de redirección permitida para robar los tokens**.
|
||||
- Ten en cuenta que es posible **agregar URIs de redirección** (no es necesario eliminar la real) y luego enviar un enlace HTTP utilizando la URI de redirección del atacante, de modo que cuando el usuario siga el enlace, la autenticación ocurra automáticamente y el atacante reciba el token.
|
||||
- También es posible cambiar los permisos que la aplicación solicita para obtener más permisos de los usuarios, pero en ese caso el usuario necesitará **aceptar nuevamente el aviso** (incluso si ya había iniciado sesión).
|
||||
- Para realizar este ataque, el atacante **NO NECESITA** controlar el código de la aplicación, ya que podría simplemente enviar el enlace para iniciar sesión en la aplicación al usuario con la nueva URL en el parámetro **`redirect_uri`**.
|
||||
|
||||
### Post Explotación de Aplicaciones
|
||||
|
||||
Consulta las secciones de Aplicaciones y Principal de Servicio de la página:
|
||||
Consulta las secciones de Aplicaciones y Principales de Servicio de la página:
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-entraid-privesc/
|
||||
|
||||
Reference in New Issue
Block a user