{
	"id": "618aaea2-983e-485c-a4df-0159425cf417",
	"created_at": "2026-04-06T00:21:22.833356Z",
	"updated_at": "2026-04-10T03:21:35.031423Z",
	"deleted_at": null,
	"sha1_hash": "4b2c53255815959c760b5243b56a03077b7a81b6",
	"title": "Detection And Hunting Of Golden SAML Attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 215207,
	"plain_text": "Detection And Hunting Of Golden SAML Attack\r\nBy Sygnia\r\nPublished: 2021-07-21 · Archived: 2026-04-05 21:54:43 UTC\r\nThe SolarWinds software supply chain attack is known to have affected U.S. government agencies, critical\r\ninfrastructure entities, and private sector organizations by an advanced persistent threat actor since at least March\r\n2020. U.S. authorities now believe that additional initial access vectors other than the SolarWinds platform exist,\r\nbut these are still being investigated. The US Cybersecurity \u0026 Information Security Agency (CISA) expects that\r\nremoving this threat actor from compromised environments will be highly complex and challenging.\r\nOne of the major techniques used by the threat actor as part of the SolarWinds attack, was compromising the\r\nSecurity Assertion Markup Language (SAML) signing certificate, using their Active Directory privileges. CISA\r\nexplained that “once this is accomplished, the adversary creates unauthorized but valid tokens and presents them\r\nto services that trust SAML tokens from the environment. These tokens can then be used to access resources in\r\nhosted environments, such as email, for data exfiltration via authorized application programming interfaces\r\n(APIs)”[1].\r\nThe “Golden SAML” attack technique enables attackers to forge SAML responses and bypass ADFS\r\nauthentication to access federated services. First reported by CyberArk in 2017, the current attack is the first time\r\nthat this technique is known to have been used “in the wild”.\r\nTo successfully leverage Golden SAML, an attacker must first gain administrative access to the ADFS server and\r\nextract the necessary certificate and private key. Once this is accomplished, unauthorized access can be performed\r\nfrom anywhere, without further access to the victim environment.\r\nUnless discovered and remediated, this attack provides attackers with persistent access to all services federated\r\nwith ADFS. Such services often include critical infrastructure and sensitive data such as AWS and Office 365.\r\nAccounting for some of the key functions and systems that commonly use SAML, CISA referred to hosted email\r\nservices, hosted business intelligence applications, travel systems, timecard systems, and file storage services\r\n(such as SharePoint).\r\nThe recent rise in awareness and novel in-the-wild use of this attack significantly raises the likelihood of attackers\r\nleveraging it to their advantage. It is therefore highly advised that organizations move swiftly in taking the\r\nnecessary steps to protect their SSO infrastructure and establish effective monitoring to detect and respond to such\r\nattacks.\r\nGolden SAML Attack\r\nIn order to explain the Golden SAML attack, we’ll first provide a short description of the legitimate SAML\r\nauthentication process. The process involves the following steps, illustrated in Figure 1:\r\n1.  User attempts to access desired service (e.g. AWS, Office 365).\r\nhttps://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nPage 1 of 6\n\n2.  Service redirects user to ADFS for authentication.\r\n3.  User authenticates with ADFS according to Domain policy (e.g. Multi-Factor-Authentication).\r\n4.  ADFS returns signed SAML response to user machine.\r\n5.  User presents desired service with signed SAML response and receives access.\r\nFigure 1: Legitimate SAML Authentication Process\r\nWhen performing a golden SAML attack, an adversary must first gain administrative privileges on the ADFS\r\nserver through additional Lateral Movement and Privilege Escalation. Once these privileges are obtained, the\r\nattack will proceed according to the following steps, illustrated in Figure 2.\r\n1.  Attacker accesses ADFS server and extracts private key and certificate.\r\n2.  User attempts to access desired service (e.g. AWS, Office 365).\r\n3.   Service redirects attacker to ADFS for authentication.\r\n4.  Bypassing ADFS authentication, attacker signs a forged SAML response with stolen key.\r\n5.   Attacker presents desired service with signed SAML response and receives access.\r\nhttps://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nPage 2 of 6\n\nFigure 2: Golden SAML Attack Process\r\nAs can be seen in the attack process, once the ADFS private key and certificate are compromised attackers will\r\ngain persistent access to all relevant services. Critical data and infrastructure can now be compromised without\r\nany additional access to the victim environment. This powerful access will persist until the existing ADFS private\r\nkey is invalidated and replaced, a difficult process requiring altering or terminating connectivity to all federated\r\nsystems and re-creating them.\r\nThe increasingly rapid transition of critical assets to cloud services is making ADFS SAML and other SSO\r\ninfrastructures lucrative high value targets for threat actors. The current hype and increased attention may lead to a\r\nrise of Golden SAML attacks. Along with the difficulty of remediating such attacks and the persistent access\r\nafforded to a successful attacker, we expect this technique to present a major challenge for defenders, SOCs and\r\nsecurity teams.\r\nDetecting and hunting Golden SAML attack\r\nBased on understanding the attack process and modeling the attack in several environments, we recommend the\r\nfollowing analyses to detect a Golden SAML attack. While there are many potential detection mechanisms which\r\nare only applicable when attackers erroneously leave unnecessary traces, our focus in this section will be on\r\nanalyses capable of detecting any standard Golden SAML attack.\r\nThe analyses proposed here are designed for a standard Golden SAML attack, targeting an on-prem ADFS\r\narchitecture. Other variations of SAML attacks, such as those targeting Azure AD, may require additional\r\ndetection analyses.\r\nDetection Method 1 – Correlating service provider login events with corresponding authentication events in\r\nADFS and Domain Controllers\r\nWhen performing legitimate authentication to an on-prem ADFS, the following events are logged:\r\nIn the ADFS server Windows Security Event Log:\r\nEvent id 1202 – “The Federation Service validated a new credential”.\r\nEvent id 1200 – “The Federation Service issued a valid token”.\r\nhttps://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nPage 3 of 6\n\nIn the Domain Controller Windows Security Event Log:\r\nEvent id 4769 – “A Kerberos service ticket was requested”, the source IP being the ADFS.\r\n In the service provider logs:\r\nAppropriate log for each service, indicating a successful login (e.g. ‘ConsoleLogin’ or\r\n‘AssumeRoleWithSAML’ in AWS or ‘Sign-ins’ in Azure AD).\r\nHowever, when authenticating with a Golden SAML forged response the only event logged is the login to the\r\nservice provider. The ADFS and Domain Controller are not involved in the authentication process in this scenario,\r\nand therefore do not log any events. While an attacker may also create a TGS request leaving behind a Kerberos\r\nrequests (Event id 4769) on the Domain Controller, they cannot successfully authenticate to ADFS and create the\r\nstandard authentication events.\r\nTherefore, in order to detect Golden SAML authentications we can simply search for any logins to service\r\nproviders using SAML SSO, which do not have corresponding 4769, 1200 and 1202 events in the Domain.\r\nThis detection mechanism is powerful, as it strikes at the core difference between a legitimate SAML\r\nauthentication and a Golden SAML attack.\r\nIn order to facilitate this analysis, ensure the above mentioned events are enabled in audit policy:\r\nAudit ObjectAccess: success and failure on ADFS for event ids 1200 and 1202.\r\nAccountLogon – Kerberos Service Ticket Operations: success and failure on the Domain Controllers for\r\nevent id 4769.\r\nApplicable login audit logs from service provider.\r\nDetection Method 2 – Identifying certificate export events in ADFS\r\nAs previously mentioned, a Golden SAML attack requires the private key and certificate of the ADFS. Access to\r\nthese can be obtained by exporting the certificate from the ADFS server, generating event id 1007 (enabled by\r\ndefault) in the ‘Microsoft-Windows-CertificateServicesClient-Lifecycle-System’ Windows Event Log.\r\nAdditionally, command-line evidence for exporting the ADFS certificate is likely incriminating. In many cases\r\nthese can be found in:\r\nPowerShell script block logs: ‘Export-PfxCertificate’ or ‘certutil -exportPFX’ in event ids 4103 and 4104.\r\nCommand line auditing tools (e.g. event id 4688): using certutil.exe -exportPFX.\r\nExecution evidence of known tools such as Mimikatz and ADFSDump. Certificate extraction with\r\nADFSdump can be detected using Sysmon Event id 18, when the pipe name is\r\n“\\microsoft##wid\\tsql\\query”, excluding processes regularly making this pipe connection on the machine.\r\nDetection Method 3 – Customizing SAML response to identify irregular access\r\nIn order to facilitate an additional layer of monitoring, organizations can modify their SAML responses to include\r\ncustom elements for each service provider. Once enabled, these custom elements can be monitored in service\r\nhttps://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nPage 4 of 6\n\nprovider access logs to detect any anomalous requests. While these parameters can be faked by an attacker, they’re\r\nlikely to be different and facilitate effective detection of Golden SAML attacks.\r\nDetection Method 4 – Detecting malicious ADFS trust modification\r\nAn attacker gaining administrative access to ADFS may, instead of extracting the certificate and private key for a\r\nstandard Golden SAML attack, add a new trusted ADFS. This approach will enable them to sign valid SAML\r\nresponses and gain persistent access to resources, while evading detection by methods 1-3 . This attack can be\r\ndetected by monitoring the creation of new ADFS trust, using these events in the ADFS server Windows Security\r\nEvent Log:\r\nEvent id 307 – “The Federation Service configuration was changed”. This event can be correlated to\r\nrelevant event 510 with the same Instance ID for change details.\r\nEvent id 510 with the same Instance ID – could be more than one event per single 307 event. These events\r\nshould be reviewed, specifically searching for “Configuration: Type: IssuanceAuthority“ where “Property\r\nValue” references an unfamiliar Domain.\r\nDetecting SAML attack scenarios in additional architectures\r\nDifferent SAML architectures involving multiple identity providers and Cloud services may change the way\r\ncertain SAML attacks are carried out. While these architectures may vary significantly, we decided to focus our\r\nattention in this section on two main potential architectures: Cloud identity providers and multiple/hybrid identity\r\nprovider architectures.\r\nMultiple Identity Provider Architectures\r\nAs different architectures may utilize multiple ADFS instances from different Domains or organizations, it\r\nis vital to ensure log collection and analysis is performed on all relevant ADFS. When utilizing a multiple-ADFS or hybrid ADFS-Azure AD architecture, different tokens are created by each identity  provider.\r\nAttackers targeting this infrastructure can compromise one identity provider, leaving no trace of malicious\r\nactivity on the other. This means legitimate authentication events may be viewed on the ADFS or Azure\r\nAD instance authenticating with the service provider, but not on all upstream instances which may have\r\nbeen attacked, as can be seen in Figure 3. To ensure effective detection, each ADFS trust relationship\r\nshould be analyzed as an IDP-SP pair, following the same logic applied in the previous section (detection\r\nmethods 1-3).\r\nCloud Only Identity Provider Architectures\r\nFederation architecture only utilizing Azure AD as an identity provider mitigates the standard Golden\r\nSAML attack vector, as the certificate and private key are stored in Azure instead of in ADFS on-prem.\r\nHowever, an attacker gaining administrative access to Azure AD may add federated ADFS instances under\r\ntheir control, thereby enabling themselves to sign valid SAML responses and gain persistent access to\r\nresources. While not a classic Golden SAML attack, this attack can be detected by monitoring the “Set\r\nfederation settings on domain” activity type and ensuring no unknown ADFS instances are federated to\r\nAzure AD. It is also recommended to verify existing federation under Azure AD Connect, to detect\r\nprevious compromise.\r\nhttps://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nPage 5 of 6\n\nFigure 3: Multi Identity Provider SAML Architecture\r\n[1] CISA Alert (AA20-352A)Advanced Persistent Threat Compromise of Government Agencies, Critical\r\nInfrastructure, and Private Sector Organizations.\r\nSource: https://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nhttps://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.sygnia.co/threat-reports-and-advisories/golden-saml-attack/"
	],
	"report_names": [
		"golden-saml-attack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434882,
	"ts_updated_at": 1775791295,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4b2c53255815959c760b5243b56a03077b7a81b6.pdf",
		"text": "https://archive.orkl.eu/4b2c53255815959c760b5243b56a03077b7a81b6.txt",
		"img": "https://archive.orkl.eu/4b2c53255815959c760b5243b56a03077b7a81b6.jpg"
	}
}