gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-28 05:33:10 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-services/az-automati

Browse Source
This commit is contained in:
Translator
2025-02-12 13:50:28 +00:00
parent ba998814e3
commit 610c9afdcd
4 changed files with 22 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md
View File

@@ -1,6 +1,6 @@
# Az - Cuentas de Automatización
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Información Básica
@@ -26,19 +26,19 @@ Un **Trabajo es una instancia de ejecución de un Runbook**. Cuando ejecutas un
- **Salida**: El resultado de la ejecución del Runbook.
- **Hora de Inicio y Fin**: Cuándo comenzó y se completó el trabajo.
Un trabajo contiene la **salida** de la ejecución del **Runbook**. Si puedes **leer** los **trabajos**, hazlo ya que **contienen** la **salida** de la ejecución (potencial **información sensible**).
Un trabajo contiene la **salida** de la **ejecución del Runbook**. Si puedes **leer** los **trabajos**, hazlo ya que **contienen** la **salida** de la ejecución (potencial **información sensible**).
### Programaciones y Webhooks
Hay 3 formas principales de ejecutar un Runbook:
- **Programaciones**: Se utilizan para **activar** Runbooks en un **hora específica** o **intervalo**.
- **Programaciones**: Se utilizan para **activar** Runbooks en un **momento específico** o **intervalo**.
- **Webhooks**: Son **puntos finales HTTP** que pueden ser utilizados para **activar** Runbooks desde **servicios externos**. Ten en cuenta que la URL del webhook **no es visible** después de la creación.
- **Activación Manual**: Puedes **activar manualmente** un Runbook desde el Portal de Azure y desde la CLI.
### Control de Versiones
Permite importar Runbooks desde **Github, Azure Devops (Git) y Azure Devops (TFVC)**. Es posible indicar que publique los Runbooks del repositorio en la cuenta de Automatización de Azure y también es posible indicar que **sincronice los cambios del repositorio** a la cuenta de Automatización de Azure.
Permite importar Runbooks desde **Github, Azure Devops (Git) y Azure Devops (TFVC)**. Es posible indicar que publique los Runbooks del repositorio en la cuenta de automatización de Azure y también es posible indicar que **sincronice los cambios del repositorio** a la cuenta de automatización de Azure.
Cuando la sincronización está habilitada, en el **repositorio de Github se crea un webhook** para activar la sincronización cada vez que ocurre un evento de push. Ejemplo de una URL de webhook: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d`
@@ -61,7 +61,7 @@ Sin embargo, también es posible **crear tus propios entornos**, utilizando uno
### Grupos de Trabajadores Híbridos
En Azure Automation, el entorno de ejecución predeterminado para los runbooks es el **Azure Sandbox**, una plataforma basada en la nube gestionada por Azure, adecuada para tareas que involucran recursos de Azure. Sin embargo, este sandbox tiene limitaciones, como el acceso restringido a recursos locales y restricciones en el tiempo de ejecución y uso de recursos. Para superar estas limitaciones, se emplean Grupos de Trabajadores Híbridos. Un Grupo de Trabajadores Híbridos consiste en **uno o más Trabajadores de Runbook Híbridos instalados en tus propias máquinas**, ya sea en local, en otros entornos de nube o en VMs de Azure. Esta configuración permite que los runbooks se ejecuten directamente en estas máquinas, proporcionando acceso directo a recursos locales, la capacidad de ejecutar tareas más largas y que consumen más recursos, y la flexibilidad para interactuar con entornos más allá del alcance inmediato de Azure.
En Azure Automation, el entorno de ejecución predeterminado para los runbooks es el **Azure Sandbox**, una plataforma basada en la nube gestionada por Azure, adecuada para tareas que involucran recursos de Azure. Sin embargo, este sandbox tiene limitaciones, como el acceso restringido a recursos locales y restricciones en el tiempo de ejecución y el uso de recursos. Para superar estas limitaciones, se emplean Grupos de Trabajadores Híbridos. Un Grupo de Trabajadores Híbridos consiste en **uno o más Trabajadores de Runbook Híbridos instalados en tus propias máquinas**, ya sea en local, en otros entornos de nube o en VMs de Azure. Esta configuración permite que los runbooks se ejecuten directamente en estas máquinas, proporcionando acceso directo a recursos locales, la capacidad de ejecutar tareas más largas y que consumen más recursos, y la flexibilidad para interactuar con entornos más allá del alcance inmediato de Azure.
Cuando se crea un grupo de trabajadores híbridos, es necesario indicar las **credenciales** a utilizar. Hay 2 opciones:
@@ -73,14 +73,14 @@ Por lo tanto, si puedes elegir ejecutar un **Runbook** en un **Trabajador Híbri
Además, si el trabajador híbrido se está ejecutando en Azure con otras Identidades Administradas adjuntas, el runbook podrá acceder a la **identidad administrada del runbook y todas las identidades administradas de la VM desde el servicio de metadatos**.
> [!TIP]
> Recuerda que el **servicio de metadatos** tiene una URL diferente (**`http://169.254.169.254`**) que el servicio desde donde se obtiene el token de identidad administrada de la cuenta de automatización (**`IDENTITY_ENDPOINT`**).
> Recuerda que el **servicio de metadatos** tiene una URL diferente (**`http://169.254.169.254`**) que el servicio desde donde se obtiene el token de identidades administradas de la cuenta de automatización (**`IDENTITY_ENDPOINT`**).
### Configuración de Estado (SC)
>[!WARNING]
> [!WARNING]
> Como se indica en [la documentación](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), la Configuración de Estado de Automatización de Azure será retirada el 30 de septiembre de 2027 y reemplazada por [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
Las Cuentas de Automatización también admiten **Configuración de Estado (SC)**, que es una función que ayuda a **configurar** y **mantener** el **estado** de tus VMs. Es posible **crear** y **aplicar** configuraciones DSC a máquinas **Windows** y **Linux**.
Las Cuentas de Automatización también admiten **Configuración de Estado (SC)**, que es una característica que ayuda a **configurar** y **mantener** el **estado** de tus VMs. Es posible **crear** y **aplicar** configuraciones DSC a máquinas **Windows** y **Linux**.
Desde la perspectiva de un atacante, esto era interesante porque permitía **ejecutar código PS arbitrario en todas las VMs configuradas**, permitiendo escalar privilegios a las identidades administradas de estas VMs, potencialmente pivotando a nuevas redes... Además, las configuraciones podrían contener **información sensible**.
@@ -238,4 +238,4 @@ Get-AzAutomationHybridWorkerGroup -AutomationAccountName <AUTOMATION-ACCOUNT> -R
- [https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview)
- [https://github.com/rootsecdev/Azure-Red-Team#runbook-automation](https://github.com/rootsecdev/Azure-Red-Team#runbook-automation)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/azure-security/az-services/az-container-instances.md
View File

@@ -1,6 +1,6 @@
# Az - Container Instances
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Información Básica

20
src/pentesting-cloud/azure-security/az-services/az-container-registry.md
View File

@@ -1,6 +1,6 @@
# Az - Container Registry
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Información Básica
@@ -20,7 +20,7 @@ Estos son los **diferentes permisos** [según la documentación](https://learn.m
También hay algunos **roles integrados** que se pueden asignar, y también es posible crear **roles personalizados**.
![](</images/registry_roles.png>)
![](/images/registry_roles.png)
### Autenticación
@@ -29,8 +29,8 @@ También hay algunos **roles integrados** que se pueden asignar, y también es p
Hay 4 formas de autenticarte en un ACR:
- **Con Entra ID**: Esta es la **forma predeterminada** de autenticarte en un ACR. Utiliza el comando **`az acr login`** para autenticarte en el ACR. Este comando **almacenará las credenciales** en el archivo **`~/.docker/config.json`**. Además, si estás ejecutando este comando desde un entorno sin acceso a un socket de docker, como en un **cloud shell**, es posible usar la opción **`--expose-token`** para obtener el **token** para autenticarte en el ACR. Luego, para autenticarte, debes usar como nombre de usuario `00000000-0000-0000-0000-000000000000` así: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
- **Con una cuenta de administrador**: El usuario administrador está deshabilitado por defecto, pero se puede habilitar y luego será posible acceder al registro con el **nombre de usuario** y **contraseña** de la cuenta de administrador con permisos completos para el registro. Esto todavía se admite porque algunos servicios de Azure lo utilizan. Ten en cuenta que se crean **2 contraseñas** para este usuario y ambas son válidas. Puedes habilitarlo con `az acr update -n <acrName> --admin-enabled true`. Ten en cuenta que el nombre de usuario suele ser el nombre del registro (y no `admin`).
- **Con Entra ID**: Esta es la **forma predeterminada** de autenticarte en un ACR. Utiliza el comando **`az acr login`** para autenticarte en el ACR. Este comando **almacenará las credenciales** en el archivo **`~/.docker/config.json`**. Además, si estás ejecutando este comando desde un entorno sin acceso a un socket de docker, como en un **cloud shell**, es posible usar la opción **`--expose-token`** para obtener el **token** para autenticarte en el ACR. Luego, para autenticarte, debes usar como nombre de usuario `00000000-0000-0000-0000-000000000000`, así: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
- **Con una cuenta de administrador**: El usuario administrador está deshabilitado por defecto, pero se puede habilitar y luego será posible acceder al registro con el **nombre de usuario** y **contraseña** de la cuenta de administrador con permisos completos para el registro. Esto sigue siendo compatible porque algunos servicios de Azure lo utilizan. Ten en cuenta que se crean **2 contraseñas** para este usuario y ambas son válidas. Puedes habilitarlo con `az acr update -n <acrName> --admin-enabled true`. Ten en cuenta que el nombre de usuario suele ser el nombre del registro (y no `admin`).
- **Con un token**: Es posible crear un **token** con un **`scope map`** específico (permisos) para acceder al registro. Luego, es posible usar este nombre de token como nombre de usuario y alguna de las contraseñas generadas para autenticarte en el registro con `docker login -u <registry-name> -p <password> aregistry-url>`
- **Con un Service Principal**: Es posible crear un **service principal** y asignar un rol como **`AcrPull`** para descargar imágenes. Luego, será posible **iniciar sesión en el registro** utilizando el appId del SP como nombre de usuario y un secreto generado como contraseña.
@@ -51,11 +51,11 @@ echo "Service principal password: $PASSWORD"
```
### Cifrado
Solo el **Premium SKU** admite **cifrado en reposo** para las imágenes y otros artefactos.
Solo el **SKU Premium** admite **cifrado en reposo** para las imágenes y otros artefactos.
### Redes
Solo el **Premium SKU** admite **puntos finales privados**. Los otros solo admiten **acceso público**. Un punto final público tiene el formato `<registry-name>.azurecr.io` y un punto final privado tiene el formato `<registry-name>.privatelink.azurecr.io`. Por esta razón, el nombre del registro debe ser único en todo Azure.
Solo el **SKU Premium** admite **puntos finales privados**. Los otros solo admiten **acceso público**. Un punto final público tiene el formato `<registry-name>.azurecr.io` y un punto final privado tiene el formato `<registry-name>.privatelink.azurecr.io`. Por esta razón, el nombre del registro debe ser único en todo Azure.
### Microsoft Defender para la Nube
@@ -67,13 +67,13 @@ La función de **eliminación suave** te permite **recuperar un registro elimina
### Webhooks
Es posible **crear webhooks** dentro de los registros. En este webhook es necesario especificar la URL donde se **enviará una solicitud cada vez que se realice una acción de push o delete**. Además, los Webhooks pueden indicar un alcance para señalar los repositorios (imágenes) que se verán afectados. Por ejemplo, 'foo:*' significa eventos bajo el repositorio 'foo'.
Es posible **crear webhooks** dentro de los registros. En este webhook es necesario especificar la URL donde se **enviará una solicitud cada vez que se realice una acción de push o delete**. Además, los Webhooks pueden indicar un alcance para señalar los repositorios (imágenes) que se verán afectados. Por ejemplo, 'foo:\*' significa eventos bajo el repositorio 'foo'.
Desde la perspectiva de un atacante, es interesante verificar esto **antes de realizar cualquier acción** en el registro y eliminarlo temporalmente si es necesario, para evitar ser detectado.
### Registros conectados
Esto básicamente permite **reflejar las imágenes** de un registro a otro, generalmente ubicado en las instalaciones.
Esto permite básicamente **reflejar las imágenes** de un registro a otro, generalmente ubicado en las instalaciones.
Tiene 2 modos: **Solo lectura** y **Lectura y escritura**. En el primero, las imágenes solo se **extraen** del registro de origen, y en el segundo, las imágenes también se pueden **enviar** al registro de origen.
@@ -94,7 +94,7 @@ az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world
```
Sin embargo, eso activará ejecuciones que no son muy interesantes desde la perspectiva de un atacante porque no tienen ninguna identidad administrada adjunta.
Sin embargo, **tasks** pueden tener una **identidad administrada del sistema y del usuario** adjunta a ellas. Estas tareas son las útiles para **escalar privilegios** en el contenedor. En la sección de escalada de privilegios es posible ver cómo usar tareas para escalar privilegios.
Sin embargo, **tasks** pueden tener una **identidad administrada por el sistema y por el usuario** adjunta a ellas. Estas tareas son las útiles para **escalar privilegios** en el contenedor. En la sección de escalada de privilegios es posible ver cómo usar tareas para escalar privilegios.
### Cache
@@ -154,4 +154,4 @@ az acr cache show --name <cache-name> --registry <registry-name>
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli)
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}