# Malicious PyPI Package mudraid-sdk in Agent HTTP Traffic

- **Severity:** High
- **Signature ID:** `7b3f1c94-2d8a-4e51-9c60-5a7d2f0b8e13`
- **MITRE ATLAS:** AML.T0005 (Create Proxy AI Model)
- **OWASP:** LLM03 (Supply Chain), LLM02 (Sensitive Information Disclosure)

## Summary

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.

## 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.

## References

- https://attack.mitre.org/techniques/T1195/001/
- https://atlas.mitre.org/techniques/AML.T0005
- https://genai.owasp.org/llmrisk/llm032025-supply-chain/

---
Source: https://www.netzilo.com/threats/mudraid-sdk-supply-chain