Azure Active Directory Exposes Internal Information

Summary

Microsoft Azure Active Directory (Azure AD) is an identity and access management solution used by over 88 percent of Fortune 500 companies as of this publication. This market penetration makes Azure AD a lucrative target for threat actors. In the second half of 2021, Secureworks® Counter Threat Unit™ (CTU) researchers analyzed Azure AD tenants and were able to extract open-source intelligence (OSINT) about organizations. Threat actors frequently use OSINT to perform reconnaissance. CTU™ researchers identified several application programming interfaces (APIs) that access internal information of any organization that uses Azure AD. Collected details included licensing information, mailbox information, and directory synchronization status.

CTU researchers shared their findings with Microsoft, and all but two of the issues have been mitigated as of this publication. Microsoft applied the updates automatically to all Azure AD tenants, so there are no actions required for Azure AD administrators. Microsoft classified the unmitigated issues as “by-design.” The first issue allows anyone to query the directory synchronization status. In some scenarios, Azure AD reveals the name of the high-privileged account used for synchronization. The second issue could reveal internal information about the target Azure AD tenant, including the technical contact’s full name and phone number. The technical contact usually holds Azure AD Global Administrator privileges.

OSINT details in Azure AD

Tools such as AADInternals gather OSINT from Azure AD using unauthenticated APIs. This OSINT includes the target tenant’s registered domains and types, tenant name and ID, and seamless single sign-on status (also known as DesktopSSO). Figure 1 lists Invoke-AADIntReconAsOutsider command output that contains OSINT information about the organization.

Figure 1. Invoke-AADIntReconAsOutsider output listing OSINT from unauthenticated APIs. (Source: Secureworks)

In addition to the unauthenticated APIs, there are authenticated APIs that can only be used after logging into an Azure AD tenant. Figure 2 lists the information that any user can access from their own tenant. Administrator privileges are not required. CTU researchers discovered authenticated APIs that could access information about any tenant, not just the authenticated user’s tenant.

Figure 2. Invoke-AADIntReconAsInsider output listing data from authenticated APIs. (Source: Secureworks)

Diagnostics API

Microsoft uses the undocumented Diagnostics API with the Support and Recovery Assistant (SaRA) tool to help the logged-in user diagnose and solve problems when accessing Microsoft cloud services. In 2019, CTU researchers observed SaRA using an analysis API endpoint. The traffic between the SaRA client and the analysis endpoint used the process in Figure 3.

Figure 3. Diagnostics API analysis endpoint process. (Source: Secureworks)

1. A user opens SaRA, enters symptoms, and starts the diagnostic.
2. SaRA makes an initial HTTP POST request to the analysis endpoint (see Figure 4). The request contains an AnalyzerId and DiagnosisInfo.

   
   Figure 4. Diagnostics API analysis endpoint initial request. (Source: Secureworks)

3. The response returns the SessionId to SaRA.
4. The Diagnostics API backend starts the analyzer to explore the defined user’s tenant and mailbox.
5. SaRA uses an HTTP GET request and the SessionId to poll the analysis status (see Figure 5).

   
   Figure 5. Diagnostics API analysis endpoint poll request. (Source: Secureworks)

6. The Diagnostics API returns analysis results to SaRA.
7. SaRA displays the results to the user.

The AnalyzerId represents an analyzer containing the diagnostic instructions that SaRA tasks the Diagnostics API to perform on the user’s behalf. The SaRA client source code contains a list of analyzers (see Figure 6).

Figure 6. Sample of SaRA analyzer IDs and names from the analyzer list in the source code. (Source: Secureworks)

CTU researchers identified the cloud-related analyzers from this list (see Table 1).

Table 1. Cloud-related Diagnosis API analysis endpoint analyzers.

The SaRA client uses the DiagnosisInfo structure to pass parameters to analyzers. Figure 7 lists the parameters used by each of the cloud-related analyzers.

Figure 7. DiagnosisInfo content for each cloud-related analyzer. (Source: Secureworks)

The results contain user information, including full licensing information, Office versions enabled in the tenant, the organization’s Exchange hybrid configuration and external relationships, user mailbox information, and Messaging Application Programming Interface (MAPI) status (see Figure 8).

Figure 8. Information returned by Diagnostics API analysis endpoint. (Source: Secureworks)

The SaRA client extracts the logged-in user’s email address from their OAuth token (see Figure 9) and uses that as the target SmtpAddress in the DiagnosisInfo parameter.

Figure 9. OAuth token for Diagnostics API. (Source: Secureworks)

The Diagnostics API does not validate whether the SmtpAddress matches the logged-in user. It is possible to retrieve information for any user from any tenant by replacing the SmtpAddress with the email address of the target user. If the target user does not exist but the domain is correct, the API returns all tenant-related information. This information is valuable to threat actors. For instance, the licensing information shows which protective components the target tenant could be using. Moreover, the organizational relationships identify additional individuals that could be targeted in phishing attacks to gain access to a tenant.

CTU researchers reported this vulnerability to Microsoft on September 7, 2021. On September 22, Microsoft responded that the issue was resolved. CTU researchers confirmed that the resolution included two modifications:

• Denies access to other users’ information (see Figure 10).
  
  Figure 10. ‘You don’t have access to given user’ response. (Source: Secureworks
• Invalidates all AnalyzerIDs, making the analysis endpoint obsolete (see Figure 11).
  
  Figure 11. ‘Unknown analyzer id’ response. (Source: Secureworks)

In 2021, CTU analysis of SaRA version 17.0.7.7119.4 revealed the client using the cloudcheck endpoint instead of the analysis endpoint. Figure 12 depicts the cloudcheck endpoint process.

Figure 12. Diagnostics API cloudcheck endpoint process. (Source: Secureworks)

1. A user opens SaRA, enters symptoms, and starts the diagnostic.
2. SaRA makes an initial HTTP POST request to the cloudcheck endpoint (see Figure 13).

   
   Figure 13. Diagnostics API cloudcheck endpoint initial request. (Source: Secureworks)

   The request contains the Symptom and Parameters details (see Figure 14) the user entered in Step 1.
   
   Figure 14. Information sent to cloudcheck endpoint. (Source: Secureworks)

3. The response returns the RequestId to SaRA (see Figure 15).

   
   Figure 15. Diagnostics API initial response. (Source: Secureworks)

4. The diagnosis API backend starts the diagnostics to explore the defined user’s tenant and mailbox.
5. SaRA uses an HTTP GET request and the RequestId to poll the analysis status (see Figure 16).

   
   Figure 16. Diagnostics API v1 poll request. (Source: Secureworks)

6. The cloudcheck endpoint returns diagnostic results to SaRA.
7. SaRA displays the results to the user.

The SaRA client revealed the following symptoms that could retrieve similar diagnostic information as the analysis endpoint:

• CasMailbox
• DirSyncCheck
• ExchangeHybridTenant
• GetUserDiagnostic
• TenantUserInfo

Figure 17 lists the parameters used by the DirSyncCheck symptom.

Figure 17. Parameter values for DirSyncCheck request. (Source: Secureworks)

Like the analysis endpoint, the UserUpn and UserSMTPEmail attributes in the initial request were the same as the user principal name of the bearer token used to access the API. As with the analysis endpoint, it was possible to retrieve information for other users and tenants by replacing the values with the email address of the target user. After Microsoft addressed the analysis endpoint issue, the logged-in user could only retrieve CasMailBox information for users of the same tenant. However, all other information could still be requested from any tenant.

CTU researchers reported this vulnerability to Microsoft on September 23, 2021. On December 2, 2021, Microsoft applied an update. CTU researchers confirmed that everything except the directory synchronization status issue was addressed. On January 28, 2022, Microsoft closed the issue as fixed, leaving the synchronization status intact.

Table 2 lists the directory synchronization status values. While all status information is important for threat actors, the password expiration message is the most valuable as it reveals the account name used for synchronization. This account has high privileges in the target tenant. It can be used to create, edit, and delete users in all tenants, and to reset users’ passwords in some tenants. By default, the synchronization account’s password is generated during the configuration and is not set to expire. For security purposes, some organizations configure the password to expire in their tenants, which could expose the account name. The password expiration reminder can be configured to be sent 1 to 30 days prior to the expiration date.

Table 2. Directory synchronization status messages.

Organization information

Azure AD collects information when a representative from an organization signs up for a new Microsoft 365 or Azure AD environment or tenant. The form collects the full name and phone number of this representative (see Figure 18), and that person becomes the technical contact of the tenant.

Figure 18. Office 365 signup form. (Source: Secureworks)

After signing up, this technical contact can edit their contact details in the Microsoft 365 admin center (see Figure 19). The company name and phone number are pre-populated from the original signup form.

Figure 19. Organization information in the admin center. (Source: Secureworks)

Microsoft business partners offer services to customer organizations that use Microsoft cloud services such as Microsoft 365 and Azure AD. Azure AD administrators in customer organizations can authorize these partners to access their tenants, which creates a partner relationship in the customer’s tenant. These partner relationships can only be accessed via the Microsoft 365 admin center. Only administrators have access to the admin center.

CTU researchers discovered an API (see Figure 20) used by the admin center to retrieve details regarding the partner’s organization. Although the API is exclusively used by the admin center, it does not require administrative permissions to be accessed. The API requires the partner’s tenant ID as an input.

Figure 20. Admin API request for partner details. (Source: Secureworks)

The response (see Figure 21) contains contact data from the organization information and signup form. After the initial signup, the first and last name can only be changed by Microsoft. Those fields cannot be viewed or modified in the admin center.

Figure 21. Partner information returned by admin API. (Source: Secureworks)

CTU researchers verified that this API could retrieve this information for any tenant, regardless of their partner status. CTU researchers reported this vulnerability to Microsoft on December 14, 2021. On January 12, 2022, Microsoft stated that “this information is expected to be shown” and did not mitigate the issue.

Conclusion

A threat actor can gather a significant amount of OSINT from an Azure AD tenant. Microsoft addressed all but two of the issues CTU researchers identified:

• The tenant’s synchronization status can reveal if the synchronization is configured, if is it operational, the time of the last synchronization, and the synchronization account’s name. Attackers can use this information for social engineering (leveraging the synchronization error data) and targeted brute-force attacks (using the account name).
• The organization information could expose the name and phone number of the tenant’s Global Administrator. This information can be abused for social engineering, spearphishing, and targeted brute-force attacks.

CTU researchers recommend the following actions to protect tenants from OSINT abuse:

• Organizations should ensure that their directory synchronization can perform the synchronization within the defined timeframes to avoid exposing details in error messages. Administrators receive an email if synchronization has not been successful in more than 24 hours, but the error message is displayed after three hours of inactivity.
• Organizations that implement an expiration for a directory synchronization account password should reset the password before Azure AD displays the expiration reminder to prevent exposure of the directory synchronization account name.
• Organizations should change the details associated with their tenant to general labels (e.g., “IT Department”) rather than personally identifiable data. Using a generic term prevents exposing the name of the potential Global Administrator account. An organization can modify some fields (e.g., phone number), but must create a support request in the Azure portal to change the first and last name of the technical contact.