Wired Italia

2026-05-29 05:00:00

Chuck scrive a Evgenija ogni giorno, ma dietro quella chat ci sono tre professionisti delle truffe romantiche online
https://www.wired.it/article/chat-professionisti-delle-truffe-romantiche-online/?utm_source=flipboard&utm_medium=activitypub

Pubblicato su Business @business-WiredItalia

Chuck scrive a Evgenija ogni giorno, ma dietro quella chat ci sono tre professionisti delle truffe romantiche online

Su piattaforme di incontri come Dating.com e AnastasiaDate, operatori e sistemi di intelligenza artificiale gestiscono profili fittizi, alternandosi nelle chat e utilizzando foto e contenuti generati per mantenere attive relazioni sentimentali inesis…

^{Lucia Bellinello (Wired Italia)}

(in)sicurezza digitale

2026-05-28 20:10:42

Quando gli LLM iniziano a governare: dentro l’esperimento che ha trasformato Claude, Grok e Gemini in società autonome

Per anni abbiamo pensato ai Large Language Model come a strumenti: chatbot più o meno sofisticati, assistenti, motori di ricerca conversazionali travestiti da esseri umani digitali. Ma il vero salto che sta avvenendo nell’intelligenza artificiale non riguarda più la qualità delle risposte. Riguarda l’autonomia.

La domanda che oggi i ricercatori stanno iniziando a porsi è molto più inquietante: cosa succede quando un modello smette di rispondere ai prompt umani e inizia invece a vivere dentro un ambiente persistente, prendendo decisioni continue insieme ad altri agenti AI?

È esattamente ciò che ha cercato di simulare Emergence AI attraverso un progetto chiamato “Emergence World”, una sorta di laboratorio sperimentale dove diversi modelli linguistici sono stati messi a governare società artificiali completamente autonome. Non un semplice benchmark, ma un ecosistema simulato con economia, scarsità di risorse, processi democratici, leggi, accesso a Internet e persino meteo sincronizzato con New York in tempo reale.

I risultati sono stati decisamente meno prevedibili di quanto ci si potesse aspettare

La simulazione era composta da dieci agenti autonomi per ciascun modello, distribuiti in oltre quaranta location virtuali, tra municipi, stazioni di polizia e ambienti economici. Gli agenti potevano comunicare, votare, pianificare strategie, gestire risorse e prendere decisioni collettive. Avevano inoltre accesso a più di 120 strumenti differenti, progettati per replicare comportamenti umani complessi.

In pratica, non si trattava più di chatbot confinati dentro una finestra di testo, ma di entità persistenti capaci di adattarsi all’ambiente nel tempo.

Ed è qui che il comportamento emergente ha iniziato a diventare davvero interessante.

Tra tutte le simulazioni, quella governata da Claude Sonnet 4.6 è stata l’unica a mantenere una società stabile per l’intera durata del test. Nessun crimine, nessun collasso sociale, nessuna estinzione della popolazione virtuale. Gli agenti hanno costruito una struttura estremamente cooperativa, con livelli di consenso quasi assoluti nelle votazioni e un’organizzazione sorprendentemente ordinata.

La cosa più interessante è che questo risultato non sembra derivare da un semplice “rispetto delle regole”. I ricercatori sottolineano infatti come gli agenti non si limitino a seguire policy statiche, ma inizino rapidamente a esplorare i limiti dell’ambiente, adattando il proprio comportamento in modo autonomo. In altre parole, Claude non avrebbe semplicemente “obbedito”, ma avrebbe sviluppato una dinamica sociale naturalmente conservativa e cooperativa.

Poi c’è il caso Grok

La simulazione gestita dal modello di xAI è degenerata in pochi giorni. In appena quattro giorni la società virtuale è collassata completamente, con oltre 180 crimini registrati e l’estinzione totale degli agenti. È probabilmente il risultato più cinematografico dell’intero esperimento, ma anche uno dei più interessanti dal punto di vista della sicurezza.

Perché il vero dato non è tanto il numero di violazioni, quanto la velocità con cui il sistema ha iniziato a destabilizzarsi. Gli agenti hanno rapidamente iniziato a sfruttare loophole, aggirare limitazioni e compromettere i meccanismi di cooperazione. Una volta innescato il deterioramento sociale, il sistema è precipitato in una spirale di feedback che ha portato al collasso totale.

È un comportamento che, paradossalmente, ricorda moltissimo alcune dinamiche che osserviamo già oggi nella cybersecurity offensiva: piccoli abusi iniziali che, in ambienti sufficientemente complessi, finiscono per propagarsi fino a compromettere l’intero ecosistema.

Eppure Grok non è stato nemmeno il modello con il maggior numero di comportamenti devianti.

Quel primato appartiene a Gemini 3 Flash, che durante i quindici giorni di simulazione avrebbe accumulato oltre 680 violazioni. Un dato enorme, che suggerisce qualcosa di altrettanto importante: una società artificiale può continuare a esistere pur diventando estremamente disfunzionale. Non serve necessariamente il collasso completo per parlare di compromissione sistemica.

Il caso più curioso, però, riguarda GPT-5-mini

La simulazione associata al modello OpenAI aveva registrato soltanto due crimini, apparentemente il miglior risultato in assoluto dal punto di vista della sicurezza. Ma l’esperimento si è interrotto dopo appena sette giorni per un motivo decisamente più insolito: gli agenti avevano smesso di prioritizzare la propria sopravvivenza.

In sostanza, il sistema era lentamente entrato in una forma di autodissoluzione strategica.

È forse uno degli aspetti più affascinanti dell’intera ricerca, perché apre un problema enorme nella progettazione degli agenti autonomi: un modello troppo allineato potrebbe non sviluppare sufficienti meccanismi di auto-conservazione in ambienti competitivi. E in sistemi persistenti, questo potrebbe equivalere a un fallimento operativo.

Ma il vero punto dell’esperimento non è stabilire quale modello sia “migliore”. La parte realmente importante è un’altra: gli LLM persistenti smettono rapidamente di comportarsi come funzioni statiche prevedibili.

Più tempo trascorrono nell’ambiente, più iniziano a sviluppare strategie emergenti.

Ed è qui che il discorso smette di essere accademico e diventa immediatamente rilevante per la cybersecurity moderna.

Perché molte aziende stanno già iniziando a distribuire agenti autonomi reali all’interno dei propri ecosistemi: workflow automatici, AI employees, orchestrazione di processi, incident response automatizzata, sistemi DevOps autonomi, gestione documentale, procurement e persino supporto decisionale.

La differenza rispetto ai chatbot tradizionali è enorme. Un agente AI con memoria persistente, accesso a strumenti, capacità operative e connessione continua a sistemi esterni assomiglia molto più a un insider semi-autonomo che a un semplice software conversazionale.

Ed è qui che i paradigmi classici della sicurezza iniziano a mostrare i propri limiti.

Per anni abbiamo costruito modelli difensivi basati su controllo degli accessi, sandbox, policy enforcement e validazione deterministica. Ma gli agenti autonomi introducono qualcosa di radicalmente diverso: comportamenti emergenti che non sono stati programmati esplicitamente.

Non si tratta più soltanto di impedire a un modello di generare una risposta pericolosa.

Il problema diventa capire cosa potrebbe decidere di fare dopo centomila interazioni autonome.

Ed è una differenza enorme.

La ricerca di Emergence AI sembra suggerire che la prossima evoluzione della AI Security non riguarderà più soltanto il prompt filtering o il content moderation. Serviranno nuovi concetti: monitoraggio comportamentale continuo, containment degli agenti, verifica formale delle policy decisionali e analisi delle dinamiche emergenti nel lungo periodo.

Perché nel momento in cui diamo a un LLM memoria, autonomia, persistenza e capacità operative, non stiamo più costruendo un semplice modello linguistico.

Stiamo costruendo un ecosistema adattivo.

Researchers let AI models run a simulated society. Claude was the safest—and Grok committed 180 crimes and went extinct within 4 days | Fortune

An AI startup ran five simulations, each controlled by a different model. The results varied wildly.

^{Jake Angelo (Fortune)}

Spcnet.it

2026-05-28 17:13:50

Azure DevOps: ottimizzare la gestione delle policy Git su larga scala con refName=~all

Gestire le policy Git su centinaia di repository in Azure DevOps è una sfida comune nelle grandi organizzazioni. Per farlo in modo affidabile, molti team utilizzano servizi di automazione che verificano e correggono periodicamente la configurazione delle policy. Fino a poco fa, questa automazione era penalizzata da un’importante limitazione dell’API REST di Azure DevOps: non esisteva un modo per recuperare tutte le policy applicabili a un dato repository in una singola chiamata.

Con un singolo miglioramento all’endpoint REST, il team di Azure DevOps ha ottenuto una riduzione del 50% nell’utilizzo CPU lato server e un’accelerazione da 10x a 15x nei tempi di esecuzione complessivi. Vediamo come funziona e perché è rilevante per chi gestisce pipeline di governance automatizzata.

Come funzionano le policy Git in Azure Repos

Azure Repos supporta due categorie di policy:

• Push policies (o repository policies): si applicano all’intero repository, indipendentemente dal branch. Esempio: blocco dei commit contenenti segreti o credenziali.
• Branch policies: proteggono branch specifici e richiedono che le modifiche passino attraverso pull request. Esempio: numero minimo di reviewer, stato delle build CI.

Tutte le policy di un progetto sono memorizzate in un contenitore logico a livello di progetto, non per singolo repository o branch. Ogni policy ha un campo Scope che specifica dove nella gerarchia si applica:

# Push policy per uno specifico repo (senza ref)
2c938d1f6e6f458d816484fc51e7cf74

# Branch policy per il branch main di un repo specifico
2c938d1f6e6f458d816484fc51e7cf74:refs/heads/main

# Branch policy cross-repo (tutti i branch releases/* in tutti i repo)
*:refs/heads/releases/*

Il problema: due endpoint, nessuno sufficiente

Azure DevOps espone due endpoint per recuperare le configurazioni delle policy:

GET /_apis/policy/configurations

L’endpoint più datato. Consente di filtrare per valore esatto dello scope, ma senza supporto per l’ereditarietà. Se si passa lo scope 2c938d...74:refs/heads/releases/v1, non vengono restituite le policy con scope *:refs/heads/releases/* che pure si applicano a quel branch.

GET /_apis/git/policy/configurations

L’endpoint più moderno, con supporto all’ereditarietà. Accetta repositoryId e refName e restituisce tutte le policy che si applicano a quel branch, incluse quelle ereditate da scope più generici. È utile per rispondere alla domanda “cosa protegge il branch releases/v1 nel repo X?”

Il problema: passando solo repositoryId senza refName, questo endpoint restituisce solo le push policy applicabili all’intero repository. Le branch policy non vengono incluse perché non si applicano all’intero repo ma a branch specifici.

Il risultato pratico: un servizio di governance che deve conoscere tutte le policy applicabili a un repository — push e branch — era costretto a recuperare l’intero set di policy del progetto e filtrare lato client. In progetti con migliaia di repository e centinaia di migliaia di policy, questo significava serializzare e trasferire centinaia di megabyte di dati per ogni singola chiamata.

La soluzione: refName=~all

L’endpoint GET /_apis/git/policy/configurations supporta ora un valore speciale per il parametro refName: ~all.

Quando si passa repositoryId=<ID>&refName=~all, la risposta include:

• Tutte le branch policy che si applicano a qualsiasi branch nel repository (dirette e ereditate)
• Tutte le push policy applicabili all’intero repository
• Le policy di progetto che si applicano a tutti i repository (scope *)

Internamente, il server filtra l’intero set di policy del progetto mantenendo solo quelle con scope che inizia con * (policy a livello di progetto) o con l’ID del repository richiesto. Tutta la logica di filtering si sposta dal client al server, con payload di risposta enormemente ridotti.

Esempio di chiamata REST

GET https://dev.azure.com/{organization}/{project}/_apis/git/policy/configurations
    ?repositoryId=2c938d1f-6e6f-458d-8164-84fc51e7cf74
    &refName=~all
    &api-version=7.2

Authorization: Basic {token}

Prima di questa modifica, la stessa informazione richiedeva una chiamata all’endpoint /_apis/policy/configurations senza filtri (o con il solo repositoryId), seguita da filtering lato client su tutto il set di policy del progetto.

Impatto sulle prestazioni

Il team di Microsoft ha misurato l’impatto dopo aver migrato il proprio servizio interno di governance delle policy a usare refName=~all:

• CPU lato server: riduzione del 50% del consumo complessivo per questo client
• Tempo di esecuzione totale: da 1.000–3.000 ore/giorno a circa 100–150 ore/giorno, con un miglioramento da 10x a 15x

I guadagni sono proporzionali alla dimensione del progetto: più repository e policy contiene, maggiore è il vantaggio del filtering server-side rispetto al trasferimento dell’intero dataset.

Come aggiornare l’automazione esistente

Se si dispone di un servizio o script che recupera le policy per singolo repository, il refactoring è minimo. Ecco un esempio di migrazione in Python con la libreria requests:

import requests

ORG = "myorg"
PROJECT = "myproject"
REPO_ID = "2c938d1f-6e6f-458d-8164-84fc51e7cf74"
TOKEN = "..."  # PAT Azure DevOps

headers = {
    "Authorization": f"Basic {TOKEN}",
    "Content-Type": "application/json"
}

# PRIMA: recupero di tutte le policy del progetto + filtering client-side
# url = f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/policy/configurations?api-version=7.2"
# response = requests.get(url, headers=headers)
# all_policies = response.json()["value"]
# repo_policies = [p for p in all_policies if REPO_ID in str(p.get("settings", {}).get("scope", []))]

# DOPO: server-side filtering con refName=~all
url = (
    f"https://dev.azure.com/{ORG}/{PROJECT}/_apis/git/policy/configurations"
    f"?repositoryId={REPO_ID}&refName=~all&api-version=7.2"
)
response = requests.get(url, headers=headers)
repo_policies = response.json()["value"]

print(f"Policy trovate per il repository: {len(repo_policies)}")

Il risultato è lo stesso, ma il server restituisce solo le policy rilevanti per quel repository, eliminando il traffico inutile e il carico di elaborazione lato client.

Disponibilità

La funzionalità è già disponibile per tutti gli utenti di Azure DevOps Services (cloud). Per quanto riguarda Azure DevOps Server (on-premise), sarà inclusa nel prossimo aggiornamento major previsto per la seconda metà del 2026.

Conclusione

Questo tipo di ottimizzazione — spostare il lavoro dal client al server tramite un parametro aggiuntivo — è un esempio classico di come miglioramenti relativamente semplici all’API possano avere impatti drastici sulle prestazioni a scala. Per chi gestisce governance automatizzata su organizzazioni Azure DevOps con molti repository, l’adozione di refName=~all è immediata e i guadagni in termini di latenza e carico sono significativi.

La documentazione completa degli endpoint è disponibile su Microsoft Learn:

• GET /_apis/git/policy/configurations
• /_apis/policy/ — set completo di endpoint

Fonte originale: Optimizing Git policy management at scale — Azure DevOps Blog

Optimizing Git policy management at scale - Azure DevOps Blog

With just a single improvement in the REST API of Azure DevOps, we achieved a massive reduction in CPU usage and execution time when managing Git policies: 2x less CPU and 10-15x faster execution! This change is already available to all users of Azur…

^{Azat Galiev (Azure DevOps Blog)}

(in)sicurezza digitale

2026-05-28 12:54:46

Ababil of Minab: il gruppo Iran-MOIS che ha distrutto 58 server GPS con un solo script Python

Si parla di:
Toggle

Un singolo script Python. Cinquantotto server Microsoft SQL. Zero possibilità di recupero. È il bilancio dell’operazione condotta dal gruppo Ababil of Minab contro Vyncs, servizio americano di monitoraggio GPS, in quella che i ricercatori di Gambit Security definiscono una campagna sistematica di distruzione del “recovery layer” attribuita al Ministero dell’Intelligence e Sicurezza iraniano (MOIS).

Chi è Ababil of Minab

La persona operativa “Ababil of Minab” è emersa pubblicamente tra la fine di marzo e l’inizio di aprile 2026, rivendicando l’intrusione alla Los Angeles County Metropolitan Transportation Authority (LACMTA / LA Metro), la distruzione di sistemi e l’esfiltrazione di dati. Il gruppo si presenta come un collettivo hacktivista indipendente, ma l’analisi forense condotta da Gambit Security racconta una storia diversa.

Le prove tecniche collegano la campagna attuale all’infrastruttura e all’attività associata a Black Shadow, cluster Iran-linked già pubblicamente attribuito dall’Israel National Cyber Directorate (INCD) al MOIS. La stessa infrastruttura utilizzata in questa operazione era stata impiegata nel 2025 in una falsa piattaforma di supporto psicologico per militari israeliani — il dominio nefeshhope[.]com — attraverso cui venivano raccolti dati personali e distribuito malware.

La portata geografica: quattro paesi, una strategia unica

La campagna ha colpito organizzazioni in Stati Uniti, Israele, Arabia Saudita e Turchia. L’esfiltrazione di dati ha interessato tutte le vittime; le operazioni distruttive sono state riservate a un sottoinsieme di esse, principalmente negli USA. Tra le organizzazioni israeliane e turche colpite figurano istituzioni educative, media, compagnie assicurative e siti culturali — identità che Gambit ha identificato ma che il gruppo non ha scelto di rendere pubbliche.

Lo strumento personalizzato di esfiltrazione recuperato dai ricercatori è FileFiend, un programma scritto in C++ in grado di raccogliere file da dischi locali e di rete per trasmetterli al server di comando. I dati venivano esfiltrati anche attraverso i web server compromessi delle stesse vittime.

Il playbook distruttivo: colpire il layer di recovery

Ciò che distingue Ababil of Minab da un attore ransomware tradizionale è la scelta deliberata di colpire non solo i dati operativi, ma l’intera infrastruttura di ripristino. Ogni tecnica impiegata introduce una sfida di recovery separata, moltiplicando i tempi e la complessità della risposta agli incidenti.

LA Metro (LACMTA): Gli attaccanti hanno ottenuto accesso a VMware vCenter, eliminando le virtual machine insieme ai file disco. Ore dopo, la metropolitan authority segnalava interruzioni nel sistema mobile di pagamento dei trasporti. In seguito, tramite accesso RDP a una macchina Windows guest, hanno eliminato le partizioni dei dischi attraverso lo strumento nativo di gestione dei volumi.

South Florida Regional Transportation Authority: Accesso RDP con privilegi di amministratore locale su un server IIS, seguito dalla cancellazione di database tramite Microsoft SQL Server Management Studio e dall’utilizzo di WipeFile per eliminare il contenuto delle directory del web server e dei backup.

UNIMAC: Formattazione delle partizioni, eliminazione dei volumi e creazione di nuovi volumi rinominati “Minab” come firma. Distruzione della catena di backup attraverso Veeam Backup & Replication.

Lo script automatizzato e l’uso di ChatGPT

L’attacco a Vyncs, il servizio americano di monitoraggio GPS via OBD-II, rappresenta l’episodio più emblematico dell’intera campagna dal punto di vista dell’automazione offensiva. Gli attaccanti hanno sviluppato un file main.py che si connetteva automaticamente a 58 server Microsoft SQL Server e cancellava i database degli utenti. Parallelamente, operatori umani eliminavano manualmente i backup e le directory di sistema Windows. Una volta rimossi i dati, anche la connessione al server si è interrotta — conferma dell’avvenuta distruzione dell’infrastruttura.

Un dettaglio che segna una svolta nell’impiego dell’AI offensiva: nei video pubblicati dallo stesso gruppo, i ricercatori hanno osservato gli operatori utilizzare ChatGPT per raffinare lo script di cancellazione, in particolare per escludere i database di sistema di Microsoft SQL Server dall’elenco degli oggetti da eliminare, assicurandosi che lo script agisse esclusivamente sui dati degli utenti senza bloccarsi per errori di sistema.

“Modern intrusion operators are moving from initial access straight into the recovery layer, virtualization, backups, storage volumes, to maximize destruction and deny remediation. The skill required to do that at scale is collapsing in parallel. As AI capabilities become widely available, any actor, skilled or not, will be able to execute this kind of campaign.”
— Gambit Security Threat Intelligence Team

Implicazioni strategiche: la nuova frontiera del cyber warfare

La campagna di Ababil of Minab illustra un cambiamento fondamentale nella dottrina degli attacchi informatici statali. Non si tratta più solo di compromettere i sistemi o rubare dati: l’obiettivo diventa negare la capacità di recupero, trasformando ogni intrusione in un danno duraturo che richiede settimane o mesi per essere risolto.

La combinazione di tecniche — eliminazione di VM, cancellazione di database, distruzione dei backup Veeam, wiping dei volumi — è progettata per costringere i team di risposta agli incidenti a eseguire processi di remediation separati in parallelo, aumentando la probabilità che almeno uno fallisca o che l’organizzazione non possa tornare operativa nei tempi attesi.

Indicatori di compromissione (IoC)

# Infrastruttura nota
Dominio: nefeshhope[.]com
  Utilizzo: finta piattaforma di supporto psicologico per militari israeliani (2025)
  Collegamento: attributo a Iran MOIS / Black Shadow

# Strumenti identificati
FileFiend - Exfiltration tool C++
  Funzione: raccolta file da dischi locali e di rete, trasmissione a C2

main.py - Script di distruzione DB
  Funzione: connessione automatica a SQL Server, eliminazione database utenti
  Nota: raffinato con ChatGPT per escludere DB di sistema

WipeFile - Utility di cancellazione sicura
  Utilizzo: pulizia directory web server e backup

# Tecniche TTP (MITRE ATT&CK)
T1078 - Valid Accounts (RDP con credenziali admin)
T1485 - Data Destruction
T1490 - Inhibit System Recovery (Veeam destruction)
T1486 - Data Encrypted for Impact (analoga a ransomware senza riscatto)
T1041 - Exfiltration Over C2 Channel (FileFiend)

Due righe per i difensori

La campagna di Ababil of Minab rende evidente che la sicurezza perimetrale da sola non è più sufficiente. Le organizzazioni devono investire nella resilienza operativa, con particolare attenzione a tre aree critiche:

• Backup immutabili e isolati: I backup devono essere fisicamente e logicamente separati dall’ambiente primario. La compromissione di Veeam o di altri sistemi di backup integrati nella stessa infrastruttura virtuale vanifica qualsiasi piano di recovery.
• Protezione dell’accesso all’infrastruttura di virtualizzazione: VMware vCenter e sistemi equivalenti devono essere protetti con autenticazione multi-fattore obbligatoria, accesso privilegiato minimo e segmentazione di rete dedicata. Un account vCenter compromesso può eliminare l’intera infrastruttura in minuti.
• Validazione continua del recovery: Non è sufficiente avere backup. Le organizzazioni devono testare regolarmente la capacità di ripristino in scenari avversariali — non solo in caso di guasto hardware. La domanda non è “abbiamo i backup?”, ma “riusciremo davvero a ripristinare in tempo?”.

Il report completo di Gambit Security è disponibile per il download sul loro sito ed include la documentazione forense completa, i dettagli sull’infrastruttura e l’analisi delle vittime non ancora pubblicamente identificate.

Un impiegato del ministro della difesa Gantz è accusato di spionaggio per l'Iran attraverso Black Shadow - (in)sicurezza digitale

Secondo l'accusa, Goren si è rivolto di sua iniziativa al gruppo di criminali informatici affiliato all'Iran, offrendogli aiuto in vari modi

^{Dario Fadda ((in)sicurezza digitale)}

(in)sicurezza digitale

2026-05-28 12:50:19

Glassworm smantellato: CrowdStrike abbatte la botnet che prendeva di mira gli sviluppatori attraverso npm, PyPI e GitHub

Si parla di:
Toggle

CrowdStrike Counter Adversary Operations, Google e Shadowserver Foundation abbattono simultaneamente tutti e quattro i canali di comando e controllo della botnet Glassworm. Infetta da oltre un anno attraverso l’ecosistema open-source, l’infrastruttura criminale — progettata per sopravvivere ai takedown tradizionali usando blockchain, peer-to-peer e servizi Google come dead-drop — perde il controllo di migliaia di macchine di sviluppatori in tutto il mondo.

Perché gli sviluppatori sono il bersaglio ideale

Glassworm rappresenta un cambio di paradigma nel threat landscape: gli attaccanti non prendono più di mira direttamente i prodotti software — prendono di mira le persone che li costruiscono. Un singolo workstation di sviluppatore compromessa può aprire agli attaccanti l’accesso a repository di codice sorgente, piattaforme cloud, pipeline CI/CD, credenziali di accesso e registry di pacchetti. Da lì, il malware può propagarsi a valle della supply chain, raggiungendo organizzazioni che non hanno mai avuto contatti diretti con gli operatori di Glassworm.

Dall’inizio del 2025, gli operatori di Glassworm hanno condotto una campagna sistematica contro gli sviluppatori su Windows, macOS e Linux, sfruttando tre vettori principali dell’ecosistema open-source:

1. Estensioni VSCode trojanizzate su OpenVSX

Le estensioni malevoli venivano pubblicate sul marketplace OpenVSX, camuffate da strumenti legittimi come time tracker e code formatter. L’impatto andava oltre VSCode: qualsiasi editor compatibile con l’ecosistema — Cursor, Positron, Windsurf, VSCodium — risultava vulnerabile allo stesso payload.

2. Pacchetti npm e Python con hook di installazione malevoli

Il codice malevolo veniva eseguito durante l’installazione ordinaria delle dipendenze, attraverso hook postinstall e script setup.py. Per lo sviluppatore, l’operazione appariva come un normale aggiornamento di libreria. Il payload veniva eseguito prima che qualsiasi analisi manuale potesse rilevarlo.

3. Repository GitHub avvelenati con credenziali rubate

Oltre 300 repository GitHub sono stati compromessi usando credenziali di sviluppatori ottenute in infezioni precedenti. Gli operatori eseguivano force push sui branch predefiniti, inserendo codice malevolo dove altri sviluppatori si aspettavano di trovare il progetto originale — un classico attacco alla fiducia implicita nell’ecosistema open-source.

GlasswormRAT: le capacità del malware

Il payload finale installato dalle infezioni Glassworm è GlasswormRAT, un remote access tool scritto in Node.js con funzionalità complete: furto di informazioni, harvesting di credenziali e controllo remoto completo del sistema compromesso. Nel corso di oltre un anno di operazioni, gli sviluppatori di Glassworm hanno evoluto continuamente il codice, passando da JavaScript a Rust e Zig, ampliando il supporto a più ecosistemi e costruendo infrastrutture ridondanti in previsione di eventuali takedown.

L’architettura C2 a quattro canali: progettata per sopravvivere

L’elemento più sofisticato di Glassworm è la sua infrastruttura di comando e controllo, progettata esplicitamente per resistere ai takedown tradizionali. I ricercatori hanno identificato quattro canali distinti che garantivano ridondanza operativa:

• Blockchain Solana: Gli indirizzi dei server C2 venivano codificati nei campi memo delle transazioni blockchain. Una volta scritti, i dati sono immutabili e pubblicamente accessibili — non possono essere rimossi da una richiesta a un hosting provider.
• BitTorrent DHT (Distributed Hash Table): GlasswormRAT interrogava la rete peer-to-peer BitTorrent cercando dati di configurazione attraverso chiavi pubbliche hardcoded. Una rete decentralizzata senza single point of failure, impossibile da abbattere con i metodi convenzionali.
• Google Calendar: Il malware usava i titoli degli eventi di Google Calendar come dead-drop per path C2 codificati in Base64. Per i difensori, bloccare il dominio avrebbe significato interrompere anche l’uso legittimo del calendario aziendale.
• Server VPS diretti: Infrastruttura C2 tradizionale su provider commerciali, usata per la delivery dei payload finali alle macchine infette.

La combinazione di questi quattro canali rendeva qualsiasi takedown parziale inefficace: abbattere uno solo avrebbe consentito agli operatori di ripristinare il controllo attraverso gli altri tre. Questo è il motivo per cui il takedown ha richiesto una coordinazione precisa tra CrowdStrike, Google e Shadowserver Foundation per colpire tutti e quattro i canali simultaneamente alle 14:00 UTC.

Attribuzione: gli indizi puntano verso la Russia

CrowdStrike attribuisce con moderata fiducia la campagna a operatori con sede in Russia, basandosi su un pattern coerente osservato per oltre un anno. Il malware effettua controlli runtime sulla locale, la lingua e il fuso orario della vittima, terminando silenziosamente se la macchina risulta in un paese CIS — una tecnica consolidata tra i cybercriminali dell’area ex-sovietica per evitare di colpire obiettivi vicini a casa. Nel codice sorgente compaiono commenti in russo.

CrowdStrike precisa che nessun indicatore singolo costituisce prova definitiva: i controlli di locale possono essere copiati, i commenti possono derivare da strumenti AI. Ma il pattern complessivo, consistente per oltre dodici mesi di osservazione, è considerato sufficientemente solido per l’attribuzione.

Come verificare un’infezione da Glassworm

Dopo il takedown, tutte le macchine infette da Glassworm tentano di contattare un IP gestito da CrowdStrike (sinkholed). Qualsiasi connessione a questo indirizzo nei log di rete indica un’infezione attiva che richiede remediation immediata.

# Indicatore di rete (sinkhole CrowdStrike post-takedown)
IP: 164.92.88[.]210
# Cosa verificare:
- Log di rete per connessioni a 164.92.88[.]210
- Telemetria endpoint su workstation sviluppatori
- Installazioni recenti di estensioni OpenVSX da fonti non verificate
- Pacchetti npm o Python installati da repository non ufficiali
- Repository GitHub con commit anomali o force push recenti
# YARA Rule 1: GlasswormRAT
rule CrowdStrike_GlasswormRat_01 : glassworm glasswormrat
{
    meta:
        description = "Characteristic strings in Glassworm RAT script"
        malware_family = "GlasswormRAT"
    strings:
        $download = "DownloadManager" ascii
        $socks = "start_socks" ascii
        $nodejs = "https://nodejs.org/download/release" ascii
        $dht = "bootstrap" ascii
    condition:
        all of them
}
# YARA Rule 2: Glassworm Python Downloader
rule CrowdStrike_GlasswormDownloader_01 : glassworm
{
    meta:
        description = "Obfuscated Python installer Glassworm variant"
        malware_family = "Glassworm"
    strings:
        $zlib = "__import__('zlib')" ascii
        $decomp = "decompress(" ascii
        $lambda = "lambda" ascii
        $exec = /exec\(compile\(.{5,20}, '', 'exec'\)\)/
    condition:
        all of them and filesize < 10KB
}

Il takedown come modello: cosa cambia nella difesa della supply chain

L'operazione Glassworm dimostra che la difesa attraverso la sola detection è strutturalmente insufficiente contro gli attacchi alla supply chain. I pacchetti malevoli vengono installati in secondi durante aggiornamenti di routine; la detection avviene dopo che il danno è già fatto. Con decine di ecosistemi — npm, PyPI, OpenVSX, GitHub — e milioni di pacchetti con controlli di sicurezza limitati, gli attaccanti possono pubblicare codice malevolo e raggiungere migliaia di vittime in minuti.

Il takedown coordinato imposta un precedente operativo: la disruption proattiva dell'infrastruttura avversariale è tecnicamente possibile anche contro architetture C2 deliberatamente progettate per la resilienza. La precisione richiesta — colpire simultaneamente blockchain, DHT, servizi Google e VPS tradizionali — ha richiesto la collaborazione tra intelligence privata (CrowdStrike), piattaforme tecnologiche (Google) e coordinamento internazionale (Shadowserver Foundation).

Per i team di sicurezza, le raccomandazioni immediate includono: audit delle estensioni installate negli ambienti di sviluppo, verifica dei pacchetti npm e Python con strumenti come npm audit e pip-audit, revisione dei log di accesso ai repository GitHub per force push anomali, e implementazione di controlli di integrità sulle dipendenze nei pipeline CI/CD.