<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with npm]]></title><description><![CDATA[A list of topics that have been tagged with npm]]></description><link>https://forum.androidiani.net/tags/npm</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 17:10:17 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/npm.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 25 May 2026 16:37:30 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Laravel-Lang compromessa: oltre 700 versioni PHP infettate da uno stealer cross-platform]]></title><description><![CDATA[Si parla di:ToggleUn sofisticato attacco alla supply chain ha compromesso quattro pacchetti PHP appartenenti al progetto Laravel-Lang, iniettando codice malevolo in oltre 700 versioni pubblicate in rapida successione tra il 22 e il 23 maggio 2026. Il payload — uno stealer cross-platform da quasi 6.000 righe di codice — è stato progettato per drenare credenziali cloud, token CI/CD, wallet di criptovalute e segreti di repository da qualsiasi sistema che utilizzi queste librerie di localizzazione diffusissime nell’ecosistema Laravel.La natura dell’attacco: tag git riscritti, non codice sorgenteQuello che rende questa campagna particolarmente insidiosa è la tecnica adottata: gli attaccanti non hanno modificato il codice sorgente del repository, bensì hanno riscritto ogni tag git esistente in ciascun repository per puntare a commit malevoli appartenenti a un fork controllato dagli aggressori. Questo approccio bypassa molti controlli di integrità tradizionali basati sull’analisi dei diff del codice principale.GitHub consente ai tag di versione di puntare a commit di fork dello stesso repository. Gli attaccanti hanno sfruttato questa funzionalità per sostituire silenziosamente tutti i tag — compresi quelli di versioni storicamente sicure — con riferimenti a commit malevoli nel fork. Il risultato pratico è che anche un progetto che non aggiornava le dipendenze da mesi si ritrovava improvvisamente a scaricare codice ostile.I ricercatori di Socket, Aikido Security, StepSecurity e Snyk hanno analizzato in dettaglio l’incidente, confermando che le versioni compromesse sono state pubblicate in rapida successione — alcune a pochi secondi di distanza l’una dall’altra — il 22 e il 23 maggio 2026, con oltre 700 versioni identificate tra i quattro pacchetti interessati. La velocità di pubblicazione indica quasi certamente un processo automatizzato.I pacchetti compromessiI quattro pacchetti colpiti sono componenti fondamentali dell’ecosistema di localizzazione per applicazioni Laravel:laravel-lang/lang — le traduzioni principali per decine di linguelaravel-lang/http-statuses — messaggi di stato HTTP localizzatilaravel-lang/attributes — traduzioni degli attributi dei formlaravel-lang/actions — azioni comuni localizzateSi sospetta che gli attaccanti abbiano ottenuto accesso a credenziali a livello di organizzazione, a sistemi di automazione del repository o all’infrastruttura di rilascio del progetto. Packagist ha risposto tempestivamente rimuovendo le versioni malevole e mettendo temporaneamente in stato di “unlisted” i pacchetti interessati per prevenire ulteriori installazioni.Il meccanismo di esecuzione automatica: autoloader ComposerLa funzionalità malevola è contenuta in un file denominato src/helpers.php, incorporato nei tag di versione compromessi. Il file è registrato nel campo autoload.files del composer.json di ciascun pacchetto. Questa scelta tecnica è devastante: qualsiasi applicazione PHP che esegua require __DIR__.'/vendor/autoload.php' all’avvio — ovvero praticamente ogni applicazione Laravel, Symfony, PHPUnit o framework PHP moderno — esegue automaticamente il payload senza che sia necessaria alcuna chiamata di metodo esplicita.“Il backdoor viene eseguito automaticamente ad ogni richiesta PHP gestita dall’applicazione compromessa”, ha spiegato Socket nella propria analisi. Lo script genera un identificatore univoco per host (un hash MD5 che combina il percorso della directory, l’architettura del sistema e l’inode) per garantire che il payload si attivi una sola volta per macchina, limitando le esecuzioni ridondanti e aiutando il malware a restare non rilevato dopo l’esecuzione iniziale.Payload: uno stealer modulare con 15 collector specializzatiIl dropper contatta il server flipboxstudio[.]info per recuperare il payload principale: uno stealer PHP cross-platform da circa 5.900 righe di codice, organizzato in 15 moduli collector specializzati. Su Windows viene distribuito un launcher Visual Basic Script eseguito tramite cscript; su Linux e macOS il payload viene eseguito tramite exec().L’elenco di ciò che lo stealer è in grado di raccogliere è impressionante per ampiezza e profondità:Cloud provider: ruoli IAM AWS e documenti di identità dell’istanza, credenziali default di Google Cloud, token di accesso Microsoft Azure, profili service principal, token di account DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.ioContainer e orchestrazione: token Service Account Kubernetes, configurazioni Helm registry, token HashiCorp Vault, auth token Docker, configurazioni cluster KubernetesCI/CD e DevOps: token e configurazioni di Jenkins, GitLab Runner, GitHub Actions, CircleCI, TravisCI, ArgoCDCriptovalute: seed phrase e file di portafogli Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow; dati di estensioni browser MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, RabbyBrowser: cronologia, cookie e login data da Chrome, Edge, Firefox, Brave, Opera, usando un eseguibile Windows embedded in Base64 che bypassa Chromium’s App-Bound Encryption (ABE)Password manager: vault locali e dati di estensioni 1Password, Bitwarden, LastPass, KeePass, Dashlane, NordPassComunicazioni e sessioni: token di Discord, Slack, Telegram; sessioni PuTTY/WinSCP, Windows Credential Manager, sessioni RDPFile sensibili: chiavi private SSH, credenziali Git, history di shell, file .env, wp-config.php, docker-compose.yml, variabili d’ambiente del processo PHPEmail e FTP: dati Outlook, Thunderbird, FileZilla, WinSCP, CoreFTPVPN: configurazioni OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost, MullvadDopo aver raccolto tutto il materiale disponibile, il payload cripta i risultati con AES-256 e li trasmette all’endpoint flipboxstudio[.]info/exfil, dopodiché si cancella dal disco per limitare le tracce forensi.IoC (Indicatori di Compromissione)# Dominio C2 principale
flipboxstudio[.]info
flipboxstudio[.]info/exfil
# File malevolo nei pacchetti
src/helpers.php  (registrato in autoload.files di composer.json)
# Pacchetti PHP compromessi (verificare versioni 22-23 maggio 2026)
laravel-lang/lang
laravel-lang/http-statuses
laravel-lang/attributes
laravel-lang/actions
# Verifica presenza del file malevolo
find ./vendor -name "helpers.php" -path "*/laravel-lang/*" -exec grep -l "flipboxstudio" {} \;Contesto: una campagna in crescita nell’ecosistema PHPQuesto attacco non è isolato. Negli ultimi mesi si è assistito a un’ondata di compromissioni delle supply chain nei principali registri di pacchetti. In particolare, la campagna Mini Shai-Hulud attribuita al gruppo TeamPCP (UNC6780) ha colpito pacchetti npm di TanStack, Mistral AI, Guardrails AI e OpenSearch, diffondendosi come un vero e proprio worm grazie all’abuso di token OIDC GitHub e al meccanismo di trusted publishing di npm. Il fatto che ora un attacco simile colpisca l’ecosistema PHP/Composer dimostra che i gruppi criminali stanno sistematicamente esplorando tutti i principali registri di pacchetti come vettori di attacco.La tecnica di riscrivere i tag git invece di modificare il codice sorgente rappresenta un’evoluzione tattica significativa: bypassando i controlli diff tradizionali, rende molto più difficile il rilevamento automatico da parte degli strumenti di analisi della composizione software (SCA).Due righe per i difensoriVerificare immediatamente se le applicazioni Laravel utilizzano uno dei quattro pacchetti compromessi e controllare le versioni installate durante il periodo 22-23 maggio 2026Ruotare tutte le credenziali (AWS, GCP, Azure, GitHub, npm, CI/CD, database) su qualsiasi sistema che abbia eseguito codice con le versioni infetteNon revocare immediatamente i token sospetti prima di aver isolato e acquisito un’immagine forense del sistema: il malware include meccanismi di risposta alla revocaBloccare il dominio flipboxstudio[.]info a livello di firewall/DNSImplementare controlli di integrità sui tag git (verificare le firme dei commit) e considerare il pinning degli hash SHA degli artefatti nel composer.lockAdottare strumenti SCA capaci di rilevare tag git riscritti, non solo modifiche al codice sorgenteAggiornare a versioni sicure dei pacchetti rilasciate dal team Laravel-Lang dopo la rimozione delle versioni malevole da Packagist]]></description><link>https://forum.androidiani.net/topic/1f0ec210-d3f7-4547-b5e1-1d66b42032ef/laravel-lang-compromessa-oltre-700-versioni-php-infettate-da-uno-stealer-cross-platform</link><guid isPermaLink="true">https://forum.androidiani.net/topic/1f0ec210-d3f7-4547-b5e1-1d66b42032ef/laravel-lang-compromessa-oltre-700-versioni-php-infettate-da-uno-stealer-cross-platform</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Mon, 25 May 2026 16:37:30 GMT</pubDate></item><item><title><![CDATA[TeamPCP viola GitHub dall’interno: 3.800 repository sottratti in 18 minuti tramite un’estensione VS Code malevola]]></title><description><![CDATA[18 minuti. È il tempo in cui una versione trojanizzata dell’estensione VS Code Nx Console (nrwl.angular-console) è rimasta disponibile sul Visual Studio Marketplace il 18 maggio 2026. Un lasso di tempo apparentemente irrisorio, ma sufficiente perché il gruppo criminale TeamPCP compromettesse il device di almeno un dipendente GitHub e sottraesse circa 3.800 repository interni — uno degli incidenti di supply chain più gravi dell’anno sul piano dell’impatto sistemico.Il contesto: TeamPCP e la catena TanStackPer capire la violazione di GitHub è necessario risalire di dieci giorni. L’11 maggio 2026, TeamPCP aveva già pubblicato 84 artifact npm malevoli distribuiti su 42 pacchetti nel namespace TanStack — uno degli ecosistemi più adottati per il web development con React. Quell’operazione, che il sito ha seguito nelle settimane precedenti nella campagna Mini Shai-Hulud, aveva come obiettivo la compromissione a cascata di developer tramite dipendenze malevole che esfiltravano credenziali e token durante l’installazione.TeamPCP ha guadagnato notorietà rapidamente come attore specializzato negli attacchi alla developer trust surface: non attacca i sistemi delle vittime direttamente, ma compromette la catena di strumenti e dipendenze su cui i developer si fidano implicitamente ogni giorno. L’attacco TanStack era già sufficientemente grave da soli — ma era anche il setup per qualcosa di più ambizioso.Il vettore: Nx Console 18.95.0Nx Console (nrwl.angular-console) è un’estensione VS Code con 2,2 milioni di installazioni e lo status di verified publisher — la certificazione più alta che Microsoft assegna agli editori sul marketplace. Questa combinazione di popolarità e fiducia istituzionale ne fa un bersaglio di enorme valore per un attore supply chain.Il team di Nx ha successivamente ricostruito la catena causale: uno dei propri developer era stato precedentemente compromesso nel contesto dell’attacco a TanStack. Le sue credenziali GitHub erano trapelate, permettendo a TeamPCP di accedere al repository dell’estensione, modificare il codice, e pubblicare la versione 18.95.0 — quella avvelenata. Il meccanismo era semplice ma letale: non appena un developer apriva qualsiasi workspace in VS Code con l’estensione installata, il malware iniziava a raccogliere silenziosamente le credenziali memorizzate nel sistema.La timeline dell’attacco11 maggio 2026 — TeamPCP pubblica 84 pacchetti npm malevoli nel namespace TanStack; un developer Nx viene compromesso18 maggio 2026, 12:30 UTC — Nx Console 18.95.0 (versione backdoor) appare sul VS Code Marketplace18 maggio 2026, 12:48 UTC — La versione malevola viene rimossa dal Marketplace (18 minuti di esposizione)18 maggio 2026, ~13:06 UTC — Rimossa da Open VSX (36 minuti totali di esposizione)20 maggio 2026 — GitHub conferma la violazione: circa 3.800 repository interni esfiltrati, avvio rotazione di tutti i secret espostiL’impatto: 3.800 repository interni di GitHubGitHub ha confermato la sottrazione di circa 3.800 repository interni a opera di TeamPCP. L’azienda ha proceduto immediatamente alla rotazione di tutti i secret potenzialmente esposti. Non è ancora stato reso noto se i repository contengano codice relativo alla piattaforma github.com stessa, strumenti interni, infrastrutture di supporto o documentazione riservata — ma la sola portata numerica dell’esfiltrazione suggerisce un accesso profondo all’ecosistema di sviluppo interno di Microsoft GitHub. L’incidente ha colpito anche Grafana, compromessa attraverso un percorso diverso ma sempre legato alla catena TanStack.Perché questo attacco è strutturalmente diversoA differenza dei classici attacchi alla supply chain che operano a livello di package manager (npm, PyPI), questo incidente colpisce il layer dell’IDE — la superficie più prossima al developer e quella con i privilegi di accesso più ampi. Un’estensione VS Code non è un pacchetto passivo: ha accesso al filesystem locale, alle variabili d’ambiente di sistema, ai token Git memorizzati, alle chiavi SSH, ai file di configurazione cloud e all’intera sessione di sviluppo attiva.Un’estensione verified con milioni di installazioni diventa, una volta compromessa, un vettore di distribuzione quasi impossibile da bloccare con le tradizionali difese perimetrali. La maggior parte degli endpoint detection agent non monitora il comportamento delle estensioni IDE con la stessa granularità con cui monitora i processi di sistema — un gap che TeamPCP ha sfruttato con precisione chirurgica.Indicatori di compromissione (IoC)# TeamPCP - GitHub Breach via Nx Console - IoC (maggio 2026)
# Estensione malevola
EXTENSION: nrwl.angular-console (Nx Console) versione 18.95.0
MARKETPLACE: Visual Studio Code Marketplace
TIMEFRAME: 2026-05-18 12:30–12:48 UTC (VS Code Marketplace)
TIMEFRAME: 2026-05-18 12:30–13:06 UTC (Open VSX)
# Infrastruttura TeamPCP documentata
DOMAIN: t.m-kosche.com (infra C2 TeamPCP)
# Campagne correlate
CAMPAIGN: Mini Shai-Hulud (npm/PyPI, 160+ pacchetti)
CAMPAIGN: TanStack supply chain (84 artifact npm su 42 pacchetti, 2026-05-11)
# Possibili alias
ACTOR: TeamPCP
ACTOR_ALIAS: UNC6780 (attribuzione parziale)
# Azione raccomandata
ACTION: Verificare estensioni VS Code installate nel periodo 2026-05-11/20
ACTION: Ruotare tutti i token GitHub/credential store sui sistemi degli sviluppatoriDue righe per i difensoriL’incidente impone una revisione urgente della postura di sicurezza degli ambienti di sviluppo. I team di sicurezza dovrebbero verificare immediatamente se l’estensione Nx Console 18.95.0 è stata installata su device aziendali nel periodo 11–20 maggio 2026, e in caso affermativo avviare la rotazione di tutte le credenziali presenti sui sistemi coinvolti — token GitHub, chiavi SSH, credenziali cloud, certificati. È fondamentale estendere il monitoraggio EDR alle estensioni IDE, configurando alert per comportamenti anomali come lettura massiva di file di configurazione, accesso ai credential store di sistema o connessioni di rete originate dal processo VS Code verso endpoint inusuali. Sul piano organizzativo, è necessario implementare il principio del minimo privilegio per le credenziali usate negli ambienti di sviluppo: i developer non dovrebbero mai usare token con permessi di scrittura su repository interni critici sui propri device personali. Infine, considerare l’adozione di ambienti di sviluppo isolati — container o VM dedicati — per i progetti a più alto rischio, separando fisicamente l’ambiente di esecuzione del codice dall’ambiente di lavoro quotidiano.]]></description><link>https://forum.androidiani.net/topic/b9e48550-bfd9-4379-8b8c-b58de3d8d4f7/teampcp-viola-github-dall-interno-3.800-repository-sottratti-in-18-minuti-tramite-un-estensione-vs-code-malevola</link><guid isPermaLink="true">https://forum.androidiani.net/topic/b9e48550-bfd9-4379-8b8c-b58de3d8d4f7/teampcp-viola-github-dall-interno-3.800-repository-sottratti-in-18-minuti-tramite-un-estensione-vs-code-malevola</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Thu, 21 May 2026 17:14:57 GMT</pubDate></item><item><title><![CDATA[QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software]]></title><description><![CDATA[Si parla di:ToggleUn nuovo implant Linux mai documentato prima — denominato Quasar Linux RAT (QLNX) — sta prendendo di mira sviluppatori e ambienti DevOps con l’obiettivo di appropriarsi silenziosamente delle credenziali più preziose del ciclo di sviluppo software: token npm, PyPI, AWS, Kubernetes, GitHub e molto altro. La scoperta, opera dei ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim di Trend Micro, descrive uno strumento che non si limita ad essere un semplice trojan di accesso remoto, ma una piattaforma di spionaggio industriale progettata per persistere, nascondersi e colpire l’intera supply chain del software.Cosa rende QLNX diverso dagli altri RAT LinuxA differenza di molti implant Linux che puntano sulla semplicità, QLNX è costruito come una piattaforma d’attacco coerente e modulare. Il suo punto di forza non sta in una singola tecnica innovativa, ma nell’integrazione armoniosa di più capacità offensive che si concatenano in un flusso d’attacco preciso: arriva, cancella le tracce dal disco, si radica con sei meccanismi ridondanti, si nasconde sia a livello userspace che kernel, e infine raccoglie sistematicamente le credenziali che contano davvero.Il malware esegue filelessly dalla memoria, mascherandosi da thread del kernel attraverso nomi come kworker o ksoftirqd — nomi che ogni amministratore di sistema Linux incontra quotidianamente nei propri processi. Questo lo rende praticamente invisibile a una normale ispezione manuale. È inoltre in grado di profilare l’host per rilevare ambienti containerizzati, cancellare i log di sistema e stabilire persistenza attraverso non meno di sette metodi diversi, tra cui systemd, crontab e shell injection nel file .bashrc.Un harvester di credenziali pensato per la supply chainIl componente di furto credenziali di QLNX è ciò che lo rende particolarmente pericoloso per l’ecosistema open source. Il malware estrae sistematicamente segreti da un elenco preciso di file ad alto valore per uno sviluppatore:File target di QLNX per il furto credenziali:

.npmrc              → Token di pubblicazione npm
.pypirc             → Credenziali PyPI
.git-credentials    → Credenziali Git
.aws/credentials    → Chiavi di accesso AWS
.kube/config        → Credenziali Kubernetes
.docker/config.json → Autenticazione Docker Registry
.vault-token        → Token HashiCorp Vault
.env                → Variabili d'ambiente con segreti
**/terraform.tfvars → Credenziali Terraform
GitHub CLI tokens   → Token di accesso GitHubIl rischio non è solo per lo sviluppatore compromesso: un attore che ottiene accesso a uno di questi token può pubblicare pacchetti malevoli su npm o PyPI, accedere all’infrastruttura cloud o muoversi lateralmente attraverso pipeline CI/CD. È esattamente il meccanismo che ha consentito attacchi supply chain devastanti in passato, come l’operazione TeamPCP che ha colpito oltre 160 pacchetti npm e PyPI nelle scorse settimane.Architettura rootkit a doppio livello: LD_PRELOAD + eBPFL’aspetto più sofisticato di QLNX è la sua architettura rootkit a due livelli, che combina tecniche di occultamento a livello userspace e kernel.Il primo strato è un rootkit userland deployato attraverso il meccanismo LD_PRELOAD del dynamic linker di Linux. Questo garantisce che tutti gli artefatti e i processi dell’implant rimangano nascosti agli strumenti di ispezione standard. Il secondo strato è un componente kernel-level basato su eBPF (Extended Berkeley Packet Filter) — il potente sottosistema Linux originariamente pensato per il networking e l’osservabilità dei sistemi. QLNX sfrutta eBPF per nascondere processi, file e porte di rete agli strumenti userland come ps, ls e netstat, su istruzione del server di comando e controllo (C2).L’uso offensivo di eBPF per il rootkitting è una tendenza già documentata da altri ricercatori, ma la sua integrazione in un RAT con builder pipeline modulare indica una maturazione significativa di queste tecniche al di fuori di ambienti di ricerca accademica.Backdoor PAM: furto di credenziali SSH in tempo realeQLNX include anche un backdoor basato su PAM (Pluggable Authentication Module) che intercetta le credenziali in chiaro durante gli eventi di autenticazione SSH. Il componente PAM inline-hook registra i dati delle sessioni SSH in uscita e li trasmette al C2. È inoltre presente un secondo logger PAM che viene caricato automaticamente in ogni processo collegato dinamicamente, per estrarre nome del servizio, username e token di autenticazione.Questa tecnica è particolarmente insidiosa perché i moduli PAM girano tipicamente con privilegi root e operano a un livello così basso nello stack di autenticazione che la maggior parte dei sistemi di monitoring tradizionali non riesce a intercettarli. Non a caso, negli ultimi mesi sono emersi altri strumenti simili — come PamDOORa, venduto su forum russi di cybercrime per 900 dollari — che sfruttano lo stesso vettore.58 comandi C2 e un’infrastruttura operativa completaQLNX supporta ben 58 comandi distinti che conferiscono agli operatori il controllo completo dell’host compromesso. Le capacità operative includono esecuzione di shell commands, gestione file, code injection nei processi, cattura di screenshot, keylogging, SOCKS proxy, TCP tunneling, esecuzione di Beacon Object Files (BOFs) — la stessa tecnica usata da Cobalt Strike — e gestione di una rete P2P mesh tra host compromessi.La comunicazione con il C2 avviene su tre protocolli — TCP grezzo, HTTPS e HTTP — con un loop persistente che tenta continuamente di mantenere attiva la connessione. La vettore di infezione iniziale rimane ancora sconosciuto, ma una volta stabilito il foothold, QLNX cancella i propri artefatti dal disco e avvia la fase operativa principale.Indicatori di compromissione e contromisureQLNX evidenzia una tendenza preoccupante: la supply chain del software sta diventando il bersaglio privilegiato di attori sofisticati, perché compromettere un singolo sviluppatore con accesso ai registri npm o PyPI può avere effetti moltiplicatori su migliaia di utenti downstream. Per i team di sicurezza, alcune contromisure prioritarie:Ruotare regolarmente tutti i token di pubblicazione per npm, PyPI, GitHub e altri registri, soprattutto dopo accessi da sistemi non familiari.Monitorare processi Linux con nomi simili a thread del kernel — kworker, ksoftirqd ecc. — che non corrispondono agli effettivi thread del kernel: strumenti come pstree con verifica del PPID possono rivelare anomalie.Verificare l’integrità dei moduli PAM: controllare regolarmente che i file .so nei percorsi PAM non siano stati modificati rispetto alla versione del package manager.Abilitare audit logging di eBPF per rilevare il caricamento di programmi eBPF non autorizzati: auditctl -a always,exit -F arch=b64 -S bpf.Isolare i segreti CI/CD dall’ambiente di sviluppo locale, usando secret manager dedicati piuttosto che file in chiaro su disco.Trend Micro ha pubblicato i dettagli tecnici completi nel proprio blog di ricerca. La natura fileless di QLNX e il suo doppio rootkit rendono il rilevamento basato su signature sostanzialmente inefficace: la difesa deve puntare su behavioral analytics e monitoraggio delle anomalie a livello di syscall, combinati con soluzioni EDR capaci di ispezionare la memoria dei processi.]]></description><link>https://forum.androidiani.net/topic/9e334f68-e6dc-4f7d-b9a5-b5163dd9e1e2/qlnx-il-nuovo-implant-linux-silenzioso-che-saccheggia-la-supply-chain-del-software</link><guid isPermaLink="true">https://forum.androidiani.net/topic/9e334f68-e6dc-4f7d-b9a5-b5163dd9e1e2/qlnx-il-nuovo-implant-linux-silenzioso-che-saccheggia-la-supply-chain-del-software</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Tue, 19 May 2026 13:01:17 GMT</pubDate></item><item><title><![CDATA[Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise]]></title><description><![CDATA[Si parla di:ToggleIl 29 aprile 2026, il gruppo TeamPCP ha compromesso i pacchetti npm ufficiali di SAP in quello che i ricercatori di Wiz hanno battezzato “Mini Shai-Hulud”: un attacco alla supply chain enterprise di estrema rilevanza che ha preso di mira gli ambienti di sviluppo e CI/CD di organizzazioni che utilizzano il Cloud Application Programming Model (CAP) e Cloud MTA di SAP. L’operazione si distingue per la sofisticazione del meccanismo di esfiltrazione e per la capacità di rubare credenziali da praticamente ogni sistema cloud aziendale utilizzato dagli sviluppatori colpiti.SAP nell’occhio del ciclone: perché questa supply chain attack è criticaSAP è il backbone ERP di migliaia di aziende enterprise globali. Il suo Cloud Application Programming Model (CAP) è il framework ufficiale per costruire applicazioni cloud-native su SAP Business Technology Platform. Una compromissione dei pacchetti npm di SAP CAP non è, quindi, un attacco a una libreria open source di nicchia: è un’iniezione di malware nel cuore degli ambienti di sviluppo enterprise, con accesso diretto a credenziali di produzione, segreti CI/CD e infrastrutture cloud di organizzazioni Fortune 500.La finestra temporale dell’attacco è stata precisa e calcolata: le versioni malevole dei pacchetti SAP sono state pubblicate su npm il 29 aprile 2026 tra le 09:55 UTC e le 12:14 UTC — un arco di circa due ore e mezza. Questo tipo di timing suggerisce un’operazione pianificata per massimizzare la finestra di esposizione prima che i team di sicurezza potessero reagire, sfruttando le ore mattutine dei fusi orari europei e americani durante le quali i sistemi CI/CD eseguono build automatizzate.Anatomia dell’attacco: da preinstall script a credential stealerIl meccanismo di attacco sfrutta una caratteristica legittima del registry npm: gli script preinstall, che vengono eseguiti automaticamente ogni volta che un pacchetto viene installato come dipendenza. I ricercatori di Socket e Wiz hanno ricostruito la catena di infezione in tre fasi distinte.Fase 1 — Bootstrap con Bun: Lo script preinstall esegue un loader chiamato setup.mjs che scarica da GitHub il runtime JavaScript Bun. L’utilizzo di Bun anziché Node.js è un’indicazione tattica: Bun è meno monitorato dai tool di sicurezza aziendali ed è più difficile da rilevare in ambienti enterprise dove Node.js è già whitelistato. Questo scaricamento di un binary non verificato è di per sé sufficiente per classificare il pacchetto come malevolo.Fase 2 — Execution payload offuscato: Il runtime Bun viene utilizzato per eseguire un payload denominato execution.js, pesantemente offuscato. Il payload implementa logiche di raccolta credenziali e meccanismi anti-analisi per complicare il reverse engineering.Fase 3 — Esfiltrazione crittografata: I dati rubati vengono cifrati con una chiave RSA pubblica hardcoded nel malware e caricati su repository GitHub pubblici creati sull’account della stessa vittima — con la descrizione ironica “A Mini Shai-Hulud has Appeared” (riferimento al verme del deserto di Dune). Questa tecnica di esfiltrazione tramite GitHub è particolarmente insidiosa poiché il traffico verso github.com è raramente bloccato nelle reti aziendali.Tipologia di credenziali rubateIl credential stealer è progettato per aspirare qualsiasi segreto accessibile nell’ambiente dello sviluppatore o del pipeline CI/CD:Token GitHub e npm — accesso ai repository e alle pipeline di deployGitHub Actions secrets — credenziali iniettate nei workflow di CI/CDChiavi SSH — accesso diretto a server e infrastrutturaCredenziali cloud: AWS (access key + secret), Azure (service principal), Google Cloud Platform (service account JSON), Kubernetes (kubeconfig)Segreti CI/CD in memoria — variabili d’ambiente caricate nei processi attivi al momento dell’esecuzioneAttribuzione a TeamPCP: la chiave RSA come firma digitaleWiz attribuisce l’operazione a TeamPCP con alta confidenza. L’elemento chiave è la riutilizzazione della stessa chiave RSA pubblica per cifrare i dati esfiltrati — la medesima chiave impiegata in precedenti compromissioni di librerie attribuite allo stesso gruppo. È un errore operativo significativo da parte degli attaccanti: la chiave di cifratura diventa di fatto una firma identificativa che collega tutte le campagne dello stesso operatore.TeamPCP non è un nuovo arrivato nel panorama degli attacchi alla supply chain npm. Il gruppo ha già condotto operazioni simili contro altre librerie, dimostrando un interesse sistematico per l’ecosistema JavaScript enterprise e un pattern operativo consolidato: compromissione di pacchetti legittimi e ad alta fiducia, payload multistadio con downloader, esfiltrazione tramite servizi cloud legittimi.Il pattern più ampio: tre supply chain attack in 48 oreL’attacco ai pacchetti SAP non è avvenuto in isolamento. GitGuardian ha documentato come nelle stesse 48 ore abbiano colpito campagne analoghe su npm (il pacchetto tanstack contraffatto che esfiltrava file .env), PyPI e Docker Hub — suggerendo un’intensificazione coordinata delle operazioni di supply chain attack verso l’ecosistema di sviluppo software nel suo complesso. Questo tipo di attività “a grappolo” potrebbe indicare un mercato underground più attivo, o una risposta a opportunità specifiche emerse nell’ecosistema open source.Indicatori di Compromissione (IoC)# Pacchetti SAP npm compromessi (versioni malevole - 29 aprile 2026)
# Pubblicati tra 09:55 UTC e 12:14 UTC

# Indicatori infrastrutturali:
# - Loader: setup.mjs (scarica Bun runtime da GitHub)
# - Payload: execution.js (offuscato, eseguito via Bun)
# - Chiave RSA pubblica condivisa con altre campagne TeamPCP

# Pattern di esfiltrazione:
# - Dati caricati su repository GitHub pubblici della vittima
# - Descrizione repository: "A Mini Shai-Hulud has Appeared"
# - Dati cifrati con RSA prima dell'upload

# File target:
.env
.env.local
.env.production
~/.ssh/id_rsa
~/.aws/credentials
~/.kube/config

# Riferimenti:
# Socket: https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
# Wiz: https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
# BleepingComputer: https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/Raccomandazioni immediate per i difensoriChi utilizza pacchetti SAP CAP o Cloud MTA nel proprio ambiente di sviluppo deve agire immediatamente su più fronti. Il primo passo è verificare le versioni installate nei propri progetti e disinstallare qualsiasi versione pubblicata il 29 aprile 2026: eseguire npm audit e confrontare le versioni con il changelog ufficiale SAP. In secondo luogo, è necessario trattare tutte le credenziali presenti negli ambienti di sviluppo e CI/CD come potenzialmente compromesse: ruotare token GitHub, chiavi AWS/Azure/GCP, credenziali npm e kubeconfig.A livello organizzativo, questo attacco riporta all’attenzione la necessità di implementare policy di Software Composition Analysis (SCA) nei pipeline CI/CD, con blocco automatico di pacchetti che eseguono script preinstall o scaricano binary da sorgenti esterne. L’adozione di soluzioni come Socket, Wiz o Snyk per il monitoraggio in real-time delle dipendenze npm rappresenta oggi una misura non più opzionale per chi gestisce ambienti enterprise basati su Node.js.Fonti: Socket Research Team, Wiz Security Blog, BleepingComputer, GitGuardian Blog — 29-30 aprile 2026.]]></description><link>https://forum.androidiani.net/topic/872f4603-a90a-4dd7-adce-3830ba4a6ff7/mini-shai-hulud-teampcp-compromette-i-pacchetti-npm-ufficiali-di-sap-in-un-attacco-supply-chain-enterprise</link><guid isPermaLink="true">https://forum.androidiani.net/topic/872f4603-a90a-4dd7-adce-3830ba4a6ff7/mini-shai-hulud-teampcp-compromette-i-pacchetti-npm-ufficiali-di-sap-in-un-attacco-supply-chain-enterprise</guid><dc:creator><![CDATA[blog@insicurezzadigitale.com]]></dc:creator><pubDate>Thu, 30 Apr 2026 15:30:41 GMT</pubDate></item></channel></rss>