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 351489d14..dd313a257 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 @@ -10,6 +10,15 @@ Fore more information check: ../az-services/az-automation-accounts.md {{#endref}} +### Hybrid Workers + +Remember that if somehow an attacker can execute an arbitrary runbook (arbitrary code) in a hybrid worker, he will **pivot to the location of the VM**. This could be an on-premise machine, a VPC of a different cloud or even an Azure VM. + +Moreover, if the hybrid worker is running in Azure with other Managed Identities attached, the runbook will be able to access the **managed identity of the runbook and all the managed identities of the VM from the metadata service**. + +> [!TIP] +> Remember that the **metadata service** has a different URL (**`http://169.254.169.254`**) than the service from where get the managed identities token of the automation account (**`IDENTITY_ENDPOINT`**). + ### `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`) As summary these permissions allow to **create, modify and run Runbooks** in the Automation Account which you could use to **execute code** in the context of the Automation Account and escalate privileges to the assigned **Managed Identities** and leak **credentials** and **encrypted variables** stored in the Automation Account. @@ -43,7 +52,11 @@ az automation runbook publish \ The permission **`Microsoft.Automation/automationAccounts/jobs/write`** allows the user to run a Runbook in the Automation Account using: ```bash -az automation runbook start --automation-account-name --resource-group --name +az automation runbook start \ + --automation-account-name \ + --resource-group \ + --name \ + [--run-on ] ``` The permission **`Microsoft.Automation/automationAccounts/jobs/output/read`** allows the user to read the output of a job in the Automation Account using: @@ -170,6 +183,7 @@ az automation runbook replace-content --no-wait \ --content 'echo "Hello World"' # Run the unpublished code +## Indicate the name of the hybrid worker group in runOn to execute the runbook there az rest \ --method PUT \ --url "https://management.azure.com/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f/resourceGroups/Resource_Group_1/providers/Microsoft.Automation/automationAccounts/autoaccount1/runbooks/AzureAutomationTutorialWithIdentity/draft/testJob?api-version=2023-05-15-preview" \ @@ -205,11 +219,29 @@ az automation source-control create \ This will automatically import the runbooks from the Github repository to the Automation Account and with some other permission to start running them it would be **possible to escalate privileges**. -Moreiver, remember that four 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 this can be configured also by setting in the variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** the **client id** of the user managed identity to use. +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] > Note that it's not possible to change the repo URL of a source control once it's created. +### `Microsoft.Automation/automationAccounts/variables/write` + +With the permission **`Microsoft.Automation/automationAccounts/variables/write`** it's possible to write variables in the Automation Account using the following command. + +```bash +az rest --method PUT \ +--url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//variables/?api-version=2019-06-01" \ +--headers "Content-Type=application/json" \ +--body '{ + "name": "", + "properties": { + "description": "", + "value": "\"\"", + "isEncrypted": false + } +}' +``` + ### Custom Runtime Environments If an automation account is using a custom runtime environment, it could be possible to overwrite a custom package of the runtime with some malicious code (like **a backdoor**). This way, whenever a runbook using that custon runtime is executed and load the custom package, the malicious code will be executed. diff --git a/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md b/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md index df58965dd..4d7c86886 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md +++ b/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md @@ -46,7 +46,7 @@ When the sync is enabled, in the **Github repository a webhook is created** to t Note that these webhooks **won't be visible** when listing webhooks in the associated runbooks to the Github repo. Also note that it's **not possible to change the repo URL** of a source control once it's created. -In order for the configured source control to work, the **Azure Automation Account** needs to have a managed identity (system or user) with the **`Contributor`** role. Moreover, to assing a user managed identity to the Automation Account, it'spossible to do it just setting the variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** to the **User Managed Identity Client ID**. +In order for the configured source control to work, the **Azure Automation Account** needs to have a managed identity (system or user) with the **`Contributor`** role. Moreover, to assing a user managed identity to the Automation Account, it's needed to indicate the client ID of the user MI in the variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. ### Runtime Environments @@ -62,15 +62,22 @@ When creating a Runbook it'spossible to select the runtime environment. By defau 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 +### Hybrid Worker Groups -A Runbook can be run in a **container inside Azure** or in a **Hybrid Worker** (non-azure machine).\ -The **Log Analytics Agent** is deployed on the VM to register it as a hybrid worker.\ -The hybrid worker jobs run as **SYSTEM** on Windows and **nxautomation** account on Linux.\ -Each Hybrid Worker is registered in a **Hybrid Worker Group**. +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. + +When a hybrid worker group is created it's needed to indicate the **credentials** to use. There are 2 options: + +- **Default credentials**: You don't need to provide the credentials and the runbooks will be executed inside the VMs as **System**. +- **Specific credentials**: You need to provide the name of the credentials object inside the automation account, which will be used to execute the **runbooks inside the VMs**. Therefore, in this case, it could be possible to **steal valid credentials** for the VMs. Therefore, if you can choose to run a **Runbook** in a **Windows Hybrid Worker**, you will execute **arbitrary commands** inside an external machine as **System** (nice pivot technique). +Moreover, if the hybrid worker is running in Azure with other Managed Identities attached, the runbook will be able to access the **managed identity of the runbook and all the managed identities of the VM from the metadata service**. + +> [!TIP] +> Remember that the **metadata service** has a different URL (**`http://169.254.169.254`**) than the service from where get the managed identities token of the automation account (**`IDENTITY_ENDPOINT`**). + ### State Configuration (SC) >[!WARNING] @@ -183,6 +190,15 @@ az automation dsc configuration show --automation-account-name --resource-group --name + +# Get hybrid worker groups for an automation account +az automation hrwg list --automation-account-name --resource-group + +# Get hybrid worker group details +az automation hrwg show --automation-account-name --resource-group --name + +# Get more details about a hybrid worker group (like VMs inside it) +az rest --method GET --url "https://management.azure.com/subscriptions//resourceGroups/>/providers/Microsoft.Automation/automationAccounts//hybridRunbookWorkerGroups//hybridRunbookWorkers?&api-version=2021-06-22" ``` ```powershell