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,443
11,831
5,875
5,151
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
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.
Detects a suspicious sequence of events where a user modifies their MFA phone number, followed within 30 minutes by a sign-in event flagged with 'impossibleTravel' or 'unfamiliarFeatures' risk. This pattern is indicative of potential SIM-swap fraud, where an attacker has hijacked the user's phone number to receive MFA prompts and then attempts to access the account from an anomalous location.
Detects Azure AD sign-in events indicative of a session token replay attack. The rule identifies successful sign-ins where the traffic source originates from known residential proxy infrastructure (anonymizing services often used by attackers) and the authentication process lacks a fresh interactive MFA challenge, suggesting the use of a stolen, valid session token.
This rule detects potentially unauthorized device registration or Intune enrollment activity by monitoring Azure Sign-in logs. It specifically flags accounts that exhibit rapid, multiple device registration attempts (>= 2 in 5 minutes) combined with suspicious indicators such as scripted User Agents ('python-requests'), the presence of Primary Refresh Tokens (PRT), specific device naming patterns, or concurrent Intune enrollment activity. These behaviors are common indicators of automated adversary activity aiming to bypass conditional access policies by enrolling illicit devices.
Detects a suspicious correlation between the registration of new authentication methods or application integrations and the subsequent modification of Conditional Access policies within a 2-hour window. This behavior is indicative of the activation phase of a TrustSink attack, where an adversary sets up a malicious MFA provider and forces its use by expanding Conditional Access policy scope.
Detects Azure AD sign-in events where Multi-Factor Authentication (MFA) was reportedly satisfied by an External Authentication Method (EAM) claim without evidence of a traditional secondary authentication challenge. This behavior is indicative of a 'TrustSink' technique where a rogue or compromised OIDC provider injects a spoofed assertion of MFA success into the authentication token.
This rule detects potential Adversary-in-the-Middle (AiTM) activity by identifying a sequence where a user experiences a sign-in interruption (ResultType 50199) followed by a successful sign-in with the same SessionId but from a different, anomalous User-Agent (typically associated with automated tools like Axios). This pattern indicates the reuse of intercepted session tokens to bypass multi-factor authentication.
Detects sign-in events where Multi-Factor Authentication (MFA) was satisfied using an External Authentication Method (EAM) that asserts specific possession or inherence claims (e.g., 'hwk' - hardware key). This behavior may indicate an adversary attempting to bypass or forge MFA responses via a rogue EAM provider.
Detects anomalous authentication patterns in Microsoft 365 logs where a valid session is utilized across multiple distinct devices within a short timeframe (under 5 minutes) without a corresponding multi-factor authentication (MFA) challenge. This behavior is indicative of a session token replay attack, where an adversary uses a stolen session cookie to bypass MFA and access cloud services.
Detects instances where a user account modifies security information, registers a new MFA method, or resets a password shortly after a successful sign-in from a country not observed for that user within the previous 30 days. This pattern is indicative of potential account takeover where an adversary adds persistence or MFA bypass methods to a newly compromised account.
Detects MFA fatigue or push-bombing attacks where a user account experiences an abnormally high volume of MFA request denials in a short duration (10 minutes), followed by a successful authentication event. The rule specifically looks for evidence where the successful authentication potentially originates from a different IP address than the failed attempts.
Detects high-frequency authentication attempts originating from user agents associated with automation frameworks (Selenium, Playwright, Puppeteer, etc.). This pattern is often indicative of automated credential stuffing, brute force attacks, or CAPTCHA/2FA bypass attempts orchestrated by headless browsers.
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 modifications to Entra ID Conditional Access or Okta authentication policies that introduce MFA exclusions, trusted network bypasses, or authentication-strength downgrades. This activity is highly indicative of an adversary attempting to maintain persistence or bypass MFA following a successful initial account compromise.
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 suspicious account management activities, such as password resets or MFA re-enrollment, performed by an operator on a high-privileged or administrator account outside of typical business hours (06:00-20:00). This behavior is often indicative of help-desk impersonation or credential takeover attempts targeting Identity Provider (IdP) administrative roles.
Page 8 of 22