Skip to content

Commit

Permalink
automation acc hybrid workers
Browse files Browse the repository at this point in the history
  • Loading branch information
carlospolop committed Jan 10, 2025
1 parent b193c5c commit 9c3a698
Showing 2 changed files with 56 additions and 8 deletions.
Original file line number Diff line number Diff line change
@@ -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 <account-name> --resource-group <res-group> --name <runbook-name>
az automation runbook start \
--automation-account-name <account-name> \
--resource-group <res-group> \
--name <runbook-name> \
[--run-on <name-hybrid-group>]
```

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/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/variables/<variable-name>?api-version=2019-06-01" \
--headers "Content-Type=application/json" \
--body '{
"name": "<variable-name>",
"properties": {
"description": "",
"value": "\"<variable-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.
Original file line number Diff line number Diff line change
@@ -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 <AUTOMATION-ACCOU

# Get State Configuration content
az automation dsc configuration show-content --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME> --name <DSC-CONFIG-NAME>

# Get hybrid worker groups for an automation account
az automation hrwg list --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME>

# Get hybrid worker group details
az automation hrwg show --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME> --name <HYBRID-WORKER-GROUP>

# Get more details about a hybrid worker group (like VMs inside it)
az rest --method GET --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/hybridRunbookWorkerGroups/<hybrid-worker-group-name>/hybridRunbookWorkers?&api-version=2021-06-22"
```

```powershell

0 comments on commit 9c3a698

Please sign in to comment.