Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
172 detections
Filters
Last updated
All Time
Detection languages
55
54
47
9
3
Contributors
49
37
36
17
8
Categories
44
40
37
34
33
Platforms
142
15
11
10
7
Products / Services
10,643
9,755
6,688
4,418
3,745
MITRE Techniques
70
62
53
52
32
CVEs
1
1
1
IDS Classtypes
1
IDS Protocols
1
Detects events in Okta where there is the eventType of "user.session.impersonation.grant".
This grants access in the context of the user. This could be high privilege admin access.
This grants access in the context of the user. This could be high privilege admin access.
Detects when an administrator or help desk agent resets a user's password or deactivates/resets their MFA factors. This activity, while often legitimate, is a key tactic used by social engineering groups like Muddled Libra (aka Scattered Spider) who are known to 'vishing' (voice-phishing) IT help desks to take over accounts.
Detects when a new administrator role assignment is created within Okta. This activity can indicate privilege escalation, where an attacker gains higher-level permissions, or persistence, where an attacker establishes a way to maintain access to the system over time.
Detects when an administrator role is assigned to a user or group within Okta. This could indicate privilege escalation or persistence by an attacker, or a legitimate administrative action.
This rule detects the creation of an API token within the Okta environment. API tokens can be used for programmatic access to Okta resources, and their creation, especially if unauthorized or unexpected, could indicate an attempt to establish persistence or gain unauthorized access to the identity provider.
This rule detects when an API token is revoked within the Okta environment. API tokens are used for authentication and authorization to access Okta APIs. Revoking a token can be a normal administrative action, but it can also indicate an attempt to disable a compromised token or an adversary attempting to disrupt legitimate access.
This rule detects attempts to access Okta administrative functions when the request is routed through a proxy. This could indicate an adversary attempting to bypass security controls or obscure their origin when performing administrative actions within Okta.
This rule detects when an Okta Policy Rule is either modified or deleted. Monitoring changes to policy rules is crucial as unauthorized modifications or deletions could indicate an attempt to bypass security controls, alter access permissions, or disrupt normal operations within the Okta environment. Such actions could lead to unauthorized access, privilege escalation, or impact the availability of services.
This rule detects when Okta identifies new or unusual activity within the Admin Console. It specifically looks for 'policy.evaluate_sign_on' events targeting the 'Okta Admin Console' where Okta's internal heuristics (debugcontext.debugdata.behaviors or debugcontext.debugdata.logonlysecuritydata) flag the activity as 'POSITIVE' for unusual behavior. This can indicate an adversary attempting to gain or maintain access to administrative functions, or an administrator performing actions that are outside their typical patterns.
This rule detects when Okta FastPass successfully identifies and prevents an authentication attempt originating from a known phishing site. It specifically looks for Okta System Log events where the outcome reason is 'FastPass declined phishing attempt', the outcome result is 'FAILURE', and the event type is 'user.authentication.auth_via_mfa'. This indicates that a user attempted to authenticate via MFA, but Okta FastPass intervened due to a detected phishing attempt.
This rule detects when an application within the Okta environment is either modified or deleted. This activity can indicate administrative changes, potential misconfigurations, or malicious activity aimed at disrupting services or altering access controls.
This rule detects when a Multi-Factor Authentication (MFA) factor is deactivated or all MFA factors are reset for a user within Okta. This activity can indicate an adversary attempting to bypass or disable MFA to gain persistent access to an account.
Detects when an Okta Network Zone is deactivated or deleted. This activity can indicate an attempt to bypass network-based security controls, potentially allowing unauthorized access from untrusted IP ranges or locations. It could be a precursor to other malicious activities or an attempt to hinder forensic investigation.
Detects when an Okta user session starts from an IP address associated with an anonymizing proxy service. This could indicate an attempt to bypass security controls or obscure the true origin of the access.
Detects the creation of new user accounts within Okta. This rule specifically looks for the 'user.lifecycle.create' event type in Okta logs, indicating that a new user account has been provisioned in the identity management system.
Detects when an Okta application Sign-on Policy is modified or deleted. This could indicate an adversary attempting to weaken security controls to gain unauthorized access or maintain persistence.
This rule detects when an end-user within an Okta environment reports suspicious activity associated with their account. This event indicates that a user has actively flagged an action or login as potentially unauthorized or malicious, prompting further investigation.
The following analytic detects the use of default or publicly known named pipes associated with Cobalt Strike. It leverages Sysmon EventID 17 and 18 to identify specific named pipes commonly used by Cobalt Strike's Artifact Kit and Malleable C2 Profiles. This activity is significant because Cobalt Strike is a popular tool for adversaries to conduct post-exploitation tasks, and identifying its named pipes can reveal potential malicious activity. If confirmed malicious, this could indicate an active Cobalt Strike beacon, leading to unauthorized access, data exfiltration, or further lateral movement within the network.
Detects access to Okta admin functions through proxy.
This analytic detects suspicious data transfer activities involving the use of the `split` syscall with the `-b` option, which specifies the size of each output file. This technique can be used by attackers to evade detection by breaking large files into smaller parts, bypassing size-based security controls, and facilitating covert exfiltration of sensitive data. By monitoring for unusual or unauthorized use of the `split` syscall with a specified block size, this analytic helps identify potential data exfiltration attempts.
This analytic identifies the bulk creation of ransomware notes (e.g., .txt, .html, .hta files) on an infected machine. It leverages Sysmon EventCode 11 to detect multiple instances of these file types being created within a short time frame (10 seconds). A detection is triggered if 15 or more unique readme paths are observed. This activity is a strong indicator of an active ransomware attack, where the attacker is notifying the victim of the encryption. If confirmed malicious, this behavior could lead to widespread data encryption, rendering critical files inaccessible and potentially causing significant operational disruption.
Page 4 of 9