Checkmarx nel mirino di TeamPCP: l’immagine Docker ufficiale di KICS trojanizzata per esfiltrare i segreti dell’infrastruttura

Il 22 aprile 2026 Docker, Inc. ha rilevato attività sospette sul repository ufficiale checkmarx/kics e ha allertato i ricercatori di Socket. L’analisi ha confermato il peggiore degli scenari per un vendor di security scanner: le immagini Docker ufficiali dello strumento open source KICS (Keeping Infrastructure as Code Secure) erano state sostituite con versioni trojanizzate, progettate per generare, cifrare ed esfiltrare i report di scansione completi insieme a token cloud, credenziali GitHub e chiavi SSH di ogni pipeline CI/CD che le eseguiva. Poche ore dopo, l’account @pcpcats rivendicava l’operazione: «Thank you OSS distribution for another very successful day at PCP inc.»

Non è la prima volta che Checkmarx finisce nel mirino di TeamPCP. A marzo 2026 lo stesso gruppo aveva compromesso due workflow GitHub Actions di Checkmarx e plugin distribuiti tramite OpenVSX, colpendo nella stessa ondata anche Trivy e LiteLLM. L’attacco di aprile rappresenta però un salto qualitativo: non si limita più al codice sorgente o agli action, ma colpisce direttamente i binary artifact distribuiti ufficialmente dal vendor, trasformando uno strumento che gli ingegneri installano proprio per cercare vulnerabilità in un vettore di furto di segreti su scala globale.

Che cos’è KICS e perché è un bersaglio ideale

KICS è uno scanner open source per Infrastructure-as-Code mantenuto da Checkmarx, ampiamente integrato nelle pipeline CI/CD per rilevare misconfiguration in Terraform, CloudFormation, Ansible, Kubernetes manifests e Dockerfile. Per sua stessa natura, viene eseguito con accesso di lettura all’intero repository, ai file di configurazione, ai secret dell’ambiente di build e spesso alle credenziali cloud a breve durata emesse dal provider di CI. Compromettere KICS significa ottenere, per ogni installazione infetta, una vista privilegiata sui crown jewels della pipeline.

Il vettore Docker Hub: tag sovrascritti e un v2.1.21 fantasma

Gli attaccanti hanno sovrascritto tag esistenti del repository checkmarx/kics — tra cui alpine, latest, debian, v2.1.20 e v2.1.20-debian — e hanno introdotto un tag v2.1.21 che non corrisponde ad alcun rilascio ufficiale del progetto. Questa tecnica è particolarmente insidiosa: ogni sistema che effettua docker pull checkmarx/kics:latest o che aggiorna l’immagine di base nei workflow di CI scarica silenziosamente la versione compromessa, senza allarmi da parte dei tool di dipendency scanning che si fidano del nome del repository ufficiale.

Il binario ELF di KICS all’interno dell’immagine è stato modificato per mantenere la funzionalità legittima (la scansione si completa senza errori, non ci sono segnali visibili di compromissione nei log) e aggiungere in parallelo una routine di raccolta dati che genera un report di scansione non censurato, lo cifra e lo invia a un endpoint esterno. In pratica, i file di configurazione che contengono password, token e connection string — normalmente redatti dai report pubblici di KICS — vengono esportati in chiaro verso l’infrastruttura dell’attaccante.

L’estensione VS Code e il payload mcpAddon.js

La campagna non si ferma alle immagini Docker. Socket ha identificato malware anche nelle estensioni Checkmarx per Visual Studio Code pubblicate sul marketplace Microsoft e su OpenVSX. Le versioni compromesse sono checkmarx.cx-dev-assist@1.17.0 e @1.19.0, oltre a checkmarx.ast-results@2.63.0 e @2.66.0 (la 1.18.0 risulta pulita, con il malware temporaneamente rimosso nel ciclo di release).

Il meccanismo è chirurgico: gli attaccanti hanno iniettato un commit retrodatato (68ed490b) nel repository Checkmarx/ast-vscode-extension contenente un file di circa 10 MB in modules/mcpAddon.js. Il modulo viene stageed per l’esecuzione runtime tramite l’interprete Bun, una scelta che riduce la probabilità di rilevazione rispetto all’esecuzione tradizionale in Node.js e permette di eseguire codice JavaScript con minore scrutinio da parte degli EDR endpoint.

Cosa ruba realmente mcpAddon.js

Il payload è un infostealer di caratura operativa avanzata. Esegue comandi nativi sulla macchina della vittima per raccogliere un dossier completo di credenziali:

• Token di autenticazione GitHub tramite gh auth token
• Credenziali AWS dai file di configurazione standard
• Token Azure tramite az account get-access-token e azd auth token
• Configurazioni Google Cloud tramite gcloud config config-helper
• Token npm dai file .npmrc dell’utente
• Chiavi SSH e file di configurazione
• File di configurazione di Claude Code e di altri MCP client
• Variabili d’ambiente selezionate del processo

L’inclusione esplicita dei file di configurazione MCP è un segnale che TeamPCP sta mappando non solo le supply chain tradizionali, ma anche l’ecosistema emergente degli agenti AI — che a loro volta conservano token per molteplici servizi di terze parti.

Esfiltrazione via repository GitHub pubblici: l’ingegno del «vocabolario Dune»

L’aspetto più creativo dell’operazione riguarda l’esfiltrazione. Invece di esfiltrare direttamente verso un C2 facilmente bloccabile, il malware crea repository GitHub pubblici con nomi casuali costruiti dal pattern <word>-<word>-<3 digits>, attingendo a un vocabolario ispirato all’universo di Dune — «gesserit», «melange», «fedaykin», «ornithopter», «atreides», «sandworm». Ogni repository ospita tre file: envelope con il payload cifrato, key con la chiave di decifratura (a sua volta cifrata), e token con un identificativo che lega il furto alla vittima.

I messaggi di commit incorporano token aggiuntivi secondo il pattern «LongLiveTheResistanceAgainstMachines:<encoded>», uno slogan ricorrente nel folklore di TeamPCP. Questa architettura rende la rilevazione molto più complessa: il traffico di esfiltrazione è indistinguibile dal normale uso di GitHub da parte di sviluppatori.

Il workflow format-check.yml e l’abuso di toJSON(secrets)

Nell’operazione di marzo, TeamPCP aveva già dimostrato padronanza dei GitHub Actions: il workflow maligno .github/workflows/format-check.yml sfruttava l’espressione ${{ toJSON(secrets) }} per serializzare tutti i segreti del repository e dell’organizzazione in un artefatto JSON scaricabile per 90 giorni. È una tecnica di supply chain attack elegante e sottovalutata, perché non richiede di esfiltrare alcunché verso infrastruttura esterna: GitHub stesso ospita il bottino, che diventa scaricabile con le sole credenziali dell’attaccante.

Propagazione npm via token rubati

Una volta ottenuti i token npm delle vittime, il malware cerca automaticamente pacchetti scrivibili interrogando l’endpoint /-/org/<user>/package e, in fallback, effettua ricerche con https://registry.npmjs.org/-/v1/search?text=maintainer:<user>&size=250. La logica è quella classica dei self-replicating npm worm già osservati in campagne come Shai-Hulud: ogni sviluppatore colpito diventa un potenziale vettore per nuove pubblicazioni malevoli.

Indicatori di Compromissione

== Hash ==
mcpAddon.js
  SHA256  24680027afadea90c7c713821e214b15cb6c922e67ac01109fb1edb3ee4741d9
  SHA1    2b12cc5cc91ec483048abcbd6d523cdc9ebae3f3
  MD5     d47de3772f2d61a043e7047431ef4cf4

kics (ELF binary trojanizzato)
  SHA256  2a6a35f06118ff7d61bfd36a5788557b695095e7c9a609b4a01956883f146f50
  SHA1    250f3633529457477a9f8fd3db3472e94383606a
  MD5     e1023db24a29ab0229d99764e2c8deba

== Docker tag compromessi (checkmarx/kics) ==
alpine, latest, debian, v2.1.20, v2.1.20-debian, v2.1.21 (fake)

== Index manifest digest ==
sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d  (alpine/v2.1.20/v2.1.21)
sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b  (debian variants)
sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0  (latest)

== Estensioni VS Code / OpenVSX ==
checkmarx.cx-dev-assist  1.17.0, 1.19.0   (malevole)
checkmarx.ast-results    2.63.0, 2.66.0   (malevole)

== C2 ==
audit.checkmarx[.]cx/v1/telemetry
94[.]154[.]172[.]43

== Pattern repository di staging ==
<word>-<word>-<3 digits> (vocabolario Dune: gesserit, melange, fedaykin,
ornithopter, atreides, sandworm, ...) con file envelope/key/token

== Pattern commit message ==
LongLiveTheResistanceAgainstMachines:<encoded>

Implicazioni e raccomandazioni

Il caso Checkmarx/KICS è un promemoria brutale: gli strumenti di security scanner sono essi stessi componenti della supply chain, spesso eseguiti con privilegi elevati dentro le pipeline più sensibili dell’organizzazione. Per chi gestisce ambienti che integrano KICS o altri scanner Checkmarx:

• Verificare le versioni pullate di checkmarx/kics negli ultimi 30 giorni e confrontare i digest con quelli pubblicati ufficialmente dal vendor dopo la rimediation.
• Effettuare il pin delle immagini Docker a digest SHA invece che a tag mutabili come latest o alpine.
• Controllare i log GitHub per workflow artefacts di dimensione anomala, in particolare quelli generati da workflow che referenziano toJSON(secrets).
• Ruotare tutti i token GitHub, npm, AWS, Azure e GCP che potrebbero essere stati esposti a sviluppatori con cx-dev-assist o ast-results nelle versioni compromesse.
• Monitorare la creazione di repository GitHub pubblici corrispondenti al pattern Dune descritto sopra.
• Bloccare o allertare sulle connessioni verso audit.checkmarx.cx (dominio di lookalike non legittimo di Checkmarx).

Il doppio colpo di TeamPCP a Checkmarx in meno di due mesi suggerisce che il gruppo conserva un accesso persistente o ricorrente agli ambienti di build del vendor, o quantomeno che alcune delle credenziali rubate nella prima ondata non sono state completamente invalidate. La security community attende risposte più dettagliate dal vendor su come il tag Docker ufficiale sia stato sovrascritto e su quale catena di fiducia debba essere ricostruita per i clienti che hanno integrato KICS nelle proprie pipeline negli ultimi mesi.