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
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.
Detects Microsoft Entra ID sign-in events where the multi-factor authentication (MFA) requirement was marked as satisfied by an External Authentication Method (EAM) provider, but the authentication claims (AMR) include values typically reserved for locally verified hardware-based factors (e.g., hwk, fido). This pattern is indicative of a TrustSink attack, where a malicious OIDC identity provider injects forged assertions to bypass actual MFA requirements.
Detects successful authentication events that rely on external authentication method providers, which may indicate an adversary is using a rogue MFA provider to bypass standard authentication controls or to perform adversary-in-the-middle (AiTM) attacks.
Detects Azure AD sign-in events where Multi-Factor Authentication (MFA) was reportedly satisfied by an External Authentication Method (EAM) claim without evidence of a traditional secondary authentication challenge. This behavior is indicative of a 'TrustSink' technique where a rogue or compromised OIDC provider injects a spoofed assertion of MFA success into the authentication token.
Detects Microsoft Entra ID sign-in events where the multi-factor authentication (MFA) requirement was marked as satisfied by an External Authentication Method (EAM) provider, but the authentication claims (AMR) include values typically reserved for locally verified hardware-based factors (e.g., hwk, fido). This pattern is indicative of a TrustSink attack, where a malicious OIDC identity provider injects forged assertions to bypass actual MFA requirements.
Detects successful authentication events that rely on external authentication method providers, which may indicate an adversary is using a rogue MFA provider to bypass standard authentication controls or to perform adversary-in-the-middle (AiTM) attacks.
Detects successful Entra ID sign-in events that utilize an External Authentication Method (EAM) within 7 days of that authentication method being registered or modified in the tenant's authentication methods policy. This pattern is indicative of a potential MFA bypass scenario where an adversary registers a rogue external authentication provider to intercept or forge MFA tokens.
Detects a potential Adversary-in-the-Middle (AiTM) attack sequence by correlating OneDrive/SharePoint document sharing email lures with subsequent successful Microsoft 365 sign-ins from unusual locations or user agents within a short time window. This activity often indicates session cookie theft and MFA bypass.
Detects successful authentication events using the device code flow for specific end-user applications including Windows App, Azure Virtual Desktop, and Windows 365. This pattern is often utilized in legitimate workflows but can also be abused to gain access to corporate resources.
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 a sequence of events starting with a user signing in via the OAuth device code flow, followed immediately by mailbox item enumeration and sending of email. This pattern is characteristic of attackers who use device code phishing to steal tokens, subsequently using those tokens to access mailboxes and send malicious emails from the compromised account.
Detects authentication events associated with known actor infrastructure (AnonyMousKIT/Cluster B/UKT) and identifies anomalous crossover patterns where a single source IP authenticates into multiple distinct accounts within a short time window. This behavior is indicative of a shared backend infrastructure across multiple accounts or storefronts.
Detects Microsoft 365 / Entra ID sign-in events where the reported client application is Microsoft Outlook but the User-Agent string is inconsistent with Outlook's standard Edge-based WebView. This behavioral discrepancy often indicates the use of automated HTTP clients to replay stolen session tokens in Adversary-in-the-Middle (AiTM) phishing campaigns, allowing attackers to maintain authenticated access for reconnaissance and data collection.
Detects Microsoft Entra OAuth 2.0 device authorization grant flow completion immediately followed by non-interactive API access from automated user agents like python-requests. This behavior is indicative of device code phishing kits, where an attacker tricks a user into entering a code and then programmatically hijacks the resulting session token.
Detects the issuance of a Primary Refresh Token (PRT) to Microsoft Graph occurring in close temporal proximity to a device code authentication flow. This pattern is indicative of device-code phishing attacks, where an adversary intercepts a device code to obtain long-lived, session-persistent access to a tenant.
Detects potentially malicious OAuth device code sign-ins by identifying sign-in events that exhibit anomalous characteristics, such as atypical geographic locations, rare client-application combinations, unmanaged/noncompliant device status, or elevated risk signals associated with the account. This detection helps identify account compromise or malicious OAuth consent activity often associated with 'EvilTokens' or device-code phishing attacks.
Detects potential device code phishing patterns where a successful OAuth device-code authentication is rapidly followed by Microsoft Graph resource access from the same account. The rule identifies suspicious polling sessions (e.g., EvilTokens) by monitoring for successful device-code sign-ins and immediate, subsequent Graph API activity. It filters known first-party applications and incorporates risk-based triggers and reconnaissance behavioral patterns to minimize false positives.
Detects potential device code phishing patterns where a successful OAuth device-code authentication is rapidly followed by Microsoft Graph resource access from the same account. The rule identifies suspicious polling sessions (e.g., EvilTokens) by monitoring for successful device-code sign-ins and immediate, subsequent Graph API activity. It filters known first-party applications and incorporates risk-based triggers and reconnaissance behavioral patterns to minimize false positives.
Detects potential device code phishing patterns where a successful OAuth device-code authentication is rapidly followed by Microsoft Graph resource access from the same account. The rule identifies suspicious polling sessions (e.g., EvilTokens) by monitoring for successful device-code sign-ins and immediate, subsequent Graph API activity. It filters known first-party applications and incorporates risk-based triggers and reconnaissance behavioral patterns to minimize false positives.
Page 31 of 80