Executive summary
SentinelLABS reported PCPJack on 7 May 2026, describing a credential-theft framework that spreads through exposed cloud services and removes artefacts associated with TeamPCP. The researchers found two toolsets on the same staging server, including a modular Python framework and a separate credential harvester that deploys Sliver beacons. We assess it is likely (B2) that a response confined to deleting the initial script will miss consequential exposure, because the analysed tools target credentials and connected services as well as the infected host.
Contextual background
SentinelLABS says it located the initial script on 28 April 2026 through a Kubernetes-focused hunting rule. The script’s deliberate removal of TeamPCP-related processes and files prompted the PCPJack name. Later-stage analysis showed credential theft and propagation, so the removal behaviour was not evidence of a benign clean-up operation.
The researchers suggest that an operator familiar with TeamPCP’s tooling could be involved, but explicitly state that they have no evidence establishing an association. PCPJack should therefore remain the name of the reported toolset and activity, not an asserted identity for a former TeamPCP member. Shared targets and awareness of another group’s artefacts do not establish common ownership.
The report found no cryptocurrency miners in either analysed toolset. That is a bounded observation about the material examined. The credential targets suggest possible fraud, spam, resale of access or extortion, but the report does not establish that every such outcome occurred. Incident communications should distinguish the stolen access an organisation can demonstrate from possible ways an attacker could monetise it.
Technical analysis: the first toolset
The initial Linux script, bootstrap.sh, prepares a working directory at /var/lib/.spm/, removes selected TeamPCP artefacts and obtains Python dependencies and six modules. The downloaded worm.py becomes monitor.py locally, while other modules handle credential parsing, movement, encryption, cloud address ranges and external scanning. These renamed files explain why searching only for the original download names can miss installed components.
Persistence depends on privileges. SentinelLABS describes a sys-monitor.service systemd service when the bootstrap runs as root, and cron entries when it does not. The main script also presents itself as a monitoring utility while gathering system and credential information. Our recommendation is to relate a service’s executable, working directory and creation event to its approved purpose rather than trusting a plausible service name.
The local collection logic targets configuration files, environment variables, SSH material, cloud credentials, Kubernetes service-account tokens, Docker secrets and cryptocurrency-related files. It also searches repository history for deleted secrets. These are capabilities identified in the analysed code; the presence of a target in the code does not prove that the corresponding service or credential existed on a particular victim.
The framework uses Telegram for command-and-control and exfiltration. SentinelLABS describes encryption of stolen credential data, with a plaintext fallback when the required cryptography library is unavailable. During the researchers’ testing, the Telegram API rejected the bot token even though the malware remained hosted and distributed. That limited observation should not be read as proof that every affected installation failed to send data.
Propagation and connected services
SentinelLABS identifies Docker, Kubernetes, Redis, MongoDB, RayML and vulnerable web applications as targets. Internal movement and external scanning are related but distinct parts of the framework. Its cloud-range component obtains provider address ranges, while another path uses hostnames from Common Crawl data. Those legitimate infrastructure and data services are not, by themselves, malicious indicators.
The Kubernetes routines look for service-account access, enumerate resources and attempt to read secrets or execute commands where permissions allow. The report also describes attempts to reach host resources through a container. Our recommendation is to evaluate the actual service-account permissions and cluster configuration: a capability in the script is not proof that the target’s authorisation policy permitted it.
Docker access is sought through local sockets and reachable management services. Redis, RayML and SSH provide additional movement or persistence paths in the analysed framework. For the external-scanning component, SentinelLABS distinguishes Docker, Redis and RayML infection logic from Kubernetes and MongoDB paths used for credential harvesting without established persistence. Preserve that distinction when deciding what to investigate on each service.
The report also lists web-application vulnerabilities in the propagation code. This article does not reproduce their version ranges or exploit instructions. Our recommended response is to identify the actual exposed applications in the affected environment and validate their patch state against their own vendors’ advisories, rather than assume every service in the malware’s target list was successfully exploited.
The second toolset
On the same delivery server, SentinelLABS found a separate check.sh toolset. It selects a Sliver binary for the system architecture, stores it locally as /var/tmp/apt-daily-upgrade and collects credentials through shell and Python components. The researchers describe builds for 64-bit Intel, 32-bit Intel and ARM systems. This is separate tooling, not another name for every Python component in the first framework.
The second toolset sends collected data to the lookalike domain cdn[.]cloudfront-js[.]com, using a path ending in /u, and attempts further SSH movement before deleting the initial script. The domain imitates CloudFront naming but is distinct from the legitimate service. Investigate the exact domain and associated process context instead of treating all CloudFront traffic as evidence of compromise.
The Sliver binaries use obfuscation, but the researchers identified protocol strings and other implementation details supporting their classification. That finding describes the analysed samples. It should not be converted into an assertion that every Sliver detection belongs to PCPJack or that different builds necessarily share one developer.
Selected indicators and hunting leads
The following artefacts come from the SentinelLABS analysis. They support a contextual hunt, not a claim that any one file name proves compromise.
| Artefact | Reported role | Investigation context |
|---|---|---|
/var/lib/.spm/ |
First toolset working directory | Review contents, creation time and launching service or job |
monitor.py and utils.py |
Orchestration and credential parsing | Common names require content and path validation |
harvest.jsonl |
Collected credentials used by the framework | Preserve securely; avoid copying secrets into routine tickets |
sys-monitor.service |
Bootstrap persistence when running as root | Compare service configuration with authorised monitoring |
/var/tmp/apt-daily-upgrade |
Sliver deployment path in the second toolset | Check the executable and process ancestry |
cdn[.]cloudfront-js[.]com |
Second toolset command-and-control destination | Match exact domain and correlate with endpoint events |
The report also lists IP addresses embedded in the bootstrap’s exclusion list. SentinelLABS cautions that their relationship to the operator deserves scrutiny. Our recommendation is to retain that uncertainty rather than promote every excluded address into a confirmed command-and-control endpoint.
Detection and hunting guidance
Our recommended hunt connects host execution to service access. Start with the working directories, persistence entries, scripts and outbound destinations, then identify which credentials the executing account could read. Follow the audit trail in each connected service for unexpected authentication, new workloads, secret access or administrative changes.
Review both current files and retained execution history. The analysed bootstrap and second-stage installer can delete themselves, so absence of the installer is weaker evidence than a complete execution record. Similarly, deletion of TeamPCP artefacts may complicate reconstruction of an earlier intrusion. Preserve evidence of both activities where present instead of assuming the newer tool removed all prior risk.
Separate ordinary administration from suspicious combinations. Python modules, monitoring services and access to cloud APIs all have legitimate uses. A new service launching scripts from an unexpected directory, followed by secret reads and unexplained connections to other management services, provides a stronger investigation lead than any isolated name.
Incident response guidance
Our recommended containment begins with the affected host and the management paths that enabled movement. Preserve relevant logs and samples, isolate confirmed compromised systems according to the response plan, and restrict unauthorised access to exposed services. Removing persistence without closing the reachable management interface can leave a straightforward reinfection path.
Map credentials to services and permissions before recovery. Prioritise revocation or rotation according to the authority exposed, then review actions already performed with that authority. A cloud key, repository token and SSH private key can require different response procedures. Carry unanswered questions about use or exfiltration into the incident record rather than treating every rotated secret as proof of a completed investigation.
Recover through trusted configurations and software sources. Check service-account permissions, container definitions and scheduled jobs before reconnecting systems. Where the toolset attempted movement into other hosts, use successful authentication and execution evidence to expand scope. An attempted connection and a confirmed secondary infection should remain separate findings.
Mitigation recommendations
Docker’s security guidance describes protecting daemon access with SSH or TLS and treating client credentials with appropriate care. Our recommendation is to inventory every route to the daemon, including local socket mounts granted to workloads. Restricting an external port does not answer whether an already running container has excessive management access.
Redis’s security documentation explains the role of network restrictions, authentication and access controls. Apply those controls to the actual deployment and verify them from the relevant network position. Do not rely on a service being intended for internal use when its effective exposure has not been checked.
Our additional priorities are to reduce unnecessary secrets in workload files, narrow service-account permissions and retain provider-side audit logs. Test the recovery process for an exposed credential and the ability to identify every service it can reach. These controls address the credential-driven consequences described in the report even where the initial intrusion path differs.
Our recommended closure record should identify the original service exposure, the host recovery evidence and the disposition of each consequential credential. Assign unresolved downstream checks to the service owner who can inspect the relevant audit trail. This prevents endpoint recovery from becoming an unsupported declaration that every connected account is safe.
Threat intelligence context and outlook
Our ATT&CK mappings are T1552.001: Credentials In Files, T1053.003: Cron and T1543.002: Systemd Service. They reflect credential collection and persistence in the analysed tools, not additional observations about victims.
The operational priority is to follow access beyond the first infected machine. Maintain separate conclusions for confirmed execution, exposed credentials, observed downstream use and unresolved gaps. That approach supports recovery without relying on an unproven operator identity or treating the absence of cryptomining as evidence of a low-impact intrusion.
