Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Okta, Inc. is recognized in the identity and access management sector for its cloud-based software solutions. These solutions are designed to streamline and secure user authentication across various modern applications. They cater not only to companies aiming to safeguard their sensitive data but also to developers interested in integrating identity controls into applications, web services, and devices.
The flagship offering from Okta is the Okta Identity Cloud. This platform encompasses a suite of products, including but not limited to:
Single Sign-On (SSO): Simplifies user access by allowing one set of login credentials across multiple applications.
Multi-Factor Authentication (MFA): Enhances security by requiring multiple forms of verification.
Lifecycle Management: Automates user account creation, update, and deactivation processes.
Universal Directory: Enables centralized management of users, groups, and devices.
API Access Management: Secures and manages access to APIs.
These services collectively aim to fortify data protection and streamline user access, enhancing both security and convenience. The versatility of Okta's solutions makes them a popular choice across various industries, beneficial to large enterprises, small companies, and individual developers alike. As of the last update in September 2021, Okta is acknowledged as a prominent entity in the Identity and Access Management (IAM) arena.
The main gola of Okta is to configure access to different users and groups to external applications. If you manage to compromise administrator privileges in an Oktas environment, you will highly probably able to compromise all the other platforms the company is using.
To perform a security review of an Okta environment you should ask for administrator read-only access.
There are users (which can be stored in Okta, logged from configured Identity Providers or authenticated via Active Directory or LDAP). These users can be inside groups. There are also authenticators: different options to authenticate like password, and several 2FA like WebAuthn, email, phone, okta verify (they could be enabled or disabled)...
Then, there are applications synchronized with Okta. Each applications will have some mapping with Okta to share information (such as email addresses, first names...). Moreover, each application must be inside an Authentication Policy, which indicates the needed authenticators for a user to access the application.
The most powerful role is Super Administrator.
If an attacker compromise Okta with Administrator access, all the apps trusting Okta will be highly probably compromised.
Usually the portal of a company will be located in companyname.okta.com. If not, try simple variations of companyname. If you cannot find it, it's also possible that the organization has a CNAME record like okta.companyname.com pointing to the Okta portal.
If companyname.kerberos.okta.com is active, Kerberos is used for Okta access, typically bypassing MFA for Windows users. To find Kerberos-authenticated Okta users in AD, run getST.py with appropriate parameters. Upon obtaining an AD user ticket, inject it into a controlled host using tools like Rubeus or Mimikatz, ensuring clientname.kerberos.okta.com is in the Internet Options "Intranet" zone. Accessing a specific URL should return a JSON "OK" response, indicating Kerberos ticket acceptance, and granting access to the Okta dashboard.
Compromising the Okta service account with the delegation SPN enables a Silver Ticket attack. However, Okta's use of AES for ticket encryption requires possessing the AES key or plaintext password. Use ticketer.py to generate a ticket for the victim user and deliver it via the browser to authenticate with Okta.
Check the attack in https://trustedsec.com/blog/okta-for-red-teamers.
This technique involves accessing the Okta AD Agent on a server, which syncs users and handles authentication. By examining and decrypting configurations in OktaAgentService.exe.config, notably the AgentToken using DPAPI, an attacker can potentially intercept and manipulate authentication data. This allows not only monitoring and capturing user credentials in plaintext during the Okta authentication process but also responding to authentication attempts, thereby enabling unauthorized access or providing universal authentication through Okta (akin to a 'skeleton key').
Check the attack in https://trustedsec.com/blog/okta-for-red-teamers.
This technique involves hijacking an Okta AD Agent by first obtaining an OAuth Code, then requesting an API token. The token is associated with an AD domain, and a connector is named to establish a fake AD agent. Initialization allows the agent to process authentication attempts, capturing credentials via the Okta API. Automation tools are available to streamline this process, offering a seamless method to intercept and handle authentication data within the Okta environment.
Check the attack in https://trustedsec.com/blog/okta-for-red-teamers.
Check the attack in https://trustedsec.com/blog/okta-for-red-teamers.
The technique involves deploying a fake SAML provider. By integrating an external Identity Provider (IdP) within Okta's framework using a privileged account, attackers can control the IdP, approving any authentication request at will. The process entails setting up a SAML 2.0 IdP in Okta, manipulating the IdP Single Sign-On URL for redirection via local hosts file, generating a self-signed certificate, and configuring Okta settings to match against the username or email. Successfully executing these steps allows for authentication as any Okta user, bypassing the need for individual user credentials, significantly elevating access control in a potentially unnoticed manner.
In this blog post is explained how to prepare a phishing campaign against an Okta portal.
The attributes that each user can have and modify (like email or first name) can be configured in Okta. If an application is trusting as ID an attribute that the user can modify, he will be able to impersonate other users in that platform.
Therefore, if the app is trusting the field userName, you probably won't be able to change it (because you usually cannot change that field), but if it's trusting for example primaryEmail you might be able to change it to a colleagues email address and impersonate it (you will need to have access to the email and accept the change).
Note that this impersoantion depends on how each application was condigured. Only the ones trusting the field you modified and accepting updates will be compromised. Therefore, the app should have this field enabled if it exists:
I have also seen other apps that were vulnerable but didn't have that field in the Okta settings (at the end different apps are configured differently).
The best way to find out if you could impersonate anyone on each app would be to try it!
Behavioral detection policies in Okta might be unknown until encountered, but bypassing them can be achieved by targeting Okta applications directly, avoiding the main Okta dashboard. With an Okta access token, replay the token at the application-specific Okta URL instead of the main login page.
Key recommendations include:
Avoid using popular anonymizer proxies and VPN services when replaying captured access tokens.
Ensure consistent user-agent strings between the client and replayed access tokens.
Refrain from replaying tokens from different users from the same IP address.
Exercise caution when replaying tokens against the Okta dashboard.
If aware of the victim company's IP addresses, restrict traffic to those IPs or their range, blocking all other traffic.
Okta has a lot of possible configurations, in this page you will find how to review them so they are as secure as possible:
Okta HardeningLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
