Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
597 detections
Filters
Last updated
All Time
Detection languages
285
97
95
69
31
Contributors
186
88
47
47
44
Categories
20,440
11,814
5,871
5,145
4,864
597
Platforms
300
161
158
103
25
Products / Services
221
148
147
132
88
MITRE Techniques
536
265
233
226
98
CVEs
5
5
5
5
4
IDS Classtypes
1
IDS Protocols
1
Detects a suspicious sequence of administrative actions where a user's phishing-resistant multi-factor authentication (MFA) factor, such as FIDO2, passkeys, or certificates, is removed and immediately replaced by a weaker authentication method like SMS, voice call, or TOTP. This behavior, when performed by an administrator account on a different user account, is a common indicator of an MFA bypass attempt often associated with social engineering or insider threat scenarios.
Detects high-privilege OAuth application consent grants occurring shortly after a user identity recovery event (e.g., password or MFA reset). This pattern is indicative of a help-desk social engineering attack where an adversary uses an identity reset to gain access to an account and subsequently establishes persistent access via a malicious OAuth application.
Detects high-risk identity modifications (password or MFA resets) following an IT helpdesk ticket that lacks mandatory security controls, such as callback verification, manager approval, or established ticket history. This behavior is indicative of vishing and social engineering attacks aimed at helpdesk personnel to compromise user accounts.
Detects anomalous large-volume file download or export activity from cloud repositories (SharePoint, OneDrive, or Salesforce) occurring shortly after a help-desk-mediated credential or MFA reset for the same user. This behavior is indicative of account takeover, specifically vishing-to-exfiltration patterns used by threat actors.
Detects the registration of a new MFA device or authenticator by a user shortly after a password reset event, where the registration originates from an IP address classified as a hosting provider, datacenter, or VPN. This pattern is indicative of a help-desk or vishing-based account takeover attack where an adversary registers their own MFA device to gain persistent access.
Detects modifications to Active Directory user accounts (Event IDs 4720, 4738) that coincide with suspicious MFA registration indicators—such as increased device counts, software token activations, or default device/token placeholders—within one hour of a successful user authentication event. This behavior is indicative of potential account takeover or persistence activities involving MFA manipulation.
Detects when a user registers a new MFA or authentication method, such as a software token or authenticator app, within one hour of a suspicious sign-in event. This pattern is commonly indicative of an adversary establishing persistence or bypassing authentication controls following account compromise via phishing or credential harvesting.
This rule monitors for updates to a user's multi-factor authentication (MFA) configuration, specifically detecting when a new device is registered or activated. Attackers often register their own devices as MFA second factors to maintain persistent access to a compromised user account.
Detects modifications to a user account's authentication methods, specifically when an increase in the number of configured multi-factor authentication (MFA) devices or methods occurs. This is often associated with an adversary enrolling their own device to bypass MFA or maintain persistent access.
This rule detects a sequence of events where a database user record is updated (inserting a new password hash) followed by a successful authentication for that same user, immediately following a recent login failure. This pattern is indicative of an attacker modifying credentials and then testing the new access.
Detects scenarios where a user registers a new WebAuthn/Passkey credential and subsequently performs a sign-in from a different network or device shortly after, preceded by a sign-in from a risky or non-passkey-based method. This pattern is often associated with credential abuse or MFA registration hijacking.
Detects anomalous, high-frequency MFA method resets, deletions, or updates performed by a single administrative account within a 15-minute window. This activity is indicative of a compromised support or helpdesk account being leveraged to bypass multi-factor authentication across multiple user accounts for unauthorized access or account takeover.
Detects the addition of a new strong authentication method (MFA/authenticator device) to an account. This activity is a common indicator of persistence following a successful AiTM (Adversary-in-the-Middle) phishing attack or initial account compromise, as attackers establish their own MFA device to maintain long-term access.
Detects modifications or additions to Multi-Factor Authentication (MFA) security information for high-value users, specifically targeting those with executive titles (Director, VP, President, etc.). This behavior is frequently associated with account takeover attempts where an attacker registers their own MFA device to a compromised privileged account to maintain persistence.
This rule detects scenarios where a user completes a device-code authentication flow, followed immediately (within 10 minutes) by the registration of an unmanaged, non-compliant device to their account. This behavior is indicative of potential token theft (e.g., EvilTokens) where an adversary uses a stolen token to register their own device as a persistent, unmanaged entity, bypassing standard corporate device enrollment controls.
This rule detects scenarios where a user completes a device-code authentication flow, followed immediately (within 10 minutes) by the registration of an unmanaged, non-compliant device to their account. This behavior is indicative of potential token theft (e.g., EvilTokens) where an adversary uses a stolen token to register their own device as a persistent, unmanaged entity, bypassing standard corporate device enrollment controls.
This rule detects scenarios where a user completes a device-code authentication flow, followed immediately (within 10 minutes) by the registration of an unmanaged, non-compliant device to their account. This behavior is indicative of potential token theft (e.g., EvilTokens) where an adversary uses a stolen token to register their own device as a persistent, unmanaged entity, bypassing standard corporate device enrollment controls.
This rule detects scenarios where a user completes a device-code authentication flow, followed immediately (within 10 minutes) by the registration of an unmanaged, non-compliant device to their account. This behavior is indicative of potential token theft (e.g., EvilTokens) where an adversary uses a stolen token to register their own device as a persistent, unmanaged entity, bypassing standard corporate device enrollment controls.
Detects a suspicious sequence of events where a user modifies the Entra Authentication Methods Policy to register an external authentication method (EAM) provider, followed immediately by the same user associating a new FIDO key with their account. This behavior can be indicative of an adversary setting up a persistence mechanism via a malicious or unauthorized MFA provider.
Detects a suspicious sequence of events where a user modifies the Entra Authentication Methods Policy to register an external authentication method (EAM) provider, followed immediately by the same user associating a new FIDO key with their account. This behavior can be indicative of an adversary setting up a persistence mechanism via a malicious or unauthorized MFA provider.
Detects administrator-privileged actions in JFrog Artifactory audit logs attributed to the 'token:anonymous' identity, the tell-tale signature left when CVE-2026-42018 (unauthenticated token retrieval) is chained with CVE-2026-42016 (privilege escalation) to mint an admin-scope token that retains the anonymous username. Also relevant to CVE-2026-82329 authentication bypass activity.
Page 10 of 29


