The LiteLLM Supply-Chain Attack — TeamPCP “SANDCLOCK” CI/CD Credential-Harvesting Campaign via a Backdoored Trivy GitHub Action

Resecurity has acquired 152.5 GiB of data following a supply-chain security breach involving LiteLLM, exposing stolen corporate credentials and configuration data linked to thousands of domains.

Analysis of the attacker's victim archive from the March 2026 LiteLLM supply-chain compromise (TeamPCP / “SANDCLOCK” stealer): 415,427 on-host secret-capture files harvested from GitHub Actions / CI-CD runners across 898 owners and 2,038 repositories — with the Trivy→LiteLLM attack chain, captured-secret composition, real masked evidence, and named victims.

1   Executive Summary

Resecurity analysed an acquired archive, supplychain_victims.tar (≈152.5 GiB), containing 415,427 secret-capture files. Every file follows the naming convention <YYYYMMDD>_<HHMMSS>_<µs>_127.0.0.1.txt and holds a JSON-style secret store of the form "<name>":{"value":"<secret>","isSecret":true}. The uniform 127.0.0.1 tag indicates the secrets were dumped in-process on the victim host — i.e. environment/secret material read from live CI-CD pipeline memory, not intercepted over the network.

The archive is attributed to the LiteLLM supply-chain attack conducted by TeamPCP using the “SANDCLOCK” credential-stealer. Per published incident reporting — corroborated by this dataset — TeamPCP backdoored the Trivy GitHub Action (aquasecurity/trivy-action, which appears in the affected-repos manifest) on 19 March 2026; LiteLLM's CI auto-installed the poisoned Trivy, which stole LiteLLM's PyPI publishing tokens and published malicious litellm==1.82.7 / 1.82.8 on 24 March 2026. On every compromised runner the stealer escalated to root and swept SSH keys, cloud credentials, Kubernetes tokens, .env files and in-memory secrets from /proc/<pid>/mem — precisely the artefacts captured in these files.

Accompanying victim manifests enumerate 898 compromised GitHub owners (organisations/accounts) across 2,038 repositories. The affected owners include major global enterprises — among them Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me and 1inch (see §7).

From a 1,073-file sample (the portion recoverable from the partial download), Resecurity catalogued 2,146 captured secret records. The dominant artefact is the GitHub Actions GITHUB_TOKEN — present in ~98% of sampled files — alongside GitHub App private keys, AWS/GCP/Firebase credentials, container-registry (ECR/JFrog) tokens, SSH keys, code-signing passwords and CI webhooks. No live secret values are reproduced in this report; all exhibits show real captures with secret values masked (start/end retained, entropy removed).

Assessment: this is a high-to-critical severity software-supply-chain compromise. Harvested CI-CD tokens grant push/publish access to source repositories and package registries, enabling second-order supply-chain propagation (poisoning downstream artefacts) as well as cloud-account takeover — indeed this campaign itself propagated Trivy→LiteLLM by exactly that mechanism. Every organisation named herein should treat all referenced credentials as compromised and rotate immediately.

2   Key Findings

3   Incident Overview — the Trivy → LiteLLM Attack Chain

This is a chained software-supply-chain attack attributed to TeamPCP, delivering the “SANDCLOCK” credential-stealer. A trusted, widely-used security tool — the Trivy GitHub Action — was backdoored; because thousands of organisations' CI pipelines auto-install Trivy, the poisoned Action executed inside their GitHub Actions runners and swept every secret in reach. The uniform 127.0.0.1.txt captures in this archive are the stealer's per-run loot files.

The chain is corroborated by this dataset: the backdoored aquasecurity/trivy-action appears directly in the affected-repository manifest, the captures are GitHub Actions-scoped (system.github.token in ~98% of files), and runner identifiers reference actions-runner-controller (arc-prod-…-runner) and GitHub-hosted runners — matching the reported self-hosted + hosted CI footprint.

Why GITHUB_TOKEN matters. Every GitHub Actions job receives an automatically-generated GITHUB_TOKEN with write scope to its repository. Harvested at scale (415k+ runs), these tokens — even though short-lived — provide a wide, time-boxed window to push code, publish packages, alter releases and read repository secrets, which is precisely how supply-chain compromises cascade to downstream consumers.

4   Acquired Dataset — Scope & Structure

The archive expands to a single extracted/ directory of 415,427 timestamped .txt capture files (manifest: tree.txt). Files are small on average (median 418 B) but 197,410 exceed 50 KB, with the largest ~30 MB — the size split reflects minimal beacons/empty runs versus full secret-bearing captures. Captures concentrate on 19–20 March, taper on the 22nd, and resurge on 23–24 March.

5   Captured Secrets — Composition

Across the 1,073-file sample, Resecurity enumerated 2,146 secret records by key name (values never inspected beyond structural masking). The composition is overwhelmingly GitHub CI-CD identity material, with a long tail of high-value cloud and registry credentials.

6   Evidence — Redacted Capture Sample

Real captured records are reproduced below with secret values masked — the real type prefix and final characters are retained (start******end) while all entropy is removed, so the exhibit is authentic yet discloses no usable credential. Key names and non-secret structure are unmodified. Values are drawn from actual sample files.

 EXHIBIT A — REAL CAPTURE RECORDS (VALUES MASKED)  ·  *_127.0.0.1.txt
  "github_token":            {"value":"ghs_**********9wDB", "isSecret":true},   // 40-char GH Actions token
  "system.github.token":     {"value":"ghs_**********9wDB", "isSecret":true},
  "GH_ACTIONS_APP_ID":       {"value":"2*****0",           "isSecret":true},
  "GH_ACTIONS_APP_PRIVATE_KEY":{"value":"----**********--","isSecret":true},  // 1,702-char RSA key
  "GH_PAT":                  {"value":"gith**********BfpL", "isSecret":true},   // 93-char PAT
  "AWS_ROLE_TO_ASSUME":      {"value":"arn:aws:iam::26******39:role/GithubAutomationPrisma…","isSecret":true},
  "WORKLOADS_DEV_AWS_ACCESS_KEY_ID":{"value":"AKIA**********5ED","isSecret":true},
  "ECR_REPOSITORY_URI":      {"value":"07******86.dkr.ecr.us-gov-west-1.amazonaws.com/****","isSecret":true},
  "GCP_SERVICE_ACCOUNT":     {"value":"gcp-****@felix-shared-services.iam.gserviceaccount.com","isSecret":true},
  "JFROG_AUTH_TOKEN":        {"value":"eyJ2**********hxiw", "isSecret":true},   // 759-char JWT
  "SECURITY_CI_ERRORS_WEBHOOK_URL":{"value":"https://hooks.slack.com/****","isSecret":true},
  "SIGNING_PASSWORD":        {"value":"xJRp**********EHL6", "isSecret":true}

7   Affected Organisations & Repositories

Victim manifests (owners.txt, repos.txt) enumerate 898 distinct compromised GitHub owners across 2,038 repositories. The distribution is long-tailed: 631 owners have a single affected repo, while the most-affected owner (Cencosud-Cencommerce) has 64. Critically, the owner list includes major global enterprises and regulated organisations.

7.1  Notable named organisations (verified in owners/repos manifests)

7.2  Cloud tenants & secret-scoped identifiers (from sample)

Beyond owner names, capture values embed cloud identifiers pinpointing specific tenants:

7.3  Affected owners — sample (45 of 898, by repository count)

7.4  Affected repositories — sample (30 of 2,038)

Rows 1 above (aquasecurity/trivy-action, reviewdog/action-trivy) are the poisoned build-tooling repositories at the root of the chain; the remainder are victim repositories whose CI executed the backdoored Action. Full lists: 898 owners / 2,038 repositories.

8   Impact & Risk Assessment

9   Attribution & TTPs (MITRE ATT&CK, assessed)

Assessed from dataset structure and public reporting of the associated campaign; not confirmed victim telemetry.

10   Indicators & Detection Guidance

11   Recommendations

▪ Immediate (0–72 hours)

• Rotate everything referenced. Revoke/rotate GitHub App private keys, PATs, AWS/GCP/Firebase credentials, ECR/JFrog tokens, SSH keys and signing passwords; invalidate sessions. Ephemeral GITHUB_TOKENs expire, but persistent secrets exposed alongside them do not.
• Audit for supply-chain propagation. Review repository push history, package/registry publishes and release edits during 19–24 Mar 2026; verify downstream artefact integrity and pin/verify dependencies.
• Identify the malicious component. Examine CI/CD build logs for the trojanised dependency/Action; remove and block it; rebuild from known-good sources.
• Notify affected tenants & authorities. Prioritise the GovCloud tenant and any regulated data; engage cloud providers and, where applicable, collaborate with national CERTs.
• Contain cloud blast radius. Constrain OIDC/workload-identity trust, tighten IAM role conditions, and enable anomaly alerting on the implicated accounts.

▪ Short term (2–6 weeks)

• Adopt short-lived, least-privilege CI secrets (OIDC federation over static keys); scope GITHUB_TOKEN to read-only by default and elevate per-job.
• Enforce dependency pinning, provenance/attestation (e.g. build SLSA), and allow-listing of Actions; isolate runners.
• Deploy secret-scanning and push-protection across repos and registries; add DLP on runners to detect local secret-dump files.
• Establish continuous dark-web/leak monitoring for organisation tokens and cloud identifiers.

12   About Resecurity & Disclaimer

Resecurity is a cybersecurity and threat-intelligence company providing dark-web monitoring, digital-risk protection and CTI services to enterprises and government organizations. This report was produced by the Resecurity HUNTER threat-intelligence unit.

Provided for defensive, situational-awareness and victim-notification purposes only. Findings derive from analysis of the attacker's victim archive and its manifests, correlated with published incident reporting on the LiteLLM / TeamPCP (“SANDCLOCK”) supply-chain attack; the attack-chain narrative reflects that public reporting. 

Resecurity has not reproduced any live credential: all exhibits show real captures with secret values masked (start/end retained, entropy removed). Owner/repository counts (898 / 2,038) are taken from the leak manifests; per-secret and per-tenant details derive from the recovered 1,073-file sample. Organisation identifiers are surfaced solely to enable defensive notification; named entities are victims of a criminal supply-chain compromise and no fault is implied. Nothing herein is legal advice.