Compromising Identity Provider Federation

• CrowdStrike’s Incident Response team has seen a recent increase in cases involving adversaries that abuse identity provider federation to gain access to protected services by adding and authorizing rogue domains to federation. From these cases, patterns have emerged that indicate a common attack structure.
• Monitoring for identity provider abuse can be difficult, given that adversaries do so by leveraging legitimate cloud services, often using compromised accounts for initial access — a reminder that securing identity and authentication services is critical in preventing these attacks.
• In a recent expansion of CrowdStrike Falcon® Cloud Security detections, CrowdStrike is noting these attacks are prevalent and significant enough to warrant establishing visibility over identity provider management. The indicators of attack discussed in this blog should be considered early indicators that require analysis in context to determine a final verdict on their nature.
• Since observed attack scenarios predominantly target Microsoft Azure as an identity provider, this blog and the referenced detections focus on that domain.

What Is a Federated Identity Provider?

 

A federated identity provider is an outside service provider that has been entrusted by an organization as an authority regarding user authentication and identity management. In the context of a service that leverages single sign-on (SSO), when an individual user requests access to the service, the service contacts the identity provider (IdP) to validate the user’s identity.

This capability enables different identity domains (organized groups of users) to partner with one another in validating users and granting their access to a downstream service, domain or cloud environment without having to replicate or maintain multiple instances of user identities. In this way, if an organization provides a service that has a user population outside of its authentication domain, it can extend access to those outside users by defining a trust relationship with the IdP for that outside user group.

The service provider is trusting that the IdP has performed all relevant authentication actions and verifications, and any subsequent access requests by the user to the service should be considered as authorized.

Okta provides details on federated identity and the role of identity providers in SSO.

The Attack

Adversaries are taking advantage of this architecture by compromising IdPs and modifying them to extend the umbrella of trust to include domains and users controlled directly by the attacker and to expand cross-tenant authentication partnerships. An example attack sequence is depicted in Figure 1.

Figure 1. Illustration of observed IdP compromise (click to enlarge)

Initial Access

The first step in the attack involves establishing access to the IdP’s cloud service provider (CSP) environment at the Control Plane layer with a user account that has permissions to administer resources.

While there are numerous methods that can be used to compromise a user account, CrowdStrike has noted the use of social engineering to obtain credentials as well as using a self-service password reset to take control of an existing account. Some CSPs also add risk analysis indicators to sign-in activity that can also be leveraged to spot signs of initial access.

Once credentials are obtained and authentication is verified, the adversary has been noted to use the CSP command line interface for initial login.

Reconnaissance

Reconnaissance in observed attacks has been focused on obtaining information that can be specifically leveraged to facilitate adding a new domain to federation settings. Observed behaviors during reconnaissance have included:

• Download users (bulk operation)
• Download role assignments (bulk operation)
• Download groups (bulk operation)
• Get API connectors
• Get authentication flows policy
• Get available output claims
• Get customAuthenticationExtensions
• Get identity providers
• Get tenant details
• Get user flows

It should be noted that CrowdStrike has observed the “get authentication flows policy” action to be extremely common, and by itself, it is not a strong indicator of an attack. It is listed here for reference and is included as part of CrowdStrike Falcon® Cloud Security detection logic as a contributing behavior.

Persistence and Backdoors

Once an attacker has completed their reconnaissance, they move to perform the necessary changes to federation settings to add the domains and user accounts under their control. Actions specifically related to creating a backdoor are listed below:

• Add unverified domain
• Add verified domain
• Verify domain
• Set domain authentication
• Update user
• Set directory feature on tenant

Some attacks may include establishing backdoor access via cross-tenant synchronization, which would be observable via the following:

• Add a partner to cross-tenant access setting
• Update a partner cross-tenant access setting
• Create a partner cross-tenant identity sync setting

Additional actions that have been observed in conjunction with those listed above include the following:

• Update named location
• Add policy
• Add application
• Add service principal
• Add service principal credentials
• Update application
• Update service principal
• Update provisioning setting or credentials
• Update authorization policy
• Update authentication flows policy
• Set company information

As with the behaviors listed as signs of reconnaissance, some of the behaviors CrowdStrike has categorized as persistence and backdoor may also occur in large volume in the normal course of cloud operations. CrowdStrike detections attempt to account for this and only elevate scenarios that resemble a sequence of behaviors that indicate abuse. It is important to evaluate all detections in context before reaching a final verdict.

Actions on Objectives

The primary goal of abusing federated identity providers is to gain access to resources or services that trust the IdP. Abuse of one IdP is likely used to access resources in an external domain, so this scenario should be viewed largely as a method to establish access and maintain persistence via the IdP.