{ "id": "8fac9639-a14a-44fa-abc0-34f1ed64c8ee", "created_at": "2026-04-06T00:21:21.821085Z", "updated_at": "2026-04-10T03:37:32.819926Z", "deleted_at": null, "sha1_hash": "c2f4cc629caf0eadddfc03a8da957af40221511c", "title": "Golden SAML Revisited: The Solorigate Connection", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 253533, "plain_text": "Golden SAML Revisited: The Solorigate Connection\r\nBy Shaked Reiner\r\nPublished: 2020-12-29 · Archived: 2026-04-05 18:56:25 UTC\r\nIn the past few weeks, we’ve been witnessing one of the most elaborate supply-chain attacks unfold with a threat actor that\r\ninfected SolarWinds Orion source code and used the update process to get to around 18,000 victims all around the globe.\r\nOne of the most (if not the most) innovative techniques used in this attack, now known as Solorigate, is the “Golden SAML”\r\ntechnique. The threat actor (UNC2452) did a phenomenal job across all stages of the attack — from meticulously planting\r\nthe backdoor code and making it look like yet another legitimate class, to avoiding almost every possible forensics/analysis\r\ntool you can name, and even hiding data in DNS queries and making all the traffic look as if it’s part of the SolarWinds\r\nOrion communication protocol. There’s no doubt the threat actor knew what they were doing and tried to do everything in\r\nthe best way possible. Still, we believe that performing a Golden SAML attack is the most innovative part of the attack (as\r\nof writing this post), having it be the first-ever documentation of such an attack. We (CyberArk Labs) did describe this\r\nattack vector at the end of 2017, but this is the first time we’ve seen it used in the wild. Golden SAML is an attack vector\r\nthat can serve sophisticated attackers in their post-exploitation stages allowing them to maintain persistency and gain access\r\nto different services in a convenient and stealthy manner.\r\nIn this blog post, we’ll first have a quick refresh on the basics of Golden SAML. Then we’ll try to illustrate why it can be so\r\npowerful in the hands of attackers and how it fits the UNC2452 threat actor’s perceived modus operandi like a glove.\r\nFinally, we’ll share a few mitigation tactics that can be used by defenders to mitigate this risk.\r\nGolden SAML Recap\r\nGolden SAML is a technique that allows attackers, once they got privileged access to the victim’s network, to impersonate\r\nalmost any identity in the organization and acquire any type of privilege across almost all services of the organization (this\r\ndepends on what services in the organization use SAML as their authentication protocol). You may already be familiar with\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection\r\nPage 1 of 4\n\na similar technique called – Golden Ticket. Golden SAML introduces to a federation environment the same advantages that\r\ngolden ticket offers in a Kerberos environment. It simply applies the same principle in a different environment. If you would\r\nlike to get into the details of this attack vector, you can find the full details on our blog.\r\nWhy Do Attackers Want to Use Golden SAML?\r\nIn this section we’ll list a few of the powerful advantages this attack vector can offer for attackers.\r\nFlexibility – Golden SAML provides a lot of flexibility for attackers, in the sense that they can impersonate any identity\r\nthey wish in the federation. It is beneficial for two main reasons:\r\n1. Attackers capable of performing a Golden SAML attack can basically get access to every service or asset in the\r\norganization (as long as it’s a part of the federation of course). This means that they are not limited to the\r\ncredentials/access they were lucky enough to stumble upon – they can practically gain access to anything they want.\r\n2. Being able to do that gives attackers more than just access. In the majority of the cases, sophisticated attackers go to\r\ngreat lengths in trying to hide their activity and avoid detection. Imagine you’re an attacker and that you have gained\r\nthe ability to perform a Golden SAML attack in your target’s network, which is monitored heavily. Whatever action\r\nyou choose to perform next, you can do that using the identity of a user that is “known” to take this action from time\r\nto time, thus diminishing the chances of looking like a suspicious action, and ultimately getting detected and ruining\r\nthe whole operation. Simply put, you are blending malicious actions with normal, legitimate activities. The attackers\r\nbehind SolarWinds did just that, we can see it in the code they’ve planted, the communication protocol they used, and\r\nin their usage of legitimate configuration files for the backdoor’s needs. It is very likely that it was this flexibility and\r\nthe ability to blend in which were the factors that “sold” UNC2452 on the idea to use the Golden SAML vector.\r\nMFA (Multi-Factor Authentication) Bypass – The usage of this technique can potentially make the additional security\r\nlayer MFA provides completely useless. Since users get a valid SAML token after they’ve authenticated using MFA,\r\nattackers that are using Golden SAML don’t need to go through that stage at all. The attackers basically skip it altogether\r\nand go straight to forging an identity using the stolen certificate, without having to know the user’s password or to have\r\nother authentication factors. This is a very substantial ability, and it shows that the sense of security MFA provides, might\r\njust be a false one in some cases.\r\nThe ability to bypass MFA depends on the specific implementation of MFA an organization might have. MFA bypass can\r\nonly be applied if the integration is on the identity provider side. If the integration is on the service provider side, then multi\r\nfactor authentication happens only after the SAML token has been generated, thus making Golden SAML ineffective in\r\nbypassing it. Having said that, we need to remember that times organizations often use federated service for the sake of\r\nconvenience in the form of SSO, and this could have the potential of damaging the overall security of the organization, as\r\nwe see in the Golden SAML case.\r\nDifficulty to Detect – Detection of such an attack can be extremely challenging for defenders. Even though there are\r\nmethods that can potentially detect such malicious behavior (which we’ll elaborate on in the next section), many\r\norganizations are not aware of this type of threat and do not monitor SAML authentication (especially not in the pre-Solorigate era).\r\nDifficulty to Remediate – If an attacker steals your password, it’s relatively easy to change this password and take back\r\ncontrol of your identity. But if an attacker steals your SAML token signing certificate, it’s a whole different ballgame. First,\r\nif you’ll naively try to change your passwords, the attacker can easily continue to make SAML tokens that impersonate you,\r\nwithout the need to know the actual password (same case as being able to bypass MFA). So, what you really need to do is to\r\nchange the actual token signing certificate. Which basically means reestablishing the trust across your entire federation.\r\nLong-Term Persistency – Let’s compare this to passwords again. Passwords are being changed every set period of time (a\r\nfew weeks if your organization has proper credential management), but a SAML token signing certificate is almost never\r\nchanged, or. This allows attackers to potentially maintain their access for a long period of time.\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection\r\nPage 2 of 4\n\nGolden SAML Detection and Mitigation\r\nFollow best practices of your federation Identity Provider (IdP) technology. Here are, for example, the AD FS\r\n(Active Directory Federation Services by Microsoft) best practices. Some IdP support protecting your token signing\r\ncertificate in a hardware security module (HSM). This should make stealing your token signing certificate a much\r\nharder task for attackers.\r\nDo as much as you can to protect your tier-0 assets (a federation identity provider should be included here). This\r\nincludes having proper credential hygiene, deploying a privileged access management solution, an EDR, etc. This\r\nwill make it very difficult for attackers to gain sufficient privileges for stealing a token signing certificate in the first\r\nplace.\r\nExamine SAML tokens to identify suspicious ones (such as tokens with an unusually long lifetime or with unusual\r\nclaims).\r\nCorrelate logs between your Identity Provider and your Service Provider. If you see a SAML authentication in your\r\nService Provider that doesn’t correlate to a SAML token issuance by the Identity Provider – something is wrong.\r\nUse third-party security solutions to protect the token signing certificate from being stolen by attackers. CyberArk\r\nEndpoint Privilege Manager (EPM) has the ability to do just that.\r\nFor more information on detection and mitigation please see this document by the NSA and this advisory by Sygnia.\r\nConclusion\r\nAt the time of writing this post, we’re still learning new things on Solorigate with every day that passes. This attack has been\r\nan important lesson for everyone in the information security field, whether you were impacted directly or not.\r\nAs for Golden SAML, we do expect to see this tactic become more commonly used for two reasons:\r\nWith more and more services being ported to the cloud, there is a greater need to establish some level of trust\r\nbetween them and between on-premise services – and SAML has become the de facto authentication and\r\nauthorization standard. Attackers operating in those types of environments will have to adapt their methods to\r\nfit the new norm. For instance, instead of settling on getting the domain’s KRBTGT and forging any identity\r\nwithin that domain, attackers can now steal the SAML token signing certificate and forge almost any identity\r\nacross the entire organization.\r\nSeeing Golden SAML being used in one of the most sophisticated and elaborate cyber-attacks we have seen in recent\r\nyears (and we are still not aware of the full impact of it), potential future attackers will come to know this tactic and\r\npossibly use it as well in the future.\r\nWe need to find joy in the rare cases in which defenders beat attackers at their own game and anticipate attack vectors before\r\nthey’re being used in the wild by malicious threat actors. This timeframe between the discovery of a new attack vector and\r\nits use by attackers should be utilized by defenders to prepare their network for such an attack as best as they can – setting\r\nup monitoring rules to detect this and deploying protection mechanisms that should block it. Golden SAML is a great\r\nexample of such an opportunity, and we hope that as a security community we can learn from that and do better in the\r\nfuture.\r\nReferences\r\nhttps://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/\r\nhttps://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps\r\nhttps://www.sygnia.co/golden-saml-advisory\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection\r\nPage 3 of 4\n\nSource: https://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection\r\nhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.cyberark.com/resources/threat-research-blog/golden-saml-revisited-the-solorigate-connection" ], "report_names": [ "golden-saml-revisited-the-solorigate-connection" ], "threat_actors": [ { "id": "b43e5ea9-d8c8-4efa-b5bf-f1efb37174ba", "created_at": "2022-10-25T16:07:24.36191Z", "updated_at": "2026-04-10T02:00:04.954902Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "Dark Halo", "Nobelium", "SolarStorm", "StellarParticle", "UNC2452" ], "source_name": "ETDA:UNC2452", "tools": [], "source_id": "ETDA", "reports": null }, { "id": "1d3f9dec-b033-48a5-8b1e-f67a29429e89", "created_at": "2022-10-25T15:50:23.739197Z", "updated_at": "2026-04-10T02:00:05.275809Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "UNC2452", "NOBELIUM", "StellarParticle", "Dark Halo" ], "source_name": "MITRE:UNC2452", "tools": [ "Sibot", "Mimikatz", "Cobalt Strike", "AdFind", "GoldMax" ], "source_id": "MITRE", "reports": null }, { "id": "5b748f86-ac32-4715-be9f-6cf25ae48a4e", "created_at": "2024-06-04T02:03:07.956135Z", "updated_at": "2026-04-10T02:00:03.689959Z", "deleted_at": null, "main_name": "IRON HEMLOCK", "aliases": [ "APT29 ", "ATK7 ", "Blue Kitsune ", "Cozy Bear ", "The Dukes", "UNC2452 ", "YTTRIUM " ], "source_name": "Secureworks:IRON HEMLOCK", "tools": [ "CosmicDuke", "CozyCar", "CozyDuke", "DiefenDuke", "FatDuke", "HAMMERTOSS", "LiteDuke", "MiniDuke", "OnionDuke", "PolyglotDuke", "RegDuke", "RegDuke Loader", "SeaDuke", "Sliver" ], "source_id": "Secureworks", "reports": null }, { "id": "a241a1ca-2bc9-450b-a07b-aae747ee2710", "created_at": "2024-06-19T02:03:08.150052Z", "updated_at": "2026-04-10T02:00:03.737173Z", "deleted_at": null, "main_name": "IRON RITUAL", "aliases": [ "APT29", "Blue Dev 5 ", "BlueBravo ", "Cloaked Ursa ", "CozyLarch ", "Dark Halo ", "Midnight Blizzard ", "NOBELIUM ", "StellarParticle ", "UNC2452 " ], "source_name": "Secureworks:IRON RITUAL", "tools": [ "Brute Ratel C4", "Cobalt Strike", "EnvyScout", "GoldFinder", "GoldMax", "NativeZone", "RAINDROP", "SUNBURST", "Sibot", "TEARDROP", "VaporRage" ], "source_id": "Secureworks", "reports": null }, { "id": "70872c3a-e788-4b55-a7d6-b2df52001ad0", "created_at": "2023-01-06T13:46:39.18401Z", "updated_at": "2026-04-10T02:00:03.239111Z", "deleted_at": null, "main_name": "UNC2452", "aliases": [ "DarkHalo", "StellarParticle", "NOBELIUM", "Solar Phoenix", "Midnight Blizzard" ], "source_name": "MISPGALAXY:UNC2452", "tools": [ "SNOWYAMBER", "HALFRIG", "QUARTERRIG" ], "source_id": "MISPGALAXY", "reports": null }, { "id": "20d3a08a-3b97-4b2f-90b8-92a89089a57a", "created_at": "2022-10-25T15:50:23.548494Z", "updated_at": "2026-04-10T02:00:05.292748Z", "deleted_at": null, "main_name": "APT29", "aliases": [ "APT29", "IRON RITUAL", "IRON HEMLOCK", "NobleBaron", "Dark Halo", "NOBELIUM", "UNC2452", "YTTRIUM", "The Dukes", "Cozy Bear", "CozyDuke", "SolarStorm", "Blue Kitsune", "UNC3524", "Midnight Blizzard" ], "source_name": "MITRE:APT29", "tools": [ "PinchDuke", "ROADTools", "WellMail", "CozyCar", "Mimikatz", "Tasklist", "OnionDuke", "FatDuke", "POSHSPY", "EnvyScout", "SoreFang", "GeminiDuke", "reGeorg", "GoldMax", "FoggyWeb", "SDelete", "PolyglotDuke", "AADInternals", "MiniDuke", "SeaDuke", "Sibot", "RegDuke", "CloudDuke", "GoldFinder", "AdFind", "PsExec", "NativeZone", "Systeminfo", "ipconfig", "Impacket", "Cobalt Strike", "PowerDuke", "QUIETEXIT", "HAMMERTOSS", "BoomBox", "CosmicDuke", "WellMess", "VaporRage", "LiteDuke" ], "source_id": "MITRE", "reports": null }, { "id": "f27790ff-4ee0-40a5-9c84-2b523a9d3270", "created_at": "2022-10-25T16:07:23.341684Z", "updated_at": "2026-04-10T02:00:04.549917Z", "deleted_at": null, "main_name": "APT 29", "aliases": [ "APT 29", "ATK 7", "Blue Dev 5", "BlueBravo", "Cloaked Ursa", "CloudLook", "Cozy Bear", "Dark Halo", "Earth Koshchei", "G0016", "Grizzly Steppe", "Group 100", "ITG11", "Iron Hemlock", "Iron Ritual", "Midnight Blizzard", "Minidionis", "Nobelium", "NobleBaron", "Operation Ghost", "Operation Office monkeys", "Operation StellarParticle", "SilverFish", "Solar Phoenix", "SolarStorm", "StellarParticle", "TEMP.Monkeys", "The Dukes", "UNC2452", "UNC3524", "Yttrium" ], "source_name": "ETDA:APT 29", "tools": [ "7-Zip", "ATI-Agent", "AdFind", "Agentemis", "AtNow", "BEATDROP", "BotgenStudios", "CEELOADER", "Cloud Duke", "CloudDuke", "CloudLook", "Cobalt Strike", "CobaltStrike", "CosmicDuke", "Cozer", "CozyBear", "CozyCar", "CozyDuke", "Danfuan", "EnvyScout", "EuroAPT", "FatDuke", "FoggyWeb", "GeminiDuke", "Geppei", "GoldFinder", "GoldMax", "GraphDrop", "GraphicalNeutrino", "GraphicalProton", "HAMMERTOSS", "HammerDuke", "LOLBAS", "LOLBins", "LiteDuke", "Living off the Land", "MagicWeb", "Mimikatz", "MiniDionis", "MiniDuke", "NemesisGemina", "NetDuke", "OnionDuke", "POSHSPY", "PinchDuke", "PolyglotDuke", "PowerDuke", "QUIETEXIT", "ROOTSAW", "RegDuke", "Rubeus", "SNOWYAMBER", "SPICYBEAT", "SUNSHUTTLE", "SeaDaddy", "SeaDask", "SeaDesk", "SeaDuke", "Sharp-SMBExec", "SharpView", "Sibot", "Solorigate", "SoreFang", "TinyBaron", "WINELOADER", "WellMail", "WellMess", "cobeacon", "elf.wellmess", "reGeorg", "tDiscoverer" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434881, "ts_updated_at": 1775792252, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/c2f4cc629caf0eadddfc03a8da957af40221511c.pdf", "text": "https://archive.orkl.eu/c2f4cc629caf0eadddfc03a8da957af40221511c.txt", "img": "https://archive.orkl.eu/c2f4cc629caf0eadddfc03a8da957af40221511c.jpg" } }