Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,666 detections
Filters
Last updated
All Time
Detection languages
1,077
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,401
11,795
5,864
5,145
4,864
1,666
Platforms
1,091
590
440
252
122
Products / Services
1,130
476
189
125
118
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
This rule identifies successful user sign-ins originating from IP addresses associated with residential or commercial VPN ASNs that have not been observed in the user's historical sign-in data (past 30 days). By comparing current activity against a baseline of known user locations, it flags potentially unauthorized access through masked connections.
Detects anomalous access to the Azure Portal Single Page Application (SPA) by monitoring sign-in logs. The rule flags users accessing this specific application from multiple devices or over an unusually long time span (exceeding 24 hours), which may indicate session hijacking, token theft, or unauthorized access attempts via stolen session tokens.
attackers are continuously abusing Device Code phishing, convincing victims to authenticate using the legitimate Microsoft login page. The victim completes the password and MFA correctly, but the resulting tokens are delivered to the attacker.
And one point that I think is important: Device Code Flow should not be enabled if you don't really need it. The recommendation is clear: disable it where possible and only allow documented exceptions.
The KQL below takes Cmsi:Cmsi as a reference (which means a Device Code Authentication flow was used) point and looks 15 minutes backwards (the time that a Code is valid) for the same user, grouping the authentication flow together with countries, IPs, browsers and User-Agents. The aim is to identify authentication flows where we observe different Browsers, Countries, IPs or User-Agents, potentially showing the transition between the victim and attacker context.
The idea is simple: Look at the complete authentication sequence and identify what changes between the victim and attacker context.
And one point that I think is important: Device Code Flow should not be enabled if you don't really need it. The recommendation is clear: disable it where possible and only allow documented exceptions.
The KQL below takes Cmsi:Cmsi as a reference (which means a Device Code Authentication flow was used) point and looks 15 minutes backwards (the time that a Code is valid) for the same user, grouping the authentication flow together with countries, IPs, browsers and User-Agents. The aim is to identify authentication flows where we observe different Browsers, Countries, IPs or User-Agents, potentially showing the transition between the victim and attacker context.
The idea is simple: Look at the complete authentication sequence and identify what changes between the victim and attacker context.
Detects successful authentication events using the OAuth device code flow. This flow is often abused by adversaries to perform OAuth phishing, where a user is tricked into authorizing a malicious application, granting it access tokens to cloud resources.
Detects successful Azure AD sign-in events authenticated via the device code flow that subsequently access Microsoft 365 resources such as Outlook, SharePoint, OneDrive, or Teams. This pattern is consistent with post-compromise use of OAuth tokens obtained through device-code phishing.
Detects successful authentication events using the OAuth device code flow. This flow is often abused by adversaries to perform OAuth phishing, where a user is tricked into authorizing a malicious application, granting it access tokens to cloud resources.
Detects successful Azure AD sign-in events authenticated via the device code flow that subsequently access Microsoft 365 resources such as Outlook, SharePoint, OneDrive, or Teams. This pattern is consistent with post-compromise use of OAuth tokens obtained through device-code phishing.
Detects successful Azure AD sign-in events authenticated via the device code flow that subsequently access Microsoft 365 resources such as Outlook, SharePoint, OneDrive, or Teams. This pattern is consistent with post-compromise use of OAuth tokens obtained through device-code phishing.
This rule analyzes Microsoft Entra (Azure AD) sign-in logs over a 30-day period for access to sensitive administrative applications (e.g., Azure Portal, Microsoft Intune, Defender). It flags user-application-IP sessions that exhibit unusual characteristics, such as login successes following failures, access from multiple geographic locations, or the use of multiple client types, which may indicate account compromise or unauthorized access.
Detects a Telegram account session being authorized from a new device/IP, which BlueNoroff has been observed abusing as the precursor step in the GhostCall self-propagation pipeline: operators reuse stolen/hijacked Telegram session cookies from a new device or IP, then use the hijacked session to send fake meeting invites to trusted contacts, enabling cyclical propagation to subsequent victims.
This rule only detects the session authorization event in isolation. Analysts should correlate matches on this rule with a companion rule that detects rapid meeting-invite fan-out for the same UserId occurring within roughly 15 minutes, since that cross-event correlation cannot be expressed within a single Sigma detection. A standalone match here does not confirm active self-propagation and requires that follow-up correlation to raise confidence.
This rule only detects the session authorization event in isolation. Analysts should correlate matches on this rule with a companion rule that detects rapid meeting-invite fan-out for the same UserId occurring within roughly 15 minutes, since that cross-event correlation cannot be expressed within a single Sigma detection. A standalone match here does not confirm active self-propagation and requires that follow-up correlation to raise confidence.
This rule detects potential Adversary-in-the-Middle (AiTM) phishing attacks targeting Microsoft 365. It monitors for suspicious network connections to known Evilginx-style subdomains (e.g., owa, sso, secure, billing) that proxy traffic to login.microsoftonline.com, followed immediately by a successful user login event on the same host. This pattern indicates an active session hijacking attempt designed to capture session cookies like ESTSAUTH and ESTSAUTHPERSISTENT.
This rule detects non-interactive sign-in events involving the 'Microsoft Authentication Broker' where the authentication was performed using only single-factor authentication and originated from a device that is not recognized or lacks trust information (unmanaged/unknown device). This pattern is consistent with token replay attacks or session hijacking, where an adversary uses stolen authentication artifacts to access resources without undergoing standard multi-factor authentication.
Detects anomalous sign-in behavior where a single unique token identifier is used from multiple IP addresses, countries, or devices within a short timeframe (less than one hour). This pattern is often indicative of session token theft, where an adversary uses an exfiltrated token to authenticate from a different location or device, bypassing standard credential-based authentication.
Detects successful authentication events using the OAuth device code flow. This flow is often abused by adversaries to perform OAuth phishing, where a user is tricked into authorizing a malicious application, granting it access tokens to cloud resources.
Detects anomalous, automated data exfiltration cycles in Microsoft 365 environments consistent with the Helix threat group. The rule identifies a pattern of successful sign-ins followed within 6 hours by new MFA registration, suspicious SharePoint enumeration, and a high-frequency, non-human-paced burst of file downloads.
This rule detects scenarios where a user's session originates from the 'Microsoft Authentication Broker' and another application (like 'OfficeHome' or 'One Outlook Web') within a short window (15 minutes), but from different source IP addresses. This indicates potential session hijacking or the use of stolen session cookies by an external actor.
Detects a near-simultaneous correlation between a user registering a new FIDO2 authentication method and a login session from an unmanaged or non-compliant device. This behavioral pattern is often associated with adversary-in-the-middle or vishing attacks where an attacker tricks a user into registering an attacker-controlled security key to maintain persistent MFA access.
Detects a sign-in failure with error code 50199 (indicating a device-code interrupt/waiting state) followed immediately by a successful sign-in from the same source IP address. This pattern is characteristic of device-code phishing attacks, where an attacker intercepts a device code and completes the authentication process on behalf of the victim.
Detects Microsoft Entra ID sign-in events using the non-interactive OAuth device-code protocol against the 'common' tenant endpoint where MFA was not applied. This behavior is consistent with OAuth device-code phishing campaigns (e.g., Storm-2372/DEBULL) that exploit Conditional Access device-code flow allowances to bypass standard authentication controls.
Detects a sequence of authentication events from a specific IP address associated with the Microsoft Authentication Broker app, where an initial MFA challenge (ResultType 50199 - MFA challenge) is followed by a successful authentication (ResultType 0). This pattern is indicative of MFA fatigue attacks where an adversary repeatedly prompts a user until they inadvertently approve the request.
Detects successful non-interactive sign-ins to Azure CLI using the Resource Owner Password Credentials (ROPC) flow where Conditional Access policies failed to enforce multi-factor authentication (MFA). This typically indicates misconfigured Conditional Access policies, such as exclusions for non-interactive authentication methods or service accounts, which could be exploited by adversaries to bypass MFA.
Page 50 of 80