Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,865 detections
Filters
Last updated
All Time
Detection languages
2,524
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,091
792
575
Platforms
39,934
7,265
6,535
3,865
3,645
Products / Services
1,755
1,449
1,121
438
406
MITRE Techniques
1,889
1,392
913
814
727
CVEs
12
5
4
3
2
IDS Classtypes
10
7
6
6
5
IDS Protocols
37
2
1
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.
Detects a suspicious correlation between the registration of new authentication methods or application integrations and the subsequent modification of Conditional Access policies within a 2-hour window. This behavior is indicative of the activation phase of a TrustSink attack, where an adversary sets up a malicious MFA provider and forces its use by expanding Conditional Access policy scope.
Detects a suspicious correlation between the registration of new authentication methods or application integrations and the subsequent modification of Conditional Access policies within a 2-hour window. This behavior is indicative of the activation phase of a TrustSink attack, where an adversary sets up a malicious MFA provider and forces its use by expanding Conditional Access policy scope.
Detects authentication failures in Microsoft Entra ID associated with external MFA providers. This condition, specifically indicated by failure codes 70002 or 50012 and associated error messages regarding signature validation or external token trust, may indicate an attempt to bypass authentication via a rogue MFA provider or a misconfigured integration.
Detects signs of the TrustSink technique where an Entra sign-in process, while at the MFA stage, is intercepted by redirecting the user to a rogue External Authentication Method (EAM) provider. This unauthorized provider typically uses look-alike domains or tunneling services to host phishing pages that harvest plaintext credentials and return forged MFA tokens to Entra.
Detects high-frequency, diverse Microsoft Graph API requests initiated by an identity, indicative of automated reconnaissance or enumeration of the cloud environment. The rule tracks requests across multiple categories such as organization settings, user/group identities, privilege information, application configurations, and resource access within a 30-minute window.
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 high-frequency authentication failures in Entra ID (Azure AD) originating from External Authentication Method (EAM) providers. The rule identifies instances where the external identity token fails signature or key-ID validation (AADSTS50012/AADSTS70002), which may indicate configuration issues with the external IdP or attempts to forge authentication tokens.
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 high-frequency authentication failures in Entra ID (Azure AD) originating from External Authentication Method (EAM) providers. The rule identifies instances where the external identity token fails signature or key-ID validation (AADSTS50012/AADSTS70002), which may indicate configuration issues with the external IdP or attempts to forge authentication tokens.
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 high-frequency access to multiple sensitive Microsoft Graph API paths (users, groups, applications, directoryRoles, servicePrincipals, etc.) from a single identity within a short timeframe. This pattern is indicative of automated reconnaissance or enumeration of the cloud environment's identity and application landscape.
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 anomalous, high-frequency password submission patterns from a single IP address within a short timeframe, which is indicative of an Adversary-in-the-Middle (AiTM) phishing proxy (e.g., NovaCookies) testing multiple credentials before proceeding to MFA.
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 high-volume, multi-endpoint enumeration activity against the Microsoft Graph API, involving a high frequency of requests across sensitive tenant resources (users, groups, applications, roles, mailboxes, etc.). This behavior is consistent with post-compromise reconnaissance by an adversary attempting to map the environment.
Page 58 of 185