Oktajacking

We have spoken previously about SAMLjacking and poisoned tenants, particularly with regard to clever phishing attacks aimed at gaining initial access to some cloud identities. Today, we’ll look at how Okta’s AD synchronization is pretty much SAMLjacking on steroids. We’ll also consider how it can be used as a stealthy watering-hole style lateral movement attack too.

To be clear, this isn't a vulnerability in Okta that circumvents a security boundary and needs to be patched. This is offensive use of a product feature, the SaaS version of living off the land (LOTL). Let's call it living off the cloud (LOTC).

What is SAMLjacking?

SAMLjacking is where an attacker makes use of SAML SSO configuration settings for a SaaS tenant they control in order to redirect users to a malicious link during the authentication process. This can be highly effective for phishing, as the original URL will be a legitimate SaaS URL and users will provide their credentials because they’re expecting that as part of the login process. 

What is a poisoned tenant?

Poisoned tenants involve an adversary registering a tenant for a SaaS app they control and tricking target users to join it, often using built-in invite functionality. The end goal is to have some target users actively using a tenant you (as the adversary) control.

What is Oktajacking?

This is a name I’ve been using to refer to using Okta to do the credential capture/keylogging for you, without needing to have your own malicious domain hosting your malicious SAML server. This is even more effective than regular SAMLjacking as the user will only ever see legitimate SaaS domains, with the subdomain being the attacker-chosen part (e.g. https://attacker-tenant.okta.com).

However, the awesome research that underpins this technique was conducted by Adam Chester (@_xpn_) and is covered in his excellent article, Okta for Red Teamers. If you haven’t already read that, you absolutely should. 

Adam identified that if you compromise a Windows domain that’s linked to Okta and/or compromise an Okta admin account for an Okta instance linked to a Windows domain, you can use the Okta AD agent to capture credentials during logins. There’s lots more, but that’s the key part we’ll build upon for this article. 

This attack works because Okta forwards credentials from logins for accounts tied to AD to its own AD agent that runs on the target network. Then, Okta allows the agent to report back to them about whether the login should be successful or not. This enables an attacker who has compromised an AD agent, or is able to emulate one, to both monitor login credentials for Okta users and provide skeleton key-like functionality to authenticate to Okta as any user they like. 

The context of this in Adam’s article was primarily a traditional Windows domain compromise scenario where an attacker could use this method as a form of incredibly powerful domain-level persistence or to move laterally to other accounts. This is applicable in late-stage kill chain phases, where the attacker has already achieved a total organization-level compromise. 

So, how can this technique be leveraged earlier in the kill chain? We’ll consider the following two scenarios for this article:

• Oktajacking for initial access - directly phishing credentials via a valid Okta tenant we create

• Oktajacking for lateral movement - capturing credentials via a watering hole attack when having admin-level compromised a SaaS application in use by the target organization

Oktajacking for initial access

The most common way someone might attack Okta-protected organizations would be to conduct traditional phishing attacks hosted on an attacker-controlled domain that emulate an Okta login page. A great article to check out on this would be Nick Vangilder’s article, Okta for Red Teamers - Perimeter Edition. 

However, as with most phishing attacks this involves the use of a malicious domain to host the phishing server. Okta AD synchronization allows us to use legitimate Okta domains to do the phishing for us. This attack can catch out even the most security conscious users.

To do this, we set up an attacker-controlled Okta tenant as a poisoned tenant and configure it for AD integration, using Adam Chester’s python script to harvest credentials. This enables actual Okta-owned domains to be used in phishing attacks to target users. A careful attacker would likely use a tenant name similar to the target organization’s real Okta tenant name. This is incredibly powerful and is likely to be effective against even the most security conscious users. 

A few prerequisites and tweaks are required in order to make this attack successful:

• Import and activate accounts from AD that match the emails of users you want to target - this will ensure these emails are mapped to AD for authentication and cause Okta to send the credentials to the monitoring script.

• Make a small modification to the python script to accept any password as valid, rather than a specific skeleton key. 

• Modify the default authentication policy for Okta to allow single-factor password authentication for the target users - this will prevent them being prompted to use Okta Verify as part of the login process.

The goal for the last two actions above is to allow target users to authenticate legitimately and then redirect them elsewhere, while capturing their credentials. This is better achieved by having their first password accepted rather than them continually failing to authenticate, which may eventually raise alarm bells. 

In this case, we’ll use Okta’s bug bounty system as a test for our poisoned tenant, but in practice an attacker could set up a legitimate Okta tenant, pay for it and name it whatever they like. 

The end result is a legitimate Okta domain and login page that will capture credentials for the attacker, which can then be used in highly convincing phishing attacks. In this example, the following URL will capture credentials for us:

https://bugcrowd-oie-lukejennings-1.oktapreview.com/

Oktajacking for lateral movement

In both the previous section and our article on SAMLjacking, we focused on conducting highly convincing phishing attacks by sending URLs for legitimate SaaS domains that capture credentials. 

But what if we achieve an admin-level compromise of a SaaS app used by a target organization that authenticates via Okta already? How can we leverage that access to perform lateral movement?

We can change the SAML configuration in the compromised SaaS application to point to a different Okta instance that we control and then conduct the same credential capture attack we saw in the previous section. 

In other words, we can then authenticate to the target SaaS application as any user we like and also capture Okta credentials for all legitimate users also using that application without needing to send any phishing links. 

We’re going to use Datadog as a demo example for this - just because we need something real to target. To be crystal clear, this will work for basically any app that supports SAML. This is not a bug in SAML, or in Okta, or Datadog - it's the consequence of having privileged administrative access to an app, and the ability to change SSO configuration. To set up the attack, we need to first:

• Compromise the organization’s Datadog tenant at admin-level

• Create a malicious Okta tenant and connect it to an active directory instance with the same email domain as the target organization

• Create AD accounts for all users that will be targeted so they can be imported into Okta as AD account - in practice, it would be best to copy the list of users from Datadog and replicate this in AD and Okta

• Run Adam Chester’s python script to harvest credentials for Okta AD authentication and modify it to accept any password 

• Modify the Datadog SAML configuration to point to the malicious Okta tenant, instead of the original legitimate Okta tenant

• Sit back, relax, and watch the credentials coming in

Now we’ll explain what happens from the perspective of other users of the target organization’s Datadog tenant that has been compromised:

• Their Datadog session expires and they’re redirected back to the SAML login provider for re-authentication - in this case, to our malicious Okta tenant we have substituted for the real Okta tenant

• The user enters their credentials into the login page for our malicious Okta tenant. Our instance of Adam Chester’s AD synchronization script harvests the user’s login credentials.

• The user is already accustomed to using Okta to access Datadog, the Okta login page they are directed to is on a legitimate Okta domain and they haven’t clicked any links in emails/IM messages so there is no reason for suspicion.

• The modification we made to accept any credentials means the script returns true to Okta and causes Okta to accept the authentication attempt. This causes the user to be logged into the legitimate Datadog tenant again, where they can carry on their work, unaware they have just had their Okta credentials stolen.

The following video shows what a login attempt to Datadog looks like after the SAML configuration has been modified to point to our malicious Okta tenant. You can see how all the URLs observed are legitimate Datadog and Okta domains, any password will be accepted and harvested and the target user will be logged into the legitimate Datadog tenant successfully at the end.

This type of attack sits somewhere in the middle of the kill chain between the initial access phishing we covered in the previous section and the full active directory/Okta domain compromise Adam Chester covered in his article. In this instance, we are looking at leveraging a more limited admin-level compromise of a single SaaS application to extend our access much further. 

When an organization relies on SaaS apps, it’s likely there may be some apps that are not considered particularly security critical and also may have “admins” that are actually just members of non-technical teams in the business. An admin-level compromise of any SaaS application used by the organization can be used to conduct highly stealthy Okta credential capturing for all users. With those credentials, an attacker can expand their access and move laterally to other accounts and applications. 

Impact

Let’s take a step back and consider the key points of impact here:

• Attackers can send phishing links pointing to legitimate Okta domains and use those to capture credentials due to the way Okta AD synchronization works - this bypasses common user security training around checking domains are legitimate

• If an attacker compromises a legitimate SaaS tenant in use by an organization protected by Okta, they can modify the SAML configuration to point to their own malicious Okta tenant and thus capture credentials using the same method

• It would be extremely unlikely legitimate users would notice as it is part of the normal authentication flow, all domains observed would be legitimate SaaS and Okta domains, and they would be logged in successfully to the real SaaS tenant after entering their password

Conclusion

Okta is an identity management service that can help manage and protect access to a large number of applications used by an organization. However, due to the manner in which Okta AD synchronization works, it’s possible to use phishing links pointing to legitimate Okta domains to capture users credentials.

Additionally, admin access to any application in use with Okta needs to be carefully considered even if the application itself is not particularly sensitive. This is because a compromise of that application, or of a user account with admin access to it, can be used to modify the existing Okta SAML configuration to point to a malicious Okta tenant and conduct an extremely stealthy credential harvesting attack of all users of the application. 

Defenders should carefully monitor user access to Okta URLs that do not match their own legitimate tenant as it could be a sign of credential capturing attacks.