Threat actors are using social engineering to convince IT desk personnel to reset multifactor authentication (MFA) for highly privileged Okta enterprise accounts, gaining access to the cloud-based identity access management (IAM) service and moving laterally through targeted networks from there.
Okta is a cloud-based, enterprise-grade IAM service that connects enterprise users across applications and devices, and it’s used by more than 17,000 customers globally. While it was built for cloud-based systems, it also is compatible with many on-premises applications.
US-based customers of Okta have reported a “consistent pattern” of “cross-tenant impersonation” attacks in recent weeks, with the actors targeting users assigned with “Super Administrator” permissions, the company revealed in a recent blog post.
“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,” according to the post, attributed to Okta’s Defensive Cyber Operations.
The hackers then access compromised accounts using anonymizing proxy services and an IP and device not previously associated with the user account “to abuse legitimate identity federation features that enabled them to impersonate users within the compromised organization,” according to the post.
Hacker activities included the assignment of higher privileges to other accounts; a reset of enrolled authenticators in existing admin accounts; and, in some cases, the removal of second-factor requirements from authentication policies. These allow attackers to move laterally across enterprise cloud-based networks and engage in other nefarious activities.
Manipulating Identity Access
Threat actors in the attack abused a feature in Okta called Inbound Federation, which allows access to applications in a target Identity Provider (IdP) if the user has successfully authenticated to a source IdP.
The feature, which also can also be used for just-in-time provisioning of users, is one used “to save months off mergers, acquisitions and divestitures,” according to the post. It’s also popular with large organizations that require central controls or who want to globally provision one set of applications, while also providing autonomy to individual divisions for their own policies and apps.
Given how much power someone with access to this feature has, it’s limited to users with the highest permissions in an Okta organization, defined as a Super Admin or Org Admin. One of these admins also can delegate this role to a “Custom Admin” to reduce the number of people with Super Admin privileges in large, complex environments, according to the post.
In the attacks, Okta observed the actors configuring a second IdP to act as an “impersonation app” to access applications within the compromised organization on behalf of other users. This second IdP acts under attackers’ control as a “source” IdP in an inbound federation relationship with the target.
From the source IdP, threat actors manipulated the username parameter for targeted users in the second “source” IdP to match a real user in the compromised “target” IdP. This enabled them to use single sign-on to access applications in the target IdP as the targeted user.
Protecting Access to Users With High Privileges
The attacks highlight why it’s important to protect access to highly privileged accounts in IAM solutions, according to Okta, which made a slew of recommendations for users to better secure these accounts in their IAM deployments. Indeed, closing the permissions gap across multiple workforces is a common issue in enterprise cloud environments.
Okta advises customers to restrict the use of highly privileged accounts, apply dedicated access policies for administrative users, and monitor and investigate any suspicious use of functions reserved for privileged users.
Enterprises that use Okta also can configure the application’s Authentication Policies for access to privileged applications — including the Admin Console — to require reauthentication “at every sign-in” to better secure their environments.
Moreover, to prevent hackers from targeting help-desk personnel to gain access to accounts, Okta recommended that organizations strengthen help desk identity verification processes using a combination of visual verification, delegated Workflows in which help-desk 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.
Organizations also should review and limit the use of Super Admin roles, implementing only privileged access management for them. According to Okta, they should use Custom Admin roles for maintenance tasks and to create help desk roles with the least privileges required, and to constrain these roles to groups that exclude highly privileged administrators.
- SEO Powered Content & PR Distribution. Get Amplified Today.
- PlatoData.Network Vertical Generative Ai. Empower Yourself. Access Here.
- PlatoAiStream. Web3 Intelligence. Knowledge Amplified. Access Here.
- PlatoESG. Automotive / EVs, Carbon, CleanTech, Energy, Environment, Solar, Waste Management. Access Here.
- PlatoHealth. Biotech and Clinical Trials Intelligence. Access Here.
- ChartPrime. Elevate your Trading Game with ChartPrime. Access Here.
- BlockOffsets. Modernizing Environmental Offset Ownership. Access Here.
- Source: https://www.darkreading.com/cloud/hackers-target-high-privileged-okta-accounts-via-help-desk
