Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
455 detections
Filters
Last updated
All Time
Detection languages
251
67
56
42
18
Contributors
196
63
61
18
17
Categories
20,401
11,795
5,864
5,145
4,864
Platforms
335
226
118
16
13
Products / Services
292
184
60
48
42
MITRE Techniques
301
233
146
139
97
CVEs
8
7
2
2
IDS Classtypes
2
2
2
IDS Protocols
6
This rule detects suspicious multi-factor authentication (MFA) behavior by identifying MFA denials that occur from an unknown IP address or with an unusual authentication method for a given user. It establishes a baseline of known IP addresses and usual authentication methods for each user over a 30-day period. Alerts are generated for recent MFA denials (within the last hour) if they involve a high-risk denial detail (e.g., too many invalid codes, user blocked) combined with an unknown IP or unusual authentication method, or if they involve any other denial reason combined with both an unknown IP and an unusual authentication method. This helps to identify potential MFA fatigue attacks or attempts to bypass MFA.
Kali365 PHaaS Device Code Detection
Cortex XDR
This rule detects potential device code phishing attempts by correlating a device code flow initiated from an unmanaged/non-compliant device with a suspicious user agent (e.g., 'python-requests' or '-live') and an 'unbound' signInTokenProtectionStatus, with a subsequent 'Cmsi:Cmsi' token replay event for the same user. This combination suggests a successful device code phishing attack where an adversary has obtained and is replaying a token after the victim has authenticated.
Detects possible MFA-approved session replay by identifying abnormal reuse of authenticated sessions across multiple IPs, browsers, and devices compared against a 14-day historical baseline. The rule prioritizes browser/device anomalies over geography since modern attackers often use same-country VPS/proxies.
Detects abnormal MFA session behavior by monitoring user sessions with multiple IPs or browsers over 24h. Note: KQL 14-day historical baseline and set_difference logic is approximated.
Detects AiTM compromise where user click phishing URL, completed MFA, and signed in from a different IP within 10 minutes
Detects when Okta FastPass prevents a known phishing site.
Detects disabling of Multi Factor Authentication.
Detects when a successful MFA authentication occurs due to the use of a bypass code.
A bypass code is a temporary passcode created by an administrator for a specific user to access a Duo-protected application. These are generally used as "backup codes," so that enrolled users who are having problems with their mobile devices (e.g., mobile service is disrupted, the device is lost or stolen, etc.) or who temporarily can't use their enrolled devices (on a plane without mobile data services) can still access their Duo-protected systems.
A bypass code is a temporary passcode created by an administrator for a specific user to access a Duo-protected application. These are generally used as "backup codes," so that enrolled users who are having problems with their mobile devices (e.g., mobile service is disrupted, the device is lost or stolen, etc.) or who temporarily can't use their enrolled devices (on a plane without mobile data services) can still access their Duo-protected systems.
Detects when an attempt at deactivating or resetting MFA.
This rule detects multiple failed sign-in attempts using the 'Device Code' authentication flow from various IP addresses or locations for a single user. This behavior can indicate an adversary attempting to bypass multi-factor authentication (MFA) or gain unauthorized access through device code phishing or brute-force attacks against the device code flow. The rule specifically looks for more than 3 attempts from more than 2 distinct IP addresses or locations, targeting common Microsoft applications like Office, Teams, Azure Portal, or Graph.
Detects successful sign-ins to the Microsoft Intune Company Portal (AppId '9ba1a5c7-f17a-4de9-a1f1-6178c8d51223') where Conditional Access Policies (CAP) have failed. This indicates an attempt to bypass device compliance requirements, potentially allowing access from non-compliant or unmanaged devices.
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 when multi-factor authentication (MFA) or strong authentication settings are disabled or removed for a user account. It specifically looks for successful audit log entries related to operations such as 'Disable Strong Authentication', 'Update user', 'Update StsRefreshTokensValidFrom', 'Admin registered security info', or 'Admin deleted security info'. This activity could indicate an adversary attempting to maintain persistent access to a compromised account by weakening its authentication requirements.
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 Okta MFA device enrollment or life cycle changes that occur shortly after a successful authentication or password reset for the same user. This pattern is a strong indicator of a post-vishing account takeover, as seen in ShinyHunters campaigns.
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.
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 KQL Query helps to keep an eye on accounts that are being excluded from Conditional Access (CA) policies which they should be blocked by it and which specific field triggered the CA detection and got them excluded.
The aim of this case is to identify:
Spot CA policies with a high number of exclusions.
Find exclusions that don’t make sense, like skipping MFA when it’s mandatory for privileged accounts.
Catch new exclusions that might not have been approved.
Check how exclusions are actually working (e.g., excluding a device is fine, but if it’s connecting from risky countries or open networks, that’s a problem—hopefully, other CA policies cover this).
Identify unexpected exclusions, which could mean an attacker got in and excluded themselves to bypass CA controls
The aim of this case is to identify:
Spot CA policies with a high number of exclusions.
Find exclusions that don’t make sense, like skipping MFA when it’s mandatory for privileged accounts.
Catch new exclusions that might not have been approved.
Check how exclusions are actually working (e.g., excluding a device is fine, but if it’s connecting from risky countries or open networks, that’s a problem—hopefully, other CA policies cover this).
Identify unexpected exclusions, which could mean an attacker got in and excluded themselves to bypass CA controls
Detects when a successful multi-factor authentication (MFA) occurs due to the use of a bypass code in Cisco Duo. Bypass codes are temporary passcodes created by administrators for specific users to access Duo-protected applications, typically used as backup codes when users cannot use their enrolled devices. This rule identifies instances where such a bypass code facilitates a successful authentication.
Detects when an organization member or an outside collaborator is added to or removed from a project board or has their permission level changed or when an owner removes an outside collaborator from an organization or when two-factor authentication is required in an organization and an outside collaborator does not use 2FA or disables 2FA.
Page 19 of 22