Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
455 detections
Filters
Last updated
All Time
Detection languages
251
67
56
42
18
Contributors
196
63
61
18
17
Categories
20,417
11,806
5,870
5,145
4,864
Platforms
335
226
118
16
13
Products / Services
292
184
60
48
42
MITRE Techniques
301
233
146
139
97
CVEs
8
7
2
2
IDS Classtypes
2
2
2
IDS Protocols
6
Detects sign-in patterns indicative of Adversary-in-the-Middle (AiTM) phishing attacks such as EvilProxy or Tycoon2FA. The rule identifies a sequence where a user fails an MFA challenge (using codes 50074 or 50140) followed by a successful authentication within a short period (1 hour) where the MFA claim appears as 'Previously satisfied' or 'already succeeded' from a different IP address or user-agent string, suggesting the session was stolen or replayed.
Detects potential help-desk impersonation or social engineering activity involving account credential or MFA method resets, followed shortly by a sign-in from an unknown device or geography. The rule excludes activity tied to established ticketing systems or standard automated password expiration processes.
Detects potential help-desk impersonation or social engineering activity involving account credential or MFA method resets, followed shortly by a sign-in from an unknown device or geography. The rule excludes activity tied to established ticketing systems or standard automated password expiration processes.
Detects Azure sign-in events claiming successful hardware-key or FIDO2 authentication where the authentication issuer is not part of a known-good allow-list. This behavior is indicative of a rogue MFA provider, such as the TrustSink attack, which issues forged tokens claiming MFA requirements were satisfied.
Detects a suspicious sequence of identity-related operations performed by a single user within a 2-hour window. The chain consists of a password reset, MFA method modification, new device registration, and a subsequent privilege escalation event (such as role assignment or application consent). This pattern is consistent with helpdesk-vishing campaigns often used by threat actors like Scattered Spider to perform full account takeovers.
Detects instances where a user successfully authenticates via the OAuth Device Code flow using an unmanaged or non-compliant device, followed closely by high-privileged Azure/Graph API administrative actions within a short timeframe. This behavior is indicative of a device-code phishing attack aimed at bypassing MFA controls, including FIDO2/passkeys, by compromising an active session.
Detects evidence of account persistence and potential mailbox manipulation following an anomalous sign-in event in Google Workspace. The rule identifies suspicious post-compromise activity such as the addition of new MFA methods, new OAuth application grants, or mailbox forwarding/inbox rules, which are consistent with the reuse of captured authenticated sessions.
Detects instances where a privileged account (such as an administrator or helpdesk user) removes MFA security information or resets a password for a target account, followed shortly (within 4 hours) by a sign-in attempt from that same target account exhibiting risk characteristics such as impossible travel or unfamiliar features. This pattern is often associated with social engineering attacks, such as those attributed to Scattered Spider, where an attacker coerces support staff to disable MFA protections for an account.
Detects a sequence of events where a user with a high-risk or compromised sign-in status registers a new device in Entra ID shortly after the event, followed by subsequent sign-ins from that device that bypass multi-factor authentication (MFA) via Conditional Access policies.
Detects MFA relay phishing kits (such as Bluekit) where the MFA challenge is satisfied by an attacker-controlled proxy rather than the legitimate user device. The rule identifies sign-in attempts where the primary authentication request originates from one network location, while the MFA completion step originates from a different network location, and the MFA claim indicates it was satisfied via a proxied token.
Detects high-frequency authentication attempts originating from user agents associated with automation frameworks (Selenium, Playwright, Puppeteer, etc.). This pattern is often indicative of automated credential stuffing, brute force attacks, or CAPTCHA/2FA bypass attempts orchestrated by headless browsers.
Detects high-privilege user accounts (e.g., executives, administrators) undergoing a credential or MFA reset, followed by an atypical sign-in event within a two-hour window. This pattern is indicative of potential account takeover or identity-compromise scenarios, often associated with help-desk vishing attacks where an attacker induces a user or administrator to reset credentials or MFA methods.
Detects MFA or credential reset activities on high-value or privileged accounts that lack a corresponding out-of-band verification signal, such as manager approval or identity proofing, within a one-hour window. This behavior is indicative of social engineering attempts where attackers manipulate help-desk procedures to bypass identity protections.
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 evidence of account persistence and potential mailbox manipulation following an anomalous sign-in event in Google Workspace. The rule identifies suspicious post-compromise activity such as the addition of new MFA methods, new OAuth application grants, or mailbox forwarding/inbox rules, which are consistent with the reuse of captured authenticated sessions.
Detects successful cloud console login events across AWS, Azure, and GCP where multi-factor authentication (MFA) was not utilized, combined with impossible travel indicators (login from different countries within an 8-hour window for the same principal).
Detects unauthorized or suspicious modifications to Azure Active Directory (Azure AD) Conditional Access Policies. This includes deleting a policy, disabling an enabled policy, narrowing the scope of users or groups targeted by a policy, or removing MFA requirements from existing policies.
This rule detects modifications to multi-factor authentication (MFA) settings performed by privileged users (e.g., Global Admins) from IP addresses not previously associated with their account. The rule tracks actions such as registering new security information, changing default MFA methods, or deleting authentication methods. High-risk indicators like an unknown IP address for a privileged account are flagged for further investigation.
This rule detects modifications to multi-factor authentication (MFA) settings performed by privileged users (e.g., Global Admins) from IP addresses not previously associated with their account. The rule tracks actions such as registering new security information, changing default MFA methods, or deleting authentication methods. High-risk indicators like an unknown IP address for a privileged account are flagged for further investigation.
Detects modifications to Microsoft 365 tenant configurations that weaken security posture, specifically the disabling of Security Defaults or the re-enabling of legacy/basic authentication methods (e.g., POP, IMAP, ActiveSync).
Detects modifications to Microsoft Entra ID (formerly Azure AD) Conditional Access policies that lower security posture. This includes disabling policies, switching them to report-only mode, removing Multi-Factor Authentication (MFA) or grant control requirements, or expanding exclusion lists to exempt users, groups, or locations from security controls. Such modifications are often indicative of an adversary attempting to maintain persistent access or bypass MFA requirements.
Page 3 of 22