A primer on SAML, Golden SAML, Sunburst

How the adversary steamrolled customers on-premises, and their cloud, bypassing MFA, and the facts on how we got here and why Microsoft was an enabler of the whole thing

A primer on SAML, Golden SAML, Sunburst

Sunburst showed how easy an adversary could carry out their mission, from gaining a foothold on-premises, to then laterally moving, compromising the entire Active Directory Forest. But it didn't stop there. With a hop, skip and a jump, with literally no speed-bump in between, the adversary was able to jump to Active Directory Federation Service (ADFS) and from there, exert control of Cloud Service Providers (i.e. Azure) and other applications (i.e. Office 365).

This was eye opening and something I've talked to at length with customers well before even Sunburst was a thing--the risk of asymmetric encryption has always been how secure the private key is. There certainly is nothing new here. The trust relationship between on-premises and the cloud is too often not-understood. In addition, the heavily reliance on "MFA", just like SmartCards, has too often been used as a silver bullet to check the box of "protect Identity".

However, unfortunately based on corporate decisions, Microsoft decided to not support things like SmartCard/Comman Access Card natively in Azure. This meant customers had to use Active Directory Federation Service (AD FS) so they could use the very expensive Public Key Infrastructure (PKI) they stood up to help secure on-premises authentication (for more on this, see this, and what you can do to actually fix the problem here). This meant, for the critical Public Sector customers, they needed to expose this private key on-premises, to their existing Active Directory environment. This meant the security of their cloud and anything else with a trust against Azure AD (i.e. O365, Microsoft Defender and Security Center, Azure, ...) was only as secure as their ADFS server. ADFS can only be as secure as Active Directory. Active Directory can only be as secure as the exposure of Domain Admin and equivalent credentials on other systems (i.e. Admin Workstations).  See the issue here?

Why? This is purely a guess: Most likely Microsoft didn't want to allow extend Azure authentication to existing PKI natively. They rather have customers throw that PKI-garbage all away, move to Azure AD and their MFA solution. Microsoft could do this by getting its cash cow, Office 365, behind Azure AD; let's not even explore how Microsoft then extend O365 logs into Azure Sentinel, Microsoft's SIEM, to force its O365 customers to use Azure Sentinel (and be charged transactional costs if they want to do anything with that data).

Now in Microsoft's defense, AD FS existed a while ago, way before Cloud becoming a big thing. It was used to build federations across boundaries. However, it was also used as a crutch, to provide a "good" solution yet clearly pointed towards "pure Azure" as the "better" and "best" solution. Why? Again, see my hypothesis above, but ultimately, Microsoft knows how important the Identity-plane is. It knows how important it is to own that part of the market--heck it owns 99.9% of on-premises Identity with Active Directory. Having a monopology there put it in control of many things, specifically developers, integrations. Now with Azure, owning Azure AD means having the Identity-plane for cloud, that can span across other clouds. It puts Azure in a strategic advantage the larger its market share gets.

Does AD make Microsoft money? Is Azure AD a cash cow for Microsoft? Absolutely not. But its the residual benefits these products and platforms bring to the Microsoft ecosystem that enable it to be the juggernaut it is.

This story gets better, so read on.

A note on "Hybrid" vs "Pure Cloud"

As briefly discussed above, you as a customer are only as secure as your trust relationships--which ultimately start on-premises (i.e. ADFS, Domain Admin creds, etc). The number of companies who told me, "we moved all in on the cloud", but forgot they still have on-premises Domain Controllers (or on-premises endpoints) is quite high. Those customers had to be reminded: "you're actually running in a hybrid mode, where your Identities exist in two places, on-premises and the cloud". Furthermore, those who are truly "all-in on the cloud" (no on-premises Domain Controllers; easily less-than 1% of customers) still have trusth relationships with on-premises! They have computers where their Global Admin, Super Admin (Okta) are exposed to. They have some device they still need to protect so it can also protect their legitimate credentials. And notice I said credentials, not Identity. Credentials are what a system gives you after properly autenticating--via MFA, biometric, whatever. It's those credentials which can be harvested by the bad guy and re-used maliciously.

Before you move forward, you should also be aware of these resources which double down on the above, and really show you exactly what this means. If your like me, you'll need to sit down and watch this a few times over a few days, since for most, this somewhat myth-busts what we've been told or taught. Microsoft saying your "more secure in the cloud" is, well... needless to say, Sunburst happened.

So, here are great resources I've pushed out on this topic:

In the next post I'll be releasing a video that I worked on for RSA for Hacking Exposed, illustrating just how easy it was to do what Microsoft previously said was "nearly impossible". In fact, Microsoft said this affected less than 10% of customers impacted by Sunburst, yet FireEye immediately stated this was the majority of what they saw for Sunburst customers.

What is more friegtening is that Microsoft didn't even have the proper logging for some of these Indicators-of-Compromise (IOCs), specifically for non-interactive logons (i.e. non-Human, Applications) since April 2021, months after briefing Congress that had customers (paraphrasing) paid us more money for security services, this wouldn't of happened. I state this since one of the IOCs was the adversary creating backdoors in Azure, as Applications or backdooring existing Applications (i.e. creating another certificate used to sign-in as that Application). That Application would have the entitlements (permissions) to do anything it wanted in Azure. Unfortunately, up until April 2021, Azure AD wasn't even logging these sign-ins! That said, NSA and other entities stated the best way to detect this was correlating sign-in logs between ADFS and Azure AD--well, um... Azure AD wasn't even auditing the right events.

So, stay tuned for when I release the Hacking Exposed video as we walk you step-by-step the Golden SAML hack using the tools (based on OSINT) of the adversary, to pull of this attack, compromise O365, Azure, M365 (including Security Center).

This isn't an "anti-MSFT" thing--however there are things that MSFT has done, deliberatly or non-deliberatly, that exerabated this issue. For example, they chose not to log non-interactive or SPN logons in Azure AD, meaning you are blind as a customer if someone is maliciously logging on (i.e. a registered Application)

Happy hunting,