Okta for Red Teamers

For a long time, Red Teamers have been preaching the mantra “Don’t make Domain Admin the goal of the assessment” and it appears that customers are listening. Now, you’re much more likely to see objectives focused on services critical to an organization, with many being hosted in the cloud.

This article provides an overview of post-exploitation techniques for Okta, a popular identity provider used in customer environments. It explains how attackers can use Delegated Authentication to gain access to a cloud service that uses Okta as its identity provider. This is done by requesting a TGS (Ticket Granting Service) for the AD user and injecting it on a host they control. Attackers can also hijack an Okta AD Agent by taking a look at the OktaAgentService.exe.config, which contains a Base64 encoded AgentToken. This token can be decrypted using DPAPI, and attackers can use it to make an internal API call to capture credentials or provide a skeleton key. The article also explains how attackers can hijack a privileged Okta account by requesting an OAuth Code, which will give them a permission prompt. Accepting the prompt will give them a redirection to /oauth-response along with a code parameter. They can then use this code parameter to request an API token and gain access to the service.

The article then explains how to use Okta's API to gain access to an Active Directory domain and how to use a fake SAML provider to authenticate as any Okta user without needing to know their credentials. It explains how to use the grant_type, code, and client_id parameters to obtain an API token. This token is then used to associate it with an active AD domain using an API call. The article also explains how to use a tool to support a few use-cases, such as token mode, which takes a compromised Agent Token value and will connect to the Okta API, dumping any credentials it receives. The article also explains how to deploy a fake SAML provider, which allows external providers like Entra ID to complete the authentication before redirecting the user to Okta to select integrated apps.

Overall, this article provides a comprehensive overview of post-exploitation techniques for Okta. It is important to monitor cloud based IDPs to ensure that these techniques are not used maliciously.

📓 Okta for Red Teamers

👉🏽 For a long time, Red Teamers have been preaching the mantra “Don’t make Domain Admin the goal of the assessment” and it appears that customers are listening. Now, you’re much more likely to see objectives focused on services critical to an organization, with many being hosted in the cloud. 👉🏽 Overview of post-exploitation techniques for Okta, a popular identity provider 👉🏽 Explanation of how attackers can use Delegated Authentication to gain unauthorized access 👉🏽 Hijacking Okta AD Agent by decoding Base64 encoded AgentToken in OktaAgentService.exe.config 👉🏽 Decrypting the token using DPAPI to capture credentials or provide a skeleton key 👉🏽 Hijacking a privileged Okta account by requesting an OAuth Code and accepting a permission prompt 👉🏽 Gaining access to an Active Directory domain using Okta's API 👉🏽 Authenticating as any Okta user without knowing their credentials using a fake SAML provider 👉🏽 Steps to obtain an API token using grant_type, code, and client_id parameters 👉🏽 Associating the API token with an active AD domain using an API call 👉🏽 Deployment of a fake SAML provider to complete authentication before redirecting to Okta.

🔗 source link: https://www.trustedsec.com/blog/okta-for-red-teamers/

🔗 summarized content: https://hut.threathunterz.com/battlefield-intel/articles-and-reports/okta-for-red-teamers

#OktaPostExploitation #DelegatedAuthentication #HijackOktaADAgent #HijackOktaAccount #APIAccess