Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
170 detections
Filters
Last updated
All Time
Detection languages
70
30
24
17
15
Contributors
49
33
20
8
8
Categories
104
61
51
49
42
Platforms
93
64
28
16
15
Products / Services
99
41
24
23
21
MITRE Techniques
18,116
15,638
12,585
8,395
6,225
CVEs
2
IDS Classtypes
3
3
3
IDS Protocols
9
This rule detects potential MFA fatigue attacks (Push Bombing) by monitoring sign-in logs for a high volume of authentication prompts directed at a single user within a one-hour window. It specifically identifies patterns where a user receives multiple denied MFA push requests followed by at least one successful approval. The rule also accounts for suspicious behavior such as requests originating from multiple IP addresses or geographic locations.
This rule detects HTTP requests to the Microsoft device login endpoint (/devicelogin) that originate from a non-Microsoft referrer domain. This behavior is highly indicative of Adversary-in-the-Middle (AiTM) phishing attacks targeting OAuth device code flows, where a malicious proxy site redirects users to the legitimate Microsoft login page while attempting to capture session tokens.
Detects sign-in failures in Azure Active Directory specifically linked to MFA error codes 50074 (MFA required) or 50140 (MFA interruption/continuation). This logic monitors for users who are unable to complete the MFA challenge during the OfficeHome sign-in process, which may indicate issues with MFA registration, configuration, or an attempt to bypass MFA requirements.
This rule detects HTTP requests to the Microsoft device login endpoint (/devicelogin) that originate from a non-Microsoft referrer domain. This behavior is highly indicative of Adversary-in-the-Middle (AiTM) phishing attacks targeting OAuth device code flows, where a malicious proxy site redirects users to the legitimate Microsoft login page while attempting to capture session tokens.
Detects anomalous sign-in activity where a user triggers both Error Code 50074 (MFA required) and 50140 (MFA bypass occurred or not required/invalidated) in a short window of time (less than 1 hour). The rule looks for sessions on unmanaged devices (empty TrustType) using Chrome, which may indicate an adversary attempting to bypass or manipulate MFA enrollment or verification flows.
Detects multiple authentication failures in Azure AD (specifically error codes 50074: strong authentication required/MFA failure and 50140: interruption of MFA completion) originating from devices identified as either unmanaged or non-compliant. This pattern often indicates an adversary attempting to brute force or bypass conditional access policies by leveraging credentials where the device security posture is insufficient.
Detects multiple failed multifactor authentication (MFA) attempts from the same user on an unmanaged device. This behavior is indicative of an adversary attempting to bypass MFA or perform MFA fatigue attacks using stolen credentials.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects a sequence of events where a user performs a sign-in from an unmanaged or mobile device while interacting with applications often associated with MFA or SSO prompts (indicative of a social engineering lure), followed by an administrative update to register a new authentication method within 30 minutes. This pattern is characteristic of attackers establishing persistent access to an account by adding their own MFA device.
This rule identifies potential MFA fatigue attacks by detecting multiple MFA denial or failure events for a user within a 30-minute window, followed by a successful authentication for the same user in the same time frame.
This rule detects successful device-code authorization logins to Azure AD that originate from a country or region not previously associated with the user. It evaluates the user's historical sign-in locations to establish a baseline and flags deviations, which may indicate account compromise via device-code phishing or MFA bypass attempts.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects outbound WebSocket upgrade requests from internal network assets to known IronToll C2 IP addresses, restricted to requests whose Host header ends in one of the disposable TLDs observed across the campaign's 73+ rotating lookalike domains (.cfd, .sbs, .shop, .icu, .buzz, etc). This narrows the alert to the campaign's actual phishing-domain pattern rather than any WebSocket traffic that happens to reach the same shared Tencent/Alibaba cloud IPs, and a per-source threshold caps repeat alerts from the same host to one per hour.
Detects multiple failed multifactor authentication (MFA) attempts from the same user on an unmanaged device. This behavior is indicative of an adversary attempting to bypass MFA or perform MFA fatigue attacks using stolen credentials.
Surfaces Silverfort-detected incidents excluding ImpossibleTravel (high FP rate from VPN and mobile users, better covered by XSIAM Analytics UEBA)
Detects HTTP requests to known UNC6671 AiTM reverse-proxy phishing kit IPs on MFA/OTP interception URI paths (push-tap, duo-push, oauth2 2fa, community verify), indicating live MFA bypass.
Detects user account lockouts or instances where a user has been flagged for frequent failed authentication attempts within the Duo Security platform. This activity is indicative of brute force attacks, credential stuffing, or attempts to bypass Multi-Factor Authentication (MFA) via fatigue or repeated request generation.
This rule detects instances where a user has explicitly marked an MFA push notification as fraudulent within the Duo Security platform. This indicates that an unauthorized party may have triggered an MFA request using stolen credentials, and the legitimate user is actively denying the authentication attempt.
Duo MFA Push Fatigue Activity
Cortex XDR
Detects a suspicious burst of multi-factor authentication (MFA) push request denials (such as user cancellations or ignored requests) originating from a single user within a short time window. This behavior is indicative of MFA fatigue, where an attacker repeatedly triggers MFA requests in an attempt to annoy or trick the legitimate user into inadvertently approving a push notification.
Detects successful passkey/WebAuthn authentication or signing events where the User Verification (UV) flag is unset/false or no UV assertion accompanies a device-key signature, scoped to relying parties/credentials where UV is policy-required, or corroborated by a missing biometric/user-presence event or a static (unchanged) signature counter. This reduces noise from relying parties or lower-risk contexts that legitimately do not require UV on every assertion.
Detects successful passkey/WebAuthn authentication or signing events where the User Verification (UV) flag is unset/false or no UV assertion accompanies a device-key signature, scoped to relying parties/credentials where UV is policy-required, or corroborated by a missing biometric/user-presence event or a static (unchanged) signature counter. This reduces noise from relying parties or lower-risk contexts that legitimately do not require UV on every assertion.
Page 3 of 9