Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
733 detections
Filters
Last updated
All Time
Detection languages
362
124
60
58
35
Contributors
222
123
75
46
32
Categories
334
253
143
139
101
Platforms
525
383
290
80
34
Products / Services
161
158
114
72
47
MITRE Techniques
18,123
15,639
12,580
8,394
6,215
733
CVEs
4
3
3
2
2
IDS Classtypes
17
2
1
1
IDS Protocols
15
2
2
1
Detects the execution of the specific Linux payload path '/tmp/ld.py', commonly executed via python3 in the background by the dropper associated with the Axios npm supply chain attack.
Detects file creation, modification, or execution events involving the path '/Library/Caches/com.apple.act.mond', which is the hardcoded drop location for the macOS C++ RAT deployed by the Axios supply chain attack.
Detects processes referencing confirmed TeamPCP C2 infrastructure or known malicious artifacts from the Trivy supply chain compromise. This includes specific C2 domains/IPs, temporary runner files, and a specific tarball name. It also looks for `entrypoint.sh` executing `grep` for environment variables or SSH-related strings, which could indicate credential access attempts.
Detects `curl` commands performing `POST` requests with `--data-binary` that are spawned from a process whose command line contains "trivy-action". This behavior is indicative of potential data exfiltration in the context of a compromised Trivy supply chain.
Detects a high volume of 'git push --force' events specifically targeting tags from a single user or to a single repository within a short timeframe.
This is a strong indicator of a tag poisoning campaign, similar to the one used in the supply chain attack against the 'aquasecurity/trivy-action' repository where 75 tags were force-pushed to point to malicious code.
This is a strong indicator of a tag poisoning campaign, similar to the one used in the supply chain attack against the 'aquasecurity/trivy-action' repository where 75 tags were force-pushed to point to malicious code.
Detects a 'git push --force' event in GitHub audit logs. A force push overwrites the remote repository's history with the local history, which is a potentially destructive action.
This technique was notably used in the supply chain attack against the 'aquasecurity/trivy-action' repository, where attackers force-pushed malicious versions to existing version tags.
This technique was notably used in the supply chain attack against the 'aquasecurity/trivy-action' repository, where attackers force-pushed malicious versions to existing version tags.
This rule detects the execution of specific malicious JavaScript files (`install.js` or `version.js`) associated with the StegaBin campaign, launched by the Node.js runtime. The detection focuses on the exact file paths identified in the campaign to minimize false positives, as these files are part of a harmful developer package designed to hide its next moves behind normal-looking setup work. Successful detection indicates the initial stage of a supply chain attack, potentially leading to secret theft, remote control, or further payload downloads.
This rule set detects components of the StegaBin supply-chain attack targeting npm packages. The first rule, 'stegabin_npm_loader', identifies malicious JavaScript loaders that utilize Pastebin for steganography and Vercel API paths for command and control. It looks for specific strings indicating Pastebin usage, Vercel API endpoints, and unique markers related to the steganographic decoding or payload. The second rule, 'StegaBin_VSCode_Tasks_Persistence', focuses on persistence mechanisms within VSCode's tasks.json files. It detects configurations that automatically execute malicious code upon folder opening, specifically looking for the 'runOn': 'folderOpen' property and references to the 'ext-checkdin.vercel.app' domain and associated API paths. Together, these rules aim to identify both the initial loader and the persistence mechanism used by the StegaBin campaign.
This rule detects the execution of specific Node.js scripts associated with the StegaBin package campaign. It looks for 'node.exe' or 'node' processes executing command lines containing 'scripts/test/install.js' or 'vendor/scrypt-js/version.js'. The intent is to identify the initial phase of a malicious package installation chain, which could lead to further compromise.
Detects the use of curl.exe where the User-Agent string contains a URL pointing to temp.sh. This specific TTP was observed in the Notepad++ supply chain attack (Chrysalis infection chain) to exfiltrate system information and signal the uploaded file's location to the C2 server.
Detects legitimate executables, known to be abused in the Notepad++ supply chain attack, running from user AppData directories. This behavior is highly indicative of DLL side-loading.
Detects the execution of `node` running scripts from a `vendor` directory during an `npm install` lifecycle. This behavior was observed in the StegaBin campaign where malicious npm packages used an install hook to execute a loader from 'vendor/scrypt-js/version.js'.
Detects the execution of the Lua interpreter with a script that has a .ini extension or the known malicious name 'alien.ini' from the Notepad++ supply chain attack. This TTP was used to load and execute shellcode via the Lua Alien FFI library.
Detects an npm installation process (node.exe) spawning a shell or network utility to download a secondary payload from a Vercel-hosted domain. This TTP was observed in the StegaBin campaign where malicious packages used install scripts to fetch next-stage malware.
Detects Node.js package managers (npm, yarn, pnpm) spawning suspicious child processes like network utilities or shells during the installation of a package. This TTP is abused by malicious packages like 'ambar-src' which use 'preinstall' lifecycle scripts to download and execute secondary payloads.
Detects creation or modification of repository controlled Claude Code project configuration files (.claude/settings.json or .mcp.json) which were abused for code execution and token exfiltration.
This rule helps identify suspicious repository files that may try to run code automatically when a developer opens a project in an editor or when a build starts. It searches for the exact wording used by the editor to auto run tasks when a folder is opened, and it also looks for a set of web addresses published in public reporting that were used to deliver additional code. A match does not always mean the repository is malicious, but it does mean the file deserves careful review before it is executed on a developer machine. If you see a hit, confirm the repository source, check for unexpected scripts or obfuscated code, and review recent network traffic for connections to the listed staging sites. If the repository is not clearly trusted, isolate the environment, remove the project from production developer workstations, and rotate any secrets that may have been available. This rule is meant to provide a clear and understandable safety check for teams that regularly clone and run new code.
Detects instances where an npm or node process spawns a shell, which in turn executes a command-line networking utility like curl or wget. This behavior is indicative of a malicious pre/post-install script used in supply chain attacks, such as the one seen with the 'ambar-src' package.
Matches marker filenames and propagation strings described in the report.
Detection attempts to modify package manager configurations to point to potentially malicious repositories, enabling supply chain attacks through dependency confusion.
Detects installation of the typosquatted NuGet package StripeApi.Net reported as malicious and targeting Stripe integrations.
Page 31 of 35