Malicious Packages – they’re gonna get ya!

Malicious Packages – they’re gonna get ya!

Speakers: Meg Sage, Senior Product Security Engineer, PagerDuty (introduced as “Mag Sage” in opening announcer transcript)

Conference: BSides Las Vegas

YouTube: https://www.youtube.com/watch?v=JPn-fV5_Drc

Overview

Meg Sage delivers a BSides Proving Grounds talk aimed at developers and security engineers who treat dependency installation as a routine npm install or pip install—and therefore miss that supply-chain attacks have scaled into a six-figure annual discovery rate by at least one major tracker. The core distinction is malicious versus vulnerable dependencies: vulnerabilities are unintentional flaws requiring some interaction or chain to exploit; malicious packages intend harm and may execute the moment you install or run tooling. Sage’s narrative threads through typo-squatting, trojan utilities, AI hallucinated package names (“slop squatting”), dependency confusion, and account hijacking, then pivots to defense—arguing layered controls because no single tool solves the problem. The tone is accessible, occasionally humorous, and grounded in recent incidents, including a popular ESLint-related npm package compromise “a couple weeks” before the talk and the xz/liblzma social-engineering saga.

Background

▶ Watch: Defines malicious vs vulnerable dependencies and why dev laptops/API keys are... (2:00)

Sage introduces a software engineering path through web development (self-deprecating PHP joke) into product security at PagerDuty. The two “remember this” bullets on the opening slide distill the thesis: malicious dependencies are increasingly common, and defending them is complicated.

She defines vulnerable dependencies as unintentional weaknesses (XSS, resource exhaustion, etc.) that typically need a chain to become incidents. Malicious dependencies are intentionally harmful—often targeting developers because laptops hold API keys, cloud credentials, DB passwords, and signing material, frequently in environment variables. A minimal JavaScript example grabs process.env and exfiltrates it to a URL—small code, large blast radius.

Attackers hide behavior via secondary downloads, steganography (including invisible Unicode tricks observed “earlier this year” per talk), base64 obfuscation, and blending malicious code into otherwise useful libraries. Malicious code may appear only as a transitive dependency, invisible at the top-level package.json.

That last point is why “we reviewed our direct dependencies” is not a coherent security statement for large JavaScript graphs: the malicious line may live five hops away, inside a package your team never heard of, installed as a helper to a helper. Sage’s opening env exfil snippet is intentionally boring—no exploit chain, no privilege escalation poetry—because the threat model is credential theft, not RCE showmanship. On a developer laptop, process.env is often the keys to the kingdom for AWS, GCP, GitHub, npm publish tokens, and internal VPN secrets. The malware does not need to survive in production if it already minted new access while you ran npm test.

Key Findings

▶ Watch: Sonatype scale stats: 156k (2023) vs 459k (2024) malicious packages cited, wi... (6:00)

1) Scale: Sonatype stats cited: 156,000 malicious packages found in 2023, 459,000 in 2024 alone—roughly triple year-over-year. Sage cautions Sonatype sells protective products; treat numbers skeptically, but directionally assume growth.

2) Typo-squatting dominates new-package attacks. Example: PyPI incident where 566 typo-squats landed in ~10 hours, forcing signup halts; slide shows many Pillow-adjacent misspellings.

3) Trojan packages deliver real functionality plus covert features—especially dangerous around crypto and API helpers where users supply secrets.

4) “Slop squatting” / AI hallucinations: LLMs suggest nonexistent package names repeatedly; attackers register those names and publish malware. First documented 2023, still present “today” in newer models per speaker.

5) Dependency confusion: attackers publish a public package matching an internal name with a newer semver; misconfigured registries pull public code. Defense: scope internal packages to private feeds only.

6) Package hijacking via expired maintainer email domains, stolen credentials/API tokens (MFA helps users, not always CI tokens), and social engineering. ESLint-ecosystem lint package compromise: maintainer phished, install.js and DLL added; caught quickly but still saw large download counts in a short window.

The ESLint-adjacent story is instructive because the malicious changes were visibly weird to a human reviewer—new install script and a stray DLL—yet automation still moved bits to many machines during the window before revocation and clean releases. That is the supply-chain clock: measured in hours, not CVE publication cadence.

7) xz / liblzma: multi-year pressure campaign on a sole maintainer, test file concealment, discovered when SSH latency caught an engineer’s eye—used as a lesson in patience and luck as defenses.

8) SCA limitations: traditional SCA focuses on known CVEs; malicious packages may have no advisory. Even known-malicious detection requires running before install/CI steps that execute the dependency—linters and tests often run before scans or in parallel, so SCA may arrive too late. Many tools skip devDependencies by default—exactly where linters live.

9) EDR helps on obvious behaviors (ransomware) but may miss quiet env exfil blended into normal web traffic.

10) Repository firewall products (unnamed category) monitor public registries and block known-bad fetches—speaker has not used them personally and does not vouch for efficacy.

Technical Deep Dive

▶ Watch: AI hallucination packages (“slop squatting”): attackers register LLM-invented... (10:00)

Attack mechanics

Typo-squatting exploits human typing error and search rank. Trojans exploit trust earned by useful code. Slop squatting exploits LLM training/correlation—a novel supply chain where the recommendation engine is the attack surface.

Dependency confusion exploits semver precedence and registry precedence misconfigurations. The fix is configuration: private packages must never resolve from public mirrors without an explicit, audited mapping.

Hijacking exploits identity longevity: abandoned packages with expired domains convert trust into payload channels.

Defender architecture

Sage advocates layers:

• Education (awareness that dev laptops are high-value targets).
• Manual diligence (double-check names, maintainers, history)—acknowledged imperfect against determined fakeries.
• SCA still valuable for CVE management, just not a complete malicious-package strategy.
• EDR on developer endpoints.
• Private artifactories with curation—with warning that a dumb full mirror replicates malware too.
• Registry firewall class (third-party review pipelines).

CI ordering problem

She diagrams a pipeline where build/test precedes security scans or runs in parallel—classic race against malicious dev tools that execute immediately on developer workstations outside CI entirely.

Even perfect CI gating cannot retroactively unrun a postinstall script that fired on a laptop yesterday. That asymmetry is why Sage keeps returning to developer workstation EDR and human habits—some classes of malware never touch the parts of your pipeline you lovingly secured.

“Healthy-looking” packages can still lie

Sage warns that attackers invest in plausible project metrics: fake stars, forks, download inflation, sockpuppet discussions. Manual review is not foolproof; it is one signal among many. This is another reason registry firewall-style services exist: they attempt continuous ingress review at publication time, though the speaker does not claim personal experience with their effectiveness.

Demo / Proof of Concept

▶ Watch: Dependency confusion mechanics: newer semver on public registry hijacks misco... (12:00)

No live exploit demo; the talk uses slides with code snippets and download charts for incidents. The xz narrative functions as a case study rather than a hands-on lab.

Defensive Implications

▶ Watch: xz/liblzma social engineering saga: multi-year pressure, hidden test payloads... (16:00)

AppSec programs should separate vuln management from malware ingestion controls. Minimum actions:

• Lockfiles + hash pinning where ecosystems support it; reproducible installs reduce drift.
• Private registry with allowlisting for production and dev toolchains.
• Pre-install hooks that run static reputation checks when available.
• Separate CI identities with least privilege and MFA where applicable; rotate publish tokens aggressively.
• Monitor for typo-squat alerts in security@ channels from registries.
• LLM guardrails in engineering: treat suggested package names as untrusted until verified in the registry UI.

Executives should fund artifact supply-chain programs as product security, not “developer convenience,” because one compromised maintainer laptop can become production signing compromise.

Legal/PR teams should have a playbook for “our build tool was poisoned” distinct from “our app has a CVE.” The xz narrative shows how volunteer maintainership and burnout create structural risk—another non-technical lever (sponsorship, support contracts) that security leaders can champion without pretending a scanner fixes sociology.

Dependency confusion deserves extra emphasis for monorepo shops: internal package names leak through error messages, public tickets, blog posts, and job ads. Attackers do not need to guess your Artifactory layout if someone pasted a pip/npm error into Stack Overflow. Treat internal names like identifiers with discovery risk, not just as build ergonomics.

For slop squatting, the mitigation is cultural: teams should adopt a “registry-first” habit—open the official package page, verify maintainers, release history, and download patterns, then paste the exact name into code. Copilot-style flows that go name → editor without that pause are the hazardous path.

Sage closes with the same sober line she opens: layered defenses because no one product closes the loop from publication → developer laptop → CI → production. That is the right mental model for budgeting: partial controls in parallel, not a single magic SKU.

If you need a single organizational habit to add first, make it evidence: for any new dependency, capture who approved it, why it is needed, and what upstream signal justified trust. That metadata becomes invaluable when a package later appears on a blocklist and you must decide rollback scope under incident time pressure.

Key Takeaways

• Malicious ≠ vulnerable; different defenses, different timelines.
• Developer machines are primary targets for token theft.
• Sonatype stats suggest rapid growth—verify, but do not ignore.
• Typo-squatting, trojans, dependency confusion, hijacks, and slop squatting cover most ingress patterns cited.
• SCA alone is insufficient and often late relative to dev tool execution.
• Private registries help if configured as curated gates, not dumb mirrors.
• Layered controls are mandatory; no silver bullet (speaker’s explicit conclusion).

About the Speaker(s)

Meg Sage is a Senior Product Security Engineer at PagerDuty, with prior software engineering and web development experience. Personal interests mentioned include cosplay and houseplants. The opening announcer’s transcript says “Mag Sage”; the speaker’s slides introduce Meg Sage. Bundle metadata lists Speakers: Unknown.