AD FS Threat Hunting, Part 2: Golden SAML

By Yonatan Khen, Threat Hunting Expert at Team Axon

Recap & Executive Summary

In the previous part of this series, Part 1: AD FS Threat Hunting Series: DLL Adapter Attacks, we learned about the foundations and structure of Active Directory Federation Services (AD FS), its authentication workflow, and some memory adapter attacks that can be used against it. If you’ve found yourselves here before reading Part 1, we recommend reading that part first, since the theoretical concepts explained there form the background for this paper. 

In this installment, we won’t mess with claims, adapters, or any other inners of the AD FS <> Active Directory authentication workflow. Instead, we’ll see how we can manipulate the result of that authentication for our needs. In other words, we will explain how to abuse the way the AD FS cryptographically signs the security tokens to impersonate any user or entity within the applications in the federation. This technique is known as Golden SAML, and we’ll explore it deeply in this paper while sharing effective methods to detect and hunt for this activity.

Overview

As we’ve learned, Active Directory Federation Services (AD FS) is a type of federation IdP (Identity Provider) that establishes trust between different environments such as on-premises Active Directory, Azure, AWS, and many others. This trust allows a user in an AD on-premises environment to benefit from single sign-on (SSO) access to all trusted environments in the federation with the same identity. 

Golden SAML is a technique that enables an attacker, once they have gained privileged access to a victim's network and stolen the AD FS certificate, to impersonate the identity of any user in the organization and obtain any type of privilege across the majority of the organization's federation services. It is achieved by presenting forged identity objects to the relying party that is cryptographically signed by the stolen AD FS certificate.

High-level representation of Golden SAML

Golden SAML shares many similarities with Golden Ticket, which is a well-known on-premises AD technique. While Golden Ticket enables the impersonation of any user in an on-premises domain by signing forged TGTs with the KRBTGT hash, Golden SAML allows the impersonation of any SAML authentication within the federation by using the AD FS certificate. This allows abuse of login to any third-party SaaS application that has a trust relationship with the domain.

Similarly to Golden Ticket, the Golden SAML technique is not considered a vulnerability, but rather a flaw in the authentication process of AD FS, as the authentication trust of the relying party and the AD FS is built on that shared certificate.

A regular authentication flow of AD FS

In order to exploit the flaw, it is necessary to complete a series of steps. These can be accomplished with various methods, so before getting too deep, let’s lay out what those steps are. In order to exploit Golden SAML, one must:

1. Gain a foothold on the on-premises Active Directory domain 
2. Compromise the AD FS Certificate. Different methods are possible based on the level of permissions on the target enterprise AD. The methods are explained below
3. Extract relevant attributes based on the target service provider object. For example, accessing the O365 service provider requires ObjectGUID and UserPrincipalName (UPN). However, it might change based on the target Service Provider
4. Build a forged security token based on the claims and use the decrypted token-signing certificate to cryptographically sign the SAML security token
5. Create a custom-crafted packet using the forged SAML object to authenticate with the service provider

Deep Dive: Exporting AD FS Certificate

Now that we have gotten a high-level understanding of how to exploit the flaw, let’s review a couple of common methods to extract the AD FS certificate for leveraging Golden SAML.

Extracting the certificate from the MMC

Requirements:

• AD FS Server Local Access
• Local Admin
• Vulnerable Certificate (“exportable”)

When a certificate is created in the AD CS (Active Directory Certificate Services) the creator can configure the certificate to be “exportable.” This means that the private key will be available for exportation in any server the certificate was imported on. In that case, a potential attacker can export the certificate from the MMC cerlm, by simply navigating to the certificate store settings and exporting the related certificate from there.

This technique appears to be one of the easiest ways to access the AD FS certificate, and while this “exportable” configuration isn’t uncommon among enterprises it can put organizations that don’t enforce it at high risk. 

Vulnerable certificate settings in the AD CS 

Exploration through the cerlm MMC GUI 

Extracting the certificate using Certutil 

Requirements:

• AD FS Server Local Access
• Local Admin
• Vulnerable Certificate (“exportable”)

Certutil is a command-line utility in Windows that enables the management of certificates. Exporting a certificate using Certutil.exe involves running a command with the -ExportPfx parameter. To export a certificate, first, you need to identify the certificate's thumbprint or serial number which can be done by providing the certificate store name.

Certutil.exe -Store my 
Certutil.exe  -exportpfx <cerifcate store> <certThumb> <output>

 
It is important to note, that similarly to exporting the certificate from the MMC, the certificate has to be configured with an “exportable” flag on its private key. In case it isn’t, you’ll probably need to look for one of the other methods below.

Identify the certificate serial number

Extract the certificate using -ExportPFX

Extracting the certificate with patching CryptoAPI 

Requirements:  

• AD FS Server Local Access
• Local Admin

Exporting the certificate from the certificate store by patching CryptoAPI. 

As you might have guessed, this technique doesn't require an “exportable” private key configuration certificate in order to work. As the tool intercepts the calls to the vulnerable functions and modifies their behavior. Specifically, it intercepts the function calls to the CNG Key Isolation API and replaces them with its own code that bypasses the DPAPI and directly extracts the cryptographic keys from memory. A variety of tools provides that functionality, while Mimikatz is one of the most popular tools among them.

Exporting non-exportable certificate using Mimikatz

Extracting the certificate from AD FS ServiceSettings Table

Requirements:

• AD FS Service Account 

Exporting the certificate from the AD FS ServiceSettings table is by far the most commonly observed technique used by attackers and Red Teamers. This might be due to the popularity of the ADFSDump tool and a desire to avoid using more complex tools that require patching of internal functions like CryptoApi and memory protections in lsass.exe, which can be detected by security products. The technique involves extracting an encrypted AD FS certificate blob, also referred to as the "token signing certificate" from the AD FS Settings table, along with its decryption key, also known as the DKM.

To obtain the token signing certificate, the attacker must first have access to the AD FS service account. Once access is obtained, the attacker can open a named pipe to an external database that contains configuration settings for the AD FS server. The attacker then queries a table called ServerSettings under the IdentityServerPolicy schema to extract the EncryptedPfx element under SigningToken.

Please note: it is not possible for any other user in the Active Directory to open a named pipe to the relevant database and query the results, making it essential to have the necessary privileges associated with the AD FS service account object. 

Querying the ServiceSettings table

"EncryptedPfx” under the “SigningToken” Element

As explained above, the signing token certificate is an encrypted blob, and can’t be used to sign our forged SAML without having the decryption key, which is the AD FS DKM key.

Compared to the token signing certificate, querying the DKM doesn't require special privileges such as the AD FS service account context. 

The way that AD FS stores its configuration encryption key involves the use of a Distributed Key Manager (DKM) container which is located in the DC. The location of the container can be found in the configuration file within the ServerSettings table under the DkmSettings.Group element. 

 The DKM container GUID under DkmSettings.Group element

Inside the DKM container, there are one or more groups, and the correct group is the group GUID from the DkmSettings.Group element. Each group contains at least two contact objects, with one object always being named "CryptoPolicy".

To find the key, it is necessary to locate the ObjectClass contact type which isn’t named CryptoPolicy. 

To summarize the LDAP Object query: 

1. AD FS Default Container CN=ADFS 
2. Group GUID’s Object from DKMSettings
3. Find ObjectClass contact type which isn’t named CryptoPolicy within AD FS GUID group object 
4. thumbnailPhoto attribute is AD FS’ DKM

LDAP query example to retrieve the AD FS DKM

Deep Dive: Building a Forged Security Token

Obtaining the certificate is a crucial step in carrying out the attack, but it's only a part of the process. We still need to create a forged security token that we can present to the relying party object to which we want to authenticate.

As we discussed in a previous blog, the security token consists of the claims pipeline output, which are the issuing claims. Therefore, we need to gather more information and adjust the appropriate claims to the target object in order to create a relevant security token for the relying party we want to impersonate.

It's important to note that different relying parties will require different adjustments, so prior knowledge and research on the target relying party is necessary. Fortunately, Mandiant has kindly provided a tool name ADFSpoof, which simplifies the tedious work by collecting the necessary attributes for popular relying parties such as O365, Dropbox, and a generic SAML2 template that can be customized based on the target application.

Let’s take a look at the template of O365, and its requirements.

Elements that are required in all federated security tokens:

• Token Creation and Experiment time - Simply the token creation and experiment time which is required in security token in both versions. 
• AD FS trust endpoint - the trust endpoint of the internal AD FS server.
• AssertionID - Randomized GUID for the assertion security token. 

Required elements within a federated security token

Element attributes that are mandatory for O365 specifically:

• UserPrincipalName (UPN) - Universal identifier for the target O365 user object. It is composed from the username and the federated domain.
• ObjectGuid (Immutable id) -  The object GUID is a globally unique identifier assigned by Microsoft Active Directory Domain Services when the object instance is created.

Example of UserPrincipalName and ObjectGuid elements required for O365 authentication

ADFSspoof provides a predefined template for the relying party and automatic generation of the required parameters as well as the mandatory requirements based on the relevant relying party. 

A pre-defined function template from ADFSspoof tool for O365 security token

Let’s go hunting

Now that we have an understanding of how an attack can be carried out, we can now take a proactive approach. We will look at three different theses that can help you identify if this flaw has been exploited in your environment. 

In order to make the threat hunting effective and relevant, all the threat hunting theses presented below should be run in the context of AD FS servers. The AD FS servers can be identified by finding the AD FS service process Microsoft.IdentityServer.Servicehost.exe as discussed in the previous blog post in this series.

Note: Within Hunters' platform, they are automatically identified using the Asset Tagging feature, which reduces the complexity of the searches and makes them faster and more effective.  

Suspicious Login to the AD FS Service Account

Objective: Threat Hunting, Detection Engineering
Source: EDR Telemetry  

The AD FS Service account is a built-in user object which is generated during the creation of the AD FS service (server) in the on-premises AD.  Natively, and in case your organization wasn’t messing with the configuration of the service, it’ll only perform service logins as part of the normal behavior of the user. 

A valid threat hunting thesis would be identifying suspicious user logins that use login type codes other than service logins, specifically logon type 5 as represented in Windows event log 4624. Any non-service login should be viewed with suspicion, but an RDP login (logon type 10) is particularly concerning and could suggest unauthorized access to a service account.

So how do we identify and tag AD FS service accounts? Don’t worry, it is easier than you might’ve thought. The service account is the user who is running the AD FS service host process Microsoft.IdentityServer.Servicehost.exe when the service starts.

AD FS service account loading Microsoft.IdentityServer.Servicehost.exe

Just like the AD FS server tagging, at Hunters we automatically tag AD FS service accounts with the Asset Tagging feature. However, in order to facilitate the audience who doesn’t use the product, we’ve included an additional query below on how to identify the service account. 

Tagged AD FS service account in Hunters 

Investigation Flow:

• Examine the login type method and logon session used by the user
• Examine network and process creations by the service account in the context of the logon session

Query:  suspicious_login_adfs_service_account.sql

Team Axon Tip: Users have no justification for utilizing the AD FS service account. If you happen to come across instances of individuals logging on with the AD FS service account interactively, and it has been determined that the organization authorized such activity, it is essential to immediately cease the practice of using the service account. This is because you do not want the service account credentials to be present in various machines' memories.

LDAP packets from an unknown process

Objective: Threat Hunting, Detection Engineering
Source: EDR Telemetry 

Spotting LDAP packets to the DC from an unknown process on the AD FS server is a valid method to find tools that try to extract the DKM from the AD FS Default Container. While extracting the DKM isn’t supposed to be done from the AD FS service account context or even from the AD FS server itself, most of the tools such AdfsDump and ADDinternals module perform the activity altogether as part of their extraction technique. This was found to be a strong indicator for detecting threats using process and network audit alone, and without the need for named pipe and LDAP query telemetry.  

Investigation Flow:

• Examine the process that made the LDAP packet.
• Examine the modules the process was loading. Crypto modules for example are highly common to be used by certificate abuse tools.
  

Cross-Correlation, Federated login to a relying party without event log 1200

Objective: Threat Hunting, Detection Engineering
Source: AD FS Event Logs Auditing, Relying party telemetry 

This blog post has taught us that Golden SAML exploits the legitimate authentication flow of AD FS by presenting a forged SAML object to the relying party without passing through the AD FS itself. So, can we use cross-correlation detection to identify federated logins to the relying party without any indication of being recorded in the AD FS server? Yes, we can.

Whenever a user accesses a federated relying party, an AD FS auditing event log 1200 is generated with relevant attributes that represent the login. This event is created on the target AD FS server in the on-premises network.

1200 Windows Event Log from AD FS auditing

Furthermore, when a user accesses the relying party object itself, it should be logged by the service's auditing. It is uncommon to find relying party applications that do not at least provide telemetry for login activity. If we notice a login recorded in the relying party application logs without a corresponding log of 1200 that represents authentication against AD FS, we can assume that the user may have used a forged SAML object.

Forensics artifacts that are collected during legitimate authentication

Important tips to reduce noise:

• As you probably assume, different relying parties provide different telemetry for their application. In order to fit the detection to your needs, you should make sure you’re focusing on login records and not on authentication records. Authentication records are generated for accessing the application and utilizing the security token. Those actions shouldn’t have a matched 1200 event log prior to them, since they are not involving authentication with the AD FS server. The TTL of the SAML to your application is based on your organization's settings.
• Base your attributes matching on multiple unique values, such as the GUID of the user, the target application, or any other identification that is relevant to your relying party application.

Summary 

In this blog post, we’ve continued our journey by exploring AD FS attack flows and threat hunting practices. This part of the series discussed the Golden SAML attack which exists due to a design flaw in Active Directory Federation Services. We’ve taken you through how the exploitation works and how to build a proper detection and hunting program.

As this concludes the "AD FS Threat Hunting Series," we have aimed to provide a comprehensive overview of Active Directory Federation Services and hope that you have found this series informative and useful.

Stay vigilant, and keep your eyes open on your AD FS servers.

See you next time!

~Axon

References

• MSDN: Active Directory Federation Services
• Golden SAML by Shaked Reiner
• AADinternals by Nestori Syynimaa
• ADFSDump by Doug Bienstock
• ADFSpoof by Doug Bienstock
  

To stay updated on threat hunting research, activities, and queries, follow Team Axon’s Twitter account (@team__axon).