Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,667 detections
Filters
Last updated
All Time
Detection languages
1,078
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,456
11,839
5,876
5,155
4,865
1,667
Platforms
1,092
591
440
252
122
Products / Services
1,131
476
189
125
118
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
Detects MFA fatigue or push-bombing attacks where a user account experiences an abnormally high volume of MFA request denials in a short duration (10 minutes), followed by a successful authentication event. The rule specifically looks for evidence where the successful authentication potentially originates from a different IP address than the failed attempts.
Detects phishing emails containing suspicious URLs pointing to PaaS platforms (Azure Static Web Apps, Cloudflare, Firebase) that exhibit credential harvesting characteristics (branded keywords or base64 patterns). The rule correlates these emails with subsequent clicks and a successful M365 sign-in by the same user within 30 minutes of the click, indicating a probable successful credential compromise.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
Detects anomalous sign-in patterns indicative of real-time MFA relay attacks, where a user principal authenticates successfully from multiple distinct IP addresses and geographical locations within a short time window (15 minutes), suggesting the active interception of credentials and MFA challenges by a Phishing-as-a-Service platform.
Detects anomalous sign-in patterns indicative of real-time MFA relay attacks, where a user principal authenticates successfully from multiple distinct IP addresses and geographical locations within a short time window (15 minutes), suggesting the active interception of credentials and MFA challenges by a Phishing-as-a-Service platform.
Detects anomalous sign-in patterns indicative of real-time MFA relay attacks, where a user principal authenticates successfully from multiple distinct IP addresses and geographical locations within a short time window (15 minutes), suggesting the active interception of credentials and MFA challenges by a Phishing-as-a-Service platform.
This rule monitors for successful sign-in events that follow a threshold of failed authentication attempts within a one-hour window, specifically flagging cases where the successful login originated from a new location or a previously unseen device, which is often indicative of successful brute force or password spraying attacks.
Detects anomalous authentication behavior where the same session token or identifier is utilized by multiple distinct IP addresses or User-Agent strings within a short timeframe. This behavior is indicative of Adversary-in-the-Middle (AiTM) attacks, such as those employing Evilginx, where an attacker intercepts and replays stolen session cookies to bypass standard authentication and MFA controls.
Detects successful administrative logins to VMware ESXi, vCenter, or related VDI infrastructure (Horizon) by users who have recently performed a password or MFA reset. This pattern is indicative of a helpdesk-based social engineering attack (vishing) or credential compromise where the attacker regains account access and immediately pivots to critical virtualization management infrastructure to facilitate ransomware deployment.
Detects successful administrative logins to VMware ESXi, vCenter, or related VDI infrastructure (Horizon) by users who have recently performed a password or MFA reset. This pattern is indicative of a helpdesk-based social engineering attack (vishing) or credential compromise where the attacker regains account access and immediately pivots to critical virtualization management infrastructure to facilitate ransomware deployment.
Detects high-privileged Entra ID accounts successfully reaching the verification stage of the Self-Service Password Reset (SSPR) process. While SSPR is automatically enabled for administrative accounts, this activity is anomalous and potentially indicates an attacker focusing on discovered privileged accounts after performing broader enumeration.
Detects high-privileged Entra ID accounts successfully reaching the verification stage of the Self-Service Password Reset (SSPR) process. While SSPR is automatically enabled for administrative accounts, this activity is anomalous and potentially indicates an attacker focusing on discovered privileged accounts after performing broader enumeration.
Detects high-privileged Entra ID accounts successfully reaching the verification stage of the Self-Service Password Reset (SSPR) process. While SSPR is automatically enabled for administrative accounts, this activity is anomalous and potentially indicates an attacker focusing on discovered privileged accounts after performing broader enumeration.
This rule detects a correlation between a successful user login from an IP address not previously seen for that specific user in the last 14 days, followed immediately (within 1 hour) by sensitive administrative operations performed by the same user, such as adding members to roles or modifying application permissions.
Detects successful authentication attempts in Azure AD or Microsoft 365 logs originating from known proxy/VPN service providers or identified by suspicious Python-requests user agent strings. The rule specifically filters for events where MFA was not satisfied, indicating potentially bypassed or failed security controls from potentially malicious infrastructure.
Detects activity associated with the 'BlueKit' session relay tool, which uses the rrweb library to capture and replay user session interactions. This rule identifies web browser network events involving rrweb-related scripts occurring within 10 minutes of a successful user sign-in, indicating a potential Adversary-in-the-Middle (AiTM) phishing attack where credentials and session cookies are being captured.
Detects activity associated with the 'BlueKit' session relay tool, which uses the rrweb library to capture and replay user session interactions. This rule identifies web browser network events involving rrweb-related scripts occurring within 10 minutes of a successful user sign-in, indicating a potential Adversary-in-the-Middle (AiTM) phishing attack where credentials and session cookies are being captured.
Detects user sign-ins that utilize an 'External Authentication Method' within 3 days of a password reset event. This behavior may indicate an adversary has successfully established persistence using a rogue authentication provider (e.g., via a TrustSink or similar malicious configuration) that survives password remediation and is capable of capturing or intercepting subsequent authentication tokens.
Detects Azure AD sign-in events where Multi-Factor Authentication (MFA) was reportedly satisfied by an External Authentication Method (EAM) claim without evidence of a traditional secondary authentication challenge. This behavior is indicative of a 'TrustSink' technique where a rogue or compromised OIDC provider injects a spoofed assertion of MFA success into the authentication token.
This rule identifies sign-in events using an External Authentication Method (EAM) that occur within the 2-day cache window immediately following a certificate or key credential update for an application or service principal in Entra ID. This detection highlights a timeframe where an attacker potentially possessing a compromised old signing key could use it to forge tokens before the Entra cache refreshes.
Page 22 of 80