OpenSourceMalware

🚨 Attack alert: Axios has been compromised Read the full technical analysis >>> https://lnkd.in/gZW8BywU See the threat reports >>> https://lnkd.in/gr_svMEh Malicious versions axios v1.14.1 and v0.30.4 were published with a new dependency, plain-crypto-js, that executes automatically on install and deploys a cross-platform remote access trojan. From npm install to full compromise: approximately 15 seconds. The attacker built platform-specific payloads for Windows, Linux, and macOS, with persistence, reflective DLL injection on Windows, and a compiled universal binary for Mac. C2: sfrclak[.]com (142.11.206[.]73:8000). TL;DR - Threat Actor: Unknown (assessed espionage/APT motive) - Target: axios npm package (40M+ weekly downloads) - Attack: Malicious dependency plain-crypto-js injected via package.json, executes via postinstall hook - Payload: Cross-platform RAT that beacons system info, enumerates files, and accepts remote code execution commands - Exfil targets: ~/.ssh, ~/.aws, ~/Documents, ~/Desktop, config directories - C2: sfrclak.com / 142.11.206[.]73:8000 - Status: Malicious versions published; axios maintainer account reported locked

OpenSourceMalware now supports threat reports for malicious containers! View all container findings: https://lnkd.in/ggfV7M_8 Is there a type of component you want to see supported in the platform? 👇 let us know in the comments.

🚨 Telnyx is the latest victim of the TeamPCP attack. We're tracking the full campaign here: https://lnkd.in/g2yRuHH5 The Telnyx attack introduces a technique not seen in prior phases: audio steganography. Rather than embedding the payload directly in Python code, the malware fetches a WAV file from the C2 server and extracts the credential stealer from the audio frames. This bypasses network inspection tools that flag raw executables or encoded blobs. The payload splits by platform. Windows gets persistence: the extracted executable drops into the Startup folder as msbuild.exe and survives reboots. Linux and macOS get a smash-and-grab: a single high-speed credential sweep, AES-256-CBC encryption under the same RSA-4096 public key used in the LiteLLM phase, exfiltration as tpcp.tar.gz to 83.142.209[.]203:8080, then self-deletion with near-zero forensic artifacts. TL;DR Threat Actor: TeamPCP Target: Telnyx PyPI package Versions: telnyx==4.87.1 and telnyx==4.87.2 (published March 27) Delivery: WAV steganography — hangup.wav (Windows), ringtone.wav (Linux/macOS) Exfil: 83.142.209[.]203:8080 via tpcp.tar.gz Attribution: Shared RSA-4096 public key matches LiteLLM and Checkmarx phases Status: PyPI quarantined. Downgrade to telnyx==4.87.0 immediately Recap of the entire attack chain: Stolen PAT → directly enabled Phase 1 (Trivy) Phase 1 (Trivy) → enabled Phase 2 (Aqua org) via Argon-DevOps-Mgt token harvested from Trivy CI runner Phase 1 (Trivy) → enabled Phase 3 (CanisterWorm/npm) via npm tokens harvested from Trivy CI runners Phase 1 (Trivy) → enabled Phase 4 (Checkmarx) via reused stealer tradecraft and credentials from prior harvest Phase 1 (Trivy) → enabled Phase 5 (LiteLLM) via PyPI token exfiltrated from LiteLLM's CI pipeline running compromised Trivy Phase 5 (LiteLLM) → enabled Phase 6 (Telnyx) via PyPI token harvested during LiteLLM phase

The OpenSourceMalware team has identified a live supply chain attack against LiteLLM (litellm), a popular Python SDK and AI gateway proxy with over 40,000 GitHub stars. Read the research blog >>> https://lnkd.in/ggBCr4QW See the threat report for litellm >>> https://lnkd.in/gnddjR49 The threat actor TeamPCP hijacked the PyPI maintainer account and published malicious package versions containing a credential stealer that executes on every Python startup — no import required. This is the same threat actor behind the aquasec-com GitHub organization compromise we reported on March 23, and represents a significant escalation: from org defacement to a weaponized supply chain attack targeting the AI/LLM developer ecosystem. TL;DR Threat Actor: TeamPCP Target: LiteLLM (litellm) PyPI package Attack: Maintainer's PyPI account hijacked, malicious versions 1.82.7 and 1.82.8 published Payload: litellm_init.pth — a .pth file that auto-executes on every Python startup, steals all credentials, and exfiltrates to attacker infrastructure Exfil Domain: models.litellm.cloud (registered March 23 via Spaceship, IP 46.151.182.203 — Ghosty Networks, Luxembourg) Status: PyPI has quarantined the entire litellm project. BerriAI GitHub org partially defaced. Maintainer's personal GitHub account also compromised.

Aqua Security is having a bad week. The OpenSourceMalware team has identified an active compromise of the aquasec-com GitHub organization — Aqua Security's internal org for proprietary code. The threat actor TeamPCP (aka DeadCatx3, PCPcat, ShellForce) defaced all 44 repositories in a scripted 2-minute burst, renaming every repo with a tpcp-docs- prefix and setting all descriptions to "TeamPCP Owns Aqua Security." Our forensic analysis of the GitHub Events API points to a compromised service account token (likely stolen during TeamPCP's prior Trivy GitHub Actions compromise) as the attack vector. TL;DR Threat Actor: TeamPCP Target: aquasec-com GitHub organization Impact: 44 internal repos defaced, renamed, and exposed publicly Attack Vector: Compromised Argon-DevOps-Mgt service account token (high confidence) Key Finding: The threat actor tested the stolen token 7 hours before the defacement by creating and deleting a ghost branch on aquasecurity/trivy-plugin-aqua All the gritty details are here: https://lnkd.in/gmTkXSvq

Catch up on the latest product improvements and research! Highlights for March include... Product: - Research crypto wallets and IP addresses - Custom threat alerts - Sorting by 'most downloaded' Research: - New glassworm attacks - PolinRider campaign - Neutralinojs attack

Co-founders Jenn Gile and Paul McCarty are in San Francisco - come say hi if you spot us!

🚨 Trivy compromised with malware 🚨 Threat actors compromised the GitHub build process for Trivy and pushed a malicious update. If you have Trivy version 0.69.4 installed, you will need to start incident response ASAP. Malicious tag included a link to a binary payload which we have not analyzed yet. Treat as CRITICAL until we know more. Check out the threat report here: https://lnkd.in/gD-FvQmz Kudos to Rami McCarthy for the find.

🎉 There are now 160k verified threats in our threat intelligence database! If you take a look at our stats page - https://lnkd.in/gJkZh2bu - you’ll see a fancy new graph showing weekly threat trends. There’s a big spike around August 31, which is when we launched the database. Of course with most malicious open source living in npm, that dominates the chart. But if we strip away npm, we can see some interesting trends related to other types of malicious assets. 📈 Shai-Hulud 2.0: There were spikes in malicious PyPI, GitHub repos, and other assets around November 30. This illustrates that while Shai-Hulud started in npm…it didn’t stay there. 📈 PyPI: Though historically much less malware is found in PyPI, we’re seeing an uptick. In January, there were just 30 PyPI packages reported. In February, that jumped to 132 threat reports. Hmm, what’s going on there? (The “other” category includes non-npm/PyPI packages, URLs, IP addresses, domains, and crypto wallets) What kind of trends are you interested in?

For our first “research best practices” post, we’re going to talk about why sandboxing is often the wrong tool for modern, open-source malware. While compiled language malware (written in C/C++, Go, Rust, etc) can be analyzed through dynamic analysis, interpreted languages (JavaScript, Python, etc) offer specific properties that make malware harder to detect via traditional methods. With interpreted language malware: 👉 Source code ships as the attack artifact 👉 Full deobfuscation is deterministic 👉 Sandbox evasion is trivially implemented  👉 Import-time and dependency-context execution is the real bypass For dynamic analysis to produce useful signal, the malware must *actually execute its malicious payload during the observation window.* But interpreted language malware is unlikely to execute in a sandbox environment. Take a look at the graphic to understand how the requirements for dynamic analysis don’t align well with interpreted malware (focused on Python and JavaScript). Stay tuned for more on this topic!