Executive Summary

• SentinelLABS has identified PCPJack, a credential theft framework that worms across exposed cloud infrastructure and removes artifacts associated with TeamPCP,  a threat actor persona who claimed several high-profile supply chain intrusions throughout early 2026.
• The toolset harvests credentials from cloud, container, developer, productivity, and financial services, then exfiltrates the data through attacker-controlled infrastructure while attempting to spread to additional hosts.
• PCPJack targets exposed services including Docker, Kubernetes, Redis, MongoDB, RayML, and vulnerable web applications, enabling both external propagation and lateral movement inside victim environments.
• Unlike typical cloud-focused malware, PCPJack does not deploy cryptominers; the services it targets suggest monetization through credential theft, fraud, spam, extortion, or resale of stolen access.

Overview

On 28 April 2026, SentinelLABS located a script through a Kubernetes-focused VirusTotal hunting rule that stood out from known cloud hacktools: the script’s first actions are to evict and delete tools associated with the TeamPCP attack group, leading us to call the toolset PCPJack. Analyzing this script led us to discover a full framework dedicated to cloud credential harvesting and propagating onto other systems, both internal and external to the victim’s environment.

TeamPCP stood out in early 2026 following the group’s February compromise of Aqua Security’s Trivy vulnerability scanner. The incident enabled several downstream attacks, including the compromise of LiteLLM, an open-source library that routes requests across widely used LLM providers. TeamPCP also announced a partnership with the VECT ransomware group to monetize the data stolen through their cloud environment attacks.

Many of the services targeted by the PCPJack framework are similar to the early TeamPCP/PCPCat campaigns from December 2025, before the high-visibility campaigns of early 2026 brought significant attention to TeamPCP and purportedly led to changes in group membership. We believe this could be a former operator who is deeply familiar with the group’s tooling.

The types of credentials collected by the framework suggest PCPJack’s targeting motivations are primarily to conduct spam campaigns and financial fraud, or to simply monetize stolen credentials to actors with these focuses. The inclusion of enterprise productivity software like Slack and business database services expands the focus to extortion attacks. Notably, neither of the two toolsets we identified from the attacker’s staging server performed any cryptocurrency mining, a stark departure from typical multi-disciplinary cloud attack campaigns.

First Toolset | bootstrap.sh & Python Worms

The infection begins with bootstrap.sh, a shell script designed for Linux systems. This script serves only to set up the environment and download additional payloads. bootstrap.sh sets several key variables, including PAYLOAD_HOST, which is set to hxxps://spm-cdn-assets-dist-2026[.]s3[.]us-east-2[.]amazonaws[.]com, a legitimate Amazon Simple Storage Service (S3) resource that was likely registered by the attacker for unauthorized purposes.

The main functionality of bootstrap.sh is:

1. Create /var/lib/.spm/ working directory
2. Check public IP against operator’s blocklist: this prevents the attacker from infecting their own infrastructure
3. Find and remove processes or artifacts that match naming conventions referencing TeamPCP or PCPcat process list, services, paths, or containers
4. Install Python 3.6+ via available package manager: apk, apt, dnf, pacman, yum or zypper
5. Create a Python virtual environment and install requests, cryptography, and pyarrow
6. Download six Python modules from the attacker’s S3 URL in the following order: worm.py, parser.py, lateral.py, crypto_util.py, cloud_ranges.py, cloud_scan.py
7. Rename modules to their on-disk names (see the list of downloaded payloads below)
8. Establish persistence:
   1. If run as root: create sys-monitor.service, which runs monitor.py, aka worm.py, an orchestrator script
   2. If not root, create two crontabs: one runs every 5 minutes to check if monitor.py is running, the other starts monitor.py if it is not running
9. Launch monitor.py
10. Self delete using rm -f "$0"

The following table itemises the downloaded payloads:

The logic targeting TeamPCP files stands out: each of the artifacts has been associated with TeamPCP in public reporting, though BORING_SYSTEM is mentioned only sparsely. We initially considered that this toolset could be a researcher removing TeamPCP’s infections. However, analysis of the later-stage payloads indicates otherwise. When exfiltrating system information and credentials, the PCPJack operator even collects success metrics on whether TeamPCP has been evicted from targeted environments in a “PCP replaced” field sent to the C2.

Infection Flow

The infection begins with bootstrap.sh, which executes the orchestrator script, monitor.py (aka worm.py). The orchestrator imports a set of purpose-built modules for credential parsing (utils.py), lateral movement (_lat.py), C2 message encryption (_cu.py), cloud IP range lookups (_cr.py), and cloud scanning (_csc.py).

Rather than let the modules find their own dependencies, the orchestrator injects them at runtime with shared references, ensuring all components operate with the same credential and movement handles without hardcoding inter-module imports.

The scanning module, _csc.py, receives the lateral movement engine, the cloud range lookup function, and the credential parser all via injection from the worm. This design keeps each module independently minimal while the orchestrator alone holds the full dependency graph, making the framework harder to analyze in isolation. No single imported file reveals the complete picture without visibility into monitor.py.

Sensitive strings are stored in the source code as a hex-encoded blob instead of clear text. When a script runs, it obtains the actual value by calling function _d(), which is near the top of each Python module, against the encoded hex string containing the sensitive content.

The function decrypts it by XORing each byte against the MD5 hash of the string urllib3.poolmanager, a name chosen to look like a reference to a common Python web library. PCPJack’s author encrypted the constants that would immediately identify the malware’s infrastructure. Despite this, the actor failed to encrypt the Telegram bot token in bootstrap.sh and the credential decryption key in crypto_util.py, so the operational security awareness only goes so far.

monitor.py | Orchestrator Script

The monitor.py script, which was hosted on the attacker’s staging server as worm.py and had persistence established by bootstrap.sh, is the main script driving the toolset. The script starts with logic designed to make the script appear like a benign system monitoring utility that collects metrics about the system.

While this is valuable information for the attacker, we believe it is an attempt to help the script blend in if spotted by an administrator, given that the posted information also includes data about the types of systems being targeted by the toolset.

Local Credential Theft

On each compromised host, monitor.py executes a shell pipeline that steals:

• .env files and config files
• Environment variables filtered for secrets, API keys, DB & SMTP creds
• SSH private keys and targets from known_hosts, ~/.ssh/config, and bash history
• AWS IMDS credentials
• Kubernetes service account tokens
• Docker secrets (/run/secrets/)
• Cryptocurrency wallets (wallet.dat files, Ethereum keystores, Solana keys)

A separate scan walks the local /etc, /home, /opt, /root, /srv, /var/lib , and /var/www directories looking for config or secret files, and _mgr searches through git history for deleted secrets. The results are parsed by utils.py.

Target Selection & Propagation

After credential extraction, the command checks for prior installation (/var/lib/.spm/worm.py or /var/lib/.spm/monitor.py) and, if clean, downloads and executes bootstrap.sh from the C2 payload host.

Propagation targets come from parquet files that the worm downloads directly from Common Crawl, a legitimate web scan archival nonprofit with a rich history of furnishing AI models with vast amounts of training data harvested from the web. The URL is extracted from obfuscated variables _CI and _CB.

The tool picks parquet files containing url_host_name columns, and iterates through those hostnames. Each monitor.py node gets a window of parquet files based on the date or a seed index (SPM_SEED_IDX), which gives the attacker distributed coverage without central coordination. A deduplication set, variable _sh, is stored in memory to prevent re-scanning. This list is capped at 15 million entries.

This module spreads the toolset to targets by exploiting several vulnerabilities in web technologies, including the ubiquitous React2Shell flaw:

Command & Control

The framework uses Telegram for C2. An infected system posts data to one channel and checks another to receive commands from a pinned message. Most of the commands are self-explanatory. RUN downloads a module from the attacker’s payload storage, saves it as run_script.py, and executes the script. The PARQUET command gives the node a new index to parse from the parquet file, meaning the operator can manually override previously chosen attack ranges.

utils.py | Credential Extractor

This script handles credential extraction using regular expressions to identify and categorize stolen keys and secrets. The logic centers on a wide variety of online services, many of which pertain to bulk messaging services, cryptocurrency/FinTech, cloud or web application services.

Finance & Enterprise

SMTP & Bulk Messaging Services

Web & Cloud Services

Interestingly, the actor’s regular expression matching includes credentials for FTX, a crypto exchange that went bankrupt in a high-profile case in 2022. This suggests the actor adapted the matching logic from an older tool, or that it was inserted erroneously through LLM code generation.

lateral.py | Internal Network Lateral Movement

The lateral.py or _lat.py script performs reconnaissance on the infected system and the assets it connects to, enabling internal propagation. The script runs only once and writes a lateral_done file to the working directory; if that file is found, the script exits. This is likely to improve stealth and reduce the likelihood of network security alerts.

The Kubernetes spreading logic _lk checks for a Kubernetes service account token, which is present inside pods mounted in a cluster, then uses the service account to authenticate with the Kubernetes management API to enumerate namespaces and pods in the cluster. The script runs commands against each container to:

• Extract credentials from a list of file names and paths associated with secret stores
• Harvest SSH private keys
• Query the AWS Instance Metadata Service (IMDS); this works only in environments where IMDSv2 is not strictly enforced and goes against modern default configurations and best practices

_lk also reads Kubernetes Secrets and ConfigMaps directly via the API, base64-decodes their values, which works even when pod execution is denied by role-based access controls (RBAC). Lastly, it attempts a container escape by mounting the host filesystem to a new container, enabling the attacker’s tools to interact with the host system.

The Docker propagation function _ld checks for the local Docker socket at /var/run/docker.sock, then scans the network for services running on ports 2375 or 2376. When found, the script connects to the Docker API through the management daemon, lists all running containers, and executes the same credential harvesting script as seen in the Kubernetes routine. If connected to a remote host, the spreader will bind-mount the root filesystem of the machine running the Docker management service to the remote instance’s /host path, which creates a container escape.

When Redis is found, _rec dumps the configuration, then calls the Redis KEYS command to scan database key names for secrets, passwords, tokens, and API keys, and GETs their values. For persistence, _rwc performs a Redis cron rewrite, resulting in a cron job that fires bootstrap.sh every 5 minutes as root.

lateral.py targets several other services running within the victim’s environment:

• RayML Clusters: scans port 8265, submits a Python job via the API to extract credentials and download bootstrap.sh
• MongoDB: scans port 27017, enumerates databases & extracts credentials

The SSH propagation module _ls searches SSH key store locations on the infected machine and parses  ~/.ssh/known_hosts, ~/.ssh/config, and .bash_history for username and host combinations. It then pulls SSH keys from harvest.jsonl, a file containing credentials found by other lateral movement techniques earlier. These combinations are tried against any hosts running SSH. On access, it runs bootstrap.sh on the remote machine to propagate the worm.

crypto_util.py | Data Encryption

PCPJack’s framework uses the crypto_util.py (aka _cu.py, imported as a module named _crypto) script to encrypt credentials. It is called by monitor.py to exfiltrate the encrypted data before it is sent to the attacker’s Telegram channel.

The encrypt_message function:

• Generates an X25519 keypair for each message chunk
• Performs ECDH against a hardcoded attacker public key set to variable _RPK = "6d4imqQ/s/GfQCVcybdcjfTe/PMYHtZN8ZGHnEXSbRo="
• Uses the raw shared secret directly as a ChaCha20-Poly1305 key to encrypt the data
• Splits output into 2800-byte chunks: the __main__ test block validates against Telegram’s 4096-character message limit
• Packs each encrypted chunk by concatenating the ephemeral public key (32 bytes), a random nonce (12 bytes), and the ciphertext, then base64-encodes the result and prepends a emoji

If the cryptography library is not installed, the function silently falls back to sending plaintext, meaning credentials may be exfiltrated unencrypted during some infections.

The decrypt_message function requires the private key corresponding to variable _RPK. The test keypair in __main__ (PRIVATE_KEY) is a matching test pair. If a researcher could access the attacker’s Telegram channel, there is a reasonable chance they could decrypt the stolen credentials sent to the channel. During our testing, the Telegram API responded that the bot token was invalid, although the malware was actively hosted and being distributed during this time.

cloud_ranges.py | Cloud Service Provider IPs

The cloud_ranges.py (aka _cr.py) module is relatively small and simple: it collects a list of IP addresses assigned to AWS, Azure, Cloudflare, Cloudfront, Fastly, and Google Cloud Platform (GCP). The approach is to query URLs from each provider that host information about the cloud service IP ranges, which change periodically.

This allows the attacker to avoid hardcoding IPs into the script which may be outdated. Once the information is retrieved, the cloud ranges are written to a file at /var/lib/.spm/_cr/ranges.json. The data is refreshed every 24 hours.

cloud_scan.py | External Propagation

The final module is cloud_scan.py (aka _csc.py), which scans external cloud services and attempts to propagate by looking for ports indicating exposed Docker, Kubernetes, MongoDB, RayML, or Redis services.

When a target responds on a matching port, cloud_scan.py scans the entire /24 subnet for the responding IP and runs infection logic imported from lateral.py.

For Docker, Redis, and RayML targets, this includes installing persistence via bootstrap.sh. Docker is targeted through a privileged container with host escape, Redis through cron injection, and RayML through a weaponized job submission.

Kubernetes and MongoDB targeting results only in credential harvesting. cloud_scan.py queries unauthenticated Kubernetes API endpoints to dump secrets and it scrapes MongoDB collections for credentials, but does not establish persistence.

Infrastructure

bootstrap.sh contains a hardcoded list of attacker infrastructure IPs excluded from targeting. Perhaps a nostalgic nod to the presumed retired cloud attack group TeamTNT, each of these IPs are VPS servers geolocated to Germany. Given the complex dynamics that could drive this attacker to focus on killing processes associated with TeamPCP activity, it is reasonable to scrutinize whether these IPs actually belong to the attacker behind PCPJack.

• 38.242.204[.]245
• 38.242.237[.]196
• 38.242.245[.]147
• 83.171.249[.]231
• 161.97.129[.]25
• 161.97.135[.]154
• 161.97.163[.]87
• 161.97.186[.]175
• 161.97.187[.]42
• 193.187.129[.]143
• 213.136.80[.]73

The IPs are relatively minimal in their online footprint, but the available data suggests management infrastructure and potentially different malicious activity. 38.242.245[.]147 has hosted lastpass-login-help[.]com, clearly a phishing domain to harvest LastPass master credentials: a motive that aligns with this toolsets heavy credential harvesting focus.

Second Toolset | Credential Harvester & Sliver Beacons

We also identified another toolset on the attacker’s payload delivery server unrelated to the previous one. The file check.sh is an 858-line shell script that handles everything before the beacon phones home. The script detects CPU architecture and pulls the matching Sliver binary: update.bin, update-386.bin, or update-arm.bin, depending on the system architecture.

The binary is saved locally as /var/tmp/apt-daily-upgrade to blend in with system processes. Simultaneously, check.sh sweeps IMDS endpoints, Kubernetes service accounts, Docker instances, and /proc/*/environ for credentials from 30+ services, many through a dropped Python script called  extractor.py.

Targets include many services covered by the bootsrap.sh framework, with several standout new additions: Anthropic, Digital Ocean, Discord, Google API, Grafana Cloud, HashiCorp Vault, OnePassword, and OpenAI keys.

The script then exfiltrates stolen data to hxxps://cdn[.]cloudfront-js[.]com:8443/u, a typosquatted domain mimicking CloudFront, over ports 443 or 8443. It finishes by SSH-spraying up to 10 lateral targets before self-deleting.

Sliver ELF Binaries

The update binaries are Sliver C2 beacons compiled with the garble obfuscation tool, which scrambles Go type names and removes build metadata to hinder signature-based detection. Despite the obfuscation, several indicators remained across the analyzed binaries: protobuf field tags (name=BeaconID), interface method names (GetC2URI, GetBeaconInterval), and multiple Sliver-specific RPC strings including PivotListener, PivotPeerEnvelope, WGSocksServer, and WGTCPForwarder among others.

The binaries form a deployment set: update.bin, the 64-bit variant, targets modern Intel-based cloud infrastructure and includes CPU feature detection for Intel Sapphire Rapids, a powerful processor present in many cloud environments.

update-386.bin is a 32-bit variant that serves as a capability-identical fallback for legacy servers or 32-bit containers.

update-arm.bin is designed for ARM processors. Interestingly, each of the binaries have different garble seeds, meaning they were compiled separately and hinders conclusive attribution to the same developer.

Conclusion

Overall, the two toolsets are well developed and indicate that the owner values making code as a modular framework, despite some redundancies in behavior. The occasional operational security lapses were interesting, particularly their choice to encrypt everything except for Telegram credentials and their own alleged infrastructure.

In the threat actor ecosystem, there is constant churn and turnover between groups: something TeamPCP alluded to before their main social media account was suspended.

We have no evidence to suggest whether this toolset represents someone associated with the group or familiar with their activities. However, the first toolset’s focus on disabling and replacing TeamPCP’s services implies a direct focus on the threat actor’s activities rather than pure cloud attack opportunism. There are plenty of other cloud credential harvesting campaigns which have other forensic artifacts that could be considered when performing a pre-installation cleanup early during an intrusion.

Compared to similar cloud threat actors, PCPJack stands out for its complete lack of cryptominers in all tooling we analyzed. Nearly all moderately-sophisticated cloud threat campaigns deploy XMRig or similar at some point, including several of TeamPCP’s campaigns. This campaign does not, and it deliberately removes the miner functions associated with TeamPCP. Desite that, this actor has well-defined scopes for extracting cryptocurrency credentials.

Mitigations and Recommendations

The impacts of PCPJack and similar toolsets range from data exposure and extortion to financial impacts of an attacker with access to high-limit, enterprise API services.

Organizations can defend against these threats by adhering to cloud and web application security best practices. Credential management will mitigate the majority of these credential harvesting techniques: use an enterprise-wide vault or secret management service and ensure access to those stores is never stored to a file saved in clear text.

Ensure that authentication mechanisms follow industry standards: require MFA from service accounts rather than an API key alone. In AWS environments, ensure that IMDSV2 is enforced across all services to prevent credential theft and consider allow-listing downloads only from approved S3 resources.

Even when systems are not exposed to the internet, ensure authentication is required to manage services like Docker and Kubernetes, as these are popular lateral movement targets which can enable much deeper access through connected nodes, and restrict scopes on Kubernetes service accounts to adhere to the principle of least privilege.

Indicators of Compromise

Domains

IP Addresses
The following IP addresses are hardcoded into bootstrap.sh and labelled as attacker infrastructure:

File Hashes | SHA-1

File System

HTTP Request Indicators

Strings

The post Broken by Design: How VECT 2.0 Ransomware Becomes a Permanent Data Wiper appeared first on Daily CyberSecurity.

CERT-EU says a European Commission cloud hack exposed data from 30 EU entities and links the breach to the TeamPCP group.

CERT-EU attributed a European Commission cloud breach to the TeamPCP threat group, revealing that data from at least 30 EU entities was exposed. The incident was publicly disclosed on March 27 after inquiries confirmed that the Commission’s Amazon cloud environment had been compromised.

On March 24, the European Commission detected a cyberattack affecting the cloud infrastructure hosting its Europa.eu websites. The incident was quickly contained, with mitigation measures applied and no disruption to website availability. Early findings suggested some data may have been accessed, and potentially affected EU entities are being notified. The Commission alerted CERT-EU two days before disclosure, noting no signs of compromise until March 24, five days after the initial breach.

“Early findings of our ongoing investigation suggest that data have been taken from those websites. The Commission is duly notifying the Union entities who might have been affected by the incident.” reads the press release published by the European Commission. “The Commission’s services are still investigating the full impact of the incident.  “

The EU has launched an investigation into the security breach to determine its full impact. However, the Commission initially pointed out that its internal systems were not affected, limiting the overall impact of the attack.

The Commission said its internal systems were not affected and will continue monitoring the situation while strengthening protections. It announced it will improve cybersecurity, as the EU faces ongoing cyber and hybrid threats targeting critical services and institutions.

BleepingComputer first reported the incident, claiming that threat actors breached the European Commission’s AWS account, stealing hundreds of gigabytes of data, including databases, and providing screenshots as proof.

“On March 25, CERT-EU received a notification from the European Commission that one of their AWS cloud accounts had been compromised. The first alerts, indicating potential misuse of Amazon APIs, potential account compromise, and an unusual volume of network traffic, had been detected by their Cybersecurity Operations Centre (CSOC) team the previous day.

An investigation uncovered that a malicious actor acquired an Amazon Web Services (AWS) secret (an API key) on March 19 through the Trivy supply chain compromise. This key granted control over other AWS accounts affiliated with the European Commission. On the same day, the threat actor attempted to discover additional secrets by launching TruffleHog, a tool commonly used for scanning secrets and validating AWS credentials by calling the Security Token Service (STS). STS is an AWS service that generates short-lived security credentials for accessing AWS resources and verifying identities.” reported CERT-EU. “The threat actor used the compromised AWS secret to create and attach a new access key to an existing user, aiming to evade detection. They then carried out reconnaissance activities.”

TeamPCP reportedly accessed the EU’s AWS environment on March 10 using a stolen API key from the Trivy supply-chain attack.

They then used tools like TruffleHog to find more credentials, created new access keys to stay hidden, and carried out reconnaissance and data theft. TeamPCP is also linked to supply-chain attacks on platforms like GitHub, PyPI, NPM, and Docker, including a compromised LiteLLM package used to spread data-stealing malware.

“The European Commission and CERT-EU have assessed with high confidence that the initial access vector was the Trivy supply-chain compromise, publicly attributed to TeamPCP by Aqua Security. The firm has provided comprehensive details on this compromise in its advisory.” continues CERT-EU.

“This assessment is based on three main factors:

• The timing of the Trivy supply-chain compromise coincides with the observed initial compromise on March 19.
• The specific resources being targeted: AWS credentials and cloud infrastructure.
• The European Commission was unwittingly using a compromised version of Trivy during the relevant timeframe, having received it through normal software update channels.”

On March 28, the ShinyHunters group published 350GB of stolen from the European Commission, containing emails, names, and usernames, dumps of mail servers, databases, confidential documents, contracts, and much more sensitive material.

CERT-EU confirmed tens of thousands of files were taken, affecting up to 71 Europa web hosting clients, including 42 Commission entities and at least 29 other EU bodies, using a compromised AWS credential.

“The threat actor used the compromised AWS secret to exfiltrate data from the affected cloud environment.” added CERT-EU. “The exfiltrated data relates to websites hosted for up to 71 clients of the Europa web hosting service: 42 internal clients of the European Commission, and at least 29 other Union entities.”

Analysis shows the leaked dataset includes personal data such as names, usernames, and email addresses, mainly from European Commission websites but possibly affecting multiple EU entities. It also contains over 51,000 outbound email files, mostly automated, though some bounce-back messages may expose user-submitted content, increasing the risk of data exposure.

“The analysis of the databases linked to the hosted websites is underway. Given the volume and intricate nature of the data involved, this process requires a considerable amount of time.” concludes CERT-EU.

Summarizing, a compromised AWS account tied to the europa.eu hosting service exposed data from 42 European Commission clients and at least 29 other EU entities. Despite the breach, no websites were disrupted or altered. The Commission has notified affected parties and, with CERT-EU, continues investigating and will share further findings as they emerge.

On 30 January, the European Commission detected another cyberattack on its mobile device management system. The organization pointed out that no mobile devices were compromised. The Commission contained and cleaned the system within nine hours.

Attackers may have accessed some staff data, including names and phone numbers, but so far they have not compromised any devices.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CERT-EU)

Company Background and Scale of Operations 

Response to the Mercor Cyberattack

Origins of the LiteLLM Security Incident 

Ongoing Investigation and Unanswered Questions 

Overview Recently, NSFOCUS Technology CERT detected that the GitHub community disclosed that there was a credential stealing program in the new version of LiteLLM. Analysis confirmed that it had suffered supply chain poisoning by the TeamPCP group on PyPI. It stole the publishing permission credentials by hacking into the security scanning tool Trivy used in […]

The post AI Infrastructure LiteLLM Supply Chain Poisoning Alert appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

The post AI Infrastructure LiteLLM Supply Chain Poisoning Alert appeared first on Security Boulevard.

TeamPCP backdoored LiteLLM v1.82.7–1.82.8, likely via Trivy CI/CD, adding tools to steal credentials, move in Kubernetes, and keep persistent access.

Threat actor TeamPCP compromised LiteLLM versions 1.82.7 and 1.82.8, likely through a Trivy CI/CD breach. LiteLLM, with over 95 million monthly downloads, helps developers route LLM requests via a single API.

The malicious releases, now removed from PyPI, included a multi-stage payload: a credential harvester targeting SSH keys, cloud data, wallets, and .env files; tools for lateral movement in Kubernetes via privileged pods; and a persistent systemd backdoor connecting to a remote server for further payloads.

On March 24, 2026, Endor Labs discovered that LiteLLM versions 1.82.7 and 1.82.8 on PyPI were backdoored, despite no malicious code in the GitHub repo.

The compromised versions execute a hidden payload on import, while v1.82.8 also installs a .pth file to trigger it on any Python run. Version 1.82.6 remains the last safe release.

The malware launches a three-stage attack: stealing credentials (SSH keys, cloud tokens, Kubernetes secrets, wallets, .env files), spreading across Kubernetes clusters via privileged pods, and installing a persistent systemd backdoor that fetches more payloads. Attackers encrypted stolen data before exfiltrating it. The campaign is linked to TeamPCP, already tied to attacks across multiple ecosystems including GitHub Actions, Docker Hub, npm, OpenVSX, and PyPI.

“The malicious code resides in a single file within the litellm wheel distributed on PyPI: litellm/proxy/proxy_server.py. The attacker inserted 12 lines at line 128, between two unrelated legitimate code blocks (the REALTIME_REQUEST_SCOPE_TEMPLATE dictionary and the showwarning function).” reads the report published by Endor Labs. “The GitHub source at the corresponding commit does not contain these lines — the injection was performed during or after the wheel build process.”

The malicious code was hidden inside the LiteLLM PyPI package, specifically in proxy_server.py, where 12 malicious lines were inserted during or after the wheel build.

This code runs automatically when the module is imported, silently decoding and executing a payload. It avoids detection by using subprocess calls instead of flagged methods like exec().

Version 1.82.8 adds a more dangerous method: a .pth file that executes the payload on every Python startup, even if LiteLLM is never used. It runs in the background, making detection harder and spreading impact across any Python process in that environment.

“This makes 1.82.8 significantly more dangerous: any Python script, test runner, or tool invoked in an environment where litellm is installed will silently trigger the credential harvester in the background.” continues the report.

The malware works in three stages. First, it launches an orchestrator that collects and encrypts stolen data before sending it to a remote server. Second, a credential harvester scans the system for sensitive data, including SSH keys, cloud credentials, Kubernetes secrets, environment files, databases, wallets, and system logs. It can also move laterally by deploying privileged pods across Kubernetes nodes.

Finally, it installs a persistent backdoor as a systemd service that regularly contacts a remote server, downloads new payloads, and maintains long-term access while blending in with normal system processes.

The malicious code reveals three development stages left in the package as commented base64 blobs. The first version used exec() and basic obfuscation, already targeting credentials and using the same C2 and persistence. The second included both old and new harvester code, showing a transition phase. The final version refined delivery, replacing exec() with subprocess techniques to evade detection, while keeping the same targets and infrastructure.

The malware uses two C2 domains: one to receive encrypted stolen data and another to deliver additional payloads. Its obfuscation relies on multiple nested base64 layers and standard library code to appear harmless. Stolen data is protected with RSA+AES encryption, and the package was rebuilt with valid hashes, making detection difficult without comparing it to the original source.

Endor Labs attributes the attack to TeamPCP with high confidence, citing strong overlaps with earlier incidents reported by Wiz. Key indicators match exactly, including the same C2 domain (checkmarx.zone), identical persistence files (sysmon.py and sysmon.service), the “System Telemetry Service” name, 50-minute beaconing, the same kill switch logic, and the tpcp.tar.gz exfiltration archive. Encryption methods and Kubernetes persistence techniques are also consistent.

Timeline data supports this attribution, the researchers reported that the malicious LiteLLM versions were released shortly after the KICS compromise, with rapid iteration between versions.

TeamPCP repeatedly leverages stolen credentials to pivot across ecosystems, targeting security tools to maximize access to sensitive data and infrastructure.

“This campaign is almost certainly not over. TeamPCP has demonstrated a consistent pattern: each compromised environment yields credentials that unlock the next target.” concludes the report. “The litellm compromise is the latest escalation in a month-long campaign that began with a single incomplete incident response. On February 28, an autonomous bot exploited a workflow vulnerability in Trivy and stole a PAT. Aqua remediated the surface-level damage but left residual access. Three weeks later, TeamPCP leveraged that opening — and in five days crossed five supply chain ecosystems: GitHub Actions, Docker Hub, npm, OpenVSX, and now PyPI.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, TeamPCP)

A financially motivated data theft and extortion group is attempting to inject itself into the Iran war, unleashing a worm that spreads through poorly secured cloud services and wipes data on infected systems that use Iran’s time zone or have Farsi set as the default language.

Experts say the wiper campaign against Iran materialized this past weekend and came from a relatively new cybercrime group known as TeamPCP. In December 2025, the group began compromising corporate cloud environments using a self-propagating worm that went after exposed Docker APIs, Kubernetes clusters, Redis servers, and the React2Shell vulnerability. TeamPCP then attempted to move laterally through victim networks, siphoning authentication credentials and extorting victims over Telegram.

A snippet of the malicious CanisterWorm that seeks out and destroys data on systems that match Iran’s timezone or have Farsi as the default language. Image: Aikido.dev.

In a profile of TeamPCP published in January, the security firm Flare said the group weaponizes exposed control planes rather than exploiting endpoints, predominantly targeting cloud infrastructure over end-user devices, with Azure (61%) and AWS (36%) accounting for 97% of compromised servers.

“TeamPCP’s strength does not come from novel exploits or original malware, but from the large-scale automation and integration of well-known attack techniques,” Flare’s Assaf Morag wrote. “The group industrializes existing vulnerabilities, misconfigurations, and recycled tooling into a cloud-native exploitation platform that turns exposed infrastructure into a self-propagating criminal ecosystem.”

On March 19, TeamPCP executed a supply chain attack against the vulnerability scanner Trivy from Aqua Security, injecting credential-stealing malware into official releases on GitHub actions. Aqua Security said it has since removed the harmful files, but the security firm Wiz notes the attackers were able to publish malicious versions that snarfed SSH keys, cloud credentials, Kubernetes tokens and cryptocurrency wallets from users.

Over the weekend, the same technical infrastructure TeamPCP used in the Trivy attack was leveraged to deploy a new malicious payload which executes a wiper attack if the user’s timezone and locale are determined to correspond to Iran, said Charlie Eriksen, a security researcher at Aikido. In a blog post published on Sunday, Eriksen said if the wiper component detects that the victim is in Iran and has access to a Kubernetes cluster, it will destroy data on every node in that cluster.

“If it doesn’t it will just wipe the local machine,” Eriksen told KrebsOnSecurity.

Image: Aikido.dev.

Aikido refers to TeamPCP’s infrastructure as “CanisterWorm” because the group orchestrates their campaigns using an Internet Computer Protocol (ICP) canister — a system of tamperproof, blockchain-based “smart contracts” that combine both code and data. ICP canisters can serve Web content directly to visitors, and their distributed architecture makes them resistant to takedown attempts. These canisters will remain reachable so long as their operators continue to pay virtual currency fees to keep them online.

Eriksen said the people behind TeamPCP are bragging about their exploits in a group on Telegram and claim to have used the worm to steal vast amounts of sensitive data from major companies, including a large multinational pharmaceutical firm.

“When they compromised Aqua a second time, they took a lot of GitHub accounts and started spamming these with junk messages,” Eriksen said. “It was almost like they were just showing off how much access they had. Clearly, they have an entire stash of these credentials, and what we’ve seen so far is probably a small sample of what they have.”

Security experts say the spammed GitHub messages could be a way for TeamPCP to ensure that any code packages tainted with their malware will remain prominent in GitHub searches. In a newsletter published today titled GitHub is Starting to Have a Real Malware Problem, Risky Business reporter Catalin Cimpanu writes that attackers often are seen pushing meaningless commits to their repos or using online services that sell GitHub stars and “likes” to keep malicious packages at the top of the GitHub search page.

This weekend’s outbreak is the second major supply chain attack involving Trivy in as many months. At the end of February, Trivy was hit as part of an automated threat called HackerBot-Claw, which mass exploited misconfigured workflows in GitHub Actions to steal authentication tokens.

Eriksen said it appears TeamPCP used access gained in the first attack on Aqua Security to perpetrate this weekend’s mischief. But he said there is no reliable way to tell whether TeamPCP’s wiper actually succeeded in trashing any data from victim systems, and that the malicious payload was only active for a short time over the weekend.

“They’ve been taking [the malicious code] up and down, rapidly changing it adding new features,” Eriksen said, noting that when the malicious canister wasn’t serving up malware downloads it was pointing visitors to a Rick Roll video on YouTube.

“It’s a little all over the place, and there’s a chance this whole Iran thing is just their way of getting attention,” Eriksen said. “I feel like these people are really playing this Chaotic Evil role here.”

Cimpanu observed that supply chain attacks have increased in frequency of late as threat actors begin to grasp just how efficient they can be, and his post documents an alarming number of these incidents since 2024.

“While security firms appear to be doing a good job spotting this, we’re also gonna need GitHub’s security team to step up,” Cimpanu wrote. “Unfortunately, on a platform designed to copy (fork) a project and create new versions of it (clones), spotting malicious additions to clones of legitimate repos might be quite the engineering problem to fix.”

Update, 2:40 p.m. ET: Wiz is reporting that TeamPCP also pushed credential stealing malware to the KICS vulnerability scanner from Checkmarx, and that the scanner’s GitHub Action was compromised between 12:58 and 16:50 UTC today (March 23rd).