Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,122 detections
Filters
Last updated
All Time
Detection languages
1,062
796
474
242
137
Contributors
463
427
399
318
291
Categories
926
771
637
574
311
Platforms
2,112
365
219
214
142
Products / Services
487
482
389
167
150
MITRE Techniques
18,116
15,638
12,585
8,395
6,225
3,122
CVEs
12
12
8
8
5
IDS Classtypes
62
26
22
11
7
IDS Protocols
47
37
15
8
7
This rule detects patterns indicative of cryptomining malware execution, specifically targeting those distributed via impersonated PyPI packages. It looks for Python processes exhibiting characteristics such as: 1. Command lines containing keywords related to mining, cryptocurrency, hashing, and mining pools. 2. Python processes making suspicious network connections to stratum+tcp or mining pools. 3. Python processes engaging in resource-intensive operations like multiprocessing or threading, often utilizing all available CPU cores. 4. Python processes executing obfuscated code, potentially involving base64, zlib, or gzip decoding, combined with network requests. The rule triggers if any of these conditions are met, or if a combination of suspicious network activity and resource-intensive behavior, or obfuscated execution and resource-intensive behavior, is observed.
High AWS S3 Object Deletion Count
Cortex XDR
Detects when a single IP address or identity performs a high number of S3 object or bucket deletions within a short timeframe. This could indicate an attacker attempting to destroy data, evade detection, or disrupt services.
Detects ransom note creation associated with Yurei ransomware.
Detects specific User-Agent strings associated with the DDoSia malware, which is used by the NoName057(16) hacktivist group for DDoS attacks. The rule looks for two distinct User-Agent patterns in HTTP traffic.
This rule detects a specific sequence of commands often used by ransomware, particularly the '01flip' variant, to self-delete after execution. The sequence involves 'ping.exe' for a delay, 'fsutil.exe' to zero out file data, and 'cmd.exe' to delete files. The rule correlates these events within a short timeframe, initiated by the same process on a given device.
Detects the mass renaming or creation of files with the '.01flip' extension, which is characteristic of the 01flip ransomware. A high count of these files on a single host is a strong indicator of an active ransomware infection.
Detects the execution of the command to stop the vCenter remote management service (vpxa) on an ESXi host. This is a technique used by the RansomHouse MrAgent tool to inhibit system recovery and impair defenses before deploying the Mario encryptor.
Detects the renaming of VMware virtual machine related files to a new file ending with the '.emario' extension. This behavior is characteristic of the RansomHouse 'Mario' encryptor.
This rule detects the execution of known proxyware applications such as Infatica, Honeygain, and IPRoyal by looking for specific command-line arguments. Proxyware applications monetize unused internet bandwidth by routing traffic through the user's device, which can pose security and privacy risks.
Detects the mass creation of the 'RECOVER-YOUR-FILE.TXT' ransom note, a behavior characteristic of the 01flip ransomware. A high count of these notes on a single host is a strong indicator of compromise, suggesting that data has been encrypted for impact.
Detects the renaming of critical virtualization files by the RansomHouse 'Mario' encryptor, which appends an extension containing '.mario' (e.g., '.emario'). This activity is a strong indicator of a successful encryption event on an ESXi host.
Detects the ransom note file 'How To Restore Your Files.txt' created by the RansomHouse 'Mario' encryptor.
This rule detects 3 types of suspicious activities: first, the presence of files matching a list of known malicious SHA256 hashes associated with Sha1-Hulud; second, suspicious process behavior involving file deletion commands and third traffic towards potential C2.
This rule detects various activities associated with the Sha1-Hulud campaign, including the creation of malicious files (setup_bun.js, bun_environment.js) identified by their SHA256 hashes or filenames within .npm directories. It also identifies the execution of malicious preinstall scripts involving 'node' and 'setup_bun.js'. Furthermore, the rule looks for persistence mechanisms related to GitHub Actions, specifically the creation of 'discussion.yaml' within '.github/workflows' or 'run.sh'/'config.sh' within '/.dev-env/'. Finally, it detects destructive commands used as a fallback, targeting both Linux (using 'find', 'shred', 'xargs', 'delete') and Windows (using 'del', 'rd' on '%USERPROFILE%').
Detects host-based artifacts associated with AK47/X2ANYLOCK ransomware, such as the creation of specific ransom notes ('How to decrypt my data.txt', 'How to decrypt my data.log') or files being encrypted with the '.x2anylock' extension. This rule identifies both the creation of the ransom note and the encryption of files by monitoring file creation and renaming events.
Detects process execution patterns associated with the "Sha1-Hulud: The Second Coming" NPM supply chain attack. This includes the silent installation of the 'bun' runtime during an 'npm install' and a destructive file shredding command. The rule filters out legitimate manual installations by developers by checking the initiating parent process.
Adversaries may shutdown/reboot systems to interrupt access to, or aid in the destruction of, those systems.
Detects the use of fsutil.exe to delete the USN (Update Sequence Number) journal, a technique observed in the ZEROLOT wiper to inhibit system recovery.
Detects the ZEROLOT wiper, a component reportedly used by the Sandworm group. This rule identifies specific artifacts related to its disk wiping functionality.
Detects overwriting (effectively wiping/deleting) of a file.
Detects the potential abuse of the Linux Magic SysRq (System Request) key by adversaries with root or sufficient privileges
to silently manipulate or destabilize a system. By writing to /proc/sysrq-trigger, they can crash the system, kill processes,
or disrupt forensic analysis—all while bypassing standard logging. Though intended for recovery and debugging, SysRq can be
misused as a stealthy post-exploitation tool. It is controlled via /proc/sys/kernel/sysrq or permanently through /etc/sysctl.conf.
to silently manipulate or destabilize a system. By writing to /proc/sysrq-trigger, they can crash the system, kill processes,
or disrupt forensic analysis—all while bypassing standard logging. Though intended for recovery and debugging, SysRq can be
misused as a stealthy post-exploitation tool. It is controlled via /proc/sys/kernel/sysrq or permanently through /etc/sysctl.conf.
Page 93 of 149