Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
256 detections
Filters
Last updated
All Time
Detection languages
105
48
37
29
21
Contributors
95
44
35
17
11
Categories
20,401
11,795
5,864
5,145
4,864
Platforms
160
128
78
7
7
Products / Services
144
123
42
33
30
MITRE Techniques
152
104
90
82
80
IDS Classtypes
3
IDS Protocols
3
Detects the registration of a new MFA authentication method on an Entra ID account from an unrecognized IP or device, occurring in close temporal proximity to a password reset or a risky sign-in event. This behavior is indicative of an adversary establishing persistence via self-service MFA registration after compromising user credentials.
Detects a sequence of events where a user performs a risky or anomalous login to Azure AD, such as from an anonymous network or an non-compliant device, followed shortly after by the registration of a new MFA method or security information. This behavior is indicative of an attacker who has compromised credentials and is attempting to establish persistence or bypass authentication controls by enrolling their own MFA device.
Detects a successful self-service password reset followed shortly by an authentication method change on the same account -- the exact SSPR-then-MFA-reregistration sequence used by Storm-3068 and Storm-2949 for persistence.
Hardened before submission: switched TargetResources[0] positional indexing to mv-expand + type == "User" matching, consistent with the fix already applied to the Agent User group-membership rule.
MITRE ATT&CK: T1098.005 (Account Manipulation: Device Registration), T1556 (Modify Authentication Process)
Hardened before submission: switched TargetResources[0] positional indexing to mv-expand + type == "User" matching, consistent with the fix already applied to the Agent User group-membership rule.
MITRE ATT&CK: T1098.005 (Account Manipulation: Device Registration), T1556 (Modify Authentication Process)
Detects MFA-fatigue style attacks (push-bombing) against Microsoft 365 accounts. The rule identifies a pattern where a user experiences a high frequency of MFA challenges or denials (at least 5 within a 10-minute window) immediately followed by a successful sign-in from a previously unseen IP and device, excluding phishing-resistant authentication methods and break-glass accounts.
Detects MFA-fatigue style attacks (push-bombing) against Microsoft 365 accounts. The rule identifies a pattern where a user experiences a high frequency of MFA challenges or denials (at least 5 within a 10-minute window) immediately followed by a successful sign-in from a previously unseen IP and device, excluding phishing-resistant authentication methods and break-glass accounts.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Detects the multi-stage Microsoft cloud identity compromise chain reported by Microsoft Security Research (September 2026): a victim completes a successful Entra ID device-code sign-in (often induced by passkey-themed device-code phishing), the same identity's authentication/security info is registered or changed (MFA/passkey persistence) within 60 minutes (deduplicated to the earliest such event per sign-in), followed within 120 minutes by a burst of at least 25 successful, delegated-context Microsoft Graph API calls (Scopes claim populated, i.e. user-delegated permissions rather than pure application/client-credential access) spanning at least 3 distinct resource paths, exhibiting reconnaissance (>=5 requests against /users, /groups, /directoryRoles, /roleManagement, /applications, /servicePrincipals, /organization) and/or collection (>=10 requests against /messages, /mailFolders, /attachments, /drive, /drives, /sites, /lists, /search) patterns. Restricting to delegated (Scopes-bearing) Graph calls and requiring resource-path breadth removes the two largest false-positive sources: service-principal/application-only automation jobs (Roles-only tokens) and single-endpoint polling tools. Pure behavioral correlation across SigninLogs, AuditLogs, and MicrosoftGraphActivityLogs - no static IOCs. Flags whether Graph activity originated from an IP different from the original device-code sign-in IP as a strong pivot/session-reuse indicator.
Detects user authentication events where the MFA redirect URL points to an unrecognized or potentially malicious domain. This behavior is indicative of an Adversary-in-the-Middle (AiTM) attack, such as the TrustSink credential capture technique, where the user is diverted from the legitimate identity provider to an attacker-controlled OIDC endpoint to capture credentials or session tokens.
Detects a suspicious sequence of events where a user's registered phone number or recovery contact method is updated, followed shortly by an MFA factor reset or new factor enrollment. This pattern is a common indicator of a SIM-swap attack, where an attacker intercepts SMS-based MFA codes after hijacking the victim's phone number.
Detects the registration or modification of multi-factor authentication (MFA) security information in Entra ID or Okta that occurs within 15 minutes of a sign-in event flagged as risky. This behavioral pattern is a common indicator of persistence being established by an attacker after performing an adversary-in-the-middle (AiTM) attack, where they leverage a stolen session to register their own MFA factors to maintain long-term access.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Single-source Sigma proxy for the authentication-persistence stage of the multi-stage device-code-phishing-to-Graph-collection chain (see the companion KQL correlation rule "Passkey Persistence: Device-Code Phishing to MFA Takeover and Graph Collection" for the full, threshold-gated, cross-table detection). Sigma has no join, temporal-windowing, or aggregation support, so this rule fires on the authentication-persistence event alone and does NOT enforce the device-code sign-in precursor or the subsequent Graph-activity burst - both required by the full correlation. Scoped to the two highest-signal operations only (new security-info registration, and any admin-initiated registration on another user's account) to cut noise from routine self-service profile edits.
Detects the multi-stage Microsoft cloud identity compromise chain reported by Microsoft Security Research (September 2026): a victim completes a successful Entra ID device-code sign-in (often induced by passkey-themed device-code phishing), the same identity's authentication/security info is registered or changed (MFA/passkey persistence) within 60 minutes (deduplicated to the earliest such event per sign-in), followed within 120 minutes by a burst of at least 25 successful, delegated-context Microsoft Graph API calls (Scopes claim populated, i.e. user-delegated permissions rather than pure application/client-credential access) spanning at least 3 distinct resource paths, exhibiting reconnaissance (>=5 requests against /users, /groups, /directoryRoles, /roleManagement, /applications, /servicePrincipals, /organization) and/or collection (>=10 requests against /messages, /mailFolders, /attachments, /drive, /drives, /sites, /lists, /search) patterns. Restricting to delegated (Scopes-bearing) Graph calls and requiring resource-path breadth removes the two largest false-positive sources: service-principal/application-only automation jobs (Roles-only tokens) and single-endpoint polling tools. Pure behavioral correlation across SigninLogs, AuditLogs, and MicrosoftGraphActivityLogs - no static IOCs. Flags whether Graph activity originated from an IP different from the original device-code sign-in IP as a strong pivot/session-reuse indicator.
Detects instances where a user account registers a new Multi-Factor Authentication (MFA) method (such as TOTP or Authenticator app) shortly (within 30 minutes) after a high-risk or potentially anomalous sign-in event. This pattern is commonly associated with adversary-in-the-middle (AiTM) phishing attacks where an attacker captures an authenticated session and uses it to enroll a secondary, attacker-controlled MFA device for persistent account access.
This rule detects modifications to multi-factor authentication (MFA) settings performed by privileged users (e.g., Global Admins) from IP addresses not previously associated with their account. The rule tracks actions such as registering new security information, changing default MFA methods, or deleting authentication methods. High-risk indicators like an unknown IP address for a privileged account are flagged for further investigation.
This rule detects modifications to multi-factor authentication (MFA) settings performed by privileged users (e.g., Global Admins) from IP addresses not previously associated with their account. The rule tracks actions such as registering new security information, changing default MFA methods, or deleting authentication methods. High-risk indicators like an unknown IP address for a privileged account are flagged for further investigation.
Detects a suspected account takeover pattern where an Azure AD account logs into the Azure Portal shortly after experiencing failed authentication attempts from the same IP address. The detection correlates password spraying or VPN probing activity (multiple failed logins against different users from a single IP) with subsequent successful or near-successful logins (MFA enrollment interrupts) on the Azure Portal, signaling potential post-compromise activity.
Detects MFA-fatigue style attacks (push-bombing) against Microsoft 365 accounts. The rule identifies a pattern where a user experiences a high frequency of MFA challenges or denials (at least 5 within a 10-minute window) immediately followed by a successful sign-in from a previously unseen IP and device, excluding phishing-resistant authentication methods and break-glass accounts.
Flags FIDO2/passkey registrations initiated or facilitated by a helpdesk/support identity for another user's account, matching Okta's advisory on threat actor O-UNC-066 ('Pink' leak site) and the ShinyHunters O-UNC-037 campaign that mimicked Microsoft's passkey enrollment flow to register attacker-controlled passkeys.
Detects when a user adds a new Multi-Factor Authentication (MFA) method such as a phone number, authenticator app, or FIDO2 key in Entra ID (Azure AD). Attackers often register their own MFA devices to maintain persistent access to a compromised account, particularly following a successful password reset or social engineering event.
Detects a suspicious pattern where an inbound Microsoft Teams call or chat from an untrusted external guest tenant is followed within 30 minutes by a credential, MFA, or account-recovery action on the target user's account in Entra ID. This behavior is indicative of a vishing-over-Teams attack where an adversary impersonates IT support to facilitate unauthorized account recovery or MFA bypass.
Page 2 of 13