Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
259 detections
Filters
Last updated
All Time
Detection languages
113
50
38
38
10
Contributors
116
35
20
11
10
Categories
146
101
98
84
80
Platforms
183
108
58
9
5
Products / Services
126
117
59
35
31
MITRE Techniques
18,114
15,633
12,576
8,388
6,215
CVEs
3
3
IDS Classtypes
1
1
IDS Protocols
2
This rule detects suspicious command-line activity related to Duo Security administration. It looks for processes executing with 'duo_client', 'duo_admin', or 'duo_api' in their command line, combined with sensitive parameters like '--admin-api', '--key', '--secret', or 'token'. The rule specifically excludes processes spawned by 'powershell.exe' or 'cmd.exe' to reduce noise, and triggers if such activity occurs at least twice within an hour on the same computer by the same user. This could indicate an attempt to manipulate Duo Security configurations, potentially to bypass multi-factor authentication.
This rule detects suspicious command-line activity related to Duo Security administration. It looks for processes executing with 'duo_client', 'duo_admin', or 'duo_api' in their command line, combined with sensitive parameters like '--admin-api', '--key', '--secret', or 'token'. The rule specifically excludes processes spawned by 'powershell.exe' or 'cmd.exe' to reduce noise, and triggers if such activity occurs at least twice within an hour on the same computer by the same user. This could indicate an attempt to manipulate Duo Security configurations, potentially to bypass multi-factor authentication.
This rule detects the creation of Okta API tokens with broad administrative scopes (okta.users.manage, okta.factors.manage, or okta.apps.manage) by the same user multiple times within a one-hour window. This behavior can indicate an attempt to establish persistent access or bypass multi-factor authentication.
This rule detects potential multi-factor authentication (MFA) bypass attempts for privileged accounts. It identifies instances where an administrative user attempts 10 or more sign-ins from 3 or more unique devices within a 5-minute window, specifically when the authentication method is 'Push notification to app' and the result type is '0' (success). This behavior could indicate an adversary attempting to bypass MFA for a privileged account.
This rule detects attempts to modify or delete Multi-Factor Authentication (MFA) provider configurations via the Microsoft Graph API. Specifically, it looks for HTTP DELETE requests to 'graph.microsoft.com' with a URI containing 'authentication'. This activity could indicate an attacker attempting to disable or alter MFA settings to gain unauthorized access or maintain persistence.
Detects Okta Multi-Factor Authentication (MFA) factor enrollment, activation, update, and reset events. These events may indicate an attacker adding their own MFA factor post-compromise to maintain access or removing an existing factor to weaken account security and facilitate unauthorized access.
Detect when users are authenticating without MFA being required.
Detects disabling of Multi Factor Authentication.
Detects when an attempt at deactivating or resetting MFA.
This rule detects successful sign-ins to Microsoft 365 services that occur via legacy authentication protocols. These protocols (e.g., Exchange ActiveSync, IMAP4, POP3, SMTP AUTH) do not support modern authentication methods like Multi-Factor Authentication (MFA) or Conditional Access policies, making them a potential bypass vector for adversaries who have compromised user credentials. The rule identifies the user, the specific legacy client application used, and provides details on the source IP address and country.
This rule detects when multi-factor authentication (MFA) or strong authentication settings are disabled or removed for a user account. It specifically looks for successful audit log entries related to operations such as 'Disable Strong Authentication', 'Update user', 'Update StsRefreshTokensValidFrom', 'Admin registered security info', or 'Admin deleted security info'. This activity could indicate an adversary attempting to maintain persistent access to a compromised account by weakening its authentication requirements.
This rule detects suspicious activity where an 'unfamiliar sign-in properties' alert occurs shortly after an administrator has changed a user's Multi-Factor Authentication (MFA) method. It correlates security alerts for unfamiliar sign-ins with audit logs indicating MFA method changes for the same user within a short timeframe. The rule then checks if the user's sign-in activity shows multiple IP addresses or locations, indicating a potential compromise or MFA bypass after the change.
Detects Okta MFA device enrollment or life cycle changes that occur shortly after a successful authentication or password reset for the same user. This pattern is a strong indicator of a post-vishing account takeover, as seen in ShinyHunters campaigns.
Detects when a new Multi-Factor Authentication (MFA) method is registered shortly after a successful sign-in from an unfamiliar or risky location. This pattern is a strong indicator of an Adversary-in-the-Middle (AiTM) attack where the threat actor, having bypassed MFA to gain initial access, immediately adds their own authentication method to establish persistence on the account.
This KQL Query helps to keep an eye on accounts that are being excluded from Conditional Access (CA) policies which they should be blocked by it and which specific field triggered the CA detection and got them excluded.
The aim of this case is to identify:
Spot CA policies with a high number of exclusions.
Find exclusions that don’t make sense, like skipping MFA when it’s mandatory for privileged accounts.
Catch new exclusions that might not have been approved.
Check how exclusions are actually working (e.g., excluding a device is fine, but if it’s connecting from risky countries or open networks, that’s a problem—hopefully, other CA policies cover this).
Identify unexpected exclusions, which could mean an attacker got in and excluded themselves to bypass CA controls
The aim of this case is to identify:
Spot CA policies with a high number of exclusions.
Find exclusions that don’t make sense, like skipping MFA when it’s mandatory for privileged accounts.
Catch new exclusions that might not have been approved.
Check how exclusions are actually working (e.g., excluding a device is fine, but if it’s connecting from risky countries or open networks, that’s a problem—hopefully, other CA policies cover this).
Identify unexpected exclusions, which could mean an attacker got in and excluded themselves to bypass CA controls
Detects when a successful multi-factor authentication (MFA) occurs due to the use of a bypass code in Cisco Duo. Bypass codes are temporary passcodes created by administrators for specific users to access Duo-protected applications, typically used as backup codes when users cannot use their enrolled devices. This rule identifies instances where such a bypass code facilitates a successful authentication.
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.
This detection identifies single-factor ROPC (Resource Owner Password Credentials) logins from new countries not seen in the last 14 days for a given user+app combination. ROPC authentication does not support MFA, making it a frequent vector for attackers to bypass MFA misconfigurations and gain initial access or escalate privileges in Azure AD.
Detects successful authentication attempts originating from clients using legacy authentication methods, identifiable via specific user agent strings. This activity can indicate an adversary attempting to bypass multi-factor authentication (MFA), potentially as part of a password spray attack. Legacy authentication protocols often do not support modern MFA mechanisms, making them a target for attackers who have obtained valid credentials through other means or are performing brute-force attacks like password spraying.
Detects when users successfully authenticate to Azure AD using only single-factor authentication, indicating that MFA was not required or was bypassed. This could be due to misconfiguration, an attacker bypassing MFA, or legitimate exceptions.
This rule detects when a user registers security information, which indicates a change to their authentication method. This could be an attacker adding an authentication method to a compromised account to maintain persistent access.
Page 10 of 13