Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,664 detections
Filters
Last updated
All Time
Detection languages
1,075
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,396
11,792
5,863
5,144
4,864
1,664
Platforms
1,089
590
440
252
122
Products / Services
1,128
476
189
125
116
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
Detects MFA fatigue attacks where a user receives more than 10 MFA push denials within a 10-minute window, followed immediately by a successful authentication from a different IP address. This behavior is indicative of an adversary bombarding a user with push notifications until they are approved, followed by account takeover.
This rule detects potentially compromised accounts by correlating successful device code authentication events that exhibit anomalous characteristics (such as first-time usage, high/medium risk scores, or non-compliant/unmanaged device status) with highly sensitive Azure AD/Graph API administrative operations occurring within 30 minutes of the sign-in.
Detects Entra ID guest (B2B) users performing a sign-in from a previously unseen IP address or country (observed over the last 30 days), followed within a 4-hour window by sensitive file operations in SharePoint, OneDrive, or Teams (e.g., file downloads, exports, or sensitivity label changes). This pattern is indicative of potential account takeover or unauthorized access to sensitive corporate data.
Detects successful sign-ins using legacy authentication protocols (e.g., IMAP, POP3, SMTP AUTH, ROPC) for user accounts that are in scope of a Conditional Access policy requiring multi-factor authentication (MFA). Legacy protocols do not support modern authentication flows, effectively bypassing configured MFA requirements and increasing the risk of credential-based attacks.
Detects a sequence of events within a 30-minute window for a single user, specifically capturing MFA configuration changes (reset/enrollment), authentication, and device registration, occurring outside of typical business hours (20:00 - 06:00). This behavioral pattern is often indicative of an adversary establishing persistence or account takeover after gaining access to a valid account.
This rule detects authentication events for service accounts (matching patterns like 'svc', 'sa', 'service') originating from at least two different countries within a short time window (30 minutes or less), indicating potential credential compromise and anomalous geographic movement.
This rule detects potentially malicious OAuth activity in Azure AD where a user performs a device code authentication flow, followed by a refresh token request from a different, anomalous IP address or geographical location. This behavior is indicative of an attacker who has successfully phished a device code from a user and is now attempting to maintain persistent access to the account via a stolen refresh token.
Detects Microsoft Entra ID (formerly Azure AD) sign-in logs where a single user account authenticates from two different countries within a 10-minute window, which is indicative of potential account compromise or credential sharing.
This rule detects suspicious Azure AD sign-in activity where a user successfully signs in from multiple unusual cities within a 24-hour period. It specifically looks for sign-ins that are not from a trusted network and are not from a compliant device, aggregating successful sign-ins by UserPrincipalName and IpAddress, and flagging if there are 5 or more distinct cities.
Detects NTLM-authenticated network logons (Logon Type 3) originating from loopback IP addresses (127.0.0.1, ::1, or 0.0.0.0). This behavior is often associated with NTLM relay attacks or credential reflection bypass techniques where an adversary forces a local service to authenticate to itself to gain unauthorized access.
Detects network logon events (Logon Type 3) using NTLM authentication where the source IP address is local (127.0.0.1 or ::1). This behavior can be indicative of attempts to interact with local services or perform lateral movement within the same host using credential-based techniques such as 'Pass-the-Hash' or unauthorized access to local resources.
Detects unauthorized SSH public key authentication to the vmanage-admin account on Cisco SD-WAN devices. This behavior is indicative of potential unauthorized persistence or account manipulation using SSH keys. The rule also references monitoring for changes to the PermitRootLogin configuration, which is a common indicator of attempts to enable root access via SSH.
This rule detects successful Azure AD authentication attempts originating from known hosting provider or VPS IP addresses, combined with anomalous behavior such as headless browser user agents, impossible travel, or high-risk sign-in flags. This pattern is indicative of Adversary-in-the-Middle (AiTM) phishing proxies like Evilginx or Bluekit, which attempt to bypass MFA by proxying the authentication process.
Detects successful authentication events from accounts identified as service, managed, or robot accounts (e.g., svc_, sa_, msol, robot) originating from external IP addresses or exhibiting an unusually high number of distinct source IP addresses. This behavior is indicative of potential credential theft, token replay attacks, or unauthorized usage of service account identities.
Detects a non-interactive sign-in using an existing session shortly after the user completes interactive MFA, which can indicate stolen token replay. This rule identifies scenarios where a user successfully completes an interactive multi-factor authentication (MFA) sign-in, and then, within a short time frame (1800 seconds or 30 minutes), a non-interactive sign-in occurs for the same user and session ID. This pattern is indicative of a stolen session token being replayed by an attacker, bypassing subsequent MFA prompts.
Detects successful authentication to Atlassian Jira from an anomalous network source (e.g., proxied or unusual geolocation/ASN) following a period of credential inactivity. This activity is consistent with tactics used by the HellCat ransomware group, who leverage credentials harvested by infostealers (such as Raccoon, Redline, StealC, or Lumma) to gain initial unauthorized access to corporate Jira environments.
This rule detects potential exploitation activity related to CVE-2026-45657 involving the Windows Kernel tcpip.sys driver. It monitors for a combination of system crashes (Kernel-Power 41 or EventLog 6008) correlated with Windows Error Reporting (WER) events referencing 'tcpip.sys', or significant spikes in external authentication attempts occurring shortly before a system crash. The rule aims to identify potential remote code execution attempts manifesting as kernel instability.
Detects anomalous AWS API activity following a console login where the API calls originate from a different IP address within 10 minutes, potentially indicating the replay of stolen session tokens captured via Adversary-in-the-Middle (AiTM) techniques.
Detects anomalous device registration in Azure AD where a device code flow is used to authenticate to the Device Registration Service (DRS) and the resulting device is registered with an 'Unknown' or 'Linux' operating system. This behavior is indicative of an adversary, such as Storm-2372, using tools like AADInternals to perform phantom device registration to bypass conditional access policies by simulating a device without TPM attestation.
This rule monitors for successful external logins occurring on an endpoint that previously demonstrated patterns of suspected MFA fatigue (multiple failed push notifications) and subsequent internal reconnaissance activity (execution of commands used for domain or system discovery). The rule correlates these events to identify potential compromised credentials being actively used for lateral movement or persistence.
Correlates a successful Fortinet SSL VPN session with nltest, net, Get-AD*, AdFind, ldapsearch, WinRS, or WMIC discovery commands for the same account within forty-five minutes. This behavior can indicate an attacker establishing initial access via VPN and then performing internal reconnaissance.
Page 58 of 80