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
Detects potential session hijacking where an Entra ID session is reused by a non-managed/non-compliant device from a different IP and country shortly after an initial authentication from a managed device. This pattern is consistent with infostealer malware stealing session tokens and replaying them on attacker-controlled infrastructure to bypass MFA.
Detects potential session hijacking where an Entra ID session is reused by a non-managed/non-compliant device from a different IP and country shortly after an initial authentication from a managed device. This pattern is consistent with infostealer malware stealing session tokens and replaying them on attacker-controlled infrastructure to bypass MFA.
Detects authentication to Snowflake instances where Multi-Factor Authentication (MFA) is absent and the account authenticates from multiple distinct source IP addresses within a 14-day window. This behavior is indicative of potential account takeover using compromised non-MFA credentials, a pattern consistent with activities attributed to threat actors like ShinyHunters/UNC5537.
Detects account modification activity (e.g., password resets or MFA registration changes) followed within 24 hours by a sign-in event for the same user account that is flagged as risky or exhibits anomalous device/location characteristics, indicative of social engineering campaigns like Scattered Spider.
Detects modifications to Entra ID (formerly Azure AD) that disable security defaults, per-user MFA enforcement, or conditional access policies requiring MFA. Such actions remove tenant-wide MFA protection and are often precursors to account takeover, password spraying, or ransomware attacks.
Detects successful sign-in events in Entra ID where MFA is marked as satisfied, but no interactive MFA challenge (e.g., Push, FIDO2, SMS) was recorded as completed in the authentication details. This behavior, when correlated with a new IP, device, or user-agent relative to a 30-day baseline, is highly indicative of session token replay or AitM (Adversary-in-the-Middle) attacks attempting to bypass MFA requirements.
Detects a suspicious pattern where a user authenticates to a remote access portal (like Citrix or VPN) without multi-factor authentication (MFA) or with an existing risk flag, followed by a surge in file activity (creation, modification, or renaming of >500 files or >200 distinct files) on the same account within a 24-hour window, potentially indicating compromised credential usage for staging data for exfiltration or ransomware.
This rule detects successful non-interactive sign-ins to high-value applications (e.g., Office 365, Azure, Okta) where no multi-factor authentication (MFA) challenge was performed during the current session. Such activity is a strong indicator of session hijacking or token replay attacks, where adversaries reuse stolen session cookies to bypass interactive login requirements and MFA.
Detects successful user authentication to Microsoft Entra ID or Exchange Online using legacy authentication protocols (e.g., IMAP, POP3, SMTP AUTH, Exchange ActiveSync) that bypass modern MFA enforcement. The rule specifically alerts when these legacy sign-ins originate from a source IP address not previously associated with that specific user account, indicating potential credential abuse.
Detects AWS CloudTrail events where an actor performs identity or session token manipulation, specifically through the use of sts:GetFederationToken or sts:AssumeRole, or by modifying MFA configurations such as DeactivateMFADevice or CreateVirtualMFADevice on privileged accounts. This activity may indicate an attempt to gain persistent access, bypass security controls, or masquerade as a legitimate principal.
Detects potential account takeover by monitoring identity providers (Azure AD or Okta) for MFA method resets or deletions immediately followed by new MFA method registrations for the same user. This behavior is highly characteristic of Scattered Spider's (Octo Tempest) tactic of social-engineering help-desk staff to perform MFA resets, allowing the adversary to enroll their own device to bypass MFA and maintain persistence.
Detects potential help-desk impersonation or social engineering activity involving account credential or MFA method resets, followed shortly by a sign-in from an unknown device or geography. The rule excludes activity tied to established ticketing systems or standard automated password expiration processes.
This rule monitors for indicators of compromise (IOCs) associated with the TrustSink rogue MFA provider, specifically tracking the domain 'trident-sip-filter.ngrok-free.dev' and its associated OIDC discovery path. It aggregates signals from sign-in logs, audit logs, DNS queries, and network proxy traffic to identify attempts to interact with this malicious infrastructure.
Detects successful cloud console login events across AWS, Azure, and GCP where multi-factor authentication (MFA) was not utilized, combined with impossible travel indicators (login from different countries within an 8-hour window for the same principal).
Detects sign-in activity using refresh tokens from device details (deviceId, browser, OS) that have not been previously observed for the user. This pattern is indicative of session token theft, often associated with Adversary-in-the-Middle (AiTM) phishing kits where attackers replay stolen session or refresh tokens to bypass multi-factor authentication.
Detects modifications to Microsoft Entra ID (formerly Azure AD) Conditional Access policies that lower security posture. This includes disabling policies, switching them to report-only mode, removing Multi-Factor Authentication (MFA) or grant control requirements, or expanding exclusion lists to exempt users, groups, or locations from security controls. Such modifications are often indicative of an adversary attempting to maintain persistent access or bypass MFA requirements.
Detects modifications to Microsoft Entra ID (formerly Azure AD) Conditional Access policies that lower security posture. This includes disabling policies, switching them to report-only mode, removing Multi-Factor Authentication (MFA) or grant control requirements, or expanding exclusion lists to exempt users, groups, or locations from security controls. Such modifications are often indicative of an adversary attempting to maintain persistent access or bypass MFA requirements.
This rule detects administrative changes that weaken cloud identity security, specifically the disabling of Entra ID Security Defaults, per-user MFA enforcement, or tenant-wide authentication-methods policies. These actions remove critical second-factor authentication requirements, significantly increasing the risk of unauthorized access via password-spraying or credential-stuffing attacks.
Detects instances where a user account that has been flagged as risky (e.g., unfamiliar features, impossible travel, or malicious IP activity) performs a modification or registration of multi-factor authentication (MFA) security information within a short timeframe (30 minutes). This behavior is highly indicative of an adversary attempting to establish persistence or bypass authentication controls after a credential compromise.
This rule detects scenarios where an existing SSO or Identity Provider (IdP) session is reused from a device context that differs from the one that originally performed MFA. It identifies this by joining authentication events by SessionId, specifically looking for instances where MFA occurred in one event and a subsequent non-MFA event for the same session has a different User-Agent, DeviceId, JA3 hash, or Operating System build, indicating potential session token theft or reuse.
Detects non-interactive sign-in events where a refresh token is used to authenticate without satisfying a multi-factor authentication (MFA) requirement. This pattern is indicative of potential token theft and replay attacks, where an adversary uses a stolen refresh token to maintain persistence or access resources without triggering the expected MFA prompt.
Page 2 of 22