Watch our Hands-on Security Walkthrough Session on how to harden your Okta platform. Watch Now

Authomize Discovers PassBleed Password Stealing and Impersonation Risks in Okta

19/07/2022 • Gabriel Avner

Organizations depend on their Identity Providers for managing their identities and access to their apps and services, using them as their trusted management solution for everything from Single Sign-On and Multi-Factor Authentication to directory services and provisioning access.

In the course of Authomize’s ongoing effort to support stronger security for IAM tools, our research lab has uncovered a number of high impact inherent security risks in the Identity Provider (IdP) Okta.

They include:

  1. Clear text Password extraction via SCIM
  2. Sharing of Passwords and sensitive data over unencrypted channels (HTTP)
  3. Hub & spoke configuration allows sub-org admins to compromise accounts in the hub or other spokes downstream
  4. Mutable identity log spoofing

As responsible security researchers, we have reached out to Okta with our findings and confirmed that these risks do not represent vulnerabilities. Okta responded that the features are performing as designed and should not be categorized as vulnerabilities. It is important to note that while not categorized as vulnerabilities, these findings expose customers to potential attacks. As a vendor focused on securing the identity and access layer, we believe it is important to share our findings and to provide a way to detect and mitigate these risks.

Below we break down our findings, explain how they impact your organization, provide actionable recommendations for protecting your organization, and present a walk through of each of these risks.

Risk 1: Clear Text Password Extraction via SCIM


An attack requiring a relatively low level of privilege, an app admin can extract all Okta passwords of all app users by redirecting SCIM provisioning protocol to an attacker controlled host.


This can result in an app admin gaining the clear text passwords of other admins and being able to continue to compromise additional users. The potential impact here is complete compromise of a tenant, which also means all downstream applications. This can lead to a malicious actor destroying all organization data, stealing money by authorizing payments by impersonating another user, or generally causing damage. We will also note that SCIM might be used to send a lot of sensitive PII data about employees that can also be stolen using this method.


An app admin is the lowest privilege built-in role that can assign a user access to an app. As such, it is granted to people like helpdesk agents and even ops teams like the sales ops or fin-ops, as well as various other app owners. References about Okta roles can be found here.

Example Attack Scenarios:

  1. An app admin of a non-critical app like Calendly is bribed by a cyber criminal group to be their insider. Using this technique they could go in and use their permissions to exfiltrate all the company’s passwords by reconfiguring SCIM.
  2. An app admin can just steal the password of a super admin and use it to connect as that highly privileged user; basically achieving privilege escalation to super admin.


Based on their documentation, we have surmised that Okta holds passwords in clear text because they do not want to send hashes. This is likely because there is no standard reliable protocol for syncing hashes. Maybe now is a good time to get started on making one? We are happy to help in such an initiative.

Granted that this attack requires compromising an app admin and hopefully those users have MFA enabled. But as we have seen time and again, far too many admins do not have MFA in place or such measures have been defeated by adversaries.

Step-by-Step Proof of Concept: 

  1. Download a free SCIM server such as go-scim and run it on some network exposed host. If you do use go-scim, here are some bits of usage advice:
    1. We found that on weak hosts, you might want to delay the start of the server container by 10 seconds by editing the command line in “docker-compose.yml”
    2. In order to see the passwords in the web path of /Users in your server you will need to edit user_schema.json and remove the keys “returned” and “_annotations”
  2. Log in to Okta as app admin
  3. Install the “SCIM 2.0 test app” (or use an existing app) and configure it to auto-login
  4. Configure provisioning target to the SCIM server that you set up in step 1
  5. Configure Okta->App provisioning to share the Okta passwords and not randomly generated and check all the boxes
  6. Assign all targeted users to the app 
  7. Note: You might need to wait for the user to login again because the timing of when a sync happens is not clearly defined

Clear Text Password Extraction via SCIM 2

Recommendations for Okta Customers:

    • Never export your master Okta passwords
    • If you must sync passwords, then only send alternate passwords
    • Review your logs and seek out changes in SCIM configurations that may indicate that changes/actions may have occurred
      • Note that you only have 3 months of logs going back by default and the logs lack the exact target that was set to the sync
  • Review current targets of SCIM sync, especially when password sync is enabled, and continuously monitor newly created SCIM settings
  • Check who your app admins are and treat them as highly privileged actors 
    • Alternately – create a new reduced role for them with only the rights to edit user assignments

1-Clear Text Password Extraction via SCIM

Risk 2: Sharing of Passwords and Sensitive Data Over Unencrypted Channels (HTTP)


An attacker with the ability to sniff network communication between Okta and a SCIM server that is not using encrypted communication can sniff all shared profile details (PII), group membership and group details, and clear text passwords.


Attackers can access data that can aid in their exploitation of targeted organizations.


As opposed to the first risk listed above, in this case, the attacker does not control which users will be exposed and when.

Example Attack Scenario:

An unsuspecting organization configured a SCIM over HTTP and no warnings regarding the risk popped up. An attacker who gains the ability to sniff traffic between the SCIM server and Okta can gain access to all PII and clear text passwords transferred over this channel.


An attacker could try to forcefully trigger an account lockdown/password change if they wanted to try and target a specific user.

Step-by-Step Proof of Concept:

  1. Repeat the previous steps
  2. Configure the target URL to be HTTP and not HTTPS based

Recommendations for Okta Customers:

  • Review current targets of SCIM sync, especially when passwords are enabled
  • Continuously monitor newly created SCIM settings to ensure none point to unencrypted URLs
    • Note that unfortunately previous targets are not logged so you can’t know if you had this issue in the past

FREE Risk Assessment

Join our FREE Assessment to:

  • Detect if your Okta is configured securely
  • Assess if you have likely been impacted by these risks
  • Establish a secure IdP posture

Risk 3: Hub & Spoke Configuration Allows Sub-org Admins to Compromise Accounts in the Hub or Other Spokes Downstream


A small company was acquired by a large Fortune 500. The corporation connected the small company’s Okta as a spoke to their main Okta which acts as their hub with the default configuration. A compromised admin from the acquired company’s spoke gains super admin privileges throughout their Okta hub by impersonating a super admin, and therefore achieves full, unlimited access to the corporate’s entire collection of apps and services.

Attack Scenarios:

  1. A small company was acquired by a large Fortune 500. The corporation connected the small company’s Okta as a spoke to their Okta hub with the default configuration. A compromised admin from the acquired company’s spoke gains super admin privileges throughout all of the Okta, and therefore achieves access to the corporate’s entire collection of apps and services.
  2. A malicious insider with high privilege makes plans for retirement. They sign up to an Okta developer account and connect it as a spoke to the company’s Okta. Thus gaining access for malicious activity as long as no one audits.


An attacker with the spoke admin can hide their real identity and access other hubs and their downstream apps. The compromise of an Okta tenant affects all downstream apps and can potentially lead to a malicious actor destroying all organization data, stealing money by authorizing payments by impersonating another user, or generally causing damage.

Context and Conclusions:

The hub and spoke architecture is meant to support larger distributed organizations. While the spokes are meant to be lower security domains, they are trusted de-facto as IdPs by the hub. Example scenarios from the link above include: M&As, departments and main company, outsource companies and employing company, and more. In all cases, the lower privilege domain is the spoke that the hub trusts.

The out-of-the-box name duplication feature in the hub & spoke architecture is intentional and meant to make it easier to scale access controls across the organization while limiting the scope of control to a specific spoke.

Hub & Spoke Configuration 1

However, those barriers to access between the spokes are paper thin. With just a limited level of admin access to a spoke, an attacker (internal or external) can break through to access the other hub and compromise all apps connected to the hub, as well as identities from the hub and those that may originate in other spokes.

To be clear, Okta offers ways for the user to prevent name duplication. To fully achieve this you need to both apply filtering to prevent using admins in the hub, and the ability to modify the username in the hub and downstream apps by setting the IdP username.

Hub & Spoke Configuration 2

But these controls are not set by default, making the user potentially insecure from the initial settings. Okta also does little in their guide to explain to their users that they may be at significant risk from these insecure default settings.

Additionally, only filtering Okta admins is an insufficient mitigation as all other users in downstream apps will still be affected. In addition, in actual operations it is very hard to ensure all admins match a specific regular expression. Only adding a unique username format per spoke can prevent all potential impersonation.

This risk is further worsened by a “mutable identity log spoofing” risk that is described below and allows attackers to obfuscate their actions, making it appear under a cursory glance as if they were performed by others.

Step-by-Step Proof of Concept: 

Follow the instructions to set up a hub & spoke configuration using the Okta org2org application with this guide

Screenshots from the setup process:

Okta org2org 1

Okta org2org 2

Okta org2org 3

  1. In the spoke, assign users to be able to access the org2org app. For simplicity, just assign “Everyone”

Okta org2org 6

  1. In the spoke, create a user with the same identifier as a super admin in the hub. I added Ron Liberman who is a super admin in the organization I used in the hub (i.e. already has a user in the hub). For comfort, when creating the user, you should forcefully set the password to one you can easily use.

Okta org2org 7

  1. Log into the spoke (sub-organization) as the new identity and select the org2org app to login into the hub (main organization) as the super admin (could also work for downstream apps)
    1. First is in spoke, second is after login being in hub.
      Okta Org2Org 8
      Okta Org2Org 9
  2. Success – you are now a super admin on the hub (main organization).

Recommendations for Okta Customers:

  • Review all Identity Providers (i.e. upstream providers) configured in all your Okta tenants. Make sure you have set the following:
    • The IdP username format to prevent name duplication, e.g. by adding a suffix, except intentional scenarios such as using AD as the login source for Okta
    • Apply a filter policy to validate name matching formatting using a RegEx
  • Continuously monitor changes to the aforementioned settings
  • Search your logs in the spoke/hub to determine if anyone performed an impersonation in the hub or a downstream app 
    • Again note that logs only go back 3 months by default

Risk 4: Mutable Identity Log Spoofing


Any Okta user can by default edit their first and last name. 

The problem is that those parameters are logged and displayed in different places to prevent privileged or unauthorized actions from going unnoticed.

The logs save the details at the time of the action and they are the details displayed in the dashboard when an org change occurs. This family of issues is sometimes referred to as “mutable identity” because the users can change their own “identity”.


In and of itself, the impact of this risk is limited.

But it allows a malicious actor to obfuscate their actions so that they are hidden under any cursory review, making it appear as if the illicit activity was done by someone else.

Context and Conclusions:

This risk is more about the coverup than the crime itself. However the real risk here is that attackers can act with near impunity because they are skating beneath the radar undetected and raising no red flags. Keep in mind that the default log retention in Okta is 90 days, so if an attacker is successful in hiding for 90 days, she is basically successful ad infinitum.

If an attacker is able to capitalize on this free movement, they can carry out a number of dangerous actions such as:

  • An attacker could pretend to be a valid actor making changes such as connecting an IdP or redirecting an existing one to go through a proxy. This could give them a persistent backdoor and the change will not be investigated because it will seem to come from a valid source. 
  • An attacker could also perform a sequence of actions to reproduce the state of the dashboard as it was before they performed a malicious action, granted that they have enough privileges. 

Step-by-Step Proof of Concept: 

  1. Log in to Okta and go to user settings  
  2. Edit your personal information to be that of the user you want to impersonate
  3. Perform a malicious logged action – e.g. an org change that shows up in the dashboard
  4. Edit your personal information back to normal
  5. The log / dashboard still shows the changed details unless you expand it fully to see the unique ID

See the screenshots below of actions performed by the user Gal Diskin who changed his own name in the logs:

Mutable Identity Log Spoofing

Expanding this:

Mutable Identity Log Spoofing 2

Expanding further:

Mutable Identity Log Spoofing 3

Expanding even further, we finally find out it was Gal who performed the actions:
Mutable Identity Log Spoofing 4

Recommendations for Okta Customers:

  • Apply monitoring to Okta to detect changes in configurations and the actual actions performed taken by users, especially the admins
  • Review logs to look for users who performed a name change and check each such change

Responsible Disclosure and Discussion

At a high level — we believe this should be a wake up call for the IAM industry and IdP vendors. It is essential that the necessary APIs and audit logs are enabled to allow security monitoring of the settings and activities within the IdPs and IAM tools in general.

Okta has very good security practices in many areas. We chose to study Okta because of their significant market adoption and the high-profile of the Lapsus$ breach earlier this year but we are sure similar issues exist in other IAM providers and are already working on the next ones.

Authomize is working in collaboration with Okta, as well as other IdP and IAM vendors we partner with, to enable better monitoring abilities. We believe that this will lead to a more secure future as IAM takes an increasingly critical role in modern cloud security.

If you are an IdP vendor and want to discuss this, feel free to reach out to us.

In light of our research, our recommendation is that organizations take a proactive approach to implement independent security solutions for their IAM tools that are capable of continuously monitoring and alerting on irregular or malicious activity like the changes described here above. 

If your organization is ready to take that approach, Authomize offers a free assessment to analyze and determine your exposure to the risks detailed above. 

To sign up for a free assessment, or to hear more about the Authomize Cloud Identity and Access Security Platform, please fill in your details and we will be in touch with you shortly. 

FREE Risk Assessment

Join our FREE Assessment to:

  • Detect if your Okta is configured securely
  • Assess if you have likely been impacted by these risks
  • Establish a secure IdP posture

Next read

Solution Brief

Learn how Authomize's solution is changing the way companies are managing authorizations