Spcnet.it

2026-07-03 15:16:09

GitHub Copilot CLI: selezione automatica del modello AI con HyDRA per task routing intelligente

GitHub ha aggiornato il Copilot Command Line Interface (CLI) introducendo una nuova funzionalità di selezione automatica del modello AI: a partire dal 1° luglio 2026, Copilot CLI può scegliere autonomamente il modello più adatto per ogni richiesta grazie a un sistema interno chiamato HyDRA (Hybrid Dynamic Routing Architecture). Vediamo nel dettaglio come funziona e cosa cambia per sviluppatori e amministratori di sistema.

Come funziona la selezione automatica del modello

Il cuore della novità è il routing intelligente. Quando si usa la modalità Auto in Copilot CLI, HyDRA analizza ogni richiesta lungo più dimensioni prima di scegliere il modello:

• Profondità di ragionamento richiesta: un semplice completamento di codice non ha bisogno dello stesso modello di una diagnosi complessa di bug.
• Complessità di generazione del codice: snippet elementari vs. architetture multi-file.
• Difficoltà di debugging: analisi di stack trace o errori runtime con molte variabili contestuali.
• Necessità di orchestrazione di tool: quanti tool call sono necessari e quanto complessa è la loro concatenazione.

Oltre all’analisi del task, HyDRA considera in tempo reale la disponibilità e la salute dei modelli (latenza, tasso di errore, saturazione) per garantire un’esperienza affidabile anche sotto carico elevato.

Token efficiency e cache hit rate

Uno degli obiettivi principali di HyDRA è ridurre lo spreco di token. Il sistema rispetta i confini naturali della cache: anziché spezzare il contesto in modo arbitrario, le richieste vengono strutturate per massimizzare il tasso di cache hit del prompt, riducendo la latenza complessiva e i costi.

Nei test interni di GitHub, questo approccio ha prodotto guadagni significativi di token efficiency senza regressione qualitativa: non tutti i task richiedono un modello ad alta densità di ragionamento, e selezionare il modello “giusto” per compiti semplici libera capacità per quelli complessi.

Impatto economico: sconto del 10% sugli AI credit

Per i piani a pagamento, l’uso della modalità Auto porta un beneficio economico diretto:

• Sconto del 10% sul costo in AI credit rispetto all’uso diretto dello stesso modello.
• Per i piani annuali legacy (Copilot Pro e Pro+) ancora su billing a premium request: lo sconto si applica al model multiplier. Ad esempio, un modello con moltiplicatore 1x consuma 0,9 premium request invece di 1.

Questo significa che scegliere Auto non è solo conveniente in termini di qualità, ma anche economicamente vantaggioso rispetto alla selezione manuale.

Deferred tool loading: meno overhead per ogni prompt

La stessa release introduce il caricamento differito dei tool (deferred tool loading). Tradizionalmente, ogni prompt includeva gli schema completi di tutti i tool disponibili, anche se la maggior parte non veniva utilizzata. Con il nuovo approccio, le definizioni dei tool vengono recuperate on demand, riducendo il numero di token inviati per ogni richiesta e accelerando l’elaborazione.

Controllo dell’utente e policy di amministrazione

La modalità automatica non significa perdita di controllo:

• Override manuale: in qualsiasi momento è possibile usare il comando /model per selezionare esplicitamente un modello specifico o un provider diverso.
• Policy aziendali: gli amministratori possono imporre l’uso della selezione automatica tramite policy organizzative, garantendo uniformità e rispetto dei requisiti di costo o sicurezza.
• Accesso multi-modello: Auto sfrutta modelli da più famiglie (OpenAI, Anthropic, Mistral, ecc.) a seconda del tipo di abbonamento e delle policy configurate.

Come iniziare

Non è richiesta alcuna configurazione: basta aggiornare Copilot CLI all’ultima versione e selezionare la modalità Auto. GitHub prevede che i modelli disponibili in Auto cambieranno nel tempo, man mano che nuovi modelli saranno integrati nella piattaforma.

# Aggiorna Copilot CLI (se installato via npm)
npm update -g @github/copilot-cli

# Oppure verifica la versione corrente
gh copilot --version

# Nel CLI, seleziona la modalità Auto con il comando /model
# e poi inizia a lavorare normalmente
gh copilot suggest "come creo un Dockerfile multi-stage per .NET 8?"

Considerazioni per team e organizzazioni

Per i team che usano Copilot CLI in contesti enterprise, la funzionalità porta vantaggi concreti:

• Prevedibilità dei costi: la combinazione di routing intelligente e sconto del 10% rende più prevedibile il consumo di AI credit per team numerosi.
• Centralizzazione delle policy: gli admin possono gestire il comportamento del routing da un unico punto di controllo, senza che ogni sviluppatore debba configurare nulla localmente.
• Conformità: le policy di model selection possono essere usate per rispettare requisiti di compliance (es. usare solo modelli ospitati in certi data center o appartenenti a certi vendor).

Conclusione

La selezione automatica del modello in Copilot CLI rappresenta un passo avanti significativo verso un’esperienza AI developer veramente adattiva. HyDRA non si limita a scegliere il modello “migliore” in astratto, ma lo sceglie in base al contesto reale della richiesta, ottimizzando contemporaneamente qualità, latenza e costo. Per chi usa Copilot CLI come parte del workflow quotidiano, la modalità Auto è ora la scelta di default più sensata.

---

Fonte: GitHub Changelog – Copilot CLI auto model selection routes based on task

Copilot CLI auto model selection routes based on task - GitHub Changelog

Editor’s note (July 1, 2026): Updated the premium request costs to reference AI credits. GitHub Copilot auto model selection now routes to the best model for your task in Copilot…

^{Allison (The GitHub Blog)}

(in)sicurezza digitale

2026-07-03 15:15:07

Pegasus spia chi indaga su Pegasus: il caso Kouloglou scuote il Parlamento Europeo

Si parla di:
Toggle

C’è un dettaglio che rende il caso di Stelios Kouloglou diverso da tutti gli altri scandali Pegasus degli ultimi anni: l’eurodeputato greco non era una vittima qualsiasi, ma il membro di una commissione d’inchiesta del Parlamento Europeo istituita proprio per indagare sugli abusi dello spyware commerciale. Secondo un report pubblicato il 3 luglio 2026 dal Citizen Lab dell’Università di Toronto, il telefono di Kouloglou è stato infettato con Pegasus nell’ottobre 2022 e almeno altre due volte nel marzo 2023, proprio nei momenti cruciali della stesura del rapporto finale della commissione PEGA. È la prima volta che un membro della commissione viene pubblicamente identificato come bersaglio dello stesso strumento che era chiamato a indagare.

La commissione PEGA e il suo bersaglio interno

La commissione d’inchiesta PEGA (Pegasus and Surveillance Spyware) è stata istituita dal Parlamento Europeo nel marzo 2022, dopo che un consorzio internazionale di giornalisti aveva rivelato l’uso diffuso dello spyware Pegasus di NSO Group contro giornalisti, avvocati, attivisti e politici in diversi Stati membri, tra cui Ungheria, Polonia, Spagna e Grecia. Kouloglou, giornalista ed ex parlamentare di SYRIZA, sedeva nella commissione mentre questa raccoglieva testimonianze e redigeva le prime bozze del suo rapporto, concentrate in particolare sugli abusi documentati a Cipro, Grecia, Ungheria, Polonia e Spagna.

Il fatto che proprio lui sia finito nel mirino, mentre la commissione lavorava a conclusioni che avrebbero potuto imbarazzare governi europei, ha immediatamente sollevato interrogativi sulla natura dell’attacco. Un eurodeputato in carica ha definito l’episodio “un attacco diretto allo stato di diritto”, chiedendo alla Commissione Europea di imporre limiti stringenti all’uso dello spyware nei 27 Stati membri. La Commissione, contattata dai giornalisti, non ha risposto.

Timeline degli attacchi: due finestre, due momenti chiave

Il Citizen Lab ha ricostruito con precisione forense due finestre di compromissione, entrambe coincidenti con fasi decisive del lavoro della commissione:

• 21 ottobre 2022 — Prima infezione confermata, nel pieno delle discussioni via email e messaggistica di ottobre-novembre 2022, in vista della consegna della prima bozza del rapporto sugli abusi in Cipro, Grecia, Ungheria, Polonia e Spagna. Il momento coincide inoltre con un ricovero ospedaliero di Kouloglou per un intervento chirurgico programmato, circostanza che potrebbe aver permesso agli operatori dello spyware di intercettare anche conversazioni ambientali relative alla sua salute o scambi con i visitatori.
• 6-7 marzo 2023 — Due ulteriori infezioni, mentre Kouloglou viaggiava da Atene a Bruxelles per le audizioni della commissione, mesi prima dell’adozione finale del rapporto scritto.

Kouloglou ha raccontato ai giornalisti di TechCrunch la rabbia provata nello scoprire la compromissione: “Ti rendi conto che tutti i tuoi dati personali sono stati presi — non solo gli scambi professionali o i messaggi con i ministri, ma anche le cose molto private, i momenti felici e quelli tristi”. L’eurodeputato ha annunciato l’intenzione di citare in giudizio NSO Group.

PWNYOURHOME: l’exploit zero-click che passa da HomeKit

Dal punto di vista tecnico, l’infezione del 2022 sfrutta una catena di exploit già documentata dal Citizen Lab in precedenti ricerche e nota con il nome in codice PWNYOURHOME, attiva contro iOS 15 e iOS 16 a partire da ottobre 2022. Si tratta di un exploit zero-click in due fasi che colpisce due processi distinti del sistema operativo iPhone: il primo stadio prende di mira il framework HomeKit — il sistema Apple per la gestione della smart home — mentre il secondo stadio sfrutta iMessage per ottenere l’esecuzione di codice e l’installazione dello spyware.

La vulnerabilità sfruttata riguarda un problema di deserializzazione in NSKeyedUnarchiver, una classe già abusata in precedenti catene di exploit zero-click contro iMessage. Poiché non richiede alcuna interazione da parte della vittima, il bersaglio non riceve notifiche, non deve cliccare link né aprire allegati: lo spyware si installa silenziosamente, consentendo l’accesso a messaggi, cronologia delle chiamate, dati di geolocalizzazione, foto e — nel caso dei modelli più recenti — anche all’attivazione da remoto di microfono e fotocamera.

Apple ha corretto le falle sfruttate da PWNYOURHOME con il rilascio di iOS 16.3.1, introducendo tra l’altro un nuovo controllo che rifiuta di decodificare determinati messaggi HomeKit a meno che non provengano da una fonte plausibile. Il problema, come spesso accade con gli attacchi Pegasus, è che l’aggiornamento correttivo non era ancora installato sul dispositivo di Kouloglou al momento dell’attacco dell’ottobre 2022 — una finestra di esposizione che gli operatori dello spyware hanno sfruttato attivamente.

Un cliente governativo con licenza multi-paese

Il Citizen Lab non ha attribuito pubblicamente l’attacco a un governo specifico, ma un dettaglio tecnico rende il quadro più inquietante: l’indirizzo email utilizzato come vettore d’infezione da chi ha colpito Kouloglou è lo stesso già osservato in una precedente campagna che aveva infettato i telefoni di giornalisti in diversi paesi europei. Il riutilizzo dello stesso indirizzo — e quindi, presumibilmente, della stessa infrastruttura di comando e controllo — suggerisce che il cliente governativo di NSO Group disponesse di un’autorizzazione per operare lo spyware Pegasus contro bersagli in più Stati membri dell’Unione Europea, non in uno soltanto.

Questo elemento è cruciale per il dibattito politico che ne è seguito: se la licenza NSO copre operazioni cross-border all’interno dello spazio europeo, i meccanismi di controllo nazionale sull’export e sull’uso dello spyware — già ritenuti insufficienti dallo stesso rapporto PEGA — risultano ancora più permeabili di quanto documentato finora.

NSO Group tra sanzioni USA e tentativi di riabilitazione

NSO Group resta in gran parte bandita dall’uso governativo negli Stati Uniti, a seguito di un ordine esecutivo dell’amministrazione Biden che vieta l’impiego federale di spyware commerciale capace di violare i diritti umani. Nel 2025 l’azienda israeliana ha confermato che un gruppo di investitori statunitensi non identificato ha versato decine di milioni di dollari nella società, in quella che gli osservatori hanno letto come un tentativo di riabilitare il marchio NSO in vista di un possibile ingresso nel mercato americano — un percorso già criticato per la scarsa trasparenza degli impegni dichiarati dall’azienda.

Il caso Kouloglou arriva quindi in un momento delicato: mentre NSO cerca legittimazione commerciale, un membro della stessa commissione UE nata per indagarla diventa l’ennesima prova pubblica che gli abusi non si sono fermati.

Implicazioni e due righe per i difensori

Per chi opera in ruoli ad alto rischio — parlamentari, giornalisti, avvocati per i diritti umani, ricercatori di sicurezza, dissidenti — il caso conferma alcune priorità difensive ormai consolidate ma spesso disattese:

• Aggiornamenti tempestivi: gli exploit zero-click di Pegasus sfruttano quasi sempre vulnerabilità già note ma non ancora patchate sul dispositivo bersaglio. Applicare gli aggiornamenti iOS entro 24-48 ore dalla pubblicazione riduce drasticamente la finestra di esposizione.
• Lockdown Mode: la modalità di isolamento introdotta da Apple su iOS disabilita molte delle superfici di attacco usate dagli exploit zero-click (inclusi determinati messaggi HomeKit e allegati iMessage complessi), ed è fortemente consigliata per soggetti ad alto rischio.
• Verifica forense periodica: strumenti open source come Mobile Verification Toolkit (MVT), sviluppato da Amnesty International, permettono di analizzare backup iOS/Android alla ricerca di indicatori di compromissione noti legati a Pegasus e spyware simili.
• Riavvii regolari del dispositivo: molte varianti di Pegasus non sopravvivono a un riavvio senza reinfezione, complicando la persistenza per gli attaccanti — una contromisura semplice ma efficace in assenza di altre difese.
• Segnalazione a Citizen Lab o Access Now: chi sospetta di essere bersaglio di spyware commerciale può richiedere supporto tecnico gratuito attraverso l’Access Now Digital Security Helpline.

Il caso Kouloglou dimostra ancora una volta che lo spyware di livello statale non conosce eccezioni istituzionali: nemmeno chi indaga sugli abusi è al riparo dal diventarne bersaglio. Per il Parlamento Europeo, la domanda che resta aperta è se le raccomandazioni della stessa commissione PEGA — largamente rimaste lettera morta — troveranno finalmente attuazione concreta.

Indicatori tecnici e riferimenti

Spyware: NSO Group Pegasus
Catena di exploit: PWNYOURHOME (zero-click, iOS 15/16)
Vettori sfruttati: HomeKit (stage 1) + iMessage/NSKeyedUnarchiver (stage 2)
Patch correttiva: iOS 16.3.1

Date di compromissione confermate (dispositivo Kouloglou):
- 21 ottobre 2022
- 6 marzo 2023
- 7 marzo 2023

Strumenti di verifica consigliati:
- Mobile Verification Toolkit (MVT) - github.com/mvt-project/mvt
- Access Now Digital Security Helpline

Fonte primaria: Citizen Lab, University of Toronto
"Member of Committee Investigating Spyware Hacked With Pegasus" (3 luglio 2026)

netzpolitik.org

2026-07-02 12:53:38

Die Spitzen von Union und SPD wollen die Informationsfreiheit massiv einschränken. Die Zivilgesellschaft zeigt sich entsetzt und spricht vom „schwersten Angriff auf staatliche Transparenz“. #ifg

netzpolitik.org/2026/informati…

Schwarz-Rot plant Frontalangriff auf Journalismus und Transparenz

^{Daniel Leisegang (netzpolitik.org)}

(in)sicurezza digitale

2026-07-02 12:56:32

L’intelligence russa punta a Signal e WhatsApp: USA offre 10 milioni per i gruppi UNC5792 e UNC4221

Si parla di:
Toggle

Il Dipartimento di Stato americano ha messo sul piatto 10 milioni di dollari per chi fornira’ informazioni utili a identificare o localizzare i membri dei gruppi UNC5792 e UNC4221, entrambi legati ai servizi di intelligence militare e al FSB russo. Nel frattempo, FBI e CISA hanno aggiornato il loro advisory di marzo 2026 con una nuova tattica individuata nella campagna: il furto delle Signal Backup Recovery Key, che consente agli attaccanti di accedere all’intera cronologia dei messaggi delle vittime.

Chi sono UNC5792 e UNC4221

I due gruppi, tracciati pubblicamente con i designatori UNC di Mandiant/Google, operano nell’ambito dei servizi segreti russi. UNC5792 e’ associato all’FSB (Federal Security Service), in particolare agli ufficiali embedded nelle Guardie di Frontiera russe; UNC4221 opera invece per conto dei servizi militari russi. Le attivita’ delle due entita’ si sovrappongono parzialmente: entrambi prendono di mira individui di alto valore informativo attraverso campagne di phishing su applicazioni di messaggistica, in particolare Signal e WhatsApp.

Il profilo delle vittime e’ estremamente specifico e rivela gli obiettivi dell’intelligence russa: funzionari governativi statunitensi e NATO (attuali ed ex), vertici militari, figure politiche, analisti di policy, giornalisti che coprono Russia e Ucraina, ONG attive in supporto all’Ucraina e ricercatori di sicurezza o esperti di affari russi. Secondo l’annuncio ufficiale del programma Rewards for Justice, migliaia di account individuali sono stati compromessi in questo modo.

La storia della campagna: dall’account linking al furto delle Recovery Key

La campagna non nasce oggi. Il primo advisory pubblico di FBI e CISA risale a marzo 2026, quando gli analisti avevano documentato una tecnica di compromissione basata sull’abuso della funzione legittima di device linking di Signal. Gli attaccanti, spacciandosi per il supporto di Signal, inducevano le vittime a collegare un dispositivo controllato dagli attaccanti al proprio account, consentendo la lettura in tempo reale delle conversazioni senza compromettere la crittografia end-to-end del protocollo.

L’advisory aggiornato del 26 giugno 2026 documenta l’evoluzione della tattica. Gli operatori hanno ora spostato il loro obiettivo primario: non piu’ solo l’intercettazione in tempo reale, ma il furto delle Signal Backup Recovery Key — le chiavi che proteggono le copie cifrate dell’intera cronologia dei messaggi nei server Signal Secure Backups. Si tratta di un cambio di paradigma operativo significativo: con la Recovery Key, l’attaccante puo’ recuperare su un proprio dispositivo tutti i messaggi storici della vittima, incluse conversazioni private e di gruppo potenzialmente risalenti a mesi o anni.

Come funziona l’attacco in dettaglio

La catena di attacco si articola in due fasi di social engineering, entrambe condotte direttamente su Signal spacciandosi per il team di supporto della piattaforma:

Fase 1: il pretesto

La vittima riceve un messaggio che afferma che Signal ha registrato un’ondata di attacchi da parte di “hacker iraniani e di paesi post-sovietici” e che, in risposta, la piattaforma sta introducendo una verifica obbligatoria a due fattori. Per “non perdere messaggi e media”, l’utente viene guidato passo per passo ad abilitare i backup e a visualizzare la propria Recovery Key:

Istruzioni fornite dagli attaccanti nel messaggio di phishing:
Settings -> Backups -> Enable backups -> View recovery key
-> Copy to clipboard -> Next -> Enter the recovery key
-> Next -> Continue -> Choose your backup plan

[Premere "Accept" nel pop-up]

Questa sequenza e’ reale: seguendo questi passi, l’utente attiva effettivamente Signal Secure Backups e genera una Recovery Key legittima. La chiave viene copiata negli appunti del dispositivo.

Fase 2: l’estrazione della chiave

Poco dopo, sempre spacciandosi per Signal, gli attaccanti inviano un secondo messaggio urgente che avvisa l’utente di un “problema di sincronizzazione” che metterebbe a rischio la perdita permanente dei dati. Per “risolvere il problema”, vengono chiesti di andare nelle impostazioni di backup, copiare la Recovery Key e incollarla nel messaggio di chat. Se la vittima esegue, gli attaccanti ottengono la chiave in chiaro.

Con la Recovery Key in mano, gli attaccanti possono ripristinare il backup cifrato su qualsiasi loro dispositivo, scaricando l’intera cronologia messaggi della vittima dai server di Signal. L’operazione e’ completamente silenziosa per la vittima: nessuna notifica, nessun alert sul dispositivo.

La trappola del recovery: perche’ cambiare account non basta

FBI e CISA sottolineano un aspetto critico spesso sottovalutato: se un attaccante ottiene la Recovery Key di un utente, creare un nuovo account Signal con lo stesso numero di telefono non invalida la chiave compromessa. L’attaccante puo’ continuare a utilizzare quella chiave per scaricare i backup gia’ acquisiti, anche dopo che la vittima ha cambiato account.

L’unica azione risolutiva e’ generare una nuova Recovery Key attraverso le impostazioni di backup di Signal, che invalida la chiave precedente per i download futuri. Tuttavia — e questa e’ la parte piu’ critica — una nuova chiave non impedisce l’accesso ai backup che l’attaccante ha gia’ scaricato prima del cambio.

Il bounty e gli obiettivi del programma Rewards for Justice

Il programma statunitense Rewards for Justice (RFJ) ha pubblicato il 29 giugno 2026 un annuncio specifico per UNC5792 e UNC4221, offrendo fino a 10 milioni di dollari per informazioni su:

• Identita’, localizzazione, affiliazioni e biografie dei membri dei gruppi e del personale di supporto.
• Legami con i servizi di intelligence russi, contractor e fornitori terzi.
• Infrastruttura operativa: domini, server, hosting, strumenti, framework e software.
• Fonti di finanziamento, conti bancari, meccanismi di pagamento.
• Wallet di criptovaluta, transazioni blockchain e reti finanziarie a supporto delle operazioni.

L’entita’ del bounty — identica a quella offerta per i responsabili di attacchi ransomware contro infrastrutture critiche — segnala quanto Washington consideri questa campagna una minaccia alla sicurezza nazionale, non un semplice problema di cybercrime.

Il fronte ucraino: SMS fasulli per rubare credenziali

Parallelamente all’advisory FBI/CISA, l’Ucraina ha confermato che l’intelligence russa ha utilizzato falsi messaggi SMS di “supporto tecnico” per indurre utenti ucraini a rivelare le credenziali dei propri account di messaggistica. La tattica e’ la stessa: impersonare un servizio tecnico legittimo, creare urgenza attraverso una narrativa di sicurezza, estrarre credenziali o chiavi di backup. Il coordinamento tra le due campagne — quella focalizzata su obiettivi occidentali (UNC5792/UNC4221) e quella contro obiettivi ucraini — suggerisce un’operazione di intelligence integrata sotto ombrello comune.

Consigli pratici per i difensori e gli utenti a rischio

Signal e le sue comunicazioni cifrate restano tecnicamente integre: la crittografia end-to-end del protocollo Signal non e’ stata compromessa. Il vettore e’ esclusivamente il social engineering applicato alla gestione delle chiavi. Le misure di difesa piu’ efficaci sono le seguenti:

• Non condividere mai la Recovery Key: Signal non la chiedera’ mai via messaggio in-app. Qualsiasi richiesta in tal senso e’ un attacco.
• Verificare l’identita’ del mittente: il supporto Signal comunica esclusivamente tramite indirizzi email ufficiali, mai tramite messaggi in-app.
• Controllare i dispositivi collegati: in Settings > Account > Linked Devices, verificare periodicamente che non siano presenti dispositivi non riconosciuti.
• Ruotare la Recovery Key in caso di sospetto: Settings > Backups > Recovery Key > Create new key. Ricordarsi che i backup gia’ scaricati dall’attaccante rimangono accessibili con la vecchia chiave.
• Segnalare attivita’ sospette all’IC3 dell’FBI (ic3.gov) o al proprio ufficio locale FBI.

Per le organizzazioni con personale ad alto rischio (giornalisti, diplomatici, ricercatori, personale ONG), e’ consigliabile implementare sessioni di awareness specifica sulla gestione delle Recovery Key di Signal e sul riconoscimento di questo pattern di social engineering, ormai sufficientemente documentato da considerarsi una tecnica consolidata nel repertorio dell’intelligence russa.

(in)sicurezza digitale

2026-07-02 12:54:21

Da un runner Jenkins ad Amazon Redshift: come il worm Shai-Hulud trasforma una CI/CD in una breach cloud

Si parla di:
Toggle

Un worm nato per infettare pacchetti npm, pensato per propagarsi da un progetto all’altro sottraendo token di pubblicazione, si è trasformato in un vettore capace di arrivare fino a un data warehouse Amazon Redshift in produzione. È la traiettoria che i ricercatori di FortiGuard Labs hanno ricostruito analizzando una compromissione partita da un semplice runner Jenkins esposto: nel giro di poche ore, l’attaccante è passato da un job di build a pieni poteri amministrativi sull’intero account AWS.

Shai-Hulud: la storia del worm che ha terrorizzato npm

Battezzato con il nome dei vermi delle sabbie di Dune, Shai-Hulud è emerso per la prima volta alla fine del 2025 come campagna di supply chain attack contro l’ecosistema npm, e da allora è stato attribuito al cluster tracciato come TeamPCP. Il meccanismo è quello del worm classico: un pacchetto compromesso esegue codice malevolo durante l’installazione o all’interno di una pipeline CI, ruba i token e le credenziali di build presenti sulla macchina, e li usa per pubblicare versioni trojanizzate di altri pacchetti di cui il maintainer ha accesso — propagandosi così, in autonomia, lungo l’intero grafo delle dipendenze.

La variante più recente, Shai-Hulud 2.0, ha alzato ulteriormente l’asticella: all’infezione di un pacchetto legittimo vengono iniettati due file, setup_bun.js e bun_environment.js, attivati tramite uno script di preinstall (anziché postinstall come nella prima ondata) — una modifica che amplia sensibilmente la superficie di impatto perché il codice malevolo scatta prima ancora che l’installazione del pacchetto sia completa. Il payload offuscato raccoglie credenziali da oltre 100 percorsi di file diversi, spaziando da provider cloud a wallet di criptovalute, tool AI e app di messaggistica, e installa hook di persistenza dentro Claude Code, VS Code e servizi a livello di sistema operativo, capaci di sopravvivere al riavvio della macchina. Secondo le stime della community, la campagna 2.0 ha compromesso almeno 796 pacchetti npm unici (1.092 versioni), toccando oltre 25.000 repository riconducibili a circa 350 maintainer.

Dal runner Jenkins a Redshift: la ricostruzione di FortiGuard Labs

Il caso analizzato da FortiCNAPP nasce a metà maggio 2026, quando gli analisti individuano su un ambiente cliente l’accesso persistente a un Jenkins runner con un pattern di credential-harvesting coerente con Shai-Hulud. Il runner, raggiungibile da internet, viene usato dall’attaccante come testa di ponte: sfruttando il ruolo IAM associato al job Jenkins, l’operatore compie un’escalation di privilegi fino a ottenere pieno accesso amministrativo sull’account cloud, dopodiché modifica i controlli di rete del database e avvia l’estrazione di dati da Amazon Redshift.

La sequenza operativa ricostruita da FortiGuard Labs è particolarmente istruttiva perché mostra quanto velocemente un accesso CI/CD apparentemente marginale possa tradursi in un data breach cloud su vasta scala:

• Creazione di un utente IAM con nome cloudops-monitor, pensato per confondersi con account di monitoraggio legittimi.
• Attribuzione della policy AdministratorAccess al nuovo utente ed emissione di access key.
• Modifica dei security group per allargare l’accesso di rete verso i database.
• Tentativi di modifica della configurazione di accesso a RDS e Redshift.
• Enumerazione sistematica di AWS Secrets Manager, con recupero dei secret collegati al data warehouse.
• Uso ripetuto della Redshift Data API (chiamate ExecuteStatement, DescribeStatement e successivo recupero dei risultati) per interrogare ed esfiltrare dati senza bisogno di una connessione diretta al cluster.
• Creazione di policy IAM con nomi espliciti dal chiaro intento di esfiltrazione, assunzione di ruoli con session name come exfil, e uso di SSM SendCommand insieme alla verifica di identità su Amazon SES — probabilmente in preparazione di un canale di invio dati o notifiche verso l’esterno.

Questa catena mostra un salto qualitativo rispetto alle prime campagne Shai-Hulud, centrate quasi esclusivamente sul furto di token npm e credenziali di sviluppatori: qui l’obiettivo finale è chiaramente il dato strutturato in un data warehouse aziendale, raggiunto attraverso l’abuso sistematico dei permessi IAM disponibili nella pipeline compromessa.

Perché la CI/CD è il bersaglio ideale

I runner Jenkins, GitHub Actions e sistemi CI/CD analoghi sono per costruzione dei nodi ad alto privilegio: hanno bisogno di credenziali per pubblicare pacchetti, effettuare il deploy su infrastruttura cloud e interagire con registry e repository. Quando queste credenziali sono sovradimensionate rispetto al reale bisogno — un ruolo IAM che consente escalation invece di essere ristretto al minimo indispensabile — un singolo pacchetto npm compromesso durante una build automatica può bastare per compiere il salto da “sviluppatore infettato” a “amministratore dell’intero account cloud”. È esattamente lo scenario che rende Shai-Hulud diverso da un comune infostealer: non si limita a rubare, usa quello che ruba per muoversi lateralmente e scalare privilegi in autonomia.

Raccomandazioni per i difensori

• Applicare il principio del minimo privilegio ai ruoli IAM usati dai runner CI/CD: nessun job di build dovrebbe poter assumere ruoli con permessi di amministrazione dell’account.
• Isolare i runner Jenkins/CI da internet o proteggerli dietro autenticazione forte e reti segmentate.
• Monitorare la creazione di utenti/ruoli IAM anomali, in particolare l’attribuzione di AdministratorAccess a identità nuove o non previste nell’infrastructure-as-code.
• Alert su chiamate massive alla Redshift Data API o pattern insoliti di query su data warehouse da identità di servizio.
• Verificare l’eventuale presenza degli script setup_bun.js e bun_environment.js in node_modules, e controllare gli script di preinstall dei pacchetti recentemente aggiornati.
• Applicare lockfile e pinning delle versioni, con verifica delle firme dei pacchetti dove disponibile, per limitare l’impatto di aggiornamenti automatici malevoli.
• Ruotare immediatamente tutte le credenziali (token npm, chiavi AWS, secret in Secrets Manager) se si sospetta una compromissione, anche parziale, della toolchain di sviluppo.

Il caso ricostruito da FortiGuard Labs è un promemoria scomodo: la supply chain del software open source non è più solo un problema di sviluppatori, ma un vettore diretto verso i dati più sensibili dell’azienda, quando la fiducia implicita accordata alle pipeline di build non è accompagnata da controlli granulari sui permessi cloud.

Indicatori di compromissione

Malware: Shai-Hulud / Shai-Hulud 2.0 (worm supply chain, ecosistema npm/PyPI)
Attore: TeamPCP (cluster tracciato)

File iniettati nei pacchetti compromessi:
  setup_bun.js
  bun_environment.js
Trigger: script "preinstall" (2.0) invece di "postinstall" (1.0)

Scala campagna 2.0 (stime community):
  796+ pacchetti npm unici compromessi
  1.092 versioni di pacchetto interessate
  25.000+ repository coinvolti
  ~350 maintainer impattati

Catena post-compromissione osservata da FortiGuard Labs (caso Jenkins -> Redshift):
  - Nuovo utente IAM: cloudops-monitor
  - Policy attribuita: AdministratorAccess
  - Modifica security group per esporre database
  - Enumerazione AWS Secrets Manager
  - Uso Redshift Data API: ExecuteStatement / DescribeStatement
  - Ruoli assunti con session name: "exfil"
  - Attività su SSM SendCommand e verifica identità Amazon SES

Persistenza osservata su endpoint sviluppatore:
  Hook in Claude Code, VS Code, servizi OS-level (sopravvivono al reboot)

Riferimento tecnico: FortiGuard Labs,
"From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach"

(in)sicurezza digitale

2026-07-02 12:55:36

ShinyHunters e lo zero-day PeopleSoft: il regolatore assicurativo USA tra le 100+ vittime di UNC6240

Si parla di:
Toggle

Per due settimane, prima ancora che Oracle pubblicasse una patch, un gruppo di cybercriminali ha avuto le chiavi di oltre cento infrastrutture PeopleSoft in tutto il mondo. Tra le vittime finite nella rete c’è la National Association of Insurance Commissioners (NAIC), l’organizzazione che coordina la vigilanza assicurativa dei 50 stati USA: 3,1 terabyte di dati pubblicati online, agenzie di rating che hanno sospeso i feed verso il regolatore, e la firma inconfondibile di ShinyHunters, oggi meglio nota agli analisti come UNC6240.

Chi c’è dietro l’attacco: da ShinyHunters a Scattered LAPSUS$ Hunters

ShinyHunters non è un nome nuovo per chi segue il cybercrime dei data breach: attivo almeno dal 2019 e comparso pubblicamente nel maggio 2020 con la vendita di dati sottratti a oltre una dozzina di aziende, il gruppo ha costruito la propria reputazione sul modello “pay or leak” — contatto privato con la vittima, richiesta di riscatto, pubblicazione dei dati in caso di rifiuto. Dal 2025 ShinyHunters opera in una struttura più ampia e fluida, la cosiddetta Scattered LAPSUS$ Hunters (SLH), un’alleanza informale che unisce le competenze di Scattered Spider (accesso iniziale tramite social engineering e SIM swap), LAPSUS$ (estorsione ad alta visibilità mediatica) e ShinyHunters stesso, specializzato in exfiltration su larga scala e gestione dei data leak site. È la stessa federazione già dietro le violazioni a catena di Salesforce e Snowflake nel 2025.

Mandiant e il Google Threat Intelligence Group tracciano il cluster responsabile della campagna PeopleSoft con la sigla UNC6240, confermando la sovrapposizione operativa con ShinyHunters.

CVE-2026-35273: RCE non autenticata nel cuore di PeopleSoft

Il vettore d’ingresso è una vulnerabilità critica (CVSS 9.8) in Oracle PeopleSoft Enterprise PeopleTools, versioni 8.61 e 8.62, localizzata nel componente Environment Management Hub, noto anche come PSEMHUB. Tecnicamente si tratta di una Server-Side Request Forgery che, incatenata correttamente, consente l’esecuzione di codice remoto senza alcuna autenticazione né interazione dell’utente: basta accesso di rete via HTTP agli endpoint /PSEMHUB/hub e /PSIGW/HttpListeningConnector per prendere il controllo del server.

Il dettaglio più inquietante è la tempistica. Secondo Mandiant, lo sfruttamento attivo in the wild è iniziato il 27 maggio 2026, ben prima che Oracle rilasciasse un advisory di sicurezza: un vero zero-day, sfruttato per circa due settimane a insaputa dei difensori. Solo il 10 giugno 2026 Oracle ha pubblicato una patch fuori banda (Patch Availability Document CPU187), poi confluita nel Critical Patch Update di giugno. Nel frattempo, CISA ha aggiunto la falla al proprio catalogo Known Exploited Vulnerabilities.

Una campagna su scala industriale

Tra il 27 maggio e il 9 giugno gli attaccanti hanno colpito circa 300 istanze PeopleSoft appartenenti a oltre 100 organizzazioni, con il 68% delle vittime concentrato nel settore dell’istruzione superiore, in gran parte negli Stati Uniti. Il gruppo ha pubblicato i dati sottratti sul proprio data leak site già il 9 giugno, un giorno prima ancora della patch ufficiale.

Sul piano operativo, gli attaccanti hanno predisposto ambienti di staging che ospitavano agenti MeshCentral camuffati da servizi Microsoft Azure legittimi (file come meshagent64-azure-ops.exe), utilizzati per eseguire query amministrative ed effettuare movimento laterale. Un elemento tecnico rilevante è lo script di defacement e lateral movement che automatizza il credential spraying via SSH: analizza il file /etc/hosts locale per identificare host interni secondo pattern di naming specifici, poi tenta l’autenticazione con una lista predefinita di credenziali amministrative e applicative comuni.

Il caso NAIC: cosa è stato sottratto

NAIC ha rilevato l’accesso non autorizzato al proprio ambiente PeopleSoft l’11 giugno 2026. ShinyHunters ha rivendicato il furto di 3,1 terabyte di dati, oltre 105.000 file: più di 264.000 PDF di filing regolatori assicurativi (rami property, casualty, health e life) relativi al periodo 2017-2024, circa 45.000 file provenienti da importanti agenzie di rating creditizio (tra cui Moody’s, Fitch, S&P, Kroll, DBRS, AM Best), log e file di configurazione di infrastruttura AWS di produzione, oltre a script SQL contenenti credenziali per ambienti produttivi.

NAIC ha dichiarato che nessun dato personale identificabile né informazioni di pagamento risultano compromessi, e che i sistemi regolatori critici — SERFF, OPTins, UCAA, EDP e RDC — non sono stati toccati. Ma l’impatto operativo è stato comunque tangibile: diverse agenzie di rating hanno sospeso temporaneamente i feed di dati verso il regolatore, e NAIC ha interrotto momentaneamente l’assegnazione delle proprie designazioni di investimento, i parametri che determinano quanto capitale gli assicuratori vita statunitensi devono accantonare a fronte dei propri portafogli. Un breach che tocca un ente pubblico, quindi, si traduce in frizioni immediate sull’intero mercato assicurativo americano.

Cosa devono fare i difensori

• Applicare immediatamente la patch CPU187 di Oracle su tutte le istanze PeopleSoft PeopleTools 8.61/8.62.
• Se il patching non è immediato, bloccare l’esposizione internet degli endpoint EMHub/PSEMHUB o disabilitare il servizio nelle configurazioni multi-server; nelle installazioni single-server valutare la rimozione dell’applicazione PSEMHUB.
• Verificare i log di accesso WebLogic per richieste POST esterne verso /PSEMHUB/hub o /PSIGW/HttpListeningConnector.
• Cercare file .jsp non attesi sotto PSEMHUB.war e cartelle anomale (logs, persistantstorage, scratchpad); controllare modifiche recenti ai file XML sotto envmetadata/data/environment, potenziale vettore di persistenza via XMLDecoder al riavvio.
• Monitorare traffico DNS e connessioni verso il dominio C2 noto azurenetfiles.net.
• Ruotare le credenziali potenzialmente esposte in script SQL, configurazioni e log applicativi.

La campagna NAIC conferma un pattern ormai consolidato per l’alleanza Scattered LAPSUS$ Hunters: individuare zero-day in software enterprise ampiamente diffusi (Salesforce, Snowflake, ora Oracle PeopleSoft), colpire in massa prima che la finestra di patching si chiuda, e monetizzare l’estorsione anche quando i dati sottratti sono in gran parte “pubblici” o di scarso valore diretto — sfruttando la pressione reputazionale e regolatoria che un data leak comporta per l’organizzazione colpita.

Indicatori di compromissione

CVE: CVE-2026-35273 (CVSS 9.8, SSRF -> RCE non autenticata)
Componente: Oracle PeopleSoft PeopleTools 8.61 / 8.62 - Environment Management Hub (PSEMHUB)
Endpoint sfruttati:
  /PSEMHUB/hub
  /PSIGW/HttpListeningConnector

C2 domain: wss://azurenetfiles[.]net:443/agent.ashx

Agenti MeshCentral malevoli (masquerading Azure):
  meshagent32-azure-ops.exe
  meshagent64-azure-ops.exe
  meshagent64-v2.exe

IP di staging (Python HTTP server, porta 8888):
  142.11.200.186 - 142.11.200.190

Percorsi sospetti da monitorare:
  /logs/
  /persistantstorage/
  /scratchpad/
  envmetadata/data/environment/*.xml (persistenza via XMLDecoder)

Attore: UNC6240 (Mandiant) / ShinyHunters / Scattered LAPSUS$ Hunters
Finestra di sfruttamento zero-day: 27 maggio - 9/10 giugno 2026
Patch Oracle: CPU187, rilasciata 10 giugno 2026