PCPJack is a new credential theft framework targeting exposed cloud services (Docker, Kubernetes, Redis, MongoDB, RayML, vulnerable web applications). It not only massively steals access to cloud, container, development, office, and financial services, but also deliberately deletes artifacts related to the TeamPCP group, effectively “evicting” competitors from compromised environments. Owners of cloud infrastructure need to immediately inventory exposed services, strictly restrict access to instance metadata, and check systems for traces of automated installation scripts and the Sliver tool.

Technical details of PCPJack

The published analysis describes a complete, modular toolset operating in several stages and focused on cloud infrastructure.

Initial access and environment preparation

The attack starts with a bootstrap shell script that:

• prepares the runtime environment and configures the host for subsequent downloads;
• downloads the next stage of tools (including six Python scripts);
• attempts to infect the attacker’s own infrastructure (indicating some “worm-like” traits);
• detects and stops processes and deletes artifacts associated with TeamPCP;
• installs Python and sets up a persistence mechanism;
• launches the orchestration Python script and then deletes itself, minimizing traces.

Propagation targets are exposed and/or misconfigured:

• cloud services and instances;
• Docker and Kubernetes environments;
• Redis and MongoDB data storage services;
• the RayML platform and vulnerable web applications.

Orchestration and use of Common Crawl

A key feature: the worm’s orchestrator obtains its target list not from its own scanner, but from parquet files downloaded directly from the public Common Crawl dataset. This makes it possible to:

• scale the campaign using ready-made mass lists of domains and URLs;
• offload part of the internet “crawling work” onto a legitimate project;
• disguise the target selection logic as routine work with open data.

This approach aligns well with technique T1595 (Active Scanning), but with a reliance on external threat intelligence sources.

Credential theft and success metrics

The framework systematically collects:

• system information from the victim;
• credentials for cloud, container, development, office, and financial services;
• individual “successful” events, including a special “PCP replaced” field sent to the command-and-control (C2) server, indicating whether TeamPCP was successfully displaced from the host.

The behavior model maps to techniques MITRE ATT&CK T1552 (Unsecured Credentials) and T1555 (Credentials from Password Stores): a systematic sweep of secret sources in cloud and container environments.

Additional check.sh script and Sliver

On the operator’s infrastructure, researchers found an additional shell script, check.sh, which:

• determines the CPU architecture and downloads the corresponding Sliver binary — a well-known multiplatform command-and-control framework whose source code is available in the Sliver repository on GitHub;
• scans the Instance Metadata Service (IMDS) in cloud environments;
• enumerates Kubernetes service accounts;
• analyzes Docker environments in search of configurations and tokens.

The goal is to extract credentials and tokens related to:

• Anthropic, OpenAI, Google API;
• Digital Ocean, Grafana Cloud, HashiCorp Vault;
• Discord, OnePassword, and other services.

All discovered secrets are sent to an external server for command, control, and storage of the stolen data.

Indicators of Compromise (IOC) are not provided in the original report, so detection currently relies on behavioral signs and artifacts (bootstrap/check.sh scripts, Sliver network activity, access to Common Crawl).

Threat context and link to TeamPCP

Researchers note substantial overlap between PCPJack’s targets and those of the earlier TeamPCP group, which actively exploited vulnerabilities (including React2Shell) and configuration errors in cloud services to build a distributed host network for subsequent data theft and other post-compromise activities.

Key differences between PCPJack and TeamPCP:

• no cryptocurrency mining — unlike the earlier campaign, the new framework explicitly removes miner functionality previously used by TeamPCP;
• a focus on credential theft and monetization via fraud, spam, extortion, or resale of access, rather than direct mining;
• anti-competitive behavior: explicit removal of TeamPCP processes and artifacts and collection of “PCP replaced” telemetry, showing that the goal is not just mass infection but replacement of competing infrastructure.

Researchers suggest that similarities in codebase and tactics may indicate a possible link to a former TeamPCP member, but this remains an assessment: there is no confirmed technical attribution.

Impact assessment and risk profile

The most vulnerable organizations are those that:

• run publicly accessible Docker/Kubernetes/Redis/MongoDB without strict authentication policies and network segmentation;
• use the Instance Metadata Service with default settings, without restrictions and proxy layers;
• store sensitive tokens (API keys for Anthropic, OpenAI, Google API, Grafana Cloud, Digital Ocean, HashiCorp Vault, etc.) in environment variables, container configuration files, or Kubernetes service accounts;
• have long-lived or non-expiring access tokens without rotation.

Potential consequences of a successful attack include:

• compromise of the supply chain and development processes — access to repositories, CI/CD, secrets in Vault and password managers;
• compromise of customer data through access to databases, monitoring dashboards, and storage systems;
• secondary misuse of credentials: spam campaigns, attacks on third parties, extortion, fraud involving financial services;
• reputational and regulatory risks if stolen keys are used to attack external customers or partners.

Special attention should be paid to the depth of access provided by tokens for providers such as Anthropic or OpenAI: uncontrolled resource consumption, theft of internal prompts and configurations, and potential abuse of data sent to the models.

Practical defense recommendations

1. Reducing the attack surface in cloud and container environments

• Inventory all publicly accessible services (Docker API, Kubernetes API, Redis, MongoDB, RayML, administrative interfaces of web applications).
• Disable anonymous and “default” access, and close unnecessary ports at the cloud firewall and security group levels.
• Strictly limit access to the Kubernetes API and Docker socket to authenticated channels only.

2. Protecting the Instance Metadata Service and service accounts

• Restrict access to IMDS (for example, only from trusted services/sidecar proxies) and minimize the use of metadata to obtain long-lived tokens.
• Review Kubernetes service account permissions, remove excessive privileges, and follow the principle of least privilege.
• Configure network policies in the cluster so that containers cannot arbitrarily access IMDS and the Kubernetes API.

3. Managing secrets and tokens

• Move API keys (Anthropic, OpenAI, Google API, Digital Ocean, Grafana Cloud, HashiCorp Vault, OnePassword, etc.) out of environment variables and static configurations into dedicated secrets management systems.
• Enable token rotation, especially for highly privileged and non-expiring keys.
• Implement monitoring for anomalous key usage at providers (spikes in requests, new geographies, atypical usage patterns).

4. Detecting PCPJack and related activity

• Search logs and file systems for traces of unknown shell scripts, especially those exhibiting behavior such as “downloading Python, setting up persistence, self-deletion.”
• Monitor at the network level for:
  • unusual access to Common Crawl (downloading parquet files containing large domain lists);
  • connections and traffic characteristic of Sliver (C2 patterns, mutual TLS, unusual command domains).
• Use known Sliver detections and MITRE-aligned rules (for example, for techniques T1105 (Ingress Tool Transfer) and T1552/T1555) in SIEM and IDS/IPS.

5. Response and prioritization

• High priority (timeline — days, not weeks): close exposed Docker/Kubernetes/Redis/MongoDB/IMDS endpoints, review tokens and keys for the listed services, and check for the presence of Sliver and suspicious shell scripts.
• If compromise is detected:
  • immediately revoke and rotate all potentially compromised keys and tokens;
  • rebuild heavily affected instances from trusted images with a new secret base;
  • conduct a retrospective log analysis to identify actions performed with stolen credentials.

The key takeaway: PCPJack illustrates a shift away from crude cryptomining toward more profitable and stealthy monetization via theft of cloud and API credentials. In the near term, security teams should prioritize closing exposed Docker/Kubernetes/IMDS points, immediately reviewing and rotating tokens for cloud and AI services, and implementing behavioral monitoring to detect anomalous access to metadata and Sliver execution.