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.

Microsoft Log Retention Overview

Microsoft Log Retention Overview

For most Microsoft products, data retention is 30 days. However, it depends on some products if you use the free or paid version of the product, and some products do not allow you to change to the retention period at all. To get a clear overview, I created a table with the most common Microsoft products with their retention period.

Microsoft Log Retention

ProductReportMinimumMaximumDefault
Microsoft Azure AD FreeAudit Logs7 days7 days7 days
Microsoft Azure AD FreeSign-in Logs7 days7 days7 days
Microsoft Azure AD FreeAzure MFA Usage30 days30 days30 days
Microsoft Azure AD FreeUsers at risk7 days7 days7 days
Microsoft Azure AD FreeRisky sign-ins7 days7 days7 days
Microsoft Azure AD PremiumAudit Logs30 days30 days30 days
Microsoft Azure AD PremiumSign-in Logs30 days30 days30 days
Microsoft Azure AD PremiumAzure MFA Usage30 days30 days30 days
Microsoft Azure AD Premium P1Users at risk30 days30 days30 days
Microsoft Azure AD Premium P1Risky sign-ins30 days30 days30 days
Microsoft Azure AD Premium P2Users at risk90 days90 days90 days
Microsoft Azure AD Premium P2Risky sign-ins90 days90 days90 days
Microsoft Defender for EndpointData Retention30 days180 days180 days
Microsoft Cloud App SecurityActivity Logs180 days180 days180 days
Microsoft Cloud App SecurityDiscovery Data90 days90 days90 days
Microsoft Cloud App SecurityAlerts180 days180 days180 days
Microsoft Cloud App SecurityGovernance Logs120 days120 days120 days
Microsoft Defender for IdentityAudit Logs90 days90 days90 days
Microsoft Defender for Office 365 P1Real-time Detections30 days30 days30 days
Microsoft Defender for Office 365 P2Threat Explorer30 days30 days30 days
Microsoft Azure Log Analytics FreeData Retention30 days30 days30 days
Microsoft Azure Log Analytics PaidData Retention30 days730 days30 days
Microsoft Office 365Basic Audit Logs90 days90 days90 days
Microsoft Office 365Advanced Audit Logs365 days365 days365 days
Microsoft Office 365Message Trace90 days90 days90 days
Table 1: Microsoft Log Retention Overview

Conclusion

Not all products allow you to change the retention period, and some products come with an additional cost when changing the retention period. However, this is not always the case. When a Log Analytics Workspace is attached to Sentinel, data retention if free for 90 days.

Suppose you want to extend the retention period longer than the maximum period. In that case, you need to send the logs to a Security Information and Event Management (SIEM) solution or send it to an Azure Log Analytics workspace if the product supports it.

Microsoft Azure AD Premium

Microsoft Azure AD Premium

Every Microsoft 365 tenant contains an Azure AD free edition. The free version includes Core Identity and Access Management, and Business to Business Collaboration. Even though the free edition comes with many features like Multi-Factor Authentication (MFA), Password Protection, Azure AD Connect sync, and Single Sign-On (SSO), Microsoft offers two additional plans called Azure AD Premium P1 and P2.

This article will explain the differences between the two and take a more in-depth look into Azure AD Premium.

Azure AD Premium Features

The difference between Azure AD Premium P1 and P2 is Identity Protection and Identity Governance. But before we look at the features of Identity Protection and Identity Governance, let’s take a look at the premium features first.

The free version contains Password Protection, but it is not possible to use custom banned passwords. Custom banned passwords is one of the premium features. You can set a list of passwords that users cannot use as their password. Simple passwords like “Company Name” is not allowed. Password Protection for Windows Server Active Directory does the same as Password Protection, but for on-premises.

Self-service password reset eliminates the users to call the ServiceDesk to change their password. The user can change their password on a portal that does not need any support from the company. Azure AD Join makes it possible to auto-enroll your mobile device.

A noticeable feature in Azure AD Premium is Conditional Access. Conditional Access, as the name implies, grants, or block access to certain conditions. You can force MFA, block specific applications, block legacy authentication, etc.

Figure 1: Conditional Access Policies

Identity Protection and Identity Governance

An Azure AD Premium P2 feature not included in Azure AD Premium P1 is Identity Protection and Identity Governance. Identity Protection is a feature that detects risky accounts based on many indicators (atypical travel, malware linked IP address, and many more). Conditional Access uses these detections to allow or block an identity. Using Identity Protection makes it possible to mitigate an attack within seconds due to an automated response to a risky user.

Figure 2: Risky Users

Identity Governance contains Privileged Identity Management (PIM), Access Reviews, and Entitlement Management. PIM makes it possible to control, manage, and monitor access to essential resources in your organization. PIM provides Just-In-Time (JIT) access to Azure AD and Azure resources, assign time-bound access, asks for approval, and much more. Identity Governance also includes Access Review to review access regularly to make sure only the right people have continued access.

Conditional Access, Identity Protection, and Privileged Identity Management help organizations control their identities and definitely worth checking.

Licensing

Azure AD Premium comes with Microsoft 365 E3, Microsoft 365 E5, or a separate license.

Figure 3: Licensing

Conclusion

With features like conditional access, Azure AD premium is a must.