Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,235 detections
Filters
Last updated
All Time
Detection languages
734
214
105
78
51
Contributors
206
187
159
111
90
Categories
396
296
264
260
247
Platforms
492
314
281
204
110
Products / Services
379
234
152
109
106
MITRE Techniques
18,123
15,639
12,581
8,394
6,215
1,235
CVEs
9
9
4
4
4
IDS Classtypes
11
6
4
2
1
IDS Protocols
10
5
3
This rule detects several types of suspicious activities related to Microsoft Graph API calls, specifically targeting device management actions. It identifies: 1. Actions from an IP address not previously seen for a given caller identity. 2. Actions performed by a service principal that has not been observed before. 3. High-risk actions (e.g., device wipe, retire, remote lock, reset passcode) or device configuration changes occurring outside of business hours or on weekends. 4. Bulk device targeting, where a single caller identity performs actions on a large number of devices within a short time frame. These detections aim to identify potential compromise of accounts or malicious administrative actions.
Detects a FortiGate configuration file download followed by the creation of a new computer account in Active Directory by the 'fortidcagent' service account within a short time window. This pattern may indicate an attacker has compromised a FortiGate appliance, extracted credentials from the configuration, and is now using them to join a rogue device to the domain for lateral movement.
This rule detects interactive logons (LogonType 10) where a single account from the same domain logs into multiple distinct devices. This could indicate an attacker using compromised credentials to move laterally within the network or access multiple systems.
This query identifies users exhibiting unusual authentication behavior by combining Behavior Analytics with recent sign-in activity. It highlights high‑risk sign-ins originating from previously unseen IP addresses where the user agent or operating system has changed compared to historical patterns. The query enriches findings with historical sign-in context and Identity Info to support investigation of potentially compromised accounts.
This rule detects unusual access patterns to Azure resources where a single identity (user or service principal) accesses resources from multiple distinct IP addresses and/or geographic locations within a 7-day timeframe. This behavior can indicate compromised credentials, session hijacking, or an adversary attempting to evade detection by frequently changing their apparent origin.
Detects suspicious sign-in activities by user in a specified timeframe
Detects attempts to exploit the authentication bypass vulnerability (CVE-2026-29000) in the pac4j-jwt library. An attacker can craft a JWE token containing an unsigned PlainJWT, which causes the library to skip signature verification. This is often indicated by a successfully authenticated token with an 'alg' (algorithm) claim of 'none'. This detection requires application logs to be configured to record the claims of successfully authenticated JWTs.
With OAuth 2.0 Device Code Flow phishing campaigns actively targeting M365 environments in financial services and beyond, I built a cross-phase KQL detection rule that moves beyond the obvious deviceCode protocol filter — because the real damage happens in tables most hunts never look at.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
This query identifies rare or newly observed application sign-ins by comparing activity in the last 24 hours against a 30‑day historical baseline.
It highlights applications that are never used or seldom used in the tenant, helping detect anomalous or suspicious application activity that may indicate OAuth abuse, automation tools, or compromised accounts.
It highlights applications that are never used or seldom used in the tenant, helping detect anomalous or suspicious application activity that may indicate OAuth abuse, automation tools, or compromised accounts.
Detects actions performed on RiskyUsers in Azure Entra ID by unauthorized
members. Specifically looks for CA or GA accounts performing IdentityProtection
actions where the admin is not from the Information Security department.
Note: String parsing (AdminLocalPart, AdminLastName, StrippedAdminName),
fallback identity matching, summarize arg_max, and project are handled
natively in KQL post-conversion.
members. Specifically looks for CA or GA accounts performing IdentityProtection
actions where the admin is not from the Information Security department.
Note: String parsing (AdminLocalPart, AdminLastName, StrippedAdminName),
fallback identity matching, summarize arg_max, and project are handled
natively in KQL post-conversion.
This rule detects 'impossible travel' scenarios where a user successfully signs in from two geographically distant locations within an implausibly short time frame (less than 120 minutes). It specifically looks for sign-ins where the country of origin changes between consecutive successful login events for the same user.
This rule detects successful sign-ins to Microsoft 365 services that occur via legacy authentication protocols. These protocols (e.g., Exchange ActiveSync, IMAP4, POP3, SMTP AUTH) do not support modern authentication methods like Multi-Factor Authentication (MFA) or Conditional Access policies, making them a potential bypass vector for adversaries who have compromised user credentials. The rule identifies the user, the specific legacy client application used, and provides details on the source IP address and country.
This rule detects a potential quishing (QR code phishing) attack followed by a suspicious successful sign-in to Entra ID (formerly Azure AD). It correlates URL click events or device network events containing deep link indicators (like 'tg://login', 'wa.me/settings/linked_devices', 'signal://', 'line://') or '.apk' file downloads with a successful Entra ID sign-in by the same user within a 30-minute window. This behavior suggests a user may have scanned a malicious QR code, clicked a phishing link, or downloaded a malicious application, leading to a successful but potentially compromised authentication.
Correlates AuditLogs and IdentityInfo on AccountUPN to detect
unauthorized CA or GA members performing IdentityProtection actions
on RiskyUsers in Azure Entra ID outside of the Information Security
department.
Note: The following logic is NOT expressible in Sigma and must be
applied post-conversion in native KQL:
- Multiple join fallback matching (by UPN, last name, full name)
- StrippedAdminName prefix removal (CA - / GA - )
- summarize arg_max(TimeGenerated, *) by AccountUPN
- iff() fallback logic for department and job title
- sort by TimeGenerated desc
- project-reorder
unauthorized CA or GA members performing IdentityProtection actions
on RiskyUsers in Azure Entra ID outside of the Information Security
department.
Note: The following logic is NOT expressible in Sigma and must be
applied post-conversion in native KQL:
- Multiple join fallback matching (by UPN, last name, full name)
- StrippedAdminName prefix removal (CA - / GA - )
- summarize arg_max(TimeGenerated, *) by AccountUPN
- iff() fallback logic for department and job title
- sort by TimeGenerated desc
- project-reorder
Detects logons to Keystone core banking system outside of business hours.
Excludes specific departments and job titles that have extended access.
Note: Timezone conversion (UTC to PST), WeekDay function, summarize, and
project-reorder are handled natively in KQL post-conversion.
Excludes specific departments and job titles that have extended access.
Note: Timezone conversion (UTC to PST), WeekDay function, summarize, and
project-reorder are handled natively in KQL post-conversion.
Correlates IdentityLogonEvents and IdentityInfo on AccountObjectId to detect
after-hours access to Keystone core banking system enriched with user identity.
Note: The following logic is NOT expressible in Sigma and must be applied
post-conversion in native KQL, SPL or whatever query language you use and want
to convert to:
- Timezone conversion (UTC to PST)
- WeekDay function and day-of-week filtering
- Hour-based filtering per department
- summarize arg_max with bin(TimeGenerated, 5m)
- ManagerEmail construction via mgrSplit
- project-reorder
after-hours access to Keystone core banking system enriched with user identity.
Note: The following logic is NOT expressible in Sigma and must be applied
post-conversion in native KQL, SPL or whatever query language you use and want
to convert to:
- Timezone conversion (UTC to PST)
- WeekDay function and day-of-week filtering
- Hour-based filtering per department
- summarize arg_max with bin(TimeGenerated, 5m)
- ManagerEmail construction via mgrSplit
- project-reorder
Detects a suspicious sequence where a new credential (PAT, SSH key, or OAuth authorization) is created and then used to establish durable persistence via webhooks or deploy keys. This behavior typically occurs after an account compromise as an attacker attempts to "lock in" access that survives credential rotation and provides real-time exfiltration of repository data.
Multi-layered detection rule that identifies anomalous behavior on privileged accounts across six independent detection layers: absolute rule violations ("never actions"), self-calibrating ratio-based thresholds, behavioral technique substitution (e.g., WMI drop-off while other lateral movement continues), time-series statistical anomaly detection via series_decompose_anomalies(), reconnaissance burst detection on LDAP/directory queries, and MFA gap analysis. All layers roll up into a composite risk score for analyst prioritization. Originally derived from diffpatterns() analysis of real penetration test data vs. normal operations, this community edition replaces environment-specific hardcoded thresholds with self-calibrating statistical baselines. Requires Microsoft Defender for Identity and Entra ID Sign-in Logs.
This rule detects suspicious activity where an 'unfamiliar sign-in properties' alert occurs shortly after an administrator has changed a user's Multi-Factor Authentication (MFA) method. It correlates security alerts for unfamiliar sign-ins with audit logs indicating MFA method changes for the same user within a short timeframe. The rule then checks if the user's sign-in activity shows multiple IP addresses or locations, indicating a potential compromise or MFA bypass after the change.
Detects the addition of an SSH public key to a GitHub account using programmatic access (Personal Access Tokens, OAuth, or GitHub Apps). Unlike keys added via the Web UI, programmatic creation often bypasses manual verification steps and provides long-lived access that survives password resets and MFA changes. This is a common technique for attackers to establish persistent command line access to repositories.
This rule detects modifications to properties of 'break glass' accounts. It joins a watchlist of identity categories containing 'Break Glass' accounts with Azure Audit Logs to identify specific operations performed on these accounts. The rule focuses on changes to user principal names, operation names, activity display names, results, and AAD operation types.
Page 40 of 59