Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
985 detections
Filters
Last updated
All Time
Detection languages
640
105
82
64
34
Contributors
242
226
216
58
46
Categories
20,439
11,829
5,873
5,151
4,864
985
Platforms
485
405
224
192
62
Products / Services
416
384
182
109
81
MITRE Techniques
498
497
264
235
234
CVEs
4
4
4
3
3
IDS Classtypes
1
Detects repeated OAuth device authorization ('device code') grant flow authentication events targeting the same user within a short window, which is indicative of an active device code phishing attempt.
Detects a successful device-code sign-in whose session is replayed successfully within 60 minutes from a different IP and ASN. Only successful replays count (interrupt codes removed) and Microsoft first-party ASN egress is excluded.
Detects users authenticating to SAP via Dialog Logons from IP addresses that are outside of approved network ranges and RFC1918 internal networks, potentially indicating unauthorized or external access.
Detects successful or failed logon activity by a privileged SAP account on a production system using SAP Security Audit logs.
Detects multiple distinct SAP users authenticating successfully from a single source IP address within a short time window (30 minutes), potentially indicating compromised credentials or shared access anomalies.
Detects a successful device-code sign-in followed within 60 minutes by non-interactive replay from a different IP AND a persistence action (inbox rule, app consent, device add) from a non-original IP. Persistence is now mandatory (inner join) instead of optional, and the retired AADSignInEventsBeta table is replaced by EntraIdSignInEvents.
Detects a successful device-code sign-in whose session is replayed successfully within 60 minutes from a different IP and ASN. Only successful replays count (interrupt codes removed) and Microsoft first-party ASN egress is excluded.
This rule monitors Entra ID Sign-in logs for authentication events flagged by risk detections related to anonymizing infrastructure, such as VPNs, TOR exit nodes, or proxies. It identifies successful logins and aggregate sign-in volume from these IP addresses, flagging successful logins as critical due to the potential for valid account abuse through multi-hop proxy chains.
This rule monitors Entra ID Sign-in logs for authentication events flagged by risk detections related to anonymizing infrastructure, such as VPNs, TOR exit nodes, or proxies. It identifies successful logins and aggregate sign-in volume from these IP addresses, flagging successful logins as critical due to the potential for valid account abuse through multi-hop proxy chains.
Builds a per-account baseline of the devices that each enabled service account has made a successful network logon to over the previous 30 days, then alerts when one makes a successful network logon to a device outside that baseline within the latest window.
Service accounts are identified from IdentityInfo using each account’s most recent recorded type and enabled status, and are matched to logon events by their on-premises SID, so local accounts or accounts in other domains that share the same name are not mistaken for them. Accounts with no logon history in the baseline period are still evaluated, so a dormant service account that suddenly begins making network logons will alert on every device it reaches.
Service accounts tend to touch a small, fixed set of hosts, so a per-entity first-seen check is a strong lateral movement signal with less noise than the same logic applied to users.
Each result is enriched with the number of times the destination device’s sensor reporting restarted during the alert window, along with the times of those restarts in UTC, as restarts close to the new logons often indicate maintenance activity such as patching, although they should prompt a check to confirm rather than closure of the alert.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and the alert window covers the last 25 hours so that a slightly delayed run does not leave a gap.
The baseline and alert windows are separated by ingestion time rather than event time, so events that arrive late are still evaluated.
Service accounts are identified from IdentityInfo using each account’s most recent recorded type and enabled status, and are matched to logon events by their on-premises SID, so local accounts or accounts in other domains that share the same name are not mistaken for them. Accounts with no logon history in the baseline period are still evaluated, so a dormant service account that suddenly begins making network logons will alert on every device it reaches.
Service accounts tend to touch a small, fixed set of hosts, so a per-entity first-seen check is a strong lateral movement signal with less noise than the same logic applied to users.
Each result is enriched with the number of times the destination device’s sensor reporting restarted during the alert window, along with the times of those restarts in UTC, as restarts close to the new logons often indicate maintenance activity such as patching, although they should prompt a check to confirm rather than closure of the alert.
The rule runs every 24 hours, as this is the only Defender custom detection frequency with a 30-day lookback, and the alert window covers the last 25 hours so that a slightly delayed run does not leave a gap.
The baseline and alert windows are separated by ingestion time rather than event time, so events that arrive late are still evaluated.
Detects a successful device-code sign-in whose session is replayed successfully within 60 minutes from a different IP and ASN. Only successful replays count (interrupt codes removed) and Microsoft first-party ASN egress is excluded.
Detects a successful device-code sign-in whose session is replayed successfully within 60 minutes from a different IP and ASN. Only successful replays count (interrupt codes removed) and Microsoft first-party ASN egress is excluded.
The following analytic identifies a local successful authentication event on a Windows endpoint using the Kerberos package.
It detects EventCode 4624 with LogonType 3 and source address 127.0.0.1, indicating a login to the built-in local Administrator account.
This activity is significant as it may suggest a Kerberos relay attack, a method attackers use to escalate privileges.
If confirmed malicious, this could allow an attacker to gain unauthorized access to sensitive systems, execute arbitrary code, or create new accounts in Active Directory, leading to potential system compromise.
It detects EventCode 4624 with LogonType 3 and source address 127.0.0.1, indicating a login to the built-in local Administrator account.
This activity is significant as it may suggest a Kerberos relay attack, a method attackers use to escalate privileges.
If confirmed malicious, this could allow an attacker to gain unauthorized access to sensitive systems, execute arbitrary code, or create new accounts in Active Directory, leading to potential system compromise.
Detects anomalous account behavior where a single user account authenticates to three or more distinct applications within a 60-minute window while originating from at least two different IP addresses. This pattern is indicative of a successful account compromise followed by rapid reconnaissance or data exfiltration across multiple cloud services.
This rule identifies successful sign-in events using the Azure CLI application where multi-factor authentication (MFA) was not enforced. This is a potential indicator of a misconfiguration where sensitive cloud management interfaces are accessible via single-factor authentication, or a sign of an adversary attempting to leverage a less secure authentication pathway.
This rule identifies successful sign-in events using the Azure CLI application where multi-factor authentication (MFA) was not enforced. This is a potential indicator of a misconfiguration where sensitive cloud management interfaces are accessible via single-factor authentication, or a sign of an adversary attempting to leverage a less secure authentication pathway.
The following analytic identifies potential Kerberos ticket forging attacks, specifically the Diamond Ticket attack. This is detected when a user logs into a host and the GroupMembership field in event 4627 indicates a privileged group (e.g., Domain Admins), but the user does not actually belong to that group in the directory service. The detection leverages Windows Security Event Log 4627, which logs account logon events. The analytic cross-references the GroupMembership field from the event against a pre-populated lookup of actual group memberships. Its crucial to note that the accuracy and effectiveness of this detection heavily rely on the users diligence in populating and regularly updating this lookup table. Any discrepancies between the events GroupMembership and the lookup indicate potential ticket forging. Kerberos ticket forging, especially the Diamond Ticket attack, allows attackers to impersonate any user and potentially gain unauthorized access to resources. By forging a ticket that indicates membership in a privileged group, an attacker can bypass security controls and gain elevated privileges. Detecting such discrepancies in group memberships during logon events can be a strong indicator of this attack in progress, making it crucial for security teams to monitor and investigate. If validated as a true positive, this indicates that an attacker has successfully forged a Kerberos ticket and may have gained unauthorized access to critical resources, potentially with elevated privileges.
This rule monitors Linux system authentication logs to identify potential unauthorized access attempts. It triggers when a single source IP initiates a high volume of failed SSH login attempts (brute force) or when a single user account is targeted by multiple distinct source IPs within a short time window (password spraying).
Detects potential misuse of SSH credentials by identifying successful SSH logins from source IP addresses that have not been observed in the previous 14 days, or successful SSH logins occurring within one hour of an authorized_keys file modification on the same host. This combination of behaviors is indicative of an adversary establishing or using persistence via SSH key manipulation.
Detects anomalous authentication patterns associated with AI agent or service account credentials. The rule monitors for logins originating from multiple disparate network locations, ASNs, or countries within a 15-minute window, and detects unexpected MFA challenges directed at accounts that typically function as automated, headless identities.
Detects potential session cookie replay attacks by identifying sign-in events using SSO or session tokens from different IP addresses, geographic locations, or devices compared to an established user baseline, without a corresponding fresh MFA challenge in the same timeframe. This behavior is indicative of unauthorized access to an already-authenticated session.
Page 3 of 47