Trust Boundary Collapse: TeamPCP & ClickFix — Lateos

TLP:CLEAR<br>2026-08-14

Supply Chain · Endpoint

TeamPCP · LiteLLM

ClickFix · AmnesiaStealer

.pth Persistence

Session Hijacking

Detection Engineering

Contents

Correcting the framing

Key judgments

Part I — TeamPCP

The .pth primitive

Payload architecture

Infrastructure

Blast radius

Detection logic

MITRE ATT&CK

Part II — ClickFix

AmnesiaStealer

Detection logic

Part III — Convergence

Part IV — Defense

Appendix A — IOCs

Appendix B — Gaps

Appendix C — Sources

← All articles

Executive Summary

Two separate campaigns demonstrated that modern security controls fail when malicious code arrives outside the expected inspection path. Both campaigns bypassed artifact inspection, which is the foundation of registry scanning, Gatekeeper, notarization, EDR file reputation, SBOM generation, and dependency vulnerability scanning.

TeamPCP poisoned the LiteLLM Python package through a compromised security scanner (Trivy). The malicious versions were live on PyPI for approximately three hours, exposing an estimated 2,500 organizations and 434,000 CI/CD pipelines. The payload harvested credentials, including Kubernetes service account tokens and cloud secrets, using a .pth file persistence mechanism that triggers on every Python interpreter start.

ClickFix delivers malware to macOS users by instructing them to paste commands into Terminal. This technique bypasses quarantine attributes, Gatekeeper, and notarization entirely because the user executes the command manually inside a trusted terminal. AmnesiaStealer uses ClickFix delivery to install a credential stealer that captures passwords, browser cookies, and cryptocurrency wallet keys. Its third stage launches a headless browser running the victim's live authenticated sessions.

Both campaigns share no infrastructure, tooling, or operators. They matter together because they expose a structural assumption shared by every mainstream security control: that malicious code arrives as an inspectable artifact at a controllable boundary before execution. Neither campaign fits that model.

Key recommendations: Pin dependencies to cryptographic hashes, not tags. Egress-allowlist CI runners. Eliminate long-lived secrets from runner environments using OIDC federation. Deploy macOS 26.4+ paste protection on non-engineering fleets. Alert on behavioral indicators like unexpected .pth file creation and bulk credential access. Treat session invalidation as a first-class step in incident response playbooks.

0. Correcting the framing

The tasking described the LiteLLM incident as "stolen CI/CD credentials allowed attackers to inject info-stealing malware." That description is true only at the last hop, and the imprecision matters operationally.

A formal Analysis of Competing Hypotheses yields two viable branches:

HypothesisMechanismConfidenceEvidence

H1: Token harvest from compromised scanner Trivy CI misconfiguration exposed aqua-bot PAT → attacker harvested PyPI_PUBLISH token from LiteLLM's own runner where Trivy ran as a build step → published poisoned litellm 1.82.7/1.82.8Moderate-to-high Cycode has documented LiteLLM's Trivy-using pipeline inadvertently exfiltrating the PyPI publishing tokens. The attack chain is technically coherent and matches all observable artifacts.<br>H2: Initial compromise of co-founder GitHub account Attackers gained direct access to LiteLLM co-founder/CEO GitHub account → used scoped PyPI publish token + account privileges to close issue #24512 as "not planned" and commit to unrelated repos with message "teampcp update"Moderate ReversingLabs assesses the PyPI compromise was likely caused by initial compromise of a GitHub account belonging to LiteLLM's co-founder and CEO. Endor Labs and THN Labs both hedge with "likely." Account-control observables (closing issues, cross-repo commits) are unexplained by H1 alone.

Why this matters: H1 predicts that hash-pinning dependencies and egress-allowlisting runners would have prevented the incident. H2 predicts those controls would have stopped the payload but not the account takeover and its collateral damage (issue closure, cross-repo contamination). Both branches converge on the same remediation conclusion — the distinction is whether you also need GitHub account hardening and multi-party authorization for high-privilege operations.

If the story is "protect your publish tokens," you get secret rotation and two-factor authentication. If the story is "any tool your pipeline executes inherits your pipeline's secrets, and any privileged account is a pivot point," you get hash-pinned dependencies, egress control on runners, ephemeral OIDC credentials, AND multi-party authorization for high-privilege operations. Only the second framing would have prevented this incident.

1. Key judgments

Both campaigns defeat artifact-inspection security models, by different routes. TeamPCP poisoned the artifact before it reached the registry, so scanning the...