Okta Hardening
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
From an attackers perspective, this is super interesting as you will be able to see all the users registered, their email addresses, the groups they are part of, profiles and even devices (mobiles along with their OSs).
For a whitebox review check that there aren't several "Pending user action" and "Password reset".
This is where you find all the created groups in Okta. it's interesting to understand the different groups (set of permissions) that could be granted to users. It's possible to see the people included inside groups and apps assigned to each group.
Ofc, any group with the name of admin is interesting, specially the group Global Administrators, check the members to learn who are the most privileged members.
From a whitebox review, there shouldn't be more than 5 global admins (better if there are only 2 or 3).
Find here a list of all the devices of all the users. You can also see if it's being actively managed or not.
Here is possible to observe how key information such as first names, last names, emails, usernames... are shared between Okta and other applications. This is interesting because if a user can modify in Okta a field (such as his name or email) that then is used by an external application to identify the user, an insider could try to take over other accounts.
Moreover, in the profile User (default) from Okta you can see which fields each user has and which ones are writable by users. If you cannot see the admin panel, just go to update your profile information and you will see which fields you can update (note that to update an email address you will need to verify it).
Directories allow you to import people from existing sources. I guess here you will see the users imported from other directories.
I haven't seen it, but I guess this is interesting to find out other directories that Okta is using to import users so if you compromise that directory you could set some attributes values in the users created in Okta and maybe compromise the Okta env.
A profile source is an application that acts as a source of truth for user profile attributes. A user can only be sourced by a single application or directory at a time.
I haven't seen it, so any information about security and hacking regarding this option is appreciated.
Check in the Domains tab of this section the email addresses used to send emails and the custom domain inside Okta of the company (which you probably already know).
Moreover, in the Setting tab, if you are admin, you can "Use a custom sign-out page" and set a custom URL.
Nothing interesting here.
You can find here applications configured, but we will see the details of those later in a different section.
Interesting setting, but nothing super interesting from a security point of view.
Here you can find all the configured applications and their details: Who has access to them, how is it configured (SAML, OPenID), URL to login, the mappings between Okta and the application...
In the Sign On tab there is also a field called Password reveal that would allow a user to reveal his password when checking the application settings. To check the settings of an application from the User Panel, click the 3 dots:
And you could see some more details about the app (like the password reveal feature, if it's enabled):
Use Access Certifications to create audit campaigns to review your users' access to resources periodically and approve or revoke access automatically when required.
I haven't seen it used, but I guess that from a defensive point of view it's a nice feature.
Security notification emails: All should be enabled.
CAPTCHA integration: It's recommended to set at least the invisible reCaptcha
Organization Security: Everything can be enabled and activation emails shouldn't last long (7 days is ok)
User enumeration prevention: Both should be enabled
Note that User Enumeration Prevention doesn't take effect if either of the following conditions are allowed (See User management for more information):
Self-Service Registration
JIT flows with email authentication
Okta ThreatInsight settings: Log and enforce security based on threat level
Here is possible to find correctly and dangerous configured settings.
Here you can find all the authentication methods that a user could use: Password, phone, email, code, WebAuthn... Clicking in the Password authenticator you can see the password policy. Check that it's strong.
In the Enrollment tab you can see how the ones that are required or optinal:
It's recommendatble to disable Phone. The strongest ones are probably a combination of password, email and WebAuthn.
Every app has an authentication policy. The authentication policy verifies that users who try to sign in to the app meet specific conditions, and it enforces factor requirements based on those conditions.
Here you can find the requirements to access each application. It's recommended to request at least password and another method for each application. But if as attacker you find something more weak you might be able to attack it.
Here you can find the session policies assigned to different groups. For example:
It's recommended to request MFA, limit the session lifetime to some hours, don't persis session cookies across browser extensions and limit the location and Identity Provider (if this is possible). For example, if every user should be login from a country you could only allow this location.
Identity Providers (IdPs) are services that manage user accounts. Adding IdPs in Okta enables your end users to self-register with your custom applications by first authenticating with a social account or a smart card.
On the Identity Providers page, you can add social logins (IdPs) and configure Okta as a service provider (SP) by adding inbound SAML. After you've added IdPs, you can set up routing rules to direct users to an IdP based on context, such as the user's location, device, or email domain.
If any identity provider is configured from an attackers and defender point of view check that configuration and if the source is really trustable as an attacker compromising it could also get access to the Okta environment.
Delegated authentication allows users to sign in to Okta by entering credentials for their organization's Active Directory (AD) or LDAP server.
Again, recheck this, as an attacker compromising an organizations AD could be able to pivot to Okta thanks to this setting.
A network zone is a configurable boundary that you can use to grant or restrict access to computers and devices in your organization based on the IP address that is requesting access. You can define a network zone by specifying one or more individual IP addresses, ranges of IP addresses, or geographic locations.
After you define one or more network zones, you can use them in Global Session Policies, authentication policies, VPN notifications, and routing rules.
From an attackers perspective it's interesting to know which Ps are allowed (and check if any IPs are more privileged than others). From an attackers perspective, if the users should be accessing from an specific IP address or region check that this feature is used properly.
Endpoint Management: Endpoint management is a condition that can be applied in an authentication policy to ensure that managed devices have access to an application.
I haven't seen this used yet. TODO
Notification services: I haven't seen this used yet. TODO
You can create Okta API tokens in this page, and see the ones that have been created, theirs privileges, expiration time and Origin URLs. Note that an API tokens are generated with the permissions of the user that created the token and are valid only if the user who created them is active.
The Trusted Origins grant access to websites that you control and trust to access your Okta org through the Okta API.
There shuoldn't be a lot of API tokens, as if there are an attacker could try to access them and use them.
Automations allow you to create automated actions that run based on a set of trigger conditions that occur during the lifecycle of end users.
For example a condition could be "User inactivity in Okta" or "User password expiration in Okta" and the action could be "Send email to the user" or "Change user lifecycle state in Okta".
Download logs. They are sent to the email address of the current account.
Here you can find the logs of the actions performed by users with a lot of details like login in Okta or in applications through Okta.
This can import logs from the other platforms accessed with Okta.
Check the API rate limits reached.
Here you can find generic information about the Okta environment, such as the company name, address, email billing contact, email technical contact and also who should receive Okta updates and which kind of Okta updates.
Here you can download Okta agents to sync Okta with other technologies.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
