automation acc hybrid workers

carlospolop · carlospolop · commit 9c3a69861049 · 2025-01-10T14:16:44.000+01:00
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
@@ -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.
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
@@ -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
