Okta, a prominent supplier of solutions for identity and access management, has disclosed that over the last several weeks, its clients have been the victim of a series of sophisticated social engineering attacks.
Okta’s security team conducted a study and found that threat actors are using social engineering techniques to obtain access to privileged accounts, in particular accounts with Super Administrator capabilities. The attackers are successful in convincing the employees at the IT help desk to reset all of the Multi-factor Authentication (MFA) factors that have been registered by highly privileged users.
Once an attacker has gained access to a privileged account, the next step for them is to misuse lawful identity federation capabilities by leveraging their penetration of highly privileged Okta Super Administrator accounts. This gives the attacker the ability to impersonate people inside the compromised company.
Single sign-on access may be obtained from a trustworthy “source” identity provider using Okta’s inbound federation, which connects to a “target” identity provider. The attackers are first creating their own fake identity provider to pose as the source, and then they are altering the username parameter to match a genuine user in the company that is the target of the attack. They are able to impersonate legitimate users and access apps inside the target company because to this vulnerability.
Tactics, Techniques and Procedures
Okta Security has found a pattern of suspicious behavior that includes the following:
Prior to phoning the IT service desk at a targeted organization and demanding a reset of all MFA factors in the target account, threat actors seemed to either a) have credentials to privileged user accounts or b) be able to influence the delegated authentication flow through Active Directory (AD). Either way, they were able to get access to the target account. In the instance of Okta customers, the threat actor specifically targeted individuals who were given access equivalent to Super Administrator.
In order to access the user account that had been hacked, the threat actor would employ anonymizing proxy services, as well as an IP and device that were not previously linked with the user account.
Compromised Super Administrator accounts were used to provide greater rights to other accounts and/or reset enrolled authenticators in existing Administrator accounts. This was done by assigning higher privileges to other accounts. The malicious actor was responsible for removing some authentication policy rules requiring a second factor in certain instances.
It was discovered that the threat actor was setting a second Identity Provider to function as a “impersonation app” so that it could access apps included inside the compromised Organization on behalf of other users. This second Identity Provider, which the attacker also controls, would function as a “source” IdP in an inbound federation relationship (also known as “Org2Org”) with the target organization.
The threat actor changed the username parameter for targeted users in the second “source” Identity Provider, such that it matched a genuine user in the compromised “target” Identity Provider. This manipulation took place from this “source” Identity Provider. This made it possible to employ single sign-on, or SSO, while logging into apps inside the target IdP in the context of the targeted user.
According to Okta, this particular kind of attack exhibits “novel methods of lateral movement and defense evasion” that have not been observed before.
The organization has offered its clients with a number of tips for protecting themselves against these kinds of attacks. These include imposing phishing-resistant multi-factor authentication (MFA), banning privileged accounts, mandating re-authentication for administrative consoles, and monitoring unusual administrative activities.
How to protect
Protect sign-in processes by requiring phishing-resistant authentication using Okta FastPass and FIDO2 WebAuthn.
It is necessary to configure Authentication Policies, also known as Application Sign-on Policies, to demand re-authentication “at every sign-in” in order to get access to privileged apps such as the Admin Console.
If you are going to use self-service recovery, make sure that you start the recovery process using the most secure authenticator that is currently available (Okta Verify or Google Authenticator), and restrict recovery flows to only trustworthy networks (by IP, ASN, or geolocation).
Help desk employees’ usage of Remote Management and Monitoring (RMM) tools should be reviewed and consolidated, and the execution of any further RMM tools should be blocked.
Help desk identity verification procedures should be strengthened by using a mix of visual verification, delegated Workflows in which helpdesk workers issue MFA challenges to authenticate a user’s identity, and/or Access Requests that need permission by a user’s line manager before factors can be reset. All of these methods should be used in conjunction with one another.
End-user alerts for New Device and Suspicious Activity should be enabled and tested at this time.
It is important to review and restrict the usage of Super Administrator Roles. Privileged access management (PAM) should be implemented for Super Administrator access. Custom Admin Roles should be used for maintenance duties, and high-risk jobs should be delegated.
Dedicated administrative policies should be enforced. – It is necessary to demand that administrators sign in using controlled devices and phishing-resistant multi-factor authentication (Okta FastPass, FIDO2 WebAuthn). Restriction should only be allowed in trustworthy Network Zones, and access should be denied to anonymizing proxies.
Even while social engineering is still one of the most common attack vectors, the harm that can be done by compromised credentials may be mitigated by adhering to security best practices such as least privilege and multi-factor authentication. This incident underscores the necessity of protecting and monitoring highly privileged accounts that act as gateways to an organization’s most sensitive systems and data in order to prevent unauthorized access to those systems and data.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.