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,443
11,831
5,872
5,155
4,866
1,666
Platforms
1,091
591
441
252
122
Products / Services
1,130
476
189
125
117
MITRE Techniques
945
843
438
416
413
CVEs
12
12
9
6
5
IDS Classtypes
1
1
Detects successful sign-ins to the Microsoft Intune Company Portal (AppId '9ba1a5c7-f17a-4de9-a1f1-6178c8d51223') where Conditional Access Policies (CAP) have failed. This indicates an attempt to bypass device compliance requirements, potentially allowing access from non-compliant or unmanaged devices.
Detects when a single user account successfully signs in from two or more distinct IP addresses within a short timeframe. This can be an indicator of an adversary-in-the-middle (AiTM) attack where both the legitimate user and the attacker have active, authenticated sessions from different locations.
This rule detects successful SSH authentications using the GSSAPI-with-MIC mechanism. This can indicate legitimate user logins or, in some cases, an adversary using valid credentials to access a system via SSH.
Detects when a successful AWS Console Login is immediately followed by discovery actions from the same user and IP address. This pattern is indicative of an attacker performing reconnaissance after gaining initial access, as seen in recent AWS phishing campaigns.
This rule detects potential brute force or credential stuffing attacks against Azure AD by identifying multiple failed sign-in attempts followed by a successful sign-in from the same user and IP address within a short time frame (1 minute). It specifically looks for scenarios where the successful sign-in occurs after the failed attempts and involves different applications, excluding common Office 365 services to reduce noise.
This rule detects interactive logons (LogonType 10) where a single account from the same domain logs into multiple distinct devices. This could indicate an attacker using compromised credentials to move laterally within the network or access multiple systems.
Detects successful Entra ID sign-ins that exhibit characteristics of an Adversary-in-the-Middle (AiTM) session cookie hijack.
This activity is often associated with AiTM phishing kits like Tycoon2FA, where attackers replay stolen session cookies from unmanaged devices to bypass MFA.
This activity is often associated with AiTM phishing kits like Tycoon2FA, where attackers replay stolen session cookies from unmanaged devices to bypass MFA.
This rule detects network connections and user sign-ins originating from IP addresses identified as belonging to Iran. It also identifies sign-ins where the reported country is Iran, but the IP address is not found within the provided Iranian IP list, which could indicate IP geolocation discrepancies or obfuscation attempts.
This detection identifies when a user clicks a URL in an email and shortly after, a risky sign-in is detected for the same user account. This pattern is indicative of a successful phishing attack, where a user is lured to a malicious site, enters their credentials, and the attacker uses those credentials or the session token to log in from a different location.
Azure Impossible Travel Detection
Cortex XDR
Detects an identity signing in from two or more distinct geolocations within a one-hour window in Azure, indicating potential impossible travel activity.
This query identifies users exhibiting unusual authentication behavior by combining Behavior Analytics with recent sign-in activity. It highlights high‑risk sign-ins originating from previously unseen IP addresses where the user agent or operating system has changed compared to historical patterns. The query enriches findings with historical sign-in context and Identity Info to support investigation of potentially compromised accounts.
Detects attempts to exploit the authentication bypass vulnerability (CVE-2026-29000) in the pac4j-jwt library. An attacker can craft a JWE token containing an unsigned PlainJWT, which causes the library to skip signature verification. This is often indicated by a successfully authenticated token with an 'alg' (algorithm) claim of 'none'. This detection requires application logs to be configured to record the claims of successfully authenticated JWTs.
This rule detects potential indicators of compromise related to CVE-2026-20127 in Cisco Catalyst SD-WAN systems. It focuses on two main areas: 1) suspicious successful SSH authentications for the 'vmanage-admin' account, and 2) SD-WAN control plane connection events indicating a new 'up' state. The first part looks for specific log entries related to publickey authentication for 'vmanage-admin' from any source IP. The second part identifies control connection state changes to 'up' and extracts peer type, peer system IP, and public IP from the raw logs. The rule aims to surface events that require human confirmation by comparing them against known network designs and change records, as these events can indicate unexpected relationships between devices or unauthorized privileged access.
Detects successful administrative logins ('vmanage-admin') to a Cisco SD-WAN device from an IP address not on the authorized list. This could indicate exploitation of CVE-2026-20127, an authentication bypass vulnerability.
This rule detects activity associated with a specific threat actor targeting FortiGate devices. It identifies network connections to known threat actor infrastructure IPs, attempts to access FortiGate management ports (443, 8443, 10443, 4443) over TCP, and successful administrative or VPN authentications from the threat actor's IPs in Fortinet/FortiGate logs. Additionally, it looks for DCSync-style directory replication access (event ID 4662) in Windows Security logs, indicating potential Active Directory compromise.
This rule detects suspicious network connections to known threat actor infrastructure associated with FortiGate exploitation, successful administrative or VPN logins to FortiGate devices from these IPs, and DCSync-style directory replication access (EventCode 4662) on Windows systems. The rule is composed of three distinct parts targeting different aspects of the attack chain.
Detects when a user grants consent to an application that has not been seen in the environment before. This rule baselines known applications over a 30-day period and alerts on any new application consent grants or service principal additions within the last day that are not part of the baseline or an explicit allow list.
This rule detects 'impossible travel' scenarios where a user successfully signs in from two geographically distant locations within an implausibly short time frame (less than 120 minutes). It specifically looks for sign-ins where the country of origin changes between consecutive successful login events for the same user.
This rule detects successful sign-ins to Microsoft 365 services that occur via legacy authentication protocols. These protocols (e.g., Exchange ActiveSync, IMAP4, POP3, SMTP AUTH) do not support modern authentication methods like Multi-Factor Authentication (MFA) or Conditional Access policies, making them a potential bypass vector for adversaries who have compromised user credentials. The rule identifies the user, the specific legacy client application used, and provides details on the source IP address and country.
This rule detects a potential quishing (QR code phishing) attack followed by a suspicious successful sign-in to Entra ID (formerly Azure AD). It correlates URL click events or device network events containing deep link indicators (like 'tg://login', 'wa.me/settings/linked_devices', 'signal://', 'line://') or '.apk' file downloads with a successful Entra ID sign-in by the same user within a 30-minute window. This behavior suggests a user may have scanned a malicious QR code, clicked a phishing link, or downloaded a malicious application, leading to a successful but potentially compromised authentication.
Identifies successful Entra ID sign-ins using the Device Code Flow from a geographic location not seen for that user in the last 30 days. The device code flow involves two separate interactions (the attacker's device and the victim's browser), so a mismatch between the sign-in location and the user's established locations is a strong indicator of a session hijacking attempt.
Page 68 of 80