Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
8,407 detections
Filters
Last updated
All Time
Detection languages
3,122
2,729
773
499
379
Contributors
1,502
1,474
1,085
844
510
Categories
2,695
1,319
905
813
749
Platforms
5,933
913
885
299
280
Products / Services
1,617
1,401
1,090
454
419
MITRE Techniques
18,127
15,648
12,596
8,407
6,231
CVEs
29
27
16
16
15
IDS Classtypes
97
50
21
14
8
IDS Protocols
98
93
9
1
The following analytic detects modifications to the registry aimed at bypassing the User Account Control (UAC) feature in Windows. It identifies changes to the .NET COR_PROFILER_PATH registry key, which can be exploited to load a malicious DLL via mmc.exe. This detection leverages data from the Endpoint.Registry datamodel, focusing on specific registry paths and values. Monitoring this activity is crucial as it can indicate an attempt to escalate privileges or persist within the environment. If confirmed malicious, this could allow an attacker to execute arbitrary code with elevated privileges, compromising system integrity.
The following analytic detects the spawning of cmd or PowerShell processes by the wermgr.exe process. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on process telemetry, including parent-child process relationships and command-line executions. This behavior is significant as it is commonly associated with code injection techniques used by malware like TrickBot to execute shellcode or malicious DLL modules. If confirmed malicious, this activity could allow attackers to execute arbitrary code, escalate privileges, or maintain persistence within the environment, posing a severe threat to system security.
This analytic detects attempts to modify or add a Component Object Model (COM) entry to the InProcServer32 path within the registry using PowerShell. It leverages PowerShell ScriptBlock Logging (EventCode 4104) to identify suspicious script blocks that target the InProcServer32 registry path. This activity is significant because modifying COM objects can be used for persistence or privilege escalation by attackers. If confirmed malicious, this could allow an attacker to execute arbitrary code or maintain persistent access to the compromised system, posing a severe security risk.
This analytic detects the creation of a remote thread by rundll32.exe into another process, leveraging Sysmon EventCode 8 logs. This activity is a common technique used by malware, such as IcedID, to execute malicious code within legitimate processes, aiding in defense evasion and data theft. If confirmed malicious, this behavior could allow an attacker to execute arbitrary code, escalate privileges, and exfiltrate sensitive information from the compromised host.
The analytic detects the execution of a Windows Scheduled Task on demand via the shell or command line. It leverages process-related data, including process name, parent process, and command-line executions, sourced from endpoint logs. The detection focuses on 'schtasks.exe' with an associated 'run' command. This activity is significant as adversaries often use it to force the execution of their created Scheduled Tasks for persistent access or lateral movement within a compromised machine. If confirmed malicious, this could allow attackers to maintain persistence or move laterally within the network, potentially leading to further compromise.
The analytic detects the Microsoft Software Licensing User Interface Tool (`slui.exe`) spawning a child process. This behavior is identified using Endpoint Detection and Response (EDR) telemetry, focusing on process creation events where `slui.exe` is the parent process. This activity is significant because `slui.exe` should not typically spawn child processes, and doing so may indicate a UAC bypass attempt, leading to elevated privileges. If confirmed malicious, an attacker could leverage this to execute code with elevated privileges, potentially compromising the system's security and gaining unauthorized access.
The analytic detects `winhlp32.exe` spawning a child process that loads a file from `appdata`, `programdata`, or `temp` directories. This activity is significant because `winhlp32.exe` has known vulnerabilities and can be exploited to execute malicious code. If confirmed malicious, an attacker could use this technique to execute arbitrary scripts, escalate privileges, or maintain persistence within the environment. Analysts should review parallel processes, module loads, and file modifications for further suspicious behavior.
WinPEAS is a widely used privilege escalation and discovery tool. This rule detects the execution of winPEAS by monitoring process creation events for specific filenames and command-line arguments. It also looks for command-line options related to information gathering (applications, browser, events, files, processes, services, windows credentials) and attempts to download the tool from its GitHub repository. The rule aims to identify potential privilege escalation attempts and extensive system discovery activities by adversaries.
This detection rule identifies the execution of WinPEAS (Windows Privilege Escalation Awesome Script), a post-exploitation reconnaissance tool used to discover privilege escalation paths on Windows systems. WinPEAS performs a wide range of local enumeration checks, including service misconfigurations, permission issues, token privileges, and more. Its usage is commonly observed during red team assessments and by adversaries seeking to elevate privileges after gaining initial access. The rule looks for common WinPEAS executable names, specific command-line arguments used by WinPEAS for various enumeration tasks, and patterns indicative of downloading WinPEAS PowerShell scripts from GitHub.
This detection rule identifies the creation of a Windows service with a suspicious or known malicious name, as logged by Windows Event ID 7045 (`A service was installed in the system`). Threat actors often create services to achieve persistence, lateral movement, remote execution, or privilege escalation. Detection of such activity is critical for identifying early-stage post-compromise behavior.
Detects the addition of a new "Allow" firewall rule by the WMI process (WmiPrvSE.EXE). This can occur if an attacker leverages PowerShell cmdlets such as "New-NetFirewallRule", or directly uses WMI CIM classes such as "MSFT_NetFirewallRule". This activity is often associated with defense evasion tactics to allow adversary communications or lateral movement.
This rule detects attempts to gain 'PROCESS_ALL_ACCESS' rights to specific, commonly used Windows processes such as 'calc.exe', 'notepad.exe', and 'mspaint.exe'. Granting 'PROCESS_ALL_ACCESS' provides the requesting process with all possible access rights to the target process, which can be abused by malicious software for process injection, privilege escalation, or defense evasion.
Detects when an attacker attempts to disable User Account Control (UAC) notifications by modifying the "UACDisableNotify" registry value. UAC is a critical Windows security feature that prompts users for permission or an administrator password before allowing actions that could affect system operation or change settings. Setting "UACDisableNotify" to 1 suppresses these UAC prompts, which can be leveraged by attackers for privilege escalation or defense evasion.
Detects when an attacker tries to change User Account Control (UAC) elevation request destination via the "PromptOnSecureDesktop" value. The "PromptOnSecureDesktop" setting specifically determines whether UAC prompts are displayed on the secure desktop. The secure desktop is a separate desktop environment that's isolated from other processes running on the system. It's designed to prevent malicious software from intercepting or tampering with UAC prompts. When "PromptOnSecureDesktop" is set to 0, UAC prompts are displayed on the user's current desktop instead of the secure desktop. This reduces the level of security because it potentially exposes the prompts to manipulation by malicious software.
WinPEAS is a script that search for possible paths to escalate privileges on Windows hosts. The checks are explained on book.hacktricks.xyz
Detects when a user attaches a Lambda layer to an existing AWS Lambda function. A malicious Lambda layer could execute arbitrary code in the context of the function's IAM role, potentially granting an adversary access to resources the function has access to. This activity could indicate privilege escalation or unauthorized modification of serverless functions.
Detects when a shell program such as the Windows command prompt or PowerShell is launched with system privileges. This rule helps identify potential suspicious processes that have escalated privileges.
Detects when a shell program such as the Windows command prompt or PowerShell is launched with system privileges from an uncommon parent location. This behavior can indicate privilege escalation or defense evasion by an attacker.
Detects when the Console Window Host (conhost.exe) process is spawned by an uncommon parent process, which could be indicative of potential code injection activity. The rule specifically looks for conhost.exe being spawned by processes other than a predefined list of common and legitimate parents, while also filtering out specific command-line patterns for svchost.exe and Dropbox to reduce false positives.
This rule detects login activity by Azure AD administrators to Microsoft cloud applications that are not part of a predefined list of common first-party applications. The rule specifically looks for successful logins where the application ID is not in the 'first_party_ms_cloud_apps' list and the user ID is present in the 'entra_id_admin_watchlist'. This helps identify potentially unusual or unauthorized access by administrators to less common or custom applications, which could indicate compromise or policy violation.
This rule detects Azure AD login activity to applications that are not part of a predefined list of first-party Microsoft Cloud Apps. This could indicate an attempt to access an unauthorized or unusual application within the Azure AD environment, potentially by a compromised account or an insider threat. The rule specifically excludes the 'On-Premises Directory Synchronization Service Account' to reduce false positives related to ADFS synchronization.
Page 378 of 401