Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,667 detections
Filters
Last updated
All Time
Detection languages
1,078
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,456
11,839
5,876
5,155
4,865
1,667
Platforms
1,092
591
440
252
122
Products / Services
1,131
476
189
125
118
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
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 instances where a single proxy service API key or account is used from an abnormally high number of distinct IP addresses within a short timeframe. This behavior is indicative of credential theft and unauthorized sharing or exploitation of proxy credentials by third-party actors.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
This rule detects a sequence of authentication activity on VPN gateways (Palo Alto, Fortinet, Cisco) where a source IP experiences multiple failed login attempts followed by at least one successful login within a 60-minute window, potentially indicating a successful brute force or password spraying attack.
Detects a pattern of multiple failed authentication attempts (brute force) from an external IP address followed by a successful authentication event on remote access services such as RDP, VPN, or NTLM. The rule filters for non-private IP addresses and flags successes occurring outside of standard business hours.
This rule monitors for the creation or presence of a specific backdoor account (username 'p2pwn' and password 'p2password') on Dahua devices. This account is known to be injected by threat actors exploiting CVE-2024-39943 as part of Operation CameraSwarm to maintain persistent unauthorized access.
Correlates a successful OAuth device-code sign-in with a subsequent 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 registration match is scoped strictly to the Device Registration Service resource (not the broader Microsoft Authentication Broker app, which fires on routine token refresh/broker activity unrelated to registering a new device). 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 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 registration match is scoped strictly to the Device Registration Service resource (not the broader Microsoft Authentication Broker app, which fires on routine token refresh/broker activity unrelated to registering a new device). 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 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 registration match is scoped strictly to the Device Registration Service resource (not the broader Microsoft Authentication Broker app, which fires on routine token refresh/broker activity unrelated to registering a new device). 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 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 registration match is scoped strictly to the Device Registration Service resource (not the broader Microsoft Authentication Broker app, which fires on routine token refresh/broker activity unrelated to registering a new device). 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.
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.
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.
Detects successful user authentication events originating from an external source IP address. This rule is intended to identify remote logins that can be correlated with RMM (Remote Monitoring and Management) activity or other remote access patterns.
Detects anomalous sign-in behavior where a device code authentication flow is initiated from one location, but the resulting session is replayed from a different IP address in a different country within a one-hour window. This behavior is indicative of an adversary capturing an authentication token via a device code phishing or relay attack and attempting to use it from their own infrastructure to bypass conditional access policies and MFA.
This rule detects a sequence of authentication activity on VPN gateways (Palo Alto, Fortinet, Cisco) where a source IP experiences multiple failed login attempts followed by at least one successful login within a 60-minute window, potentially indicating a successful brute force or password spraying attack.
This rule detects activity matching known indicators of compromise (IOCs) associated with recent Russian espionage campaigns, including malicious domains, IP addresses, email senders, file names, and file hashes. It monitors network, sign-in, email, process, and file events across enterprise systems.
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.
Page 34 of 80