TLDR

  • ChocoPoC prende di mira ricercatori e pentester con repository GitHub che sembrano proof-of-concept per CVE calde.
  • Il codice visibile può sembrare innocuo: il malware arriva da dipendenze Python transitive.
  • Il bersaglio è ricco: macchine di researcher, chiavi SSH, cookie, credenziali cloud, report e ambienti cliente.
  • La difesa è trattare ogni PoC come ostile, testare in ambienti usa-e-getta e leggere tutta la catena delle dipendenze.

Perché conta ora

Chi fa sicurezza ha una cattiva abitudine necessaria: esegue codice brutto.

PoC appena pubblicati, exploit dimostrativi, script mezzi rotti, tool di sconosciuti, repository nati ieri, branch con nomi improbabili. È parte del lavoro. Devi capire se una vulnerabilità è reale, quanto impatta, cosa rilevare, come proteggere.

Gli attaccanti lo sanno.

La campagna ChocoPoC, analizzata da YesWeHack e Sekoia, prende di mira proprio questa fretta. Pubblica repository GitHub che sembrano proof-of-concept per CVE calde e lascia che siano researcher, pentester e studenti security a fare il resto.

Il vecchio consiglio "leggi il codice prima di eseguirlo" resta giusto.

Solo che qui non basta.

Il PoC pulito è l'esca

La parte più interessante di ChocoPoC non è che esista un PoC malevolo.

Quello succede da anni.

Il punto è dove si nasconde il malware. Non necessariamente nel file principale che apri e controlli. Può stare in una dipendenza Python installata dal progetto, magari richiamata da un'altra dipendenza.

Risultato: guardi il file EXPLOIT_POC.py, ti sembra plausibile, non trovi niente di troppo sporco, installi requirements e provi.

Hai appena spostato la review nel posto sbagliato.

La supply chain non è solo il pacchetto famoso con milioni di download. È anche il pacchettino nato ieri che entra perché un PoC "temporaneo" lo chiede.

Perché i ricercatori sono bersagli perfetti

Una macchina di un ricercatore può valere più di un server generico.

Può contenere:

  • chiavi SSH;
  • token cloud;
  • cookie browser;
  • accessi VPN;
  • note su vulnerabilità non pubbliche;
  • report cliente;
  • exploit privati;
  • credenziali di laboratorio;
  • configurazioni di scanner;
  • accesso a repository interni;
  • cronologia shell molto istruttiva.

In più, il comportamento sospetto è già normale. Scaricare tool strani? Normale. Eseguire script sconosciuti? Normale. Aprire traffico verso servizi esterni? Normale. Far girare codice che l'antivirus non ama? Purtroppo normale.

È un ambiente dove il rumore copre l'attacco.

Il trucco delle dipendenze transitive

Il modello è semplice:

  1. repository GitHub con nome legato a una CVE recente;
  2. README convincente;
  3. PoC visibile abbastanza credibile;
  4. file di dipendenze;
  5. pacchetto Python malevolo o dipendenza che ne richiama un'altra;
  6. payload che si attiva solo nel contesto giusto.

Questo ultimo punto è importante. Un pacchetto malevolo può non fare nulla se analizzato da solo. Può aspettare di vedere il file del PoC, un nome specifico, un ambiente coerente o una certa sequenza di import.

Una sandbox pigra vede poco.

Una review frettolosa vede meno.

Cosa controllare prima di eseguire un PoC

Checklist minima:

  1. Età dell'account GitHub.
  2. Storico commit reale o artificiale.
  3. Issue e pull request sensate.
  4. Dipendenze dirette e transitive.
  5. Pacchetti appena pubblicati su PyPI.
  6. Maintainer dei pacchetti.
  7. Script setup.py, pyproject.toml, hook e file binari.
  8. Estensioni native .so, .pyd, .dll.
  9. Connessioni verso servizi non collegati alla CVE.
  10. Richieste di permessi o path troppo larghi.

La domanda da farsi non è "il PoC funziona?".

La domanda è "cosa sto autorizzando mentre provo a farlo funzionare?".

Come testare senza regalare la macchina

Un ambiente decente per PoC sporchi dovrebbe essere:

  • VM usa-e-getta;
  • snapshot prima del test;
  • nessun segreto dentro;
  • nessuna chiave SSH montata;
  • nessun token cloud;
  • clipboard condivisa disabilitata;
  • cartelle host non montate;
  • rete limitata;
  • DNS e traffico loggati;
  • distruzione della VM a fine test.

Se il PoC richiede accesso a un target reale, fermati e ridisegna il test.

Un buon lab deve proteggere anche dal codice che vuoi capire.

Errori comuni

Il primo errore è fidarsi del nome della CVE nel repository.

Un titolo tecnico non è una firma.

Il secondo errore è pensare che un PoC malevolo debba essere scritto male. Alcuni sono scritti abbastanza bene da sembrare lavoro di community.

Il terzo errore è eseguire PoC dalla macchina quotidiana "solo per vedere se parte".

È così che un test da cinque minuti diventa rotazione di credenziali per due giorni.

Dopo l'incidente

Se hai eseguito un PoC sospetto:

  1. isola la macchina dalla rete;
  2. conserva log, shell history e pacchetti installati;
  3. cerca pacchetti e hash indicati dagli IoC della campagna;
  4. ruota chiavi SSH, token, password e cookie importanti;
  5. controlla accessi cloud e GitHub successivi al test;
  6. avvisa eventuali clienti o team coinvolti se c'erano credenziali o dati sensibili;
  7. ricostruisci la macchina o la VM invece di "ripulirla a mano".

La pulizia parziale è rassicurante.

Non necessariamente è vera.

Il punto

ChocoPoC non inventa il veleno.

Lo mette in un posto più furbo.

Il file che guardi può essere pulito. Il repository può sembrare tecnico. La CVE può essere reale. La fretta può essere giustificata.

E proprio per questo l'attacco funziona.

Chi fa security deve trattare i PoC come campioni biologici: utili, interessanti, ma mai da aprire sul tavolo della cucina.

FAQ

Che cos'è ChocoPoC?

È una campagna malware che usa falsi repository proof-of-concept per CVE recenti e nasconde il payload in pacchetti Python collegati al PoC.

Perché colpisce chi fa security?

Perché ricercatori e pentester eseguono spesso codice non fidato per verificare vulnerabilità, e sulle loro macchine possono esserci credenziali, report e accessi sensibili.

Guardare il file PoC basta?

No. In questa campagna il file visibile può sembrare ragionevole, mentre la parte malevola arriva da dipendenze installate dal progetto.

Una VM basta a proteggersi?

Aiuta molto, ma deve essere davvero usa-e-getta, senza segreti montati, senza clipboard sensibile, senza chiavi SSH e senza accesso laterale alla rete interna.

Cosa fare se ho eseguito un PoC sospetto?

Isolare la macchina, raccogliere evidenze, cercare pacchetti e file indicati dagli IoC, ruotare credenziali e ricostruire l'ambiente invece di fidarsi di una pulizia parziale.

Fonti