Okta announced last week that their customers have been under a well coordinated attack targeting their highly privileged admin accounts in an effort to impact their identity infrastructure and downstream applications.
In their post, Okta stated that:
In recent weeks, multiple US-based Okta customers have reported a consistent pattern of social engineering attacks against 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.
You can read their full post here.
Any organization with concerns that they may be impacted by this campaign can reach out to Authomize for a free check up of your Okta environment.
Identity Federation Abuse in the Wild
What really stood out in this incident was the attackers’ abuse of the identity federation features, wherein they succeeded in adding their own identity source to their target’s Okta tenant, allowing them to impact privileges in the downstream Okta tenant and subsequent applications.
This is a real world case of an Org2Org attack, leveraging the target’s identity infrastructure against them to:
- Elevate privileges for their own accounts and others
- Compromise the integrity of the IdP’s trust relationships
- Remove Multi-factor Authentication from accounts
- Impersonate legitimate users across the organization via the Hub & Spoke architecture
- Access downstream accounts
Authomize identified these risks pertaining to the Hub & Spoke architecture last year in a blog post, along with risks of clear text password dumping.
Establishing Stealthy Persistence
Along with the risks associated with the attacker adding their own malicious IdP list above, it is also an effective method for achieving persistence. This is because if the addition of the new IdP is not detected, then the attacker will be able to keep making changes in your Okta tenant.
The impact is that he can then login as any user he wants at any time, regardless of changes to account login credentials, so long as the IdP stays connected.
What we are seeing here is not old fashioned persistence. It is continuous access to every account in every application throughout your organization. Even after the blue team is sure that they have booted the attacker out.
Once the attacker has achieved admin access in your Okta, they have numerous ways to keep their hooks. Authomize has found at least five different proven methods. One way is for the attacker to make an API key, ideally one that is being legitimately and actively used so that the blue team is unlikely to get rid of it out of fear of breaking an important business function. By controlling this key, they can then rely on the API to get around authentication and maintain access.
What is also interesting here is that according to Okta’s reporting, the attackers are also using Microsoft Active Directory as part of their operation, using it as another identity source that is exceedingly difficult for the target’s Okta admins to gain the necessary visibility over.
3 Takeaways
The reporting here is still early, but security teams should take this as a learning opportunity. Here are a few of our immediate takeaways.
Attackers are Targeting Identity Infrastructure
Everyone from criminal groups to APTs are targeting the identity infrastructure as their preferred way to make their breach. Who needs an expensive 0day when you can just pick up privileged credentials for a couple of bucks online?
This case is just the latest in a long line of attacks in the past few years. Think Lapsus$ attacking Uber and Okta as well as APT29 going after SolarWinds, where the attackers get around authentication and are then able to make their own changes within the IdP that enable them to compromise your assets.
Once they are in your IdP, they own the keys to the kingdom, so expect this trend to continue unabated.
Okta Needs to be Monitored
Okta, like all other identity and access management (IAM) systems, is identity infrastructure that needs to be monitored. Just like you need security monitoring for your endpoint, network, and cloud, the same is true for your identity infrastructure as well. The need for security solutions for your Active Directory has been understood for a while, so why should your Okta be any different?
While Okta does produce logs, these are insufficient for detecting active threats in real-time and can themselves be changed since they are mutable.
Identity Threat Detection and Response (ITDR) solutions are the only way to effectively protect IdPs, and only Authomize has the subject expertise of Okta-specific risks to mitigate against exploitation.
Be Prepared to Defend Post-Authentication
Social engineering will almost certainly find a way into an organization, and techniques like MFA bombing, or simply disabling MFA by convincing someone to do so.
What you can do is use ITDR to better inform tools like Conditional Access that add friction to the authentication process, triggering MFA, asking the user to log back in, or fully blocking them if they meet a certain set of risk criteria. Authomize automatically pushes identity contextual data to Conditional Access, providing valuable insights to create the right level of security without unnecessary friction that slows down work.
But even these measures are not silver bullets, so we need continuous monitoring and detection of activities in post-auth to achieve a reliable level of defense in-depth.
Secure Your Okta Now
Authomize’s agentless ITDR platform enables organizations to stop account takeover and privilege escalation attacks.
In this case, customers would be able to detect these attacks using our security policies that continuously monitor Okta for incidents like:
- New/changes to IdP configurations
- Session hijacking
- User impersonation
- Changes to privileges
- Creation of new users
- Deletion of admins
- Configuration changes
- Misconfigurations
We then automate responses, alerting users to take action and security teams with identity data that shortens their time to response and remediation.
Contact us to learn more about our Identity Security solutions or if you are concerned that you may have been impacted by this campaign and we will be happy to assist you.
