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,417
11,806
5,870
5,145
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 captures all successful authentication events with a populated source IP address. It serves as a foundational data collection rule for downstream security analytics, enabling the correlation of sign-in events against historical user geolocation baselines, ASN/ISP reputation feeds, and the detection of proxy or suspicious infrastructure usage.
Detects anomalous cloud authentication events occurring within a 3-hour window after suspected unauthorized access to sensitive configuration or credential files on a Vite development server. The rule flags sign-ins with high risk, anomalous location, or missing device compliance information, excluding trusted corporate locations and devices, serving as an indicator of potential post-exfiltration account takeover.
This rule detects potential API abuse by identifying high-frequency API calls using the 'python-requests' user agent that occur within a short time window (120 seconds) immediately following a successful device code authentication event. This behavior is indicative of automated token theft or session hijacking where an adversary attempts to perform unauthorized actions quickly using tokens obtained via device code phishing.
Detects successful Microsoft Intune enrollment events initiated using the Device Code authentication protocol in Azure AD/Entra ID. This flow is often abused by adversaries to perform OAuth device code phishing, allowing them to gain unauthorized access to cloud resources by tricking users into authorizing a malicious application on their own devices.
Detects an Azure AD Device Code authentication event followed within 60 seconds by a non-interactive Primary Refresh Token (PRT) sign-in event from the same user. This sequence is characteristic of adversary-in-the-middle (AiTM) phishing attacks where a user is tricked into authorizing a device code, and the adversary immediately leverages the resulting session/token to obtain a PRT for persistent access.
This rule identifies successful user sign-ins (ResultType 0) originating from specific Autonomous System Numbers (197540, 216154) where Multi-Factor Authentication (MFA) was not required or not recorded, and where Conditional Access policies either did not apply or succeeded without enforcing MFA.
Detects anomalous authentication or API access patterns where a single user account interacts with both Salesforce and ServiceNow environments simultaneously from multiple distinct source IP addresses. This behavior is indicative of credential abuse or account takeovers consistent with multi-platform SaaS targeting.
Detects successful device code authentication flows involving applications that are not part of a known list of standard Microsoft and Azure client applications. Device code flows are frequently abused in phishing attacks to bypass traditional credential-based authentication.
Detects successful device code authentication flows involving applications that are not part of a known list of standard Microsoft and Azure client applications. Device code flows are frequently abused in phishing attacks to bypass traditional credential-based authentication.
Detects anomalous non-interactive sign-ins that bypass multi-factor authentication (MFA) requirements from a geographical location not previously seen in the user's historical sign-in baseline. This pattern is indicative of attackers using stolen OAuth access or refresh tokens to maintain persistence and bypass standard authentication controls.
Detects anomalous activity associated with OAuth 2.0 device code phishing campaigns. The rule identifies accounts showing frequent device code authentication attempts, including successful logins from potentially unmanaged or unrecognized devices, which is consistent with the behavior of phishing kits targeting OAuth device grant flows.
Detects a pattern where a single source IP address performs multiple successful authentications across different cloud account identifiers within a short timeframe. This behavior is indicative of automated credential spraying, multi-agent automated access, or potential account takeover activity targeting multiple accounts within a cloud environment.
Detects instances where a user account experiences multiple failed sign-in attempts followed by a successful sign-in from a different, geographically distant location within a short timeframe, indicating impossible travel and potential credential compromise.
Detects successful remote logons to network devices (routers, VPNs, NAS) using the 'admin' account. This pattern is indicative of credential spraying or brute-force attacks targeting weak default credentials on externally facing management interfaces, often associated with botnets or threat actors performing reconnaissance and initial access operations.
Detects anomalous SSH authentication patterns characterized by a high volume of failed logon attempts (>= 10) originating from a specific IP address within a short timeframe (30 minutes), followed by a successful authentication to the same target device. This pattern is indicative of a successful credential brute-force or password guessing attack against an exposed SSH service.
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.
This rule identifies successful OAuth 2.0 device code authentication attempts originating from both an IP address and country not previously seen for that specific user, using a 90-day baseline that requires at least 5 prior non-device-code sign-ins to be established (reducing noise from sparse-history/new accounts). It excludes known legitimate device-code applications (e.g., Azure CLI, Azure PowerShell, Visual Studio, VS Code) and sign-ins from devices already marked compliant/managed. This tightened logic reduces false positives from routine travel or home/office network changes while still catching device code phishing, where an adversary tricks a user into entering a device code on a malicious site to obtain an access token.
Correlates a successful OAuth device-code sign-in with a subsequent Microsoft Authentication Broker / Device Registration Service event for the same user within 30 minutes, excluding known legitimate device-code applications (Azure CLI, Azure PowerShell, Visual Studio, VS Code) and requiring both events to have succeeded. The correlation is further restricted to cases where the device-registration event originates from a different IP address or city than the original device-code sign-in -- the pattern expected when an attacker uses a stolen token to register their own device and mint a Primary Refresh Token, versus a legitimate user completing device enrollment from their own network shortly after a CLI/developer login.
Correlates a successful OAuth device-code sign-in with a subsequent Microsoft Authentication Broker / Device Registration Service event for the same user within 30 minutes, excluding known legitimate device-code applications (Azure CLI, Azure PowerShell, Visual Studio, VS Code) and requiring both events to have succeeded. The correlation is further restricted to cases where the device-registration event originates from a different IP address or city than the original device-code sign-in -- the pattern expected when an attacker uses a stolen token to register their own device and mint a Primary Refresh Token, versus a legitimate user completing device enrollment from their own network shortly after a CLI/developer login.
This rule identifies successful OAuth 2.0 device code authentication attempts originating from both an IP address and country not previously seen for that specific user, using a 90-day baseline that requires at least 5 prior non-device-code sign-ins to be established (reducing noise from sparse-history/new accounts). It excludes known legitimate device-code applications (e.g., Azure CLI, Azure PowerShell, Visual Studio, VS Code) and sign-ins from devices already marked compliant/managed. This tightened logic reduces false positives from routine travel or home/office network changes while still catching device code phishing, where an adversary tricks a user into entering a device code on a malicious site to obtain an access token.
Page 30 of 80