Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
7,277 detections
Filters
Last updated
All Time
Detection languages
3,349
1,086
505
478
472
Contributors
1,824
1,622
874
505
300
Categories
3,035
2,546
1,076
1,051
932
Platforms
39,971
7,277
6,539
3,868
3,652
Products / Services
1,332
1,114
993
658
494
MITRE Techniques
2,274
1,337
1,319
905
886
CVEs
66
65
33
32
28
IDS Classtypes
81
80
56
27
10
IDS Protocols
149
98
6
5
4
Detects processes attempting to enumerate common CI/CD environment variables, a technique observed in the SleeperGem supply chain attack used for sandbox evasion and environment awareness to determine if the malware is running in a CI/CD build environment.
Detects attempts to perform error-based SQL injection against WordPress instances associated with the wp2shell exploit chain. The rule monitors for the use of MySQL functions EXTRACTVALUE or UPDATEXML within query parameters that are typically targeted by the exploit (author_exclude, author__not_in) or when interacting with the batch REST endpoint.
Detects the wp2shell post-exploitation cleanup pattern where a shell spawned by a web server process determines its current working directory, matches it against a wp-content/plugins path using the specific `case "$d" in */wp-content/plugins/*) cd / && rm -rf "$d";; esac` one-liner shape, and recursively deletes that directory to remove the deployed web shell plugin. This is tightened to require the exact case-statement/one-liner construction executed by a shell that is a child of a web server process, rather than any generic recursive delete under wp-content/plugins, which would also fire on legitimate WordPress plugin uninstall hooks that remove their own plugin directory. Absence of the plugin directory afterward should not be treated as evidence the host is clean.
Detects creation of PHP web shell files or plugin directories under WordPress wp-content/plugins using the wp2shell_<hex> naming convention, associated with the wp2shell WordPress Core RCE exploitation chain.
Detects a rapid sequence of blind boolean SQL injection probes against the author_exclude parameter using ASCII/SUBSTRING syntax and the X-WP-Total header oracle (CVE-2026-60137).
Detects host reconnaissance commands (e.g., pip freeze, id, hostname -I) spawned by processes whose command line references the malicious 'mrmustard' Python package. This links discovery activity directly to the context of the supply chain compromise.
Detects creation or modification of a shell profile (.bashrc/.zshrc/etc.) containing the exact 'tensorflow hardware compatibility check' marker used by the mrmustard stealer to disguise its persistence hook.
Detects attempts to exploit the WordPress wp2shell vulnerability (CVE-2026-63030/CVE-2026-60137) by correlating the identification of a vulnerable WordPress version (6.9.0-6.9.4 or 7.0.0-7.0.1) via response banners with anomalous Batch REST API requests utilizing the 'author__not_in' parameter.
Detects web server processes (Apache, Nginx, PHP-FPM) spawning a system shell to execute compound commands containing discovery utilities (like id, whoami, hostname, uname, or find) within a 'wp-content/plugins' directory. This behavior is indicative of post-exploitation activity following a remote code execution vulnerability, such as those associated with the wp2shell attack pattern.
Detects a POST to the WordPress REST API batch endpoint whose request body embeds a nested /wp/v2/users call granting the administrator role, consistent with the wp2shell exploit chain where a forged customize_changeset/parse_request replay temporarily assumes an existing admin's identity to pass current_user_can('create_users') and create a new administrator account without any preceding authenticated login. To reduce false positives from legitimate onboarding of administrator accounts, this rule now requires either the absence of an authenticated WordPress session cookie on the request, or a newly created username matching the randomized/generated wp2shell naming pattern (wp2_*, w2s_*).
Detects discovery and SUID/SGID enumeration commands (whoami, hostname, id, uname, cat /etc/passwd, find -perm) executed by a shell spawned from a WordPress plugins directory by a web server process.
This rule detects potentially unauthorized content injection within Redis or Memcached application logs. It monitors for specific keywords indicating WordPress post data ('WP_Post') being processed by these caching services, which is often an indicator of object injection or application-level exploitation attempts aimed at manipulating application data.
Detects a WordPress admin plugin ZIP upload to wp-admin/update.php?action=upload-plugin only when correlated with high-risk context: the observed wp2shell_ plugin naming convention, evidence of a just-created/unfamiliar administrator account (wp-admin/user-new.php activity in the same capture), or the upload occurring immediately after REST API batch-route/SQLi anomalies (wp-json/batch/v1, author__not_in) tied to CVE-2026-63030 and CVE-2026-60137. Routine plugin uploads by established administrators without these correlating indicators are excluded.
Detects ChonkyChicken's monitor_list enumeration chained with a screen_start command in the same C2 session.
Detects potential exploitation attempts targeting WordPress sites, specifically identifying unauthenticated REST API batch requests that attempt to forge posts with post_status 'parse' and post_type 'request' while including self-referential post_parent cycles. This pattern is associated with recent vulnerabilities enabling remote code execution.
Detects web server processes (Apache, Nginx, PHP-FPM) spawning a system shell to execute compound commands containing discovery utilities (like id, whoami, hostname, uname, or find) within a 'wp-content/plugins' directory. This behavior is indicative of post-exploitation activity following a remote code execution vulnerability, such as those associated with the wp2shell attack pattern.
Detects web server processes (Apache, Nginx, PHP-FPM) spawning a system shell to execute compound commands containing discovery utilities (like id, whoami, hostname, uname, or find) within a 'wp-content/plugins' directory. This behavior is indicative of post-exploitation activity following a remote code execution vulnerability, such as those associated with the wp2shell attack pattern.
Detects attempts to perform error-based SQL injection against WordPress instances associated with the wp2shell exploit chain. The rule monitors for the use of MySQL functions EXTRACTVALUE or UPDATEXML within query parameters that are typically targeted by the exploit (author_exclude, author__not_in) or when interacting with the batch REST endpoint.
Detects the wp2shell post-exploitation cleanup pattern where a shell spawned by a web server process determines its current working directory, matches it against a wp-content/plugins path using the specific `case "$d" in */wp-content/plugins/*) cd / && rm -rf "$d";; esac` one-liner shape, and recursively deletes that directory to remove the deployed web shell plugin. This is tightened to require the exact case-statement/one-liner construction executed by a shell that is a child of a web server process, rather than any generic recursive delete under wp-content/plugins, which would also fire on legitimate WordPress plugin uninstall hooks that remove their own plugin directory. Absence of the plugin directory afterward should not be treated as evidence the host is clean.
Detects a WordPress-context web server process spawning a non-shell interpreter or downloader (curl|bash, python -c, wget/curl via sh -c) to retrieve second-stage tooling post-exploitation.
Detects a POST to the WordPress REST API batch endpoint whose request body embeds a nested /wp/v2/users call granting the administrator role, consistent with the wp2shell exploit chain where a forged customize_changeset/parse_request replay temporarily assumes an existing admin's identity to pass current_user_can('create_users') and create a new administrator account without any preceding authenticated login. To reduce false positives from legitimate onboarding of administrator accounts, this rule now requires either the absence of an authenticated WordPress session cookie on the request, or a newly created username matching the randomized/generated wp2shell naming pattern (wp2_*, w2s_*).
Page 155 of 347