Supply Chain vedang-cli Install Followed By Payload Execution
This rule watches for a specific two-step pattern: someone installs or runs the PyPI package vedang-cli, and shortly afterward, the same session runs a command that looks like it downloads or executes something (curl, wget, base64-decoded payloads, encoded PowerShell, persistence via cron or launchctl). It does not accuse vedang-cli itself of being malicious — no wrongdoing has been proven in that package — it just flags the behavioral sequence for a human to review.
How the attack works
An attacker (or a compromised build process) first installs or runs vedang-cli via pip, pipx, uv, poetry, conda or similar. Within the same process session and within 10 minutes, a second, payload-like command runs in the same lineage — for example a curl/wget download, a reverse shell via /dev/tcp, a base64-decoded blob being executed, or a scheduled task being created. The rule ties both steps to the same process ancestry so it can prove they came from one continuous action rather than two unrelated events. It also attaches any credential-file reads seen in that window as supporting context, though those alone never trigger the alert.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7f3c1a9e-2d84-4b16-9c05-8ae4f1d3b72a
- Severity
- Medium
Why it matters
If real, this pattern would mean a supply-chain package install was used as a stepping stone to fetch or run additional code, potentially leading to credential theft, backdoor persistence, or remote access on the affected host.
What you can do
- →Review the full command-line and process lineage the alert provides before assuming compromise — plain installs and unrelated shell commands in the same session are common and expected to sometimes match.
- →If vedang-cli or any package with a build backend fetches prebuilt binaries via curl/wget during install, verify the download source and checksum.
- →Restrict what post-install and build hooks can execute (e.g. sandboxed build environments) so a package cannot silently reach the network or spawn shells.
- →Treat unverified-provenance packages like vedang-cli with extra caution: pin versions, review source, and avoid installing them in sessions with access to sensitive credentials.
Known benign look-alikes
- Legitimate vedang-cli install whose build backend or post-install hook fetches a prebuilt binary with curl/wget. This is common for packages that ship compiled artifacts. The kill chain shows the exact command line and lineage so an analyst can confirm the destination.
- A developer installs vedang-cli and then, in the SAME interactive shell within 10 minutes, runs an unrelated curl / base64 / shell one-liner. Session scoping cannot separate two human intents inside one shell; the emitted lineage trail is provided precisely so this can be dismissed quickly.
- Custom PEP 517 build backends that invoke `python -c` with `subprocess` or `exec()` during wheel construction. Mitigated by requiring a network/exec keyword alongside `python -c` (plain `python -c "import setuptools"` from pip build isolation does not match), but an unusual backend can still match.
- Self-hosted CI runners that install vedang-cli and immediately curl an internal artifact store or upload logs as part of the same job.
- Malware-analysis or security-research sandboxes intentionally installing and exercising the package.
- Credential-file reads attached as supporting evidence may be benign (aws/gh CLI helpers invoked by the same shell); they never cause the rule to fire on their own.