Cross-tenant impersonation: Best practice tips from Okta

Identity attacks, specifically impersonation attacks, represent a significant and growing threat to organizations. Over the past couple of months, this has been well documented.

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

Okta recommends that organizations do the following

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

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

More details can be found from Okta's defensive cyber operations team here.