Okta for Red Teamers — Perimeter Edition

This article by Nick Vangilder and Dave Thomas is intended to be complimentary to the amazing work of Adam Chester (@_xpn_) over at TrustedSec who recently wrote a fantastic blog post explaining multiple, post-exploitation techniques related to Okta. We highly recommend that you check it out, here: https://trustedsec.com/blog/okta-for-red-teamers.

Inspired by his work on the post-exploitation side, we thought it could fun to back up further in the attack chain and explore some of the key activities and techniques that we’ve employed when targeting Okta for initial access.

In terms of content, we will cover the following in our article:

• Strategies for identifying a company’s Okta portal(s)
• Phishing infrastructure and hosting considerations
• An Evilginx phishlet for Okta
• Suggestions for distributing phishing links
• Replaying captured session cookies
• Okta behavioral detection policies and potential evasion technique
• OPSEC considerations for red team
• Prevention and detection recommendations for blue team

Locating your target’s production Okta portal

As a starting point, and this is probably painfully obvious (sorry), you will need to identify your target’s Okta portal. You will need this for your phishing kit later on. Locating a company’s Okta portal can be simple as visiting “companyname”.okta.com within a web browser. If you see your target company’s logo or some type of branding specific to your target (logo, background image, colors, etc.), you’ve probably found it. If you see a generic page without any branding like the one below, you may not have the right portal and should keep looking.

Your target’s Okta portal could also have a unique name that’s difficult to guess, such as companyname-8675.okta.com. In these instances, there is also likely a CNAME record in your target company’s DNS like okta.companyname.com that points to this unique name. While this complicates things, not at all is lost. To work around this possibility, try visiting subdomains on your target company’s domain within a web browser. If your target company’s domain is companyname.com, consider the likelihood that your target company’s domain will have common subdomains like “remote”, “vpn”, “mail”, “salesforce”, etc as DNS A records. Odds are high that you’ll eventually find a subdomain that redirects to the company’s Okta portal as part of the logon process for whatever service you locate at a particular subdomain. Once the redirect occurs, check to see if you’re at an Okta domain or a domain belonging to your target (e.g., companyname.com). If you’re at something like okta.companyname.com, there is more work to be done. To discover the hostname on the Okta side, open a terminal and perform a nslookup on okta.companyname.com. This should expose the hostname within Okta’s DNS, as pictured below:

If the hostname reads as companyname.customdomains.okta.com, you can remove “customdomains”. This will leave you with the with the Okta hostname for your target that you can visit within a web browser to confirm.

Locating your target’s test Okta portal

Sometimes, companies will have an Okta test portal available where various Okta configurations are tested before they are pushed to production environments. These test portals may be configured similarly or differently than the company’s production portals, and may have limited features compared to their production counterparts.

Test portals may not be monitored as heavily or be subject to Okta behavioral detection polices by an organization. While there are a lot of variables at play that can drive the value in finding a company’s Okta test portal, it can be a good place to gain insights into a company’s Okta configurations (if you can gain access). In some instances, a test Okta portal may be configured for MFA; however, users may not have enrolled yet. So, if you’re in possession of credentials, you may be able to enroll a new authenticator on their account upon first logon to the test portal.

Hosting your phishing kit at Azure

When it comes to hosting any type of phishing infrastructure or phishing kit, it’s best to avoid custom, low-trust domain names whenever possible. Ideally, you’d always use trusted, legitimate sites. However, when it comes to reverse proxy phishing frameworks or phishing kits, you’re often forced to use a custom domain name. There’s a good reason for this.

Typically, reverse proxy phishing frameworks require a custom domain name (e.g., customdomain.com) and a very specific DNS configuration. This is because the legitimate site being proxied (e.g., example.com), may need to communicate with additional websites as part of the login workflow (e.g., login.example.com, auth.example.com, sso.example.com, etc.). When this occurs, additional subdomains are dynamically generated by the reverse proxy phishing framework for the custom domain name to match the examples listed above for the legitimate site. For example, login.example.com becomes login.customdomain.com while auth.example.com becomes auth.customdomain.com and sso.example.com becomes sso.customdomain.com.

When it comes to Okta’s login workflow, at least at the time of this writing, the login workflow is very straightforward. As a result, you can host your reverse proxy phishing framework (we’ll be using Evilginx) at Azure using an Azure-provided hostname. This eliminates the need for a custom domain name and the challenges that come with newly registered, non-seasoned domain names.

We’re not going to cover all of the steps for setting up a VM at Azure; however, at a minimum, you will need to spin up an Azure VM and define a subdomain for your VM as pictured below:

In our example above, we’ve selected “companyname” as the subdomain, but you should select something you think your target would expect to see that would reduce suspicion and allow you to blend in with other traffic.

Using a custom Okta phishlet for Evilginx

Now that you’re in possession of the target company’s Okta hostname and have selected a hosting provider, you can proceed with setting up your reverse proxy phishing framework to capture session cookies. We’ve opted to use Evilginx (https://github.com/kgretzky/evilginx2), authored by the amazingly talented Kuba Gretzky (@mrgretzky). It is assumed that the reader can perform a base install of Evilginx on their own, so we’ll only touch on a few key points here.

First, and probably most importantly, you will need a “phishlet” for Evilginx that targets Okta. As part of this blog post, we’re including one that you’re welcome to use. Assuming your target company’s Okta tenant’s hostname is companyname.okta.com, your phishlet should look like this:

author: 'nickvangilder'
min_ver: '3.0.0'
proxy_hosts:
  - {phish_sub: 'companyname', orig_sub: 'companyname', domain: 'okta.com', session: true, is_landing: true, auto_filter: true}
sub_filters:
  - {triggers_on: 'companyname.okta.com', orig_sub: '', domain: 'companyname', search: 'companyname', replace: '{hostname}', mimes: ['application/ion+json']}
  - {triggers_on: 'companyname.okta.com', orig_sub: '', domain: 'companyname.com', search: 'https.*\.okta\.com', replace: 'https://{hostname}', mimes: ['text/html']}
auth_tokens:
  - domain: 'companyname.okta.com'
    keys: ['idx']
credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)'
    type: 'json'
  password:
    key: ''
    search: '"passcode":"([^"]*)'
    type: 'json'
login:
  domain: 'companyname.okta.com'
  path: '/login/login.htm'

Save the above text as okta.yaml and place within Evilginx’s “phishlets” directory:

Note: Other Okta phishlets do exist; however, they may contain entries for multiple “proxy_hosts”. While these phishlets will work in a general sense, they will not work when Evilginx is being hosted on an Azure VM using an Azure-provided DNS name. If you try this, you will see that Evilginx will attempt to generate certificates for all of the hosts defined under “proxy_hosts”. Because there is only one subdomain defined on your Azure VM, it will fail and generate errors. Unfortunately, Microsoft Azure only allows one subdomain per VM.

Secondly, and in this same vein, when hosting Evilginx at Azure, you need to ensure that the hostname is set correctly. For example, if your Azure VM’s FQDN is “companyname.westus3.cloudapp.azure.com”, you must specify the hostname within Evilginx as “westus3.cloudapp.azure.com” as pictured below:

Next, enable your newly created phishlet, generate your phishing lure, and prepare to distribute the link to your target.

Sending Okta-themed phishing links via text message

Admittedly, this technique isn’t exactly Okta-specific; however, leveraging it can definitely increase your chances of success when targeting Okta — especially when we consider the number of valid scenarios where users will receive legitimate text messages from Okta on their personal device.

It’s no secret that many companies have invested heavily in email security solutions, MDM solutions, web proxies, and on demand VPNs within MDM to force content through the company’s corporate web proxy for inspection. So, if you’re emailing your Okta-themed phishing links to your targets and they are opening them on their phone (or even their computer), be ready to bump up against those controls. For example, when a user clicks on a link from their phone within a company-managed application like Outlook, Outlook will open the link within the company-managed browser (e.g., Edge). In the background, Edge will likely establish a VPN connection to the company’s network which forces the content to flow through the company’s web proxy for inspection.

You can often avoid all of these controls by sending an Okta-themed phishing link to your target via text message. When your target clicks the link from their text messaging application, it will likely open in the phone’s default browser. Below is a basic example of an Okta-themed phishing message:

ACTION REQUIRED: Acme Inc’s Security Operations Center has detected suspicious activity on your account. As a security precaution, your account has been locked. Please login at your earliest convenience to unlock and verify your account: https://companyname.westus3.cloudapp.azure.com/OktaVerify

If clicked, your target should be presented with your target company’s legitimate Okta login page that is actively being proxied by Evilginx, similar to the below:

As previously mentioned, the page will likely be loaded in your target’s default phone browser (if the phishing link wassent to your target via SMS text) — so, it likely will not be subjected to the company’s security controls and monitoring solutions. Thus, subsequent activity by the target interacting with your Evilginx instance won’t be collected by a SIEM solution for further analysis or trip alerts from potential detections that may be in place. This is a major benefit that makes sending phishing lures via SMS text (“smishing”) an attractive attack vector for threat actors.

Replaying a captured session cookie

After your target has entered their credentials and stepped through the MFA approval process, you should be in possession of their credentials and an Okta session cookie. Below is an example of a successfully captured username, password, and token:

We can verify the presence of an Okta session cookie within Evilginx by typing the command “sessions” and checking for any captured tokens. Then, we can pull the Okta session cookie by entering the command “sessions xx” where xx is replaced with the appropriate session id.

You can leverage various browser extensions to replay a captured session cookie, such as “EditThisCookie” (https://www.editthiscookie.com/), to gain access to your target’s Okta dashboard or Okta-protected applications directly — more on this below. Simply copy the entire cookie and import it into an extension like “EditThisCookie” as depicted below. Don’t forget to click the green check box.

Once entered, you would visit the URL of your target company’s Okta dashboard, or direct URL of an Okta protected application. In our example, we replayed a captured Okta session token and gained access to our target company’s Workday application:

Background on Okta behavioral detection policies

When it comes to protecting Okta, a key control that doesn’t seem widely understood and discussed is Okta’s behavioral detection policies. Okta’s Behavior Detection Engine analyzes patterns of user behavior to create profiles of typical patterns based on previous activity. This information enables administrators to configure sign-on policy rules that respond to changes in user behavior (source: https://help.okta.com/en-us/content/topics/security/proc-security-behavior-detection.htm). For example, if an Okta access cookie has been stolen and replayed by an adversary, a behavioral detection policy (if enabled and properly implemented) can check to see if the IP address that is replaying the cookie is different from the IP for which it was issued. If the answer is “yes”, the policy could enforce another round of MFA (step-up authentication). This is just one example. Other behavioral detections can be configured based around location, device changes, and more. Ideally, hardware security tokens (FIDO2) or Okta FastPass would lessen the need for behavioral detection policies in the first place; however, neither is yet widely adopted. Until then, and if your company leverages Okta as identity provider, behavioral detection policies are an excellent compensating control that should be considered by defenders.

Evading behavioral detection policies

Unless it’s been disclosed in advance, you probably won’t know if behavioral detection policies have been implemented until you encounter them. If you have replayed an Okta access token expecting to see the Okta dashboard but immediately see a screen that looks like the below example followed by a series of redirects, you are likely encountering Okta’s behavioral detection policies. Of note, just because you are bumping up against a behavioral detection, it doesn’t necessarily mean your access token has been automatically revoked — it just depends. If the company has a mature detection and response function, you may have tipped off the SOC, and an analyst may be investigating the situation.

There is a possibility that Okta is configured in a way (maybe by default) where behavioral detection policies only apply to the main Okta dashboard. The main dashboard is where you “land” once you’ve successfully authenticated. It looks like this (without the red boxes):

One potential way to bypass Okta’s behavioral detection policies is to simply avoid the main Okta dashboard altogether and target Okta applications directly (this would be the applications in the above screenshot that are obscured by red boxes). If you are in possession of an Okta access token, instead of replaying the token at the main Okta login page of your target company, you would replay the token at the application-specific Okta URL.

To do this, you first need to know the application URL. Obviously, it can be found within the dashboard; however, you (presumably) will not have access to the dashboard and must find the Okta URLs via other methods. One way, and there may be better alternatives, is to research your target and identify web services that are configured with Okta as the identity provider for your target company.

For example, based on your LinkedIn reconnaissance efforts, you may determine that your target company utilizes a popular file sharing service named Box. So, you browse to companyname.box.com and are presented with something like this:

After you click “continue” (in this example), you would proceed through a series of redirects and eventually arrive at your target company’s Okta login portal. Now, in the process of that happening, you should see the Okta-specific application URL in your web browser or in your web browser’s history. It should look something like this:

https://okta.companyname.com/app/okta-tenant-name-here_boxboxp_1/exk7cp7--redacted--owzXlr7EoD4d6/sso/saml

or

https://companyname.okta.com/app/okta-tenant-name-here_boxboxp_1/exk7cp7--redacted--owzXlr7EoD4d6/sso/saml

Now, replay your captured access token in the same way as you would against the dashboard. If successful, you have bypassed behavioral detection policies and identified a control gap that should be addressed.

While not especially technical and certainly not groundbreaking by any stretch, we do hope that you find some of our insights and techniques helpful. In parting, we want to leave our offensive friends with a few OPSEC considerations and our defensive counterparts with some prevention and detection guidance (from a red team perspective).

OPSEC considerations for red teams

The below list is not intended to be exhaustive, and every situation and target environment is unique. This list is merely intended to cover the basics and get you started. If you have additional OPSEC considerations, feel free to add them to the comments.

1. Be careful replaying captured access tokens from popular anonymizer proxies and VPN services. Mature detection and response teams will alert on this, and it may burn you. A better option is to spin up a VPS in the geographical region of your target and setup your own HTTP proxy, like Squid. Installing and configuring Squid is simple and can be accomplished in under 10 minutes. You can even run Squid on the same server as your reverse proxy and quickly reply access tokens from the same IP for which the cookie was generated, which can help with avoiding detection.
2. When replaying an access token, use the same user-agent string if possible. Evilginx logs this in the session data, and you can manually set a user-agent string within Firefox. When coupling with replaying your access token through an HTTP proxy, this can add legitimacy and help you avoid detection.
3. Be careful replaying captured access tokens from separate users from the same IP address. This is also something that a more mature detection and response team will catch.
4. Be careful replaying captured access tokens against the Okta dashboard. If you’re trying to be stealthy, first target Okta-applications directly and avoid the dashboard until you know it’s safe or are out of other options.
5. If you are targeting users who will be visiting your Evilginx server (via clicking on phishing links) from a corporate proxy and you know the IP address or IP range, consider blocking all other traffic other than that IP or IP range. Otherwise, make sure to enable Evilginx’s blacklist feature (command: ”blacklist unauth”). This will block and blacklist the IP of every incoming request which doesn’t point to a valid lure URL of an enabled phishlet. This is a default setting.
6. When using Azure VMs to host Evilginx (and without a custom domain), Evilginx is relatively quick and easy to setup. As such, consider rolling multiple Evilginx servers with the assumption that some of them are likely to get burned by the blue team. When they get burned, just move on to the next. Also, if you’re running a large phishing campaign, you will likely want multiple Evilginx servers anyway. If the your phishing host/link is the same for every target, blue team will make short work of blocking you and impeding your progress.

Prevention guidance for blue teams

1. If possible, if you have an application that contains sensitive information, make sure that the ability to login to that application is restricted to certain IP addresses or IP ranges. That way, if an adversary DOES gain access to an Okta access token, they will still be prevented from accessing the application due to the IP restrictions at play.
2. Ensure that your Okta configuration is not preventing behavioral detection policies from kicking in on individual applications. You want/need behavioral detections on both the dashboard AND ALL individual applications.
3. If possible, provide all users with FIDO2 hardware security tokens and only allow MFA using hardware tokens or Okta FastPass. Other methods of MFA are vulnerable to phishing attacks. If you cannot do this for all users, at LEAST do this for super users, and definitely do not allow logins to your Okta Admin portal without hardware MFA or Okta FastPass.
4. Ensure session expiration policies are of a reasonable length for your organization to limit the effectiveness of session hijack attacks. Two weeks is probably too long, but 20 minutes is probably too short. Consider what is best based on your users and unique environment.

Detection guidance for blue teams

1. Monitor for instances where multiple users have attempted login from the same IP address (https://research.splunk.com/application/19cba45f-cad3-4032-8911-0c09e0444552/)
2. Monitor for mismatch between source IP and response IP for Okta Verify push request (https://research.splunk.com/application/8085b79b-9b85-4e67-ad63-351c9e9a5e9a/)
3. Monitor for multiple failed attempts to access Okta applications (https://research.splunk.com/application/1c21fed1-7000-4a2e-9105-5aaafa437247/)
4. Monitor for suspicious use of a session token (https://research.splunk.com/application/71ad47d1-d6bd-4e0a-b35c-020ad9a6959e/)
5. Monitor for when Risk Score threshold is exceeded (https://research.splunk.com/application/d8b967dd-657f-4d88-93b5-c588bcd7218c/)
6. Monitor for MFA bombing or MFA fatigue attacks (https://sec.okta.com/everythingisyes and https://research.splunk.com/application/97e2fe57-3740-402c-988a-76b64ce04b8d/)
7. Monitor for geographically improbably logons and login attempts (https://research.splunk.com/application/7594fa07-9f34-4d01-81cc-d6af6a5db9e8/)
8. Monitor for instances where a user has rejected multiple Okta pushes a specified time window (https://research.splunk.com/application/d93f785e-4c2c-4262-b8c7-12b77a13fd39/)
9. Monitor for potential password spraying attacks against Okta (https://research.splunk.com/application/25dbad05-6682-4dd5-9ce9-8adecf0d9ae2/)
10. Monitor for new device enrollments on all or select accounts (https://research.splunk.com/application/bb27cbce-d4de-432c-932f-2e206e9130fb/)