diff --git a/src/images/vm_to_aa.jpg b/src/images/vm_to_aa.jpg
new file mode 100644
index 000000000..30893dfd5
Binary files /dev/null and b/src/images/vm_to_aa.jpg differ
diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
index 2b43fa39c..f856b7380 100644
--- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md
+++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
@@ -70,6 +70,24 @@ SCP examples:
 
 Find **JSON examples** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
 
+### Resource Control Policy (RCP)
+
+A **resource control policy (RCP)** is a policy that defines the **maximum permissions for resources within your AWS organization**. RCPs are similar to IAM policies in syntax but **don’t grant permissions**—they only cap the permissions that can be applied to resources by other policies. When you attach an RCP to your organization root, an organizational unit (OU), or an account, the RCP limits resource permissions across all resources in the affected scope.
+
+This is the ONLY way to ensure that **resources cannot exceed predefined access levels**—even if an identity-based or resource-based policy is too permissive. The only way to bypass these limits is to also modify the RCP configured by your organization’s management account.
+
+> [!WARNING]
+> RCPs only restrict the permissions that resources can have. They don’t directly control what principals can do. For example, if an RCP denies external access to an S3 bucket, it ensures that the bucket’s permissions never allow actions beyond the set limit—even if a resource-based policy is misconfigured.
+
+RCP examples:
+
+- Restrict S3 buckets so they can only be accessed by principals within your organization
+- Limit KMS key usage to only allow operations from trusted organizational accounts
+- Cap permissions on SQS queues to prevent unauthorized modifications
+- Enforce access boundaries on Secrets Manager secrets to protect sensitive data
+
+Find examples in [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
+
 ### ARN
 
 **Amazon Resource Name** is the **unique name** every resource inside AWS has, its composed like this:
@@ -384,6 +402,7 @@ If you are looking for something **similar** to this but for the **browser** you
 - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
 - [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
 - [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
+- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/)
 
 {{#include ../../../banners/hacktricks-training.md}}
 
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 ebd7fe529..0804ebec1 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
@@ -12,6 +12,8 @@ Fore more information check:
 
 ### Hybrid Workers Group
 
+- **From the Automation Account to the VM**
+
 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**.
@@ -19,6 +21,15 @@ Moreover, if the hybrid worker is running in Azure with other Managed Identities
 > [!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`**).
 
+- **From the VM to the Automation Account**
+
+Moreover, if someone compromise a VM where an automation account script is running, he will be able to locate the **Automation Account** metadata and access it from the VM to obtain tokens for the **Managed Identities** attached to the Automation Account.
+
+As it's possible to see in the following image, having Administrator access over the VM it's possible to find in the **environment variables of the process** the URL and secret to access the 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`)
 
 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.