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,443
11,831
5,872
5,155
4,866
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 when a user account updates their multi-factor authentication (MFA) details to include a higher count of registered devices than previously recorded. This behavior could indicate an attacker adding their own device to a compromised account to bypass MFA or maintain persistent access.
Detects sign-in failures in Azure Active Directory specifically linked to MFA error codes 50074 (MFA required) or 50140 (MFA interruption/continuation). This logic monitors for users who are unable to complete the MFA challenge during the OfficeHome sign-in process, which may indicate issues with MFA registration, configuration, or an attempt to bypass MFA requirements.
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.
Detects successful modifications to user MFA methods (StrongAuthenticationMethod) where the associated device details are missing or indicate a software-only token activation. This behavior is often indicative of an adversary adding their own MFA device to a compromised account to maintain persistent access or bypass MFA requirements.
Detects potential Adversary-in-the-Middle (AitM) activity where a user triggers both a standard MFA requirement (50074) and a subsequent MFA requirement within the same session (50140), potentially indicating the user is interacting with a proxy site that requires re-authentication or session interception. The rule specifically looks for users who trigger these events in short succession, often associated with phishing campaigns aiming to bypass MFA.
Detects modifications to a user's Azure Active Directory (Entra ID) authentication methods where a new authentication device is added. The rule specifically monitors changes to 'StrongAuthenticationPhoneAppDetail' or 'StrongAuthenticationUserDetails' and identifies instances where the count of registered devices increases, potentially indicating an attacker adding a device for persistence or MFA bypass.
Detects instances where a user account experiences an 'Unusual sign-in' event followed by the registration of a new MFA or security information method within a one-hour window. This behavior is indicative of an attacker attempting to establish persistent access by registering their own authentication device to a compromised account.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
Detects user account logins following a recent MFA registration (within 1 to 30 days) combined with subsequent network activity that utilizes node.js applications to query the Microsoft Graph API, which may indicate account takeover or malicious persistence setup.
This rule detects suspicious cloud user activity by identifying a single user account engaging in diverse, multi-stage actions (Authentication, MFA updates, Reconnaissance, and Exfiltration) originating from a high number of distinct source IP addresses. This behavioral pattern is indicative of a compromised account where an adversary is rotating IPs while performing a coordinated, multi-stage attack sequence.
Detects anomalous activity in Microsoft Graph API logs where a single identity (user or application) performs a high volume of requests across multiple sensitive administrative categories, such as directory role management, authentication method modification, application or service principal changes, and OAuth consent operations. This pattern is indicative of potential unauthorized reconnaissance, privilege escalation, or persistence attempts within an Azure/Microsoft 365 environment.
Detects the registration of a new MFA or security information method (such as StrongAuthenticationMethod, phone, or software OTP token) on an Azure AD/Entra account. This activity is often consistent with attacker-controlled MFA enrollment, used to maintain persistent access after an initial identity compromise, such as one resulting from passkey-themed phishing.
Detects multiple authentication failures in Azure AD (specifically error codes 50074: strong authentication required/MFA failure and 50140: interruption of MFA completion) originating from devices identified as either unmanaged or non-compliant. This pattern often indicates an adversary attempting to brute force or bypass conditional access policies by leveraging credentials where the device security posture is insufficient.
Detects multiple failed multifactor authentication (MFA) attempts from the same user on an unmanaged device. This behavior is indicative of an adversary attempting to bypass MFA or perform MFA fatigue attacks using stolen credentials.
This rule detects potential adversary-in-the-middle (AiTM) or device-code authentication attacks where a user reports suspicious vishing (voice phishing) or SMS lures involving passkeys or SSO updates. The rule correlates user-reported social engineering pretexts with evidence of risky authentication flows, such as device code usage or specific authentication error codes associated with interception.
This rule identifies instances where a user successfully authenticates using a phone app OTP MFA method that was registered between 1 and 30 days prior. The rule specifically flags logins associated with potentially automated or non-browser user agents, or logins flagged with risk, suggesting potential account takeover or persistence mechanisms involving MFA re-registration.
Detects a suspicious pattern where a user registers a new PhoneAppOTP MFA method and subsequently logs in using this method after a significant time delay (exceeding 3 days). This behavior is indicative of an attacker who has gained temporary access, registered their own MFA device to ensure persistent future access, and returned later to utilize it.
Detects a suspicious pattern where a user registers a new PhoneAppOTP MFA method and subsequently logs in using this method after a significant time delay (exceeding 3 days). This behavior is indicative of an attacker who has gained temporary access, registered their own MFA device to ensure persistent future access, and returned later to utilize it.
Detects a sequence of authentication events indicative of Adversary-in-the-Middle (AiTM) phishing, where a user session experiences MFA-related errors (50074, 50140) followed by a successful sign-in (0). This pattern suggests an adversary proxying credentials and MFA requests in real-time.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
Page 6 of 13