Security for Microsoft
Exploring the Golden SAML Attack Against ADFS
Introduction to the SAML attack against ADFS
In December 2020 news broke of FireEye suffering a breach. This shocked the world as FireEye is looked at as one organization that identifies APTs and shows how these groups compromise unsuspecting targets. To think that FireEye themselves be victim meant that everyone else had no chance. In fact, that turned out to be mostly true. Shortly thereafter we learned about the SolarWinds compromise, and the world scrambled. It was bad – really bad.
As more information was revealed we learned that the attackers behind this very large compromise had several objectives. One such objective involved gaining access to the cloud infrastructure of their victims. One attack avenue that seemed to have some mileage involved going after on-premises federated identity provider services with the intent to steal cryptographic keys from Active Directory Federated Services (ADFSs).
A similar attack was first documented by CyberArk Labs in 2017. They demonstrated how an attacker can bypass authentication checks by spoofing the SAML response and signing it with a stolen signing certificate to gain access to an Amazon Web Service account. CyberArk Labs also released a tool, called ‘Shimit’ [4] that demonstrated this. In 2019 Douglas Bienstock and Austin Bake of Mandiant built on this idea with their Troopers 19 presentation where they demonstrated how to achieve a similar result by targeting Microsoft ADFS. They also release two tools ADFSDump and ADFSpoof.
What is ADFS?
ADFS is used by businesses to improve user experience regarding authentication and access management. It is very likely that staff is exposed to several applications that each require authentication. If there are, for example, 5 systems then employees will need 5 separate sets of credentials, but in reality, staff will most likely reuse their existing password 5 times. Also, this will require staff in this example to potentially log in up to 5 times in a single day. This is cumbersome and will result in staff taking shortcuts, thus weakening security overall.
ADFS enables businesses to implement on-premise Single-Sign-On as this is a feature that can be enabled for Microsoft’s Windows Server. ADFS enables a business to proxy the authentication process by interfacing with various identity stores, with Microsoft Active Directory being a common use case. ADFS supports open standards such as the Security Assertion Markup Language 2.0 (SAML 2.0) and Web Services Federation Protocol or WS-Fed. Other authentication protocols such as OAuth 2.0 and OpenID Connect are also supported. This allows ADFS to be used as a common junction for authentication with any web application that is compatible with these authentication schemes.
Moving to the cloud
Many businesses started before cloud computing was born or before it was as prominent as it is now. This means these businesses have substantial hardware and software estates that they are responsible for. Many businesses have a cloud adoption strategy, and this could be a partial or full migration. In December 2020 Deloitte referred to an IDC estimate that claims that more than 90 percent of global enterprise will rely on a hybrid cloud strategy by 2022, meaning that parts of business infrastructure still reside on-premises while specific aspects will run on some form of cloud infrastructure. Gartner predicted that 2021 would see an 18 percent growth totaling $304.9 billion in public cloud end-user spending.
Microsoft is an important vendor for many businesses and even governments. Statista lists Microsoft as having 47.5 percent of the productivity software worldwide as of May 2021. Similarly, Statista also lists Microsoft as having just over 71 percent of the desktop market for the period 2012 through 2021. There is a good chance that businesses that already committed a significant number of resources to the Microsoft tech stack have also adopted Microsoft’s Azure and Microsoft 365 cloud offerings. Microsoft also made it easy for existing clients to move parts of their critical on-premises infrastructures, such as Active Directory to Microsoft Azure. This all plays nicely into enabling Microsoft 365, previously known as Office 365.
Path of least resistance
The SolarWinds attackers knew that several of their potential targets were storing information in the cloud, and it would be less hassle to compromise the on-premises solutions and then pivot to the cloud, than trying to hack into Microsoft Azure blind. Simply put, it is far easier to log in than to hack into cloud services.
Starting with the assumption that an attacker has already breached a network and managed to extract the full Active Directory of the organization, meaning they have all the accounts and associated cryptographic details (hashes) of the target business. This alone is not necessarily enough for our attacker to pivot to the cloud. The attacker must still manage to crack the hashes to uncover passwords for some key accounts and then they might also face multi-factor authentication (MFA) challenges. This approach seems less than optimal when compared to a strategy that will guarantee access without having to know the password or be concerned with hurdles such as MFA.
These attackers have done their homework and knew of services such as ADFS that could open many doors for them. A benefit of compromising a federated identity provider such as ADFS is that it potentially can give you access to other services, not just Microsoft 365 or Azure. Any trusted relationship between ADFS and other services such as Amazon Web Services, SAP Enterprise Portal, SalesForce, ServiceNow, bespoke business-to-business or business-to-government applications that user federated identity services come into scope.
An overview of the attack
Once on the internal network, an attacker can determine if there are any ADFS installations and proceed to access these with the intent to extract sensitive information from those hosts. Hosts running ADFS is just a Windows Server. If the attacker dumped the target organization’s Active Directory, then getting onto an ADFS host is not so difficult but would still leave footprints when they interact with services on this host.
The attacker needs to extract two pieces of cryptographic material. The first piece is the X509 token signing certificate used by the ADFS server to prove its authenticity to the peer application that asked it to authenticate the user. The second piece is the private key that will unlock the encrypted token signing certificate stored in the Distributed Key Management service associated with the ADFS’ service account. With this information, the attacker can spoof authentication responses without even having to know the password or require access to a paired MFA token.
This is all possible because of the way the authentication mechanism works. There exists a trusted relationship between ADFS and the application that deferred the authentication to the ADFS, the latter referred to as the Relying Party in Microsoft parlance. The workflow involves a user wanting to gain access to a specific application that has a Relying Party trust established with the domain associated with an ADFS. When the application determines that it is not responsible for the authentication of a specific user it redirects the user to the respective identity provider or ADFS in this case. This process is asynchronous, meaning that the application redirects the user to the applicable ADFS server and the application forgets about that user. It is now the responsibility of the applicable ADFS to verify the identity of the user. The Relying Party has no role to play during this process. The Relying Party or application comes back into scope once the respective ADFS server has decided the outcome of the authentication process. At this stage, it is important for the application to verify the authenticity of the response from the ADFS. This is done using the exchanged public certificate it obtained when the trust relationship was established initially. The application trusts that the ADFS did its part to verify the users’ credentials and enforced the MFA interaction if any. If an attacker managed to spoof the response, then that application will be none the wiser.
Dissecting the details
We mentioned that there exists tooling to extract the necessary cryptographic pieces. One such tool is ADFSDump. The attacker needs to execute the .NET runtime on the host with the ADFS service but in the context of the account under which ADFS is running. Best practices for running ADFS is to use a service account, thus the attacker needs to run as that. The main reason for this is to extract the private key stored in the DKMS. This way is setup is to limit access to this key and should only be retrieved for accounts such as the ADFS service. This access list must be very narrow and must not include any other account. Not even the domain administrator must have access to this key.
In this ADFSDump screenshot that was running against a test network, we can see there are three decryption keys, labeled as ‘Private Key’, being returned plus an encrypted token signing key. The correct private key can be used to decrypt the encrypted token signing key.
ADFSDump also extracts other useful information about all the Relaying Parties. This allows the attacker to know what information needs to be included in the spoofed message.
The following screenshots show three trust relationships. One with ClaimsXray, a Microsoft SAML debugging utility, Microsoft Office 365 Identity Platform, and AWS.
ADFS uses claims-based authentication and the Access Policy Parameters are essential for how ADFS works. These are rules that are used to transform identity provider fields into specific representations that the Relying Party understands.
Armed with this information the attacker can now proceed to generate a spoofed response when they wish to gain access to a specific application that the user has access to. Identifying which user has access to which application is not obvious and depends on the scheme used by the system administrators. Some group users by role and access, assigning these users to specifically named directory service groups. Here is an example of where the claim rule uses the ‘AWS-‘ prefix in the group name to map the user to a specific AWS role:
The attacker can use a web application testing tool such as BurpSuite, a favorite of some penetration testing teams, to assist with fooling the targeted service. BrupSuite is a person-in-the-middle tool that can intercept HTTP requests and responses. This allows the attacker to modify these messages. With this, the attacker is now in the position to initiate the attack. In this example, they will target a user that has an account on Microsoft 365.
The attacker can browse to the Microsoft Office website and click the ‘Sign In’ button, thus initiating the authentication process.
Next, the attacker supplies the user’s email address. At this point, Microsoft 365 will determine that it is not responsible for the identity being queried. The backend service of Microsoft 365 will retrieve the details of the trusted identity provider and redirect the user’s browser to the host associated with the domain specified.
Here we can see that the ADFS service ‘adfs.tokelosh.net’ was invoked and it must now handle the authentication for the user ‘testuser1@tokelosh.net’.
The attacker does not know the password, nor do they have access to an MFA token. As we said earlier, this is not required. The attacker can use the information they stole to generate the appropriate WS-FED response, sign it with the token signing certificate, and send it back to Microsoft 365. The ADFSpoof tool by Mandiant facilitates this step nicely.
The spoofed ADFS response is sent back to Microsoft 365 by using BurpSuite. This requires the attacker to substitute certain fields with the output from ADFSpoof.
Microsoft 365 is happy with the spoofed WS-FED response and gives the attacker access. They are now ‘testuser1@tokelosh.net’ and have access to whatever that user has access to.
Detection
Fortunately, there are ways to detect part of this attack. Accessing the DKMS and retrieving the private key leaves some fingerprints in the form of a Windows Security Event, specifically Event ID 4662. This even lists who access the DKMS and which entry therein was queried.
Roberto Rodriguez, also known as Cyb3rWard0g, was one of the early defenders to publish a Microsoft Sentinel detection for this. Orange Cyberdefense has had this detection for a while now and we have customized it to fit our detection strategy. One thing to bear in mind when designing this rule is to test it as the ADFS service, as a legitimate service, will at start-up request access to this key. This could mean false positives that need to be accounted for. The anomalies come in when the requests to the DKMS happen out of sync with ADFS service start-up or refresh or when the user requesting access to the private key does not match the ADFS services account name.
The second detection is around the exporting of the encrypted token signing certificate. This detection is described by O365Blog and involves performing changes to the Windows Internal Database or SQL Server used by ADFS. Ultimately administrators will need to update the access list for select queries. This will result in a Windows Event Log entry with Event ID 33205. This entry will occur when the account requesting access to the WID or SQL Server is different to the account used by the ADFS instance.
Security teams also need to account for logins to the ADFS host and correlate those with scheduled or legitimate activity. This needs to be specifically followed up on when access to the WID is initiated using the ‘sqlcmd’ command, tools such as SQL Management Studio, or unknown processes such as ADFSDump.
Finally, Mandiant recommends that system architects may need to consider using a Hardware Security Module (HSM) to store the private key that is used to decrypt the token signing certificate. This will enable much stricter controls on which processes have access to the private key and is less likely to be compromised. This may require additional work when crafting detections for Microsoft Sentinel for example.
