Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,867 detections
Filters
Last updated
All Time
Detection languages
2,526
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,091
793
576
Platforms
39,952
7,270
6,537
3,867
3,651
Products / Services
1,756
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 when an application or service principal performs sensitive configuration changes, likely via the Microsoft Graph API. This can indicate an attacker using a compromised or malicious application for persistence (adding credentials), privilege escalation (adding owners), or defense evasion (modifying Conditional Access policies). This aligns with the "Consent & Compromise" research where attackers abuse application permissions.
This rule detects suspicious inbox forwarding rules, specifically those that forward a copy of all emails to an external address. This behavior is often indicative of an attacker attempting to exfiltrate sensitive information from a compromised mailbox.
A post-authentication vulnerability (CVE-2025-53786) in Microsoft Exchange hybrid-joined configurations.
Detects when a non-approved application is granted high-risk permissions via consent in Azure AD.
This is a common method for attackers to achieve persistence and privilege escalation in Microsoft 365 environments.
This is a common method for attackers to achieve persistence and privilege escalation in Microsoft 365 environments.
This rule detects successful device registrations to the 'Device Registration Service' in Azure Entra. It specifically looks for sign-in events where the ResourceDisplayName is 'Device Registration Service', the ErrorCode is '0' (indicating success), and the ConditionalAccessStatus is not '1' (which typically means that conditional access did not block the authentication flow for device registration).
The rule is pivotal for hunting devices registered for persistence, post-successful phishing campaign execution, where >= 1 accounts were compromised.
The rule is pivotal for hunting devices registered for persistence, post-successful phishing campaign execution, where >= 1 accounts were compromised.
This detection identifies interactive sign-ins from countries that a user has not accessed from in the past 30 days, based on successful logins. It highlights unusual geographic access patterns, such as remote work via VPNs, possible account compromise, or other travel-related anomalies.
Only interactive sign-ins are included to reduce noise from background service logins and token refreshes.
Recommended Extensions:
1. Trusted Applications Watchlist
Use a Sentinel watchlist (e.g., `TrustedAppsWatchlist`) to maintain known or expected applications (like SAP Cloud Identity Services, Microsoft Teams, Outlook Mobile) that frequently authenticate across multiple countries or devices. This helps suppress expected behavior and avoids alert fatigue.
2. Workation / Remote User Watchlist
Create a watchlist (e.g., `WorkationUsers`) with UPNs or user aliases of employees who are temporarily working abroad or from rotating locations. This allows legitimate, location-shifting activity to be filtered out of alerting, reducing false positives during travel seasons or flexible remote work arrangements.
Only interactive sign-ins are included to reduce noise from background service logins and token refreshes.
Recommended Extensions:
1. Trusted Applications Watchlist
Use a Sentinel watchlist (e.g., `TrustedAppsWatchlist`) to maintain known or expected applications (like SAP Cloud Identity Services, Microsoft Teams, Outlook Mobile) that frequently authenticate across multiple countries or devices. This helps suppress expected behavior and avoids alert fatigue.
2. Workation / Remote User Watchlist
Create a watchlist (e.g., `WorkationUsers`) with UPNs or user aliases of employees who are temporarily working abroad or from rotating locations. This allows legitimate, location-shifting activity to be filtered out of alerting, reducing false positives during travel seasons or flexible remote work arrangements.
Detects DNS queries to domains that are suspiciously similar to trusted ones, which may indicate typosquatting, phishing, or user deception tactics. The detection compares unknown domains to a known safe allowlist using a fuzzy character-difference heuristic.
MFA Fatigue Attack
Sigma
Detects a high number of failed or denied Multi-Factor Authentication (MFA) attempts followed by a success for the same user account within a short time frame. This pattern, known as MFA fatigue or push bombing, is a technique actively used by threat actors like Scattered Spider to overwhelm a user with push notifications until they approve one, granting the attacker access.
Identifies Ingress Tool Transfer's.
This detection identifies suspicious authentication failure patterns that may indicate brute-force attacks. It detects four common scenarios:
- Repeated failed login attempts to a single account from a single IP address.
- Distributed login attempts to a single account from multiple IPs.
- A single IP address targeting multiple accounts.
- Broad-scale attempts involving multiple accounts and multiple IPs in a short timeframe.
This rule focuses on failed login attempts only and is intended for early brute-force detection and threat hunting.
Note:
Consider tuning the TimeWindow (default: 10 minutes) and Threshold (default: 5 attempts) values to reflect your organization’s normal login activity. A more permissive or stricter threshold may be necessary depending on your environment (e.g., high-traffic services, mobile users, VPNs).
Includes both a readable union-based version and a compact case()-based variant for performance-conscious deployments.
- Repeated failed login attempts to a single account from a single IP address.
- Distributed login attempts to a single account from multiple IPs.
- A single IP address targeting multiple accounts.
- Broad-scale attempts involving multiple accounts and multiple IPs in a short timeframe.
This rule focuses on failed login attempts only and is intended for early brute-force detection and threat hunting.
Note:
Consider tuning the TimeWindow (default: 10 minutes) and Threshold (default: 5 attempts) values to reflect your organization’s normal login activity. A more permissive or stricter threshold may be necessary depending on your environment (e.g., high-traffic services, mobile users, VPNs).
Includes both a readable union-based version and a compact case()-based variant for performance-conscious deployments.
This detection detect non corporate devices running agentic AI programs attempting
Detects when a user's phone authentication method is changed or added, followed shortly by a successful MFA-based sign-in for that same user. This pattern can indicate a SIM swap attack where an adversary socially engineers a helpdesk or convinces a mobile carrier to port a user's number to an adversary-controlled SIM card. This allows the adversary to intercept MFA codes sent via SMS or phone call and gain unauthorized access.
The analytic detects an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically when more than nine MFA prompts are declined. It leverages Azure Active Directory (Azure AD) sign-in logs, focusing on "Sign-in activity" events with error code 500121 and additional details indicating "MFA denied; user declined the authentication." This behavior is significant as it may indicate a targeted attack or account compromise attempt, with the user actively declining unauthorized access. If confirmed malicious, it could lead to data exfiltration, lateral movement, or further malicious activities.
Indicates suspicious rules such as an inbox rule that forwards a copy of all emails to an external address
This rule detects when a user is added to an administrative or management role in Azure Active Directory outside of defined business hours. It specifically looks for 'Add member to role completed' or 'Add app role assignment grant to user' operations where the target role contains 'admin' or 'Manage', and the event occurs outside of the configured business hours (7 AM to 6 PM local time, Monday to Friday).
This rule detects a sequence of successful Azure AD sign-ins from the same user and device. The first sign-in uses a refresh token (RT) for a non-interactive user session, specifically for the Microsoft Teams desktop client (app ID 29d9ed98-a469-4536-ade2-f981bc1d605e) from an Azure AD joined device, where the token protection status is 'unbound'. This is followed by a second successful sign-in using a primary refresh token (PRT) from the same user and device, excluding sign-ins to the 'Device Registration Service'. This sequence could indicate an adversary attempting to transition from an acquired refresh token to a primary refresh token, potentially to gain broader access or persistence within the Azure AD environment.
This rule detects suspicious device registration activity in Azure Active Directory (now Entra ID). Specifically, it looks for a sequence of two events: first, a 'Device Registration Service' adding a device with 'CloudAccountEnabled' set to true and a specific Windows build number (10.0.19041.928) in the user agent, followed by an attempt to add registered users to the device, referencing 'urn:ms-drs:enterpriseregistration.windows.net'. This sequence could indicate an adversary attempting to register a new device to bypass conditional access policies or gain persistent access.
Detects potential exploitation of Microsoft Entra ID (formerly Azure AD) by attackers who abuse app role permissions to backdoor federated domains and escalate to Global Administrator using forged SAML tokens
Detects network connections using DNS over TLS (DoT) on port 853 or DNS over HTTPS (DoH) to known public resolvers from non-browser processes. This activity can indicate an attempt to bypass network security controls and monitoring by hiding DNS queries within encrypted traffic.
This rule detects the modification of an Azure Network Security Group (NSG) rule to allow traffic from any source IP address ('*'). This configuration change significantly broadens network access and could indicate an adversary attempting to establish persistence, enable command and control, or facilitate data exfiltration by opening up previously restricted network paths.
This rule detects when an application consent operation occurs in Azure Active Directory, specifically looking for broad consent types such as 'AllPrincipals' or when an administrator has granted consent. This can indicate a malicious application gaining wide permissions within the Azure AD tenant.
Page 154 of 185