Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,664 detections
Filters
Last updated
All Time
Detection languages
1,075
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,396
11,792
5,863
5,144
4,864
1,664
Platforms
1,089
590
440
252
122
Products / Services
1,128
476
189
125
116
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
Detects successful or failed logon attempts originating from IP addresses identified as associated with botnets, C2 infrastructure, or proxies by threat intelligence feeds. This indicates potential malicious activity or compromised accounts.
Detects MFA authentication success from one IP address followed immediately by a session access attempt from a different IP address. This pattern is characteristic of Adversary-in-the-Middle (AiTM) phishing attacks, such as those using EvilProxy, Evilginx2, or similar phishing-as-a-service (PhaaS) platforms, where an adversary proxies the authentication flow to capture session tokens.
This rule detects successful SSH login events utilizing public key authentication for the 'vmanage-admin' user. It aggregates login events by source IP, username, and host to identify patterns of access for this specific administrative account.
Detects potential Browser-in-the-Middle (AiTM) credential relay attacks where a user clicks a malicious phishing URL, followed shortly by a successful interactive sign-in from a different IP address and a previously unseen device.
Detects instances where a single authentication correlation ID is associated with multiple distinct IP addresses within a 10-minute window, followed by high-risk administrative or data-access actions within 30 minutes. This behavior is indicative of session hijacking or post-authentication account compromise, where an adversary uses stolen session tokens to perform unauthorized activities.
Detects successful Device Code authentication followed immediately by a new device registration, a tactic used to extend access via PRT generation.
Detects consecutive successful AWS ConsoleLogin events for the same user originating from distinct IP addresses within a 10-minute window. This behavior is indicative of a session-based attack such as Adversary-in-the-Middle (AiTM) where session cookies are intercepted and replayed, allowing an attacker to bypass traditional authentication or multi-factor authentication controls.
Detects a potential Conditional Access bypass, often associated with Storm-2372, where a device is registered and immediately followed by a PRT or deviceToken-authenticated sign-in to sensitive cloud applications within one hour. This behavior indicates the usage of non-TPM-attested 'phantom' devices to circumvent device-based security requirements.
Detects unauthorized changes to sensitive payroll information (such as bank accounts or direct deposit details) or suspicious inbox rule creations within Microsoft 365 or HR SaaS environments that occur immediately following anomalous authentication activity. The rule targets indicators of AiTM (Adversary-in-the-Middle) session hijacking, such as unusual user agents, unmanaged device usage, or potential token reuse.
Detects sign-ins by Global Administrators using a Temporary Access Pass (TAP) to the Azure Portal. This activity is indicative of potential credential abuse, especially in cross-tenant scenarios, as TAP can bypass MFA. The rule identifies instances where a Global Administrator role is assigned or where a user with 'globaladmin' in their UPN signs in with a TAP.
This rule detects potential automated credential stuffing attempts followed by successful authentication and subsequent access to sensitive/privileged APIs within Azure/Entra ID environments. It correlates multiple failed login attempts for service-oriented account names (e.g., svc, api, bot) with a successful login from the same user shortly thereafter, followed by privileged API operations (e.g., KeyVault secret access, user management) within a short time window.
This rule detects successful user sign-ins from anomalous IP addresses, indicative of an Adversary-in-the-Middle (AiTM) reverse proxy attack. It correlates successful logins with the receipt of a phishing email containing specific subject keywords ('Code of Conduct') within a two-hour window, suggesting that the login was a direct result of the phishing lure.
Detects successful NTLMv1 logon events (Event ID 4624) where the logon type is 3 (Network). NTLMv1 is a legacy and insecure authentication protocol. Its use in a modern environment, particularly for network logons, is often associated with pass-the-hash attacks or legacy compatibility issues that attackers may exploit.
Detects successful NTLMv1 logon events (Event ID 4624) where the logon type is 3 (Network). NTLMv1 is a legacy and insecure authentication protocol. Its use in a modern environment, particularly for network logons, is often associated with pass-the-hash attacks or legacy compatibility issues that attackers may exploit.
Detects potential Pass-the-Hash lateral movement where a single account uses NTLM authentication as a local administrator to access three or more distinct devices within a 30-minute window, a pattern often indicative of automated credential propagation.
Detects potential Adversary-in-the-Middle (AiTM) phishing activity by identifying successful user sign-ins from a new, historically unseen IP address occurring within 30 minutes of a legitimate sign-in from a known IP, indicating the potential replay of a stolen session or refresh token.
This rule detects successful sign-ins using OAuth from residential IP addresses. It joins `SigninLogs` with `IdentityLogonEvents` to correlate successful OAuth authentications with user logon events. The intent is to identify potentially suspicious access, possibly indicating credential abuse or unauthorized access attempts from non-corporate or unexpected locations.
This rule detects successful OAuth logins originating from IP addresses identified as residential proxies. This behavior can indicate an adversary attempting to bypass geo-restrictions or obscure their true location, potentially as part of a credential stuffing attack, account takeover, or to evade detection.
This rule detects potential Conditional Access bypass attempts where a Primary Refresh Token (PRT) is exchanged for an Azure Active Directory (AAD) Graph token. The detection specifically looks for successful sign-ins to 'Windows Azure Active Directory' or 'Microsoft Graph' resources from devices marked as 'compliant' but with 'Unknown' ownership or no prior device registration history in Audit Logs. This could indicate an adversary using a compromised PRT on an unregistered or untrusted device to gain access to resources that should be protected by Conditional Access policies.
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.
Page 59 of 80