Fake Payment-SDK npm/PyPI Supply-Chain Campaign

On 2026-07-07, Socket detected a coordinated supply-chain campaign that pushed 17 npm modules and 4 PyPI packages masquerading as SDKs for well-known payment brands — PaySafe, Skrill, and Neteller. Each npm package shipped four rapid versions (1.0.0–1.0.3); the PyPI packages shipped a single malicious 1.0.0. They were flagged malicious within roughly six minutes of publication, but any developer or CI job that installed one in that window is exposed.

The packages present a convincing SDK facade: calls immediately return { success: true, method, path } so the developer sees no error, while a delayed background routine harvests every environment variable whose name contains KEY, SECRET, TOKEN, PASS, AUTH, or API (values truncated to 100 chars), fingerprints the host, and exfiltrates to an ngrok-hosted C2. Prime targets include PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, and NPM_TOKEN.

The payload includes anti-analysis logic — it aborts on hosts with fewer than two CPU cores or with security keywords (sandbox, analyzer, cuckoo, vmware, vbox, malware) in the hostname/username — and hides its C2 behind a three-step decode (XOR, character shift, string reversal).

Attacker objective: steal long-lived CI/CD and cloud credentials from developer and build environments, then reuse them for downstream cloud access, further package publishing (NPM_TOKEN), or source-code access (GITHUB_TOKEN).

Defender priority: Deny the named packages in your registry proxy and scrub them from every lockfile (§7/§10); hunt Q1–Q3 for the ngrok C2 domain, the package names in install command lines, and the known payload hashes; then rotate every CI/CD and cloud secret reachable from any host that installed one — the credential exposure is the real incident, not the package file.

Sourcing note: This is a fresh (7-day) supply-chain event; primary attribution is Socket's automated detection, corroborated by GBHackers and CyberPress. Atomic IOCs used in this pack — the three SHA-256 payload hashes, the ngrok C2 domain, and the package names — are drawn directly from those reports and cited in §18. No indicator here is fabricated.

Hunt hypotheses (fidelity-ordered)

Attack chain

The package-name and hash IOCs are point-in-time (the packages were pulled quickly); the ngrok domain is perishable. Treat the SHA-256 and domain as short-lived detect entries and the package names primarily as a registry/lockfile audit (§7).

Telemetry reality: the malicious logic runs inside the node/python interpreter, so the harvest step (env read) is not directly visible to EDR. Detection leans on the install command, the DNS/egress to C2, the payload hash, and lockfile audits — plus fast secret rotation as the real mitigation.

The highest-value hunts for a package-supply-chain event live in your source repos, lockfiles, and registry proxy — not on the endpoint. Run these across every repo and build cache.

Lockfile / manifest audit (repos + build caches)

# Search every repo, lockfile, and node_modules/site-packages cache for the names:
paysafe-checkout  paysafe-node  paysafe-js  paysafe-sdk
paysafe-payments  paysafe-api   paysafe-kyc  skrill-payments  neteller
# Files to grep: package.json, package-lock.json, yarn.lock, pnpm-lock.yaml,
#                requirements.txt, poetry.lock, Pipfile.lock
# Any hit = a host/repo that pulled the package -> treat as exposed, rotate its secrets.

Registry proxy / SCA logs

# In Artifactory/Nexus/Verdaccio or your SCA tool, query download events for the
# package names above since 2026-07-07. Map each download to a host / CI job / user.

CI/CD secret exposure & provider abuse

# For every host that installed a package: enumerate which secrets were in its env
# (KEY/SECRET/TOKEN/PASS/AUTH/API) and rotate them. Then review provider-side logs:
#   - GitHub: audit log + token usage for GITHUB_TOKEN
#   - AWS: CloudTrail for the AWS_SECRET_ACCESS_KEY principal
#   - npm: publish events for NPM_TOKEN

Step 3–4 (sandbox evasion + env harvest) run inside the interpreter and leave little endpoint telemetry — the lockfile/registry audit is what actually scopes the blast radius. Pair it with the DNS/egress hunts (Q1, Q4) to catch hosts that reached the C2.

Deployment path: load the domain + hashes as Custom IOCs immediately (short expiry — they are perishable). Promote Q2 to a detection; keep Q4/Q5 as hunts until tuned. The durable control is the registry deny-list + secret rotation, not the IOC block.

1 · Purge & deny the packages

# Remove any installed copy and scrub lockfiles, then reinstall clean:
npm uninstall paysafe-checkout paysafe-node paysafe-js skrill-payments neteller
pip uninstall -y paysafe-sdk paysafe-payments paysafe-api paysafe-kyc
# Registry proxy deny-list (Verdaccio example): add the names under an unmatched
# package rule so they can never resolve internally.
# Clear caches so a poisoned copy is not reused:
npm cache clean --force
pip cache purge

2 · Harden CI install steps

# package installs must NOT run arbitrary scripts:
npm ci --ignore-scripts
# python: pin hashes so only vetted artifacts install:
pip install --require-hashes -r requirements.txt
# Egress allow-list on the runner (example iptables intent): permit registry
# endpoints only; drop everything else, including ngrok.

3 · Rotate & verify exposed secrets

# For each host that installed a package, for each secret in its env matching
# KEY|SECRET|TOKEN|PASS|AUTH|API:
#   1. Issue a replacement (prefer short-lived OIDC).
#   2. Revoke the old value.
#   3. Review provider logs for use since 2026-07-07:
#        GitHub audit log (GITHUB_TOKEN), AWS CloudTrail (access keys),
#        npm publish events (NPM_TOKEN).

Known gaps: (1) The env-var harvest and anti-sandbox checks run inside the node/python interpreter and produce no discrete EDR event — they are covered only indirectly (install + C2 + hash) and, decisively, by secret rotation. (2) Ephemeral CI runners often lack an EDR sensor, so the lockfile/registry audit (§7) is the authoritative scoping method, not CQL. (3) Q4/Q5 are FP-prone (legit ngrok / postinstall fetches) — tune before alerting.

Generated 2026-07-14 · HuntPack · Defensive detection & hardening content only. No victim organizations named.