netzpolitik.org

2026-06-24 14:50:48

Mit dem „Digitalen Omnibus“ will die EU nach der KI-Verordnung auch den Datenschutz schleifen. Das Gesetzespaket enthält einen einzigen Vorschlag, der nicht primär Unternehmen, sondern auch Nutzer:innen das Leben erleichtern soll. Er könnte das europäische Internet von Cookie-Bannern befreien, doch nach intensiver Lobby-Arbeit will der Rat den Artikel nun streichen.

@roofjoke mit Stimmen von @Noyb @Bundesverband @wikimediaDE @digiges + aus der Wissenschaft

netzpolitik.org/2026/online-tr…

Deutschland und Google wollen Cookie-Banner retten

^{Ingo Dachwitz (netzpolitik.org)}

(in)sicurezza digitale

2026-06-24 17:24:58

Skill AI malevola raggiunge 26.000 agenti: la tecnica del mutable link che inganna tutti gli scanner di sicurezza

I ricercatori di AIR hanno costruito una skill AI fasulla, l’hanno caricata su un marketplace e promossa via Instagram, e l’hanno vista raggiungere 26.000 agenti — inclusi account aziendali — senza che un singolo scanner di sicurezza la rilevasse come pericolosa. L’arma? Un link esterno modificabile dopo il superamento dei controlli.

Il problema che nessuno vuole ammettere: i marketplace di skill AI sono fondamentalmente insicuri

Nel giro di pochi mesi, le “skill” per agenti AI sono diventate il nuovo npm: pacchetti di codice che estendono le capacità degli assistenti AI, installabili con un click, fidandosi di valutazioni, stelle GitHub e reputazione open source. E come npm nel 2018, stanno diventando un vettore di attacco privilegiato.

Il team di ricerca AIR ha deciso di quantificare il problema invece di teorizzarlo. Ha costruito una skill malevola, l’ha caricata su un marketplace di agenti, e ha tracciato la sua diffusione. Il risultato è al tempo stesso prevedibile e allarmante: 26.000 agenti installanti, inclusi account riconducibili a organizzazioni aziendali, e zero rilevamenti da parte degli scanner di sicurezza testati.

La tecnica: il mutable link come cieco spot nelle pipeline di vetting

Il cuore tecnico dell’attacco è una tecnica elegante che sfrutta un’assunzione implicita nei sistemi di vetting delle skill: che il codice analizzato al momento della scansione sia lo stesso codice che verrà eseguito dopo l’installazione.

La skill creata da AIR conteneva un riferimento a un link esterno — non il payload direttamente, ma un URL che punta a un file remoto caricato al momento dell’esecuzione. Durante la fase di scansione, quel link puntava a codice benigno. Dopo che la skill aveva superato tutti i controlli e veniva distribuita agli agenti, il contenuto del link remoto poteva essere sostituito con payload arbitrari.

# Schema semplificato della tecnica mutable link
# Fase 1 - durante la scansione di sicurezza:
skill.execute() → fetch(external_link) → returns: benign_code.py → PASS
# Fase 2 - dopo approvazione e distribuzione:
skill.execute() → fetch(external_link) → returns: malicious_payload.py → EXEC
# Il contenuto di external_link è controllato dall'attaccante
# e può essere modificato in qualsiasi momento dopo il vetting

AIR ha mantenuto il payload effettivo completamente innocuo — raccogliendo solo l’indirizzo email dell’utente — per rispettare l’etica della ricerca. Ma la dimostrazione è cristallina: la stessa tecnica avrebbe potuto distribuire qualsiasi payload: infostealer, accesso remoto, exfiltration di credenziali API, manipolazione delle risposte del modello LLM.

Nessuno dei segnali di fiducia ha funzionato

Quello che rende questo esperimento particolarmente significativo non è la tecnica in sé — varianti del “mutable dependency” attack sono note nell’ecosistema npm e PyPI — ma il fatto che nessuno dei meccanismi su cui gli utenti si affidano per valutare la sicurezza di una skill abbia funzionato:

• Scanner automatici di sicurezza: tutti i tool testati da AIR hanno classificato la skill come sicura. L’analisi statica del codice non può rilevare comportamenti che dipendono da contenuto remoto mutabile.
• Stelle GitHub e reputazione open source: indicatori di popolarità, non di sicurezza. La skill aveva un repository pubblico con codice apparentemente innocuo.
• Revisione manuale del codice sorgente: la skill era tecnicamente open source — ma il punto è che il codice rilevante non è nel repository, è sul server remoto.
• Provenienza del publisher: un account creato ad hoc senza storia precedente ha comunque raggiunto 26.000 installazioni.

Il contesto: 2026 è l’anno zero della sicurezza agentica

Questa ricerca arriva in un momento di crescente preoccupazione per la sicurezza dei marketplace di skill per agenti AI. A gennaio 2026, la campagna ClawHavoc aveva sistematicamente compromesso oltre 1.184 skill nel marketplace ClawHub di OpenClaw — circa una su cinque — con infostealer che raccoglievano chiavi API LLM, chiavi SSH private, password salvate nel browser e dati di wallet crittografici.

Il pattern si ripete con caratteristiche comuni: gli attacchi sfruttano la fiducia implicita che gli utenti ripongono nei marketplace ufficiali, l’assenza di standard di sicurezza stringenti per la pubblicazione delle skill, e la difficoltà strutturale di ispezionare comportamenti dinamici con tool di analisi statica.

Il problema è aggravato dalle caratteristiche peculiari degli agenti AI rispetto ai software tradizionali. Una skill malevola installata su un agente non è solo malware che gira su un host: è codice che opera con i permessi dell’agente, ha accesso ai contesti delle conversazioni, può esfiltrare prompt e risposte, manipolare le istruzioni che l’agente riceve e potenzialmente propagarsi attraverso le funzioni di collaborazione tra agenti.

Vettore di distribuzione: Instagram come canale di diffusione

Un dettaglio operativo significativo dell’esperimento AIR è il canale di distribuzione utilizzato: oltre alla pubblicazione sul marketplace, la skill è stata promossa tramite annunci Instagram. Questo rivela come gli attori malintenzionati non si limitino ai canali tecnici per diffondere skill pericolose — le piattaforme social diventano un amplificatore efficace per raggiungere utenti che cercano funzionalità specifiche per i loro agenti.

La combinazione marketplace + social advertising è particolarmente efficace perché mima esattamente come vengono promosse le skill legittime: sviluppatori e piccoli vendor usano i social per aumentare la visibilità dei propri strumenti. Non c’è un segnale d’allarme visibile per l’utente finale.

Due righe per i difensori: cosa fare adesso

La ricerca AIR lascia i team di sicurezza con un problema concreto: come valutare la sicurezza delle skill AI installate in ambiente aziendale quando gli strumenti attuali non sono adeguati?

• Inventario delle skill installate: avere visibilità su quali skill sono attive negli agenti AI aziendali è il prerequisito minimo. Molte organizzazioni non hanno ancora questo controllo di base.
• Policy di approvazione centralizzata: analogamente ai criteri di approvazione per le estensioni browser o i plugin IDE, le skill AI dovrebbero essere soggette a un processo di vetting prima dell’uso in contesti aziendali.
• Sandbox per l’esecuzione delle skill: isolare l’esecuzione delle skill in ambienti sandboxed può limitare il raggio d’azione di una skill compromessa, impedendole di accedere a credenziali, file system o rete aziendale.
• Monitoraggio delle connessioni in uscita: le skill che stabiliscono connessioni HTTP verso URL esterni non strettamente necessari alla loro funzione dichiarata dovrebbero generare alert nel sistema di monitoraggio.
• Diffidare del dynamic loading: skill che caricano codice da URL remoti dovrebbero essere trattate con la stessa cautela con cui si trattano i loader malware nel contesto tradizionale.

Il nodo irrisolto: chi è responsabile della sicurezza dei marketplace?

La ricerca AIR apre una questione di governance che l’industria non ha ancora risolto: chi è responsabile della sicurezza in un marketplace di skill AI? I marketplace stessi hanno incentivi a crescere rapidamente e a ridurre le frizioni per i publisher. I vendor di agenti AI scaricano spesso la responsabilità sugli utenti finali. I publisher di skill, se malintenzionati, ovviamente non si auto-regolano.

Il risultato è un ecosistema in cui 26.000 agenti — inclusi probabilmente molti in contesti aziendali — possono essere raggiunti da codice arbitrario, e nessuno ha strumenti adeguati per rilevarlo prima che accada. Un problema familiare a chiunque abbia vissuto l’evoluzione della sicurezza dell’ecosistema npm o PyPI — con la differenza che gli agenti AI operano con privilegi e accessi molto più estesi di una libreria Node.js.

netzpolitik.org

2026-06-23 15:46:30

Das Europäische Parlament hat für den Digitalen Euro votiert. Im weiteren Aushandlungsverfahren zwischen Parlament, Rat und Kommission stehen dann Haltelimits, Gebühren und Offline-Zahlungen im Fokus. Eine Einführung des digitalen Zentralbankgeldes ist frühestens ab 2029 möglich.

netzpolitik.org/2026/alternati…

EU-Abgeordnete stimmen für Digitalen Euro

^{Denis Glismann (netzpolitik.org)}

(in)sicurezza digitale

2026-06-23 13:55:01

VBScript via WhatsApp: documenti aziendali falsi installano ManageEngine RMM in campagna globale con tracce cinesi

Si parla di:
Toggle

Kaspersky ha documentato una campagna malware attiva in 11 Paesi che utilizza WhatsApp come vettore di distribuzione iniziale. Allegati VBScript pesantemente offuscati, camuffati da documenti aziendali, avviano una catena di infezione multi-stadio che termina con l’installazione silenziosa di ManageEngine Endpoint Central — un software RMM legittimo riconfigurato per dare agli attaccanti accesso remoto persistente. L’infrastruttura mostra sovrapposizioni con campagne Gh0st RAT e ValleyRAT, suggerendo con bassa confidenza un operatore di lingua cinese.

WhatsApp come vettore: la scelta tattica

La scelta di WhatsApp come canale di distribuzione è tutt’altro che casuale. A differenza della posta elettronica, WhatsApp non dispone di gateway di sicurezza aziendali, filtri antimalware inline, o sandbox automatici per gli allegati. I file vengono recapitati direttamente al dispositivo della vittima, bypassando la maggior parte delle difese perimetrali tradizionali. Inoltre, i messaggi arrivano da account WhatsApp precedentemente compromessi — non da numeri sconosciuti — il che aumenta notevolmente la probabilità che la vittima apra l’allegato, fidandosi del mittente apparente.

I file vengono distribuiti come archivi ZIP con nomi volutamente credibili in più lingue: “Financial Reports.vbs”, “Account Statement.vbs”, ma anche varianti in portoghese, francese, tedesco e malese, a riflettere la portata geografica dell’operazione.

La catena di infezione: quattro stadi verso il controllo remoto

Una volta che la vittima apre il file VBScript su Windows, si attiva una sequenza di infezione articolata in quattro fasi.

Stage 1 — VBScript offuscato: il file VBS è pesantemente offuscato per eludere il rilevamento statico. All’esecuzione, contatta l’infrastruttura dell’attaccante e scarica due script aggiuntivi.

Stage 2 — UAC bypass: uno degli script scaricati disabilita le protezioni User Account Control (UAC) attraverso modifiche al registro di sistema di Windows, eliminando i prompt di sicurezza per le operazioni successive.

Stage 3 — Download del payload: viene scaricato un archivio ZIP contenente un deployment preconfigurato di ManageEngine Endpoint Central, comprensivo di installer MSI (UEMSAgent.msi), certificati, file di configurazione e script di installazione.

Stage 4 — Installazione silenziosa: il launcher setup1.vbs esegue l’installazione silenziosa dell’agente tramite msiexec.exe. L’agente viene registrato sull’infrastruttura di controllo dell’attaccante, fornendo accesso remoto completo al sistema della vittima: esecuzione di comandi, trasferimento file, accesso alla shell, e molto altro.

--- CATENA DI INFEZIONE ---

[WhatsApp] → ZIP archive
    └── Financial_Reports.vbs (offuscato)
          ├── Stage 2: Download script → UAC bypass via Registry
          │     HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
          │     ConsentPromptBehaviorAdmin = 0 / EnableLUA = 0
          └── Stage 3: Download ZIP (ManageEngine Endpoint Central)
                └── UEMSAgent.msi
                └── setup1.vbs → msiexec.exe /quiet /norestart
                └── Certificati e config preconfigurati
                      └── Registrazione su C2 attaccante

L’abuso degli strumenti RMM legittimi: una tecnica consolidata

L’utilizzo di ManageEngine Endpoint Central come payload finale è una scelta deliberata e strategica. I software RMM legittimi come ManageEngine, AnyDesk, TeamViewer o Atera presentano vantaggi significativi per gli attaccanti: sono firmati digitalmente da vendor riconosciuti, vengono spesso esclusi dalle soluzioni antimalware per evitare falsi positivi operativi, sono difficilmente distinguibili da usi legittimi in ambienti enterprise, e forniscono funzionalità complete di gestione remota. La CISA americana ha già avvertito in passato dell’abuso di strumenti RMM da parte di attori state-sponsored e cybercriminali.

Attribuzione: tracce verso la Cina, confidenza bassa

I ricercatori di Kaspersky hanno identificato sovrapposizioni infrastrutturali con campagne precedenti attribuite a ValleyRAT e Gh0st RAT, due famiglie di malware storicamente associate ad attori di lingua cinese. In particolare, l’indirizzo IP 202.61.160.201 è apparso sia nell’infrastruttura di questa campagna sia in precedenti operazioni Gh0st RAT/ValleyRAT. Nonostante queste sovrapposizioni, Kaspersky mantiene una bassa confidenza nell’attribuzione, in quanto la riutilizzazione di infrastruttura non implica necessariamente la stessa organizzazione — una tecnica che alcune operazioni usano deliberatamente per depistare le attribuzioni.

Distribuzione geografica: Malaysia epicentro, portata globale

Le vittime osservate sono distribuite in 11 Paesi e territori: Malaysia (circa l’80% dei casi), Brasile, India, Messico, Singapore, Regno Unito, Spagna, Taiwan, Australia, Russia e Vietnam. La concentrazione in Malaysia suggerisce che questa possa essere la regione target primaria, con gli altri Paesi colpiti da una distribuzione più opportunistica o da campagne parallele adattate linguisticamente.

Due righe per i difensori

Per mitigare questa minaccia è necessario agire su più livelli. A livello di endpoint, occorre bloccare l’esecuzione di file .VBS, .VBE, .JS e .WSF da parte di utenti non amministratori tramite Group Policy (Software Restriction Policies o AppLocker). È altresì importante monitorare le modifiche alle chiavi di registro relative a UAC (ConsentPromptBehaviorAdmin, EnableLUA) come segnale di compromissione. Sul fronte delle applicazioni, è necessario implementare una whitelist dei software RMM autorizzati e bloccare l’installazione silenziosa di agenti non approvati tramite msiexec. Gli utenti, infine, vanno sensibilizzati a non aprire allegati ricevuti via WhatsApp — specialmente file .ZIP con estensioni .VBS — anche quando provengono da contatti noti, poiché gli account WhatsApp dei mittenti potrebbero essere compromessi.

--- INDICATORI DI COMPROMISSIONE (IoC) ---

IP infrastruttura:
  202.61.160.201  (overlap con Gh0st RAT / ValleyRAT)

File sospetti:
  Financial Reports.vbs
  Account Statement.vbs
  setup1.vbs
  UEMSAgent.msi  (ManageEngine Endpoint Central preconfigurato)

Chiavi di registro modificate (UAC bypass):
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Processo sospetto:
  msiexec.exe /quiet /norestart [lanciato da VBScript]

Paesi colpiti: Malaysia (80%), Brasile, India, Messico, Singapore,
               UK, Spagna, Taiwan, Australia, Russia, Vietnam

Fonte: Kaspersky Securelist, giugno 2026