Organizations have been increasingly relying on cloud services from Azure since Microsoft provides native support. As a result, CSW pentesters have been researching various attack vectors related to Azure. Our pentesters noted that after obtaining administrative privileges on the on-premise network in an engagement, it is essential to always think of attack paths or scenarios to escalate privileges or describe the maximum impact. One such thing is escalating privileges to Azure Active Directory (AD).
A domain administrator is a user account that can edit, create new users, delete existing users and change permissions in the Active Directory. A domain admin can modify the configurations of the Active Directory servers and therefore, any content stored on them.
On-premise administrators might access crucial information, such as Azure Active Directory (AAD) Connect, Active Directory Federation Services (ADFS), and Active Directory Azure Active Directory Single Sign-on (SSO). Users with admin rights for these services can easily get admin rights to Azure AD to manipulate and impersonate users.
In this blog, we will discuss two attack scenarios that CSW pentesters have commonly encountered during their engagements. Both the scenarios leverage misconfigurations to escalate privileges from on-premise to Azure services:
-
Azure AD Connect
-
Azure Active Directory Single Sign-on
Azure AD Connect
Azure AD Connect is the Microsoft tool designed to meet and accomplish hybrid identity goals. It provides the following features:
When AAD is configured, it creates service accounts on Azure AD and on-premises AD environments. These service accounts and their passwords are stored in the database present in the AAD Connect machine or the machine where the Active Directory sync service is running.
The service account created in Azure AD is named as follows:
Sync_<server>_<random string>@<tenant name>.onmicrosoft.com (Azure AD)
MSOL_<random string>@<domain name> (Local AD)
Usually, after dumping the Windows NT Directory Services (NTDS) file from the domain controller present in the network, our pentesters cracked the extracted hashes. Some of the passwords that were obtained could be replayed to access Azure or Office 365 Applications. Although these accounts did not have enough permissions, our pentesters could use them for the initial set of enumerations.
Fig 1: Connecting to the Azure Portal via the AzureAD Module
Connecting to Azure Cloud via command-line interface
CSW pentesters run AzureHound, a PowerShell utility, for gathering data within Azure and Azure AD. Our pentesters were also able to identify the possible target accounts or machines that could be used during privilege escalation.
-
Global administrators
-
The machine where ADSync Service is running
Pentesters use the AADInternals tool, which is considered the arsenal of PowerShell cmdlets used to enumerate and attack Azure and other Office 365 applications.
-
Get-AADIntGlobalAdmins—Listing global administrators of the current tenant
Fig 2: List of Global Administrators
-
Get-AADIntSyncConfiguration—Returns Azure synchronization details
Fig 3: Azure Synchronization Details
Upon accessing the on-premise machine (DirSyncClientMachine) with domain admin privileges, there is a maximum probability of obtaining cleartext credentials of the service account. We can use Get-AADIntSyncCredential from AADInternals to dump the cleartext passwords of both the service accounts.
Fig 4: Passwords for both service accounts retrieved through Get-AADIntSyncCredentials
Alternatively, pentesters can also retrieve cleartext credentials from LSA Secrets.
LSA Secrets
LSA stands for Local Security Authority, used to manage the auditing, logging users onto the system, security policies, and storing credential materials such as service account passwords. Adversaries with SYSTEM access to a host may attempt to access LSA secrets. LSA secrets are stored in the registry here:
HKEY_LOCAL_MACHINE\\SECURITY\\Policy\\Secrets.
A pentester can also dump the credential materials present in the credential manager and Local Security Authority Subsystem Service to identify the cleartext password of the service account.
Fig 5: Plaintext passwords for service accounts (azureadsync and oktasync) retrieved using crackmapexec via dumping LSA Secrets
Fig 6: Global Administrator Privileges
Azure Active Directory Single Sign-on
Azure Active Directory Seamless Single Sign-on (Azure AD Seamless SSO) automatically signs users in when they are on their corporate devices connected to the corporate network. When enabled, users do not need to type in their passwords to sign in to Azure AD or even type in their usernames.
A machine account (AZUREADSSOACC) is created in the on-premise domain controller in each Active Directory forest that is synchronized with Azure AD.
A computer account (AZUREADSSOACC) is created in the on-premise Active Directory in each AD forest that you synchronize to Azure AD (using Azure AD Connect).
How did CSW pentesters discover this issue?
In one of their real-world engagements, in spite of possessing the plaintext password of a global administrator, CSW pentesters were unable to access the Azure AD Portal as the multifactor authentication (MFA) was enabled for all the global administrators.
Fig 7: MFA Is Enabled for Global Administrators
Upon further deep-dive enumeration, our team of pentesters found that a user who is part of the internal IT Team but not a global administrator, had certain special permissions over Azure Resources. This user explicitly had AzResetPassword privileges over all the users while having the MFA disabled.
Fig 8: A user (part of the IT Team) who has AzResetPassword privileges over 146 accounts visualized via BloodHound
This user also had privileges to modify the MFA settings. If our pentesters were to impersonate that user, they would be able to modify the MFA settings and attain global administrator privileges. But CSW pentesters did not have the cleartext password of the user.
This is when our team found that the organization used Azure Active Directory single sign-on, with which they would be able to impersonate any user without their passwords (while keeping MFA disabled) via forging Kerberos tickets.
How does this work?
-
A user tries to access an Azure application (browser-based) from a domain-joined device present in the corporate network.
-
If the user has not signed in, the user is redirected to the sign-in page of Azure AD, where the user types the username.
-
Using JavaScript in the background, Azure AD returns a 401 response asking the browser to provide a Kerberos ticket, which is technically termed a Kerberos challenge.
-
The browser, in turn, requests a ticket from Active Directory for the AZUREADSSOACC$ computer account (which represents Azure AD).
-
Active Directory locates the computer account and returns a Kerberos ticket to the browser encrypted with the computer account’s secret (NTLM Hash).
-
The browser forwards the obtained Kerberos ticket to Azure AD, which decrypts it and identifies details such as the identity of the user, user privileges, etc.
-
After the evaluation, Azure AD returns a token (JWT) with which the user can access the Azure Resources.
Suppose a pentester has the privileges of a Domain Admin or access to edit properties of the AZUREADSSOACC$ account, in that case, they can impersonate any user in Azure AD using Kerberos (if MFA is not enabled).
Note: The password of the AZUREADSSOACC$ account never changes unless it is manually modified.
Pwning it
-
Dumping the NTLM hash of AZUREADSSOACCS$
lsadump::dcsync /user:AZUREADSSOACC$ #using Mimikatz
Fig 9: Retrieving the NTLM hash of AZUREADSSOACC$ from the NTDS dump
-
Creating a Kerberos ticket for synced users
# Create a new Kerberos ticket
$kerberos=New-AADIntKerberosTicket -SidString “<SID>” -Hash “<NTLM>”
Note: Security identifier (SID)—SID of the user to be impersonated
NTLM—NTLM Hash of AZUREADSSOACCS$
-
With the Kerberos ticket, you can now get OAuth Access Token to be used with AADInternals functions.
# Get an access token for Exchange Online
$at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
# Send a message using “Outlook”
Send-AADIntOutlookMessage -AccessToken $at -Recipient “someone@company.com” -Subject “<Subject>” -Message “<MAIL>”
Fig 10: Forging the Kerberos ticket and access token for sending the email from one of the global administrators to our email
Our team of pentesters was also able to modify the MFA settings of the global administrator. However, they did not proceed further as this would disrupt the operations of the organization.
Fig 11: MFA Settings of a Global Administrator
Advice for Pentesters from CSW Experts
For those interested in penetration testing or red team activities, targeting Azure AD Connect and Azure Active Directory Single Sign-on will help migrate access to cloud services.
Our expert pentesters suggest that these attacks would be prevented if the following mitigation steps are in place:
-
Enable multi-factor authentication for all the users present in Azure.
-
It is recommended not to sync passwords of administrative accounts (Domain Admins, Schema Admins, etc.) to the cloud service.
Two other authentication methods, namely, Pass-Through Authentication and Federation Services, can also be leveraged for escalating the privileges from on-premise to Azure. The effectiveness of these authentication methods is still under scrutiny by our team of experts.
The inference drawn from the ongoing studies shall be updated to this blog in the coming weeks, so please be sure to stay abreast of the latest developments.
CSW’s Penetration Testing as a Service helps organizations improve their security posture across full-stack networks, cloud, container, applications, APIs, and mobile applications.
Get your attack surface assessed by our security experts today!
Click here to talk to us.