Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
8,393 detections
Filters
Last updated
All Time
Detection languages
3,122
2,721
773
497
379
Contributors
1,502
1,474
1,085
844
510
Categories
2,689
1,317
905
813
744
Platforms
5,922
913
883
299
280
Products / Services
1,616
1,400
1,084
454
419
MITRE Techniques
18,116
15,636
12,583
8,393
6,223
CVEs
29
27
16
16
15
IDS Classtypes
97
50
21
14
8
IDS Protocols
98
93
9
1
A Build Work Zone role was added to or removed from a BTP role collection
Detects when a privileged SAP user's credentials are reset by an administrator and subsequently used to log in from the same IP address that the administrator previously used.
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 when a privileged SAP account modifies the master record of a different user within a specified timeframe.
Detects successful or failed logon activity by a privileged SAP account on a production system using SAP Security Audit logs.
Detects modifications to privileged SAP accounts' user master records or authorizations, indicating potential account manipulation or privilege abuse.
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 the modification of a user's master record via an administrative action within SAP, which may indicate unauthorized account manipulation or privilege escalation.
Detects a node/npm/npx process writing to a Unix shell startup file (.zshrc, .zprofile, .bashrc, .bash_profile) immediately after package install activity. STARDUST CHOLLIMA (DPRK-nexus) used stolen maintainer credentials to compromise the Axios npm package and deliver platform-specific "ZshBucket" malware, and separately injected a malicious dependency into 131 Mastra AI framework packages. Malicious postinstall scripts modifying shell profiles is a persistence mechanism consistent with this campaign's naming and delivery pattern.
Detects Play-style lateral movement via Group Policy: an executable (.exe/.dll) written to a SYSVOL/GPO path by the same non-machine account that modified a GPO in the same 30-minute window. Attackers use this to push ransomware or Cobalt Strike/SystemBC payloads domain-wide.
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 an Entra 'Add device' event within 2 minutes after a successful sign-in from an IP never seen for that user in the lookback window, and where the registration originates from that same new IP (rogue device persistence after token replay).
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 detects the creation of shim database files (.sdb) in default directories using the sdbinst.exe application. It leverages filesystem activity data from the Endpoint.Filesystem data model to identify file writes to the Windows\AppPatch\Custom directory. This activity is significant because shims can intercept and alter API calls, potentially allowing attackers to bypass security controls or execute malicious code. If confirmed malicious, this could lead to unauthorized code execution, privilege escalation, or persistent access within the environment.
This analytic detects the execution of the ConvertTo-AADIntBackdoor command via PowerShell Script Block Logging.
The ConvertTo-AADIntBackdoor command is part of the AADInternals toolkit, which is used primarily for security testing and administrative tasks in Azure Active Directory (Azure AD) environments.
This particular command is designed to create a "backdoor" in a federated Azure AD domain.
When executed, ConvertTo-AADIntBackdoor modifies the federation settings of a domain by adding or changing the federation configuration to allow an attacker to control the authentication process.
This manipulation enables the creation of security tokens that can impersonate any user within the Azure AD tenant.
Consequently, this allows an attacker to bypass Multi-Factor Authentication (MFA), escalate privileges, and maintain persistent access to the Azure AD environment.
The ConvertTo-AADIntBackdoor command is part of the AADInternals toolkit, which is used primarily for security testing and administrative tasks in Azure Active Directory (Azure AD) environments.
This particular command is designed to create a "backdoor" in a federated Azure AD domain.
When executed, ConvertTo-AADIntBackdoor modifies the federation settings of a domain by adding or changing the federation configuration to allow an attacker to control the authentication process.
This manipulation enables the creation of security tokens that can impersonate any user within the Azure AD tenant.
Consequently, this allows an attacker to bypass Multi-Factor Authentication (MFA), escalate privileges, and maintain persistent access to the Azure AD environment.
The following analytic identifies the creation or modification of Image File Execution Options (IFEO) registry keys, detected via EventCode 3000 in the Application channel. This detection leverages Windows Event Logs to monitor for process names added to IFEO under specific registry paths. This activity is significant as it can indicate attempts to set traps for process monitoring or debugging, often used by attackers for persistence or evasion. If confirmed malicious, this could allow an attacker to execute arbitrary code or manipulate process behavior, leading to potential system compromise.
The following analytic identifies a suspicious `explorer.exe` process with the `/root` command-line parameter. This detection leverages Endpoint Detection and Response (EDR) telemetry, focusing on process and command-line data. The presence of `/root` in `explorer.exe` is significant as it may indicate parent process spoofing, a technique used by malware to evade detection. If confirmed malicious, this activity could allow an attacker to operate undetected, potentially leading to unauthorized access, privilege escalation, or persistent threats within the environment.
The following analytic detects potential malicious activities involving PowerShell's task scheduling cmdlets. It leverages PowerShell Script Block Logging (EventCode 4104) to identify unusual or suspicious use of cmdlets like 'New-ScheduledTask' and 'Set-ScheduledTask'. This activity is significant as attackers often use these cmdlets for persistence and remote execution of malicious code. If confirmed malicious, this could allow attackers to maintain access, deliver additional payloads, or execute ransomware, leading to data theft or other severe impacts. Immediate investigation and mitigation are crucial to prevent further compromise.
The following analytic identifies modifications to the SafeBoot registry keys, specifically within the Minimal and Network paths. This detection leverages registry activity logs from endpoint data sources like Sysmon or EDR tools. Monitoring these keys is crucial as adversaries can use them to persist drivers or services in Safe Mode, with Network allowing network connections. If confirmed malicious, this activity could enable attackers to maintain persistence even in Safe Mode, potentially bypassing certain security measures and facilitating further malicious actions.
The following analytic identifies the creation of a new service on a remote endpoint using sc.exe. It leverages data from Endpoint Detection and Response (EDR) agents, specifically monitoring for EventCode 7045, which indicates a new service creation. This activity is significant as it may indicate lateral movement or remote code execution attempts by an attacker. If confirmed malicious, this could allow the attacker to establish persistence, escalate privileges, or execute arbitrary code on the remote system, potentially leading to further compromise of the network.
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.
Page 10 of 400