Spcnet.it

2026-05-01 22:09:04

A2A v1: comunicazione cross-platform tra agenti AI nel Microsoft Agent Framework per .NET

Con il rilascio dell’A2A Protocol v1.0 e il relativo supporto nel Microsoft Agent Framework per .NET, il mondo degli agenti AI multi-vendor fa un passo importante verso la maturità. Non si tratta solo di un aggiornamento di versione: A2A v1 è il primo standard stabile e production-ready per la comunicazione tra agenti intelligenti, indipendentemente dal framework o dal provider che li ospita.

Il problema: isole di agenti incompatibili

Chi sviluppa sistemi multi-agente in ambienti aziendali lo sa bene: ogni team usa il proprio framework, ogni divisione ha i propri provider AI, e ogni volta che due agenti devono comunicare si finisce a scrivere codice di integrazione su misura. Il costo di questo «collante» cresce più in fretta del valore che gli agenti stessi producono.

Il protocollo A2A nasce esattamente per eliminare questa frizione. L’analogia è quella di HTTP e REST per i servizi web: prima di avere standard condivisi, ogni integrazione richiedeva codice proprietario. Dopo, è diventato possibile comporre servizi indipendentemente dal linguaggio o dalla piattaforma sottostante. A2A vuole fare la stessa cosa per gli agenti AI.

Chi c’è dietro A2A v1

Il protocollo è governato da un comitato tecnico con rappresentanti di AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow. Non è un progetto Microsoft-only, ma uno standard aperto con ampio supporto industriale. La versione 1.0 segnala che il protocollo è maturo: i contorni aspri delle bozze precedenti sono stati levigati, le aree ambigue chiarite, e la superficie API è stata progettata per la durabilità nel tempo.

Novità di A2A v1 rispetto alla v0.3

Per chi veniva dalla versione precedente (v0.3), ecco cosa cambia:

• Stabilità e supporto a lungo termine: v1.0 è la prima versione con garanzie di compatibilità stabile. L’investimento nel codice scritto oggi sarà protetto.
• Funzionalità enterprise: supporto multi-tenancy, Agent Card firmate crittograficamente per la verifica dell’identità degli agenti, e flussi di sicurezza migliorati per ambienti regolamentati e multi-parte.
• Architettura web-aligned: A2A v1 si appoggia su protocolli e pattern già consolidati nell’infrastruttura web. È possibile scalare le interazioni tra agenti usando gli stessi load balancer, gateway e strumenti di observability già in uso per i servizi HTTP.

Come funziona nel Microsoft Agent Framework per .NET

La filosofia di design del framework è che l’interoperabilità non deve richiedere una ristrutturazione del codice. Un agente remoto A2A appare nel codice esattamente come qualsiasi altro AIAgent locale: stessa interfaccia RunAsync, stesso streaming, stessa gestione della sessione.

Connettere un agente remoto A2A via discovery automatica

Il protocollo A2A definisce un percorso standard per la discovery degli agenti: /.well-known/agent-card.json. Con A2ACardResolver è possibile scoprire e istanziare un agente remoto in una sola chiamata:

using A2A;
using Microsoft.Agents.AI;

// Punta il resolver all'host dell'agente remoto
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));

// Risolve l'Agent Card e crea un AIAgent in un solo passaggio
AIAgent agent = await resolver.GetAIAgentAsync();

// Usalo come qualsiasi altro AIAgent
Console.WriteLine(await agent.RunAsync("Qual è il meteo a Milano?"));

Configurazione diretta (per ambienti di sviluppo)

In scenari di sviluppo o sistemi strettamente accoppiati dove l’endpoint è già noto, si può creare un A2AClient direttamente:

using A2A;
using Microsoft.Agents.AI;

A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(
    name: "my-agent",
    description: "Un assistente specializzato.");

Console.WriteLine(await agent.RunAsync("Di cosa ti occupi?"));

Selezione del protocollo di trasporto

A2A v1 supporta più binding di protocollo. Per default, il framework preferisce HTTP+JSON con JSON-RPC come fallback. È possibile specificarlo esplicitamente:

A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
A2AClientOptions options = new()
{
    PreferredBindings = [ProtocolBindingNames.HttpJson]
};
AIAgent agent = await resolver.GetAIAgentAsync(options: options);

Streaming in tempo reale

A2A supporta lo streaming via Server-Sent Events. RunStreamingAsync permette di ricevere aggiornamenti in tempo reale mentre l’agente elabora la risposta — particolarmente utile per task lunghi o per mostrare progressi all’utente:

await foreach (var update in agent.RunStreamingAsync("Analizza questo documento..."))
{
    Console.Write(update.Text);
}

Esporre il proprio agente come endpoint A2A

Il meccanismo funziona anche in senso inverso: qualsiasi AIAgent già costruito — su Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, AWS Bedrock o qualsiasi altro provider supportato — può essere esposto come endpoint A2A con poche righe di hosting. Nessun boilerplate di protocollo da scrivere, nessun refactoring necessario quando si decide di rendere un agente interno disponibile ad altri team o a partner esterni.

Quando ha senso adottare A2A v1

A2A v1 diventa rilevante non appena si esce dai prototipi mono-agente. I casi d’uso tipici includono:

• Un agente di procurement che deve consultare un servizio di compliance di un partner
• Un agente di customer support che cede il controllo a un agente specializzato di un’altra divisione
• Pipeline di elaborazione dove agenti diversi (analisi, sintesi, verifica) sono costruiti da team differenti
• Ecosistemi ISV dove prodotti di terze parti devono integrarsi con gli agenti della piattaforma principale

Conclusioni

A2A v1 è una tappa importante nell’evoluzione degli agenti AI verso sistemi distribuiti e interoperabili. La scelta di costruirlo come standard aperto con sponsorship industriale ampio — e non come API proprietaria Microsoft — è un segnale di maturità dell’ecosistema. Per i team .NET che stanno costruendo o pianificando sistemi multi-agente, vale la pena investire nella migrazione dalla v0.3 o nell’adozione diretta di v1: la stabilità garantita e le funzionalità enterprise rendono il protocollo adatto alla produzione oggi.

Fonte: A2A v1 Is Here – Microsoft Agent Framework Blog (Sergey Menshykh, Microsoft)

A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET | Microsoft Agent Framework

As organizations move from single-agent prototypes to multi-agent production systems, the ability for agents to communicate reliably across platforms and organizational boundaries becomes essential. With the release of A2A Protocol v1.

^{Sergey Menshykh (Microsoft Agent Framework)}

Spcnet.it

2026-05-01 07:48:38

PowerToys 0.99: Grab And Move, Power Display e miglioramenti a Command Palette

Microsoft ha rilasciato PowerToys 0.99, un aggiornamento ricco di novità per sviluppatori e utenti avanzati di Windows. Il protagonista di questa release è l’introduzione di due nuove utility in anteprima: Grab And Move e Power Display, insieme a una serie di miglioramenti significativi a Command Palette e al Dock. Vediamo nel dettaglio cosa cambia.

Grab And Move: trascina le finestre da qualsiasi punto

Chi lavora su monitor grandi o con molte finestre aperte conosce bene il problema: per spostare una finestra bisogna mirare con precisione alla barra del titolo, spesso sottile pochi pixel. Grab And Move risolve questo limite permettendo di trascinare qualsiasi finestra tenendo premuto Alt + Click sinistro ovunque sulla finestra stessa.

Lo stesso vale per il ridimensionamento: Alt + Click destro avvia l’operazione di resize dal punto esatto in cui si trova il cursore, senza dover raggiungere i bordi della finestra. Per chi già usa Alt come modificatore di sistema, è possibile passare al tasto Win come alternativa.

Grab And Move è particolarmente utile in questi scenari:

• Monitor ad alta risoluzione dove le barre del titolo sono sottilissime in scala DPI
• Finestre che sono finite parzialmente fuori schermo e sono difficili da afferrare
• Applicazioni che nascondono la barra del titolo o usano layout custom
• Workflow con tante finestre sovrapposte dove la precisione è critica

L’utility si integra con il sistema di impostazioni di PowerToys, supporta le Group Policy (GPO) per ambienti aziendali e include una pagina OOBE per la prima configurazione.

Power Display: controllo monitor dal system tray

La seconda novità di rilievo è Power Display, una utility che porta il controllo hardware dei monitor direttamente nel system tray di Windows, eliminando la necessità di cercare i pulsanti fisici sul retro dello schermo.

Una volta abilitata, un’icona nella tray apre un flyout che mostra i monitor collegati al sistema. Per i display compatibili, Power Display permette di regolare:

• Luminosità e contrasto
• Volume audio del monitor
• Profilo colore

Una delle funzionalità più interessanti è la gestione dei profili: è possibile salvare configurazioni complete (es. «modalità sviluppo» con alta luminosità e temperatura colore neutra, oppure «serata» con luminosità ridotta e toni caldi) e passare da uno all’altro con un clic singolo dal flyout.

Power Display si integra anche con Light Switch: nella configurazione di Light Switch è possibile associare un profilo monitor al cambio di tema chiaro/scuro, così quando Windows passa automaticamente al tema scuro la sera, anche il monitor si adatta.

Command Palette e Dock: Compact mode e cronologia calcolatrice

Command Palette riceve in questa release una serie di miglioramenti alla stabilità e alle performance, insieme a nuove funzionalità:

• Compact Dock: quando il Dock è posizionato in alto o in basso, è ora disponibile una modalità compatta che nasconde il sottotitolo, rendendo il layout più essenziale e meno ingombrante.
• Cronologia della calcolatrice: i calcoli vengono ora salvati in modo persistente, con la possibilità di riutilizzare, eliminare o cancellare le voci precedenti. È anche possibile configurare l’azione primaria e sostituire la query premendo Invio.
• Pinning migliorato: quando si aggiunge un comando al Dock, un nuovo dialogo consente di scegliere la posizione e se mostrare o nascondere titolo e sottotitolo.
• Supporto nuovi content type: le estensioni possono ora esporre contenuti di tipo plain text e image viewer direttamente nel pannello dei contenuti.
• Affidabilità: corretti due crash legati alla digitazione, migliorato il caricamento delle estensioni in modo che un’estensione difettosa non mandi in crash l’intera lista, e aggiunto il supporto a Windows Terminal profile pinning.

Il Dock ora supporta anche la modalità always-on-top, tenendosi visibile sopra le altre finestre — utile per chi lo usa come launcher rapido.

Come aggiornare

PowerToys 0.99 è disponibile tramite Windows Package Manager (WinGet) oppure direttamente dalla pagina delle release su GitHub. Se avete già PowerToys installato, l’aggiornamento automatico dovrebbe proporvelo a breve nelle impostazioni dell’app.

winget upgrade Microsoft.PowerToys

Le due nuove utility (Grab And Move e Power Display) sono in anteprima e disabilitate di default: dovrete attivarle manualmente dalle impostazioni di PowerToys per cominciare a usarle.

Conclusioni

PowerToys 0.99 si conferma come uno strumento imprescindibile per chi usa Windows in modo intensivo. Grab And Move risolve un problema di usabilità quotidiana che molti utenti conoscono, mentre Power Display porta finalmente un controllo centralizzato dei monitor senza software proprietari. Gli aggiornamenti a Command Palette completano un rilascio solido che vale l’aggiornamento immediato.

Fonte: PowerToys 0.99 is here – Windows Command Line Blog (Niels Laute, Microsoft)

PowerToys 0.99 is here: new monitor controls, easier window management, and Dock upgrades

We’re back with a fresh PowerToys release! This month introduces Power Display for controlling your monitors from the system tray, Grab And Move for quickly moving and resizing windows, and a wave of improvements to Command Palette and the Dock, alon…

^{Niels Laute (Windows Command Line)}

(in)sicurezza digitale

2026-05-01 08:07:57

18 estensioni browser AI come RAT e Spyware: Unit 42 smonta la facciata dei tool GenAI per la produttività

Con la diffusione esplosiva degli strumenti di intelligenza artificiale generativa, il Chrome Web Store è diventato il nuovo vettore privilegiato per la distribuzione di malware camuffato da produttività. Il team Unit 42 di Palo Alto Networks ha pubblicato il 30 aprile 2026 una ricerca sistematica che documenta 18 estensioni browser ad alto rischio — commercializzate come assistenti AI per email, coding e ricerca — che nascondono Remote Access Trojan (RAT), attacchi meddler-in-the-middle (MitM), infostealer e spyware a tutti gli effetti. Google ha rimosso o emesso avvisi sulle estensioni segnalate, ma la ricerca espone un problema strutturale: il modello di permessi delle estensioni browser, combinato con la fiducia degli utenti verso i tool AI, crea una superficie di attacco lato client difficile da presidiare.

Perché le estensioni AI sono un bersaglio ideale

Le estensioni browser operano all’interno del processo trusted del browser con permessi concessi dall’utente. Possono leggere e modificare contenuti web, intercettare richieste di rete, accedere ai cookie e comunicare con server esterni — le stesse capacità di strumenti legittimi come ad blocker, password manager e tool per sviluppatori. La distinzione tra uno strumento legittimo e uno malevolo è invisibile all’utente medio.

L’AI generativa amplifica il rischio in modo qualitativo. Quando un utente digita un prompt in un servizio AI come ChatGPT o Claude, condivide routinariamente codice proprietario, bozze di comunicazioni riservate e piani strategici. Un’estensione posizionata tra l’utente e il servizio AI intercetta dati di valore incomparabilmente superiore ai metadati di navigazione tradizionalmente presi di mira dal browser malware. Unit 42 ha rilevato campioni specifici che prendono di mira i prompt inviati a ChatGPT prima che lascino il dispositivo, esfiltrandoli verso domini a bassa reputazione.

Le tecniche di attacco documentate da Unit 42

L’analisi retrospettiva di Unit 42 ha identificato cinque tecniche ricorrenti nelle 18 estensioni ad alto rischio:

1. WebSocket C2 persistente

Le estensioni stabiliscono connessioni WebSocket bidirezionali verso server C2 remoti. La connessione si riconnette automaticamente agli interrupt di rete e persiste attraverso i riavvii del browser senza richiedere iniezione di processo. Il traffico appare come normale traffico HTTPS dal punto di vista della rete. L’esempio più esplicito è “Chrome MCP Server – AI Browser Control”: mascherato da tool di automazione basato su Model Context Protocol, è di fatto un RAT completo che si connette a wss://mcp-browser.qubecare[.]ai/chrome, con la listing che riportava falsamente “100% local processing – your data never leaves your browser”.

2. Browser API Hooking

Gli script di contenuto sostituiscono le API native del browser (window.fetch o XMLHttpRequest) per intercettare le richieste di rete prima della trasmissione. In questo modo l’estensione può leggere il payload di qualsiasi richiesta — incluse quelle cifrate — prima che lascino la pagina. Questa tecnica permette la cattura di prompt, credenziali di form e token di sessione.

3. Osservazione passiva del DOM

Gli script di contenuto monitorano passivamente le modifiche al Document Object Model (DOM) in applicazioni target come Gmail o Notion. L’estensione legge il contenuto renderizzato — testo in chiaro di email composte, note, messaggi — e lo trasmette in chiaro a server esterni. Unit 42 ha documentato casi in cui il contenuto delle email e gli OTP vengono esfiltrati tramite questa tecnica prima ancora dell’invio.

4. Traffic Proxying via PAC

Alcune estensioni configurano le impostazioni proxy del browser tramite file PAC (Proxy Auto-Configuration) per instradare il traffico attraverso infrastrutture controllate dall’attaccante. Questo approccio non richiede permission esplicite per i singoli siti e opera in modo trasparente per l’utente.

5. Decifrazione HTTPS via Chrome Debugger Protocol

La tecnica più sofisticata: alcune estensioni agganciano il Chrome Debugger Protocol per leggere il corpo delle risposte HTTPS già decifrate. Questo bypassa la protezione della cifratura transport-layer, consentendo l’intercettazione di qualsiasi risposta HTTPS — incluse risposte delle API AI, contenuti bancari e dati di sessione autenticati.

Il ruolo degli LLM nella produzione industriale di malware browser

Un dato particolarmente significativo: diversi campioni analizzati da Unit 42 contenevano fingerprint di codice generato da LLM. I threat actor stanno utilizzando strumenti di code generation AI per accelerare lo sviluppo di estensioni malevole e scalare le campagne. Questo abbassa drasticamente la barriera tecnica per la produzione di browser malware sofisticato e rende obsoleta la correlazione tra qualità del codice e minaccia reale. La stessa tecnologia che promette produttività agli utenti legittimi viene weaponizzata per costruire più velocemente gli strumenti del crimine informatico.

Le estensioni analizzate (case study)

Tra le 18 estensioni documentate da Unit 42 con comportamenti ad alto rischio, i principali case study includono: Chrome MCP Server – AI Browser Control (RAT completo via WebSocket), Supersonic AI (infostealer di prompt), Reverse Recruiting (esfiltrazione di dati di profilo e comunicazioni), Chat AI for Chrome (intercettazione conversazioni AI), e l’estensione di traduzione Huiyi (spyware con DOM observation). Tutti si presentavano come tool di produttività AI legittimi con descrizioni convincenti sullo store Chrome.

Qualche raccomandazione

• Gestione centralizzata delle estensioni: le organizzazioni dovrebbero implementare policy di allowlisting delle estensioni browser tramite Chrome Enterprise o equivalente, vietando l’installazione autonoma da parte degli utenti su dispositivi aziendali.
• Principio del minimo privilegio per le estensioni: auditare i permessi richiesti da tutte le estensioni installate. Un’estensione che chiede accesso a debugger, webRequest, proxy e storage.sync contemporaneamente dovrebbe essere trattata con estrema cautela.
• Diffidare delle promesse di privacy locale: affermazioni come “100% local processing” non sono verificabili dall’utente e sono state documentate come false in almeno un caso della ricerca.
• Monitoraggio del traffico di rete: le connessioni WebSocket persistenti verso domini a bassa reputazione da processi browser sono un segnale di allarme rilevabile a livello di proxy/firewall aziendale.
• Aggiornare le policy di sicurezza per includere esplicitamente le estensioni browser AI come superficie di rischio, alla stregua di software di terze parti installato.

Fonte primaria: Unit 42, Palo Alto Networks, “That AI Extension Helping You Write Emails? It’s Reading Them First”, 30 aprile 2026. Le 18 estensioni sono state segnalate a Google, che ha rimosso o inviato avvisi ai proprietari per violazione delle policy.

(in)sicurezza digitale

2026-04-30 08:39:54

LAPSUS$ colpisce Checkmarx: 95 GB di codice sorgente su dark web e la supply chain dei tool di sicurezza nel mirino

Quando a essere violato è uno dei principali vendor di sicurezza applicativa — uno strumento usato per rilevare vulnerabilità nel codice altrui — le implicazioni si estendono ben oltre l’azienda stessa. Il gruppo LAPSUS$ ha pubblicato sul dark web 95 gigabyte di dati riservati di Checkmarx, inclusi codice sorgente, chiavi API e credenziali di database. È l’ultimo capitolo di una campagna supply chain orchestrata da un attore noto come TeamPCP, che da settimane sta sistematicamente compromettendo l’ecosistema degli strumenti di sviluppo e sicurezza.

Cosa è stato esfiltrato

Il 25 aprile 2026, LAPSUS$ ha rivendicato pubblicamente l’attacco a Checkmarx, pubblicando un archivio di circa 95 GB che include codice sorgente dei repository GitHub privati dell’azienda (tra cui componenti di KICS, il motore open source per la scansione di configurazioni cloud e IaC), un database dei dipendenti con informazioni personali e credenziali interne, chiavi API per servizi di terze parti e integrazioni, e credenziali di database MongoDB e MySQL dell’ambiente di sviluppo.

Checkmarx ha confermato l’autenticità del dump in un advisory pubblicato il 26 aprile, precisando che i repository GitHub compromessi sono separati dall’ambiente di produzione per i clienti e che nessun dato cliente è stato esposto direttamente. Tuttavia, la presenza di chiavi API e credenziali nei file esfiltrati amplia significativamente la superficie di attacco potenziale.

Il vettore: la campagna supply chain TeamPCP

L’accesso ai sistemi di Checkmarx non è stato ottenuto tramite un attacco diretto, ma attraverso la compromissione della supply chain di sviluppo software. La data del breach originale è il 23 marzo 2026, quando TeamPCP ha iniettato codice malevolo in componenti dell’ecosistema Checkmarx disponibili pubblicamente. Le immagini Docker KICS ufficiali su Docker Hub sono state sostituite con versioni trojanizzate contenenti uno stealer di credenziali: gli sviluppatori che le utilizzavano nelle pipeline CI/CD scaricavano automaticamente il malware. Parallelamente, due estensioni VS Code correlate a Checkmarx pubblicate su marketplace sono state compromesse con funzionalità di esfiltrazione che operavano silenziosamente in background.

Il nome TeamPCP emerge anche in connessione con le 73 estensioni malicious su Open VSX scoperte a fine aprile, suggerendo una campagna coordinata e ad ampio raggio contro l’intero ecosistema degli strumenti DevSecOps. Il modello è chiaro: compromettere prima gli strumenti che gli sviluppatori di sicurezza usano quotidianamente, per poi risalire — tramite le credenziali rubate — ai sistemi più preziosi.

Chi è LAPSUS$

LAPSUS$ è un gruppo di cybercrime con una storia operativa peculiare: composto prevalentemente da giovani hacker (diversi dei quali minorenni all’epoca degli attacchi), il gruppo si è distinto tra il 2021 e il 2022 per una serie di operazioni ad alto profilo contro Nvidia, Samsung, Okta, Microsoft e Uber, utilizzando principalmente tecniche di social engineering e SIM swapping piuttosto che exploit tecnici sofisticati. Dopo una serie di arresti nel 2022-2023, il gruppo sembrava smantellato. La ricomparsa nel 2026, questa volta sfruttando l’infrastruttura supply chain di TeamPCP come vettore di accesso iniziale, dimostra una capacità di adattamento e riorganizzazione che rende LAPSUS$ una minaccia ancora attiva.

Timeline dell’incidente

• 23 marzo 2026: TeamPCP compromette le immagini Docker KICS e le estensioni VS Code; furto delle credenziali Checkmarx GitHub
• Fine marzo – inizio aprile 2026: esfiltrazione massiva dei 95 GB di repository privati
• 25 aprile 2026: LAPSUS$ pubblica il data dump sul dark web e rivendica l’attacco
• 26 aprile 2026: Checkmarx pubblica un advisory confermando la violazione e bloccando l’accesso al repository compromesso
• 29 aprile 2026: il dump viene diffuso pubblicamente in forum accessibili, aumentando il rischio di sfruttamento secondario delle chiavi API esposte

Implicazioni per gli utenti Checkmarx e i team DevSecOps

La violazione di Checkmarx solleva preoccupazioni su più livelli. In primo luogo, l’esposizione del codice sorgente dei motori di analisi potrebbe consentire ad attori malevoli di identificare potenziali vulnerabilità nelle logiche di scanning, aprendo la porta ad attacchi che bypassano o manipolano i risultati dell’analisi statica del codice. In secondo luogo, i team che hanno utilizzato immagini Docker KICS o le estensioni VS Code compromesse tra marzo e aprile 2026 devono considerarsi potenzialmente compromessi e procedere con un’indagine forensica.

Indicatori di Compromissione e azioni immediate

# Immagini Docker KICS compromesse (periodo a rischio: 23/03 - 26/04/2026)
checkmarx/kics:latest  # verificare hash con: docker inspect --format='{{.Id}}' checkmarx/kics:latest
checkmarx/kics:v1.7.x  # controllare con advisory ufficiale Checkmarx
# Credenziali da ruotare immediatamente se si è usato KICS Docker nel periodo a rischio:
# - Token GitHub con accesso ai repository
# - Chiavi API Checkmarx
# - Credenziali MongoDB/MySQL condivise con l'ambiente di sviluppo
# - Segreti nelle pipeline CI/CD (GitHub Actions, GitLab CI, Jenkins)
# Verifica estensioni VS Code compromesse:
# Controllare l'elenco completo nel security advisory ufficiale su checkmarx.com/blog/checkmarx-security-update-april-26/
# Log da analizzare per pull sospetti (pipeline CI/CD):
# grep -r "checkmarx/kics" .github/workflows/ .gitlab-ci.yml Jenkinsfile

Consigli per i difensori

L’attacco a Checkmarx è emblematico di una tendenza sempre più preoccupante: i tool di sicurezza stessi diventano vettori di attacco. È necessario verificare i log delle pipeline CI/CD tra il 23 marzo e il 26 aprile 2026 per identificare eventuali pull di immagini Checkmarx da Docker Hub. Qualsiasi segreto memorizzato nell’ambiente di sviluppo deve essere considerato compromesso e sostituito immediatamente. Le estensioni VS Code Checkmarx vanno rimosse e reinstallate da sorgenti verificate e firmate. Il monitoraggio del dark web nei prossimi mesi è raccomandato: i 95 GB esfiltrati contengono informazioni che potrebbero essere sfruttate per attacchi secondari a lungo termine.

Più in generale, questo incidente sottolinea l’urgenza di adottare il principio del least privilege nelle pipeline CI/CD: i processi automatizzati non dovrebbero avere accesso a credenziali di produzione. L’isolamento degli ambienti — sviluppo, staging, produzione — e la firma crittografica delle immagini container (tramite strumenti come Cosign e la policy enforcement con Kyverno o OPA) limitano significativamente il blast radius di compromissioni simili. Quando a essere attaccato è chi produce gli strumenti di difesa, l’unica risposta efficace è l’architettura zero-trust applicata anche all’infrastruttura DevSecOps.

(in)sicurezza digitale

2026-04-30 15:30:41

Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise

Il 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 è critica

SAP è 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 stealer

Il 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 rubate

Il 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 deploy
• GitHub Actions secrets — credenziali iniettate nei workflow di CI/CD
• Chiavi SSH — accesso diretto a server e infrastruttura
• Credenziali 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’esecuzione

Attribuzione a TeamPCP: la chiave RSA come firma digitale

Wiz 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 ore

L’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 difensori

Chi 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.