Migrate to using mdbook

src/pentesting-ci-cd/okta-security/README.md

@@ -0,0 +1,114 @@
+# Okta Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Basic Information
+
+[Okta, Inc.](https://www.okta.com/) 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.
+
+> [!CAUTION]
+> 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**.
+
+> [!TIP]
+> To perform a security review of an Okta environment you should ask for **administrator read-only access**.
+
+### Summary
+
+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.
+
+> [!CAUTION]
+> 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**.
+
+## Attacks
+
+### Locating Okta Portal
+
+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**.
+
+### Login in Okta via Kerberos
+
+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**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
+
+### Hijacking Okta AD Agent
+
+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**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
+
+### Hijacking AD As an Admin
+
+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**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
+
+### Okta Fake SAML Provider
+
+**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](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.
+
+### Phishing Okta Portal with Evilgnix
+
+In [**this blog post**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) is explained how to prepare a phishing campaign against an Okta portal.
+
+### Colleague Impersonation Attack
+
+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:
+
+<figure><img src="../../images/image (175).png" alt=""><figcaption></figcaption></figure>
+
+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!
+
+## Evading behavioural detection policies <a href="#id-9fde" id="id-9fde"></a>
+
+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 Hardening
+
+Okta has a lot of possible configurations, in this page you will find how to review them so they are as secure as possible:
+
+{{#ref}}
+okta-hardening.md
+{{#endref}}
+
+## References
+
+- [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers)
+- [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/okta-security/okta-hardening.md

@@ -0,0 +1,199 @@
+# Okta Hardening
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Directory
+
+### People
+
+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**".
+
+### Groups
+
+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).
+
+### Devices
+
+Find here a **list of all the devices** of all the users. You can also see if it's being **actively managed** or not.
+
+### Profile Editor
+
+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).
+
+### Directory Integrations
+
+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**.
+
+### Profile Sources
+
+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.
+
+## Customizations
+
+### Brands
+
+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.
+
+### SMS
+
+Nothing interesting here.
+
+### End-User Dashboard
+
+You can find here applications configured, but we will see the details of those later in a different section.
+
+### Other
+
+Interesting setting, but nothing super interesting from a security point of view.
+
+## Applications
+
+### Applications
+
+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:
+
+<figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>
+
+And you could see some more details about the app (like the password reveal feature, if it's enabled):
+
+<figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>
+
+## Identity Governance
+
+### Access Certifications
+
+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
+
+### General
+
+- **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](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) for more information):
+    - Self-Service Registration
+    - JIT flows with email authentication
+- **Okta ThreatInsight settings**: Log and enforce security based on threat level
+
+### HealthInsight
+
+Here is possible to find correctly and **dangerous** configured **settings**.
+
+### Authenticators
+
+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:
+
+<figure><img src="../../images/image (143).png" alt=""><figcaption></figcaption></figure>
+
+It's recommendatble to disable Phone. The strongest ones are probably a combination of password, email and WebAuthn.
+
+### Authentication policies
+
+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.
+
+### Global Session Policy
+
+Here you can find the session policies assigned to different groups. For example:
+
+<figure><img src="../../images/image (245).png" alt=""><figcaption></figcaption></figure>
+
+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
+
+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
+
+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.
+
+### Network
+
+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.
+
+### Device Integrations
+
+- **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
+
+### API
+
+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.
+
+## Workflow
+
+### Automations
+
+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".
+
+## Reports
+
+### Reports
+
+Download logs. They are **sent** to the **email address** of the current account.
+
+### System Log
+
+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.
+
+### Import Monitoring
+
+This can **import logs from the other platforms** accessed with Okta.
+
+### Rate limits
+
+Check the API rate limits reached.
+
+## Settings
+
+### Account
+
+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.
+
+### Downloads
+
+Here you can download Okta agents to sync Okta with other technologies.
+
+{{#include ../../banners/hacktricks-training.md}}