Summary
In response to the SolarWinds supply chain compromise, the U.S. National Security Agency (NSA) published an advisory describing advanced techniques that threat actors can use to maintain persistent access to compromised cloud tenants and exfiltrate sensitive data. Most of the public commentary about this advisory has focused on the theft of Active Directory Federation Services (ADFS) token-signing certificates to forge Security Assertion Markup Language (SAML) assertions. However, Secureworks® Counter Threat Unit™ (CTU) researchers also focused on the addition of unauthorized credentials to Azure applications and service principals and created a scenario to demonstrate how threat actors with an understanding of the Microsoft Identity Platform could perform supply chain attacks across multiple Azure Active Directory (Azure AD) tenants. These techniques do not indicate vulnerabilities or flaws in how Azure AD manages authentication and authorization.
Background
Within the Azure ecosystem, all tenants trust a common identity provider. Azure AD is the common identity provider that handles authentication within and across Azure tenants. This functionality lets organizations share access to resources with other organizations without the need to establish separate trust relationships. Azure AD manages authorization through a permissions model, allowing users and administrators to specify which resources are shared with other organizations.
Just like users, applications in Azure AD possess an identity and optionally can use credentials such as a password or certificate. From the NSA advisory:
“… the actors leverage a compromised global administrator account to assign credentials to cloud application service principals (identities for cloud applications that allow the applications to be invoked to access other cloud resources). The actors then invoke the application’s credentials for automated access to cloud resources (often email in particular) that would otherwise be difficult for the actors to access or would more easily be noticed as suspicious.”
There is a subtle but important distinction between adding credentials to an Azure application versus adding credentials to the application’s service principal.
Azure applications and service principals
In Azure AD, an application object defines a set of permissions and other metadata (collectively called a manifest) that is required for an application to function. Applications exist in the application owner’s Azure tenant and are available to the users of that tenant. However, an application owner can choose a “multi-tenant” configuration to make the application available to users in other Azure tenants. The application object in the application owner’s tenant is registered with the common identity provider (Azure AD) and made available to other tenants.
An application object is used as a template to create one or more service principal objects. A service principal is created in every tenant where the application is used to access resources on behalf of the associated application. When consent is granted to the application within the tenant in which it is being used, the associated service principal is assigned the permissions defined in the application manifest. Service principals are analogous to a service account in legacy Active Directory, but only one service principal is created per unique application in a tenant.
All tenants use the same application manifest as a template when creating service principals for that application in their own tenant. Figure 1 shows the relationship between an application, the application owner’s tenant, and service principals created in each tenant where the application is provisioned.
Figure 1. Sample scenario showing multi-tenant application relationships. Adatum is the tenant where the HR application was created. Contoso and Fabrikam are both tenants that want to use the HR app within their respective Azure AD environments. (Source: Microsoft)
Credentials can be password-based or certificate-based and can be assigned to applications and service principals. Anyone who obtains a service principal credential can authenticate to the associated tenant and leverage the permissions granted to that service principal.
OAuth 2.0 application permissions
Azure AD implements the OAuth 2.0 authorization framework. OAuth 2.0 enforces a fine-grained permission model between protected resources (such as the Microsoft Graph API) and the users or applications that have explicitly been granted access to those resources. There are two permission types:
- Delegated user permissions — These permissions are granted to a service principal when a user grants consent to an application. The service principal can then access resources in the context of that signed-in user (e.g., use the Microsoft Graph API to read the user’s contacts, emails, or files). The OAuth2PermissionGrant attribute of a service principal records which users have granted consent and to which permissions.
- Application permissions — These permissions are only granted to a service principal when an administrator grants consent to an application. The service principal in that tenant associated with the application can then access resources outside the context of a particular user (e.g., use the Microsoft Graph API to read all contacts, all email inboxes, or all files in an organization). The service principal’s AppRolesAssignedTo attribute records which resources and permissions the application was granted consent to by the administrator.
Application permissions can provide a wider range of access to protected resources than delegated user permissions, so they will likely be more attractive to a threat actor. Application permissions and delegated user permissions are ultimately assigned to the same service principal for a given application. As a result, a threat actor who maliciously adds credentials to a service principal could abuse both permission types in that tenant. If the application already has application permissions that grant it access to sensitive resources, threat actor access to the application could be particularly harmful.
If the required permissions for an application are updated in the application owner’s tenant, the modified permissions do not automatically propagate to service principals outside the owner’s tenant. Instead, those changes would require renewed consent in each individual tenant. To avoid this step, stealthy threat actors are incentivized to target applications that already have the desired permissions.
OAuth 2.0 client credentials grant flow
In contrast to service principal credentials, application credentials could give a threat actor access to protected resources in any tenant where that application has been granted application permissions. This behavior is due to how the OAuth 2.0 specification handles authentication (as opposed to authorization).
OAuth 2.0 defines a variety of authentication flows that issue bearer tokens. Bearer tokens give the possessor a specific level of access to a protected resource. Most OAuth 2.0 authentication flows involve an elaborate exchange of information among an end user, an application (called a ‘client’ in OAuth parlance), an authorization server (https: //login . microsoftonline . com for Azure AD), and a server where the protected resources reside. In the context of OAuth 2.0 flows, an Azure application credential is used as the client secret (or client assertion, if using for certificate-based credentials) to verify the identity of the client.
The OAuth 2.0 client credential grant flow, however, works a little differently. This grant flow (sometimes described as ‘two-legged OAuth’) is used for server-to-server requests that are intended to run in the background without user interaction or involvement (see Figure 2). The client credential grant flow lets an Azure application use its credential as the client secret when acting as an OAuth client. Because these requests do not involve a user, this grant only works for application permissions.
Figure 2. OAuth client credential grant flow. (Source: Microsoft)
Attack methodology
A threat actor could use the following procedure to successfully execute a supply chain attack using a malicious Azure application credential:
- Identify popular Azure applications that legitimately require the desired application permissions, such as ‘Mail.Read’ on the Microsoft Graph. The attack will not require additional consents to work in tenants where the application was already granted consent.
- Obtain application administrator-level privileges (or higher) in the application owner’s tenant.
- Add a new credential to the application. Applications can possess multiple concurrently valid credentials, so adding a new credential should not immediately impact the application’s legitimate functionality.
- Use the client credential grant flow to obtain an access token for the targeted tenant by passing the client (application) ID, the client secret (the malicious credential), and the tenant ID.
- Gain access to data based on the application permissions.
This procedure does not exploit a vulnerability or a flaw in Azure AD authentication or authorization. A threat actor must first compromise the network of an organization that is developing multi-tenant applications. It is likely that only sophisticated threat actors possess the skills and patience necessary to successfully conduct these attacks without detection.
Demonstration
CTU™ researchers developed a scenario to demonstrate how a threat actor could use Azure application credentials and OAuth Client credential flow for supply chain attacks. Figure 3 shows a multi-tenant application registered in the application owner tenant (“App Publisher Tenant”). This application requires a few sensitive application permissions on the Microsoft Graph API for legitimate functionality such as reading all chat messages.
Figure 3. Application permissions from the Azure Portal ‘App Registration’ page. (Source: Secureworks)
A new customer (“Customer Tenant”) must provide administrative consent to the application during provisioning. The application object from App Publisher Tenant is used as a reference to determine which permissions are requested and assigned to Customer Tenant’s service principal (see Figure 4).
Figure 4. Dialog that grants administrative consent to the application during provisioning. (Source: Secureworks)
Customer Tenant’s service principal is located under ‘Enterprise Applications’ in the Azure Portal (see Figure 5).
Figure 5. Service principal associated with the application. Click image to view full-size version. (Source: Secureworks)
If a threat actor obtains sufficient cloud administrator privileges in App Publisher Tenant, they could add a malicious credential to the legitimate application (see Figure 6). Even if the application has an existing credential for benign functionality, the malicious credential should not impact the stability of the application because Azure AD will validate either credential.
Figure 6. Malicious credential added to legitimate application. (Source: Secureworks)
The threat actor can use this malicious credential as the client secret in an OAuth client credentials grant flow (see Figure 7). If the application published from App Publisher Tenant is provisioned normally in Customer Tenant and the legitimate application permissions were granted to the Microsoft Graph API, then a credential added to the application in App Publisher Tenant would allow the threat actor to obtain an access token for Microsoft Graph API resources within Customer Tenant.
Figure 7. Code that uses the malicious credential to obtain an access token. (Source: Secureworks)
The threat actor can now use the access token to access resources in Customer Tenant via the Microsoft Graph API (see Figure 8).
Figure 8. Code that uses the access token to read a Customer Tenant user’s email. (Source: Secureworks)
Preventing and identifying compromises
To reduce risks resulting from the compromise of Azure applications, organizations creating applications should apply least privilege to ensure that the applications do not request excessive permissions. The permission requests should also use appropriate wording to ensure that users and administrators clearly understand what they are consenting to. Organizations that use Azure applications should remove unnecessary third-party applications from their environment and disable user consent where possible.
Application owners should monitor for “Update application – Certificates and secrets management” events in the Azure Audit Log or the legacy Unified Audit Log to identify suspicious activity. Organizations investigating potential application compromise should review Signin logs for evidence of an application signing in from one or more previously unseen IP addresses. When investigating activities such as suspicious email access through the Mail.Read permission, organizations should review MailItemsAccessed events to identify the application ID used to access the user mailbox. This ID could reveal anomalous access to data that may indicate a compromised application.
Conclusion
Attacks that abuse application permissions by compromising the application’s owner are very difficult to detect. Organizations creating multi-tenant applications should take steps to reduce the risk of those applications being compromised, ensure that they understand this attack methodology, and monitor logs for evidence that their cloud tenant or applications might be compromised. In addition to removing unnecessary third-party applications, CTU researchers recommend that organizations conduct regular audits for suspicious activity.
References
Bertocci, Vittorio. Modern Authentication with Azure Active Directory for Web Applications. Microsoft Press, December 22, 2015.
Cybersecurity and Infrastructure Security Agency. “Alert (AA21-008A): Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments.” January 8, 2021. https://us-cert.cisa.gov/ncas/alerts/aa21-008a
National Security Agency. “Detecting Abuse of Authentication Mechanisms.” December 7, 2020. https://media.defense.gov/2020/Dec/17/2002554125/-1/-1/0/AUTHENTICATION_MECHANISMS_CSA_U_OO_198854_20.PDF
Reiner, Shaked. “Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps.” CyberArk. November 21, 2017. https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
Sygnia. “Detection and Hunting of Golden SAML Attack.” December 2020. https://www.sygnia.co/golden-saml-advisory