Compromising Identity Provider Federation

Originally published by CrowdStrike.

• 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.
• 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

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.

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. 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.

Some observed actions on objectives related to these attacks include:

• Creating cloud compute resources or VMs
• Accessing cloud compute resources and exfiltrating data by exporting virtual disks
• Obtaining user information from the IdP
• Accessing data in applications that rely on the IdP access controls
• Leveraging the Azure run command to deploy other tooling

Why Is It Important to Monitor Changes to Identity Provider Configurations?

Organizations delegate user access controls to outside IdPs, which means the outside IdP is entrusted with maintaining the confidentiality, integrity, and availability of downstream services and data. Identity management and user access control are paramount to information security.

Monitoring for the scenarios outlined above provides customers with early indications of sensitive behaviors — or sequences of behaviors — that CrowdStrike believes warrant awareness and validation.

Cloud Security Detections

In response to the observed patterns in these attacks, the CrowdStrike team analyzed the prevalence of the noted behaviors and has worked to build detections that attempt to elevate awareness when a matching pattern of activity has occurred. These detections represent a combination of perspectives that warrant awareness and response by security teams.

1. Configuration changes that rarely occur and have potential for significant abuse
2. Behaviors that rarely occur in combination with others and may resemble a known attack sequence
3. Specific behaviors leveraged in these attacks

Response Recommendations

Because the behaviors outlined in this attack sequence take advantage of normal features of identity provider federation, it is possible that initial setup or routine administrative maintenance may trigger detections. CrowdStrike has considered the potential for producing false positive detections and has concluded that it is worthwhile to maintain vigilant monitoring of these sensitive functions. CrowdStrike recommends that organizations review all changes to IdP settings to verify that:

• The user account used to perform the changes is authorized by role and policy to do so.
• The user account performing the changes has not been compromised, and endpoints associated with the user are not exhibiting signs of malware.
  • This should include a review of recent actions performed by the user account to determine if it is being used in an unusual manner.
  • Consider signs of phishing, social engineering or recent password resets related to the user account.
  • Consider authentication details for the user account, including source IP address, region and user-agent strings to look for signs it is being accessed from an unusual source.
  • Review endpoint detections for suspicious activity involving the user account in question.
• The observed changes to IdP configurations were authorized through existing governance, risk and compliance (GRC) review and performed in compliance with change management policies and procedures.
  • Consider the domains added and their validity in relationship to the business and service context in which they are being used.
  • Consider the reputation and threat history of new domains.
  • For suspect domains, review any future login and service access activity originating from the new IdP.

Conclusion

Abuse of federated identity providers appears to be on the rise and represents a significant threat to downstream services, applications and data.

Due to the nature of this compromise, a timely response is prudent. CrowdStrike recommends taking immediate steps to validate the observed behaviors are authorized and to remediate them if they are not authorized by reversing any changes made.