A metà settembre 2026 i ricercatori di Aikido Security hanno individuato una campagna di supply chain attack che, per la prima volta, sfrutta il Terraform Registry di HashiCorp come canale di distribuzione di malware. Non si tratta di un incidente isolato: la stessa infrastruttura tossica ha toccato anche moduli Go, con un payload — battezzato Graphalgo — capace di trasformarsi in un vero e proprio RAT (Remote Access Trojan) con due canali di comando e controllo indipendenti, uno dei quali basato su smart contract Ethereum. Per chi gestisce pipeline di Infrastructure as Code è un campanello d’allarme che vale la pena analizzare in dettaglio, insieme alle contromisure concrete da mettere in campo.
Come funziona l’attacco
La catena inizia lontano dalla riga di comando terraform apply. Gli attaccanti hanno usato tecniche di ingegneria sociale — profili su LinkedIn, offerte di lavoro fittizie per fantomatiche aziende Web3, contatti diretti a sviluppatori — per convincere le vittime a lavorare su repository GitHub apparentemente legittimi. Questi repository importano dipendenze compromesse: due provider Terraform e due moduli Go, pubblicati con account creati ad hoc.
- gocommunity-io/dockerd — provider Terraform malevolo, circa 222 download
- kreuzwenker/docker — typosquat del popolarissimo
kreuzwerker/docker(oltre 56 milioni di download), circa 1.449 download - gocommunity.io/orderedbtree — modulo Go pubblicato l’11 agosto 2026, malware in chiaro
- gogets.dev/btreex — modulo Go pubblicato l’8 settembre 2026, malware compresso in un archivio ZIP mascherato da file SQL
Il dettaglio più interessante dal punto di vista tecnico è il meccanismo di attivazione: il payload resta completamente inerte finché non riceve un input molto specifico. Nel caso del provider Docker, il codice malevolo si attiva solo se l’hash SHA-256 della concatenazione tra containerName e networkID corrisponde a un valore hard-coded nel binario. Questo hash funge anche da chiave AES per decifrare un percorso file; una volta decompresso e decifrato il contenuto, il malware lo esegue con un comando go run . in background. È una tecnica di evasione efficace contro l’analisi statica e contro i sandbox automatici, perché senza il trigger esatto il codice non mostra alcun comportamento sospetto.
Un command & control a doppio canale
Una volta attivo, il secondo stadio — il RAT vero e proprio — instaura comunicazioni con l’infrastruttura degli attaccanti attraverso due canali ridondanti e indipendenti:
- Slack come C2: il malware effettua polling ogni 10 secondi sull’endpoint
conversations.historydi workspace Slack dedicati (osservatiportfolio-devs.slack.comeportfolio-testers.slack.com), supporta il trasferimento di file tramite pacchetti Start/Chunk/End e raccoglie informazioni di sistema come piattaforma, architettura, hostname, utente e home directory. - Smart contract Ethereum come C2: su rete Arbitrum Sepolia, il malware legge dati da un contratto a indirizzo fisso (
0xAD02b5cDE693529d3bdA0266299501ad0193036C) tramite le funzioniserviceData1/serviceData2e scrive tramitesetCPubKey, con polling ogni 3 secondi. Le comunicazioni sono cifrate con una coppia di chiavi effimere e curve ellittiche, in modo che solo l’host autenticato possa decifrare i messaggi a lui destinati — una tecnica pensata esplicitamente per resistere ad analisi e per evitare che un ricercatore che infiltri il canale possa leggere il traffico di altre vittime.
Questo design a doppio canale è la parte più sofisticata della campagna: se Slack viene bloccato o l’account sospeso, il malware continua a ricevere comandi dalla blockchain, che è per natura resistente al takedown. Gli analisti di Aikido hanno contato 18 hostname unici nei log Slack raccolti, con una distribuzione di 3 macchine Windows, 5 Linux e 10 macOS — un’operazione relativamente contenuta ma mirata, con il primo test datato 16 luglio 2026.
Perché il Terraform Registry è un bersaglio interessante
A differenza di npm o PyPI, l’ecosistema dei provider Terraform ha ricevuto storicamente meno attenzione dal punto di vista della sicurezza della supply chain, nonostante un provider Terraform giri con privilegi elevati durante il terraform apply: legge credenziali cloud, può creare o modificare risorse di produzione, e spesso viene eseguito senza sandboxing all’interno delle pipeline CI/CD. Un provider malevolo — o anche solo un typosquat ben fatto come kreuzwenker/docker — ha quindi accesso potenziale a un ventaglio di segreti (token cloud, chiavi SSH, credenziali di registry) decisamente più ampio di una libreria applicativa qualsiasi.
Contromisure concrete per i team infrastrutturali
Le raccomandazioni emerse dall’analisi della campagna si traducono in pratiche difensive già disponibili in Terraform e nell’ecosistema DevOps, ma spesso disattivate o ignorate:
1. Bloccare i provider su versione e checksum
Il file .terraform.lock.hcl generato da terraform init registra gli hash H1 di ogni provider scaricato. Va sempre committato nel repository e mai rigenerato senza revisione:
# genera/aggiorna il lock file includendo tutte le piattaforme target
terraform providers lock \
-platform=linux_amd64 \
-platform=darwin_arm64 \
-platform=windows_amd64
# verifica che il lock sia rispettato in CI, senza permettere upgrade silenziosi
terraform init -lockfile=readonly
2. Usare un registry privato o un mirror interno
Per ambienti enterprise, la soluzione più robusta è instradare tutte le richieste di provider attraverso un mirror filesystem o un proxy interno (Artifactory, Nexus, o il provider network mirror nativo di Terraform), che permette di whitelistare esplicitamente namespace e versioni approvate:
# ~/.terraformrc o file di configurazione CLI
provider_installation {
network_mirror {
url = "https://terraform-mirror.interno.aziendale/"
}
direct {
exclude = ["registry.terraform.io/*/*"]
}
}
3. Diffidare dei nomi “quasi corretti”
kreuzwenker/docker contro kreuzwerker/docker è un classico typosquat: una sola lettera di differenza in un namespace con decine di milioni di download legittimi. Vale la regola generale della supply chain security: pinnare sempre il namespace esatto nel blocco required_providers, non fidarsi del completamento automatico dell’IDE, e far parte della code review anche i file .tf che dichiarano provider e moduli.
4. Isolare l’esecuzione delle pipeline IaC
Eseguire terraform plan/apply in runner CI/CD isolati, senza accesso di rete non necessario in uscita (in particolare verso API di terze parti come Slack o endpoint blockchain), riduce drasticamente l’impatto di un binario malevolo anche se questo dovesse superare i controlli precedenti. Un semplice controllo di egress filtering che blocchi il traffico verso domini non whitelisted avrebbe reso inutile il canale Slack di Graphalgo.
5. Rotazione e audit in caso di sospetto
Se si sospetta un’esposizione, gli step raccomandati dagli analisti sono: isolamento immediato della macchina dalla rete, rotazione prioritaria di token GitHub/GitLab, credenziali cloud, chiavi SSH e token di pubblicazione dei package manager; audit forense di commit, apply Terraform ed esecuzioni CI/CD nella finestra di esposizione; e, soprattutto, reimmagine completa del sistema, perché la sola rimozione del pacchetto non garantisce l’eliminazione di eventuali impianti secondari lasciati dal RAT.
Conclusione
Graphalgo conferma un trend che negli ultimi anni ha già colpito npm, PyPI e i pacchetti Go singolarmente: gli attaccanti seguono la fiducia implicita che gli sviluppatori ripongono nei registry ufficiali, e il Terraform Registry — proprio perché finora considerato un bersaglio “di nicchia” — offre un potenziale di privilegio (accesso a credenziali cloud e infrastruttura di produzione) superiore a molte altre supply chain. Per i team DevOps e platform engineering la lezione pratica è semplice da enunciare ma spesso disattesa: trattare i provider Terraform con lo stesso livello di paranoia riservato alle dipendenze applicative, con lock file, mirror privati e pipeline isolate come prima linea di difesa.
Fonte: 4sysops.com, con approfondimenti tecnici da Aikido Security e The Hacker News.