Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,868 detections
Filters
Last updated
All Time
Detection languages
2,527
525
299
218
131
Contributors
999
706
554
263
188
Categories
1,449
1,199
1,092
793
576
Platforms
39,960
7,270
6,537
3,868
3,651
Products / Services
1,757
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 detection identifies successful logon activity (Event ID 4624) on a device that has been reported as stolen or missing. Such activity is highly suspicious and could indicate unauthorized access. The rule enriches the alert with ISP IP information from Azure AD sign-in logs to aid in investigation.
This query detects suspicious sign-in activity from a user who has recently clicked on a phishing link. It correlates email click events with sign-in logs, identifying sign-ins from new or infrequent IP addresses after a user has interacted with a suspicious email. The rule uses configurable parameters for sender email addresses, sender domains, and subject keywords to identify phishing emails.
This rule detects successful sign-ins that used single-factor authentication and were flagged by Azure AD Identity Protection for having unfamiliar properties, such as a new location, device, or ASN. Single-factor authentication is inherently weaker, and when combined with anomalous sign-in properties, it can be an indicator of a compromised account.
This rule detects suspicious activity where an Azure CLI session, initially interactive, is followed by non-interactive access from a different IP address. This could indicate an attacker using a stolen token or session from a legitimate user's interactive login to perform automated actions. The rule specifically looks for a pivot from interactive to non-interactive access where the non-interactive access occurs after the interactive access and from a different IP address, within a 30-day lookback window.
This rule detects inbound network connections to internet-facing devices on ports other than 80 (HTTP) or 443 (HTTPS). This could indicate an adversary attempting to establish command and control, exfiltrate data, or exploit services running on non-standard ports.
This KQL look for any IOCs from the given list and compare against EmailEvents on Defender for Email
Azure Device Code OAuth Consent
Cortex XDR
This rule detects suspicious activity related to Microsoft 365 Device Code OAuth consent flows. It specifically looks for device code authentications that are single-factor or lack MFA, and then groups these by IP address and client application. The rule identifies suspicious patterns such as a high number of logins, unique users, or unique applications from a single IP address, or rapid login attempts within a short timeframe, which could indicate enumeration or phishing attempts.
The current AI ecosystem has significant security gaps that can be weaponized for corporate espionage, supply-chain compromise, data harvesting, and even nation-state operations.
This KQL query identifies endpoints that are accessing, installing, or executing AI-related services or applications. The primary objective is to detect :
- Unauthorized AI usage (Policy Violation)
- Potential data exfiltration via AI platforms
- Shadow IT activity involving local or cloud-based LLMs
- High-risk AI deployments that bypass corporate policy
This KQL query identifies endpoints that are accessing, installing, or executing AI-related services or applications. The primary objective is to detect :
- Unauthorized AI usage (Policy Violation)
- Potential data exfiltration via AI platforms
- Shadow IT activity involving local or cloud-based LLMs
- High-risk AI deployments that bypass corporate policy
Multiple threat actors are compromising Microsoft 365 accounts in phishing attacks that leverage the OAuth device code authorization mechanism.
Attackers trick victims into entering a device code on Microsoft’s legitimate device login page, unknowingly authorizing an attacker-controlled application and granting them access to the target account without stealing credentials or bypassing multi-factor authentication (MFA).
Attackers trick victims into entering a device code on Microsoft’s legitimate device login page, unknowingly authorizing an attacker-controlled application and granting them access to the target account without stealing credentials or bypassing multi-factor authentication (MFA).
Try tio find out phishing domain based on mail history
This rule detects potential malicious email campaigns by identifying when multiple users submit email reports (e.g., phishing or spam) that share common entities such as sender IP, primary sender address/domain, secondary sender address/domain, or subject line. A configurable threshold determines the minimum number of distinct reports required to flag an entity as suspicious.
Detects successful Microsoft 365 sign-ins using the OAuth 2.0 device code grant flow for applications with low prevalence. This technique is used by threat actors to gain unauthorized access to accounts, bypassing some MFA controls.
This alert finds sessions where a device-code flow produced multiple sign-in events (interactive + non-interactive), with mismatched user-agents or differing country/geolocation, for the same Session ID - a strong indicator of device-code phishing abuse.
Looks for:
Brute-forcing device code tokens
Token replay attempts
Malicious use of device code authentication across different devices or locations
Anomalous sign-in behaviour suggesting account compromise
Looks for:
Brute-forcing device code tokens
Token replay attempts
Malicious use of device code authentication across different devices or locations
Anomalous sign-in behaviour suggesting account compromise
Detects potential exploitation attempts against Next.js applications vulnerable to CVE-2025-66478 (React2shell). The rule looks for POST requests to Next.js Server Action endpoints with an unusually large request body, which may indicate a malicious payload designed to trigger a deserialization RCE.
This query hunts for indicators of compromise (IOCs) and behaviors linked to the LockBit 5.0 ransomware variant. It identifies the creation of the ransom note, suspicious file renaming patterns using hexadecimal extensions, and network connections to known command-and-control (C2) infrastructure associated with LockBit activity.
This detection correlates suspicious device code authentication behaviour in Azure AD with a successful creation of a Windows Hello for Business (WHfB) credential within the same 24 hours.
Microsoft allows specific application and resource combinations (permitted by CA) access without a previously registered device. Even more, one of these combinations allows the registration of a device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
Therefore, an attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
Attackers often push further to configure WHfB (Windows Hello For Business) on the registered device. WHfB issues TPM-backed, cryptographic credentials that Entra recognizes as a strong, phishing-resistant, passwordless authentication method.
Device registration unlocks persistence, but WHfB unlocks the ability to bypass stricter authentication-strength requirements.
Analysts: Check for IP mismatches, since in the Device Code authentication event we will see the victims IP, the WHfB registration event will contain the attackers IP.
Microsoft allows specific application and resource combinations (permitted by CA) access without a previously registered device. Even more, one of these combinations allows the registration of a device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
Therefore, an attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
Attackers often push further to configure WHfB (Windows Hello For Business) on the registered device. WHfB issues TPM-backed, cryptographic credentials that Entra recognizes as a strong, phishing-resistant, passwordless authentication method.
Device registration unlocks persistence, but WHfB unlocks the ability to bypass stricter authentication-strength requirements.
Analysts: Check for IP mismatches, since in the Device Code authentication event we will see the victims IP, the WHfB registration event will contain the attackers IP.
This detection identifies cases where a successful device registration event in Azure AD occurs shortly after a successful Resource Owner Password Credentials (ROPC) authentication to Microsoft Intune Enrollment via the Microsoft Authentication Broker.
Microsoft allows specific application and resource combinations access without a previously registered device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
An attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
The following query joins ROPC successful sign-ins, to successful device registrations. Registrations that occur soon after a ROPC event (2 days in this instance) could be an indicator of abuse.
Microsoft allows specific application and resource combinations access without a previously registered device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
An attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
The following query joins ROPC successful sign-ins, to successful device registrations. Registrations that occur soon after a ROPC event (2 days in this instance) could be an indicator of abuse.
This rule detects when a domain or URL observed in Teams Messages matches a known threat intelligence indicator from Microsoft Defender Threat Intelligence. It specifically looks for hits against 'Domain' and 'URL' type indicators.
Detects when an internal user successfully authenticates as a guest to an external Microsoft Teams tenant. This could be legitimate B2B collaboration, but it can also be abused by attackers to lure users into a malicious tenant where security controls (like Safe Links/Safe Attachments) are not enforced.
Detects when an internal user successfully authenticates as a guest to an external Microsoft Teams tenant. This could be legitimate B2B collaboration, but it can also be abused by attackers to lure users into a malicious tenant where security controls (like Safe Links/Safe Attachments) are not enforced.
Detects the ToolShell exploit chain used against SharePoint servers. This exploit involves a POST request to ToolPane.aspx with a spoofed Referer header pointing to SignOut.aspx, which is a key indicator of this specific attack.
Page 145 of 185