The Long Road to Rebuilding Trust After 'Golden SAML'-Like Attacks

Recent breaches, such as those related to the SolarWinds supply chain attack, have focused attention on the considerable challenges that organizations face re-establishing trust in a network where an adversary may have maintained privileged access on it for some time.

In several of the breaches, attackers stole the victim organization's Active Directory Federation Services (ADFS) token-signing certificate and used it to forge SAML tokens for arbitrary users. The tactic — which some refer to as Golden SAML — allowed the attackers to authenticate to the breached organization's Microsoft 365 environment — and to other federated services — as any user without needing a password or going through a multifactor authentication process.

The attack vector let threat actors maintain persistent, privileged access on breached networks, allowing them to move laterally and carry out other malicious activities without being spotted.

Such attacks pose a big problem both from a detection and a mitigation standpoint.

"Attackers that are able to take over privileged identities can make highly impactful changes to application settings, master data, and other configurations," says Kevin Dunne, president at Pathlock.

Golden SAML further complicates the problem by giving intruders a way to have evergreen, privileged access on a network that cannot be easily terminated through a password reset or forced multifactor authentication, he says.

Determining the actions an attacker might have taken on the network using their privileged access can be extremely hard to do, especially if they are good at wiping their tracks. In fact, once an attacker gets into the network with a privileged foothold, their options for doing damage are basically limitless, says Shaked Reiner, security researcher at CyberArk, the vendor that first sounded the alarm on Golden SAML back in 2017.

An attacker, for instance, could create backdoors on the network or generate tokens that allow persistent access to a breached network without being on it. The attacker also could add a user to the domain admin group or other highly privileged group, or quietly add specific privileges — like resetting the password of a domain administrator — to a regular user account, Reiner says.

"We can't really know for sure what the attackers did," Reiner says. "There is sometimes a possibility they did something that we don't even know to look for."

Re-establishing trust in the aftermath of a Golden SAML attack or similar attacks can be potentially disruptive. If an organization suspects that a Golden SAML attack has been used against them, the most important step is to rotate the token signing and token encryption certificates in ADFS twice in rapid succession, says Doug Bienstock, manager at FireEye Mandiant's consulting group.

This action should be done in tandem with traditional eradication measures for blocking any known malware and resetting passwords across the enterprise, he says. Organizations that don't rotate — or change — the keys twice in rapid succession run the risk of a copy of the previous potentially compromised certificates being used to forge SAML tokens.

Potential Disruption
CyberArk's Reiner says key rotation could cause disruption if security teams are not prudent about how it is implemented.

"Rotating means revoking the old key and creating a new one," he says. "That means you have removed the trust between your own network and other cloud services."

In normal situations, when an organization wants to rotate existing keys, there's a grace period during which the old key will continue to work while the new one is rolled out. With key rotation in the wake of a Golden SAML attack, organizations won't have that luxury, Reiner says.

The same issue is present when it comes to other mitigation measures designed to evict a privileged intruder from the network. In many cases, for instance, organizations can get a measure of security by restoring all potentially affected machines to a golden image, resetting all passwords for all accounts, and re-creating all private keys or secrets, says Oliver Tavakoli, CTO at Vectra. However, in situations where an attacker might have had privileged access, organizations cannot afford to make these changes on a rolling basis, he says.

"A smart attacker can switch to the already cleansed region before you get to the space they inhabit [on the network]," he says. "So the practical reality of having to do the cleanup simultaneously across all vectors is what makes this very difficult and disruptive."

Complete, guaranteed eradication is very difficult and sometimes might require every piece of hardware to be scrapped and replaced with new gear, Tavakoli says.

Mandiant's Bienstock says organizations can rebuild trust with minimal disruption by maintaining an up-to-date inventory of cloud applications they are federating with ADFS. They also need a practiced playbook for resetting ADFS certificates. The playbook should include refreshing the connection between the ADFS and cloud applications so the latter will trust the new ADFS certificates, he says.

"Organizations that are well-versed in this procedure should be able to perform it relatively quickly and keep downtime minimized," he says.

Mandiant recommends that organizations also take proactive steps to harden their on-premises ADFS environment to make it harder for attackers to pull off Golden SAML-style attacks. The steps it recommends include configuring a dedicated on-premises ADFS service account with restricted access rights, reviewing ADFS logging and auditing settings, and tightly restricting access to ADFS servers.

"On-premises ADFS servers should be considered Tier 0 assets," the security vendor says. "Mandiant recommends restricting access to the ADFS servers to an even smaller subset of unique accounts than the typical 'Domain Administrators' group."

Tim Wade, technical director at Vectra, says that when it comes to the broader issue of keeping an eye on privileged accounts, organizations should audit both the privileges that have been granted to specific accounts and to how those privileges are actually being used. Organizations should identify the set of critical roles and entitlements to be audited and deploy technologies for monitoring use of those privileges. Such monitoring can help organizations detect and respond in real time to the leading indicators that privilege is being abused, he says.

"Understanding privilege and its associated risks and periodic audits are necessary but insufficient due to the combined complexity and velocity of today's enterprise," Wade says.