Cross-Tenant Impersonation: Prevention and Detection

Summary

• Okta has observed attacks in which a threat actor used social engineering to attain a highly privileged role in an Okta customer Organization (tenant).
• When successful, the threat actor demonstrated novel methods of lateral movement and defense evasion.
• These methods are preventable and present several detection opportunities for defenders.

In recent weeks, multiple US-based Okta customers have reported a consistent pattern of social engineering attacks against their IT service desk personnel, in which the caller’s strategy was to convince service desk personnel to reset all Multi-factor Authentication (MFA) factors enrolled by highly privileged users.

The attackers then leveraged their compromise of highly privileged Okta Super Administrator accounts to abuse legitimate identity federation features that enabled them to impersonate users within the compromised organization.

Tactics, Techniques and Procedures

Okta Security has identified a cluster of activity in which:

• Threat actors appeared to either have a) passwords to privileged user accounts or b) be able to manipulate the delegated authentication flow via Active Directory (AD) prior to calling the IT service desk at a targeted org, requesting a reset of all MFA factors in the target account. In the case of Okta customers, the threat actor targeted users assigned with Super Administrator permissions.
• The threat actor would access the compromised account using anonymizing proxy services and an IP and device not previously associated with the user account.
• The compromised Super Administrator accounts were used to assign higher privileges to other accounts, and/or reset enrolled authenticators in existing administrator accounts. In some cases, the threat actor removed second factor requirements from authentication policies.
• The threat actor was observed configuring a second Identity Provider to act as an "impersonation app" to access applications within the compromised Org on behalf of other users. This second Identity Provider, also controlled by the attacker, would act as a “source” IdP in an inbound federation relationship (sometimes called “Org2Org”) with the target.
• From this “source” IdP, the threat actor manipulated the username parameter for targeted users in the second “source” Identity Provider to match a real user in the compromised “target” Identity Provider. This provided the ability to Single sign-on (SSO) into applications in the target IdP as the targeted user.

What is Inbound Federation?

Inbound Federation allows access to applications in a target Identity Provider (IdP) if the user has successfully authenticated to a source IdP. The feature can also be used for Just-in-time (JIT) provisioning of users. It’s a feature that is used to save months off mergers, acquisitions and divestitures. It is also popular with large organizations (such as global parent companies) that require central controls or globally provision one set of applications (while also empowering divisions to have some level of autonomy for their own policies and apps).

Given how powerful this is, access to create or modify an Identity Provider is limited to users with the highest permissions in an Okta organization - Super Administrator or Org Administrator. It can also be delegated to a Custom Admin Role to reduce the number of Super Administrator’s required in large, complex environments.

These recent attacks highlight why protecting access to highly privileged accounts is so essential.

Prevention

Based on our analysis of this intrusion, we recommend Okta customers implement our industry-leading, phishing-resistant methods for enrollment, authentication and recovery; restrict the use of highly privileged accounts, and apply dedicated access policies for administrative users and monitor and investigate anomalous use of functions reserved for privileged users.

A more detailed set of recommendations is listed below:

• Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn.
• Configure Authentication Policies (Application Sign-on Policies) for access to privileged applications, including the Admin Console, to require re-authentication “at every sign-in”. 
• If using self-service recovery, initiate recovery with the strongest available authenticator (currently Okta Verify or Google Authenticator), and limit recovery flows to trusted networks (by IP, ASN or geolocation).
• Review and consolidate the use of Remote Management and Monitoring (RMM) tools by help desk personnel, and block execution of all other RMM tools.
• Strengthen help desk identity verification processes using a combination of visual verification, delegated Workflows in which helpdesk personnel issue MFA challenges to verify a user’s identity, and/or Access Requests that require approval by a user’s line manager before factors are reset.  
• Turn on and test New Device and Suspicious Activity end-user notifications.
• Review and limit the use of Super Administrator Roles - Implement privileged access management (PAM) for Super Administrator access, and use Custom Admin Roles for maintenance tasks and delegate the ability to perform high-risk tasks.
• All Administrative roles in Okta can be constrained to a specific group. We recommend using Custom Admin Roles to create help desk roles with the least privileges required in your organization, and to constrain these roles to groups that exclude highly privileged administrators.
• Enforce dedicated admin policies - Require admins to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies.

Detection and Response

The following System Log events and Workflows templates can be adapted to detect several of the TTPs listed above.

Indicators of Compromise

For the period 2023-07-29 to 2023-08-19

IP addresses: