{
	"id": "6b42695e-fd59-417c-bcc9-94f887079a8d",
	"created_at": "2026-04-06T01:29:01.057944Z",
	"updated_at": "2026-04-10T03:21:23.403112Z",
	"deleted_at": null,
	"sha1_hash": "0d645d49e3b50c3dcd35e78134351dc3fe7ca1b4",
	"title": "Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1404585,
	"plain_text": "Golden SAML: Newly Discovered Attack Technique Forges\r\nAuthentication to Cloud Apps\r\nBy Shaked Reiner\r\nPublished: 2017-11-21 · Archived: 2026-04-06 00:13:21 UTC\r\nIn this blog post, we introduce a new attack vector discovered by CyberArk Labs and dubbed “golden SAML.”\r\nThe vector enables an attacker to create a golden SAML, which is basically a forged SAML “authentication\r\nobject,” and authenticate across every service that uses SAML 2.0 protocol as an SSO mechanism.\r\nIn a golden SAML attack, attackers can gain access to any application that supports SAML authentication (e.g.\r\nAzure, AWS, vSphere, etc.) with any privileges they desire and be any user on the targeted application (even one\r\nthat is non-existent in the application in some cases).\r\nWe are releasing a new tool that implements this attack – shimit.\r\nIn a time when more and more enterprise infrastructure is ported to the cloud, the Active Directory (AD) is no\r\nlonger the highest authority for authenticating and authorizing users. AD can now be part of something bigger – a\r\nfederation.\r\nA federation enables trust between different environments otherwise not related, like Microsoft AD, Azure, AWS\r\nand many others. This trust allows a user in an AD, for example, to be able to enjoy SSO benefits to all the trusted\r\nenvironments in such federation. Talking about a federation, an attacker will no longer suffice in dominating the\r\ndomain controller of his victim.\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 1 of 7\n\nThe golden SAML name may remind you of another notorious attack known as golden ticket, which was\r\nintroduced by Benjamin Delpy who is known for his famous attack tool called Mimikatz. The name resemblance\r\nis intended, since the attack nature is rather similar. Golden SAML introduces to a federation the advantages that\r\ngolden ticket offers in a Kerberos environment – from gaining any type of access to stealthily maintaining\r\npersistency.\r\nSAML Explained\r\nFor those of you who aren’t familiar with the SAML 2.0 protocol, we’ll take a minute to explain how it works.\r\nThe SAML protocol, or Security Assertion Markup Language, is an open standard for exchanging authentication\r\nand authorization data between parties, in particular, between an identity provider and a service provider. Beyond\r\nwhat its name suggests, SAML is each of the following:\r\nAn XML-based markup language (for assertions, etc.)\r\nA set of XML-based protocol messages\r\nA set of protocol message bindings\r\nA set of profiles (utilizing all of the above)\r\nThe single most important use case that SAML addresses is web browser single sign-on (SSO). [Wikipedia]\r\nLet’s take a look at figure 1 in order to understand how this protocol works.\r\nFigure 1- SAML Authentication\r\n1. First the user tries to access an application (also known as the SP i.e. Service Provider), that might be an\r\nAWS console, vSphere web client, etc. Depending on the implementation, the client may go directly to the\r\nIdP first, and skip the first step in this diagram.\r\n2. The application then detects the IdP (i.e. Identity Provider, could be AD FS, Okta, etc.) to authenticate the\r\nuser, generates a SAML AuthnRequest and redirects the client to the IdP.\r\n3. The IdP authenticates the user, creates a SAMLResponse and posts it to the SP via the user.\r\n4. SP checks the SAMLResponse and logs the user in. The SP must have a trust relationship with the IdP. The\r\nuser can now use the service.\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 2 of 7\n\nSAML Response Structure\r\nTalking about a golden SAML attack, the part that interests us the most is #3, since this is the part we are going to\r\nreplicate as an attacker performing this kind of attack. To be able to perform this correctly, let’s have a look at the\r\nrequest that is sent in this part – SAMLResponse. The SAMLResponse object is what the IdP sends to the SP, and\r\nthis is actually the data that makes the SP identify and authenticate the user (similar to a TGT generated by a KDC\r\nin Kerberos). The general structure of a SAMLResponse in SAML 2.0 is as follows (written in purple are all the\r\ndynamic parameters of the structure):\r\nDepending on the specific IdP implementation, the response assertion may be either signed or encrypted by the\r\nprivate key of the IdP. This way, the SP can verify that the SAMLResponse was indeed created by the trusted IdP.\r\nSimilar to a golden ticket attack, if we have the key that signs the object which holds the user’s identity and\r\npermissions (KRBTGT for golden ticket and token-signing private key for golden SAML), we can then forge such\r\nan “authentication object” (TGT or SAMLResponse) and impersonate any user to gain unauthorized access to the\r\nSP. Roger Grimes defined a golden ticket attack back in 2014 not as a Kerberos tickets forging attack, but as a\r\nKerberos Key Distribution Center (KDC) forging attack. Likewise, a golden SAML attack can also be defined as\r\nan IdP forging attack.\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 3 of 7\n\nIn this attack, an attacker can control every aspect of the SAMLResponse object (e.g. username, permission set,\r\nvalidity period and more). In addition, golden SAMLs have the following advantages:\r\nThey can be generated from practically anywhere. You don’t need to be a part of a domain, federation of\r\nany other environment you’re dealing with\r\nThey are effective even when 2FA is enabled\r\nThe token-signing private key is not renewed automatically\r\nChanging a user’s password won’t affect the generated SAML\r\nAWS + AD FS + Golden SAML = ♥ (case study)\r\nLet’s say you are an attacker. You have compromised your target’s domain, and you are now trying to figure out\r\nhow to continue your hunt for the final goal. What’s next? One option that is now available for you is using a\r\ngolden SAML to further compromise assets of your target.\r\nActive Directory Federation Services (AD FS) is a Microsoft standards-based domain service that allows the\r\nsecure sharing of identity information between trusted business partners (federation). It is basically a service in a\r\ndomain that provides domain user identities to other service providers within a federation.\r\nAssuming AWS trusts the domain which you’ve compromised (in a federation), you can then take advantage of\r\nthis attack and practically gain any permissions in the cloud environment. To perform this attack, you’ll need the\r\nprivate key that signs the SAML objects (similarly to the need for the KRBTGT in a golden ticket). For this\r\nprivate key, you don’t need a domain admin access, you’ll only need the AD FS user account.\r\nHere’s a list of the requirements for performing a golden SAML attack:\r\nToken-signing private key\r\nIdP public certificate\r\nIdP name\r\nRole name (role to assume)\r\nDomain\\username\r\nRole session name in AWS\r\nAmazon account ID\r\nThe mandatory requirements are highlighted in purple. For the other non-mandatory fields, you can enter\r\nwhatever you like.\r\nHow do you get these requirements? For the private key you’ll need access to the AD FS account, and from its\r\npersonal store you’ll need to export the private key (export can be done with tools like mimikatz). For the other\r\nrequirements you can import the powershell snapin Microsoft.Adfs.Powershell and use it as follows (you have to\r\nbe running as the ADFS user):\r\nADFS Public Certificate\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 4 of 7\n\nIdP Name\r\nRole Name\r\nOnce we have what we need, we can jump straight into the attack. First, let’s check if we have any valid AWS\r\ncredentials on our machine.\r\nUnsurprisingly, we have no credentials, but that’s about to change. Now, let’s use shimit to generate and sign a\r\nSAMLResponse.\r\nThe operation of the tool is as follows:\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 5 of 7\n\nFigure 2– Golden SAML with shimit.py\r\n1. 1. Generate an assertion matching the parameters provided by the user. In this example, we provided\r\nthe username, Amazon account ID and the desired roles (the first one will be assumed).\r\n2. Sign the assertion with the private key file, also specified by the user.\r\n3. Open a connection to the SP, then calling a specific AWS API AssumeRoleWithSAML.\r\n2. Get an access key and a session token from AWS STS (the service that supplies temporary credentials for\r\nfederated users).\r\n3. Apply this session to the command line environment (using aws-cli environment variables) for the user to\r\nuse with AWS cli.\r\nPerforming a golden SAML attack in this environment has a limitation. Even though we can generate a\r\nSAMLResponse that will be valid for any time period we choose (using the –SamlValidity flag), AWS specifically\r\nchecks whether the response was generated more than five minutes ago, and if so, it won’t authenticate the user.\r\nThis check is performed in the server on top of a normal test that verifies that the response is not expired.\r\nSummary\r\nThis attack doesn’t rely on a vulnerability in SAML 2.0. It’s not a vulnerability in AWS/ADFS, nor in any other\r\nservice or identity provider.\r\nGolden ticket is not treated as a vulnerability because an attacker has to have domain admin access in order to\r\nperform it. That’s why it’s not being addressed by the appropriate vendors. The fact of the matter is, attackers are\r\nstill able to gain this type of access (domain admin), and they are still using golden tickets to maintain stealthily\r\npersistent for even years in their target’s domain.\r\nGolden SAML is rather similar. It’s not a vulnerability per se, but it gives attackers the ability to gain unauthorized\r\naccess to any service in a federation (assuming it uses SAML, of course) with any privileges and to stay persistent\r\nin this environment in a stealthy manner.\r\nAs for the defenders, we know that if this attack is performed correctly, it will be extremely difficult to detect in\r\nyour network. Moreover, according to the ‘assume breach’ paradigm, attackers will probably target the most\r\nvaluable assets in the organization (DC, AD FS or any other IdP). That’s why we recommend better monitoring\r\nand managing access for the AD FS account (for the environment mentioned here), and if possible, auto-rollover\r\nthe signing private key periodically, making it difficult for the attackers.\r\nIn addition, implementing an endpoint security solution, focused around privilege management, like CyberArk’s\r\nEndpoint Privilege Manager, will be extremely beneficial in blocking attackers from getting their hands on\r\nimportant assets like the token-signing certificate in the first place.\r\nReferences:\r\nhttps://aws.amazon.com/blogs/security/how-to-set-up-federated-api-access-to-aws-by-using-windows-powershell\r\nhttps://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 6 of 7\n\nhttps://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-single-sign-on-protocol-reference\r\nSource: https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-clo\r\nud-apps\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"
	],
	"report_names": [
		"golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"
	],
	"threat_actors": [],
	"ts_created_at": 1775438941,
	"ts_updated_at": 1775791283,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0d645d49e3b50c3dcd35e78134351dc3fe7ca1b4.pdf",
		"text": "https://archive.orkl.eu/0d645d49e3b50c3dcd35e78134351dc3fe7ca1b4.txt",
		"img": "https://archive.orkl.eu/0d645d49e3b50c3dcd35e78134351dc3fe7ca1b4.jpg"
	}
}