Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,666 detections
Filters
Last updated
All Time
Detection languages
1,077
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,439
11,829
5,873
5,151
4,864
1,666
Platforms
1,091
590
440
252
122
Products / Services
1,130
476
189
125
118
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
This rule detects a suspicious sequence of events where a user performs an unusual device-code authentication (potentially indicative of device code phishing) followed shortly by an OAuth application consent or permission grant event. It flags potential compromise if the sign-in is new for the user or occurs in a short timeframe, with optional indicators associated with the 'maillive.sbs' phishing infrastructure.
Detects anomalous device-authorization-grant (RFC 8628) activity indicative of device-code phishing attacks (e.g., Tycoon2FA). The rule identifies user accounts exhibiting a rapid succession of 'authorization_pending' (70016) status polling attempts followed by a successful token issuance (0), constrained to a short time window and excluding known first-party Microsoft CLI/dev-tool applications.
Detects anomalous authentication patterns associated with AI agent or service account credentials. The rule monitors for logins originating from multiple disparate network locations, ASNs, or countries within a 15-minute window, and detects unexpected MFA challenges directed at accounts that typically function as automated, headless identities.
This rule detects potential adversary-in-the-middle (AiTM) session hijacking by monitoring non-interactive sign-in events. It identifies when a refresh token is redeemed from a device identifier that does not exist in the user's recent interactive sign-in history and from a geographical location different from the user's last known interactive session.
Detects potential session cookie replay attacks by identifying sign-in events using SSO or session tokens from different IP addresses, geographic locations, or devices compared to an established user baseline, without a corresponding fresh MFA challenge in the same timeframe. This behavior is indicative of unauthorized access to an already-authenticated session.
Detects successful authentication events to Snowflake cloud data warehouse platforms where no secondary authentication factor (MFA) was registered or triggered. This pattern is indicative of potential credential stuffing or reuse attacks, particularly those involving stolen credentials from infostealer malware, where MFA was not configured or successfully bypassed.
Detects a sequence of authentication activity indicative of a credential stuffing attack. The rule identifies a burst of failed password-only authentication attempts followed by a successful authentication for the same account. It requires that the IP address used for the successful login overlaps with the set of IPs that initiated the failed attempts, effectively filtering out typical user noise and highlighting potentially malicious activity where an attacker has identified a valid credential.
Detects a sequence of authentication activity indicative of a credential stuffing attack. The rule identifies a burst of failed password-only authentication attempts followed by a successful authentication for the same account. It requires that the IP address used for the successful login overlaps with the set of IPs that initiated the failed attempts, effectively filtering out typical user noise and highlighting potentially malicious activity where an attacker has identified a valid credential.
Detects MFA-fatigue style attacks (push-bombing) against Microsoft 365 accounts. The rule identifies a pattern where a user experiences a high frequency of MFA challenges or denials (at least 5 within a 10-minute window) immediately followed by a successful sign-in from a previously unseen IP and device, excluding phishing-resistant authentication methods and break-glass accounts.
This rule correlates phishing emails containing URLs with successful, MFA-satisfied sign-ins from an ASN or network location that has not been associated with the user account within the previous 30 days. This pattern is highly indicative of an Adversary-in-the-Middle (AiTM) session hijacking attempt, where a user is phished and their session cookie is intercepted by an attacker.
Detects a suspicious sequence of events involving NetScaler ADC or Gateway appliances: anomalous account authentication, followed by the establishment of a VPN or remote access session, and subsequent unusual outbound network activity indicating potential lateral movement or C2 communication from the appliance.
This rule detects anomalous sign-in behavior for Azure Service Principals by comparing current activity against a 14-day baseline. It alerts on sign-ins from new ASNs or countries, significant spikes in sign-in volume, or unauthorized access to sensitive resources such as Microsoft Graph, Exchange Online, or Azure Key Vault, while filtering out known cloud egress ranges.
This rule detects potential brute-force activity against remote access services (OpenVPN, StrongSwan, WireGuard, and SSH) on Linux hosts by monitoring Syslog for patterns indicating repeated failed authentication attempts. It further highlights instances where a burst of failed attempts is followed by a successful authentication for the same source IP, indicating a potential successful compromise.
This rule detects successful non-interactive sign-ins to high-value applications (e.g., Office 365, Azure, Okta) where no multi-factor authentication (MFA) challenge was performed during the current session. Such activity is a strong indicator of session hijacking or token replay attacks, where adversaries reuse stolen session cookies to bypass interactive login requirements and MFA.
Detects a sequence of authentication activity indicative of a credential stuffing attack. The rule identifies a burst of failed password-only authentication attempts followed by a successful authentication for the same account. It requires that the IP address used for the successful login overlaps with the set of IPs that initiated the failed attempts, effectively filtering out typical user noise and highlighting potentially malicious activity where an attacker has identified a valid credential.
This rule detects a credential-based attack where a single source IP performs multiple failed RDP (LogonType 3/10) attempts against various user accounts, followed by a successful authentication from the same source within an hour. This pattern is indicative of password spraying or brute-forcing followed by successful lateral movement via Remote Desktop.
Detects an anomalous OfficeHome sign-in from an unmanaged device that completes secondary auth (error 50074) followed by a keep-me-signed-in event (error 50140), with the same session/user then rapidly accessing multiple sensitive applications (My Apps, My Profile, Account Controls, My SignIns, SharePoint/OneDrive/Outlook) - consistent with AiTM-assisted MFA bypass and persistent session establishment
Device code authentication flow completed, followed by subsequent session activity from a different IP/user-agent, indicating token replay to an attacker-controlled client that bypasses MFA
Detects a suspicious sequence of events involving NetScaler ADC or Gateway appliances: anomalous account authentication, followed by the establishment of a VPN or remote access session, and subsequent unusual outbound network activity indicating potential lateral movement or C2 communication from the appliance.
Detects a suspicious sequence of events involving NetScaler ADC or Gateway appliances: anomalous account authentication, followed by the establishment of a VPN or remote access session, and subsequent unusual outbound network activity indicating potential lateral movement or C2 communication from the appliance.
Detects Microsoft Entra ID (formerly Azure AD) sign-in attempts that use the specific, hardcoded User-Agent string associated with the TeamFiltration tool. This tool is frequently used for mass credential testing against Microsoft 365 environments. The detection looks for a suspicious and outdated combination of Teams, Electron, and Chrome versions that would not be present in legitimate, modern Microsoft Teams client traffic.
Page 6 of 80