Merge branch 'HackTricks-wiki:master' into master

This commit is contained in:
Raad
2025-02-12 22:18:35 +01:00
committed by GitHub
27 changed files with 197 additions and 35 deletions

View File

@@ -47,4 +47,3 @@ az keyvault network-rule add --name <vault-name> --ip-address <your-ip>
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -6,7 +6,7 @@
For more information about SQL Database check:
{{#ref}}
[az-postgresql.md](../az-services/az-postgresql.md)
../az-services/az-postgresql.md
{{#endref}}
### `Microsoft.DBforPostgreSQL/flexibleServers/read` && `Microsoft.DBforPostgreSQL/flexibleServers/write`
@@ -57,4 +57,3 @@ az postgres flexible-server ad-admin create \
```
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -380,4 +380,3 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/
According to the [**docs**](https://learn.microsoft.com/en-us/azure/role-based-access-control/permissions/compute#microsoftcompute), this permission lets you manage the OS of your resource via Windows Admin Center as an administrator. So it looks like this gives access to the WAC to control the VMs...
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -1,6 +1,6 @@
# Az - Automation Accounts
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
@@ -59,7 +59,6 @@ When creating a Runbook it's possible to select the runtime environment. By defa
However, it's also possible to **create your own environments**, using one of these as a base. In the case of python, it's possible to upload `.whl` packages to the environment that will be used. In the case of PowerShell, it's possible to upload `.zip` packages with the modules to have in the runtime.
### Hybrid Worker Groups
In Azure Automation, the default execution environment for runbooks is the **Azure Sandbox**, a cloud-based platform managed by Azure, suitable for tasks involving Azure resources. However, this sandbox has limitations, such as restricted access to on-premises resources and constraints on execution time and resource usage. To overcome these limitations, Hybrid Worker Groups are employed. A Hybrid Worker Group consists of **one or more Hybrid Runbook Workers installed on your own machines**, whether on-premises, in other cloud environments or Azure VMs. This setup allows runbooks to execute directly on these machines, providing direct access to local resources, the ability to run longer and more resource-intensive tasks, and the flexibility to interact with environments beyond Azure's immediate reach.
@@ -78,14 +77,13 @@ Moreover, if the hybrid worker is running in Azure with other Managed Identities
### State Configuration (SC)
>[!WARNING]
> [!WARNING]
> As indicated in [the docs](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), Azure Automation State Configuration will be retired on September 30, 2027 and replaced by [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
Automation Accounts also support **State Configuration (SC)**, which is a feature that helps **configure** and **maintain** the **state** of your VMs. It's possible to **create** and **apply** DSC configurations to **Windows** and **Linux** machines.
From an attackers perspective this was interesting because it allowed to **execute arbitrary PS code in all the configured VMs** allowing to escalate privileges to the managed identities of these VMs, potentially pivoting to new networks... Also, the configurations could contain **sensitive info**.
## Enumeration
```bash
@@ -242,7 +240,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}}

View File

@@ -1,28 +1,26 @@
# Az - Container Instances
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
Azure Container Instances (ACI) provide a **serverless, on-demand way** to run **containers** in the Azure cloud. You can **deploy** single or multiple containers in a group with **scalable compute**, **networking options**, and the flexibility to connect to **other Azure services** (like Storage, Virtual Networks, or Container Registries).
Azure Container Instances (ACI) provide a **serverless, on-demand way** to run **containers** in the Azure cloud. You can **deploy** single or multiple containers in a group with **scalable compute**, **networking options**, and the flexibility to connect to **other Azure services** (like Storage, Virtual Networks, or Container Registries).
As they are **ephemeral** workloads, you don't need to manage the underlying VM infrastructure — Azure handles that for you. However, from an **offensive security perspective**, it's crucial to understand how **permissions**, **identities**, **network configurations**, and **logs** can reveal attack surfaces and potential misconfigurations.
### Configurations
- In order to create a container it's possible to use a public image, a container image from an Azure Container Registry or an external repository, which might **require to configure a password** to access it.
- Regarding networking it can also have a **public IP** or be **private endpoints**.
- It's also possible to configure common docker settings like:
- **Environment variables**
- **Volumes** (even from Azure Files)
- **Ports**
- **CPU and memory limits**
- **Restart policy**
- **Run as privileged**
- **Command line to run**
- ...
- **Environment variables**
- **Volumes** (even from Azure Files)
- **Ports**
- **CPU and memory limits**
- **Restart policy**
- **Run as privileged**
- **Command line to run**
- ...
## Enumeration
@@ -44,4 +42,4 @@ az container exec --name <container-name> --resource-group <res-group> --exec-co
# Get yaml configuration of the container group
az container export --name <container-name> --resource-group <res-group>
```
```

View File

@@ -1,6 +1,6 @@
# Az - Container Registry
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
@@ -20,7 +20,7 @@ These are the **different permissions** [according to the docs](https://learn.mi
There are also some **built-in roles** that can be assigned, and it's also possible to create **custom roles**.
![](</images/registry_roles.png>)
![](/images/registry_roles.png)
### Authentication
@@ -61,7 +61,7 @@ Only the **Premium SKU** supports **private endpoints**. The other ones only sup
### Microsoft Defender for Cloud
This allows you to **scan the images** in the registry for **vulnerabilities**.
This allows you to **scan the images** in the registry for **vulnerabilities**.
### Soft-delete
@@ -69,7 +69,7 @@ The **soft-delete** feature allows you to **recover a deleted registry** within
### Webhooks
It's possible to **create webhooks** inside registries. In this webhook it's needed to specify the URL where a **request will be sent whenever a push or delete action is performed**. Moreover, Webhooks can indicate a scope to indicate the repositories (images) that will be affected. For example, 'foo:*' means events under repository 'foo'.
It's possible to **create webhooks** inside registries. In this webhook it's needed to specify the URL where a **request will be sent whenever a push or delete action is performed**. Moreover, Webhooks can indicate a scope to indicate the repositories (images) that will be affected. For example, 'foo:\*' means events under repository 'foo'.
From an attackers perspective it's interesting to check this **before performing any action** in the registry, and remove it terporarely if needed, to avoid being detected.
@@ -160,7 +160,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}}

View File

@@ -205,6 +205,8 @@ The Azure Instance Metadata Service (IMDS) **provides information about running
Moreover, to contact the metadata endpoint, the HTTP request must have the header **`Metadata: true`** and must not have the header **`X-Forwarded-For`**.
When requesting an access token to the metadata endpoint, by default the metadata service will use the **system assigned managed identity** to generate the token, if there is any system assigned managed identity. In case there is just **ONE user assigned managed identity**, then this will be used by default. However, in case there is no system assigned managed identity and there are **multiple user assigned managed identities**, then the metadata service will return an error indicating that there are multiple managed identities and it's necessary to **specify which one to use**.
Check how to enumerate it in:
{{#ref}}