Summary
This blog post summarizes new password stealing and impersonation risks recently discovered for Okta, along with recommended SIEM detection rules and associated MITRE ATT&CK techniques for SIEM solutions including Splunk, Microsoft Sentinel, IBM QRadar, and Sumo Logic.
Okta’s identity platform
Okta provides identity and access management (IAM) services which are essential elements for implementing a zero trust strategy. It can connect any person with any application on any device and it allows IT and security teams to manage any employee’s access to any application or device. Okta runs in the cloud and can be integrated with most on-premises applications, directories, and identity management systems.
IAM and your SIEM
Many organizations already send IAM logs like Okta and Microsoft Active Directory to their SIEMs.
In our 2022 Report on SIEM Detection Risk, however, we were surprised to find that 75% of organizations do not actually implement any detection queries for these types of logs, especially queries to identify attempts to compromise the IAM system itself.
This blog post contains best practice queries to address the new password stealing and impersonation risks that were recently discovered for Okta, expressed in the native query languages of the respective SIEMs.
If you are a CardinalOps customer, these detections have already been pushed to your portal so you can automatically deploy them with the push of a button, automatically customized to your environment (naming conventions, field mappings, etc.).
Newly discovered Okta risks
Authomize recently published a report about password stealing and impersonation risks in Okta’s platform. These risks can allow a malicious actor to:
- Extract the user’s password in clear text via both encrypted (HTTPS) and unencrypted channels (HTTP) via the System for Cross-domain Identity Management (SCIM).
- Compromise administrator accounts using an Org2Org application instance.
- Exploit mutable identity log spoofing.
In order to perform any of these actions, a malicious actor would need to have privileged access to the organization, and in some cases the “Application Admin” role would be enough to do so. These actions could also be performed by a malicious insider or a trusted partner such as a service provider with privileged access to the environment. It is especially concerning that application admins are typically not treated as privileged identities.
According to the 2022 Verizon Data Breach Investigations Report, 82% of breaches involved human elements like stolen credentials, phishing, and human error (negligence). More concerning, app admins are generally not treated as privileged identities.
Password extraction via SCIM
In order to extract password in clear text, the malicious actor would need to set up a SCIM application under their control and configure it with Okta’s control panel. After the application initial setup is complete, all the attacker needs to do for the organization’s password to sync to their SCIM applications is mark the “Sync Password” checkbox and choose “Sync Okta Password” (MITRE ATT&CK T1556).
Screenshot below: The SCIM provisioning configuration screen after the initial setup.
Compromising administrator accounts using an Org2Org application instance
Okta’s Org2Org applications instances are used to push and match users from one Okta organization to another. A malicious actor can add an Org2Org application instance (MITRE ATT&CK T1556) and create a user in the source organization (controlled by the attacker) with the same identifier as a Super Administrator in the target organization. This would in turn allow the attacker to use the credentials from the source organization to login to a legitimate Super Administrator account in the target organization (MITRE ATT&CK T1078.004).
MFA is not sufficient, you also need SIEM detections for unusual or unauthorized activity
Shortly after Authomize’s post was published, Okta published their response in which they declared that “the areas of concern highlighted are not vulnerabilities” while highlighting a number of best practice recommendations such as using HTTPS to ensure secure transmission of data and using MFA for all user accounts, especially admin accounts.
While these recommendations can help, it’s also important to implement “detections-in-depth” in order to rapidly detect and respond to unusual or unauthorized activities, especially when they’re performed by insiders.
Here are our recommended detections for Splunk, Microsoft Sentinel, IBM QRadar, and Sumo Logic.
SIEM Detections for Okta Password Sync Vulnerabilities
When Okta is configured to sync Okta’s password to an application, an “application.lifecycle.update” log is created with the “Pushing user passwords” in the “Outcome Reason” field:
Splunk Detection Query
index=[OktaIndex] sourcetype=OktaIM2:log eventType=application.lifecycle.update outcome.reason=”*Pushing user passwords*” “application.lifecycle.update” “Pushing user passwords” | stats values(transaction.type) as transaction.type, values(client.userAgent.rawUserAgent) as rawUserAgent, values(client.ipAddress) as client.ipAddress, values(outcome.reason) as outcome.reason count by actor.alternateId, target{}.displayName, target{}.alternateId
Microsoft Sentinel detection query
Okta_CL
| extend targetdisplayName = tostring(parse_json(target_s)[0].displayName)
| where eventType_s =~ “application.lifecycle.update” and outcome_result_s contains “Pushing user passwords”
| project-reorder actor_displayName_s,client_ipAddress_s,displayMessage_s,outcome_result_s,targetdisplayName
IBM QRadar detection query (AQL)
SELECT QIDNAME(qid) as “Event Name”,logsourcename(logsourceid) as LogSource, “EventType”, “OutcomeReason”, sourceip, destinationip, username, DATEFORMAT(starTTime,’YYYY-MM-dd HH:mm:ss’) as startTime FROM events
WHERE devicetype=382 AND “EventType”=’application.lifecycle.update’ AND OutcomeReason ILIKE ‘%Pushing user passwords%’
Note: the field “EventType” and “OutcomeReason” might be named differently in every QRadar instance.
Sumo Logic detection query
_sourceCategory=prod/okta/logs “application.lifecycle.update”
| json field=_raw “outcome.reason” as Reason nodrop
| json field=_raw “target[0].displayName” as targetDisplayName nodrop
| json field=_raw “actor.alternateId” as User nodrop
| json field=_raw “eventType” as eventType nodrop
| json field=_raw “client.userAgent.rawUserAgent” as userAgent nodrop
| json field=_raw “outcome.result” as Result nodrop
| json field=_raw “client.ipAddress” as ipAddress nodrop
| where eventType=”application.lifecycle.update” and Reason contains “Pushing user passwords”
| count by User, targetDisplayName, Reason, Result, ipAddress, userAgent
SIEM detections for Okta Org2Org instance creation and modification vulnerabilities
Any manipulation of an Org2Org instance can be detected by monitoring the logs created when an application is created, activated or updated, and then filtering for the Org2Org application name:
Splunk detection query
index=[OktaIndex] sourcetype=OktaIM2:log eventType IN (“application.lifecycle.activate” , “application.lifecycle.create” , “application.lifecycle.update”) target.displayName=”Okta Org2Org” (“application.lifecycle.activate” OR “application.lifecycle.create” OR “application.lifecycle.update”) “Org2Org” | stats values(eventType) as eventType, values(transaction.type) as transaction.type, values(client.userAgent.rawUserAgent) as rawUserAgent, values(client.ipAddress) as client.ipAddress, values(outcome.reason) as outcome.reason count by actor.alternateId, target{}.displayName, target{}.alternateId
Microsoft Sentinel detection query
Okta_CL
| extend targetdisplayName = tostring(parse_json(target_s)[0].displayName)
| where eventType_s in~ (“application.lifecycle.activate” , “application.lifecycle.create” , “application.lifecycle.update”)
| where targetdisplayName contains “Okta Org2Org”
| project-reorder actor_displayName_s,client_ipAddress_s,displayMessage_s,outcome_result_s,targetdisplayName
I
BM QRadar detection query (AQL)
SELECT QIDNAME(qid) as “Event Name”,logsourcename(logsourceid) as LogSource, “EventType”, “TargetDisplayName”, sourceip, destinationip, username, DATEFORMAT(starTTime,’YYYY-MM-dd HH:mm:ss’) as startTime FROM events
WHERE devicetype=382 AND “EventType” IN (‘application.lifecycle.activate’ , ‘application.lifecycle.create’ , ‘application.lifecycle.update’) AND TargetDisplayName ILIKE ‘%Okta Org2Org%’
Note: the field “EventType” and “TargetDisplayName” might be named differently in every QRadar instance.
Sumo Logic detection query
_sourceCategory=prod/okta/logs (“application.lifecycle.activate” OR “application.lifecycle.create” OR “application.lifecycle.update”) “Org2Org”
| json field=_raw “outcome.reason” as Reason nodrop
| json field=_raw “target[0].displayName” as targetDisplayName nodrop
| json field=_raw “actor.alternateId” as User nodrop
| json field=_raw “eventType” as eventType nodrop
| json field=_raw “client.userAgent.rawUserAgent” as userAgent nodrop
| json field=_raw “outcome.result” as Result nodrop
| json field=_raw “client.ipAddress” as ipAddress nodrop
| where eventType IN (“application.lifecycle.activate”, “application.lifecycle.create”, “application.lifecycle.update”) and targetDisplayName contains “Okta Org2Org”
| count by User, targetDisplayName, Reason, Result, ipAddress, userAgent
Conclusion
Although Identity and Access Management (IAM) solutions like Okta and Microsoft Active Directory help enable Zero Trust security by ensuring all users are properly authenticated, they are not sufficient on their own to protect against all credential-based attacks, especially insider threats.
During the last decade, we’ve seen insiders cause damage to big companies such as Cisco, Google, and even the NSA and CIA (the Vault7 leak was called “one of the most brazen and damaging acts of espionage in American history”).
Implementing continuous monitoring in your SIEM to detect potential insider threats – including those targeting your critical IAM systems – is now considered a best practice. CardinalOps is proud to be helping our customers accelerate their detection engineering efforts in this domain.