🔷Azure
Azure es la plataforma en la nube de Microsoft.
Última actualización
Azure es la plataforma en la nube de Microsoft.
Última actualización
Azure AD != Azure
Azure Active Directory (Azure AD o AAD) es "el servicio de gestión de acceso e identidades basado en la nube de Microsoft". Por lo que, es uno de los muchos servicios dentro de Azure.
Se puede usar para acceder a recursos:
Externos: Azure Portal, Office 365, ...
Internos: Aplicaciones locales.
Proporciona acceso remoto en aquellas aplicaciones integradas en AD, dispositivos y gestión de identidades de las cuentas de AD.
Los recursos de Azure se dividen en 4 niveles:
Grupos de administración > Suscripciones > Grupos de recursos > Recursos
https://learn.microsoft.com/es-es/azure/role-based-access-control/overview
El control de acceso basado en rol (Azure RBAC) ayuda a administrar quién tiene acceso a los recursos de Azure, qué pueden hacer con esos recursos y a qué áreas puede acceder.
Consta de 3 elementos: Entidad de seguridad, definición de rol y ámbito
Una entidad de seguridad (usuario, grupo, servicio principal, identidad administrada) de azure puede tener un (https://azure.permissions.cloud/builtinroles) en determinados ámbitos (grupos de administración, suscripciones, grupos de recursos y recursos).
https://learn.microsoft.com/es-es/azure/role-based-access-control/conditions-overview
El control de acceso basado en atributos (ABAC) es un sistema de autorización que define el acceso en función de los atributos asociados a las entidades de seguridad, los recursos y el entorno de una solicitud de acceso.
Leer todos los usuarios, aplicaciones, dispositivos, roles, suscripciones o propiedades públicas.
Invitar invitados.
Crear grupos de seguridad.
Leer membresía de grupos no ocultos.
Añadir invitados a grupos propios.
Crear nuevas aplicaciones.
Añadir hasta 50 dispositivos en Azure.
Para obtener información general y pública sobre el Tenant de la organización/dominio objetivo, se podrán utilizar múltiples métodos y/o herramientas.
Alguna información puede obtenerse de forma manual al realizar una petición contra determinados recursos de Microsoft. No obstante, existen varias herramientas y scripts que permiten automatizar algunas acciones.
Conociendo un email de la organización, se podría obtener información asociada al Tenant donde se encuentra:
Para obtener el ID del Tenant e información de OpenID, se puede utilizar el siguiente recurso, donde se indicará el dominio objetivo:
Si queremos saber si un email existe o no en el Tenant, sin agotar intentos de inicio de sesión, se puede usar el recurso GetCredentialType para ello, se realiza la siguiente petición POST indicando el email:
O365EmailValidator: Si se desea automatizar esto, también se puede utilizar el siguiente script indicando la lista de emails que se quiera comprobar.
"MicroBurst includes functions and scripts that support Azure Services discovery, weak configuration auditing, and post exploitation actions such as credential dumping. It is intended to be used during penetration tests where Azure is in use." - MicroBurst
Iniciar sesión:
Obtener toda la información que puede leer el usuario actual:
Iniciar la interfaz gráfica:
El servidor web se ejecutará en la URL: http://127.0.0.1:5000
Obtención de políticas de accesos condicionales:
Se genera un fichero llamado caps.html con la información.
Se ejecuta el siguiente comando:
Ejecución de StormPotter:
Acceso a la web: http://localhost:9091/
Credenciales por defecto:
Usuario: neo4j
Contraseña: password
La información reconectada se encuentra en un ZIP dentro de la carpeta de C:\Pentest\Tools\stormspotter\stormcollector
.
Para visualizar la información se pueden utilizar las consultas por defecto de la sección "Queries" o crear unas propias.
Por ejemplo, para obtener todos los administradores:
Conexión e importación: #azurehound
Para consultar la información se deberá abrir BloodHound.
Buscar todos los usuarios que tengan el rol de "Global Administrator":
Todas las rutas a las máquinas virtuales:
Todas las rutas hacia "Azure KeyVaults":
Todas las rutas hacia "Azure Resource Group":
Buscar los Owners de "Azure Groups":
Esta herramienta contiene un conjunto de funciones que realizan peticiones contra Azure REST API de Microsoft.
https://github.com/xtormin/PowerPentest/tree/main/Azure/AzureRA
Realizar una petición GET contra el recurso que se desee usando un token de acceso y la URL de la consulta que se quiera realizar:
Obtener suscripciones:
Obtener los recursos de una suscripción por su ID:
Obtener roles asociados a un recurso:
Obtener un nonce:
https://learn.microsoft.com/es-es/security/operations/incident-response-playbook-app-consent
Para explotar esta vulnerabilidad se requiere poder crear una aplicación de Azure controlada por el atacante. En esta se añadirán los permisos que se deseen obtener.
La información de la aplicación se incluye en la configuración de la herramienta O365Stealer, que creará un enlace de phishing y será el que se le enviará a la víctima.
Usando AzureAD Preview se puede obtener la configuración del consentimiento de los usuarios a las aplicaciones:
Modificar o registrar una nueva aplicación.
Asignarle, por ejemplo los siguientes permisos:
Se añade, por ejemplo, a un servidor xampp la carpeta de o365-stealer y se ejecuta el servidor:
Se configura la herramienta con los valores del Client ID, Client Secret y URL de la aplicación registrada.
Desde el panel de Azure, la información necesaria para la configuración se obtiene desde los siguientes apartados/secciones:
2. Ejecución de la herramienta:
La herramienta genera una URL que será utilizada para el ataque de phishing.
Esta URL puede ser enviada, por ejemplo:
Enviando un email a la víctima.
Enviando la URL a través de un formulario.
Explotando un XSS almacenado.
Etc.
Una vez que la víctima pique en el anzuelo, obtendremos los tokens de acceso, correos, acceso a OneDrive, etc.
Desde el panel de O365-Stealer, podremos obtener la información en ficheros, subir ficheros a OneDrive, crear reglas en Outlook, etc.
Con el siguiente script es posible insertar código malicioso en un fichero .doc
:
https://github.com/samratashok/nishang/blob/master/Client/Out-Word.ps1
Siendo por ejemplo la IP del atacante 10.0.0.10
con el puerto 80
que cuenta con un servicio web que sirve el fichero Invoke-PowerShellTcp.ps1
y el puerto 443
que se encuentra a la escucha con netcat:
Se pone el puerto 443 a la escucha en la máquina del atacante 10.0.0.10
:
Desde el panel de acciones se puede subir un fichero .doc malicioso a One Drive y esperar hasta obtener la reverse shell.
Si nos encontramos con una aplicación que permite la subida de ficheros sin restricción, podríamos subir una webshell que nos permita ejecutar comandos en el sistema e identificar si la aplicación tiene una identidad administrada (managed identity).
Una aplicación tiene una identidad administrada si contiene en sus variables de entorno (env
):
Si se quiere obtener un token de acceso para la identidad administrada se puede realizar lo siguiente:
Webshell básica: https://victima.com/shell.php?cmd=env
Token de acceso: https://victima.com/gettoken.php
Se obtendría un token de acceso como el siguiente:
Es posible conectarse con Az Powershell haciendo uso del access_token y client_id:
Para obtener las subscripciones y sus subscriptionId se puede utilizar el siguiente script (AzureRA) usando el token de acceso (access_token) anterior:
Para obtener la lista de recursos se utiliza el siguiente script (AzureRA) con el mismo token de acceso y el subscriptionId de la suscripción de la cuál queramos obtener los recursos:
Si se quiere consultar los permisos de un recurso, se puede utilizar el siguiente script (AzureRA) con el mismo token de acceso y la ruta del recurso:
Por ejemplo:
Si contamos con una entrada vulnerable a inyección de plantillas:
Para averiguar de cuál tipo de engine se trata se pueden buscar claves de configuración en el buscador para identificarlo.
Sustituyendo el comando por env
para obtener las variables de entorno:
Con el siguiente comando se puede obtener el token de acceso usando las variables de entorno:
Si contamos con una entrada vulnerable a inyección de comandos, podríamos obtener las variables de entorno y usarlas para obtener un token de acceso que nos permita posteriormente acceder:
Para obtener las variables de entorno:
Para obtener un token de acceso:
Si no es posible realizar esto desde el punto de inyección de comandos, se podría crear un fichero python y ejecutarlo en el sistema para obtener los tokens de acceso:
Las cuentas de almacenamiento cuentan con tres niveles de acceso:
Ejemplo de una Storage Account:
Se pueden enumerar los Blobs disponibles con la herramienta MicroBurst:
También se pueden enumerar los Blobs con:
BlobHunter: https://github.com/cyberark/BlobHunter
Para enumerar las cuentas de almacenamiento:
Para comprobar si un contenedor cuenta con acceso anónimo:
Con la herramienta Azure Storage se puede realizar la conexión de forma cómoda y fiable (vía web no siempre se puede acceder correctamente):
Para configurar el acceso anónimo, se pueden seguir las indicaciones que se encuentran en la página oficial de Microsoft: https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure?tabs=portal#set-the-public-access-level-for-a-container
Si el los Key Vaults cuentan con acceso anónimo, podría llegar a accederse a la información confidencial que almacenan, como: secretos, cedenciales, etc.
Obtener KeyVault:
Mostrar información de un KeyVault:
Obtener credenciales en texto plano:
Posteriormente podríamos intentar iniciar sesión en el servicio, cuenta, sistema, etc. del cuál hayamos obtenido credenciales.
Por ejemplo:
Si se trata de una cuenta de Azure:
Si un rol cuenta con permisos de lectura en recursos que cuentan con claves secretas o información sensible. Se podría obtener dicha información realizando una petición que obtenga la información de los parámetros sobre recursos donde se tengan más permisos de los necesarios.
Obtener los recursos:
Obtener los roles asignados a un recurso:
De los roles obtenidos, se pueden visualizar las acciones permitidas:
Si en los campos se utiliza un tipo de campo que no oculte la información. Esta información puede verse expuesta y accesible a terceros no autorizados.
Para evitar esta situación se deberían utilizar los campos SecureString o SecureObject que permite ocultar esta información a usuarios no autorizados.
En el código fuente de aplicaciones podrían haber credenciales en texto plano.
Para evitar exponer estas credenciales en el código, es mejor hacer uso de Azure Key Vaults.
Si se cuenta con acceso a la API MSGraph, es posible realizar consultas directamente contra la API con el fin de obtener la lista completa de usuarios, grupos, roles asignados, etc.
Si se cuenta con un "hybrid runbookworker" podría ser posible ejecutar comandos en el servidor. Para ello se creará un runbook que cuente con un fichero powershell que contendrá el código malicioso que nos enviará el interprete de comandos a nuestra netcat.
Crear un runbook:
Contenido del fichero rshell.ps1:
Publicar el runbook:
Se pone el puerto 4444 a la escucha con netcat en la máquina del atacante:
Se ejecuta el runbook:
Término | Definición |
---|---|
Para conectarse usando el token de acceso:
Tipo de acceso | Permisos | Descripción |
---|---|---|
Obtener token de graph: