Microsoft on-premises to the cloud using Seamless Single Sign-On

Microsoft on-premises to the cloud using Seamless Single Sign-On

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.

Image 1: Service Principal Names for the computer object AZUREADSSOACC

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.

Image 2: Requesting a TGS using Kerberos

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.

Image 3: Local Computer Policy / User Configuration / Administrative Templates / Windows Components / Internet Explorer / Internet Control Panel / Security Page / Site to Zone Assignment List

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.

Image 4: Login using Kerberos TGT and TGS on Azure / Microsoft 365 and MyApps

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.