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. 

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. This will give Falcon Cloud Security customers the opportunity to detect these attacks quickly and also obtain evidence that could be useful in incident response activities.  

Falcon Cloud Security Detections

In response to the observed patterns in these attacks, the Falcon Cloud Security 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
Detection Name Type Description
User accounts exported from Active Directory Behavior A bulk export was performed of all user accounts in Active Directory. While this could be legitimate Admin behavior, it could also indicate a threat actor is performing reconnaissance of user accounts in an attempt to elevate privileges and move laterally in your tenant. It is recommended this behavior be reviewed to validate the user’s need to export all user accounts and ensure this data is not improperly shared.
User groups exported from Active Directory Behavior A bulk export was performed of all user groups in Active Directory. While this could be legitimate Admin behavior, it could also indicate a threat actor is performing reconnaissance of user groups in an attempt to elevate privileges and move laterally in your tenant. It is recommended this behavior be reviewed to validate the user’s need to export all user groups and ensure this data is not improperly shared.
Role assignments exported from Active Directory Behavior A bulk export was performed of all role assignments in Active Directory. While this could be legitimate Admin behavior, it could also indicate a threat actor is performing reconnaissance of role assignments in an attempt to move laterally and escalate privileges in your tenant. It is recommended this behavior be reviewed to validate the user’s need to export all role assignments and ensure this data is not improperly shared.
New unverified domain added to tenant Behavior A custom domain was added to the Azure Active Directory (Azure AD) tenant. This is often the first step in configuring federated domain authentication. Federated domain authentication is a legitimately used configuration to support using on-premises passwords. Adversaries also leverage this Azure AD feature to create Azure AD persisted backdoors by configuring new federated domains with resources/infrastructure that they control.
Guest users given same permissions to Azure AD resources as member users Behavior Azure Active Directory was updated to give guest users the same access to Azure AD resources as member users. This setting gives guest users the ability to view and interact with Active Directory resources that they may not need access to and should be reviewed to ensure the access is appropriate.
Cross-tenant partner given inbound access Behavior A cross-tenant partner was configured in Azure Active Directory to support automatic user consent for inbound access. Cross-tenant synchronization is a legitimately used configuration to automate creating, updating and deleting Azure AD B2B users across different tenants. Adversaries also leverage this Azure AD feature to create persisted backdoors by adding new cross-tenant partners (controlled by the adversaries) to environments they have compromised.
Cross-tenant partner user syncing enabled Behavior A cross-tenant partner was configured in Azure Active Directory to support inbound user syncing/creation. Cross-tenant synchronization is a legitimately used configuration to automate creating, updating and deleting Azure AD B2B users across different tenants. Adversaries also leverage this Azure AD feature to create persisted backdoors by adding new cross-tenant partners (controlled by the adversaries) to environments they have compromised.
New federated domain added to Azure Active Directory Behavior A domain was configured in Azure Active Directory to support federated authentication. Integrating Azure AD with on-premises Active Directory using Active Directory Federation Services (AD FS) is a legitimately used configuration to support using on-premises passwords. Adversaries also leverage this Azure AD feature to create Azure AD persisted backdoors by configuring new federated domains with resources/infrastructure that they control.
Virtual machine disk exported by user Behavior A virtual machine disk was made available for download/export by a user account. Review the activity and validate the user’s need to export the disk, as this may be a way for an attacker to collect and exfiltrate data stored on the disk.
Default cross-tenant synchronization policy allows outbound automatic user consent Configuration In a breach scenario, an attacker can utilize automatic outbound user consent within a cross-tenant synchronization policy to sync the compromised user account into a partner tenant and grant attacker access using the same initially compromised credentials. It is not recommended to allow automatic outbound user consent.
Partner cross-tenant synchronization policy allows inbound user sync Configuration In a breach scenario, an attacker can utilize inbound identity synchronization within a cross-tenant synchronization policy to sync the compromised user account into a partner tenant and grant attacker access using the same initially compromised credentials. It is not recommended to automatically sync identities into tenants you are not in control of.

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:

  1. The user account used to perform the changes is authorized by role and policy to do so.
  2. The user account performing the changes has not been compromised, and endpoints associated with the user are not exhibiting signs of malware.
    1. This should include a review of recent actions performed by the user account to determine if it is being used in an unusual manner.
    2. Consider signs of phishing, social engineering or recent password resets related to the user account.
    3. 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.
    4. Review endpoint detections for suspicious activity involving the user account in question.
  3. 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. 
    1. Consider the domains added and their validity in relationship to the business and service context in which they are being used.
    2. Consider the reputation and threat history of new domains.
    3. 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. 

CrowdStrike has released detections in Falcon Cloud Security that are designed to shed light on administrative behaviors that could represent attempts to compromise this trust architecture so that customers have early warnings an attack may be occurring.

While the attack outlined in this blog shows that adversaries are leveraging legitimate cloud services and configurations to perform their attacks, CrowdStrike’s detections are designed to differentiate normal administrative functions from those with suspect attributes that could indicate an attack in progress.

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. By quickly cutting off access established by an adversary, CrowdStrike customers can disrupt the attack and stop the breach.

Additional Resources

Related Content