WebFi 4 Okta customers hit by campaign that gave attackers super admin control

Authentication service Okta said four of its customers have been hit in a recent social-engineering campaign that allowed hackers to gain control of super administrator accounts and from there weaken or entirely remove two-factor authentication protecting accounts from unauthorized access.

The Okta super administrator accounts are assigned to users with the highest permissions inside an organization using Okta’s service. In recent weeks, Okta customers’ IT desk personnel have received calls that follow a consistent pattern of social engineering, in which attackers pose as a company insider in an attempt to trick workers into divulging passwords or doing other dangerous things. The attackers in this case call service desk personnel and attempt to convince them to reset all multi-factor authentication factors assigned to super administrators or other highly privileged users, Okta said recently.

Two-factor authentication and multi-factor authentication, usually abbreviated as 2FA and MFA, require a biometric, possession of a physical security key, or knowledge of a one-time password in addition to a normally used password to access an account.

Targeting users with the highest of permissions

When successful, the attackers used the compromised super administrator accounts to assign higher privileges to other accounts and/or reset enrolled authenticators in existing administrator accounts. In some cases, the threat actor also removed second-factor requirements from authentication policies. The threat actor also assigned a new app to access resources within the compromised organization. These “impersonation apps” were created after enrolling a new identity provider, which customers integrate into their Okta account.

“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,” Okta officials wrote. “It can also be delegated to a Custom Admin Role to reduce the number of Super Administrators required in large, complex environments. These recent attacks highlight why protecting access to highly privileged accounts is so essential.”

An Okta representative, citing company Chief Security Officer David Bradbury, said in an email that four customers were affected within the three-week period from July 29, when the company began tracking the campaign, through August 19. Bradbury didn’t elaborate.

Attacks such as the ones here are serious because authentication companies often hold or safeguard multiple high-privileged credentials inside sensitive organizations. Last year’s breach of 2FA provider Twilio, for instance, allowed the attackers to hack at least 136 of the company’s customers.

As was the case in that campaign, the attackers targeting Okta customers are well-resourced. In some cases, they already possessed passwords to the high-access accounts. In others, they were able to change the authentication flow for customers’ Active Directory, which is federated through Okta. To complete the compromise, the attackers first needed to trick customers into lowering the MFA protections standing in their way.

The Okta post summarized the attacker techniques, tactics, and procedures this way:

• The threat actor would access the compromised account using anonymizing proxy services and an IP and device not previously associated with the user account.
• 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.

The post provided a list of IP addresses and other traces left behind by the attackers. Okta customers can use the indicators of compromise to detect if they have been targeted in the same campaign. Okta didn’t identify the four affected customers or say what attackers could do once they had access to the customer resources. Based on the hack of Twilio and the resources of the attackers, it wouldn’t be surprising if the number of affected customers rises in the coming days.