Xinference on PyPI: TeamPCP's self-attribution marker, AWS post-exploitation scope, and why April 22 matters for the .pth timeline

Three versions of the xinference PyPI package — 2.6.0, 2.6.1, and 2.6.2 — were trojanized with a two-stage credential-stealing payload, then yanked from the registry. xinference is a distributed inference runtime for open-source LLMs, embedding models, and multimodal models, used in environments where model serving infrastructure holds cloud credentials with meaningful scope.

JFrog Security Research identified # hacked by teampcp in the decoded payload — a Layer 1 self-attribution string directly comparable to the tpcp.tar.gz archive name in the litellm payload and the Technique: .pth file injection (TeamPCP/LiteLLM method) string in CanisterWorm. The April 22 date positions this compromise three weeks after the litellm .pth injection (March 24) and establishes that the operator had standardized the technique by this point in the campaign timeline.

The Xinference payload also introduces a post-exploitation capability not documented in prior TeamPCP PyPI victims: the payload actively enumerates AWS IMDS credentials, Secrets Manager secrets, and SSM Parameter Store parameters. This goes beyond passive collection of credentials already present on the filesystem — it is active cloud API enumeration that will succeed in any compute environment with an IAM role attached, even if the developer has not explicitly stored credentials locally.

What we know

• April 22, 2026 — JFrog Security Research published primary analysis. Malicious versions 2.6.0, 2.6.1, and 2.6.2 yanked from PyPI.
• Attribution: # hacked by teampcp found in decoded payload by JFrog. This is the same self-attribution pattern present in the litellm tpcp.tar.gz archive name — the operator consistently leaves self-attribution markers in payload artifacts.
• Injection point: Malicious code embedded in xinference/__init__.py — executes on package import, not at install time. Any process that imports xinference will trigger the payload.
• Exfiltration endpoint: whereisitat[.]lucyatemysuperbox[.]space — a distinctive domain with no plausible typosquat relationship to xinference. Unlike models.litellm[.]cloud (which impersonated the legitimate litellm.ai), this domain makes no pretense of legitimacy.

Timeline significance: why April 22 matters

The TeamPCP PyPI campaign timeline matters for understanding the operator's technique evolution:

• March 20 — Trivy GitHub Action compromised (npm-focused, credential theft)
• March 24 — litellm PyPI compromise; first documented .pth injection in TeamPCP chain
• April 22 — xinference PyPI compromise; three-week gap from litellm
• April 29–30 — Mini Shai-Hulud (SAP npm), elementary-data, lightning PyPI — cluster expansion

The three-week gap between litellm (March 24) and xinference (April 22) is consistent with a technique refinement period. The litellm payload introduced .pth injection. The xinference payload does not appear to use .pth injection based on available JFrog analysis — it uses direct __init__.py modification instead. This suggests the operator was running parallel technique development: .pth injection for stealthy persistence in one branch, direct __init__.py injection for broad trigger coverage in another.

Payload mechanics

The following analysis is from JFrog Security Research's primary publication, as characterized by Datadog Security Research. Primary-source artifact verification against the JFrog report is pending (Task #16).

Malicious code embedded in xinference/__init__.py executes a two-stage base64 decode chain on import:

• Stage 1 (SHA-256: 077d49fa708f498969d7cdffe701eb64675baaa4968ded9bd97a4936dd56c21c): base64-decoded Python stage that launches a credential collector and enumerates host context.
• Stage 2 (SHA-256: fe17e2ea4012d07d90ecb7793c1b0593a6138d25a9393192263e751660ec3cd0): the full credential collection and exfiltration logic.

Passive collection targets include SSH material, Git credentials, cloud credentials, Kubernetes service account tokens, Docker auth files, npm tokens, .env files, TLS private key artifacts, and infrastructure secrets. These are consistent with the litellm collection scope.

The distinguishing capability is active cloud API post-exploitation:

The payload does not just read credentials that are already present on disk. It actively queries the AWS Instance Metadata Service (IMDS) to retrieve temporary IAM credentials — credentials that exist only in memory on EC2 instances and ECS containers, not in credential files. It then uses those credentials to enumerate AWS Secrets Manager secrets and AWS Systems Manager Parameter Store parameters. This is post-exploitation behavior: the malware is not just stealing what's there, it's using what's there to go deeper.

The AWS post-exploitation scope matters operationally. A cloud environment running xinference in an ECS container or EC2 instance with an attached IAM role is exposed even if the developer has never written a credentials file to disk. The IMDS tokens are ephemeral by design — they expire, they rotate, they leave no local trace. Detection requires CloudTrail anomaly monitoring (unusual Secrets Manager list/get operations from the instance profile), not filesystem artifact hunting.

Exfiltration is via HTTP to whereisitat[.]lucyatemysuperbox[.]space. JFrog notes the domain style differs from litellm's typosquat (models.litellm[.]cloud). The exfil domain is not attempting to impersonate anything — it is operationally functional but not designed for egress log evasion. This may indicate the operator prioritized speed over OPSEC for this campaign.

Self-attribution: four-step analysis

Observation: JFrog found the string # hacked by teampcp in the decoded xinference payload. This is the same attribution pattern as the tpcp.tar.gz archive name in litellm (March 24) — the operator embeds campaign identifiers directly in payload artifacts.

Mechanism: A self-attribution comment string in decoded payload is a deliberate operator choice, not an accident. The operator is labeling their work for internal tracking and (arguably) public credit at disclosure. The consistency of attribution markers across litellm (tpcp.tar.gz), xinference (# hacked by teampcp), and CanisterWorm (Technique: .pth file injection (TeamPCP/LiteLLM method)) indicates systematic self-attribution practice, not occasional tagging.

Inference: The same operator is responsible for all three attribution-marked payloads. The xinference compromise is a TeamPCP campaign. Attribution confidence is confirmed — Layer 1 evidence exists in the payload artifact rather than relying on infrastructure or toolchain overlap.

Confidence bound: This inference is robust against alternative explanations. The only realistic alternative is that a different actor deliberately injected TeamPCP attribution markers to cause misattribution. This is possible but requires intentional effort and would be unusual for a financially motivated actor operating in the supply-chain space. JFrog's primary analysis is the verification source (Task #16).

Indicators of compromise

Compromised versions:

• xinference==2.6.0 — malicious
• xinference==2.6.1 — malicious
• xinference==2.6.2 — malicious

File hashes (SHA-256, from JFrog):

• xinference/__init__.py: e1e007ce4eab7774785617179d1c01a9381ae83abfd431aae8dba6f82d3ac127
• Decoded stage 1: 077d49fa708f498969d7cdffe701eb64675baaa4968ded9bd97a4936dd56c21c
• Decoded stage 2: fe17e2ea4012d07d90ecb7793c1b0593a6138d25a9393192263e751660ec3cd0

Network indicator (defanged):

• whereisitat[.]lucyatemysuperbox[.]space — exfiltration endpoint; any outbound connection to this domain is evidence of active data collection

Campaign self-attribution (Layer 1):

• # hacked by teampcp comment string in decoded payload (identified by JFrog)

CloudTrail indicators (AWS post-exploitation):

• Unexpected secretsmanager:ListSecrets or secretsmanager:GetSecretValue API calls from an EC2 or ECS instance profile not normally accessing Secrets Manager
• Unexpected ssm:DescribeParameters or ssm:GetParameter calls from the same source
• IMDS query from a process that is not the expected application workload

Detection and mitigation

• Check hashes immediately. Hash xinference/__init__.py in every installed environment. The JFrog SHA-256 (e1e007ce4eab7774785617179d1c01a9381ae83abfd431aae8dba6f82d3ac127) is a reliable match for the malicious version — it is a stable artifact unlike the ephemeral IMDS credentials collected by the payload.
• Treat IMDS enumeration as the worst-case scope. Any environment running xinference on EC2 or ECS with an attached IAM role should be investigated for post-exploitation activity. If the instance profile had Secrets Manager or SSM access, assume those secrets are compromised regardless of whether credential files were present on disk.
• Query CloudTrail for anomalous Secrets Manager and SSM calls. The AWS post-exploitation enumeration will appear in CloudTrail. Search for ListSecrets and GetSecretValue calls from the instance or task role during the April 22 window. Unexpected calls from a role that does not normally access Secrets Manager are confirmation of post-exploitation activity.
• Block whereisitat[.]lucyatemysuperbox[.]space. This domain has no legitimate use. Block at the DNS and egress firewall layer.
• Rotate all accessible credentials from affected environments. The collection scope spans SSH keys, Git tokens, cloud credentials, Kubernetes service account tokens, npm tokens, and TLS private keys. Treat any environment that imported the malicious xinference versions as fully compromised.
• Implement IMDS access controls. If your compute infrastructure does not require broad Secrets Manager or SSM access from application roles, apply IAM least-privilege constraints that would fail or alert on these enumeration calls. This is the structural defense against the post-exploitation pattern, not just this specific payload.

Attribution and cluster position

Xinference is the second confirmed PyPI victim in the TeamPCP cluster following litellm (March 24), and the first to document active AWS post-exploitation rather than passive credential collection. The attribution confidence is the highest in the cluster — # hacked by teampcp is unambiguous Layer 1 evidence.

The C2 domain style (whereisitat[.]lucyatemysuperbox[.]space) is operationally less sophisticated than litellm's typosquat approach. This could indicate a different operator sub-team handling the xinference deployment, or simply that the operator's OPSEC priority varied between campaigns. The cluster article (Task #10) should include the domain style variation as an open question rather than claiming consistency.

See the TeamPCP campaign tracking and the npm supply-chain worm cluster analysis for the full campaign timeline and cross-ecosystem technical analysis.

Criminal-market signal

No dark-web presence for TeamPCP tooling, xinference-specific payloads, or the whereisitat[.]lucyatemysuperbox[.]space infrastructure has been observed. The confirmed operator-run, credential-collection pattern documented across the TeamPCP cluster applies. The AWS post-exploitation adds scope but does not change the monetization model assessment — an actor actively enumerating Secrets Manager is using the credentials directly, not selling them on commodity markets where that capability would be unnecessary. Detection must occur at the package import layer and CloudTrail layer, not via dark-web early warning (H2 operator-run pattern, confirmed three-campaign basis).