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 network activity, email URLs, and DNS queries associated with a specific set of known malicious domains often used in phishing or credential harvesting campaigns. By aggregating telemetry from EmailUrlInfo, EmailEvents, DeviceNetworkEvents, and DnsEvents, the rule flags any interactions with these indicators of compromise.
This detection identifies enabled user accounts that have not had a successful sign-in for the last 90 days, highlighting potential security risks from dormant accounts.
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.
This rule detects various event types (email, identity authentication, network connections, and cloud audit logs) originating from or interacting with the specific IP address range 160.79.104.0/22 to 160.79.111.0/22, which is associated with known malicious activity.
No description available.
This rule identifies successful user sign-in events specifically targeted at Microsoft's management portals (myaccount.microsoft.com and mysignins.microsoft.com). It aggregates these events by user, tracking the frequency, timeframe, and originating IP addresses for successful access. This monitoring is useful for detecting abnormal access to identity settings, which could indicate credential abuse or unauthorized account management.
This rule detects potentially unauthorized access to Microsoft Graph API resources (Mail or Files) following a device-code authentication event for the same user. It identifies scenarios where a previously unknown application client performs read operations within 24 hours of a device-code login, which is characteristic of 'ARToken' or 'EvilProxy' type device-code phishing and session proxy attacks.
Detects user sign-ins using the OAuth 2.0 Device Code authentication flow in Entra ID. This flow, designed for input-constrained devices, is frequently abused by attackers in 'Device Code Phishing' (or ARToken) campaigns to steal session tokens and bypass MFA by tricking users into authorizing a malicious application via a web portal.
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 multiple anomalous sign-in events using the device-code authentication flow within an Entra ID tenant. The rule correlates sign-ins from geographically disparate IP addresses (often associated with known attacker infrastructure or proxies) using device-code flows, which is a technique used in 'ARToken' style phishing campaigns to compromise multiple user accounts in a short timeframe.
This rule monitors web server logs (IIS, W3C, and Azure Application Gateway) for incoming traffic that matches known malicious or automated vulnerability scanners, as well as requests for common system fingerprinting paths (such as /server-status or /.git/config). The rule aggregates these hits by source IP address to identify potential active reconnaissance or vulnerability scanning attempts.
This rule detects modifications to Group Policy Objects (GPO) or Microsoft Entra (formerly Azure AD) policies that weaken established security controls. For GPO, it monitors Event ID 5136 for changes to security-relevant attributes (e.g., disabling firewall or real-time monitoring) in Active Directory. For Entra, it monitors audit logs for administrative operations that reduce security posture, such as disabling MFA, lowering authentication trust, or deleting Conditional Access policies. It includes filters to exclude legitimate, documented change management activities.
Detects automated directory fuzzing attempts against Azure Storage blobs targeting sensitive files like .env, .pem, or configuration files. The rule identifies suspicious activity by aggregating requests from Anonymous or SAS-authenticated sources that exhibit high request volumes and access to multiple distinct sensitive paths, while excluding known legitimate bulk-transfer and synchronization tools.
Detects the use of the default, hardcoded 'sk-1234' secret key for HS256 JWT signing in LiteLLM proxy logs. This configuration is insecure and allows for the forgery of arbitrary user session tokens.
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 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.
This rule detects scenarios where a device registration event occurs within 15 minutes of a device-code authentication sign-in for the same user. This pattern is indicative of potential account manipulation where an adversary registers their own device to an existing account to maintain persistent access or bypass multi-factor authentication (MFA).
This rule detects scenarios where a device registration event occurs within 15 minutes of a device-code authentication sign-in for the same user. This pattern is indicative of potential account manipulation where an adversary registers their own device to an existing account to maintain persistent access or bypass multi-factor authentication (MFA).
This rule detects potential OAuth token theft resulting from device code phishing (e.g., N0va phishkit). It monitors for a successful OAuth device-code authentication followed within 5 minutes by a secondary successful sign-in for the same user from a different IP address, different browser client, or different user agent, which is a common indicator of an adversary-in-the-middle (AiTM) session hijacking attempt.
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.
Page 66 of 185