If you can't tell, I'm a huge fan of knowing exactly what is going on with authentication since most attacks you see today, lead to post-compromise activity thanks to the weaknesses in this layer.
What do I mean? Well, if you read my blog on why SmartCards aren't doing anything about Pass-the-Hash/Pass-the-Ticket, you know that the endpoint is still given an NTLM hash and Kerberos ticket after authentication. Okay, so what? Well, that means if the adversary finds themselves on such an endpoint, such as a Dept of Defense laptop, they can harvest those credentials and laterally move as that Identity.
Yea, but SmartCard is required for authentication right? WRONG. SmartCard is enforced by the endpoint, for starters. But more importantly, not all authentication methods support SmartCard, hence Microsoft called it "SCRIL", or SmartCard Required Interactive Logon. The sad truth is, majority of your logons on the network are not interactive logons!
Do read more on the linked blog, but his is an example. Microsoft did everything in its power to try and secure your credentials on the endpoint, with things like Credential Guard, but the day those features are released, usually there is already code in the wild that bypasses those defenses anyways (like Mimikatz...).
Okay, so with that example done, lets look at "Modern Authentication". Microsoft told everyone MFA everything! MFA will save your life. Use only Microsoft's MFA, so we can have another monopoly on Active Directory in the cloud as we did with Active Directory on-premises--since we did such a good job with that!
Well, truth be told, people reported to Microsoft Security Response Center (MSRC) on how bad the implementation was. See, 99.9999% of organizations still have on-premises AD, which means they need to establish trust on-premises to the cloud somehow. Microsoft made a decision to do this via SAML, which you can read a lot more on here. This blog shows why that was a horrific decision.
And no Microsoft, I'm not saying SAML itself is bad. I'm saying you using it in this way, knowing it can be used to bypass MFA, the silver bullet you've preached till Sunburst/SolarWinds, was absurd. For a company to say it spends $1B/year (now $2B/year) in "cybersecurity", you've done an awful job in your own SDL practices. And for the love of god, stop asking customers to install Winpcap, a not-supported open-source project with tons of vulnerabilities, on their Active Directory!!! We all make mistakes, but its what we do with those lessons--actively ignoring MSRC input of you have a major issue isn't a good move. You can't wait for a national security crisis every time before you actually do something about it.
There are many other examples of this, including Microsoft stating "this attack was extremely hard to pull off, it even includes exporting non-exportable keys". What they are referring to here is ADFS holds non-exportable keys, which are the keys used to establish that trust relationship. Sadly, FireEye wrote software and open-sourced it that makes this easy. In addition, Mimikatz always could export "non-exportable" keys.
Microsoft also said only the ADFS process owner could export these keys. This was true! Sadly, its very easy to become anyone, including the ADFS process owner, when you already compromised ADFS (and therefor the Domain/Forest).
In this video I show you exactly what this all looks like and how easy this (sadly) was. Audio is coming soon. This video was also what CrowdStrike shared at RSA 2021 and what I'm happy to be able to show the world:
Microsoft has since then really worked on fixing this issue, including using a new protocol to establish that trust between on-premises and Azure which doesn't actually lead to bypassing MFA.
In addition, many great Zero Trust use-cases now take into account the trust of the device, trust of the Identity (including Service Accounts, sorry Microsoft since you still weirdly ignore service accounts, the most targeted accounts in an Kerberos realm...). In fact, in a strong Zero Trust architecture, you can even "hide" your authentication plane until certain checks are passed, drastically lowering your exposure against brute-force attacks against cloud-Identity Providers (i.e. Okta, Azure AD, etc.).