This blog post will demonstrate how an attacker can hop from on-premises Active Directory to Azure Active Directory or Microsoft 365 when Seamless Single Sign-On is enabled.
Seamless Single Sign-On
Azure Active Directory supports multiple authentication methods, including Seamless Single Sign-On. Seamless Single Sign-On automatically signs-in users when they are on their corporate devices connected to their corporate network. Users do not type in their username and password to sign in to their cloud-based applications. This feature provides users easy access to cloud-based applications without needing any additional on-premises components. Seamless Single Sign-On can be combined with either the Password Hash Synchronization or Pass-through Authentication sign-in methods.
Note: Seamless Single Sign-On does not apply to Active Directory Federation Services (ADFS).
When enabling Seamless Single Sign-On, Azure AD Connect creates a computer object (AZUREADSSOACC) within the on-premises Active Directory. The computer object holds multiple Service Principal Names.
Service Principal Name
The Service Principal Name ‘HTTP/autologon.microsoftazuread-sso.com’ holds a “secret” used to decrypt a Kerberos ticket when authenticating to Azure AD. If the client can present a valid Ticket Granting Service ticket, Azure AD assumes the client is on the corporate on-premises network and authenticates the user using Kerberos.
In my previous blog post about Kerberoasting, you can read that anyone with a valid Ticket Granting Ticket (any authenticated domain user) can request a Ticket Granting Service ticket. An attacker only needs to get a valid Ticket Granting Ticket and request the correct Ticket Granting Service ticket to log in to Azure AD or Microsoft 365 as that user.
Request the Ticket Granting Service ticket
I have added an option to request the Ticket Granting Service ticket using my Kerberos tool.
Extract the Ticket Granting Ticket of the user, including the HTTP Ticket Granting Service ticket, from memory and copy it to an attacker’s machine.
Access cloud applications
For Seamless Single Sign-On to work, you need to add a local policy to the attacker’s machine first.
Import the Ticket Granting Ticket and Ticket Granting Service ticket using a tool like Mimikatz and browse to https://myapps.microsoft.com to access the user’s cloud applications. You can now go to the Azure or Microsoft 365 portal to log in as the user.
Conclusion
When an attacker gets hold of a Ticket Granting Ticket, the attacker can hop to cloud-based applications, including Azure and Microsoft 365. Other attack vectors make it possible for an attacker to jump from on-premises to the cloud, but they need admin privileges. With this attack, the attacker only needs to hold a valid Ticket Granting Ticket to jump to the cloud.
Microsoft Defender for Identity does not detect the Ticket Granting Service ticket request as it is an expecting request. Authenticating using Kerberos could bypass Conditional Access policies if not configured correctly.
There are other attack possibilities since the authentication creates an OAuth2 token for that user after authenticating, but more on that later.
