Summary
Pass-through authentication (PTA) is one of the Azure Active Directory (Azure AD) hybrid identity authentication methods. PTA relies on PTA agents installed on one or more on-premises servers. Azure AD uses a certificate-based authentication (CBA) to identify each agent. In May 2022, Secureworks® Counter Threat Unit™ (CTU) researchers analyzed how the protocols used by PTA could be exploited. The researchers determined that threat actors could steal the identity of the PTA agent by exporting the certificate used for CBA. The compromised certificate can be used with the attacker-controlled PTA agent to create an undetectable backdoor, allowing threat actors to log in using invalid passwords, gather credentials, and perform remote denial of service (DoS) attacks. Attackers can renew the certificate when it expires to maintain persistence in the network for years. A compromised certificate cannot be revoked by an organization’s administrators.
CTU™ researchers shared their findings with Microsoft on May 10, 2022. Microsoft responded on July 2 that PTA is working as intended and gave no indication of plans to address the reported flaws.
Azure AD hybrid identity authentication options
Azure AD supports three authentication options for hybrid identities (see Figure 1). Microsoft recommends using password-hash synchronization (PHS) for authentication. Identity federation and PTA are options for organizations that cannot or choose not to synchronize password hashes to the cloud, or organizations that need stronger authentication controls. Identity federation is usually implemented with the Microsoft Active Directory Federation Services (AD FS), which is included in Windows Server operating systems. PTA is often promoted as being preferable to identity federation, as AD FS has been targeted in attacks such as Solorigate (using a technique known as Golden SAML). In these attacks, threat actors can export the token-signing certificate from a compromised AD FS server and use it to forge SAML tokens to impersonate users.
Figure 1. Azure AD hybrid identity authentication options. (Source: Secureworks)
PTA relies on PTA agents installed on one or more on-premises servers. Microsoft recommends installing a minimum of three agents for high availability. Each tenant can have a maximum of 40 agents. Figure 2 illustrates the high-level PTA architecture.
Figure 2. High-level PTA architecture. (Source: Secureworks)
- A user accesses a service that uses the Azure AD identity platform (e.g., Microsoft 365) and provides their username and password.
- Azure AD encrypts the credentials and sends an authentication request to one or more PTA agents.
- The PTA agent decrypts the user’s credentials, attempts to log in to Active Directory with decrypted credentials, and returns results to Azure AD.
Installation
During the installation of a PTA agent, a certificate signing request (CSR) is sent to the Azure AD https: //<tenant ID> . registration . msappproxy . net/register/RegisterConnector endpoint (see Figure 3). The response includes a certificate signed by Azure AD.
Figure 3. PTA agent registration request. (Source: Secureworks)
The certificate is issued by HISconnectorRegistrationCA . his . msappproxy . net, and the certificate subject is the Azure AD tenant ID (see Figure 4). The agent ID is a globally unique identifier (GUID), which is encoded in object identifier (OID) value 1.3.6.1.4.1.311.82.1 as a byte array. The certificate is valid for six months.
Figure 4. PTA agent certificate information and details. (Source: Secureworks)
The list of PTA agents and their associated IP address and status is stored in Azure SQL Database and is available in the Azure AD portal (see Figure 5). The list does not display the agent IDs.
Figure 5. List of PTA agents in the Azure AD portal. (Source: Secureworks)
Administrators can use the MS Graph API or tools such as AADInternals to view agents’ IDs. For example, Figure 6 lists two agents and their IDs. The first ID matches the certificate in Figure 4, but each segment of the ID lists the values of the certificate in reverse order as described in RFC4122.
Figure 6. Using AADInternals to list PTA agents. (Source: Secureworks)
The PTA agent ID is included on the Authentication Details tab in the Azure AD sign-ins log details. It identifies which agent was used to authenticate the user. For example, Figure 7 shows that the second agent listed in Figure 6 performed the authentication.
Figure 7. Authentication details in the Azure AD sign-ins log. (Source: Secureworks)
The thumbprint of the certificate used by the PTA agent is located on disk in a configuration file named C:ProgramDataMicrosoftAzure AD Connect Authentication AgentConfigTrustSettings.xml (see Figure 8).
Figure 8. PTA agent configuration file. (Source: Secureworks)
The certificate, including the private key protected by the data protection API (DPAPI), can be exported with tools such as AADInternals and Mimikatz. AADInternals exports the certificate as a PFX file named as <computer full name>_<tenant ID>_<agent ID>.pfx (see Figure 9).
Figure 9. Exporting PTA agent certificate using AADInternals. (Source: Secureworks)
PTA agent startup
The main technical components involved with PTA are Azure AD, Azure Service Bus, and the Azure AD Connect Authentication Agent (PTA agent). The agent searches for a “bootstrap” document that specifies settings and a list of command and control (C2) channels that enable the PTA to establish WebSocket connections to identified endpoints (see Figure 10).
Figure 10. PTA agent startup sequence. (Source: Secureworks)
- The PTA agent connects to https: //<tenant ID> . pta . bootstrap . his . msappproxy . net/ConnectorBootstrap and uses CBA to identify itself.
- Azure AD sends an HTTP redirect to the PTA agent for the regional endpoint.
- The PTA agent connects to the regional endpoint at https: //bootstrap-<xxxn> . his . msappproxy . net/ConnectorBootstrap. The <xxxn> variable includes three alphabetical characters and one number.
- Azure AD returns a “bootstrap” XML document containing several settings and a list of signaling listener endpoints geographically close to the PTA agent (see Figure 11). This document instructs the PTA agent to connect to and listen on specific command and control (C2) channels via the Azure Service Bus.
- The PTA agent establishes a WebSocket connection to each signaling listener endpoint and is ready to receive authentication requests. Endpoints are implemented using Azure Service Bus.
Figure 11. Excerpt of bootstrap file. (Source: Secureworks)
The PTA agent repeats steps 1 through 4 every ten minutes to refresh the bootstrap. The agent reconnects to the signaling listener endpoints defined in the bootstrap XML data (step 5) as needed.
PTA authentication process
PTA leverages Azure Service Bus, Azure Relay, and Azure AD Application Proxy services during the authentication process (see Figure 12). These elements deliver authentication requests from Azure AD to PTA agents, and authentication responses from the PTA agents to Azure AD.
Figure 12. PTA authentication process. (Source: Secureworks)
- Azure AD sends a notification to all connected agents via Azure Service Bus. The notification includes an address of the Azure Relay.
- The PTA agent establishes a WebSocket connection to the Azure Relay.
- Azure AD sends an authentication request to the PTA agent via Azure Relay.
- The PTA agent attempts to log in to the on-premises Active Directory domain. It sends the authentication results to Azure Web Application Proxy via an HTTP POST request.
The established WebSocket connections are not closed. This means that subsequent authentication requests are faster, as not all steps are needed. Requests can be sent using the already established connection to the relay.
The authentication request sent in step 3 is an XML file (see Figure 13). The EncryptedData element contains an array of credentials encrypted using different certificates. The key identifier is in the format <agent ID>_<certificate thumbprint>. This format allows each PTA agent to decrypt the appropriate credentials entry.
Figure 13. Authentication request. (Source: Secureworks)
After signing in using the provided credentials, the PTA agent sends a response message to Azure AD via the proxy. The response is a JSON file that includes two claims. In a successful response (see Figure 14), the “http: //schemas . xmlsoap . org/ws/2005/05/identity/claims/authentication” claim is set to true and the “http:// schemas . xmlsoap . org/ws/2002/05/identity/claims/name” claim is set to the user’s username. Azure AD does not check the validity of the username.
Figure 14. Response for successful authentication. (Source: Secureworks)
In the failed response (see Figure 15), the “http: //schemas . xmlsoap . org/ws/2005/05/identity/claims/authentication” claim is set to false and the “http: //schemas . xmlsoap . org/ws/2002/05/identity/claims/validationfailurereasoning” claim contains the error code. For instance, error 1327 means “Account restrictions are preventing this user from signing in.”
Figure 15. Response for failed authentication. (Source: Secureworks)
Custom PTA agent
After studying the protocols used by PTA agents, CTU researchers implemented a proof-of-concept custom PTA agent that leverages the certificate of an existing PTA agent. After startup, the custom PTA agent connects to Azure AD and waits for authentication requests. Figure 16 shows the agent connecting to Azure AD using the provided certificate, decrypting credentials, and displaying the plaintext user password. The custom agent can accept or deny all requests regardless of whether the password is valid. Threat actors can create a similar custom PTA agent to harvest credentials, establish a backdoor, or conduct a DoS attack by denying authentication requests containing valid credentials.
Figure 16. Custom PTA agent. (Source: Secureworks)
CTU researchers observed that the PTA agent’s IP address changed in the Azure AD portal when the custom PTA agent started (see Figure 17). However, after the original PTA agent fetched the bootstrap during its next ten-minute cycle, the IP address reverted. This behavior implies that the IP address is populated every time a PTA agent fetches the bootstrap. When CTU researchers pointed the custom PTA agent to an existing bootstrap file on the system, the agent’s IP address did not change on the portal. This result suggests that connecting directly to signaling listener endpoints does not affect the IP address. As such, threat actors can use an existing bootstrap to connect to Azure AD undetected.
Figure 17. PTA agent IP address change. (Source: Secureworks)
The certificate used to authenticate the PTA agent is valid for six months. The PTA agent cannot decrypt passwords when its certificate expires or if the agent has been inactive for ten days. In these cases, the PTA agent can “renew” the trust with Azure AD by making a HTTP POST request to the trust renew endpoint defined in the bootstrap file. The expired certificate can be used for CBA with this endpoint, and Azure AD returns a new certificate. Renewing trust does not populate the PTA agent’s IP address or invalidate the previous certificate, so a single agent can possess multiple valid certificates. CTU researchers observed that if a PTA agent possesses more than ten active certificates, the authentication requests contain passwords encrypted with the ten newest certificates. Threat actors can perform DoS attacks by renewing the certificate of the compromised agent ten or more times, making the original agent unable to decrypt credentials.
Because the information available from the Azure AD portal for administrators is populated when the bootstrap XML is requested, impersonating a PTA agent using the compromised certificate cannot be detected using Microsoft administrator tools. The Secureworks custom PTA agent can dump all active agents and certificates (Figure 18), helping administrators detect and identify compromised agents.
Figure 18. Secureworks custom PTA agent dumping active agents. (Source: Secureworks)
The PTA agent exports agent IDs and certificate thumbprints for all active certificates to a text file. Figure 19 shows that the PTA agent with ID 672843e0-8b25-434f-93e2-5d5071139e09 possesses three active certificates, which indicates that a compromised agent certificate was used to renew the certificate twice. The renewed certificates’ active status means that they were used by a threat actor during the last ten days.
Figure 19. List of active agents and certificates. (Source: Secureworks)
Unlike AD FS token-signing certificates, PTA agent certificates cannot be explicitly revoked. Administrators can remove PTA agents from servers but cannot directly remove PTA agents from the Azure SQL Database. Agents can only be removed from the database by keeping them inactive for ten days, after which they are automatically removed by Microsoft. If a threat actor is actively using any certificate associated with the compromised PTA agent, the agent never becomes inactive.
Communication with Microsoft
CTU researchers reported their initial findings to the Microsoft Security Response Center (MSRC) on May 10, 2022 and submitted additional findings related to undetectable access on May 16. The MSRC responded to the CTU research team on July 7:
Our team completed the assessment for this issue and we understand that the attack surface for this requires compromising a high security asset by gaining administrative access in the first place. If the customer followed our hardening guidance but the attacker still has access to the server that runs the PTA agent then they already had access to the user credentials, hence we believe this vulnerability in itself does not pose an additional risk. As a mitigation mechanism, we do have the ability to block agents on the server side based on customer escalations and furthermore we are looking into ways to improve our audit logs as an improved detection mechanism.
Conclusion
A compromised PTA agent certificate gives threat actors persistent and undetectable access to a target organization. Threat actors can use the compromised certificate to conduct the following activities:
- Harvest credentials
- Create a backdoor
- Conduct DoS attacks by rejecting valid passwords or by renewing the certificate ten or more times
CTU researchers recommend that organizations perform the following actions to protect their tenants:
- Treat all on-premises hybrid identity components, including servers with PTA agents, as tier 0 servers.
- Consider using other hybrid authentication methods, such as PHS or identity federation, until Microsoft addresses these security issues.
- Monitor for suspicious activity, such as logins using an incorrect password. Sign-in activity is available in the Azure AD portal and via the ‘beta’ version of the Microsoft Graph sign-ins report. If there are any indications of a compromised PTA agent, immediately create a support request in the Azure AD portal to invalidate the agent.
- Use multi-factor authentication to prevent threat actors from using a PTA agent as a backdoor.