Malicious PyPI Package mudraid-sdk in Agent HTTP Traffic
mudraid-sdk is a trojanized package published to PyPI. This rule spots outbound web traffic that mentions the package name, whether that's a download, a manifest listing it, or a runtime beacon carrying stolen credentials.
How the attack works
A system or build pipeline fetches the mudraid-sdk package from the Python Package Index, or a dependency file that pins mudraid-sdk gets sent to a build/CI/packaging service before anyone even resolves it. If the trojan has already been installed and run, it may 'phone home' using identifiers like an SDK version string or custom headers - and if that beacon also carries real credential data in the same request, that's the payoff moment for the attacker: stolen secrets leaving over a connection that identifies itself as the compromised package. The rule only sees network traffic; it cannot see the actual install or code execution happening on disk.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3f1c94-2d8a-4e51-9c60-5a7d2f0b8e13
- Severity
- High
Why it matters
If the credential-carrying beacon fires, an attacker is actively exfiltrating live tokens or secrets from a system running the trojanized package. Earlier-stage matches (download or manifest mention) mean exposure risk, not confirmed compromise.
What you can do
- →Search build logs, dependency manifests, and lockfiles for any reference to mudraid-sdk and remove it immediately.
- →If found installed, treat all credentials accessible to that runtime as compromised and rotate them.
- →Block outbound requests to PyPI URLs for this package from production and CI systems where it has no legitimate use.
- →Distinguish real installs from mirror syncs, SCA scans, or research downloads before treating a match as an incident - check whether the package was actually installed and run.
Known benign look-alikes
- Internal PyPI mirror or pull-through proxy (devpi, Artifactory, Nexus, uv cache warmer) performing an index sync - it will fetch /simple/mudraid-sdk/ and the artifact even though nothing installed it into a runtime.
- Security research, IR triage or a malware sandbox deliberately downloading the mudraid-sdk wheel/sdist for analysis - same URL shape as a real install.
- SCA / dependency-audit tooling POSTing a complete lockfile or SBOM to a scanning API, where mudraid-sdk appears as a listed (possibly already-removed) entry; the manifest-pin branch fires on the name inside the uploaded document.
- An agent drafting or reviewing a remediation PR that removes the pin - the removed line is still present in the diff body sent outbound.
- Takedown notices, blog posts or threat-intel writeups quoting the package name next to a sample Authorization header; suppressed by filter_advisory_* when advisory identifiers and advisory JSON shape are both present, and by filter_placeholder_secret when the token is templated.
- A legitimately named unrelated package or vendor product that happens to contain the token "mudraid-sdk" - none known at authoring time, but the name is the sole anchor for branches A and B.