Okta SSWS/API Token Theft

Attack technique

Technique name: Okta SSWS/API Token Theft


MITRE ATT&CK

• Tactic: Privilege Escalation, Credential Access, Persistence

• Technique: Token Impersonation/Theft, Steal Application Access Token
  
  
  Technique description

• SSWS (Session-Specific Web Service) token is a type of access token used in the Okta API. by getting unauthorized access to this kind of token, an attacker can get access to Okta’s resources, such as user profiles, groups, applications, and other data via API requests or management tools.

• The SSWS (Session-Specific Web Service) token is an access token utilized within the Okta API. It serves as a secure and time-restricted token that authenticates and authorizes API requests for users or applications. Okta SSWS/API tokens facilitate authentication and authorization for accessing Okta’s resources, including user profiles, groups, applications, and various data. They offer a secure method for accessing protected resources while maintaining the integrity of the user's session.

• A main weakness area to be aware of in relation to SSWS token is the option to find them saved in clear-text on disk, after using an administrative tool like Okta CLI. In this case the token will be saved in a file named okta.yaml, and can be stolen in case of unauthorized interactive access to the machine from which it was used, or even using different types of malware like infostealers.

• Since SSWS/API tokens tend to have administrative permissions attached to them stealing an Okta SSWS/API token, can lead to severe implications such as:

  • Addition of Permissions to compromised user account
  • Unauthorized access to organizational applications
  • Creation of backdoor user accounts
  • Data exfiltration
  • etc.

References

There are multiple data sources related to a potential abuse of SSWS/API tokens, so as other Okta token related attack examples:

• XMCyber | Okta rbac attacks blog post
• Okta | HAR files
• Cloudflare | Thanksgiving 2023 security incident blog post

Threat hunting theses breakdown

Okta SSWS/API - Potential Token Theft

Relevant data sources

• Main Data Source: Okta Logs
• Complementary Data Sources: EDR Logs, Cloud platforms’ logs.
  
  

Thesis explanation
Looking for SSWS/API token creation that were created from a specific IP address (referred as IP #1) and was later used from a different IP address (referred as IP #2).
Using this method we aimed to identify cases in which a system administrator created the token to conduct management activities using tools like Okta CLI, followed by unauthorized usage of the same token that might occur as a result of token theft from disk.
As part of the threat-hunting we cleaned up different hunting-query results that originated from commonly used IP addresses, Okta owned IP addresses, common user-agents, and more.

Potential blind spots

• Cases in which the SSWS/API token was stolen and used from a commonly used IP address (for example, used from within an organizational device)
• Cases in which no significant suspicious/malicious activities were logged from the second IP address (IP #2).
• Cases in which a potentially malicious activity was logged with an empty source IP or user-agent in Okta logs.
• Cases in which the attacker conducted user-agent manipulations to mimic the user-agent of known systems (for example automation applications that tend to use those tokens).

Recommended investigation flow

• Check the logged user-agent used in the actions conducted using the token.
  
  
  • Indication of a known organizational application in the user-agent value, for example an organizational system that uses Okta API token for automations will make this less suspicious.
  • However, a user-agent that indicates a manual management activity using the SSWS/API token, for example a user-agent that includes the name of a CLI tool, PowerShell, etc. will make this result more suspicious, and will require further investigation.
    
    
• Look for the IP address from which the token was created (IP #1), and compare it with the IP address (IP #2) from which the suspicious actions were conducted. Does the IP range of IP #1 is from the same IP range as IP#2? if so, it is less likely to be a suspicious activity.
  
  
• Characterize the IP from which the activities conducted using the SSWS/API token:
  
  
  • Is it a known organizational IP?
  • Was it in use before and/or after the suspicious activities? Was it found in other log sources as well?
  • In case the IP is not organizational, what additional information can you get? including ISP/Cloud provider, etc.
    
    
    • In case the activities are conducted from an infrastructure that is not being used in the organization, for example - hosting provider that is not used as part of the organizational infrastructure, it makes the activities more suspicious and potentially malicious.
      
      
• Compare the creation time of the token to the time in which the activities were conducted:
  
  
  • In case the token was used a long time ago, and never used until the identified detected activity - it increases the suspicion.
    
    
• Map the activities conducted using the SSWS/API token
  
  
  • Does it look like some kind of automation/repeatedly conducted actions? if not, it makes it more interesting and potentially suspicious.
  • Were there any activities that may indicate of malicious intent? for example:
    
    
    • Addition of user to additional groups, providing it with OAuth access to sensitive applications.
    • Reset of MFA factor and reset of user’s password.
    • Creations of new users, etc.

Hunting Queries

GitHub