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,417
11,806
5,870
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 successful Azure AD sign-in events where the session is marked as compliant or trusted by Conditional Access policies, but simultaneously flagged by Identity Protection as originating from an anonymized IP (e.g., residential proxy, VPN). This indicates an adversary has bypassed location-based Conditional Access controls, likely in the context of an Adversary-in-the-Middle (AiTM) phishing attack.
Detects sign-in activity where an attacker or user fails a phishing-resistant MFA challenge (such as FIDO2, Windows Hello, or Passwordless Phone) and immediately succeeds using a lower-assurance, phishable factor (SMS, Voice call, or Push notification). This pattern is indicative of an Adversary-in-the-Middle (AiTM) attack attempting to bypass stronger authentication methods.
Detects a suspicious authentication pattern involving 3 or more MFA failures within 15 minutes, immediately followed by an MFA success for the same user. This pattern is characteristic of potential Adversary-in-the-Middle (AiTM) activity, where an attacker intercepts a session or MFA token and relays it through separate infrastructure, while the legitimate user's own MFA attempts fail or time out.
Detects instances where an existing, non-interactive SSO session token is reused from a suspicious network location, such as an anonymizing proxy, VPN, or VPS, or triggered by an impossible travel risk event. The rule specifically looks for token usage that lacks a fresh interactive Multi-Factor Authentication (MFA) challenge, a common indicator of session token hijacking or 'replay' attacks frequently used in cloud account takeover campaigns.
This rule detects two suspicious patterns related to authentication: (1) 'MFA Fatigue' or 'Push Bombing' where a user experiences a high volume of MFA push denials followed by an acceptance in a short timeframe, and (2) potential account takeover where a help-desk initiated password reset is followed by an MFA re-registration or new device enrollment by the same user within 30 minutes.
Detects instances where a user successfully authenticates via the OAuth Device Code flow using an unmanaged or non-compliant device, followed closely by high-privileged Azure/Graph API administrative actions within a short timeframe. This behavior is indicative of a device-code phishing attack aimed at bypassing MFA controls, including FIDO2/passkeys, by compromising an active session.
Detects instances where a user successfully authenticates to a cloud service (Azure AD) from an unrecognized ASN, device, or country without performing MFA, followed shortly by high-risk actions such as mailbox rule creation, mass file downloads, or OAuth application registration. This pattern is indicative of session cookie theft or OAuth token replay used to bypass MFA.
Detects suspicious help-desk activity where a user password is reset by an administrator followed shortly by a new MFA factor being enrolled for that same user. This pattern is characteristic of Scattered Spider-style social engineering and vishing attacks to bypass MFA without deploying malware.
Detects suspicious help-desk activity where a user password is reset by an administrator followed shortly by a new MFA factor being enrolled for that same user. This pattern is characteristic of Scattered Spider-style social engineering and vishing attacks to bypass MFA without deploying malware.
Detects a suspicious correlation where an employee's phone number undergoes a SIM change or number reassignment event, immediately followed by a successful login using SMS-based MFA for the same identity. This pattern is indicative of SIM swapping/hijacking attacks, often used by threat actors like Scattered Spider to bypass SMS-based multi-factor authentication.
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 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 instances where a Temporary Access Pass (TAP) is assigned to a user account, followed by a sign-in from an unmanaged or non-compliant device within one hour. This behavior is indicative of potential help-desk impersonation (vishing) attacks where an adversary obtains a TAP to bypass standard authentication controls.
Detects a suspicious sequence of events indicative of social engineering. An administrator or help-desk account resets a user's password, followed within 15 minutes by the target user performing a successful MFA authentication from a device or IP address not associated with that user in the preceding 30 days, suggesting an attacker hijacked the session or coerced the user after the password reset.
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.
Aggregates password/MFA reset actions by the performing helpdesk identity, alerting on abnormal reset volume or resets outside a normal ticket pattern — a proxy for a support agent being repeatedly socially engineered or a fraudulent-ticket abuse pattern.
Flags re-enablement of legacy/basic authentication protocols or a new per-user authentication-policy exclusion occurring shortly after that account's MFA method was reset — the fallback technique used to sidestep modern MFA once the vishing playbook's reset step succeeds.
Detects an Azure AD/Entra ID device registration or join event occurring within 60 minutes of an account-recovery action (password reset, MFA reset, or account unlock) for the same user identity. This sequence is indicative of an attacker registering a managed device to maintain persistent, long-term access following a successful account takeover or vishing-based helpdesk credential reset.
Detects the removal of phishing-resistant authentication methods (FIDO2 or Windows Hello for Business) and the registration of weaker, phishable MFA methods (SMS, voice, or phone app) within Entra ID. This behavior is indicative of an attacker attempting to lower the security posture of an account to facilitate future credential theft or unauthorized access.
Detects instances where an administrative action involving a password reset or MFA configuration (StrongAuthenticationMethod update) is initiated by a user account that lacks the designated Helpdesk or Password Administrator role. This behavior indicates potential unauthorized privilege escalation or credential manipulation by an account not formally assigned to support workflows.
This rule detects a potential vishing attack by correlating suspicious IT helpdesk requests (e.g., password or MFA reset without manager approval or verified callback) with subsequent sensitive Entra ID identity changes (e.g., self-service password resets, MFA device registration, or new device registration) occurring for the same user within a short time window. This activity is indicative of an attacker attempting to social-engineer helpdesk staff to bypass authentication controls and compromise a user account.
Page 7 of 22