{
	"id": "77caecf6-3ec5-4726-a882-65c148ae7f61",
	"created_at": "2026-04-06T00:21:48.146501Z",
	"updated_at": "2026-04-10T03:24:29.14984Z",
	"deleted_at": null,
	"sha1_hash": "8baebe280bd48bf3856d94273de69ac8be3aa24a",
	"title": "A Golden SAML Journey: SolarWinds Continued | Splunk",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 102872,
	"plain_text": "A Golden SAML Journey: SolarWinds Continued | Splunk\r\nBy Marcus LaFerrera\r\nPublished: 2021-01-08 · Archived: 2026-04-05 20:38:05 UTC\r\nSplunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we\r\nno longer use. For more information on our updated terminology and our stance on biased language, please visit\r\nour blog post. We appreciate your understanding as we work towards making our community more inclusive for\r\neveryone.\r\nT L;DR: In this blog post we will review what SAML is, how what is old is new again, and how you can start\r\ndetecting and mitigating SAML attacks. Our focus for detection is intended as scaffolding to get you started,\r\nrather than a solution that will work for everyone and all installations. We won’t spend much time going over\r\nSunburst or Supernova, instead, we will focus on some lessons learned and how we can better position ourselves\r\nagainst future attacks.\r\nWhat is SAML?\r\nSecurity Assertion Markup Language (SAML) is a method for exchanging authentication and authorization\r\nbetween trusted parties. It’s essentially an XML schema that allows for federated Single Sign-On (SSO) to work.\r\nAt least, this is how it’s most commonly used today. The basic construct is when a client attempts to authenticate\r\nwith a service provider, they are redirected to an authentication server. Once authenticated, they are provided a\r\ncryptographically signed response that the client then provides back to the service provider. Once received, the\r\nresponse is validated thanks to the magic of cryptography. At least, that’s how it’s supposed to work and keep us\r\n(and our data) safe.\r\nIf this is confusing, take a look at this flow chart from Sygnia:\r\n(Image credited to Sygnia)\r\nWithout SAML, our system administrators would have to create countless new accounts for each service we all\r\nneed to do our jobs. That means we’d have to remember multiple usernames and passwords for each service\r\n(because, you never reuse passwords, right?) and also have to ensure they are periodically updated. It would be an\r\nadministrative nightmare for system admins and users alike. Thankfully, technology has saved the day and\r\nallowed us all to rest easy at night.\r\nA Brief History of Golden SAML\r\nWell, that was nice while it lasted. As with any technology, there are weaknesses that our adversaries will work\r\nvery hard to find and exploit. Way back in 2017, CyberArk published a blog post detailing a new attack technique\r\ncalled Golden SAML. In this blog post, they detailed a technique that allows an adversary to generate their own\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 1 of 7\n\nSAML response with the content and authorizations they deem necessary. Now, there are a few gotchas that the\r\nadversary needs to figure out first. Namely, they need access to the certificates used to sign the SAML objects.\r\nThis generally means they need a foothold into the network and privileged access to extract the certificates.\r\nMultiple tools are available that will help the adversary extract the needed certificates to include certutil.exe,\r\nPowerShell, ADFSDump, and the ever-popular Mimikatz (don’t worry, we detail how to detect this in a bit). All\r\nthe adversary needs to do is run their preferred tool to extract the certificates and they are well on their way to\r\nGolden SAML bliss.\r\nSygnia has another great visual representation of what a Golden SAML attack would look like.\r\n(Image credited to Sygnia)\r\nWhy is this such a big deal? Now that the adversary has access to the extracted certificates, they can impersonate\r\njust about any user and privilege in the organization. Not only that, but they can do it from anywhere in the world.\r\nAdditionally, the adversary will be able to bypass Multi-Factor Authentication (MFA) protections. Why, you ask?\r\nBecause the actual authentication server is being removed from the process entirely. The adversary has forged a\r\nvalid response from the authentication server, completely bypassing MFA.\r\nGolden SAML and the SolarWinds Cyberattack\r\nYou may be wondering what any of this has to do with the SolarWinds attack. Well, the SolarWinds Orion\r\ncompromise resulted in the first recorded use of Golden SAML in the wild. Nearly three years after it was first\r\ndocumented as a viable post-exploitation technique, this was the first time anyone had detected it. That either\r\nspeaks to the effectiveness, flexibility, and stealthiness of this technique, or the determination and tradecraft of this\r\nactor. Probably both.\r\nWhat Data Do I Need?\r\nIn our examples, we will be focusing on a Windows environment that leverages Active Directory Federation\r\nServices (ADFS) for SAML. ADFS security and audit logs will help provide additional insight into potential\r\nGolden SAML attacks. More on that in a bit though. Additionally, some queries may need to be customized to\r\nyour environment, depending on the Splunk TA’s that are installed and configured. One thing to keep in mind, just\r\nbecause our examples are limited to a Windows environment and ADFS, doesn’t mean this attack vector is.\r\nGolden SAML attacks are possible with just about any SAML provider.\r\nBut first, a few caveats. This is not a simple endeavor. Detecting this activity can be extremely difficult and\r\nrequire data from multiple sources across an enclave, both internal and external. We will work towards providing\r\nexamples that can help you detect this type of attack.\r\nNow that we have that out of the way, let’s go over some Windows Events that we’ll need to find this activity.\r\nWindows Event Codes\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 2 of 7\n\nIn order to detect SAML attacks against Microsoft infrastructure, you will need (not surprisingly) Microsoft logs.\r\nNow we are going to post some links/ideas below on how to enable and collect the events you need to detect\r\nGolden SAML excitement. Think of them as “Splunkspiration”. It may not work for you out of the box, but it\r\nshould get you along the right path. Depending on the detection methodology, there are several Windows Events\r\nthat need to be collected for detection to be feasible. Keep in mind that you’ll probably want some adult\r\nsupervision (SysAdmin) around before making any system changes. YMMV and there are some requirements\r\n(like Windows 2016 or later and sysmon installed) to actually be able to get them!\r\nOh, and since this is a Splunk blog, we’ll assume you’re using the Splunk Universal Forwarder to ingest Windows\r\nevents into Splunk.\r\nADFS Event IDs\r\nThese are perhaps the most important Windows Events to collect, and unfortunately, several are not enabled by\r\ndefault. You can find additional information on enabling these events from this blog post and PowerShell Gallery,\r\nand documentation for them here and here.\r\n1200 (AD FS-Admin): The Federation Service validated a new credential\r\n1202 (AD FS-Admin): The Federation Service issued a valid token\r\n307 (AD FS-Admin): The Federation Service configuration was changed\r\n510 (AD FS-Admin): Additional information\r\n1007 (Microsoft-Windows-CertificateServicesClient-Lifecycle-System): Certificate Exported\r\nNow, we don’t by default collect the event logs that these show up in, so we need to add them to a Splunk TA\r\nconfiguration — for example, you could add them to the inputs.conf in the Splunk Add-on for Windows. First, add\r\na stanza to enable the proper Certificate Services log (this one only brings in 1007 — remove the whitelist\r\ndirective if you want the other Certificate Services goodness):\r\n[WinEventLog://CertificateServicesClient-Lifecycle-System/Operational]\r\ndisabled = 0\r\nstart_from = oldest\r\ncurrent_only = 0\r\ncheckpointInterval = 5\r\nrenderXml=true\r\nwhitelist = $XmlRegex=’(?:1007).+’\r\nAnd just in case you thought that was the only tweak, think again. Active Directory Federation Services has its\r\nown log for events. So we need to add another stanza to inputs.conf (on our forwarder):\r\n[WinEventLog://AD FS/Admin]\r\ndisabled = 0\r\nstart_from = oldest\r\ncurrent_only = 0\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 3 of 7\n\ncheckpointInterval = 5\r\nrenderXml=true\r\nBoth of these inputs.conf examples were tested on a Windows 2019 Server.\r\nDomain Controller Event IDs\r\nTo gather the needed events from the Domain Controller(s), we will have to enable them via the Local Security\r\nPolicy snap-in, or via Group Policy. More information on the settings can be found in Microsoft’s documentation.\r\n4769 (Security): A Kerberos service ticket was requested\r\nEndpoint Event IDs\r\nAll of the below Event IDs will help identify command line execution or powershell for certification extraction.\r\nNeed help getting the PowerShell events into Splunk? We’ve got you covered there (the documentation is from\r\nUBA, but don’t worry it works for any logging of PowerShell.)\r\n4688 (Security) (and make sure you enable process arguments.)\r\n4103 (PowerShell) (slide 79ish, here)\r\n4104 (PowerShell) (see above)\r\n18 (Sysmon)\r\nHow Can Golden SAML Be Detected?\r\nI’m glad you asked! We have a few opportunities to detect related activity. Let’s take a look at how we can find\r\nsome in Splunk using the methodology that Sygnia discussed in a recent advisory. Also, keep in mind these are\r\nexample queries to help you along. Detecting this activity in an enterprise can be challenging, so YMMV with the\r\nfollowing queries and they will probably need some massaging to get working correctly in your environment.\r\nNote that they all assume you are using XML-formatted Windows logs (but can be adjusted for Classic format.)\r\n1. Search for certificate exports in ADFS event logs In order for this attack to be successful, the adversary must\r\nexport the appropriate certificates from an ADFS server. This should be fairly rare as there are few reasons to\r\nexport certificates legitimately. We can search for this activity in the Windows Event Logs for the ADFS server for\r\nthe Event ID 1007.\r\nsourcetype=xmlwineventlog\r\nsource=\"xmlwineventlog:CertificateServicesClient-Lifecycle-System/Operational\"\r\nEventCode=\"1007\"\r\nAdditionally, we can search for indications that ADFS certificates were exported from the command-line or\r\nPowerShell. These commands can be executed from anywhere, to include servers or clients. So be sure your\r\nqueries aren’t limited to just the ADFS server.\r\nFirst, let’s look for certificate exports via PowerShell\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 4 of 7\n\nindex=main sourcetype=xmlwineventlog\r\nsource=\"xmlwineventlog:Microsoft-Windows-PowerShell/Operational\"\r\nEventCode IN (4104, 4103) ScriptBlockText IN\r\n(\"*Export-PfxCertificate*\", \"*certutil -exportPFX*\" )\r\nWe can also look for any indication by the use of certutil.exe\r\nindex=main sourcetype=xmlwineventlog\r\nsource=\"xmlwineventlog:Security\" EventCode=4688\r\nCommandLine=\"*certutil.exe -exportPFX*\"\r\nLast, let’s look for the methods used by Mimikatz and ADFSDump. Please note that this pipe is popular, so we\r\nwill want to see which process (images) are not commonly used and dig into them further.\r\nindex=main sourcetype=\"xmlwineventlog:microsoft-windows-sysmon/operational\"\r\nEventCode=18 PipeName=\"\\microsoft##wid\\tsql\\query\"\r\n| stats count by Image\r\n| sort count\r\n2. Identify abnormal authentication events\r\nNote: This technique will only work on Windows Server 2016 or greater. Event IDs 1200 and 1202 did not exist\r\nin prior versions of Windows.\r\nValid SAML authentication events will generate multiple security events on the ADFS and DC servers, as well as\r\nthe service we are authenticating to. We will look for all three of the following Event IDs on our ADFS and DC in\r\nthe Windows Security Events logs.\r\n1200 - The Federation Service issued a valid token\r\n1202 - The Federation Service validated a new credential\r\n4769 - A Kerberos service ticket was requested\r\nWe will then look to correlate these events with authentication events from the service the user attempted to\r\nauthenticate to (the service provider). In this use case, we will check for authentication attempts to Azure AD\r\nSign-in logs.\r\nGolden SAML attacks will lack ADFS (and most likely DC) authentication logs, since the adversary is\r\nconveniently forging the SAML response, effectively removing them from the authentication process. We should\r\nhowever still see a “successful” authentication from the service provider since they did receive a signed SAML\r\nresponse, even though it was forged by the adversary.\r\nsourcetype=xmlwineventlog source=\"xmlwineventlog:Security\"\r\nEventCode IN (1200, 1202, 4769)\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 5 of 7\n\n`comment(\"Look for these three event codes in Windows Security Event Logs\")`\r\n [ search sourcetype=ms:aad:signin status.errorCode=0\r\n | eval Account_Name=mvindex(split(userPrincipalName,\"@\"),0)\r\n`comment(\"Drop the @domain part from the userPrincipalName\")`\r\n | fields Account_Name ]\r\n`comment(\"Build a list of account names from log in attempts through Azure AD to correlate against Windows Secur\r\n| eval Account_Name=mvindex(Account_Name,-1)\r\n`comment(\"Only use the last Account_Name value from the Windows Event Log, which should filter out situations wh\r\n| eval Account_Name=mvindex(split(Account_Name,\"@\"),0)\r\n`comment(\"Drop the @domain part from the Account_Name\")`\r\n| transaction dest Account_Name maxspan=2s maxevents=3\r\n`comment(\"Create a single event with the same dest and Account_Name that occur within 2 seconds and limited to t\r\n| eval mcount=mvcount(EventCode)\r\n`comment(\"Count the number of unique event codes for each account name\")`\r\n| where mcount\u003c3\r\n`comment(\"Look for events where there is an absence of all three event codes\")`\r\n| table _time Account_Name EventCode\r\n3. Monitor for ADFS Trust Modifications Rather than extract the required certificates from a trusted ADFS\r\nserver, the adversary may prefer to add a new trusted ADFS server that they control. We will look for Event ID\r\n307 (The Federation Service configuration was changed) and correlate with Event ID 510 with the same instance\r\nid. Configuration changes for federations don’t frequently occur in many organizations so use this as a starting\r\npoint and adjust as you see fit.\r\nsourcetype=xmlwineventlog source=\"xmlwineventlog:AD FS/Admin\"\r\nEventCode IN (307, 510)\r\nMitigation Recommendations\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 6 of 7\n\nAs with any technology, following best practice guides and recommendations are always the best path forward. If\r\nyou are using Active Directory Federated Services (ADFS), Microsoft provides an excellent resource for securing\r\nit. Considering how critical ADFS is to many organizations, implementing as many security measures as possible\r\nis always highly recommended, perhaps none more so than leveraging a Hardware Security Module (HSM) for\r\ngenerating and storing certificates. HSM has the added benefit of securely storing your keys, as well as all\r\ncryptographic functions, on a physical device. Why is this so important? It negates the ability for an adversary to\r\nextract that ever-important private key, effectively mitigating (or at least raising the bar and cost of) the\r\nadversary’s ability to conduct a Golden SAML attack.\r\nConclusion\r\nToday we went over what SAML is, how a Golden SAML attack works, and some example detection\r\nmethodologies as well as pertinent data sources. We also briefly went over high-level recommendations to help\r\nmitigate this type of attack in the future. All of this content is meant to help you forge a path forward and improve\r\nyour overall security posture. This won’t be the last time we see an adversary leveraging Golden SAML to ensure\r\npersistence in a victims network. If anything, the prominence of this attack has almost certainly highlighted the\r\neffectiveness of this technique which may result in more adversaries bringing it into their toolbox.\r\nFor more information on this and other content related to Solarwinds, check out our SolarWinds\r\nCyberattack response site.\r\nI’d also like to make a special mention and thank John Stoner, Lily Lee, James Brodsky, and Ryan Kovar here at\r\nSplunk. They were instrumental in pulling this blog post together, creating the queries, and ensuring logic\r\nprevailed.\r\nSource: https://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nhttps://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html"
	],
	"report_names": [
		"a-golden-saml-journey-solarwinds-continued.html"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434908,
	"ts_updated_at": 1775791469,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8baebe280bd48bf3856d94273de69ac8be3aa24a.pdf",
		"text": "https://archive.orkl.eu/8baebe280bd48bf3856d94273de69ac8be3aa24a.txt",
		"img": "https://archive.orkl.eu/8baebe280bd48bf3856d94273de69ac8be3aa24a.jpg"
	}
}