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 identifies risky sign-in attempts in Azure Active Directory where the sign-in originates from an IP address that has not been seen before or has been seen fewer than 3 times in the last 29 days for that specific user. It filters out guest users, non-compliant devices, and unmanaged devices, focusing on sign-ins with an aggregated risk level greater than 1 and a sign-in risk level of 50 or higher. Excluded applications are specified to reduce false positives.
This rule detects changes to user multi-factor authentication (MFA) methods within an organization. It identifies when MFA methods are added, removed, or when the default MFA method is changed. This helps audit MFA configuration changes, detect unauthorized or suspicious modifications to authentication methods, support incident response by identifying the actor and timestamp of the change, and ensure compliance with security policies requiring strong authentication.
This rule monitors changes to users' Authenticator app registrations within Azure Active Directory. It detects unauthorized device additions or removals, which can be used by adversaries to bypass multi-factor authentication or maintain persistent access to compromised accounts. The rule parses audit logs for 'Update user' operations specifically targeting 'StrongAuthenticationPhoneAppDetail' to identify both added and removed Authenticator app devices.
This rule detects changes to user multi-factor authentication (MFA) configurations within Azure Active Directory. It identifies when MFA methods are added, removed, or changed for a user, providing details on the actor, target, and the specific changes made. This helps in auditing MFA configuration changes, detecting unauthorized modifications, supporting incident response, and ensuring compliance with security policies.
This rule detects suspicious Okta login attempts where a user successfully passes the initial authentication factor but then fails or abandons a subsequent Multi-Factor Authentication (MFA) challenge, originating from a new IP address, device (user agent), and city combination. It filters out events from known corporate VPN IP addresses to reduce false positives.
This rule detects attempts to disable Multi-Factor Authentication (MFA) within Microsoft 365 services. Specifically, it looks for audit log entries containing the operation 'Disable Strong Authentication.' This action could be performed by an attacker to maintain persistent access to compromised accounts by removing an important security layer.
The analytic detects when a Duo policy is created or updated to allow network-based bypass of two-factor authentication (2FA). It identifies this behavior by searching Duo administrator logs for policy creation or update actions where the networks_allow field is present, indicating that specific networks have been permitted to bypass 2FA requirements. This is achieved by parsing the event description and filtering for relevant policy changes, then aggregating the results by user and administrator details. Detecting this behavior is critical for a Security Operations Center (SOC) because allowing network-based 2FA bypass can significantly weaken authentication controls, potentially enabling unauthorized access if a trusted network is compromised or misconfigured. Attackers or malicious insiders may exploit this policy change to circumvent 2FA protections, increasing the risk of account takeover and lateral movement within the environment. Prompt detection enables SOC analysts to investigate and respond to potentially risky policy modifications before they can be leveraged for malicious purposes.
The following analytic detects instances where a Duo administrator performs a bulk deletion of more than three policies in a single action. It identifies this behavior by searching Duo activity logs for the policy_bulk_delete action, extracting the names of deleted policies, and counting them. If the count exceeds three, the event is flagged. This behavior is significant for a Security Operations Center (SOC) because mass deletion of security policies can indicate malicious activity, such as an attacker or rogue administrator attempting to weaken or disable security controls, potentially paving the way for further compromise. Detecting and investigating such actions promptly is critical, as the impact of this attack could include reduced security posture, increased risk of unauthorized access, and potential data breaches. Monitoring for bulk policy deletions helps ensure that any suspicious or unauthorized changes to security configurations are quickly identified and addressed to protect organizational assets and maintain compliance.
The analytic detects instances where a Duo user's status is changed to "Bypass" for 2FA, specifically when the previous status was "Active." This behavior is identified by analyzing Duo activity logs for user update actions, extracting the status transitions, and filtering for cases where a user is set to bypass multi-factor authentication. This is a critical event for a Security Operations Center (SOC) to monitor, as bypassing 2FA significantly weakens account security and may indicate malicious insider activity or account compromise. Attackers or unauthorized administrators may exploit this change to disable strong authentication controls, increasing the risk of unauthorized access to sensitive systems and data. Early detection of such changes enables rapid investigation and response, helping to prevent potential breaches and limit the impact of credential-based attacks.
The following analytic detects when a Duo user generates a bypass code, which allows them to circumvent multi-factor authentication (2FA) protections. It works by monitoring Duo activity logs for the 'bypass_create' action, renaming the affected object as the user, and aggregating events to identify instances where a bypass code is issued. This behavior is significant for a Security Operations Center (SOC) because generating a bypass code can enable attackers, malicious insiders, or unauthorized administrators to gain access to sensitive systems without the required second authentication factor. Such activity may indicate account compromise, privilege abuse, or attempts to weaken security controls. Early detection of bypass code generation is critical, as it allows the SOC to investigate and respond before an attacker can exploit the reduced authentication requirements, helping to prevent unauthorized access, data breaches, or further lateral movement within the environment. Monitoring for this action helps maintain strong authentication standards and reduces the risk of credential-based attacks.
The analytic detects instances where a Duo policy is created or updated to allow access without two-factor authentication (2FA). It identifies this behavior by searching Duo administrator activity logs for policy changes that set the authentication status to "Allow access without 2FA." By monitoring for these specific actions, the analytic highlights potential attempts to weaken authentication controls, which could be indicative of malicious activity or insider threats. This behavior is critical for a SOC to identify, as bypassing 2FA significantly reduces the security posture of an organization, making it easier for attackers to gain unauthorized access to sensitive systems and data. Detecting and responding to such policy changes promptly helps prevent potential account compromise and mitigates the risk of broader security breaches.
The following analytic detects when a Duo policy is created or updated to allow access without two-factor authentication (2FA) for users in countries other than the default. It identifies this behavior by searching Duo administrator activity logs for policy creation or update actions where the policy description indicates that access is permitted without 2FA for certain user locations. This is achieved by parsing the relevant fields in the logs and filtering for the specific condition of 'Allow access without 2FA.' This behavior is significant for a Security Operations Center (SOC) because bypassing 2FA for any user group or location weakens the organization's security posture and increases the risk of unauthorized access. Attackers or malicious insiders may exploit such policy changes to circumvent strong authentication controls, potentially leading to account compromise, data breaches, or lateral movement within the environment. Early detection of these policy modifications enables the SOC to investigate and respond before attackers can leverage the weakened controls, thereby reducing the risk and impact of a successful attack.
The analytic detects when a Duo policy is created or updated to allow devices without a screen lock requirement. It identifies this behavior by searching Duo administrator activity logs for policy creation or update events where the 'require_lock' setting is set to false. This action may indicate a weakening of device security controls, potentially exposing the organization to unauthorized access if devices are lost or stolen. For a Security Operations Center (SOC), identifying such policy changes is critical, as attackers or malicious insiders may attempt to lower authentication standards to facilitate unauthorized access. The impact of this attack could include increased risk of credential compromise, data breaches, or lateral movement within the environment due to reduced device security requirements.
The analytic detects when a Duo policy is created or updated to allow tampered or rooted devices, such as jailbroken smartphones, to access protected resources. It identifies this behavior by searching Duo administrator activity logs for policy changes where the allow_rooted_devices setting is enabled. This is accomplished by filtering for policy creation or update actions and parsing the policy description for the relevant configuration. Allowing tampered devices poses a significant security risk, as these devices may bypass built-in security controls, run unauthorized software, or be more susceptible to compromise. For a Security Operations Center (SOC), identifying such policy changes is critical because it may indicate either a misconfiguration or a malicious attempt to weaken authentication requirements, potentially enabling attackers to access sensitive systems with compromised devices. The impact of this attack can include unauthorized access, data breaches, and lateral movement within the environment, making prompt detection and response essential to maintaining organizational security.
KQL Query from file: Hunting fasthttp Bruteforce Campaign
KQL Query from file: Sneaky 2FA MDO Detection
KQL Query from file: User Sign-in Activity
KQL Query
Detects suspicious AWS API calls to DeactivateMFADevice and DeleteVirtualMFADevice, which may indicate attempts to disable MFA and evade detection.
This rule detects when the user risk and multi-factor authentication (MFA) registration policy is updated within Azure Active Directory (AAD). Attackers may modify these policies to bypass MFA, weaken security thresholds, facilitate further attacks, or maintain persistence by altering how users authenticate or register for MFA.
'An account could be blocked if there are too many failed authentication attempts in a row. This hunting query identifies if a MFA user account that is set to blocked tries to login to Microsoft Entra ID.
This query has also been updated to include UEBA logs IdentityInfo and BehaviorAnalytics for contextual information around the results.'
This query has also been updated to include UEBA logs IdentityInfo and BehaviorAnalytics for contextual information around the results.'
Page 11 of 13





