Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
461 detections
Filters
Last updated
All Time
Detection languages
276
67
44
26
23
Contributors
167
111
62
17
9
Categories
238
219
140
83
78
Platforms
338
217
143
29
23
Products / Services
286
157
50
38
27
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
CVEs
13
5
3
2
1
IDS Classtypes
5
3
2
IDS Protocols
9
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.
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 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.
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 potential N0va-style phishing or token-exchange abuse where a user completes a device-code authentication flow, followed immediately by an access token usage from a different IP address or device. This sequence indicates an adversary has captured the resulting token/session and is attempting to bypass multi-factor authentication (MFA) to gain unauthorized access to cloud resources.
This rule monitors for suspicious OAuth Device Code flow authentication attempts in Azure AD sign-in logs. It detects activity involving the device code protocol combined with specific error flags or indicators of potentially compromised or non-compliant devices (such as missing device IDs, non-compliant status, or empty trust types), which are indicative of Adversary-in-the-Middle (AiTM) phishing or token interception attacks.
Detects potential abuse of the device-code authentication flow, which is often used in AiTM (Adversary-in-the-Middle) phishing campaigns. The detection looks for device-code authentication attempts followed by specific error codes (50074, 50140) commonly associated with failures in malicious passkey-themed phishing workflows.
Detects login events to the 'My Sign-Ins' portal (mysignins.microsoft.com) by users. This portal is a high-value target for adversaries who have gained access to a session via token theft or session hijacking, as it allows them to modify or add authentication methods (such as MFA devices) to establish long-term persistence in the victim's account.
Detects successful API requests to sensitive administrative endpoints on WSO2 systems that lack a corresponding legitimate authentication event (session) from the same SourceIP and user pair, which may indicate the use of forged JWTs or authentication bypass exploitation (e.g., CVE-2026-5430).
Detects anomalous access to WSO2 API Manager Store and Publisher endpoints involving the retrieval of sensitive information like consumer keys and secrets. The rule specifically targets requests authenticated with JWTs that exhibit headers indicative of 'alg=none' or other unsupported/forged algorithm patterns, often associated with CVE-2026-5430 exploitation attempts. The rule uses statistical baseline monitoring to identify volume spikes in requests to these sensitive paths.
Detects anomalous sign-in behavior following a successful device code authentication. The rule identifies instances where a successful device code login is immediately followed by a sign-in session using a different IP address or device name for the same account, indicating potential session theft or adversary-in-the-middle phishing activity.
Detects potential JWT algorithm-confusion or authentication-bypass attempts
targeting WSO2 API Manager components through JWTs specifying unsupported,
downgraded, or unexpected signing algorithms such as "none" or HS256 where
asymmetric signing is expected. Matching events should be investigated to
determine whether the request represents exploitation of CVE-2026-5430.
targeting WSO2 API Manager components through JWTs specifying unsupported,
downgraded, or unexpected signing algorithms such as "none" or HS256 where
asymmetric signing is expected. Matching events should be investigated to
determine whether the request represents exploitation of CVE-2026-5430.
Detects suspicious Entra ID device registration and Primary Refresh Token (PRT) issuance occurring shortly after an OAuth Device Code sign-in. This pattern is indicative of ARToken-style post-compromise persistence, where an attacker leverages a stolen device code to register a rogue device and establish a persistent session.
Detects a suspicious sequence of events within JFrog Artifactory where an account accesses sensitive code-signing material (rubygems/gemspec/signing keys) and subsequently performs administrative actions (user addition/role assignment/privilege escalation) within a one-hour window, indicating potential account takeover or exploitation.
Detects a suspicious sequence of events within JFrog Artifactory where an account accesses sensitive code-signing material (rubygems/gemspec/signing keys) and subsequently performs administrative actions (user addition/role assignment/privilege escalation) within a one-hour window, indicating potential account takeover or exploitation.
Detects potential cross-application SSO session or token reuse by identifying users transitioning from a low-trust application (forum) to a high-trust application (ChatGPT/Codex) within a short window (15 minutes), especially when the sign-in is non-interactive (lacking MFA) or occurs from a different IP address or user agent, suggesting a possible token replay attack.
Page 10 of 22