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
Detects network connection events involving a specific known malicious IP address (5.230.71.51) identified as participating in unauthorized Intune enrollment or Entra ID device registration processes.
This rule detects anomalous behavior where a single user account registers multiple devices within a very short timeframe (80 seconds). This pattern often follows the theft of a device code or OAuth authorization token, where an adversary attempts to rapidly enroll multiple rogue devices to maintain persistent access or bypass MFA controls.
Detects suspicious OAuth device code authorization requests matching the GhostCode phishing kit's pattern. The rule identifies the use of a known Microsoft Authentication Broker App ID (29d9ed98-a469-4536-ade2-f981bc1d605e) coupled with the 'python-requests' user agent, which are characteristic indicators of the phishing backend server attempting to authorize malicious requests.
Detects rapid, successive successful interactive sign-ins for the same user account that each satisfy MFA requirements, but originate from geographically and technically distinct environments (different IP locations, ASNs, and device IDs) within a 2-minute window. This behavior is indicative of session hijacking via Adversary-in-the-Middle (AiTM) or Phishing-as-a-Service (PhaaS) frameworks.
This rule detects successful authentication events using the Microsoft OAuth device code flow, which is often abused in phishing campaigns to hijack user sessions. It flags authentication attempts that match specific device authorization URLs, include signs of bypassing security warnings, or indicate a lack of direct user authentication interaction.
Detects OAuth 2.0 device authorization grant requests utilizing the Microsoft Authentication Broker application ID (29d9ed98-a469-4536-ade2-f981bc1d605e) with sensitive scopes like 'https://graph.microsoft.com/.default'. This specific application ID is frequently impersonated by phishing kits (e.g., GhostCode) to facilitate token theft via device code flow abuse, where adversaries trick users into authenticating to a legitimate-looking but attacker-controlled flow.
Detects login attempts to source code repositories and developer tooling (GitHub, GitLab, Bitbucket, Azure DevOps, Slack, Visual Studio Code) originating from unmanaged or non-compliant devices, excluding traffic originating from known corporate network ranges.
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.
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.
Detects successful modifications to user MFA methods (StrongAuthenticationMethod) where the associated device details are missing or indicate a software-only token activation. This behavior is often indicative of an adversary adding their own MFA device to a compromised account to maintain persistent access or bypass MFA requirements.
This rule detects potential reconnaissance activity against Microsoft Graph API endpoints, indicative of an adversary enumerating tenant resources such as users, groups, applications, and directory roles. It monitors for high volumes of diverse Graph API queries originating from a single user or application identity within a short time window, which is a common behavior pattern for automated discovery tools.
This rule monitors cloud and identity logs to detect a single user identity exhibiting multiple stages of suspicious activity (authentication, reconnaissance, and exfiltration) within a 24-hour period while utilizing distinct, non-overlapping source IP addresses for each stage. This behavior is indicative of an account compromise where different stages of the attack chain originate from different infrastructure.
Detects potential Adversary-in-the-Middle (AitM) activity where a user triggers both a standard MFA requirement (50074) and a subsequent MFA requirement within the same session (50140), potentially indicating the user is interacting with a proxy site that requires re-authentication or session interception. The rule specifically looks for users who trigger these events in short succession, often associated with phishing campaigns aiming to bypass MFA.
Detects instances where a user successfully authenticates using the OAuth 2.0 device code flow, and the resulting token is subsequently used from a different IP address or by a different client application, indicating potential token theft or session hijacking.
Detects modifications to a user's Azure Active Directory (Entra ID) authentication methods where a new authentication device is added. The rule specifically monitors changes to 'StrongAuthenticationPhoneAppDetail' or 'StrongAuthenticationUserDetails' and identifies instances where the count of registered devices increases, potentially indicating an attacker adding a device for persistence or MFA bypass.
Detects anomalous sign-in activity where a user triggers both Error Code 50074 (MFA required) and 50140 (MFA bypass occurred or not required/invalidated) in a short window of time (less than 1 hour). The rule looks for sessions on unmanaged devices (empty TrustType) using Chrome, which may indicate an adversary attempting to bypass or manipulate MFA enrollment or verification flows.
Detects instances where a user account experiences an 'Unusual sign-in' event followed by the registration of a new MFA or security information method within a one-hour window. This behavior is indicative of an attacker attempting to establish persistent access by registering their own authentication device to a compromised account.
Detects unauthorized cloud authentication attempts in Azure AD where a session token appears to have been replayed. The rule identifies sign-ins flagged by Identity Protection as anomalous or involving token/issuer irregularities, particularly when these occur without a fresh MFA challenge, suggesting a bypass of standard authentication controls.
This rule monitors for various types of events (user logons, network connections, API audits, cloud app events, and email traffic) originating from a specific CIDR block (160.79.104.0/21), which is flagged as suspicious or unauthorized.
Detects high-frequency creation and revocation of service principal credentials, indicating potential malicious credential cycling, or unusual bursts of service account JWT/refresh token rotation across multiple IP addresses, which may indicate an attempt to evade detection or maintain persistence.
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.
Page 62 of 185