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
Detects successful sign-ins where Multi-Factor Authentication (MFA) was approved using the 'PhoneAppOTP' method, specifically where the method was registered by the user prior to the observed sign-in timeframe. This pattern can indicate an adversary using an actor-controlled MFA device registered previously to maintain persistent access to a compromised account.
This rule detects administrative updates to a user account in Azure Active Directory (Microsoft Entra ID) that involve modifying authentication methods to include 'SoftwareTokenActivated' associated with HMAC-SHA1 and specific authentication type configurations. Such modifications may indicate an adversary attempting to register a new MFA device or method to maintain persistence or bypass existing security controls.
Detects changes to user authentication methods, such as activating software tokens, registering new security information, or changing MFA configuration. This activity can indicate an adversary attempting to modify MFA settings to maintain persistent access or bypass account security controls.
Detects the registration of a new MFA authentication method (software OTP token or authenticator app) on an Azure AD account, specifically when triggered with 'NO_DEVICE' or 'NO_DEVICE_TOKEN' markers and 'SoftwareTokenActivated' tags. This behavior is indicative of potential attacker persistence following account compromise where a new MFA device is added for future access.
Detects the registration of a new MFA authentication method (software OTP token or authenticator app) on an Azure AD account, specifically when triggered with 'NO_DEVICE' or 'NO_DEVICE_TOKEN' markers and 'SoftwareTokenActivated' tags. This behavior is indicative of potential attacker persistence following account compromise where a new MFA device is added for future access.
Detects when a user registers a new MFA or authentication method, such as a software token or authenticator app, within one hour of a suspicious sign-in event. This pattern is commonly indicative of an adversary establishing persistence or bypassing authentication controls following account compromise via phishing or credential harvesting.
This rule monitors for security-related account activities in Azure AD, specifically tracking self-service password resets, admin-led password resets, and changes to user security information. It aggregates these events by user to identify potential account manipulation, unauthorized password changes, or MFA registration abuse.
Detects modifications to a user's multi-factor authentication (MFA) settings, including changes to registered phone numbers, authenticator app configurations, or the registration of new authentication methods. This activity can indicate an attempt to weaken security defenses or gain persistent, unauthorized access to an account via MFA bypass.
Detects modifications to a user's Azure Active Directory (Entra ID) account involving the addition of a new MFA authentication method or device, such as software tokens or mobile devices. This activity is often performed by an adversary to establish persistence by registering a device they control for future authentication bypass.
Detects service-principal/workload-identity sign-ins occurring without an enforced Conditional Access policy — a gap CISA's red team exploited for unauthorized cloud access.
Correlates Microsoft Entra identity risk detections with subsequent password changes, MFA registrations, and security information modifications. Helps identify potential account compromise scenarios where authentication methods or credentials are altered after suspicious sign-in activity.
This rule detects a potential security risk by identifying instances where a user registers a new security information method (e.g., FIDO2/Passkey) and subsequently logs in using that same authentication method within a 15-minute window. This pattern may indicate an attacker who has gained initial access or compromised credentials and is attempting to establish persistence or facilitate further account takeovers by registering their own multifactor authentication device.
This rule detects a potential security risk by identifying instances where a user registers a new security information method (e.g., FIDO2/Passkey) and subsequently logs in using that same authentication method within a 15-minute window. This pattern may indicate an attacker who has gained initial access or compromised credentials and is attempting to establish persistence or facilitate further account takeovers by registering their own multifactor authentication device.
This rule detects potential account takeover or persistent access via MFA manipulation by correlating recent MFA-related sign-in failures with subsequent successful identity management operations such as updating security info or registering a new MFA method. This behavior pattern is frequently associated with Adversary-in-the-Middle (AiTM) phishing or vishing attacks where an attacker compromises credentials, overcomes MFA challenges, and then establishes their own MFA device to maintain persistent access.
Detects a user registering a new MFA or authentication method within a short window after multiple failed Entra ID sign-in attempts, without a corresponding verified helpdesk password-reset ticket. This pattern is indicative of vishing or helpdesk-impersonation attacks aimed at hijacking user accounts by circumventing MFA controls.
Detects Okta MFA factor re-enrollment immediately preceded by a burst (>=2) of failed MFA authentication challenges within 15 minutes, indicating attacker-driven MFA takeover following AiTM credential theft.
This rule detects potentially malicious activity where an attacker, having performed a password reset or MFA change on a compromised account, attempts to hide their tracks by rapidly deleting security-related notification emails (e.g., password reset alerts) shortly after they arrive in the user's mailbox. It correlates Exchange mailbox operations with audit log account security changes to filter out routine noise.
Detects Okta accounts that enroll a new MFA factor within a short window after multiple failed or abandoned MFA authentication attempts. This behavior is indicative of an attacker who has compromised credentials and is attempting to establish persistent access by bypassing or reconfiguring MFA. The rule includes logic to exclude legitimate self-service enrollments that have a corresponding verified helpdesk or change-management ticket.
This rule detects potential account takeover or persistent access via MFA manipulation by correlating recent MFA-related sign-in failures with subsequent successful identity management operations such as updating security info or registering a new MFA method. This behavior pattern is frequently associated with Adversary-in-the-Middle (AiTM) phishing or vishing attacks where an attacker compromises credentials, overcomes MFA challenges, and then establishes their own MFA device to maintain persistent access.
This rule detects when a user registers a new multi-factor authentication (MFA) method from an Autonomous System Number (ASN) that the user has not used for authentication in the previous 30 days. This behavior is indicative of potential account takeover or an adversary setting up persistent MFA access from a new location.
This rule detects modifications to Google Workspace user account recovery methods, including the generation or deletion of 2SV (2-Step Verification) backup scratch codes, and changes to recovery email addresses or recovery phone numbers. These actions are often performed during account takeover attempts to establish persistence or facilitate bypassing MFA.
Page 7 of 13