Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,235 detections
Filters
Last updated
All Time
Detection languages
734
214
105
78
51
Contributors
206
187
159
111
90
Categories
396
296
264
260
247
Platforms
492
314
281
204
110
Products / Services
379
234
152
109
106
MITRE Techniques
18,123
15,639
12,580
8,394
6,215
1,235
CVEs
9
9
4
4
4
IDS Classtypes
11
6
4
2
1
IDS Protocols
10
5
3
Lists accounts that still sign in successfully with Authenticated SMTP over the last 30 days. Microsoft plans to disable Basic auth for SMTP AUTH by default for existing tenants at the end of December 2026.
Rows come from SigninLogs and AADNonInteractiveUserSignInLogs, grouped per account with source IP count, apps and first and last seen.
Triage: Find the owner of each account, then move the sender to OAuth or a mail relay before the change. Inventory query, not an alert.
Limitations: Covers only sign-ins that reach the logs. Cross check with the Exchange admin center SMTP AUTH Clients Submission Report, which keeps 90 days.
Rows come from SigninLogs and AADNonInteractiveUserSignInLogs, grouped per account with source IP count, apps and first and last seen.
Triage: Find the owner of each account, then move the sender to OAuth or a mail relay before the change. Inventory query, not an alert.
Limitations: Covers only sign-ins that reach the logs. Cross check with the Exchange admin center SMTP AUTH Clients Submission Report, which keeps 90 days.
This rule detects when an SAP user generates audit records exceeding a configured hourly threshold (200 for high severity or 4000 for medium severity events) on their system. This behavior may indicate automated scanning, mass data extraction, or anomalous user activity within SAP environments.
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 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.
Detects sign-in activity originating from a known suspicious VPN/proxy IP range targeting critical Microsoft 365 applications. The rule specifically monitors for instances where multi-factor authentication (MFA) enforcement appears to be absent or failed, suggesting a potential account compromise and subsequent data access attempt via a proxy/VPN.
Detects Microsoft Entra ID (formerly Azure AD) sign-in attempts that use the specific, hardcoded User-Agent string associated with the TeamFiltration tool. This tool is frequently used for mass credential testing against Microsoft 365 environments. The detection looks for a suspicious and outdated combination of Teams, Electron, and Chrome versions that would not be present in legitimate, modern Microsoft Teams client traffic.
This detection identifies potentially suspicious usage of sqlcmd.exe, focusing on command patterns that may indicate data exfiltration, reconnaissance, or malicious database operations. The detection looks for both short-form (-X) and long-form (--flag) suspicious parameter combinations, which have been observed in APT campaigns targeting high-value organizations. For example, threat actors like CL-STA-0048 have been known to abuse sqlcmd.exe for data theft and exfiltration from compromised MSSQL servers. The detection monitors for suspicious authentication attempts, output redirection, and potentially malicious query patterns that could indicate unauthorized database access or data theft.
Okta flagged a password as present in a known breach corpus and still issued a session
for the same account within the same hour. Indicates the tenant's sign-on policy is not
enforcing the breached-credential signal and the account is likely under attacker control.
for the same account within the same hour. Indicates the tenant's sign-on policy is not
enforcing the breached-credential signal and the account is likely under attacker control.
The following analytic detects cloud provisioning activities originating from previously unseen countries. It leverages cloud infrastructure logs and compares the geographic location of the source IP address against a baseline of known locations. This activity is significant as it may indicate unauthorized access or potential compromise of cloud resources. If confirmed malicious, an attacker could gain control over cloud assets, leading to data breaches, service disruptions, or further infiltration into the network.
Detects network exploitation attempts targeting Fortinet FortiOS and FortiProxy vulnerabilities (CVE-2024-55591, CVE-2025-24472) involving authentication bypass via HTTP header manipulation (Forwarded, X-Forwarded-For) and unauthorized access to the /jsconsole endpoint.
Detects instances where an identity associated with AI or automated agents (service accounts, service principals, bots, or assistants) is assigned to highly privileged administrative roles or security groups in the directory. This behavior potentially indicates an attempt to escalate privileges using a compromised or improperly configured agent identity.
Detects a suspicious pattern where a user authenticates to a remote access portal (like Citrix or VPN) without multi-factor authentication (MFA) or with an existing risk flag, followed by a surge in file activity (creation, modification, or renaming of >500 files or >200 distinct files) on the same account within a 24-hour window, potentially indicating compromised credential usage for staging data for exfiltration or ransomware.
The following analytic detects cloud API calls executed by user roles that have not previously run these commands. It leverages the Change data model in Splunk to identify commands executed by users with the user_type of AssumedRole and a status of success. This activity is significant because new commands from different user roles can indicate potential malicious activity or unauthorized actions. If confirmed malicious, this behavior could lead to unauthorized access, data breaches, or other damaging outcomes by exploiting new or unmonitored commands within the cloud environment.
Detects anomalous AWS activity combining bulk secret retrieval from AWS Secrets Manager using the BatchGetSecretValue API with subsequent authentication failures or validation errors in AWS STS. This behavior is indicative of automated credential harvesting pipelines or agentic frameworks rapidly enumerating and testing stolen credentials.
Page 4 of 59