Az - Federation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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)
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.
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.
The IdP takes over, authenticating the user. Post-authentication, a SAMLResponse is formulated by the IdP and forwarded to the SP through the user.
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:
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.
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.
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.
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:
With all the information, it's possible to forget a valid SAMLResponse as the user you want to impersonate using shimit:
It's also possible to create ImmutableID of cloud only users and impersonate them
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
