(in)sicurezza digitale

2026-04-14 08:10:24

APT35 e la Cyber Guerra Parallela: come l’Iran aveva già compromesso ogni paese colpito nell’Operazione Epic Fury

Si parla di:
Toggle

• La notte del 28 Febbraio: quando la guerra digitale diventa fisica
• APT35 e la dottrina della Pre-Posizione
• Il modello di conflitto a tre fasi
• L’ecosistema APT iraniano: non solo APT35
• Infrastruttura di attacco: offuscamento multi-livello
• Vulnerabilità sfruttate: un catalogo di CVE note
• Il significato strategico: un nuovo standard di conflitto ibrido
• Indicazioni per i difensori

Prima che i missili iraniani illuminassero il cielo di sette nazioni, un’altra guerra era già in corso nelle reti digitali di quei paesi. L’analisi della campagna condotta da APT35 rivela come il gruppo legato all’IRGC avesse sistematicamente compromesso le infrastrutture critiche di ogni paese successivamente colpito dall’Operazione Epic Fury, trasformando la cyber intelligence in un componente integrale della dottrina militare iraniana.

La notte del 28 Febbraio: quando la guerra digitale diventa fisica

Il 28 febbraio 2026, Stati Uniti e Israele hanno lanciato l’Operazione Epic Fury (denominata “Operazione Roaring Lion” dalla parte israeliana): oltre 1.250 obiettivi colpiti nelle prime 48 ore, infrastrutture nucleari iraniane distrutte, connettività internet dell’Iran ridotta all’1-4% dei livelli normali in quello che è stato definito il più grande cyberattacco della storia. Ma ciò che i rapporti di intelligence successivi hanno rivelato è ancora più preoccupante: l’Iran non si trovava impreparato. Per mesi, forse anni, i suoi gruppi APT affiliati all’IRGC e al MOIS avevano già mappato, compromesso e pre-posizionato capacità offensive nelle reti digitali di ogni paese che avrebbe poi colpito.

APT35 e la dottrina della Pre-Posizione

APT35 — conosciuto anche come Charming Kitten, Phosphorus, Magic Hound e Mint Sandstorm — è il gruppo cyber più rappresentativo dell’IRGC Intelligence Organisation (Unit 1500, Department 40), attivo almeno dal 2014. La sua caratteristica distintiva non è la sofisticazione tecnica delle singole operazioni, ma la pazienza strategica: operazioni di ricognizione prolungate, accesso silenzioso mantenuto per mesi o anni prima di un’attivazione.

Secondo le analisi di CloudSek e dei ricercatori di IT Nerd, APT35 aveva documentabilmente compromesso infrastrutture nei seguenti paesi prima dei bombardamenti:

• Giordania: accesso ai dati dell’aviazione civile e al Ministero della Giustizia
• Emirati Arabi Uniti: sistemi di aviazione e asset governativi a Dubai
• Arabia Saudita: documenti governativi e infrastrutture energetiche; il malware Shamoon ha distrutto circa 15.000 workstation nel settore energetico saudita prima delle operazioni cinetiche
• Kuwait, Bahrain, Qatar: attività di ricognizione e targeting operativo
• Israele: sistemi industriali e infrastrutture civili

Il modello di conflitto a tre fasi

L’analisi degli eventi suggerisce un modello di conflitto ibrido strutturato in tre fasi sequenziali, ormai consolidato nella dottrina iraniana:

• Fase 1 — Ricognizione estesa e silenziosa: compromissione di sistemi internet-facing (Exchange Server, VPN, Fortinet FortiOS), installazione di webshell, tunneling nascosto, raccolta di intelligence su reti, persone e infrastrutture critiche
• Fase 2 — Degradazione pre-cinetica: attivazione di malware wiper (come Shamoon) per distruggere workstation, esfiltrazione di documenti strategici, interruzione di servizi prima degli attacchi fisici
• Fase 3 — Coordinamento post-attacco: entro 24 ore dall’avvio delle operazioni militari, creazione di un “Electronic Operations Room” che ha coordinato oltre 60 gruppi hacktivist per colpire contemporaneamente infrastrutture governative, finanziarie e critiche

L’ecosistema APT iraniano: non solo APT35

APT35 non ha operato in isolamento. Il Tenable Research ha identificato 12 gruppi APT iraniani attivi nelle settimane e mesi precedenti l’Operazione Epic Fury, coordinati attraverso strutture parallele:

Gruppi IRGC-affiliati: Pioneer Kitten (Fox Kitten, UNC757), Imperial Kitten (Tortoiseshell, TA456), CyberAv3ngers — quest’ultimo specializzato nel targeting di sistemi OT e PLC nei sistemi idrici. Gruppi MOIS-affiliati: APT34/OilRig (nuova infrastruttura per attacchi ed esfiltrazione), MuddyWater/Mango Sandstorm (picco di attività nella rete nel settembre 2025, con server distribuiti in Russia, Estonia e UK), Banished Kitten/Void Manticore (usa la persona Handala, wiper-focused). Gruppi IRGC-IO: APT42 (credential harvesting tramite social engineering). Gruppi IRGC-CEC: Cotton Sandstorm (revival della persona Altoufan Team).

Infrastruttura di attacco: offuscamento multi-livello

Particolarmente sofisticata è stata l’architettura di infrastruttura impiegata per mascherare l’attribuzione. Netcrook ha documentato uno schema di offuscamento a tre livelli:

• Livello base: ISP iraniani (Sefroyek Pardaz Engineering) come punto di origine
• Bulletproof hosting: ALEXHOST in Moldova e RouterHosting LLC nel Wyoming (USA) come nodi intermedi
• Shell company layer: società fittizie come Cloudblast (registrata negli USA, operativa a Dubai) e UltaHost (registrazioni UK/USA) per la gestione dell’infrastruttura front-end

Questa architettura ha reso estremamente complessa l’attribuzione rapida e le azioni legali di takedown durante le operazioni.

Vulnerabilità sfruttate: un catalogo di CVE note

Il documento Tenable elenca 67 CVE sfruttate dai gruppi iraniani, incluse vulnerabilità ben note mai patchate da molte organizzazioni. Tra le più critiche:

# CVE sfruttate dai gruppi APT iraniani (selezione)
CVE-2021-26855  # Microsoft Exchange Server - ProxyLogon SSRF
CVE-2021-26858  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-26857  # Microsoft Exchange - insecure deserialization
CVE-2021-27065  # Microsoft Exchange - post-auth arbitrary file write
CVE-2021-44228  # Apache Log4j2 - Log4Shell RCE
CVE-2022-40684  # Fortinet FortiOS/FortiProxy - authentication bypass
CVE-2020-3153   # Cisco ASA - path traversal
# Malware famiglie associate
BellaCiao        # RAT/implant IRGC (codice sorgente esposto in leak)
Sagheb RAT       # Remote Access Trojan IRGC
Shamoon          # Wiper distruttivo (energia, Arabia Saudita)
# Malware ICS/OT
Custom PLC malware targeting Rockwell Automation (CyberAv3ngers)

Il significato strategico: un nuovo standard di conflitto ibrido

La vicenda dell’Operazione Epic Fury e della sua dimensione cyber non è semplicemente la cronaca di un conflitto mediorientale. È la dimostrazione concreta di come le operazioni cyber siano diventate componenti integrali — non accessorie — della dottrina militare degli stati autoritari. Il pre-posizionamento di APT35 nelle reti dei paesi bersaglio anni prima delle operazioni fisiche stabilisce un precedente: in futuri conflitti, qualsiasi attore statale disporrà presumibilmente di “porte di accesso” già aperte nelle infrastrutture avversarie.

Per i difensori occidentali, la lezione è chiara: la minaccia non inizia il giorno in cui i missili vengono lanciati. Inizia quando un webshell silenzioso viene installato su un server Exchange non patchato da sei mesi.

Indicazioni per i difensori

• Patch immediata dei sistemi internet-facing: Exchange, FortiOS, Cisco ASA, Log4j sono ancora vettori attivi
• Audit degli accessi amministrativi: verificare account privilegiati, in particolare su sistemi OT/ICS
• Webshell hunting: scansione proattiva per webshell su server web esposti, soprattutto su CMS e sistemi legacy
• Validazione della copertura di detection: testare le soluzioni EDR/XDR contro BellaCiao, Sagheb RAT e le tecniche di tunneling documentate
• Monitoraggio per nuova infrastruttura hacktivist: i gruppi come Handala e CyberAv3ngers si riorganizzano rapidamente dopo le operazioni

APT35 e la Cyber Guerra Parallela: come l'Iran aveva già compromesso ogni paese colpito nell'Operazione Epic Fury - (in)sicurezza digitale

Prima che i missili iraniani illuminassero il cielo di sette nazioni, i gruppi APT dell'IRGC avevano già compromesso silenziosamente le infrastrutture critiche di quei paesi.

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

Spcnet.it

2026-04-14 07:46:54

Il Pattern Saga in .NET con Wolverine: gestire workflow distribuiti a lungo termine

Nei sistemi distribuiti, la gestione di processi di business che si estendono su più servizi e nel tempo rappresenta una delle sfide più complesse. Il Pattern Saga nasce proprio per risolvere questo problema: coordinare una sequenza di operazioni distribuite in modo affidabile, garantendo la consistenza dei dati anche in caso di errori parziali.

In questo articolo esploriamo come implementare il Pattern Saga in .NET utilizzando Wolverine, un framework moderno che semplifica notevolmente la gestione di messaggi e workflow complessi grazie al suo approccio convention-driven.

Cos’è il Pattern Saga?

Il Pattern Saga è un meccanismo di gestione delle transazioni distribuite che sostituisce le transazioni ACID tradizionali nei sistemi a microservizi. Invece di eseguire una sequenza di operazioni come un’unica transazione atomica, la saga suddivide il processo in una serie di passi indipendenti, ciascuno con la propria logica di compensazione in caso di fallimento.

Il principio fondamentale è semplice: se un passo fallisce o va in timeout, la saga esegue la logica di compensazione invece di lasciare il sistema in uno stato inconsistente. Questo approccio è particolarmente utile per processi di lunga durata come:

• Onboarding di nuovi utenti con email di verifica
• Processi di ordine e pagamento in e-commerce
• Workflow di approvazione multi-step
• Processi di provisioning di risorse cloud

Perché Wolverine?

Wolverine è un framework per .NET che adotta un approccio convention-driven alla messaggistica e ai workflow. A differenza di soluzioni come MassTransit o Rebus, Wolverine gestisce automaticamente routing dei messaggi, persistenza dello stato e correlazione, senza richiedere un’estesa configurazione tramite DSL per state machine.

Le principali dipendenze per iniziare sono:

WolverineFx (5.16.2)
WolverineFx.Postgresql (5.16.2)
WolverineFx.RabbitMQ (5.16.2)

Configurazione del progetto

La configurazione di Wolverine richiede pochi passaggi. Nell’entry point dell’applicazione, si configura il framework per utilizzare RabbitMQ come message broker e PostgreSQL per la persistenza dello stato:

builder.Host.UseWolverine(options =>
{
    options.UseRabbitMqUsingNamedConnection("rmq")
        .AutoProvision()
        .UseConventionalRouting();

    options.Policies.DisableConventionalLocalRouting();
    options.PersistMessagesWithPostgresql(connectionString!);
});

Dettagli importanti di questa configurazione:

• AutoProvision(): crea automaticamente exchange e code in RabbitMQ
• UseConventionalRouting(): instrada i messaggi in base ai nomi dei tipi
• DisableConventionalLocalRouting(): forza tutti i messaggi attraverso RabbitMQ
• PersistMessagesWithPostgresql(): archivia stato della saga e messaggi; crea una tabella per saga con serializzazione JSON

Definizione dei messaggi

Ogni passo della saga è rappresentato da un messaggio. Definiamo tutti i tipi di messaggio per un processo di onboarding utente:

public record SendVerificationEmail(Guid UserId, string Email);
public record VerificationEmailSent(Guid Id);
public record VerifyUserEmail(Guid Id);
public record SendWelcomeEmail(Guid UserId, string Email, string FirstName);
public record WelcomeEmailSent(Guid Id);
public record OnboardingTimedOut(Guid Id) : TimeoutMessage(5.Minutes());

Il record OnboardingTimedOut estende TimeoutMessage di Wolverine: questo fa sì che il messaggio venga consegnato automaticamente dopo 5 minuti, eliminando la necessità di scheduler esterni per gestire i timeout.

Implementazione della classe Saga

La saga viene implementata come una classe che estende Saga. Lo stato viene mantenuto come proprietà della classe:

public class UserOnboardingSaga : Saga
{
    public Guid Id { get; set; }
    public string Email { get; set; } = string.Empty;
    public string FirstName { get; set; } = string.Empty;
    public string LastName { get; set; } = string.Empty;
    public bool IsVerificationEmailSent { get; set; }
    public bool IsEmailVerified { get; set; }
    public bool IsWelcomeEmailSent { get; set; }
}

Il metodo Start: avvio della saga

Il metodo statico Start è il factory method che inizia la saga. Restituisce una tupla contenente l’istanza della saga, il comando iniziale e il messaggio di timeout pianificato:

public static (
    UserOnboardingSaga,
    SendVerificationEmail,
    OnboardingTimedOut) Start(
        UserRegistered @event,
        ILogger<UserOnboardingSaga> logger)
{
    var saga = new UserOnboardingSaga
    {
        Id = @event.Id,
        Email = @event.Email,
        FirstName = @event.FirstName,
        LastName = @event.LastName,
    };

    return (
        saga,
        new SendVerificationEmail(saga.Id, saga.Email),
        new OnboardingTimedOut(saga.Id));
}

Wolverine persiste automaticamente la saga e consegna tutti i messaggi restituiti. Elegante e senza boilerplate.

Metodi Handle: gestione degli eventi

I metodi Handle elaborano i messaggi in arrivo. Se restituiscono void, aggiornano solo lo stato; se restituiscono un messaggio, causano l’invio del passo successivo:

public void Handle(VerificationEmailSent @event, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Email di verifica inviata per l'utente {UserId}", Id);
    IsVerificationEmailSent = true;
}

public SendWelcomeEmail Handle(VerifyUserEmail command, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Email verificata per l'utente {UserId}", Id);
    IsEmailVerified = true;
    return new SendWelcomeEmail(Id, Email, FirstName);
}

public void Handle(WelcomeEmailSent @event, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Onboarding completato per l'utente {UserId}", Id);
    IsWelcomeEmailSent = true;
    MarkCompleted(); // Elimina lo stato dal database
}

Gestione del timeout e compensazione

Il timeout è un cittadino di prima classe in Wolverine. Se l’utente non verifica l’email entro 5 minuti, il handler del timeout gestisce la compensazione:

public void Handle(OnboardingTimedOut timeout, ILogger<UserOnboardingSaga> logger)
{
    if (IsEmailVerified)
    {
        logger.LogInformation(
            "Timeout ignorato - email già verificata per {UserId}", Id);
        return;
    }

    logger.LogWarning(
        "Onboarding scaduto per {UserId} - email non verificata", Id);
    MarkCompleted();
}

Gestione dei messaggi “orfani” con NotFound

Wolverine richiede la gestione esplicita del caso in cui arrivi un messaggio per una saga già terminata, tramite metodi statici NotFound:

public static void NotFound(VerifyUserEmail command, ILogger<UserOnboardingSaga> logger)
{
    logger.LogWarning("VerifyEmail ricevuto ma la saga {Id} non esiste più", command.Id);
}

public static void NotFound(OnboardingTimedOut timeout, ILogger<UserOnboardingSaga> logger)
{
    logger.LogInformation("Timeout per la saga già completata {Id}", timeout.Id);
}

Correlazione dei messaggi e gestione della concorrenza

Wolverine correla automaticamente i messaggi alle istanze della saga cercando nell’ordine: attributo [SagaIdentity], proprietà {SagaTypeName}Id, oppure proprietà Id. Non è necessaria alcuna configurazione esplicita per i casi standard.

Per la concorrenza, Wolverine applica di default il controllo di concorrenza ottimistico: quando più messaggi per la stessa saga arrivano contemporaneamente, uno riesce mentre gli altri vengono ritentati automaticamente. Attenzione: non invocare IMessageBus.InvokeAsync() all’interno dei handler della stessa saga, ma usare sempre i messaggi in cascata (valori di ritorno) per evitare problemi con dati obsoleti.

Opzioni di persistenza

Wolverine supporta tre strategie per la persistenza dello stato della saga:

• Lightweight Storage: serializza lo stato come JSON in tabelle dedicate per saga, zero configurazione ORM
• Marten: archivia le saghe come documenti con concorrenza ottimistica e ID fortemente tipizzati
• Entity Framework Core: mappa le saghe su tabelle queryabili, abilitando commit in singola transazione con altri dati

Il flusso completo

Il percorso “happy path” dell’onboarding segue questi passi:

1. L’evento UserRegistered attiva il metodo Start()
2. Viene creata l’istanza della saga, inviato SendVerificationEmail e pianificato OnboardingTimedOut
3. VerificationEmailSent aggiorna lo stato della saga
4. VerifyUserEmail ricevuto, viene inviato in cascata SendWelcomeEmail
5. WelcomeEmailSent completa il workflow, la saga viene eliminata

Se VerifyUserEmail non arriva entro 5 minuti, OnboardingTimedOut gestisce la compensazione e termina la saga.

Conclusione

Wolverine offre un approccio sorprendentemente pulito all’implementazione del Pattern Saga in .NET. La scelta convention-driven elimina gran parte del boilerplate tipico di altri framework, consentendo di concentrarsi sulla logica di business. La gestione automatica di persistenza, routing e correlazione dei messaggi, unita al supporto nativo per timeout e compensazione, lo rende una scelta solida per workflow distribuiti complessi.

Per i team che lavorano con architetture a microservizi in .NET, Wolverine merita certamente una valutazione approfondita come alternativa moderna ai pattern tradizionali di orchestrazione.

Fonte originale: Implementing the Saga Pattern With Wolverine — Milan Jovanović

Implementing the Saga Pattern With Wolverine

Long-running business processes don't fit neatly into a single request. Wolverine's Saga support gives you a convention-based approach to orchestrating workflows in .NET - with built-in timeout handling and compensation.

^{www.milanjovanovic.tech}

netzpolitik.org

2026-04-12 08:05:37

Stell dir vor, dass deine Standortdaten frei zugänglich im Netz für Leute zu kaufen sind. Klingt absurd? Ist aber Realität.

Sogenannte Databroker verkaufen von verschiedenen Apps gesammelte Standortdaten. Betroffen sind nicht nur Privatpersonen, sondern auch Politiker*innen oder hochrangige Beamte.

Wir haben jahrelang über das Thema geschrieben. Jetzt gibt es eine ARD-Doku zu unseren Recherchen:

"Gefährliche Apps - Im Netz der Datenhändler"

ardmediathek.de/video/story/ge…

Story: Gefährliche Apps · Im Netz der Datenhändler - hier anschauen

Was viele Smartphone-Nutzer wissen: Die Apps auf ihren Handys sammeln detaillierte Standortdaten. Was den meisten jedoch nicht bewusst ist: Die Informationen landen oft in einem undurchsichtigen, weltweiten Netzwerk aus Datenhändlern und Werbefirmen.

^{www.ardmediathek.de}

(in)sicurezza digitale

2026-04-13 13:43:24

La catena di fornitura software colpita: come CPUID è stata compromessa per distribuire il RAT stealer STX

Nel mese di aprile 2026, i ricercatori di sicurezza hanno identificato un attacco di supply chain sofisticato ai danni di CPUID, l’azienda dietro i popolarissimi tool di monitoraggio hardware CPU-Z e HWMonitor. Gli attaccanti hanno compromesso i server dell’azienda e reindirizzato i download ufficiali verso versioni malware. Per il corso di sei ore, gli utenti che scaricavano CPU-Z e HWMonitor dai siti ufficiali ricevevano un Remote Access Trojan precedentemente non documentato denominato STX RAT.

Questo incidente exemplifica una tendenza crescente nel panorama delle minacce informatiche: gli attaccanti hanno capito che il modo più efficace per ottenere una penetrazione di massa non è attaccare i singoli utenti, ma compromettere i software publisher e i loro canali di distribuzione. Se il software che stai scaricando oggi da un sito ufficiale contiene malware, la fiducia nella sicurezza della catena di distribuzione software crolla completamente.

Anatomia dell’attacco: come gli attaccanti hanno compromesso CPUID

A differenza di molti attacchi di supply chain che richiedono il compromesso dei sistemi di build e signing di un’azienda, gli attaccanti dietro questo incidente hanno adottato un approccio più mirato. Invece di cercare di infettare i binari finali di CPU-Z o HWMonitor (che sono firmati digitalmente), gli attaccanti hanno compromesso un’API secondaria utilizzata da CPUID per servire i link di download sul proprio sito web.

Modificando questa API, gli attaccanti hanno reindirizzato le richieste degli utenti verso file malevoli ospitati su Cloudflare R2. Le vittime pensavano di scaricare il software legittimo direttamente dal sito CPUID, ma ricevevano invece il malware. Non è stata trovata alcuna evidenza che gli attaccanti abbiano compromesso il processo di compilazione, il sistema di signing dei binari, o i server di controllo della versione di CPUID.

Il malware: STX RAT e le sue capacità

STX RAT è stato nominato da eSentire per la sua caratteristica firma tecnica: l’utilizzo consistente del byte STX come magic byte per prefisso nei messaggi diretti al command-and-control (C2).

Capacità di infostealer

Browser e credenziali web:

• Estrazione di password, cookie, e dati di autofill da Firefox, SeaMonkey, e browser basati su Chromium (Chrome, Edge, Brave, ecc.)
• Bypass potenziale di Application-Bound Encryption (ABE) sulle credenziali crittografate di Windows

Portafogli di criptovalute:

• Furto di chiavi private da Litecoin-Qt, Electrum, e altri wallet desktop
• Accesso a file di configurazione che contengono seed phrase o wallet backup

Credenziali client FTP:

• Estrazione di dati di accesso da FileZilla, WinSCP, e altri client FTP

Remote Desktop nascosto (HVNC)

Una capacità particolarmente insidiosa di STX RAT è il supporto per hidden VNC (Virtual Network Computing). Questo permette all’attaccante di:

• Avviare una sessione desktop virtuale nascosta che non è visibile agli utenti locali
• Controllare il mouse e la tastiera tramite l’API SendInput di Windows
• Eseguire applicazioni e navigare nel filesystem senza alcun indicatore visibile all’utente locale
• Accedere ai dati sensibili mentre l’utente legittimo è offline

I comandi supportati includono “starthvnc”, “keypress”, “mouseinput”, “mousewheel”, e “switchdesktop”, fornendo una suite completa di controllo remoto.

Tattica di delivery: DLL Sideloading

Il vettore di consegna del malware utilizza una tecnica classica pero ancora efficace: DLL sideloading (also known as DLL hijacking). Quando un utente scaricava il file trojanizzato da HWMonitor, conteneva:

• HWMonitor_x64.exe – Un file con nome legittimo (il binario vero di HWMonitor)
• CRYPTBASE.dll – Una DLL malevola che l’eseguibile legittimo carica automaticamente

Poiché Windows segue un ordine di ricerca delle DLL specifico, quando HWMonitor_x64.exe cerca di caricare CRYPTBASE.dll, trova prima la versione malevola nella stessa directory. Questo causa l’esecuzione del codice dell’attaccante con gli stessi privilegi dell’applicazione legittima.

Indicatori tecnici e infrastruttura C2

C2 Server: 95.216.51.236
Malware: STX RAT
Compromesso: 9-10 aprile 2026
Download malevoli: CPU-Z, HWMonitor versioni x64 e x86
DLL sideload: CRYPTBASE.dll

Il malware STX RAT è configurato per contattare il C2 all’indirizzo IP 95.216.51.236. Al primo contatto, il malware invia un messaggio di “introduzione” contenente: nome dell’host, nome utente, versione OS, status amministrativo, RAM disponibile, e elenco antivirus installati.

Inoltre, eSentire ha documentato che STX RAT supporta il routing del traffico C2 attraverso Tor per garantire anonimato, rendendo la tracciatura della comunicazione estremamente difficile.

Impatto e distribuzione

Kaspersky ha identificato oltre 150 vittime dirette dell’incidente CPUID. La distribuzione geografica mostra una concentrazione in Brasile, Russia, e Cina, con settori colpiti che includono: retail e e-commerce, manufacturing, consulting, telecomunicazioni, e agricoltura.

Il fatto che utenti in settori critici siano stati infetti suggerisce che STX RAT potrebbe essere utilizzato sia per cyber-spionaggio che per estorsione, poiché il malware combina capacità di reconnaissance (infostealing) con accesso remoto completo (HVNC).

Timeline dell’incidente

• 9 aprile 2026, ~15:00 UTC: Gli attaccanti modificano l’API di CPUID, reindirizzando i download
• 10 aprile 2026, ~10:00 UTC: CPUID scopre l’anomalia e ripristina l’API
• 10 aprile 2026: eSentire pubblica analisi tecnica del malware
• 13 aprile 2026: Kaspersky fornisce dati sulla distribuzione geografica

Raccomandazioni per le organizzazioni

• Verifica dell’integrità: Implementare processi di verifica dell’hash per tutti i software scaricati, anche da fonti ufficiali.
• Sandboxing: Eseguire software appena scaricati in ambienti virtuali isolati prima dell’installazione.
• Monitoraggio DLL loading: Implementare EDR in grado di rilevare il caricamento inusuale di DLL.
• Blocco C2: Aggiungere 95.216.51.236 alle blocklists firewall immediate.
• Credential rotation: Ruotare credenziali per chi ha scaricato HWMonitor/CPU-Z tra 9-10 aprile.
• Threat intelligence: Adottare YARA rules da eSentire per rilevare STX RAT in memoria.

Conclusione

L’incidente CPUID dimostra che la sicurezza della catena di distribuzione software non è negoziabile. Anche i siti ufficiali di società legittime possono essere compromessi. I defender devono adottare un mindset di “zero trust” verso qualsiasi software e implementare verifiche multi-strato di integrità e autenticità prima dell’esecuzione.

Spcnet.it

2026-04-13 13:42:44

.NET Aspire 13.2: la modalità isolata risolve i conflitti di porta nello sviluppo parallelo

Chiunque abbia lavorato con .NET Aspire su progetti reali si è prima o poi scontrato con il classico errore: “Port 17370 is already in use”. Capita quando si prova ad avviare una seconda istanza dell’AppHost — magari su un altro branch, o in un altro terminale — e le porte predefinite sono già occupate dalla prima istanza in esecuzione. Con Aspire 13.2, questo problema ha finalmente una soluzione elegante: la modalità isolata (--isolated).

In questo articolo vediamo nel dettaglio come funziona questa nuova funzionalità, i casi d’uso pratici, e le altre novità rilevanti di questa release.

Il problema: conflitti di porta nello sviluppo parallelo

In un tipico progetto .NET Aspire, l’AppHost configura i binding delle porte per tutti i servizi nell’orchestrazione: la dashboard su una porta, l’API su un’altra, il database su un’altra ancora. Questi binding sono statici per default, e questo crea problemi immediati quando si vuole eseguire due istanze dello stesso AppHost contemporaneamente:

• Sviluppo su due branch in parallelo con git worktrees
• Test di integrazione che richiedono un AppHost “live” mentre si continua a sviluppare
• Agenti AI che creano automaticamente worktree separati per task paralleli
• Pipeline CI/CD locali che eseguono più istanze dello stesso progetto

La soluzione tradizionale era modificare manualmente i port binding nella configurazione — un approccio fragile, soggetto a errori e difficile da gestire in team.

La soluzione: la flag --isolated

Aspire 13.2 introduce la flag --isolated che risolve il problema alla radice. L’utilizzo è semplicissimo:

aspire run --isolated
# oppure
aspire start --isolated

Quando si passa --isolated, la CLI genera un identificativo univoco per l’istanza corrente, e questo ID guida due comportamenti fondamentali:

1. Randomizzazione automatica delle porte

Invece di usare le porte definite staticamente nell’AppHost, ogni istanza isolata riceve un range di porte casuali disponibili. Dove un run normale potrebbe bindare i servizi su 8080, 8081, 8082, due istanze isolate potrebbero usare rispettivamente:

• Istanza 1: 15234, 15235, 15236
• Istanza 2: 22891, 22892, 22893

La cosa notevole è che il codice dell’applicazione non necessita alcuna modifica: il service discovery di Aspire risolve gli endpoint dinamicamente a runtime, quindi i servizi si “trovano” a prescindere dalle porte assegnate.

2. Isolamento dei user secrets

La configurazione rimane completamente separata per ogni istanza. Connection string, chiavi API e altre variabili d’ambiente non si “contaminano” tra run diversi, anche quando puntano a risorse Azure o database con nomi diversi. Questo è particolarmente importante in scenari di test dove ogni istanza deve operare in modo completamente autonomo.

Casi d’uso pratici

Git worktrees multipli

Il caso d’uso più comune: sviluppo su due branch in parallelo.

# Terminale 1 - branch principale
cd ~/projects/myapp-main
aspire run --isolated

# Terminale 2 - feature branch
cd ~/projects/myapp-feature-xyz
aspire run --isolated

Entrambe le istanze partono senza conflitti, con porte diverse assegnate automaticamente. La dashboard di Aspire di ciascuna istanza è accessibile su porte diverse, e i servizi di ciascuna istanza sono completamente separati.

Test di integrazione con AppHost live

Un pattern molto utile: eseguire test di integrazione contro un AppHost “live” mentre si continua a sviluppare sull’AppHost principale.

# AppHost per sviluppo interattivo
aspire run --isolated

# In un altro terminale: avvia i test che usano il loro AppHost dedicato
dotnet test --isolated-apphost

Con la modalità isolata, i test non interferiscono con l’ambiente di sviluppo e viceversa.

Sviluppo agentico

Questo è il caso d’uso che ha spinto direttamente lo sviluppo di questa feature. Gli agenti AI in VS Code Copilot possono creare automaticamente git worktree separati per task paralleli. Con --isolated, ogni agente può avviare il proprio AppHost nella sua directory di lavoro senza conflitti con la sessione principale dello sviluppatore.

Aspire 13.2 include anche il comando aspire agent init (rinominato da aspire mcp init) che configura automaticamente gli agenti per usare --isolated con i worktree git.

Nuovi comandi CLI in Aspire 13.2

La modalità isolata non è l’unica novità della CLI. Aspire 13.2 introduce una serie di nuovi comandi operativi che rendono la gestione delle istanze molto più potente:

aspire ps — lista delle istanze attive

Elenca tutti gli AppHost Aspire in esecuzione sulla macchina, con le relative informazioni (porte, stato, ID istanza). Utile specialmente quando si hanno più istanze isolate attive contemporaneamente e si vuole sapere cosa sta girando.

aspire ps
# Output:
# ID           PROJECT          STATUS    DASHBOARD
# abc123       myapp-main       Running   http://localhost:15234
# def456       myapp-feature    Running   http://localhost:22891

aspire describe — dettagli sulle risorse

Accede ai dettagli di una risorsa specifica direttamente dal terminale, senza dover aprire la dashboard:

aspire describe api
# Mostra endpoint, variabili d'ambiente, stato health, ecc.

aspire doctor — diagnostica dell’ambiente

Esegue un controllo completo dell’ambiente di sviluppo: verifica che tutte le dipendenze siano installate correttamente (Docker, .NET SDK, ecc.) e segnala eventuali problemi di configurazione.

aspire wait — attesa su uno stato specifico

Blocca l’esecuzione in script di automazione finché una risorsa non raggiunge uno stato specifico. Utile in pipeline CI/CD o in script di startup:

aspire run --isolated &
aspire wait --resource api --state Running
# Ora l'API è sicuramente up, posso eseguire i test

aspire export — export di telemetria e dati

Cattura telemetria e dati delle risorse in formato JSON per analisi offline o per integrazione con altri strumenti.

TypeScript AppHost in preview

Una delle novità più interessanti di Aspire 13.2 è il supporto preview per scrivere l’AppHost in TypeScript. Fino ad ora, l’AppHost era necessariamente un progetto C#. Con questa release, è possibile usare TypeScript con una sintassi idiomatica:

import { createBuilder } from '@aspire/hosting';

const builder = await createBuilder();

// Aggiunge Redis come risorsa
const cache = await builder.addRedis("cache");

// Aggiunge un servizio Node.js con dipendenza da Redis
const api = await builder.addNpmApp("api", "../api")
    .withReference(cache);

await builder.build().run();

Il TypeScript AppHost funziona come un processo guest che comunica tramite JSON-RPC con l’orchestrator .NET sottostante. La CLI gestisce automaticamente la generazione degli SDK TypeScript quando si esegue aspire add, e aspire restore li rigenera se necessario.

Questa funzionalità è ancora in preview e non è raccomandata per produzione, ma è un segnale chiaro della direzione che sta prendendo Aspire: abbracciare anche gli sviluppatori TypeScript/Node.js, non solo quelli .NET.

Miglioramenti alla dashboard

Export e import di telemetria

La dashboard introduce un dialog centralizzato “Manage logs and telemetry” che permette di:

• Esportare risorse e telemetria come JSON
• Esportare variabili d’ambiente come file .env
• Importare dati da sessioni precedenti

API HTTP per telemetria

Nuovo endpoint /api/telemetry sulla dashboard che permette query programmatiche dei dati di telemetria con supporto streaming NDJSON. Utile per integrare la telemetria di Aspire con strumenti di monitoring esterni o script di analisi.

Impostazione parametri dalla UI

È ora possibile impostare i parametri delle risorse direttamente dalla dashboard, con opzione di salvataggio nei user secrets. Questo elimina la necessità di modificare manualmente i file di configurazione per cambiare un parametro durante il debug.

Miglioramenti al visualizzatore GenAI

Chi usa Aspire con workload AI troverà utili i miglioramenti al GenAI visualizer: migliore gestione di schemi complessi, payload troncati, testo non-ASCII e navigazione tra definizioni di tool.

Altre novità rilevanti

Endpoint MCP per i servizi

È possibile dichiarare server Model Context Protocol (MCP) direttamente nell’AppHost con il nuovo metodo WithMcpServer():

var api = builder.AddProject<Projects.MyApi>("api")
    .WithMcpServer("/mcp");

Aspire gestirà automaticamente la discovery dell’endpoint MCP, rendendolo disponibile agli agenti AI che operano nell’ambiente.

Docker Compose publishing stabile

L’integrazione con Docker Compose passa da prerelease a stabile. È ora possibile generare un docker-compose.yaml completo direttamente dal modello di app Aspire con aspire publish --format docker-compose.

Azure Virtual Network

Nuovo pacchetto Aspire.Hosting.Azure.Network per la gestione di reti virtuali Azure:

var vnet = builder.AddAzureVirtualNetwork("vnet");
var subnet = vnet.AddSubnet("web", "10.0.1.0/24");
var natGateway = vnet.AddNatGateway("nat");


Breaking changes da tenere a mente

Se stai aggiornando un progetto Aspire esistente a 13.2, ci sono alcune breaking changes da considerare:

1. Variabili Service Discovery: usano ora lo schema endpoint invece del nome endpoint
2. File di configurazione: preferenza per aspire.config.json unificato (migrazione automatica al primo run)
3. Comandi risorse: resource-start → start, resource-stop → stop
4. Dashboard API: ora opt-in per dashboard standalone
5. Pacchetto AIFoundry: Aspire.Hosting.Azure.AIFoundry → Aspire.Hosting.Foundry
6. WithSecretBuildArg: rinominato in WithBuildSecret

Per aggiornare, usa:

aspire update --self   # aggiorna la CLI
aspire update          # aggiorna i pacchetti del progetto

Conclusione

Aspire 13.2 è una release sostanziosa che affronta problemi concreti del workflow di sviluppo. La modalità --isolated è probabilmente la novità più impattante per il day-to-day: risolve un pain point reale in modo elegante, senza richiedere modifiche al codice dell’applicazione.

L’aggiunta del TypeScript AppHost in preview è un segnale importante della direzione di Aspire verso un ecosistema più inclusivo, mentre i nuovi comandi CLI (ps, describe, doctor, wait) rendono Aspire molto più adatto a workflow di automazione e sviluppo agentico.

Chi lavora già con Aspire troverà questo aggiornamento decisamente consigliato. Chi non lo ha ancora provato, potrebbe essere il momento giusto per iniziare — soprattutto se lavora con architetture microservizi in .NET.

Fonti: Running Multiple Instances of an Aspire AppHost Without Port Conflicts · What’s new in Aspire 13.2

Running Multiple Instances of an Aspire AppHost Without Port Conflicts

Aspire 13.2 introduces isolated mode, letting you run multiple instances of the same AppHost in parallel without port conflicts.

^{James Newton-King (Aspire Blog)}

Spcnet.it

2026-04-13 09:09:55

Visual Studio Code 1.116: tutte le novità di aprile 2026

Microsoft ha rilasciato Visual Studio Code 1.116, l’aggiornamento di aprile 2026, che porta con sé una serie di miglioramenti significativi focalizzati sull’Agent Mode, sull’integrazione con Copilot e sulla produttività dello sviluppatore. In questo articolo analizziamo nel dettaglio le novità più rilevanti per chi usa VS Code come ambiente di sviluppo quotidiano.

Agent Mode e Copilot: le novità principali

Il grosso degli investimenti di questa release riguarda ancora una volta l’ecosistema degli agenti AI integrati nell’editor. Microsoft continua a spingere forte su questo fronte, e i risultati iniziano a farsi sentire in termini di produttività concreta.

Storico sessioni agenti nel Debug Panel

Una delle funzionalità più attese arriva finalmente: è ora possibile sfogliare lo storico delle sessioni degli agenti direttamente dall’Agent Debug Panel. Questo significa che non si perde traccia delle conversazioni precedenti con gli agenti, e si può tornare a consultare cosa un agente ha fatto in sessioni passate — utile soprattutto in workflow complessi dove si delega a Copilot l’esecuzione di task multi-step.

Generazione automatica dei nomi di branch

Il Copilot CLI agent può ora generare automaticamente i nomi dei branch Git a partire dal prompt dell’utente. Invece di dover pensare a un nome descrittivo, è sufficiente descrivere cosa si sta facendo e l’agente proporrà un nome di branch appropriato e consistente con le convenzioni del progetto. Una piccola cosa, ma che in team grandi fa davvero la differenza.

Controllo del reasoning effort

VS Code 1.116 introduce il controllo della profondità di ragionamento (reasoning effort) per le sessioni Copilot CLI. Questo permette di bilanciare velocità e qualità delle risposte: per task semplici si può usare un effort minore (risposte più rapide), mentre per problemi complessi si può alzare il livello per ottenere analisi più approfondite. Funzionalità particolarmente utile per chi lavora con modelli che supportano ragionamento esteso come o3 o Claude 3.7.

Strumenti terminale migliorati per gli agenti

Gli strumenti terminale degli agenti ricevono un aggiornamento importante: ora funzionano con i terminali in foreground. Questo vuol dire che send_to_terminal e get_terminal_output possono interagire con qualsiasi terminale visibile nell’interfaccia, non solo con quelli creati dall’agente stesso.

È stato aggiunto anche un pulsante Focus Terminal nel carosello delle domande dell’agente: quando un agente ha bisogno di input diretto (ad esempio una password o una conferma interattiva), l’utente può focalizzare il terminale con un click senza dover navigare manualmente nell’interfaccia.

Viene introdotto anche lo stato NeedsInput nel protocollo Agent Host: un nuovo status che segnala quando una sessione agente è in attesa di input utente. Questo permette alle estensioni e agli strumenti di terze parti di rilevare questa condizione e reagire di conseguenza — ad esempio mostrando notifiche o sbloccando blocchi di automazione.

Miglioramenti all’editor

Breakpoint widget tramite Alt+click

Una piccola ma benvenuta aggiunta: è ora possibile aprire il widget breakpoint con Alt+click direttamente nella gutter (la barra laterale con i numeri di riga) dell’editor. In precedenza era necessario usare click destro e navigare nel menu contestuale. Questo accelera il workflow di debugging, specialmente quando si devono impostare breakpoint condizionali o con log point.

CSS @[url=https://mastodon.social/users/import]Asia Link Import & Export[/url] con risoluzione node_modules

Per chi lavora con CSS e preprocessori, arriva il supporto per la risoluzione dei path node_modules negli import CSS. Ora è possibile fare Ctrl+Click su un import del tipo @import '~bootstrap/scss/bootstrap' e VS Code risolverà correttamente il percorso al modulo installato in node_modules. Funzionalità attesa da tempo, specialmente da chi usa SCSS in progetti con molte dipendenze npm.

Diff editor nei contesti agentic

I diff editor usati dagli agenti ora mostrano un pulsante “Open File” che permette di aprire direttamente il file originale dal diff. Una piccola friction in meno nel workflow di review delle modifiche proposte da Copilot.

TextMate grammars: nuovo token type “regex”

Per chi sviluppa estensioni con grammar TextMate, è stato aggiunto “regex” come token type supportato. Utile per definire regole di colorazione sintattica per espressioni regolari in linguaggi che le supportano natively.

Accessibilità

VS Code 1.116 porta diversi miglioramenti per l’accessibilità, in particolare per gli utenti che usano screen reader:

• Dialog di aiuto per l’input chat degli agenti: accessibile con ⌥F1 (macOS) o Alt+F1 (Windows/Linux), mostra comandi e scorciatoie disponibili nell’input chat degli agenti con istruzioni specifiche per gli screen reader.
• Navigazione risultati di ricerca: nuove istruzioni per navigare i risultati di ricerca con Ctrl+Down Arrow usando screen reader.
• Scorciatoie dedicate nell’app Agents: nuovi shortcut da tastiera per navigare tra la visualizzazione Changes, l’albero dei file nella Changes view e la Chat Customizations view — permettendo la navigazione full-keyboard senza toccare il mouse.

API per sviluppatori di estensioni

Chi sviluppa estensioni per VS Code trova in questa release alcune API nuove interessanti:

Diff cumulativi per sessione

Le API del protocollo Agent Host espongono ora i diff cumulativi per sessione: dopo ogni turno dell’agente sono disponibili statistiche aggregate sulle modifiche ai file effettuate durante l’intera sessione. Utile per costruire strumenti di monitoring o reporting sull’attività degli agenti.

Completamenti contestuali nell’app Agents

I completamenti attivati con il carattere # nell’app Agents ora supportano il context file scoping al workspace selezionato. Questo significa che i suggerimenti di completamento per i file sono limitati al workspace corrente, evitando confusione in setup multi-root.

Scorciatoia per il browser integrato

È stata aggiunta una scorciatoia globale per attivare/disattivare il browser integrato — particolarmente utile per chi fa sviluppo web e alterna frequentemente tra codice e preview.

Come aggiornare

VS Code si aggiorna automaticamente, ma se vuoi forzare l’aggiornamento puoi usare il menu Help → Check for Updates (Windows/Linux) o Code → Check for Updates (macOS). In alternativa, puoi scaricare l’installer direttamente da code.visualstudio.com.

Per consultare le release notes complete direttamente in VS Code, usa il comando Show Release Notes dalla Command Palette (Ctrl+Shift+P / Cmd+Shift+P).

Conclusione

VS Code 1.116 consolida ulteriormente l’ecosistema agentic dell’editor, con miglioramenti che rendono gli agenti AI più controllabili, più trasparenti e più integrati nel workflow quotidiano dello sviluppatore. Le novità sull’accessibilità sono benvenute, e le piccole migliorie all’editor (breakpoint widget, CSS imports) dimostrano che Microsoft non trascura nemmeno le funzionalità “classiche” in favore dell’hype sull’AI.

Il trend è chiaro: VS Code sta diventando sempre più un ambiente agentic-first, dove gli strumenti AI non sono plugin aggiuntivi ma cittadini di prima classe dell’editor. Per chi lavora già con Copilot in modalità agente, questo aggiornamento è decisamente consigliato.

Fonte: Visual Studio Code 1.116 Release Notes

Visual Studio Code - The open source AI code editor | Your home for multi-agent development

Visual Studio Code redefines AI-powered coding with GitHub Copilot for building and debugging modern web and cloud applications. Visual Studio Code is free and available on your favorite platform - Linux, macOS, and Windows.

^{code.visualstudio.com}

(in)sicurezza digitale

2026-04-13 08:29:16

Attacco SCADA nel mirino: le APT iraniane prendono di mira i controllori Unitronics negli Stati Uniti

Si parla di:
Toggle

• Contesto dell’operazione e portata dell’attacco
• Metodologie di attacco e indicatori tecnici
• Indicatori di compromissione (IoCs)
• Impatto operativo e rischi
• Raccomandazioni di difesa

A partire da marzo 2026, attori APT affiliati all’Iran hanno intensificato le operazioni di cyberattacco contro l’infrastruttura critica statunitense, sfruttando direttamente le esposizioni di controllori programmabili (PLC) di Unitronics e Rockwell Automation online. Secondo un avviso congiunto pubblicato dal CISA, dall’FBI e dalla NSA l’aprile 2026, questi attacchi rappresentano una minaccia diretta ai sistemi di controllo industriale (SCADA/HMI) che gestiscono funzioni critiche nelle utilities idriche, nei sistemi energetici e nelle strutture governative.

La novità inquietante è che gli attaccanti non stanno sfruttando vulnerabilità zero-day o malware sofisticato: invece, stanno utilizzando il software legittimo Rockwell Automation Studio 5000 Logix Designer per accedere direttamente ai PLC esposti, modificare i file di progetto contenenti la logica ladder, e falsificare i dati visualizzati sulle interfacce HMI (Human-Machine Interface). Una tecnica che trasforma il software di ingegneria industriale in un vettore di attacco praticamente invisibile alle difese tradizionali.

Contesto dell’operazione e portata dell’attacco

Le operazioni di ricognizione hanno identificato almeno 75 dispositivi compromessi distribuiti tra settori critici statunitensi. Tuttavia, il dato più allarmante emerge dall’analisi della superficie d’attacco: Censys ha riportato che oltre 5.219 PLC Rockwell/Allen-Bradley sono attualmente esposti a Internet, creando un bersaglio potenziale massivo per le operazioni offensive iraniane.

Gli attori APT affiliati all’Iran stanno accedendo ai dispositivi utilizzando indirizzi IP forniti da provider di hosting di terze parti, presumibilmente per mascherare la loro origine geografica. Una volta all’interno, stabiliscono connessioni autenticate sfruttando le credenziali ottenute da precedenti ricognizioni o mediante attacchi di brute force contro interfacce web esposte.

L’FBI ha formalmente valutato che questa campagna è motivata da ritorsioni geopolitiche legate alle ostilità tra Stati Uniti, Israele e Iran. Le operazioni si sono intensificate in parallelo ai crescenti attriti regionali, suggerendo che le infrastrutture critiche americane sono state designate come obiettivi di rappresaglia informatica.

Metodologie di attacco e indicatori tecnici

Gli attaccanti mantengono persistenza attraverso la modifica diretta dei file di progetto .ACD (AutoCAD) che contengono la logica ladder, gli script di automazione e le configurazioni dei PLC. Modificando questi file prima di sincronizzarli con i controller, gli attori APT possono inserire comportamenti malevoli che verranno riprodotti ogni volta che il PLC viene alimentato o riavviato.

Le porte di accesso monitorate includono:

• Porta 44818 (Rockwell Automation native)
• Porta 2222 (SSH alternativo)
• Porta 102 (Siemens S7 protocol)
• Porta 22 (SSH standard)
• Porta 502 (Modbus TCP)

La molteplicità di protocolli suggerisce che gli attaccanti stanno sfruttando un’unica campagna per accedere a dispositivi di produttori diversi: non solo Rockwell Automation e Unitronics, ma potenzialmente anche controllori Siemens S7 e altri standard OT.

Una volta dentro, gli attori hanno estratto file di configurazione contenenti la logica intera dell’infrastruttura, fornendogli una roadmap completa dell’architettura di controllo. Inoltre, hanno modificato i valori visualizzati sulle interfacce HMI per mostrare false letture agli operatori umani, disaccoppiando quello che gli ingegneri vedono sugli schermi da quello che i PLC stanno effettivamente eseguendo.

Indicatori di compromissione (IoCs)

Sebbene il CISA non abbia pubblicato una lista completa di IoCs nella versione iniziale dell’avviso, gli indirizzi IP utilizzati dagli attaccanti includono range associati a provider di hosting europei. Le organizzazioni dovrebbero monitorare:

• Connessioni non autorizzate alle porte 44818, 2222, 102, 22, 502
• Modifiche inaspettate ai file .ACD e .L5K (Rockwell Automation project files)
• Accessi a Studio 5000 Logix Designer durante ore non-lavorative
• Alterazioni dei timestamp di accesso ai sistemi HMI/SCADA
• Estrazione massiva di file di progetto verso destinazioni esterne

Impatto operativo e rischi

Le organizzazioni vittime hanno segnalato varie forme di disruption:

• Interruzioni nei sistemi di trattamento delle acque
• Alterazioni nei parametri di controllo energetico
• Falsificazione dei dati storici di telemetria
• Potenziale esposizione di procedimenti critici a spilorcare/manipolazione

Una delle implicazioni più insidiose è che i PLC modificati continuano a funzionare apparentemente normalmente secondo le metriche di superficie, mentre la logica sottostante è stata completamente compromessa. Uno scenario di “perfect impersonation” che rende estremamente difficile rilevare l’attacco senza audit tecnici approfonditi della logica ladder.

Raccomandazioni di difesa

Le organizzazioni OT dovrebbero implementare immediatamente:

• Air-gapping e segmentazione: disconnettere fisicamente i PLC critici da qualsiasi rete esterna. Se la connettività remota è essenziale, implementare DMZ dedicate e controlli di accesso granulari.
• Protezione dell’accesso remoto: disabilitare gli accessi da Studio 5000 Logix Designer su connessioni remote non crittografate. Implementare VPN con autenticazione multi-fattore.
• Monitoraggio della logica ladder: implementare sistemi di versioning e change management per i file .ACD. Qualsiasi modifica deve essere confrontata con baseline storiche approvate.
• Honeypots e deception: distribuire controller PLC decoy connessi a Internet per rilevare e tracciare i tentativi di accesso malevoli.
• Incident response capability: istituire playbook di risposta per scenari di compromissione PLC.

L’adozione di queste contromisure è critica per le organizzazioni nei settori water, energy, government, e manufacturing. La sofisticazione dell’attacco non risiede nel malware o negli exploit, ma nella comprensione profonda degli ambienti OT e nella capacità di manipolare la realtà percepita dagli operatori umani.

Attacco SCADA nel mirino: le APT iraniane prendono di mira i controllori Unitronics negli Stati Uniti - (in)sicurezza digitale

A partire da marzo 2026, attori APT affiliati all'Iran hanno compromesso almeno 75 controllori programmabili Unitronics negli USA, utilizzando il software legittimo Studio 5000 Logix Designer per modificare la logica ladder e falsificare i dati HMI.

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

(in)sicurezza digitale

2026-04-12 14:24:04

ShinyHunters colpisce Rockstar Games attraverso Anodot: la campagna Salesforce-Snowflake mette a rischio 400 aziende

Non è stato bucato Rockstar Games. Non è stato bucato Snowflake. È stato compromesso il fornitore SaaS che monitorava i costi cloud di Rockstar, e attraverso di lui gli attaccanti sono entrati nell’ambiente Snowflake del produttore di GTA come se fossero un servizio interno legittimo. L’11 aprile 2026, ShinyHunters ha pubblicato sul proprio dark web leak site la rivendicazione dell’attacco, fissando al 14 aprile la scadenza per il pagamento o la pubblicazione dei dati. Ma la storia di Rockstar è solo la punta dell’iceberg: il gruppo rivendica l’accesso ai dati di oltre 400 organizzazioni collegate a integrazioni Salesforce, in quella che si configura come una delle campagne di esfiltrazione dati più sistematiche del 2026.

Il vettore: Anodot come cavallo di Troia

Il punto di ingresso non è stato né Rockstar Games né Snowflake direttamente, ma Anodot, una piattaforma SaaS specializzata nel monitoraggio dei costi cloud e nell’anomaly detection per infrastrutture enterprise. Rockstar utilizza Anodot per la governance dei costi sulla propria infrastruttura cloud, e questo ha creato una superficie di attacco inaspettata: ShinyHunters ha compromesso l’infrastruttura di Anodot, estratto i token di autenticazione Snowflake presenti nei dati di configurazione del cliente, e li ha utilizzati per accedere all’ambiente Snowflake di Rockstar con credenziali del tutto legittime agli occhi dei sistemi di controllo.

Il meccanismo è elegante nella sua semplicità: un tool di monitoraggio dei costi cloud deve per definizione avere accesso in lettura alle metriche e ai dati dell’infrastruttura monitorata. Quei token di accesso — validi, non scaduti e provenienti da un IP “conosciuto” — sono diventati le chiavi del regno. I team di sicurezza di Rockstar, abituati a vedere traffico normalizzato da Anodot, non hanno rilevato anomalie per un periodo significativo. Quando l’esfiltrazione è stata individuata, ShinyHunters aveva già portato a termine l’operazione.

I dati in gioco: da GTA Online ai contratti riservati

La portata potenziale dell’esfiltrazione da Rockstar è notevole. I database Snowflake di una società come Rockstar Games contengono strati di dati estremamente sensibili: record finanziari di GTA Online e Red Dead Online, incluse le microtransazioni di decine di milioni di giocatori globali; dati di profilazione geografica e di spesa degli utenti; timeline di marketing interno con dettagli su lanci di prodotto futuri — GTA 6 su tutti — e, potenzialmente, contratti con Sony, Microsoft, doppiatori e label musicali. Se questi ultimi materiali fossero pubblicati, le implicazioni andrebbero ben oltre una multa GDPR: negoziazioni attive su IP, compensi e accordi esclusivi potrebbero essere compromesse.

Rockstar Games ha confermato l’incidente in una dichiarazione breve e misurata, affermando che l’attacco “non ha alcun impatto sulla nostra organizzazione o sui nostri giocatori”. Una posizione che i ricercatori di sicurezza hanno accolto con cauto scetticismo: le conseguenze di una breach su dati di questa natura raramente sono immediate o visibili, e tendono a manifestarsi nei mesi successivi sotto forma di leak mirati, manipolazioni di mercato o negoziazioni pilotate da materiale riservato.

La campagna allargata: 400+ organizzazioni nell’ecosistema Salesforce

Il caso Rockstar non è isolato ma fa parte di una campagna sistematica. ShinyHunters rivendica l’accesso ai dati di oltre 400 organizzazioni legate a integrazioni Salesforce, in quella che appare come un’operazione metodica contro l’ecosistema di fornitori SaaS interconnessi che gestiscono dati enterprise critici. Tra i nomi emersi figurano Cisco, la telco canadese Telus, l’operatore olandese Odido, e — in modo ancora non verificato indipendentemente — riferimenti a dati della Commissione Europea.

Due casi documentati nei giorni precedenti all’annuncio su Rockstar illustrano la dimensione operativa: Marcus & Millichap, società immobiliare statunitense quotata in borsa, ha visto rivendicata l’esfiltrazione di oltre 30 milioni di record Salesforce contenenti dati personali (PII); Abrigo, fornitore di software per il settore bancario, conta 1,7 milioni di record Salesforce potenzialmente compromessi. Entrambe le rivendicazioni portano la stessa firma e la stessa scadenza del 14 aprile 2026. La serialità dell’operazione suggerisce un accesso strutturale all’ecosistema Salesforce, probabilmente attraverso uno o più fornitori di integrazione condivisi.

ShinyHunters: anatomia di un’operazione di estorsione seriale

ShinyHunters non è un gruppo improvvisato. Attivo almeno dal 2020, il collettivo ha costruito un curriculum di breach di alto profilo che include la violazione di Ticketmaster (560 milioni di record nel 2024), Santander Bank, AT&T e decine di altre organizzazioni. Il modello operativo è consolidato e ripetibile: compromissione silenziosa dell’infrastruttura target o di un suo fornitore, esfiltrazione dei dati, pubblicazione della rivendicazione su dark web leak site con scadenza ravvicinata pensata per massimizzare la pressione psicologica sul management della vittima.

La scelta di attaccare la filiera dei fornitori SaaS — piuttosto che i target diretti — è una evoluzione tattica significativa e preoccupante. Strumenti come Anodot, che gestiscono token e credenziali di accesso ai dati cloud delle proprie aziende clienti, sono nodi ad altissimo valore nella catena di fornitura digitale. Un singolo breach di un fornitore SaaS condiviso può moltiplicare esponenzialmente il numero di vittime downstream, esattamente come accade negli attacchi alla supply chain software.

Raccomandazioni: gestire il rischio della fiducia transitiva

Il caso Rockstar-Anodot-Snowflake è un caso di studio esemplare sul concetto di fiducia transitiva non controllata. Quando si delega l’accesso ai propri dati a un fornitore terzo, si estende implicitamente la propria superficie di attacco all’intera catena di sicurezza di quel fornitore. Le misure difensive prioritarie includono: adozione di token di accesso a scope minimo e breve durata con rotazione automatica; IP allowlisting per le credenziali di accesso ai data warehouse; abilitazione obbligatoria di MFA anche per gli account di servizio Snowflake; monitoraggio del volume e dei pattern di query per identificare esfiltrazione massiva; e una procedura sistematica di vendor security assessment che includa evidenze SOC2 Type II e penetration test annuali prima di concedere accesso a dati sensibili.

La domanda che ogni CISO con integrazioni SaaS attive dovrebbe porsi oggi è semplice: sapete esattamente quali fornitori terzi hanno accesso — diretto o indiretto — ai vostri dati cloud? Avete verificato la loro postura di sicurezza di recente? E soprattutto: se uno di loro venisse compromesso domani, sareste in grado di revocare immediatamente l’accesso? La risposta a queste tre domande definisce la differenza tra una gestione proattiva del rischio di terze parti e la prossima vittima di ShinyHunters.

(in)sicurezza digitale

2026-04-12 09:37:29

UNC1069 trasforma Axios in un vettore di spionaggio: WAVESHAPER.V2 colpisce la supply chain npm

Per tre ore e diciannove minuti, tra la mezzanotte e le 03:20 UTC del 31 marzo 2026, chi ha eseguito npm install axios ha involontariamente invitato un RAT nordcoreano nei propri sistemi. L’attacco alla supply chain del pacchetto Axios — 70 milioni di download settimanali, il client HTTP più usato dell’ecosistema JavaScript — porta la firma di UNC1069, un cluster APT legato alla Corea del Nord e motivato finanziariamente che da anni prende di mira sviluppatori e infrastrutture crypto. L’operazione dimostra ancora una volta che il vettore più efficace per infiltrarsi in ambienti protetti non è un exploit zero-day: è la fiducia umana.

L’ingegneria sociale che ha aperto la porta

Tutto comincia mesi prima della compromissione vera e propria. Gli operatori di UNC1069 si sono avvicinati a Jason Saayman, maintainer principale di Axios su npm, fingendosi il fondatore di una società legittima e ben nota nel settore tech. Non si sono limitati a creare un profilo falso: hanno clonato digitalmente l’identità della persona reale, creando una replica convincente sia del soggetto sia dell’azienda. “Hanno calibrato ogni dettaglio specificamente su di me”, ha scritto Saayman nel post-mortem dell’incidente.

Il contatto si è trasformato in una chiamata video su Microsoft Teams. Durante il meeting, gli attaccanti hanno simulato un problema audio e hanno convinto Saayman a installare un componente “mancante” per risolvere l’incompatibilità. Il file che il maintainer ha eseguito non era una patch per Teams: era WAVESHAPER.V2, il RAT cross-platform del gruppo. Da quel momento UNC1069 disponeva delle credenziali npm di Saayman e del controllo sul suo ambiente di sviluppo.

La catena di attacco: da npm al C2 in tre passi

Una volta ottenuto l’accesso all’account npm, gli attaccanti hanno pubblicato due release backdoorate: axios@1.14.1 e axios@0.30.4. Entrambe iniettavano una dipendenza malevola — plain-crypto-js@4.2.1 — che non esiste nel registro legittimo npm. Il pacchetto conteneva SILKBELL, un dropper offuscato che si attivava automaticamente tramite un hook postinstall nello script setup.js, senza alcuna interazione da parte dell’utente o dello sviluppatore.

SILKBELL stabiliva una connessione con l’infrastruttura C2 di UNC1069 e scaricava WAVESHAPER.V2, adattando il payload al sistema operativo rilevato. Il comportamento variava per piattaforma:

• Windows: copia di powershell.exe in %PROGRAMDATA%\wt.exe, persistenza via chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run con nome “MicrosoftUpdate” e batch nascosto system.bat.
• macOS: binario Mach-O installato in /Library/Caches/com.apple.act.mond, eseguito tramite zsh.
• Linux: backdoor Python scaricato in /tmp/ld.py ed eseguito con nohup.

WAVESHAPER.V2: capacità operative e firma anomala

La versione V2 del backdoor introduce comunicazione via JSON, raccolta estesa di informazioni di sistema e un set ampliato di comandi rispetto alla versione precedente documentata da Mandiant. Le principali funzionalità includono: peinject per l’iniezione in memoria di shellcode e PE, rundir per la ricognizione del filesystem con raccolta di metadati, esecuzione di script arbitrari e terminazione di processi. Il beaconing avviene via HTTP ogni 60 secondi verso la porta 8000 del server C2.

L’anomalia più curiosa — e paradossalmente più utile per i difensori — è la stringa User-Agent hardcodata in tutte e tre le varianti di piattaforma: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0). Un fingerprint da Internet Explorer 8 su Windows XP è immediatamente anomalo su qualsiasi macchina moderna, e ancor più su host macOS o Linux. Sebbene garantisca un routing coerente lato server C2, è un indicatore di compromissione banalmente rilevabile su qualunque proxy o SIEM moderno.

Attribuzione: UNC1069 e la rete finanziaria di Pyongyang

L’attribuzione a UNC1069 è stata effettuata in modo indipendente da Google Threat Intelligence Group (GTIG), Microsoft Threat Intelligence e Mandiant. Il cluster è tracciato sotto diversi alias: Sapphire Sleet, STARDUST CHOLLIMA, Alluring Pisces, BlueNoroff, CageyChameleon e CryptoCore. Attivo almeno dal 2018, UNC1069 è motivato finanziariamente e ha storicamente preso di mira istituzioni finanziarie, exchange di criptovalute e maintainer di pacchetti open source ad alta diffusione, nella logica di massimizzare il potenziale di accesso a valle.

Il collegamento tecnico più solido emerso dall’analisi è l’infrastruttura C2: il dominio sfrclak[.]com risolve sull’IP 142.11.206[.]73, e le connessioni da questo server sono state tracciate verso un nodo AstrillVPN precedentemente attribuito a UNC1069 in campagne separate. Il binario macOS presenta poi sovrapposizioni significative con WAVESHAPER nella versione originale documentata da Mandiant, rendendo la catena di attribuzione robusta e multi-vendor.

Impatto e analisi del blast radius

La finestra di esposizione — circa tre ore — ha limitato il numero diretto di compromissioni. eSentire ha identificato 19 organizzazioni clienti colpite, principalmente nel settore dello sviluppo software in Nord America ed EMEA. Tuttavia la nuova analisi pubblicata il 12 aprile 2026 sottolinea come il “blast radius” reale vada ben oltre queste cifre dirette: pipeline CI/CD, container Docker, ambienti serverless e toolchain di build che eseguono automaticamente npm ci potrebbero aver scaricato le versioni malevole senza che gli sviluppatori ne fossero consapevoli, specialmente in organizzazioni prive di monitoraggio sui log di installazione npm.

Indicatori di Compromissione (IoC)

# Pacchetti npm malevoli
axios@1.14.1
axios@0.30.4
plain-crypto-js@4.2.1

# Hash file
SILKBELL (setup.js): e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09
Windows RAT:         617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101

# Infrastruttura C2
IP:       142.11.206[.]73
Domini:   sfrclak[.]com
          callnrwise[.]com
Endpoint: hxxp://sfrclak[.]com:8000/6202033
Porta:    8000 (beaconing HTTP, intervallo 60s)

# User-Agent anomalo (presente su Windows, macOS e Linux)
"mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)"

# Persistenza Windows
Chiave registro: HKCU\Software\Microsoft\Windows\CurrentVersion\Run -> "MicrosoftUpdate"
File: %PROGRAMDATA%\wt.exe (copia mascherata di powershell.exe)
File: system.bat (nascosto)

# Persistenza macOS
/Library/Caches/com.apple.act.mond

# Persistenza Linux
/tmp/ld.py (eseguito con nohup)

Raccomandazioni per i difensori

Chi ha eseguito npm install o npm ci il 31 marzo 2026 tra le 00:21 e le 03:20 UTC deve considerare i propri ambienti compromessi fino a prova contraria. Le azioni prioritarie: verificare i log di installazione npm per la presenza di axios@1.14.1, axios@0.30.4 o plain-crypto-js; controllare il traffico di rete in uscita verso 142.11.206.73 su porta 8000 con il caratteristico User-Agent IE8; cercare la chiave di registro “MicrosoftUpdate” nel percorso Run e il file wt.exe in %PROGRAMDATA% su sistemi Windows.

Sul piano preventivo, le pratiche raccomandate includono: pinning esplicito delle versioni nei file lock, disabilitazione degli aggiornamenti automatici delle dipendenze, implementazione di policy di “release cooldown” supportate dai principali package manager, monitoraggio continuo dell’esecuzione degli hook postinstall, e adozione di soluzioni di Software Composition Analysis (SCA) che alertino su nuove dipendenze transitive non attese. L’incidente Axios dimostra che anche i pacchetti più fidati e consolidati possono diventare vettori di attacco: la fiducia cieca nell’ecosistema open source è un lusso che le organizzazioni non possono più permettersi.