Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,666 detections
Filters
Last updated
All Time
Detection languages
1,077
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,443
11,831
5,872
5,155
4,866
1,666
Platforms
1,091
591
441
252
122
Products / Services
1,130
476
189
125
117
MITRE Techniques
945
843
438
416
413
CVEs
12
12
9
6
5
IDS Classtypes
1
1
This rule detects suspicious activity on high blast radius accounts, specifically correlating failed authentication attempts, password resets, and successful logons outside business hours.
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
The rule prioritizes detection based on a password reset event to produce an informational severity alert, then looks for preceding failed authentications and subsequent out-of-hours logons to indicate a potential compromise by raising severity accordingly.
You will need to utilise the AlertSeverityOverride configuration, pointed at the AlertSeverity field, in your Sentinel rule metaconfig to use this detection effectively.
Hard requirement: Need UEBA enabled in your tenant to populate the BlastRadius field in your IdentityInfo table.
Change each stage to suit your log source for the behaviour mapped to this stage.
Add in other stages if needed to add more dynamic severity (e.g., Account has high blast radius AND is a GA AND was logged in to from outside of expected geolocation > Critical severity)
Detects anomalous activities associated with the Zerologon (CVE-2020-1472) vulnerability. The rule identifies suspicious machine account password changes, NTLM authentication from potentially untrusted subnets or unconfigured workstations, and privilege escalation indicators occurring on domain controllers.
Detects session hijacking attempts where a session cookie is used from a different IP address or user-agent immediately following a successful MFA authentication event. This behavior is indicative of an adversary replaying a stolen session token.
Detects session hijacking consistent with Browser-in-the-Middle (BitM) attacks like Bluekit PhaaS, where an attacker captures an authenticated session token. The rule identifies instances where a successful MFA-protected login event is immediately followed by a session reuse event from a different IP address or network location, which is indicative of the attacker utilizing the intercepted session.
Detects suspicious authentication and management events associated with SD-WAN devices, specifically targeting indicators of CVE-2026-20245 exploitation. The rule monitors for unauthorized SSH access, usage of tenant-upload commands, execution of rogue scripts like vconfd_script_upload_tenant_list, and anomalous peering activity indicative of device injection.
Detects successful sign-ins to specific Azure AD applications known to bypass Conditional Access policies, where Conditional Access was not applied. This could indicate an attempt to circumvent security controls.
This rule detects successful network logons (LogonType 3) using NTLM (NTLMv1 or NTLMv2) where the authentication results in an elevated token and the logon originates from a different workstation than the target computer. This combination of factors can indicate lateral movement attempts, especially when an adversary has obtained NTLM hashes (e.g., via Pass-the-Hash or NTLM relay attacks) and is attempting to authenticate to other systems on the network. The rule excludes machine accounts and anonymous logons, as well as loopback authentications, to reduce noise.
This rule correlates a user logging in from a new ISP and immediately navigating to HR/Payroll URIs (specifically Workday or ADP) to modify direct deposit data. The detection logic joins Azure AD sign-in events with Cloud App Security events, filtering for interactive logins and page accesses to specific HR/Payroll URLs containing 'direct-deposit'. It also excludes known corporate IP addresses and requires the HR/Payroll access to occur within 30 minutes of the login.
Detects MFA fatigue attacks where a user receives more than 10 MFA push denials within a 10-minute window, followed immediately by a successful authentication from a different IP address. This behavior is indicative of an adversary bombarding a user with push notifications until they are approved, followed by account takeover.
This rule detects successful OAuth logins originating from IP addresses identified as residential proxies. This behavior can indicate an adversary attempting to bypass geo-blocking or other IP-based restrictions, potentially using stolen credentials (Valid Accounts) or after a successful phishing campaign (Spearphishing Link) to gain initial access or maintain persistence.
This rule detects successful OAuth sign-ins originating from a residential proxy IP address, correlated with a successful identity logon event for the same user. This pattern can indicate an adversary using residential proxies to bypass geo-restrictions or blend in with legitimate user traffic while attempting to access accounts via OAuth.
Detects stolen session token reuse to bypass MFA by correlating a successful SSO/VPN login from one IP with a subsequent successful login from a different IP using the same user agent context, or a user-agent change between sessions for the same user within a short window. Targets access broker technique where infostealer-harvested session cookies are replayed from different source IPs.
Detects stolen session token reuse to bypass MFA by correlating a successful SSO/VPN login from one IP with a subsequent successful login from a different IP using the same user agent context, or a user-agent change between sessions for the same user within a short window. Targets access broker technique where infostealer-harvested session cookies are replayed from different source IPs.
Detects a successful self-service password reset for a privileged or high-value account when the initiating context does not match an approved helpdesk workflow.
Detects successful non-interactive token acquisitions using specific Microsoft first-party application IDs known to bypass Entra Conditional Access Policies through Nested App Authentication (NAA/BroCI). The detection specifically targets sign-ins to the Microsoft Graph resource.
Detects a RedVDS login followed by commands modifying domain trusts or attempting Active Directory Certificate Services (AD CS) abuse within a 2-hour window. The rule specifically looks for 'Certify.exe' or 'nltest /domain_trusts' commands after a login from a predefined RedVDS IP range.
Detects a Google account completing an OAuth or MFA challenge and then generating a new session from a different client fingerprint (different source IP or user agent) within a 10-minute window. This behavior can indicate a session hijack or an adversary bypassing MFA.
Detects instances where a user successfully authenticates from a mobile device (Android or iPhone) that exhibits a geographic mismatch (geo_country vs registered_country), and subsequently performs a sensitive credential or MFA-related action (enrollment or reset) from a different device within one hour. This pattern is indicative of a potential session hijacking or credential compromise where an attacker attempts to establish persistence by enrolling their own MFA device.
This rule detects successful SSH authentications using the GSSAPI-with-MIC mechanism. This can indicate legitimate user logins or, in some cases, an adversary using valid credentials to access a system via SSH.
Detects NTLM-authenticated network logons (Logon Type 3) originating from loopback IP addresses (127.0.0.1, ::1, or 0.0.0.0). This behavior is often associated with NTLM relay attacks or credential reflection bypass techniques where an adversary forces a local service to authenticate to itself to gain unauthorized access.
Detects a suspicious pattern where a highly privileged on-premises synchronized user account signs into Azure Active Directory (Entra ID) and immediately performs sensitive administrative actions (role assignment or OAuth application consent grant) within a 30-minute window. This behavior is indicative of credential abuse by the Storm-2372 actor to escalate privileges within a tenant.
Page 60 of 80