Skip to content
Alex DowApr 26, 20213 min read

Golden SAML Attacks in 5

In 2017, CyberArk conceptualized a new attack technique called the “Golden SAML”. Coined after the “Kerberos Golden Ticket” attack which targeted Windows Active Directory and giving a hat tip to the movie Willy Wonka and the Chocolate Factory, these attacks if successfully executed would allow an attacker to forge their way through and bypass authentication controls.

That said, up until recently the Golden SAML attack was conceptual and not seen in the wild. However, in December 2020 as the Solarwind cyber attack unfolded, it was determined that M365 accounts had been compromised by way of the Golden SAML attack technique.

What is SAML?
SAML is an open authentication and authorization standard. SAML or Security Assertion Markup Language, is commonly used by web applications to authenticate users via a third party identity provider such as AzureAD, Duo or even Facebook. SAML relies on a cryptographic trust between the web app or “service provider” (SP) and an “identity provider” (IdP).

When a user authenticates to an SP, they are redirected to the IdP to authenticate. Upon successful authentication to the IdP, a cryptographically signed “SAML Assertion” is given to the user to complete their authentication with the SP.

How Does the Golden SAML Attack Work?
Cryptographic trust must be established before an SP will accept SAML Assertions from an IdP. The golden SAML attack generally speaking, involves compromising the IdP to enable the attacker to create their own SAML Assertions, thus creating a “skeleton key”.

Now with Cloud based IdPs such as Duo, Okta, AzureAD and many others, the attack surfaces are arguably built resilient and highly monitored. This makes the once conceptual attack very challenging to execute against Cloud based IdPs. However, in the case of the Solarwind cyber attack, attackers did not target the modern day Cloud based IdP infrastructure, but rather targeted the less secure legacy on-premise IdP infrastructure of several high profile victims.

Step 1: Compromise the On-Prem
The vast majority of large enterprises still rely on internal Active Directory infrastructure and leverage Active Directory Federated Services (ADFS) to establish trusts to external IdPs such as AzureAD. This enables large enterprises to operate a hybridized identity model allowing internal Active Directory users to access Cloud based services through their internal credentials.

Attackers in the Solarwind cyber attack, had initially compromised Solarwind’s SDLC and shimmed in a clandestine backdoors into Solarwind’s Orion software. Orion is a network monitoring tool which is deployed in most enterprise environments and is configured with elevated credentials to access and monitor important infrastructure…. Such as on-premise Active Directory servers.

Step 2: Writing Your Own Ticket
Attackers leveraged the backdoored Orion software to gain administrative access to (a still undetermined number of victim’s) Active Directory servers where they were able to acquire the signing certificates for SAML objects. Once the signing certificate had been stolen, the attackers were able to forge SAML Assertions and gain unfettered access to any and all Cloud assets.

It Gets Worse ☹
Multi-factor authentication (MFA) is an important security control which should be applied for most authentication requirements to mitigate the inherent weakness of password based authentication. When a user is redirected to an IdP to authenticate, the IdP will challenge the user with multi-factor authentication. Once a user provides a username, password, and a secondary factor the IdP authenticates the user and issues a SAML assertion. However, when an attack can “write their own ticket” through a Golden SAML attack, our beloved MFA is bypassed.

Prevention and Detection
The million dollar question, one which cannot be answered in a few paragraphs. To add insult to injury, Microsoft’s own recommendations to mitigate Golden SAML attacks is to disable ADFS, which is not reasonable in most cases. That said, here are a few tips:

  • Improve threat prevention and detection within business-critical parts of on-premise infrastructure

  • Harden Windows Active Directory, reduce privileges, and consider leveraging Privilege Access Management solutions

  • Re-assess what systems, like Orion, may be overprivileged in your on-premise environment (supply chain risk management)

  • Consider frequent credential rolling both on signing certificates as well as expirations of assertions

  • Ensure proper logging within web applications to support detection capabilities

Lastly, how can Golden SAML attacks be detected? This again is not a simple answer, but here are a few tips:

  • Detect attempts to export certificate data on your Active Directory Servers

  • Detect non-planned changes in trusts between on-premise AD or AzureAD and other IdPs

  • Correlate authentication logs where an SP logs an authentication message, but there is no corresponding authentication message from the IdP (on prem AD)