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,402
11,796
5,865
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
Detects Microsoft 365 sign-in events where a session token is reused without a fresh MFA challenge, originating from known residential proxy service providers. This behavior is indicative of threat actors using stolen session tokens (Session Replay) to bypass MFA protections.
Detects anomalous reuse of an authenticated Microsoft 365 session cookie shortly after a successful MFA-satisfied sign-in. The detection identifies scenarios where the subsequent access originates from a different IP address, device, or user agent without an intervening MFA challenge, which is a pattern indicative of session hijacking techniques like Adversary-in-the-Middle (AiTM) or session token replay.
Detects successful authentication to Microsoft Teams or Slack where MFA was successfully completed, but the device is reported as unmanaged or non-compliant and is accompanied by sign-in risk signals. This behavior is consistent with Adversary-in-the-Middle (AitM) proxy attacks where an attacker captures credentials and session tokens, bypassing MFA, and using the hijacked session from an unrecognized device or location.
Detects signs of Adversary-in-the-Middle (AiTM) phishing kits by identifying sequential, rapid-fire attempts to authenticate using multiple distinct MFA methods (such as push notifications, TOTP codes, or SMS) within a single sign-in session. These attempts are combined with explicit failure states (rejected passwords, rejected codes, or denied MFA requests), suggesting an attacker is relaying authentication challenges in real-time to a victim.
Detects session hijacking activity characteristic of the Mirage2FA AiTM (Adversary-in-the-Middle) phishing toolkit. The rule identifies non-interactive authentication events (token reuse) that lack an MFA challenge, occurring shortly after interaction with a known malicious phishing proxy domain. It further correlates this activity with anomalous signals, such as impossible travel or the use of an unseen device/user-agent, to confirm high-fidelity malicious intent.
Detects signs of exploitation against FortiOS/FortiProxy authentication bypass vulnerabilities (CVE-2024-55591 / CVE-2025-24472) consistent with Gunra ransomware activity. This rule monitors for administrative logins originating from non-management public IP addresses and identifies potential MFA bypass attempts through the reuse of identical one-time passcodes across multiple distinct accounts or sessions within a one-hour window.
This rule detects potentially unauthorized or suspicious administrative actions in an Azure environment following a login to specific AI-related applications (AI Gateway, LLM Proxy, or Model Router). It triggers when a user authenticates without applying Conditional Access policies or without Multi-Factor Authentication (MFA), followed immediately (within 30 minutes) by sensitive Azure administrative operations such as role assignments, Key Vault access, or VM write operations.
This rule detects potentially unauthorized or suspicious administrative actions in an Azure environment following a login to specific AI-related applications (AI Gateway, LLM Proxy, or Model Router). It triggers when a user authenticates without applying Conditional Access policies or without Multi-Factor Authentication (MFA), followed immediately (within 30 minutes) by sensitive Azure administrative operations such as role assignments, Key Vault access, or VM write operations.
Detects signs of exploitation against FortiOS/FortiProxy authentication bypass vulnerabilities (CVE-2024-55591 / CVE-2025-24472) consistent with Gunra ransomware activity. This rule monitors for administrative logins originating from non-management public IP addresses and identifies potential MFA bypass attempts through the reuse of identical one-time passcodes across multiple distinct accounts or sessions within a one-hour window.
Detects a user registering a new MFA or authentication method within a short window after multiple failed Entra ID sign-in attempts, without a corresponding verified helpdesk password-reset ticket. This pattern is indicative of vishing or helpdesk-impersonation attacks aimed at hijacking user accounts by circumventing MFA controls.
Detects Okta MFA factor re-enrollment immediately preceded by a burst (>=2) of failed MFA authentication challenges within 15 minutes, indicating attacker-driven MFA takeover following AiTM credential theft.
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 non-interactive sign-ins (refresh-token usage) for Microsoft Purview Communication Compliance reviewer accounts (Administrator, Analyst, or Investigator roles) that originate from IP addresses not observed for the user in the previous 21 days. This behavior is indicative of potential token theft or session hijacking attempting to bypass multi-factor authentication.
Detects non-interactive sign-ins (refresh-token usage) for Microsoft Purview Communication Compliance reviewer accounts (Administrator, Analyst, or Investigator roles) that originate from IP addresses not observed for the user in the previous 21 days. This behavior is indicative of potential token theft or session hijacking attempting to bypass multi-factor authentication.
Detects Okta accounts that enroll a new MFA factor within a short window after multiple failed or abandoned MFA authentication attempts. This behavior is indicative of an attacker who has compromised credentials and is attempting to establish persistent access by bypassing or reconfiguring MFA. The rule includes logic to exclude legitimate self-service enrollments that have a corresponding verified helpdesk or change-management ticket.
This rule detects modifications to Google Workspace user account recovery methods, including the generation or deletion of 2SV (2-Step Verification) backup scratch codes, and changes to recovery email addresses or recovery phone numbers. These actions are often performed during account takeover attempts to establish persistence or facilitate bypassing MFA.
Detects instances where a user who has not enrolled in Duo MFA successfully authenticates due to being connected to a defined trusted network. This behavior indicates an MFA coverage gap, potentially allowing an attacker to authenticate as an unenrolled user without MFA if they gain access to a trusted network or VPN.
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 sign-in events where a sign-in attempt is performed with a valid application ID but contains a blank application name, indicating potential spoofing of an OAuth client to bypass Conditional Access policies. The rule specifically monitors instances where Conditional Access status is recorded as 'notApplied'.
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.
Page 13 of 22