├── LICENSE ├── README.md ├── detections ├── access_to_admin_console_denied.yml ├── authentication_policy_mfa_downgrade.yml ├── detect_aitm_phishing_using_okta_fastpass.yml ├── device_enrolled_with_nonstandard_hostname.yml ├── device_registered_to_multiple_users.yml ├── fastpass_auth_via_suspicious_binary.yml ├── itp_brute_force.yml ├── log_stream_tampering.yml ├── mismatch_between_source_and_response_okta_verify_push.yml ├── multiple_failed_requests_to_access_okta_applications.yml ├── new_api_token_created.yml ├── new_idp_created.yml ├── new_super_admin_added_or_removed.yml ├── oauth_client_secret_read.yml ├── oauth_mismatched_redirect_uri.yml ├── opa_password_changed_oob.yml ├── phone_number_registered_to_multiple_users.yml ├── rapid_application_access.yml ├── request_to_access_admin_console_from_new_device_or_ip.yml ├── suspicious_mfa_abandonment.yml ├── suspicious_use_of_an_Okta_Session_Cookie.yml ├── threat_insight_high_unknown_users.yml ├── threat_insight_password_spray.yml ├── user_denied_access_due_to_session_binding.yml └── user_reported_suspicious_activity.yml ├── hunts ├── hunt_app_password_reveal.yml ├── hunt_authentication_policy_denies.yml ├── hunt_failed_identity_verification.yml ├── hunt_failed_number_challenge.yml ├── hunt_mfa_abandonment.yml ├── hunt_on_factor_resets.yml ├── hunt_rejected_MFA_pushes.yml └── hunt_sign_in_attempts_from_proxies.yml └── logs └── log_fields.csv /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright 2025 Okta, inc. 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Blog](https://img.shields.io/badge/blog-okta_security-blue)][secblog] 2 | [![Advisories](https://img.shields.io/badge/advisories-okta_security_advisories-blue)][advisories] 3 | [![EventTypes](https://img.shields.io/badge/docs-okta_event_types-blue)][eventtypes] 4 | 5 | # Okta Security Detection Catalog 6 | Welcome to the Okta Security Detection Catalog. This repository contains a collection of detection rules for security monitoring and detailed descriptions of log fields used for threat analysis within Okta environments. 7 | 8 | ## Who We Are 9 | Okta Identity Defense Operations is a team of security practitioners that help Okta customers investigate and respond to security incidents. If you are an Okta customer and need support with a security breach or incident, open a support case and indicate that you are investigating a security incident. 10 | 11 | ## File Structure 12 | | Folder | Description | 13 | | ------------- | ------------- | 14 | | `detections/` | List of YAML files for recommended security detections Okta customers can implement within their security monitoring system. | 15 | | `hunts/` | Threat hunting queries useful for aiding in detection use case creation | 16 | | `logs/` | CSV file with descriptions and examples of log fields within the Okta system log | 17 | 18 | ## Getting Started 19 | The System Log provides a detailed log of user, admin and support events relevant to use of the Okta Workforce Identity Cloud. 20 | 21 | These events can be [browsed, searched or filtered in the admin console](https://help.okta.com/en-us/content/topics/reports/syslog-filters.htm). They can also be queried and [filtered](https://developer.okta.com/docs/reference/api/system-log/#filtering-results) programmatically via the [System Log API](https://developer.okta.com/docs/reference/api/system-log/), and can be [exported](https://support.okta.com/help/s/article/Exporting-Okta-Log-Data?language=en_US) or [streamed](https://help.okta.com/en/prod/Content/Topics/Reports/log-streaming/about-log-streams.htm) to third-party security monitoring tools. 22 | 23 | Okta Security recommends the use of [Log Streaming](https://help.okta.com/en-us/Content/Topics/Reports/log-streaming/about-log-streams.htm) to capture events in third-party security tools in close to real-time, and/or the use of [Event Hooks](https://developer.okta.com/docs/concepts/event-hooks/) and [Workflows](https://www.okta.com/platform/workflows/) for security orchestration opportunities. 24 | 25 | Most events in System Log follow a similar pattern:\ 26 | *user.account.password_reset*\ 27 | `..` 28 | 29 | 30 | Some of the queries listed below use the following operators to group multiple events together: 31 | 32 | | Operator | Description | 33 | | ------------- | ------------- | 34 | | `eq` | Equals | 35 | | `ne` | Not Equal to | 36 | | `sw` | Starts With | 37 | | `ew` | Ends With | 38 | | `co` | Contains | 39 | 40 | Okta recommends customers review these detections and run searches using those that appear to be applicable to your environment. Perform any necessary tuning or baselining to ensure they deliver high fidelity results prior to creating an alert. 41 | 42 | Note: Most of these detections leverage Okta system log query languages, however a subset is provided in splunk query language. A plain english description of the detection logic is provided for splunk queries to allow detection engineers to implement in their SIEM of choice. 43 | 44 | [secblog]: https://sec.okta.com/articles 45 | [advisories]: https://trust.okta.com/security-advisories/ 46 | [eventtypes]: https://developer.okta.com/docs/reference/api/event-types/ -------------------------------------------------------------------------------- /detections/access_to_admin_console_denied.yml: -------------------------------------------------------------------------------- 1 | title: Access to Admin Console Denied 2 | id: e6e88bfdbc27a65cddf1225c9ff0fb12 3 | description: | 4 | Detects when an attempt was made to access the Okta Admin Console but failed. 5 | Adversaries may try to access the Okta Admin Console after compromising an Okta admin but get denied due to policy constraints. 6 | references: 7 | - https://sec.okta.com/leastprivilege 8 | author: Okta 9 | created_date: '2022-10-22' 10 | modified_date: '2022-10-22' 11 | threat: 12 | Tactic: 13 | - Initial Access 14 | Technique: 15 | - T1078: Valid Accounts 16 | prevention: 17 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 18 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 19 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 20 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 21 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 22 | detection: 23 | okta_systemlog: 24 | OIE: | 25 | eventType eq "user.session.access_admin_app" AND outcome.result eq "FAILURE" 26 | false_positives: 27 | - Legitimate administrative users causing a failure due to user-error. Enhance this detection looking for multiple instances of this occurring from the same source. -------------------------------------------------------------------------------- /detections/authentication_policy_mfa_downgrade.yml: -------------------------------------------------------------------------------- 1 | title: Authentication Policy MFA Downgrade 2 | id: 0c2634a68f9ac593c58349e0de80bb67 3 | description: | 4 | Detects when an Okta Administrator changes an authentication policy from requiring 2FA to only requiring 1FA. 5 | An adversary with access to a compromised Okta Admin account may try to downgrade MFA for certain applications such as password managers to bypass MFA. 6 | references: 7 | - https://www.reliaquest.com/blog/scattered-spider-x-ransomhub-a-new-partnership/ 8 | - https://help.okta.com/oie/en-us/content/topics/identity-engine/policies/add-app-sign-on-policy-rule.htm 9 | author: Okta 10 | created_date: '2025-02-11' 11 | modified_date: '2025-02-11' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | - Defense Evasion 16 | - Persistence 17 | Technique: 18 | - T1556.006: Modify Authentication Process - Multi-Factor Authentication 19 | prevention: 20 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm). 21 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 22 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 23 | detection: 24 | explanation: | 25 | The query below: 26 | Retrieves successful policy update events (policy.rule.update) 27 | Extract relevant JSON from the log to display in the search 28 | Filters on policy updates where the policy changed from requiring 2FA to only requiring 1FA using the target fields 29 | Display results grouped by the policy name and rule ID that was changed. 30 | splunk: | 31 | index=main sourcetype=OktaIM2:log AND eventType="policy.rule.update" AND outcome.result=SUCCESS 32 | | spath target{} output=targets 33 | | eval PolicyRuleChanges=mvindex(targets,1) 34 | | spath input=PolicyRuleChanges path=displayName output=policy_changed 35 | | spath input=PolicyRuleChanges path=id output=policy_rule_id 36 | ```Parse out the changeDetails that show specifically what was changed within the authentication policy``` 37 | | spath input=PolicyRuleChanges path=changeDetails.from.policyRuleActionJson output=change_from 38 | | spath input=PolicyRuleChanges path=changeDetails.to.policyRuleActionJson output=change_to 39 | ```Extract the factorMode field from Nested JSON which displays whether the authentication policy requires 1FA or 2FA``` 40 | | spath input=change_from path="appSignOn.verificationMethod.factorMode" output=from_factor 41 | | spath input=change_to path="appSignOn.verificationMethod.factorMode" output=to_factor 42 | ```Filter on the factorMode field to look for when the authentication policy was originally set to 2FA then was changed to 1FA``` 43 | | where from_factor = "2FA" AND to_factor = "1FA" 44 | ```Display the information in a table``` 45 | | stats values(actor.id) as user_id values(actor.alternateId) as username values(client.ipAddress) as src_ip values(client.userAgent.rawUserAgent) as user_agent values(from_factor) as original_factor values(to_factor) as changed_to_factor values(change_from) as full_original_policy values(change_to) as full_policy_changed_to by policy_changed policy_rule_id 46 | false_positives: 47 | - Approved changes to authentication policies where downgrading MFA is expected -------------------------------------------------------------------------------- /detections/detect_aitm_phishing_using_okta_fastpass.yml: -------------------------------------------------------------------------------- 1 | title: Okta AiTM Phishing Detection with FastPass 2 | id: d317ba7832d50618ad769b2ea22a4473 3 | description: | 4 | Detects when a user enrolled in FastPass fails to authenticate via a real-time AiTM phishing proxy. 5 | An adversary may attempt to compromise a user via AiTM phishing infrastructure, Okta Fastpass logs an event when it suspects an authentication is ocurring through a phishing proxy. 6 | references: 7 | - https://sec.okta.com/shareddetections 8 | - https://sec.okta.com/fastpassphishingdetection 9 | author: Okta 10 | created_date: '2024-11-07' 11 | modified_date: '2024-11-07' 12 | threat: 13 | Tactic: 14 | - Initial Access 15 | - Credential Access 16 | - Collection 17 | Technique: 18 | - T1557: Adversary-in-the-Middle 19 | - T1566: Phishing 20 | - T1539: Steal Web Session Cookie 21 | prevention: 22 | - Configure authentication policies to ensure Okta Fastpass is used in all authentication flows. 23 | - Perform proactive domain monitoring to detect new phishing domains impersonating your brand. 24 | detection: 25 | okta_systemlog: 26 | OIE: | 27 | eventType eq "user.authentication.auth_via_mfa" AND result eq "FAILURE" AND outcome.reason eq "FastPass declined phishing attempt" 28 | false_positives: 29 | - Planned and approved offensive security engagements -------------------------------------------------------------------------------- /detections/device_enrolled_with_nonstandard_hostname.yml: -------------------------------------------------------------------------------- 1 | title: Device Enrolled with Non-Standard Hostname 2 | id: 4f6161a02dbd790f1b1c2c9f5287ab45 3 | description: | 4 | Detects when a new device is enrolled by a user that doesn't follow standard hostname nomenclature used in the organization. 5 | An adversary with access to a compromised account may enroll their own device to leverage as MFA. This device does not often follow standard hostname nomenclature used in the organization. 6 | references: 7 | - null 8 | author: Okta 9 | created_date: '2025-02-11' 10 | modified_date: '2025-02-11' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | - Defense Evasion 15 | - Persistence 16 | Technique: 17 | - T1556.006: Modify Authentication Process - Multi-Factor Authentication 18 | - T1078: Valid Accounts 19 | prevention: 20 | - Configure authentication policies to only allow managed devices to authenticate. 21 | - If unmanaged devices are required, configure device assurance policies to ensure all devices meet a secure baseline. 22 | - Configure strong policy-based enrolments. Using a combination of Event Hooks, Okta Workflows and Okta Account Management policy, create a policy where after initial enrollment, all subsequent enrollments require phishing resistant MFA. 23 | detection: 24 | explanation: | 25 | The query below: 26 | Retrieves device enrollment and device added log events. 27 | Extracts relevant fields from the raw log. 28 | Filters where the hostname of the device being enrolled doesn't match a regex that follows your organization's nomenclature. 29 | splunk: | 30 | index=main sourcetype=OktaIM2:log AND eventType IN ("device.user.add", "device.enrollment.create") ```OPTIONAL: To filter only on Computers and not Mobile Devices add: AND client.device="Computer"``` 31 | ```Extract relevant fields from JSON in the log``` 32 | | spath "target{}.displayName" output="hostname" 33 | | spath "target{}.detailEntry.managed" output="managed" 34 | | spath "target{}.detailEntry.osPlatform" output="OS" 35 | | spath "target{}.detailEntry.osVersion" output="OS_Version" 36 | ```Filter when the name of the device being enrolled doesn't follow standard hostname nomenclature regex``` 37 | | where NOT match(hostname, "") 38 | ```Display the information``` 39 | | stats values(published) as timestamp values(displayMessage) as message values(actor.id) as actor_id values(actor.alternateId) as username values(client.ipAddress) as source_ip values(OS) as OS values(OS_Version) as OS_Version values(managed) as managed_device by hostname 40 | false_positives: 41 | - Mobile phone hostnames that aren't expected to follow any sort of hostname standard. Tune this rule to exclude mobile devices. 42 | - Legitimate BYOD or personal devices that a user enrolls. -------------------------------------------------------------------------------- /detections/device_registered_to_multiple_users.yml: -------------------------------------------------------------------------------- 1 | title: Device Registered to Multiple Users 2 | id: f2ae616490db4cc6515b5f8ff7785262 3 | description: | 4 | Detects when the same device is registered for MFA to multiple users. 5 | An adversary may register their own MFA devices, often leveraging the same device for multiple compromised accounts. 6 | references: 7 | - Threat Research 8 | author: Okta 9 | created_date: '2025-01-15' 10 | modified_date: '2025-01-15' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | - Defense Evasion 15 | - Persistence 16 | Technique: 17 | - T1556.006: Modify Authentication Process.Multi-Factor Authentication 18 | prevention: 19 | - Configure authentication policies to only allow managed devices to authenticate. 20 | - If unmanaged devices are required, configure device assurance policies to ensure all devices meet a secure baseline. 21 | - Configure strong policy-based enrolments. Using a combination of Event Hooks, Okta Workflows and Okta Account Management policy, create a policy where after initial enrollment, all subsequent enrollments require phishing resistant MFA. 22 | detection: 23 | explanation: | 24 | The query below: 25 | Retrieves events where a user added a device as an MFA factor. 26 | Groups the results by the device ID and counts the distinct number of userIDs that have added that same device ID over the supplied period of time. It's recommended this query be ran over a longer period of time. 27 | Alerts when 2 or more unique user IDs were observed registering the same device ID. 28 | splunk: | 29 | index=main sourcetype=OktaIM2:log AND eventType="device.user.add" 30 | | spath "target{}.detailEntry.oktaDeviceId" output="device_id" 31 | | spath "target{}.displayName" output="device_name" 32 | | stats values(device_name) as device_name dc(actor.id) as distinct_user_count values(client.ipAddress) as source_ip values(actor.alternateId) as username by device_id 33 | | where distinct_user_count >= 2 34 | false_positives: 35 | - Customer identity accounts that leverage a shared phone. 36 | - Service accounts leveraging a shared device. -------------------------------------------------------------------------------- /detections/fastpass_auth_via_suspicious_binary.yml: -------------------------------------------------------------------------------- 1 | title: FastPass Auth via Suspicious Binary 2 | id: d26f5a1d2c82b0e099f45a0ffe2c8da6 3 | description: | 4 | Detects suspicious binaries authenticating successfully via Okta Fastpass. 5 | An adversary with access to a compromised device may proxy fastpass auths through the compromised device to gain access to Okta. 6 | 7 | Note: This detection relies on the use of Okta Fastpass in your environment. 8 | references: 9 | - https://www.okta.com/blog/2025/04/stay-secure-with-fastpass-and-trusted-app-filters/ 10 | author: Okta 11 | created_date: '2025-04-11' 12 | modified_date: '2024-04-11' 13 | threat: 14 | Tactic: 15 | - Defense Evasion 16 | Technique: 17 | - T1604: Proxy Through Victim 18 | prevention: 19 | - Configure trusted app filters within auth policies as defined in the reference URL. 20 | detection: 21 | okta_systemlog: 22 | OIE: | 23 | debugContext.debugData.factor eq "SIGNED_NONCE" and outcome.result eq "SUCCESS" and authenticationContext.authenticatorContext.bindingMethod eq "LOOPBACK" and (authenticationContext.authenticatorContext.validationStatus eq "NO_SIGNATURE" or not (authenticationContext.authenticatorContext.binaryIdentifier co "Edge" or authenticationContext.authenticatorContext.binaryIdentifier co "Chrome" or authenticationContext.authenticatorContext.binaryIdentifier co "firefox" or authenticationContext.authenticatorContext.binaryIdentifier co "Safari" or authenticationContext.authenticatorContext.binaryIdentifier co "Brave" or authenticationContext.authenticatorContext.binaryIdentifier co "Microsoft")) 24 | false_positives: 25 | - Corporate approved binaries. Consider baselining the authenticationContext.authenticatorContext.binaryIdentifier used in your environment, and alert on everything else. -------------------------------------------------------------------------------- /detections/itp_brute_force.yml: -------------------------------------------------------------------------------- 1 | title: ITP Push Bombing 2 | id: 8a26f484504f6444804ec0095ee389cb 3 | description: | 4 | Identity Threat Protection (ITP) has detected a push bomb or MFA fatigue attack and logged the event with 5 | event type user.risk.detect. 6 | references: 7 | - https://help.okta.com/oie/en-us/content/topics/itp/risk-detections.htm 8 | - https://www.okta.com/blog/2022/09/mfa-fatigue-growing-security-concern/ 9 | author: Okta 10 | created_date: '2025-05-21' 11 | modified_date: '2025-05-21' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | - Defense Evasion 16 | Technique: 17 | - T1556.006: Modify Authentication Process.Multi-Factor Authentication 18 | - T1562.008: Impair Defenses - Disable or Modify Tools 19 | prevention: 20 | - Consider migrating to a higher assurance factor like Okta FastPass, WebAuthn, or enabling the Okta Verify Number Challenge to reduce 21 | efficacy of MFA fatigue attacks. 22 | - An ITP Action can be configured to notify SecOps team members in Slack or other notification system instead 23 | of a SIEM based detection. 24 | detection: 25 | okta_systemlog: 26 | OIE: | 27 | eventType eq "user.risk.detect" and debugContext.debugData.risk co "detectionName=Brute Force Attack, reasons=MFA brute force" 28 | false_positives: 29 | - A user rejects the push notificaiton multiple times for various reasons. 30 | -------------------------------------------------------------------------------- /detections/log_stream_tampering.yml: -------------------------------------------------------------------------------- 1 | title: Log Stream Tampering 2 | id: 6595e64287a21e6e7f63f0ab037a4401 3 | description: | 4 | Detects Okta log stream configuration changes such as deactivation, creation or deletion. 5 | An adversary with access to an Okta Administrator may attempt to disable log streams to a SIEM in order to prevent detection of their activities. 6 | references: 7 | - https://help.okta.com/en-us/content/topics/reports/log-streaming/about-log-streams.htm 8 | author: Okta 9 | created_date: '2025-02-11' 10 | modified_date: '2025-02-11' 11 | threat: 12 | Tactic: 13 | - Defense Evasion 14 | Technique: 15 | - T1562.008: Impair Defenses - Disable or Modify Cloud Logs 16 | prevention: 17 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 18 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 19 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 20 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 21 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 22 | detection: 23 | okta_systemlog: 24 | OIE: | 25 | eventType sw "system.log_stream.lifecycle" 26 | false_positives: 27 | - Approved changes to log streams where changing a log stream is expected. 28 | - This query can be further filtered to only look at disable, deletion or update events. -------------------------------------------------------------------------------- /detections/mismatch_between_source_and_response_okta_verify_push.yml: -------------------------------------------------------------------------------- 1 | title: Mismatch Between Source and Response for Verify Push Request 2 | id: 6d16360eb451ac60db533258c0c5b48e 3 | description: | 4 | Detects when an adversary has stolen a user password attempts to trick a user into accepting a Okta Verify Push request. 5 | The following detection identified variations in client-based values for source and response events to identify suspicious request behavior. 6 | The detection is enhanced if the org is evaluating behavior conditions in the authentication policies using Okta Behavior Detection. 7 | references: 8 | - https://sec.okta.com/shareddetections 9 | - https://research.splunk.com/application/8085b79b-9b85-4e67-ad63-351c9e9a5e9a/ 10 | author: Okta 11 | created_date: '2023-04-06' 12 | modified_date: '2023-04-06' 13 | threat: 14 | Tactic: 15 | - Credential Access 16 | Technique: 17 | - T1621: Multi-Factor Authentication Request Generation 18 | prevention: 19 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 20 | - Leverage Okta Number Challenge MFA over standard push verification. 21 | - Block traffic from anonymizers and proxies via network zones that are often used in account takeover. 22 | - Educate users on how to identify and report suspicious MFA push notifications. 23 | detection: 24 | explanation: | 25 | The query below: 26 | Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) 27 | Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. 28 | Creates a ratio of successful sign-ins to pushes. 29 | If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session. 30 | splunk: | 31 | index=main sourcetype=OktaIM2:log eventType IN (system.push.send_factor_verify_push) OR (eventType IN (user.authentication.auth_via_mfa) debugContext.debugData.factor="OKTA_VERIFY_PUSH") 32 | | eval groupby='authenticationContext.externalSessionId' 33 | ``` Each push is sent to each registered push device, so we should group pushes around the same time as a single event for the purpose of this use-case ``` 34 | | eval group_push_time=_time 35 | | bin span=2s group_push_time 36 | | fillnull value=NULL 37 | | stats min(_time) as _time by authenticationContext.externalSessionId eventType debugContext.debugData.factor outcome.result actor.alternateId client.device client.ipAddress client.userAgent.rawUserAgent debugContext.debugData.behaviors group_push_time groupby 38 | | iplocation client.ipAddress 39 | | fields - lat, lon, group_push_time 40 | ```Get counts for number of push events, successful authentication events, and any push sources where the client is a new device ``` 41 | | stats min(_time) as _time dc(client.ipAddress) as dc_ip 42 | sum(eval(if(eventType="system.push.send_factor_verify_push" AND 'outcome.result'="SUCCESS",1,0))) as total_pushes 43 | sum(eval(if(eventType="user.authentication.auth_via_mfa" AND 'outcome.result'="SUCCESS",1,0))) as total_successes 44 | sum(eval(if(eventType="user.authentication.auth_via_mfa" AND 'outcome.result'="FAILURE",1,0))) as total_rejected 45 | sum(eval(if(eventType="system.push.send_factor_verify_push" AND 'debugContext.debugData.behaviors' LIKE "%New Device=POSITIVE%",1,0))) as suspect_device_from_source 46 | sum(eval(if(eventType="system.push.send_factor_verify_push" AND 'debugContext.debugData.behaviors' LIKE "%New IP=POSITIVE%",1,0))) as suspect_ip_from_source 47 | values(eval(if(eventType="system.push.send_factor_verify_push",'client.ipAddress',""))) as src 48 | values(eval(if(eventType="user.authentication.auth_via_mfa",'client.ipAddress',""))) as dest 49 | values(*) as * by groupby 50 | | eval ratio = round(total_successes/total_pushes,2) 51 | ```Create a ratio of successful sign ins to pushes. If the push and response come from the same IP, it's likely legit. Note that the current ratio is quite aggressive. Aside from tuning the ratio you could add other conditions, for example: dc Country > 1, other behaviors (NEW Geo-Location=POSITIVE), device.managed=false, client.os!={SOE_OS}``` 52 | | search ((ratio < 0.5 AND total_pushes > 2) OR (total_rejected > 0)) AND dc_ip > 1 AND suspect_device_from_source > 0 AND suspect_ip_from_source > 0 53 | false_positives: 54 | - Depends on how aggressive the ratio is, tune to fit your environment after establishing baselines. -------------------------------------------------------------------------------- /detections/multiple_failed_requests_to_access_okta_applications.yml: -------------------------------------------------------------------------------- 1 | title: Multiple Failed Requests to Access Okta Applications 2 | id: 17dbb021f4a1bb58274136c6441a38ba 3 | description: | 4 | Detects an adversary attempting to reuse a stolen web session cookie in an org with well-configured authentication policies triggering failed policy evaluation events. 5 | Looks for multiple attempts to open app chiclets with no successful response to an authentication challenge. 6 | This detection assumes authentication policies are setup to require re-authentication on every access, especially for high impact applications. 7 | references: 8 | - https://sec.okta.com/shareddetections 9 | author: Okta 10 | created_date: '2023-04-06' 11 | modified_date: '2023-04-06' 12 | threat: 13 | Tactic: 14 | - Discovery 15 | - Defense Evasion 16 | - Lateral Movement 17 | Technique: 18 | - T1550.004: Use Alternate Authentication Material.Web Session Cookie 19 | - T1538: Cloud Service Dashboard 20 | prevention: 21 | - Setup strict authentication policies based on risk of the application being accesssed if compromised. Require strong MFA factors such as Okta FastPass, FIDO2 WebauthN or Okta Number Challenge if phishing-resistance factors are not applicable. 22 | - For high risk applications, ensure re-authentication is configured to every time the app is accessed. This ensures that if a session cookie is stolen, the threat actor will be prompted again for an MFA factor when accessing these apps. 23 | detection: 24 | explanation: | 25 | The query below: 26 | Retrieves policy evaluation and SSO details in events that contain the Application requested. 27 | Formats target fields so we can aggregate specifically on Applications (AppInstances). 28 | Groups by User, Session, and IPs. 29 | Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On policies. 30 | Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than 3 apps. 31 | splunk: | 32 | index=main sourcetype=oktaim2:log target{}.type=AppInstance (eventType=policy.evaluate_sign_on outcome.result=CHALLENGE) OR (eventType=user.authentication.sso outcome.result=SUCCESS) 33 | | eval targets=mvzip('target{}.type', 'target{}.displayName', ": ") 34 | | eval targets=mvfilter(targets LIKE "AppInstance%") 35 | ```Stats per user/session/ip/target app``` 36 | | stats count min(_time) as _time values(outcome.result) as outcome.result dc(eval(if(eventType="policy.evaluate_sign_on",targets,NULL))) as total_challenges sum(eval(if(eventType="user.authentication.sso",1,0))) as total_successes by authenticationContext.externalSessionId targets actor.alternateId client.ipAddress 37 | ```Exclude apps that don't require a challenge``` 38 | | search total_challenges > 0 39 | ```Group events by session/actor/ip``` 40 | | stats min(_time) as _time values(*) as * sum(total_challenges) as total_challenges sum(total_successes) as total_successes values(eval(if('outcome.result'="SUCCESS",targets,NULL))) as success_apps values(eval(if('outcome.result'!="SUCCESS",targets,NULL))) as no_success_apps by authenticationContext.externalSessionId actor.alternateId client.ipAddress 41 | | fillnull 42 | | eval ratio=round(total_successes/total_challenges,2), severity="HIGH", mitre_technique_id="T1538", description='actor.alternateId'. " from " . 'client.ipAddress' . " seen opening " . total_challenges . " chiclets/apps with " . total_successes . " challenges successfully passed" 43 | | fields - count, targets 44 | ```Assuming a majority of apps have good sign-on policies, if we see three apps with ignored challenges, that's worth investigating``` 45 | | search ratio < 0.5 total_challenges > 2 46 | false_positives: 47 | - Depends on how aggressive the ratio is, tune to fit your environment after establishing baselines. -------------------------------------------------------------------------------- /detections/new_api_token_created.yml: -------------------------------------------------------------------------------- 1 | title: New Okta API Token Created 2 | id: f0d9c641e55c89527c263090ed2ea0c8 3 | description: | 4 | Detects a new Okta API token being created by an Okta Administrator. 5 | An adversary with access to an Okta Adminsitrative account may create an API token to maintain persistence in the environment. 6 | references: 7 | - https://developer.okta.com/docs/guides/tokens/ 8 | author: Okta 9 | created_date: '2024-11-07' 10 | modified_date: '2024-11-07' 11 | threat: 12 | Tactic: 13 | - Persistence 14 | Technique: 15 | - T1078: Valid Accounts 16 | prevention: 17 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 18 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 19 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 20 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 21 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 22 | detection: 23 | okta_systemlog: 24 | OIE: | 25 | eventType eq "system.api_token.create" 26 | false_positives: 27 | - Legitimate new Okta API tokens being created for approved integrations -------------------------------------------------------------------------------- /detections/new_idp_created.yml: -------------------------------------------------------------------------------- 1 | title: Creation of a new Okta Identity Provider 2 | id: 5081584907f1037ac2e423866b55c433 3 | description: | 4 | Detects creation of an external identity provider. 5 | Threat actors may configure a second Identity Provider to act as an "impersonation app" to access applications within the compromised Org on behalf of other users. 6 | This second Identity Provider, also controlled by the attacker, would act as a “source” IdP in an inbound federation relationship (sometimes called “Org2Org”) with the target. 7 | references: 8 | - https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection 9 | author: Okta 10 | created_date: '2023-08-31' 11 | modified_date: '2023-08-31' 12 | threat: 13 | Tactic: 14 | - Persistence 15 | - Lateral Movement 16 | Technique: 17 | - T1078: Valid Accounts 18 | - T1550: Use Alternate Authentication Material 19 | prevention: 20 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 21 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 22 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 23 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 24 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 25 | detection: 26 | okta_systemlog: 27 | OIE: | 28 | eventType eq "system.idp.lifecycle.create" 29 | false_positives: 30 | - Legitimate new IDPs being created, should be very rare 31 | - To alert on all events relating to an IDP leverage this query - eventType sw "system.idp.lifecycle" -------------------------------------------------------------------------------- /detections/new_super_admin_added_or_removed.yml: -------------------------------------------------------------------------------- 1 | title: New Okta Super Admin Created or Removed 2 | id: 6b27e2df29e33ac66e321e411b703d02 3 | description: | 4 | Detects when an Okta Super Administrator is either created or removed 5 | An adversary with access to an Okta Administrator my attempt to either: 6 | 1 - Create a new super administrator account for themselves to maintain persistence. 7 | 2 - Revoke all other super administrator privileges to prevent response actions from being taken. 8 | references: 9 | - http://help.okta.com/en-us/content/topics/security/administrators.htm 10 | author: Okta 11 | created_date: '2025-02-11' 12 | modified_date: '2025-02-11' 13 | threat: 14 | Tactic: 15 | - Persistence 16 | - Privilege Escalation 17 | - Defense Evasion 18 | Technique: 19 | - T1078: Valid Accounts 20 | - T1090: Account Manipulation 21 | prevention: 22 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 23 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 24 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 25 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 26 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 27 | detection: 28 | okta_systemlog: 29 | OIE: | 30 | eventType sw "user.account.privilege" and (debugContext.debugData.privilegeRevoked co "Super administrator" or debugContext.debugData.privilegeGranted co "Super administrator") 31 | false_positives: 32 | - Onboarding or offboarding legitimate Okta administrators or service accounts. 33 | - To focus on creation events filter on eventType user.account.privilege.grant, for revocation user.account.privilege.revoke. -------------------------------------------------------------------------------- /detections/oauth_client_secret_read.yml: -------------------------------------------------------------------------------- 1 | title: OAuth Client Secret Read 2 | id: b1a96930c12ac5f3189269680bcc55ac 3 | description: | 4 | Detects an application's oauth client secret being read. 5 | An adversary with access to an Okta Administrator may attempt to read an application's client secret to perform impersonation, token theft or replay attacks. 6 | references: 7 | - https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/ 8 | author: Okta 9 | created_date: '2025-03-11' 10 | modified_date: '2025-03-11' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | Technique: 15 | - T1528: Steal Application Access Token 16 | prevention: 17 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 18 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 19 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 20 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 21 | detection: 22 | okta_systemlog: 23 | OIE: | 24 | eventType eq "app.oauth2.client.read_client_secret" 25 | false_positives: 26 | - Approved changes where a client secret is expected to be copied/viewed for example when setting up the Okta connector in Okta Workflows. -------------------------------------------------------------------------------- /detections/oauth_mismatched_redirect_uri.yml: -------------------------------------------------------------------------------- 1 | title: Oauth Mismatched Redirect URI 2 | id: 24b40c3835be13b6b1828e38c0c248b5 3 | description: | 4 | Detects an unexpected redirect when granting oauth tokens. 5 | An adversary leveraging phishing infrastructure to compromise users may issue redirects to the phishing domain during the oauth flow. 6 | references: 7 | - https://www.oauth.com/oauth2-servers/redirect-uris/ 8 | author: Okta 9 | created_date: '2025-03-11' 10 | modified_date: '2025-03-11' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | Technique: 15 | - T1528: Steal Application Access Token 16 | prevention: 17 | - Configure authentication policies to ensure Okta Fastpass is used in all authentication flows. 18 | - Perform proactive domain monitoring to detect new phishing domains impersonating your brand. 19 | detection: 20 | okta_systemlog: 21 | OIE: | 22 | eventType eq "app.oauth2.token.grant" and outcome.reason eq "mismatched_redirect_uri" and outcome.result eq "FAILURE" 23 | false_positives: 24 | - Expected redirect URIs should be excluded. 25 | - Approved phishing engagements. -------------------------------------------------------------------------------- /detections/opa_password_changed_oob.yml: -------------------------------------------------------------------------------- 1 | title: OPA Server Account Password Changed Out of Band 2 | id: 81e3eb86e6494eeffbcc642f10b591b5 3 | description: | 4 | Detects when a server account password is altered via a method other than OPA scheduled rotation. 5 | Adversaries may attempt to bypass OPA based server access such as MFA. 6 | references: 7 | - https://www.okta.com/products/privileged-access/ 8 | author: Okta 9 | created_date: '2025-05-21' 10 | modified_date: '2025-05-21' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | - Defense Evasion 15 | - Persistence 16 | Technique: 17 | - T1556.006: Modify Authentication Process.Multi-Factor Authentication 18 | - T1562.008: Impair Defenses - Disable or Modify Tools 19 | prevention: 20 | - Security education for admins to leverage OPA for server access opposed to using local server access. 21 | - Periodic auditing of server access to ensure MFA is required through OPA. 22 | detection: 23 | okta_systemlog: 24 | OIE: | 25 | eventType eq "pam.server_account.password_change.out_of_band" 26 | false_positives: 27 | - An admin may manually change the server account password in the event that the OPA scheduled password 28 | rotation had failed. 29 | -------------------------------------------------------------------------------- /detections/phone_number_registered_to_multiple_users.yml: -------------------------------------------------------------------------------- 1 | title: Phone Number Registered to Multiple Users 2 | id: d1e09d985740ae32f8267b0800e3b012 3 | description: | 4 | Detects when a phone number is registered to multiple users. 5 | An adversary may register the same SMS phone number as MFA to multiple accounts they have compromised in order to maintain persistence. 6 | This detections requires the Okta org to allow SMS as an MFA factor. 7 | references: 8 | - Threat Research 9 | author: Okta 10 | created_date: '2025-01-15' 11 | modified_date: '2025-01-15' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | - Defense Evasion 16 | - Persistence 17 | Technique: 18 | - T1556.006: Modify Authentication Process.Multi-Factor Authentication 19 | prevention: 20 | - Require strong MFA factors and do not allow factors such as email or SMS. 21 | - Configure strong Okta account management policies to lock down or place strict restrictions on MFA enrollment 22 | detection: 23 | explanation: | 24 | The query below: 25 | Retrieves events where an SMS phone MFA message is sent, this event includes the Mobile ID and phone number. 26 | Extracts the mobile phone ID from the target fields, this ID is the same when the phone number is the same. 27 | Groups the results by the "MobilePhone" that was used, and counts the distinct number of userIDs that leveraged that respective "MobilePhone" 28 | Alerts when 2 or more unique user IDs were observed using the same mobile phone number for SMS verification. It's recommended to run this query over a longer period of time. 29 | splunk: | 30 | index=main sourcetype=oktaim2:log AND eventType="system.sms.send_phone_verification_message" 31 | | eval targets=mvzip('target{}.type', 'target{}.id', ": ") 32 | | eval targets=mvfilter(targets LIKE "MobilePhone%") 33 | | stats dc(actor.id) as distinct_user_count values(client.ipAddress) as source_ip values(actor.alternateId) as username by targets 34 | | where distinct_user_count >= 2 35 | false_positives: 36 | - Customer identity accounts that leverage a shared phone 37 | - Service accounts leveraging a shared device -------------------------------------------------------------------------------- /detections/rapid_application_access.yml: -------------------------------------------------------------------------------- 1 | title: Rapid Okta Application Access 2 | id: 2c6f8d09fd3f5bc3eb735e293497ca63 3 | description: | 4 | Detects a single user accessing more than 10 distinct applications within 1 minute. 5 | An adversary after gaining initial access may immediately try and open as many applications as possible from the Okta Dashboard before sessions expire. 6 | references: 7 | - null 8 | author: Okta 9 | created_date: '2025-02-11' 10 | modified_date: '2025-02-11' 11 | threat: 12 | Tactic: 13 | - Discovery 14 | Technique: 15 | - T1538: Cloud Service Dashboard 16 | prevention: 17 | - Configure a Re-authentication Frequency of “Every Sign-In Attempt” to all high impact applications. This greatly diminishes access to applications using a stolen user session without persistent access to MFA. 18 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 19 | detection: 20 | explanation: | 21 | The query below: 22 | Filters on events for applications being successfully accessed that are IDP initiated (the application was accessed from the Okta Dashboard). 23 | Extract the Application name being accessed and storing it in the "targets" field. 24 | Set the time span to 1 minute. 25 | Distinct count the applications being accessed and group it by the timespan and username. 26 | Only show results where 10 or more applications were accessed within the timespan. 27 | splunk: | 28 | index=main sourcetype=OktaIM2:log AND eventType="user.authentication.sso" AND debugContext.debugData.initiationType="IDP_INITIATED" AND outcome.result="SUCCESS" 29 | ```Extract Application info from the targets JSON``` 30 | | eval targets=mvzip('target{}.type', 'target{}.alternateId', ": ") 31 | | eval targets=mvfilter(targets LIKE "AppInstance%") 32 | ```Set the timespan to search - Tune to fit your environment``` 33 | | bin _time span=1m 34 | ```Distinct count the Applications being accessed and group by the user and time``` 35 | | stats values(targets) as appname dc(targets) as app_count values(client.ipAddress) as source_ip values(client.userAgent.rawUserAgent) as UserAgent by actor.id actor.alternateId _time 36 | ```only show results where 10 apps were accessed in a minute. Tune to your environment``` 37 | | where app_count >= 10 38 | false_positives: 39 | - Potential automation setups where a service account is expected to be rapidly accessing applications. 40 | - Legitimate end users rapid accessing applications - you can further enrich this by only looking at applications accessed from an anonymizer. -------------------------------------------------------------------------------- /detections/request_to_access_admin_console_from_new_device_or_ip.yml: -------------------------------------------------------------------------------- 1 | title: Request to access Admin Console from new device or IP 2 | id: 832e92ebf3bbf6a6fcb094aefa7e792c 3 | description: | 4 | Detects when a user accesses the Okta Admin Console from a new device or IP. 5 | An adversary may compromise an administrative account and attempt to access the admin console from a new IP or device. 6 | references: 7 | - https://sec.okta.com/leastprivilege 8 | author: Okta 9 | created_date: '2024-11-07' 10 | modified_date: '2024-11-07' 11 | threat: 12 | Tactic: 13 | - Initial Access 14 | - Privilege Escalation 15 | Technique: 16 | - T1078: Valid Accounts 17 | prevention: 18 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 19 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 20 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 21 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 22 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 23 | detection: 24 | okta_systemlog: 25 | OIE: | 26 | eventType eq "policy.evaluate_sign_on" and target.displayName eq "Okta Admin Console" and ((debugContext.debugData.behaviors co "New Device=POSITIVE" and debugContext.debugData.behaviors co "New IP=POSITIVE") OR (debugContext.debugData.logOnlySecurityData co "\"New Device\":\"POSITIVE\"" or debugContext.debugData.logOnlySecurityData co "\"New IP\":\"POSITIVE\"")) 27 | false_positives: 28 | - Okta Admins leveraging a new legitimate corporate device. 29 | - Okta Admins logging into the admin console from a new legitimate IP. -------------------------------------------------------------------------------- /detections/suspicious_mfa_abandonment.yml: -------------------------------------------------------------------------------- 1 | title: Suspicious MFA Abandonment 2 | id: b62937f1267543f143786725e5787b0b 3 | description: | 4 | Detects suspicious patterns associated with MFA abandonment. 5 | An adversary with access to compromised passwords may try to push bomb the victim hoping they accept an MFA prompt. 6 | Note: This is currently early access (as of April 10th, 2025) and must be enabled under "Settings > Features" in the admin console. 7 | references: 8 | - https://help.okta.com/oie/en-us/content/topics/reports/mfa-abandonment.htm 9 | author: Okta 10 | created_date: '2025-04-10' 11 | modified_date: '2025-04-10' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | Technique: 16 | - T1621: Multi-Factor Authentication Request Generation 17 | prevention: 18 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistance with Okta FastPass or FIDO2 WebAuthn. 19 | - Implement passwordless authentication within your Okta tenant (https://help.okta.com/oie/en-us/content/topics/identity-engine/password-optional/password-optional-disabled.htm) 20 | - Require devices authenticating through your Okta tenant to be managed via authentication policies. 21 | detection: 22 | explanation: | 23 | The query below: 24 | Filters on MFA events where the outcome result was either "UNANSWERED" or "ABANDONED". 25 | Groups and counts the results by source IP. Displays the count of unique usernames, the raw usernames and whether the request came from a proxy. 26 | Filters the results to one of three outcomes: 27 | 1. 5 or more MFA abandonment events from a single IP to a single user. 28 | 2. Single IP issuing MFA abandonment to 5 different unique users. 29 | 3. If the MFA abandonment comes from a known proxy. 30 | It's recommended to run this detection over an hour long period. 31 | splunk: | 32 | index=main AND sourcetype=OktaIM2:log AND eventType=user.authentication.auth_via_mfa AND outcome.result IN ("UNANSWERED", "ABANDONED") 33 | | stats earliest(_time) as _time values(actor.alternateId) as username dc(actor.id) as user_count values(securityContext.isProxy) as isProxy values(outcome.reason) as outcome_reason count by client.ipAddress 34 | | where (user_count = 1 AND count > 5) OR (user_count > 5) OR (isProxy = "true") 35 | false_positives: 36 | - Users not responding to legitimate MFA prompts from a corporate VPN IP. 37 | - Company approved IPs being flagged as proxies. -------------------------------------------------------------------------------- /detections/suspicious_use_of_an_Okta_Session_Cookie.yml: -------------------------------------------------------------------------------- 1 | title: Suspicious Use of an Okta Session Cookie 2 | id: 5532601c33db3f51f8db046fe5f9c4c2 3 | description: | 4 | Detects when an IP and browser or OS changes mid-session. 5 | An adversary that has stolen an Okta cookie may attempt to import it into their own device & browser in order to access the account. 6 | This detection looks for one or more policy evaluation events in which multiple client values (IP, UA, etc.) change associated to the same Device Token for a specific user. 7 | references: 8 | - https://sec.okta.com/shareddetections 9 | author: Okta 10 | created_date: '2023-04-06' 11 | modified_date: '2023-04-06' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | Technique: 16 | - T1539: Steal Web Session Cookie 17 | prevention: 18 | - Setup strict authentication policies based on risk of the application being accesssed if compromised. 19 | - For high risk applications, ensure re-authentication is configured to every time the app is accessed. This ensures that if a session cookie is stolen, the threat actor will be prompted again for an MFA factor when accessing these apps. 20 | detection: 21 | explanation: | 22 | The query below: 23 | Retrieves policy evaluation events from successful authentication events. 24 | Aggregates/Groups by Device Token and User, providing the first policy evaluation event in the search window. 25 | Evaluates whether there is more than one IP and whether there is more than one OS or browser for each combination of User/Device Token. 26 | splunk: | 27 | index=main sourcetype=OktaIM2:log eventType IN (policy.evaluate_sign_on) outcome.result IN (ALLOW, SUCCESS) 28 | | stats earliest(_time) as _time values(client.ipAddress) as src_ip values(client.userAgent.rawUserAgent) as user_agent values(client.userAgent.os) as userAgentOS_list values(client.userAgent.browser) as userAgentBrowser_list values(device.os_platform) as okta_device_os dc(client.userAgent.browser) as dc_userAgentBrowser dc(client.userAgent.os) as dc_userAgentOS dc(client.ipAddress) as dc_src_ip values(outcome.reason) as reason by debugContext.debugData.dtHash actor.alternateId 29 | ``` If we see different Operating Systems or Browsers from a UserAccount using with the same DTHash ``` 30 | | where dc_src_ip>1 AND (dc_userAgentOS>1 OR dc_userAgentBrowser>1) 31 | false_positives: 32 | - Environment specific use cases or automations. -------------------------------------------------------------------------------- /detections/threat_insight_high_unknown_users.yml: -------------------------------------------------------------------------------- 1 | title: Threat Insight Alert - Login Failure with High Unknown Users 2 | id: c404d050ea87cfa3f950d43d866c043a 3 | description: | 4 | Detects multiple login failures with high unknown user counts from the same IP accross one or more Okta orgs. 5 | An adversary may leverage known breached credentials to try and spray Okta tenants. 6 | references: 7 | - https://sec.okta.com/shareddetections 8 | - https://help.okta.com/en-us/content/topics/security/threat-insight/configure-threatinsight-system-log.htm 9 | author: Okta 10 | created_date: '2023-04-06' 11 | modified_date: '2023-04-06' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | Technique: 16 | - T1110.004: Credential Stuffing 17 | prevention: 18 | - Configure ThreatInsight to block mode to automatically block these attacks. 19 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistant with Okta FastPass and FIDO2 WebAuthn. 20 | - Implement passwordless authentication within your Okta tenant (https://help.okta.com/oie/en-us/content/topics/identity-engine/password-optional/password-optional-disabled.htm) 21 | detection: 22 | okta_systemlog: 23 | OIE: | 24 | eventType eq "security.threat.detected" AND outcome.reason co "Login failures with high unknown users count" 25 | false_positives: 26 | - Should be rare, certain automation setups might trigger this detection. -------------------------------------------------------------------------------- /detections/threat_insight_password_spray.yml: -------------------------------------------------------------------------------- 1 | title: ThreatInsight - Password Spray 2 | id: 7ad9ac0f4e8979a273263a72c9bd1256 3 | description: | 4 | Detects failed password events across multiple user accounts. 5 | references: 6 | - https://sec.okta.com/shareddetections 7 | - https://help.okta.com/en-us/content/topics/security/threat-insight/configure-threatinsight-system-log.htm 8 | author: Okta 9 | created_date: '2023-04-06' 10 | modified_date: '2023-04-06' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | Technique: 15 | - T1110.003: Password Spraying 16 | prevention: 17 | - Configure ThreatInsight to block mode to automatically block these attacks. 18 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistant with Okta FastPass and FIDO2 WebAuthn. 19 | - Implement passwordless authentication within your Okta tenant (https://help.okta.com/oie/en-us/content/topics/identity-engine/password-optional/password-optional-disabled.htm) 20 | detection: 21 | okta_systemlog: 22 | OIE: | 23 | eventType eq "security.threat.detected" AND outcome.reason co "Password Spray" 24 | false_positives: 25 | - Should be rare, certain automation setups might trigger this detection. -------------------------------------------------------------------------------- /detections/user_denied_access_due_to_session_binding.yml: -------------------------------------------------------------------------------- 1 | title: User Denied Access due to Session Binding 2 | id: 1fae6f177a9b8ab64d8d31781ae5926f 3 | description: | 4 | Detects violations of Okta's built-in ASN binding feature for administrative sessions. 5 | This feature is enabled by default and fires an event when it detects an ASN change mid-session for administrators. 6 | An adversary may steal okta session cookies for an administrative session and import them onto their own device connected to a separate ASN. 7 | references: 8 | - https://sec.okta.com/protectingadminsessions 9 | author: Okta 10 | created_date: '2024-03-21' 11 | modified_date: '2024-03-21' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | Technique: 16 | - T1539: Steal Web Session Cookie 17 | prevention: 18 | - Implement Zero Standing Privileges via Okta Govern Admin Roles (https://help.okta.com/en-us/content/topics/security/governance-admin-roles/govern-admin-roles.htm) 19 | - Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. 20 | - Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions. 21 | - Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn. 22 | - Enforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies. 23 | detection: 24 | okta_systemlog: 25 | OIE: | 26 | eventType eq "security.session.detect_client_roaming" 27 | false_positives: 28 | - If connected to a VPN and have a Proxy agent installed on the machine (Netspoke, Zscaler), initially ASN assigned by VPN provider, and the proxy agent also tries to assign an ASN. -------------------------------------------------------------------------------- /detections/user_reported_suspicious_activity.yml: -------------------------------------------------------------------------------- 1 | title: User Reported Suspicious Activity 2 | id: 71ad731ed751b3c134aac81d830e0aa3 3 | description: | 4 | Detects when an end user clicks "Report Suspicious Activity" on an Okta notification or in the recent activity dashboard. 5 | Alerting on this event will help streamline end user suspicious activity alerts directly to security teams for investigation and incident response. 6 | references: 7 | - https://help.okta.com/en-us/content/topics/security/suspicious-activity-reporting.htm 8 | author: Okta 9 | created_date: '2024-11-07' 10 | modified_date: '2024-11-07' 11 | threat: 12 | Tactic: 13 | - Initial Access 14 | - Persistence 15 | Technique: 16 | - T1078: Valid Accounts 17 | prevention: 18 | - Enable all end-user notifications are enabled within the Okta Admin Console, empowering end-users to report suspicious activity against their own accounts. 19 | - Make employees aware of the reporting process and their ability to terminate their own session in the settings page. 20 | detection: 21 | okta_systemlog: 22 | OIE: | 23 | eventType eq "user.account.report_suspicious_activity_by_enduser" 24 | false_positives: 25 | - End users reporting suspicious activity that is legitimate. -------------------------------------------------------------------------------- /hunts/hunt_app_password_reveal.yml: -------------------------------------------------------------------------------- 1 | title: Hunt on Application Password Reveals 2 | id: c6b5061471596fa92a433d481a86820a 3 | description: | 4 | Detects when a password is revealed for an application within the Okta Dashboard 5 | An adversary with access to a compromised Okta Dashboard may reveal plaintext passwords for applications. 6 | 7 | Detection opportunities: Multiple password reveals across x number of unique applications in a limited time frame. Password reveals from known proxy IPs. 8 | references: 9 | - null 10 | author: Okta 11 | created_date: '2025-03-11' 12 | modified_date: '2025-03-11' 13 | threat: 14 | Tactic: 15 | - Credential Access 16 | Technique: 17 | - T1555: Credentials from Password Stores 18 | prevention: 19 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistance with Okta FastPass and FIDO2 WebAuthn. 20 | - Disable "Password reveal" within the SWA app authentication settings. 21 | detection: 22 | okta_systemlog: 23 | OIE: | 24 | eventType eq "application.user_membership.show_password" 25 | false_positives: 26 | - Legitimate password reveal events for various reasons. 27 | -------------------------------------------------------------------------------- /hunts/hunt_authentication_policy_denies.yml: -------------------------------------------------------------------------------- 1 | title: Hunt on Authentication Policy Blocks 2 | id: 073696c56701806c3ca06a28be18cf07 3 | description: | 4 | Detects when an authentication is blocked via the Okta Authentication Policy. 5 | An adversary with access to a compromised user may attempt to authenticate to applications but get denied due to restrictions in the authentication policy. 6 | references: 7 | - null 8 | author: Okta 9 | created_date: '2025-03-11' 10 | modified_date: '2025-03-11' 11 | threat: 12 | Tactic: 13 | - Initial Access 14 | Technique: 15 | - T1078: Valid Accounts 16 | prevention: 17 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistance with Okta FastPass and FIDO2 WebAuthn. 18 | - Require devices be managed and registered and/or meet strong device assurance policies within Authentication Policies. 19 | detection: 20 | okta_systemlog: 21 | OIE: | 22 | eventType eq "policy.evaluate_sign_on" and outcome.result eq "DENY" 23 | false_positives: 24 | - Legitimate failed policy evaluations due to various reasons. 25 | -------------------------------------------------------------------------------- /hunts/hunt_failed_identity_verification.yml: -------------------------------------------------------------------------------- 1 | title: Identity Verification Failures 2 | id: c889727a8cc9894d35467fbae6187835 3 | description: | 4 | Detects when an ID Proofing attempt failed. Adversaries may try to bypass ID Verification in order to 5 | reset a password, enroll a factor for a user with admin permissions, or unlock an account. 6 | references: 7 | - https://www.okta.com/identity-proofing/ 8 | author: Okta 9 | created_date: '2025-05-21' 10 | modified_date: '2025-05-21' 11 | threat: 12 | Tactic: 13 | - Defense Evasion 14 | Technique: 15 | - T1656: Impersonation 16 | - T1556.006: Modify Authentication Process.Multi-Factor Authentication 17 | prevention: 18 | - At the 3rd party IDV level, configure selfie liveness verification against the user's photo ID. 19 | - Leverage MDL (based on cryptographic signatures to prevent forgery) once it becomes more widely available instead of users scanning their ID. 20 | detection: 21 | okta_systemlog: 22 | OIE: | 23 | eventType eq "user.identity_verification" and outcome.result eq "DENY" 24 | false_positives: 25 | - Selfie image verification may timeout and the user may need to retry for IDV to complete successfully. 26 | -------------------------------------------------------------------------------- /hunts/hunt_failed_number_challenge.yml: -------------------------------------------------------------------------------- 1 | title: Hunt on Failed Number Challenge 2 | id: be422109b2c01d71d0ebd9b1d860ae95 3 | description: | 4 | Detects possible account takeover attempts when a user failed the number challenge during push notification in Okta Verify. 5 | This detection requires number challenge to be enabled and used. 6 | references: 7 | - https://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/configure-okta-verify-options.htm#:~:text=Push%20notification%20(number%20challenge) 8 | - https://support.okta.com/help/s/article/Number-Challenge-for-Okta-Verify 9 | - https://support.okta.com/help/s/article/what-triggers-a-number-challenge-in-okta-verify?language=en_US 10 | author: Okta 11 | created_date: '2025-01-21' 12 | modified_date: '2025-01-21' 13 | threat: 14 | Tactic: 15 | - Credential Access 16 | Technique: 17 | - T1621: Multi-Factor Authentication Request Generation 18 | prevention: 19 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistance with Okta FastPass and FIDO2 WebAuthn. 20 | detection: 21 | okta_systemlog: 22 | OIE: | 23 | debugContext.debugData.pushWithNumberChallengeResponseType eq "OV_WITH_CHALLENGE_RESPONSE_INVALID" 24 | false_positives: 25 | - End users clicking the wrong Okta Verify number challenge during legitimate login activity. 26 | -------------------------------------------------------------------------------- /hunts/hunt_mfa_abandonment.yml: -------------------------------------------------------------------------------- 1 | title: Hunt on MFA Abandonment 2 | id: 1d8e2e061cbf17326933d17f61881b5c 3 | description: | 4 | Detects MFA events that were abandoned. If an MFA prompt is not accepted or completed after a set period of time, it will be abandoned. 5 | An adversary with access to compromised passwords may try to push bomb the victim hoping they accept the MFA prompt. 6 | Note: This is currently early access (as of April 10th, 2025) and must be enabled under "Settings > Features" in the admin console. 7 | references: 8 | - https://help.okta.com/oie/en-us/content/topics/reports/mfa-abandonment.htm 9 | author: Okta 10 | created_date: '2025-04-10' 11 | modified_date: '2025-04-10' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | Technique: 16 | - T1621: Multi-Factor Authentication Request Generation 17 | prevention: 18 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistance with Okta FastPass and FIDO2 WebAuthn. 19 | - Implement passwordless authentication within your Okta tenant (https://help.okta.com/oie/en-us/content/topics/identity-engine/password-optional/password-optional-disabled.htm) 20 | - Require devices authenticating through your Okta tenant to be managed via authentication policies. 21 | detection: 22 | okta_systemlog: 23 | OIE: | 24 | eventType eq "user.authentication.auth_via_mfa" and (outcome.result eq "UNANSWERED" or outcome.result eq "ABANDONED") 25 | false_positives: 26 | - Users not responding to legitimate MFA prompts 27 | - Further filter this to look for multiple instances against a single account or events from known proxies. -------------------------------------------------------------------------------- /hunts/hunt_on_factor_resets.yml: -------------------------------------------------------------------------------- 1 | title: Hunt on Factor Resets 2 | id: b692f1a182193b734597c25df583c526 3 | description: | 4 | Detects MFA factors being resets. 5 | An adversary may reset MFA factors after compromising an account to ensure they can persistently re-authenticate. 6 | references: 7 | - https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection 8 | - https://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/require-phishing-resistant-authenticator.htm?cshid=csh-require-phish-resistant 9 | author: Okta 10 | created_date: '2023-08-31' 11 | modified_date: '2023-08-31' 12 | threat: 13 | Tactic: 14 | - Credential Access 15 | - Defense Evasion 16 | - Persistence 17 | Technique: 18 | - T1556.006: Modify Authentication Process.Multi-Factor Authentication 19 | prevention: 20 | - Configure strict authenticator enrollment policies requiring users to leverage high security methods of enrollment (see references link) 21 | - Design a secure employee verification process when end users call into help desk requesting mfa factor resets 22 | detection: 23 | okta_systemlog: 24 | OIE: | 25 | eventType eq "user.mfa.factor.reset_all" 26 | false_positives: 27 | - Legitimate factor resets when a user receives a new device. Exclude any commonalities relating to your environment and hunt for suspicious mfa resets. -------------------------------------------------------------------------------- /hunts/hunt_rejected_MFA_pushes.yml: -------------------------------------------------------------------------------- 1 | title: Hunt on rejected MFA pushes 2 | id: 052d6fd99943e35c76b75411bd2ecc0e 3 | description: | 4 | Detects when an Okta Verify push notification is rejected. 5 | An adversary with compromised credentials may try to push bomb the victim until they accept the MFA push. 6 | references: 7 | - https://support.okta.com/help/s/article/System-Log-queries-for-attempted-account-takeover?language=en_US 8 | author: Okta 9 | created_date: '2024-07-08' 10 | modified_date: '2024-07-08' 11 | threat: 12 | Tactic: 13 | - Credential Access 14 | Technique: 15 | - T1621: Multi-Factor Authentication Request Generation 16 | prevention: 17 | - Require Okta Number Challenges on all MFA pushes 18 | - Protect sign-in flows by enforcing strong MFA authenticators such as phishing-resistant with Okta FastPass and FIDO2 WebAuthn. 19 | detection: 20 | okta_systemlog: 21 | OIE: | 22 | eventType eq "user.authentication.auth_via_mfa" and debugContext.debugData.pushOnlyResponseType eq "OV_RESPONSE_DENY" 23 | false_positives: 24 | - End users accidentally pressing the wrong button during a push notification 25 | -------------------------------------------------------------------------------- /hunts/hunt_sign_in_attempts_from_proxies.yml: -------------------------------------------------------------------------------- 1 | title: Sign-in Attempts from Anonymizer Proxies 2 | id: fce89e7ad37c483094a637bbb3881e5d 3 | description: | 4 | Detects login attempts from IPs that Okta identifies as anonymizers. 5 | An adversary may attempt to login with compromised credentials from a known anonymizer. 6 | references: 7 | - https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection 8 | - https://help.okta.com/oie/en-us/content/topics/identity-engine/network/create-dynamic-zone.htm 9 | author: Okta 10 | created_date: '2023-08-31' 11 | modified_date: '2023-08-31' 12 | threat: 13 | Tactic: 14 | - Initial Access 15 | Technique: 16 | - T1566: Phishing 17 | - T1078: Valid Accounts 18 | prevention: 19 | - Configure a dynamic network zone blocklist to pro-actively block these proxies. 20 | - Configure authentication policies to only allow authentications from certain approved network ranges. 21 | detection: 22 | okta_systemlog: 23 | OIE: | 24 | eventType eq "user.session.start" and securityContext.isProxy eq "true" 25 | false_positives: 26 | - Customer identity environments where usage of common VPN providers is expected. 27 | - Potential false positives in IP reputation from our service provider. -------------------------------------------------------------------------------- /logs/log_fields.csv: -------------------------------------------------------------------------------- 1 | Field,Example,Description 2 | Actor,null,Information about the identity performing the action identified in Event.EventType 3 | actor.alternateId,example@domain.com,An alternative way to identify the actor. For users this is the username value. 4 | actor.detailEntry,"""detailEntry"": { 5 | ""osVersion"": ""15.2.0"", 6 | ""osPlatform"": ""MACOS"", 7 | ""deviceStatus"": ""ACTIVE"" 8 | }",Optional additional context about the actor. 9 | actor.displayName,Jane Doe,Display name of the identity performing the activity. If the identity is a user this will typically be their full name. 10 | actor.id,00uxxxxxxxxxxxxxxxxx,Unique ID of the identity performing the action. If the entity is a user this will start with 00u. 11 | actor.type,User,"The type of actor associated with the identity, such as a user or application." 12 | ,, 13 | Client,null,Information about the client performing the action identified in the Event.EventType. 14 | client.device,"Computer, Mobile",Type of device performing the action. 15 | client.geographicalContext,null,Metadata pertaining to the geolocation of the client IP. 16 | client.geographicalContext.City,Los Angeles,City the client IP is registered to. 17 | client.geographicalContext.Country/region,United States,Country or region the client IP is registered to. 18 | client.geographicalContext.Geolocation.Lat,-75.068819,Latitude the client IP is registered to. 19 | client.geographicalContext.Geolocation.Lon,124.464726,Longitude the client IP is registered to. 20 | client.geographicalContext.PostalCode,12345,Postal or Zip code the client IP is registered to. 21 | client.geographicalContext.State,Virginia,State or Province the client IP is registered to. 22 | client.id,okta.1234abc-123a-123a-123a-1234568abc,"For OAuth requests, this is the ID of the OAuth client making the request. For SSWS token requests, this is the ID of the agent making the request." 23 | client.ipAdress,8.8.8.8,IP address of the client. 24 | client.userAgent.browser,Chrome,Client Browser of the client derived from the User Agent. 25 | client.userAgent.os,Mac OS X,OS of the client derived from the User Agent. 26 | client.userAgent.rawUserAgent,"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",Raw User Agent String of the client. 27 | client.zone,Corporate IP Range,"A Network Zone name will be present only when it is relevant in the context of policy evaluation. When the Zone is a decisive criteria in determination of the appropriate policy rule, it will be present, otherwise the value will be null" 28 | ,, 29 | Device,null,Device telemetry if applicable. 30 | device.device_integrator,"{""CROWDSTRIKE"":{""....""}}",Metadata from the device if device integration is setup. 31 | device.disk_encryption_type,ALL_INTERNAL_VOLUMES,Type of disk encryption setup on the authenticating device. 32 | device.id,guo....,Unique Okta generated ID of the authenticating Device. 33 | device.managed,TRUE,Boolean value if the device is managed in Okta. 34 | device.os_platform,OSX,Operating system platform. 35 | device.os_version,15.2.0,Operating system version. 36 | device.registered,TRUE,Boolean value if the device is registered in Okta. 37 | device.screen_lock_type,BIOMETRIC,What type of lock is configured on the device locally. 38 | device.secure_hardware_present,TRUE,Boolean value if the device has secure hardware implemented. 39 | ,, 40 | Event.AuthenticationContext,null,Metadata pertaining to the authentication. 41 | authenticationContext.authenticationProvider,"FACTOR_PROVIDER, ACTIVE_DIRECTORY, SOCIAL, LDAP, FEDERATION",Provider verifying user credentials. 42 | authenticationContext.authenticationStep,0,The zero-based step number in the authentication pipeline. Currently unused and always set to 0. 43 | authenticationContext.credentialProvider,"""DUO"" ""GOOGLE"" ""OKTA_CREDENTIAL_PROVIDER"" ""RSA"" ""SYMANTEC"" ""YUBIKEY""","A credential provider is a software service that manages identities and their associated credentials. When authentication occurs through credentials provided by a credential provider, the credential provider is recorded here." 44 | authenticationContext.externalSessionId,idxA1A_111AAA2-22BBB333CCC,"Okta created session ID. All authenticated activities should have an externalSessionId except those that originate from an Okta first party service such as Access Requests, Okta Privileged Access and Workflows. " 45 | authenticationContext.rootSessionId,idxA111AA-AAA222_BBB333CCC,"Identifies events from all sessions that share a common root session. Some actions that can be attributed to a user, such as those taken by an Okta system actor on behalf of a user, may have a different externalSessionId value. The rootSessionId field allows all of those to be identified and grouped together." 46 | authenticationContext.authenticatorContext,null,Context about the authenticator used. 47 | authenticationContext.authenticatorContext.applicationVersion,123.0.1234.123,Version of the application facilitating the authentication. 48 | authenticationContext.authenticatorContext.binaryIdentifier,com.google.Chrome.helper,Process identifier of the application facilitating the authentication. 49 | authenticationContext.authenticatorContext.binaryPath,/Applications/Google Chrome.app/Google Chrome Helper,File path of the application facilitating the authentication. 50 | authenticationContext.authenticatorContext.bindingMethod,LOOPBACK,Binding method used during the authentication; see fastpass whitepaper for details. 51 | authenticationContext.authenticatorContext.requestOrigin,https://{company}.okta.com,Origin header value of the authentication. 52 | authenticationContext.authenticatorContext.signerDistinguishedName,Google LLC,Signer of the application facilitating the authentication. 53 | authenticationContext.authenticatorContext.signerKeyIdentifier,111aaa222bbb333ccc444ddd555eee666,Hash of the signer's key. 54 | authenticationContext.authenticatorContext.userConsent,APPROVED_USER_VERIFICATION,Outcome of user verification. 55 | authenticationContext.authenticatorContext.validationStatus,SUCCESS,Outcome of the authenticator validation. 56 | ,, 57 | displayMessage,Authentication of user via MFA,This is a user friendly display message which conveys the action that the event indicates. 58 | eventType,user.session.access_admin_app,Event identifier of the action being performed see (https://developer.okta.com/docs/reference/api/event-types/). 59 | outcome,null,Metadata pertaining to the outcome of the event. 60 | outcome.reason,INVALID_CREDENTIALS,Reason for the outcome.result. 61 | outcome.result,"SUCCESS, FAILURE, CHALLENGE",The outcome of the action being performed defined in the eventType. 62 | published,2024-12-05T17:23:52.807Z,Timestamp the log event was published in UTC. 63 | securityContext,null,Additional network context for the client IP. 64 | securityContext.asNumber,123456,ASN the client IP is authenticating from. 65 | securityContext.asOrg,palo alto networks inc,Organization the ASN is registered to. 66 | securityContext.domain,example.com,Apex domain the client IP is registered to. 67 | securityContext.isProxy,"true, false","Boolean result if the IP is registered to a proxy or anonymizer service, derived from a service provider." 68 | securityContext.isp,google,ISP the client IP is registered to. 69 | severity,"INFO, WARN, ERROR","Indicates if the log being generated is informational, a warning or an error. " 70 | ,, 71 | DebugContext,null,Extra debug data pertaining to the eventType being logged. 72 | debugContext.debugData.authenticatorMethodChallengeTime,2025-01-10T15:17:49.778Z,Timestamp the user was challenged for an authenticator. 73 | debugContext.debugData.authorizationServer,aus...,Unique ID of configured authorization server. 74 | debugContext.debugData.authorizationServerName,app-prod,Configured name of the authorization server. 75 | debugContext.debugData.behaviors,"{New Geo-Location=NEGATIVE, New Device=NEGATIVE, New IP=NEGATIVE, New State=NEGATIVE, ...}","The result of behavior detection evaluation which is present if behaviors are 76 | evaluated in the request." 77 | debugContext.debugData.clientAuthType,"none, private_key_jwt",Auth type used depending on the grant. 78 | debugContext.debugData.defaultAuthorizationServer,FALSE,Boolean if default authorization server was used. 79 | debugContext.debugData.deviceFingerprint,111aaa222bbb333ccc444ddd555eee666,Client generated unique identifier that is based off of various aspects of the end user’s browser. The device fingerprint is similar to the Device token but it is not stored as a cookie. 80 | debugContext.debugData.dtHash,111aaa222bbb333ccc444ddd555eee666,Hash of the device token. The device token is a backend generated unique string that is returned as a browser cookie. 81 | debugContext.debugData.factor,"SIGNED_NONCE, OKTA_VERIFY_PUSH, OKTA_SOFT_TOKEN, ...",MFA Factor used - SIGNED_NONCE is Okta Fastpass. 82 | debugContext.debugData.grantType,refresh_token,Type of grant being used. 83 | debugContext.debugData.grantedScopes,"offline_access, profile, openid",Scopes that were granted. 84 | debugContext.debugData.keyTypeUsedForAuthentication,PROOF_OF_POSSESSION,Type of MFA being used as configured in the authentication policy. 85 | debugContext.debugData.logOnlySecurityData,"{\""risk\"":{\""level\"":\""LOW\""},\""behaviors\"":{...}",JSON result of the risk level and behaviors of an authentication. In API responses or Log Streams this is stringified JSON with backslashes. 86 | debugContext.debugData.origin,https://{company}.okta.com,Origin header value of the request. 87 | debugContext.debugData.policy,00p..,Authorization Server policy hit for this event. 88 | debugContext.debugData.initiationType,"SP_INITIATIED, IDP_INITIATED",Determines whether the authentication was initiated through a service provider or through the IDP. 89 | debugContext.debugData.requestId,111aaa222bbb333ccc444ddd555eee,Unique ID associated to the request. 90 | debugContext.debugData.redirectUri,https://.okta.com/enduser/callback,Redirect URI associated with an authentication. 91 | debugContext.debugData.requestUrl,/app/google/{appid}/sso/saml/mail,URL of the request. 92 | debugContext.debugData.requestedScopes,openid,Scopes being requested. 93 | debugContext.debugData.responseTime,120,Response time in ms. 94 | debugContext.debugData.risk,Risk{level=LOW},"Contains the level of risk for a particular request (LOW, MEDIUM, or HIGH) dependent on the result of behavior detections." 95 | debugContext.debugData.signOnMode,"OpenID Connect, SAML 2.0",Protocol used to facilitate the authentication. 96 | debugContext.debugData.threatSuspected,TRUE,The event has met enough criteria to be considered a threat. 97 | debugContext.debugData.tunnels,"[{""anonymous"":true,""operator"":NORD_VPN,""type"":""VPN""}]",This will contain details on all relevant proxy or VPN information associated with this IP address. 98 | legacyEventType,core.user.factor.attempt_success,"Refers to the eventtype in the prior generation of the System Log, which is EOL." 99 | transaction.id,111aaa222bbb333ccc444ddd555eee,"Identifies events that have occurred together as part of an operation (for example, a request to the Okta servers) https://developer.okta.com/docs/reference/system-log-query/" 100 | ,, 101 | Request,null,Metadata pertaining to the request. 102 | request.ipChain,"""ipChain"": [{...}] 103 | ","Represents a sequence of network-related information including intermediary systems, firewalls, or security layers involved in the request. This is an array of unnamed objects." 104 | request.ipChain.geographicalContext.City,Pittsburgh,City the IP in the chain is registered to. 105 | request.ipChain.geographicalContext.Country/region,Pennsylvania ,State or Province the IP in the chain is registered to. 106 | request.ipChain.geographicalContext.postalCode,12345,Postal code the IP in the chain is registered to. 107 | request.ipChain.geographicalContext.Geolocation.Lat,-75.068819,Latitude the IP in the chain is registered to. 108 | request.ipChain.geographicalContext.Geolocation.Lon,124.464726,Longitude the IP in the chain is registered to. 109 | request.ipChain.ip,8.8.8.8,IP address in this step of the network chain. 110 | ,, 111 | Target,null,"Metadata pertaining to the target, these fields differs based on the eventType and target.type. This is an array with zero to many unnamed objects within it." 112 | target.alternateId,"example@domain.com, Okta Dashboard, ...","An alternative way to identify the target, generally a name dependent on the Target.Type" 113 | target.detailEntry.SignOnModeType,SAML_2_0,Protocol used to facilitate the authentication to the target application. 114 | target.detailEntry.Expires,2025-01-10T16:17:51.000Z,Time the target will expire. 115 | target.detailEntry.MethodTypeUsed,Use Okta FastPass,Method used depending on the target.type. 116 | target.detailEntryMethodUsedVerifiedProperties,"[DEVICE_BOUND, PHISHING_RESISTANT, USER_VERIFYING, USER_PRESENCE, HARDWARE_PROTECTED]",Properties used for verification depending on the target.type. 117 | target.detailEntry.Subject,00u...,"Subject of the oauth token, usually the user ID that is issuing it." 118 | target.displayName,Jane Doe,"Configured name of the target. Depending on the target.type it could be a full name, policy name, token name, etc. " 119 | target.id,0ua...,"Unique ID of the target, depending on the target.type it could be a user id, policy id, token id, etc. " 120 | target.type,"AppUser, AppInstance, Rule",The target type that the eventType is being performed against. The above fields will be populated based on this type. --------------------------------------------------------------------------------