Going for the Gold: Penetration Testing Tools Exploit Golden SAML

Going for the Gold: Penetration Testing Tools Exploit Golden SAML A contrived penetration testing scenario explores how attackers could exploit Active Directory Federated Services via Golden SAML and provides context for two Secureworks penetration testing tools.Wednesday, August 11, 2021By: Counter Threat Unit Research Team

The scenario

An organization hires Secureworks® to perform an internal penetration test. There is only one goal: move from the customer's on-premises environment to their Microsoft Azure cloud infrastructure.

Secureworks analysts begin enumerating the internal domain, escalating privileges, and identifying credentials. They eventually gain Domain Administrator access and begin asking questions to determine how to achieve the goal:

• How do we access the cloud environment?
• Can we obtain Global Administrator access?
• Would we need to leverage Global Administrator privileges before or after moving into the customer's Azure cloud infrastructure?
• How will we overcome multi-factor authentication (MFA)?

Using publicly available tools, Secureworks analysts identify on-premises accounts that are synced in the customer's Azure cloud infrastructure. The analysts' reconnaissance provides a general idea of which employees are in key roles (e.g., Global Administrators, Server Administrators). The analysts then begin the process of moving laterally into the customer's cloud infrastructure while trying to escalate their privileges.

Golden SAML technique

In 2019, third-party researchers published a blog post and YouTube video discussing the security of Active Directory Federated Services (AD FS). These publications were accompanied by two tools (ADFSDump and ADFSpoof) that could be used to exploit a technique known as 'Golden SAML'. By using this technique, a threat actor can compromise an AD FS server, steal the AD FS configuration settings, and use elements in that configuration to become the user of their choice in the cloud environment while bypassing MFA. Threat actors used the Golden SAML technique in the 2020 SolarWinds breach to move from on-premises systems to the cloud.

An attacker had to perform the following steps to conduct a Golden SAML attack:

1. Compromise an AD FS server.
2. Impersonate either the AD FS service account or a local administrator account on an AD FS server.
3. Extract the following data from the environment:
   • The target cloud user's ObjectGUID and UserPrincipalName
   • The Active Directory Distributed Key Manager (DKM) master key
   • The following values from the AD FS configuration settings:
     • EncryptedPfx: The encrypted token-signing certificate
     • Trust Issuer Address: The URL that the cloud uses to connect the on-premises environment to the cloud
4. Decrypt the EncryptedPfx with the DKM master key to obtain the decrypted token-signing certificate.
5. Build the SAML token using the target cloud user's ObjectGUID and UserPrincipalName.
6. Use the decrypted token-signing certificate to cryptographically sign the SAML token.
7. Pass the signed SAML token to the cloud.
   • The cloud provider validates the signature of the SAML token.
   • The cloud provider logs the user into the target cloud resource.

Back to the scenario...

Golden SAML tokens can be forged for any service that uses SAML to connect to an AD FS server, including Azure. Secureworks analysts determine that it is the best method for pivoting from the customer's on-premises environment to their cloud environment. The analysts decide to impersonate a Global Administrator within the organization so they can also elevate their privileges.

Remote extraction of AD FS configuration

Blog posts published in April 2021 by a Secureworks researcher and third-party vendor revealed that compromising an AD FS server is no longer required for these attacks. An attacker only needs three components to remotely extract an AD FS server's configuration setting:

• The IP address or fully qualified domain name (FQDN) of any AD FS server
• The NTHash of the AD FS service account
• The security identifier (SID) of the AD FS service account

The threat actor can use the NTHash and SID to build a Kerberos ticket that provides authentication for the target AD FS server.

1. Obtain the AD FS service account's NTHash and SID.
2. Craft a custom Kerberos ticket that is wrapped in an AP_REQ message, which is then wrapped in a SPNEGO message.
3. Pass the custom Base64-encoded Kerberos ticket in a RequestSecurityToken (RST) SOAP envelope to the AD FS server over HTTP. The server validates the RST SOAP envelope format and the authentication via the custom Kerberos ticket and returns the requested security token to the attacker.
4. Parse and validate the RST response envelope and extract the Key, Context, and KeyIdentifier values.
5. Use these RST response values to create and sign a SecurityTokenContext (SCT) envelope that is passed to the AD FS server over HTTP.
6. Parse and validate the SCT response envelope and extract the Key, Context, and KeyIdentifier values.
7. Use these SCT response values to create and sign a final SOAP envelope requesting the 'ServiceSettings' database entry from the AD FS server.
8. Parse and validate the final SOAP response envelope and extract all of the AD FS configuration settings from the ServiceSettings entry in XML format.
9. Parse the XML data to obtain the EncryptedPfx and the Trust Issuer Address.

The threat actor must then obtain the target cloud user's ObjectGUID and UserPrincipalName, and the Active Directory DKM master key. The attacker can leverage the ADFSpoof tool to decrypt EncryptedPfx with the Active Directory DKM master key, forge the SAML token, cryptographically sign the SAML token with the decrypted token-signing certificate, and pass the SAML token to the target cloud API to log into the cloud resource.

Secureworks tools

Secureworks researchers converted the publicly available AD FS attack toolkit into a modularized Python library named TicketsPlease and used this library for several attack toolkits. These tools can be executed from any operating system and or executed remotely through a SOCKS proxy. Secureworks analysts can use these tools to conduct external penetration tests: compromising an Internet-facing server, setting up a SOCKS proxy, and accessing internal systems to exploit the Golden SAML technique.

WhiskeySAML

WhiskeySAML is a Python Flask web application that allows Secureworks analysts to perform the following tasks:

1. Remotely extract AD FS configuration settings
2. Forge and sign Golden SAML tokens
3. Pass the Golden SAML token to the Microsoft Azure portal
4. Log into the Azure portal as any user while bypassing Azure MFA configurations

Figure 1 shows the WhiskeySAML interface populated with fake sample data to extract the configuration settings and generate the tokens.

Figure 1. WhiskeySAML interface populated with sample data. (Source: Secureworks)

After submitting the information, the tool user is prompted to pass the tokens to the Azure portal (see Figure 3).

Figure 2. WhiskeySAML prompt to pass the forged and signed Golden SAML tokens to Microsoft Office 365. (Source: Secureworks)

Azure presents a dialog confirming that the tool user is logged in as the target cloud user. The fully authenticated tool user can then perform any actions as that cloud user.

Back to the scenario...

Secureworks analysts discover that they can send portions of a Golden SAML token to various Microsoft OAuth2 endpoints. They decide to test the impact of this technique in the Azure Core Management API.

The analysts forge a Golden SAML token for the target Global Administrator, who is tied to the customer's Azure subscription. They pass the forged token to the Azure Core Management API to obtain a valid access token in the format of a JSON Web Token (JWT). They then pass the valid access token to the API to extract the Subscription ID for the customer's organization. By sending the Subscription ID and the access token back to the API, Secureworks analysts can enumerate all the virtual machine (VM) instances running in the environment.

The analysts pass information about each VM to the Azure Core Management API and realize they can execute commands as NT Authority/SYSTEM or root on all of these VMs, regardless of operating system. After running the 'whoami' command on all enumerated VMs, Secureworks analysts expand the test by executing a PowerShell stager that downloads a Cobalt Strike Beacon. This malware avoids detection by the antivirus and endpoint detection and response (EDR) solutions. Rate limiting did not appear to be enabled in the API, so a large amount of traffic was able to flow concurrently.

ShockNAwe

Secureworks researchers leveraged the TicketsPlease Python library to create a Python tool named ShockNAwe. When executed (see Figure 3), this tool performs the following functions:

1. Remotely extracts the AD FS configuration settings
2. Forges and signs a Golden SAML token
3. Extracts the 'assertion' portion of the Golden SAML token and passes it to the Azure Core Management API to obtain a valid access token for the API
4. Enumerates the Subscription ID
5. Enumerates the complete list of VMs in the subscription
6. Executes arbitrary commands on all VMs as SYSTEM/root

Figure 3. ShockNAwe tool execution. (Source: Secureworks)

Back to the scenario...

The customer maintains several internal domains in their Azure subscription. As a result, Secureworks analysts enumerate all the VMs in the customer's domain, as well as other domains in the subscription, and obtain SYSTEM/root access on all of these systems. Using ShockNAwe, the analysts are able to exploit all of the VMs in the subscription in less than two minutes (see Figure 4).

Figure 4. ShockNAwe used to execute malware as SYSTEM on all running VMs in the Azure subscription. (Source: Secureworks)

Conclusion

This technique can enable attackers to obtain SYSTEM/root level access to all the systems in an organization's Azure subscription. Any of the compromised systems could then be configured to allow the threat actors to move laterally to the associated networks, including potentially sensitive and specifically segmented networks. The ShockNAwe example demonstrates the widespread impact that compromising a Global Administrator account can have. An attacker could execute any payload, including ransomware. Although this scenario leveraged the Azure Core Management API, other APIs permit authentication via Golden SAML tokens.

Curious if your organization is vulnerable? Contact us to schedule a penetration test.