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