Spcnet.it

2026-06-11 12:37:15

Docker Desktop 4.77.0: export dei log, estensioni sicure con digest pinning e nuovi comandi docker pass

Docker ha rilasciato Docker Desktop 4.77.0 l’8 giugno 2026, portando funzionalità attese da chi lavora quotidianamente con container in ambienti di sviluppo su Windows, Mac e Linux. Il punto di forza di questa release è il miglioramento della gestione dei log, la sicurezza nella distribuzione delle estensioni Marketplace e nuovi comandi per la gestione sicura dei segreti con docker pass.

Novità principali

Export dei log dalla Logs view

È ora possibile esportare i dati di log direttamente dalla Logs view di Docker Desktop. Fino a questa release, visualizzare e copiare manualmente i log di un container era l’unica opzione nell’interfaccia grafica; ora è possibile esportarli in modo strutturato, utile per condividere output di debug o alimentare strumenti di analisi esterni.

Insieme all’export, è stato aggiunto un toggle per la sensibilità alle maiuscole nella barra di ricerca dei log: la ricerca è case-insensitive per default, ma può essere commutata in case-sensitive per trovare identificatori o messaggi di errore specifici.

Estensioni Marketplace installate tramite digest OCI fisso

Un miglioramento significativo per la sicurezza della supply chain: le estensioni del Marketplace di Docker Desktop vengono ora installate e aggiornate usando il digest del manifest OCI (hash crittografico SHA256), invece del tag. Questo protegge contro attacchi di tipo tag mutation, in cui un’immagine pubblicata con un determinato tag viene successivamente sostituita con una versione malevola dopo la pubblicazione.

Il principio è lo stesso già consigliato in produzione per i Dockerfile:

# Più sicuro: riferimento per digest immutabile
FROM mcr.microsoft.com/dotnet/aspnet@sha256:a1b2c3d4...

# Meno sicuro: il tag può cambiare dopo la pubblicazione
FROM mcr.microsoft.com/dotnet/aspnet:10.0

Nuovi comandi docker pass

docker pass è lo strumento di Docker Desktop per la gestione dei segreti. Con questa release riceve due nuovi comandi:

• docker pass run — inietta i segreti salvati come variabili d’ambiente in comandi eseguiti sull’host, eliminando la necessità di esporre segreti permanentemente nella shell
• docker pass plugins — permette la gestione dinamica dei plugin di docker pass

Esempio d’uso:

# Senza docker pass: segreto esposto nella shell
export DATABASE_URL="postgres://utente:password@host/db"
./myapp

# Con docker pass run: segreto iniettato solo durante l'esecuzione
docker pass run -- ./myapp

Supporto OAuth per MCP server in Gordon

Gordon, l’assistente AI integrato in Docker Desktop, riceve i pulsanti Authenticate e Cancel per i flussi OAuth dei server MCP. I team che usano MCP server con autenticazione OAuth possono ora completare o rifiutare il flusso direttamente dalla chat bubble di Gordon.

Componenti aggiornati

• Docker Engine v29.5.3
• containerd v2.2.4
• Docker Buildx v0.34.1
• Docker Offload v0.6.3
• Docker Agent v1.70.0
• Docker MCP gateway v0.42.2
• docker pass v0.1.2
• DHI CLI (dhictl) v0.0.4

Bug fix rilevanti

• Windows/WSL: risolto un blocco su “Starting the Docker Engine…” dopo una registrazione WSL fallita che lasciava un VHDX orfano su disco
• Windows Containers mode: risolto un hang allo shutdown che causava uscite lente o incomplete
• ECI (Enhanced Container Isolation): corretta una regressione per cui docker cp con ECI abilitato impostava erroneamente la proprietà dei file a nobody:nogroup
• Shutdown: corretto il codice di uscita 150 su shutdown via SIGINT/SIGTERM, che generava falsi segnali di errore nei sistemi di supervisione

Come aggiornare

Docker Desktop si aggiorna automaticamente nella maggior parte delle configurazioni. Per aggiornare manualmente:

# Linux (.deb)
sudo apt-get update && sudo apt-get install --only-upgrade docker-desktop

In alternativa, usate Docker menu → Check for Updates oppure scaricate direttamente dalla pagina delle release notes ufficiali.

Fonte: Docker Desktop Release Notes — docs.docker.com

release-notes

^{docs.docker.com}

Spcnet.it

2026-06-11 12:46:48

Ottimizzare TLS e HTTPS su Nginx: ridurre TTFB e latenza

TLS su Nginx: perché il tuning fa la differenza su HTTPS

Quando si parla di prestazioni web, l’ottimizzazione del TLS è spesso trascurata in favore di interventi più vistosi come la cache applicativa o l’indicizzazione del database. Eppure, su un server Nginx esposto in HTTPS, ogni handshake TLS non ottimizzato aggiunge latenza misurabile a ogni connessione nuova. Questa guida raccoglie le configurazioni che un sistemista esperto dovrebbe avere presenti per tenere basso il TTFB (Time To First Byte) e ridurre l’overhead delle connessioni sicure.

Una premessa importante: il tuning TLS non salva un’applicazione lenta. Se la generazione della pagina richiede 800ms, ottimizzare il TLS porterà al massimo qualche decina di millisecondi in meno. Il vero valore di queste configurazioni emerge su backend già veloci, dove l’overhead del protocollo diventa la variabile dominante.

TLS 1.2 o TLS 1.3: quale usare?

Dal 30 giugno 2018 il PCI Security Standards Council richiede la disabilitazione di SSL 3.0, TLS 1.0 e TLS 1.1. Ad oggi, la configurazione raccomandata è supportare esclusivamente TLS 1.2 e TLS 1.3:

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 è decisamente preferibile: riduce il numero di round-trip necessari per il handshake (da 2 a 1) e rimuove algoritmi di cifratura obsoleti. Se il target è esclusivamente moderno (browser aggiornati, client API recenti), si può anche forzare solo TLS 1.3:

ssl_protocols TLSv1.3;

Tuttavia, TLS 1.2 rimane necessario per compatibilità con client enterprise, dispositivi embedded e alcune librerie legacy. Per la maggior parte dei server in produzione, supportare entrambi è la scelta più pragmatica.

Abilitare HTTP/2 e HTTP/3 (QUIC)

HTTP/2 è diventato lo standard de facto e Nginx lo supporta nativamente. Dalla versione 1.25.1, la direttiva è cambiata: non va più in listen ma come direttiva separata nel blocco server:

listen 443 ssl;
http2 on;

Per chi vuole spingersi a HTTP/3 con QUIC (disponibile nei pacchetti Nginx mainline compilati con BoringSSL o quic-go), la configurazione si estende così:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    http2 on;

    ssl_certificate     /path/to/your/certificate.pem;
    ssl_certificate_key /path/to/your/key.pem;

    # Comunica al client il supporto HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Per verificare quale protocollo viene negoziato dal lato command-line:

# Verifica HTTP/2
curl --http2 -I https://tuo-dominio.com/

# Verifica HTTP/3
curl --http3 -I https://tuo-dominio.com/

Session cache e session tickets: differenze chiave

La session cache lato server permette di riutilizzare i parametri crittografici di una sessione TLS precedente, evitando il full handshake per connessioni successive dello stesso client. In Nginx si configura così:

ssl_session_cache shared:SSL:10m;  # ~40.000 sessioni per MB
ssl_session_timeout 1d;

I session tickets sono un meccanismo alternativo: invece di conservare lo stato sul server, il server cifra i parametri della sessione e li invia al client, che li ripresenta alla connessione successiva. Questo elimina lo stato server-side ma introduce rischi se la chiave di cifratura dei ticket viene compromessa (forward secrecy ridotta). La raccomandazione per ambienti ad alta sicurezza è disabilitarli:

ssl_session_tickets off;

Nella pratica, su infrastrutture con bilanciamento del carico senza sticky sessions, i ticket sono spesso l’unico modo per ottenere session resumption tra istanze diverse. Valutare caso per caso.

OCSP Stapling: eliminare la latenza di validazione del certificato

Senza OCSP Stapling, ogni nuovo client deve contattare la CA (Certificate Authority) per verificare che il certificato non sia stato revocato. Questo aggiunge una richiesta di rete esterna al percorso critico dell’handshake. Con lo stapling, è Nginx stesso a interrogare periodicamente la CA e a includere la risposta firmata direttamente nell’handshake TLS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Il parametro ssl_trusted_certificate deve puntare alla catena completa (root CA inclusa), non solo al certificato del server. Il resolver è necessario perché Nginx deve risolvere l’hostname della CA tramite DNS.

Ridurre ssl_buffer_size

Il valore predefinito di ssl_buffer_size in Nginx è 16KB, dimensionato per throughput massimo. Questo significa però che il primo byte del payload arriva al client solo dopo che il primo chunk da 16KB è stato riempito e cifrato. Per siti dove il TTFB è critico (landing page, API), ridurre il buffer abbassa la latenza percepita:

ssl_buffer_size 4k;

Sul throughput per file di grandi dimensioni (video, download) questo valore è subottimale; per contenuto testuale e API è quasi sempre vantaggioso.

Configurazione completa raccomandata

Di seguito la configurazione consolidata che integra tutti i punti trattati, da inserire nel blocco http o nel blocco server di Nginx:

http2 on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_buffer_size 4k;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Dopo ogni modifica, verificare la sintassi e ricaricare:

nginx -t
nginx -s reload

HSTS: forzare HTTPS a livello di browser

HTTP Strict Transport Security istruisce i browser a non tentare mai connessioni HTTP plain verso il dominio, riducendo anche la superficie d’attacco da downgrade. L’intestazione si aggiunge così:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Il valore max-age è in secondi: 63072000 corrisponde a due anni, il minimo richiesto per l’inserimento nel preload list di Chrome. Prima di abilitare includeSubDomains, verificare che tutti i sottodomini siano effettivamente raggiungibili in HTTPS.

Conclusione

Il tuning TLS su Nginx non è un’operazione una tantum ma una configurazione che vale la pena standardizzare nei propri template di deployment. HTTP/2 abilitato, session cache attiva, OCSP Stapling e buffer ridotto sono quattro interventi a costo zero che si traducono in un’esperienza più reattiva per l’utente finale e in una postura di sicurezza più moderna. Per ambienti con requisiti di latenza estrema o traffico prevalentemente mobile, HTTP/3 con QUIC rappresenta il passo successivo logico, anche se richiede una build di Nginx con supporto esplicito.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency – linuxblog.io

Nginx tuning tips: HTTPS/TLS - Turbocharge TTFB/Latency | LinuxBlog.io

Nginx tuning tips to help improve the performance of Nginx w/ HTTPS for better TTFB and reduced latency. Includes HTTP/2, session cache, HSTS, OCSP stapling

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-06-11 12:33:37

Union Types in C# 15: insiemi chiusi di tipi con pattern matching esaustivo

Le union types sono finalmente arrivate in C#. Disponibili in anteprima a partire da .NET 11 Preview 2, C# 15 introduce la parola chiave union che consente di dichiarare un tipo che può contenere esattamente uno tra un insieme fisso di tipi, con conversioni implicite e pattern matching esaustivo garantito dal compilatore.

È una delle funzionalità più richieste dalla community da anni, e capire come funziona — e soprattutto perché è stata progettata in questo modo — fa la differenza tra usarla correttamente o incappare negli stessi antipattern che esistevano prima.

Il problema che le union types risolvono

Prima di C# 15, quando un metodo doveva restituire uno tra diversi tipi possibili, le opzioni disponibili erano tutte imperfette:

• object: nessun vincolo sui tipi effettivamente memorizzati; il chiamante doveva gestire logica difensiva per valori inattesi.
• Interfacce marcatore o classi base astratte: più sicure, ma non “chiuse” — chiunque poteva implementare l’interfaccia o derivare dalla classe base, quindi il compilatore non poteva mai considerare l’insieme completo dei tipi possibili.
• Librerie di terze parti come OneOf: funzionali, ma senza supporto diretto del compilatore per l’esaustività.

Un caso tipico è il risultato di un’operazione che può restituire un valore di successo oppure un errore: si potrebbe usare object, un’eccezione, oppure un tipo result wrapper. Nessuna di queste opzioni è soddisfacente perché manca la garanzia statale che tutti i casi siano gestiti.

Le union types risolvono questi problemi dichiarando un insieme chiuso di “case types”: non devono essere correlati tra loro, nessun altro tipo può essere aggiunto, e il compilatore garantisce che le espressioni switch che gestiscono la union siano esaustive — senza aver bisogno di un ramo _ o default.

Sintassi di base

La dichiarazione è minimalista:

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Una sola riga dichiara Pet come un nuovo tipo le cui variabili possono contenere un Cat, un Dog o un Bird. Il compilatore fornisce conversioni implicite da ciascun case type:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Pet pet2 = new Cat("Whiskers");
Console.WriteLine(pet2.Value); // Cat { Name = Whiskers }

Il compilatore emette un errore se si cerca di assegnare un tipo che non fa parte dei case types. Questa è la garanzia fondamentale: l’insieme è veramente chiuso a livello di compilazione.

Pattern matching esaustivo

Quando si usa un’istanza di un tipo union non nulla, il compilatore conosce l’insieme completo dei case types, quindi un’espressione switch che li copre tutti è esaustiva — senza bisogno del _ finale:

string name = pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
};

Questo è il vantaggio principale: se in futuro si aggiunge un quarto case type a Pet, ogni espressione switch che non lo gestisce produce un avviso del compilatore. I casi mancanti vengono rilevati in fase di compilazione, non a runtime.

I pattern si applicano alla proprietà Value della union, non alla union struct stessa. Questo “unwrapping” è automatico — si scrive Dog d e il compilatore verifica Value internamente. Le eccezioni sono var e _, che si applicano al valore della union stessa.

Per gestire il valore di default (null):

Pet pet = default;

var description = pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
    null => "nessun animale",
};
// description è "nessun animale"

Union con corpo e metodi helper

È possibile aggiungere membri helper alla union tramite un corpo, proprio come per qualsiasi altra dichiarazione di tipo. Un esempio pratico è OneOrMore<T>, utile per API che accettano sia un singolo elemento che una collezione:

public union OneOrMore<T>(T, IEnumerable<T>)
{
    public IEnumerable<T> AsEnumerable() => Value switch
    {
        T single => [single],
        IEnumerable<T> multiple => multiple,
        null => []
    };
}

I chiamanti passano la forma che preferiscono, e AsEnumerable() normalizza il risultato:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
    Console.Write($"[{tag}] ");
// [dotnet]

foreach (var tag in moreTags.AsEnumerable())
    Console.Write($"[{tag}] ");
// [csharp] [unions] [preview]

Si noti che AsEnumerable gestisce esplicitamente il caso null: lo stato null predefinito della proprietà Value è maybe-null, quindi il compilatore richiede la gestione di questo caso per garantire la correttezza.

Compatibilità con librerie esistenti e scenari avanzati

Per le librerie che già forniscono tipi union-like con proprie strategie di storage (come quelle basate su OneOf), C# 15 prevede un meccanismo di compatibilità: qualsiasi classe o struct con l’attributo [System.Runtime.CompilerServices.Union] viene riconosciuta come tipo union dal compilatore, purché segua il pattern base — costruttori pubblici a parametro singolo e proprietà Value pubblica.

Per scenari ad alte prestazioni dove i case types includono tipi valore, le librerie possono implementare il pattern di accesso non-boxing aggiungendo una proprietà HasValue e metodi TryGetValue. Il tipo union generato dal compilatore usa object? internamente e quindi fa boxing dei tipi valore — per hot path critici conviene valutare i custom union types.

Come provare le union types oggi

Le union types sono disponibili a partire da .NET 11 Preview 2. I passaggi per iniziare sono:

1. Installare il .NET 11 Preview SDK
2. Creare o aggiornare un progetto che punta a net11.0
3. Impostare <LangVersion>preview</LangVersion> nel file di progetto

Poiché UnionAttribute e IUnion non sono ancora inclusi nel runtime nel Preview 2, vanno dichiarati manualmente nel progetto:

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
        AllowMultiple = false)]
    public sealed class UnionAttribute : Attribute;

    public interface IUnion
    {
        object? Value { get; }
    }
}

Una volta aggiunti questi tipi, si possono dichiarare e usare normalmente le union types. Il supporto IDE in Visual Studio sarà disponibile nella prossima build Insiders; il C# DevKit Insiders lo include già.

Il quadro più ampio: la roadmap dell’esaustività

Le union types fanno parte di una strategia più ampia del team C# per portare la verifica dell’esaustività direttamente nel compilatore. Le proposte correlate attualmente in discussione sono:

• Closed hierarchies: il modificatore closed su una classe impedisce la dichiarazione di classi derivate al di fuori dell’assembly di definizione, consentendo al compilatore di considerare esaustive le espressioni switch sulla gerarchia.
• Closed enums: un closed enum impedisce la creazione di valori diversi dai membri dichiarati, risolvendo il problema dei valori enum “numerici” inattesi.

Insieme, questi tre meccanismi danno a C# un percorso completo verso la verifica statica dell’esaustività: union types per insiemi chiusi di tipi, closed hierarchies per gerarchie sigillate, closed enums per insiemi fissi di valori.

Conclusione

Le union types in C# 15 non sono un semplice porting delle discriminated union di F#: sono state progettate come aggiunta nativa all’ecosistema C#, composte da tipi esistenti, integrate con il sistema di pattern matching già consolidato, e compatibili con le librerie union-like già diffuse. La garanzia di esaustività del compilatore è il beneficio più concreto: i casi mancanti diventano avvisi a tempo di compilazione, non bug a runtime.

La feature è in preview e il team accetta feedback attivamente su GitHub. Vale la pena esplorarla ora per contribuire alla forma definitiva della feature, prevista per la release di novembre 2026 con .NET 11.

Fonte: Explore union types in C# 15 – .NET Blog

Explore union types in C# 15 - .NET Blog

C# 15 introduces union types — declare a closed set of case types with implicit conversions and exhaustive pattern matching. Try unions in preview today and see the broader exhaustiveness roadmap.

^{Bill Wagner (.NET Blog)}

(in)sicurezza digitale

2026-06-11 12:32:31

OP-512: il nuovo cluster cinese di cyberspionaggio che sfida il rilevamento con web shell crittograficamente uniche

Si parla di:
Toggle

Un server IIS abbandonato con .NET Framework obsoleto da un decennio, settantacinque giorni di paziente ricognizione e poi un’offensiva fulminea: questo è il modus operandi di OP-512, un nuovo cluster di cyberspionaggio di presunta origine cinese scoperto da ReliaQuest grazie alla propria piattaforma di AI agentiva. La scoperta aggiunge un quarto attore al già affollato panorama degli APT cinesi che prendono di mira i server IIS aziendali, ma con un livello di sofisticazione che supera significativamente i gruppi precedentemente documentati.

La scoperta: quando l’AI vede ciò che l’analista non riesce a collegare

Il 5 giugno 2026, ReliaQuest ha pubblicato un’analisi dettagliata di un’intrusione rilevata nell’ambiente di un cliente. L’elemento distintivo non è stato solo l’attacco in sé, ma il modo in cui è stato scoperto: la piattaforma GreyMatter Agentic AI ha correlato automaticamente decine di eventi apparentemente scollegati — creazione di web shell, query DNS anomale, caricamento riflessivo di assembly .NET, esecuzione di comandi da processi del web server — ricostruendo in pochi minuti l’intera catena d’attacco che un analista umano avrebbe impiegato ore o giorni a ricostituire manualmente.

Il cluster, denominato “OP-512”, è stato attribuito con moderata-alta confidenza alla Cina, sulla base di indicatori tattici, tecnici e procedurali (TTP) che si sovrappongono parzialmente ad altri gruppi noti come CL-STA-0048, GhostRedirector e DragonRank. Tuttavia, OP-512 presenta caratteristiche uniche che ne fanno un’entità distinta: un framework di web shell costruito su misura, con crittografia per-deployment, che rende inefficace qualsiasi rilevamento basato su firme.

Il bersaglio: infrastruttura legacy come porta d’ingresso

Il server compromesso eseguiva Windows Server 2016 con .NET Framework 4.0, una versione priva di aggiornamenti di sicurezza dal 2016. I server IIS in zona demilitarizzata (DMZ) rappresentano un bersaglio prediletto per gli operatori di cyberspionaggio: si trovano al confine tra la rete esposta a Internet e la rete interna, ricevono meno monitoraggio rispetto all’infrastruttura core e fungono da pivot point ideale per muoversi lateralmente.

La telemetria EDR mostrava attività sospetta sullo stesso host già 75 giorni prima dell’attacco principale, con query DNS verso il dominio ashx.lhlsjcb[.]com. Questa prima fase — probabilmente ricognizione e test delle capacità di accesso — è tipica degli cluster di spionaggio state-sponsored, che non hanno fretta e possono permettersi di aspettare il momento più opportuno.

La fase offensiva: pochi minuti per stabilire il controllo

Quando OP-512 ha deciso di agire, ha operato con velocità e metodo. In un arco temporale di pochi minuti, il processo worker di IIS (w3wp.exe) ha scritto nella directory di upload dell’applicazione tre web shell, ciascuna con una funzione specifica:

• File manager .aspx con canale C2 self-reporting: alla prima visita, la shell codifica il proprio URL in esadecimale e lo trasmette come query DNS verso il dominio controllato dagli attaccanti (hcgos[.]com, con pattern a.<hex>.c.hcgos[.]com). Se la query DNS fallisce, attiva un canale di fallback HTTP verso un server C2 separato. Il server di fallback è stato collegato da ricercatori indipendenti a infrastrutture Meterpreter.
• Due command handler .ashx con autenticazione crittografica: ciascuno gated da autenticazione RSA+RC4 con chiavi diverse tra i due handler. Il processo di esecuzione segue quattro fasi sequenziali: decodifica Base64 del corpo della richiesta HTTP, decifratura RC4 del payload, verifica della firma RSA contro la chiave pubblica embedded, esecuzione del comando solo se la verifica ha successo.

L’elemento più sofisticato è la generazione crittograficamente unica per ogni deployment: un builder automatizzato produce istanze dal medesimo template, randomizzando i nomi di variabili e metodi e iniettando variabili morte e commenti spazzatura. Il risultato sono file che eseguono la stessa operazione ma producono hash completamente diversi, rendendo inutile il rilevamento basato su firme.

Privilege Escalation: la suite “Potato” caricata direttamente in memoria

Con le web shell operative, OP-512 ha caricato direttamente nella memoria del processo w3wp.exe quattro toolkit di post-exploitation, senza scrivere nulla su disco:

• BadPotato, SweetPotato, EfsPotato: la “Potato Suite”, una raccolta documentata di exploit Windows che abusano di servizi integrati per elevare i privilegi da un account di servizio limitato a SYSTEM. La presenza di questi strumenti in OP-512 aggiunge un dato di attribuzione, poiché compaiono anche in CL-STA-0048 e GhostRedirector.
• GhostKit: un toolkit non documentato pubblicamente, probabilmente un’etichetta vendor-specifica della telemetria EDR piuttosto che un tool consolidato.

I comandi di verifica post-escalation (whoami e whoami /priv) sono stati eseguiti come stringhe base64-encoded — una codifica identica carattere per carattere a quella documentata nel compromesso ArcGIS di Flax Typhoon, suggerendo tooling o playbook condivisi nell’ecosistema degli APT cinesi.

Il problema del loop: quando la prevenzione non basta

Un aspetto particolarmente istruttivo dell’incidente è ciò che è accaduto dopo l’intervento dell’endpoint protection: il sistema ha terminato il processo malevolo, ma IIS riavvia automaticamente i worker process dopo un crash o una terminazione forzata. Il risultato è stato un loop in cui la protezione si attivava ripetutamente mentre l’attività malevola continuava. Bloccare un processo senza isolare l’host crea esattamente questa finestra di vulnerabilità che gli attaccanti sfruttano intenzionalmente.

Un ulteriore problema per i responder è la persistenza delle DLL compilate da ASP.NET: quando le web shell vengono eseguite per la prima volta, il runtime .NET le compila in librerie DLL e le salva in una directory temporanea. Queste DLL sopravvivono alla cancellazione dei file originali e possono essere riattivate. La risposta all’incidente deve quindi includere la pulizia delle directory di compilazione temporanea di ASP.NET.

Timestomping: nascondersi nel passato

OP-512 implementa una tecnica di timestomping automatizzato particolarmente raffinata: le web shell analizzano ogni file e sottodirectory circostante, calcolano il timestamp mediano di ultima modifica e sovrascrivono i propri timestamp di creazione e modifica per allinearsi. Una web shell scritta nel 2026 tra file del 2022 sembrerebbe vecchia di anni. La funzione accetta anche un timestamp esplicito come input, permettendo all’operatore di retrodatare un file a uno specifico evento o finestra di patch.

OP-512 nel panorama degli APT cinesi su IIS

ReliaQuest posiziona OP-512 come quarto cluster cinese documentato nell’ultimo anno a colpire server IIS, ma con caratteristiche che lo distinguono dagli altri tre:

• CL-STA-0048 (l’overlap più significativo): usa query DNS con subdomain esadecimali per esfiltrare dati — OP-512 usa lo stesso encoding ma per segnalare la propria posizione, non per esfiltrare. Dipende da tool commodity come PlugX e Cobalt Strike, diversamente dal framework custom di OP-512.
• GhostRedirector e DragonRank: motivati da frodi SEO, non da spionaggio. Usano alcune delle stesse tecniche di privilege escalation ma con obiettivi completamente diversi.

IOC e Indicatori comportamentali

ReliaQuest enfatizza che gli IOC specifici di questa intrusione non saranno necessariamente presenti nelle future operazioni OP-512, data la natura generata proceduralmente del framework. I rilevamenti comportamentali sono la strada maestra:

# IOC specifici dell'intrusione
Dominio C2 primario:     ashx.lhlsjcb[.]com (attività precedente, ~75 giorni prima)
Dominio C2 secondario:   hcgos[.]com
Pattern DNS:             a.<hex>.c.hcgos[.]com
Server Meterpreter C2:   43.160.202[.]246:8053
Connessione outbound:    140.206.161[.]227:443
Source IP interazione:   124.156.129[.]151 (User-Agent: python-requests/2.33.0)

# Pattern comportamentali da monitorare
- w3wp.exe che genera query DNS con subdomain esadecimali lunghi
- Caricamento riflessivo di componenti crittografici in w3wp.exe
- Creazione di DLL in directory temporanee ASP.NET fuori dai cicli di deployment
- Risposte HTTP cifrate da endpoint .ashx che dovrebbero restituire contenuto standard

Due righe per i difensori

Per i team di sicurezza che gestiscono ambienti con server IIS legacy, le priorità immediate sono: ritirare o isolare i server con .NET Framework end-of-life esposti a Internet; disabilitare l’esecuzione di script nelle directory di upload via handler IIS per estensioni .aspx, .ashx, .asp e .asmx; monitorare le directory di compilazione temporanea ASP.NET per creazione di DLL fuori dai cicli di deployment normali; e — fondamentalmente — non chiudere un incidente senza aver identificato e rimediato la vulnerabilità di accesso iniziale. OP-512 dimostra che gli operatori di spionaggio contano esattamente su questa superficialità per tornare dopo che l’allerta è rientrata.

(in)sicurezza digitale

2026-06-11 12:30:18

Supply chain attack su npm: 11 pacchetti malevoli con C2 blockchain colpiscono 2,7 milioni di download crypto

Si parla di:
Toggle

Undici pacchetti npm malevoli, un singolo package con oltre 2,7 milioni di download, un’infrastruttura di comando e controllo ancorata alla blockchain Ethereum: questa è la mappa di una campagna di supply chain attack che i ricercatori di Cyfirma hanno identificato e documentato nel dettaglio, prendendo di mira sviluppatori blockchain, progetti Web3 e operatori di wallet crypto.

La trappola nel registro npm

Il registro npm — il più grande ecosistema di pacchetti JavaScript con oltre due milioni di moduli disponibili — si conferma ancora una volta un bersaglio privilegiato per gli attori malevoli. Questa campagna ha sfruttato una combinazione di tecniche consolidate e innovazioni notevoli, a partire dal typosquatting: i pacchetti malevoli mimicavano fedelmente nomi di librerie legittime e ampiamente utilizzate nell’ecosistema blockchain, come ethers.js, le SDK di Moralis, le utility Coinbase e i tool di sviluppo Stellar.

Il pacchetto più distribuito, moralis-sdk, ha raggiunto la cifra di 2,7 milioni di download prima della rimozione — un numero che rende l’entità potenziale della compromissione difficile da quantificare con precisione. Gli altri dieci pacchetti identificati includono ethers-jss, coinbase-wallet-utils, Ganach (typosquatting di Ganache), Solidty (typosquatting di Solidity), Stelar-sdk, oltre a hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat ed ethereum-dev-utils.

Meccanismo di esecuzione: lifecycle hooks come vettore d’attacco

Il vettore di infezione primario si basa sull’abuso degli script di ciclo di vita npm (postinstall e preinstall). Quando uno sviluppatore esegue npm install, il codice malevolo viene attivato automaticamente, senza alcuna interazione ulteriore. Questo approccio è particolarmente insidioso perché sfrutta funzionalità native del gestore di pacchetti, difficili da bloccare senza compromettere la funzionalità legittima.

Il pacchetto moralis-sdk fungeva da downloader multi-stadio: recuperava payload aggiuntivi da servizi di hosting remoto come Pastefy e GitHub, realizzando un’architettura di distribuzione del malware altamente resiliente. I pacchetti coinbase-wallet-utils e ethers-jss erano invece dedicati principalmente alle fasi di ricognizione ed esfiltrazione, con focus specifico sul furto di wallet crypto.

Blockchain come infrastruttura C2: l’innovazione più significativa

L’elemento tecnico più rilevante della campagna è l’utilizzo della blockchain Ethereum come meccanismo di command and control. Gli attori malevoli hanno impiegato smart contract Ethereum e transazioni on-chain sia per il recupero della configurazione dell’infrastruttura sia per l’esfiltrazione di credenziali. Questo approccio rende il C2 estremamente difficile da bloccare: non esistono domini da eliminare, non esistono IP da inserire in blacklist, e le transazioni on-chain sono immutabili e pseudoanonime.

Gli indirizzi Ethereum identificati nella campagna come target per la configurazione e l’esfiltrazione includono 0xa1b40044EBc2794f207D45143Bd82a1B86156c6b, 0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84 e 0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f.

Tipologia di dati rubati

L’obiettivo principale era la raccolta di segreti ad alto valore economico e operativo dagli ambienti di sviluppo compromessi. Il malware prendeva di mira: chiavi private di wallet crypto e frasi mnemoniche (seed phrase), chiavi SSH, credenziali cloud (AWS, Azure, GCP), token di autenticazione API (NPM_TOKEN, GITHUB_TOKEN), chiavi di servizi blockchain come Infura e Alchemy, oltre a file di configurazione di ambienti di sviluppo specifici come secrets.json, hardhat.config.js e foundry.toml.

Mappatura MITRE ATT&CK

La campagna copre un ampio spettro di tecniche MITRE, tra cui T1195.002 (Supply Chain Compromise), T1204.002 (Malicious File Execution), T1036.005 (Masquerading), T1552 (Unsecured Credentials), T1528 (Steal Application Access Token) e T1583.006 (Acquire Infrastructure via Web Services).

Indicatori di Compromissione (IoC)

# Pacchetti npm malevoli
moralis-sdk, ethers-jss, coinbase-wallet-utils
Ganach, Solidty, Stelar-sdk
hardhat-deploy-utils, web3-deploy-helper, defi-sdk-core, ethers-compat, ethereum-dev-utils

# Hash SHA256
d94a2444268b339dfda2615f7800322fb318e0a484414bb17016cfcd5eb07c44
6585ca0d3e26c20ced638f46f4a89eea924d411b8753d3fcf434663593c7cf0b
17bad5ae5b2ac262f5f18854853869840245c344105aa38c7f550ef51d2e5f26

# Hash SHA1
53b91117db931d3acbbfd15aa8400bb6691e023d
63154cd9c79f9d14eb9be6c4efc2a778d31646ec
74d3d5ab6d0fa4c6a5860598231728a6a893ecf7

# URL infrastruttura
pastefy.app/RhPBKGli/raw
http://193.233.201.21:3001

# Indirizzi Ethereum (C2 on-chain)
0xa1b40044EBc2794f207D45143Bd82a1B86156c6b
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0xCBbecC5E5Eb88582e6305cF6ab688f03e02Ce16f

Due righe per i difensori

Questa campagna evidenzia come i supply chain attack sul registro npm stiano diventando sempre più sofisticati. I difensori e i team di sicurezza DevOps dovrebbero implementare: verifica sistematica dell’integrità dei pacchetti prima dell’installazione; utilizzo di strumenti come npm audit e analizzatori comportamentali di pacchetti (Socket.dev, Snyk, Phylum); monitoraggio delle connessioni di rete generate durante npm install in ambienti di build CI/CD isolati; blocco preventivo dei lifecycle hook di terze parti nelle pipeline di produzione; audit periodico delle dipendenze con specifico focus su pacchetti con nomi simili a librerie popolari. L’uso della blockchain come infrastruttura C2 rappresenta una frontiera che richiede approcci di difesa diversi dal tradizionale blocco DNS/IP: è necessario monitorare le chiamate RPC verso nodi Ethereum non autorizzati nelle reti aziendali.

La ricerca completa di Cyfirma è disponibile su: cyfirma.com

New NPM Supply Chain Campaign Identified : A Multi-Stage Cryptocurrency Malware with More Than 2.7 million Downloads - CYFIRMA

New NPM Supply Chain Campaign Identified : A Multi-Stage Cryptocurrency Malware with More Than 2.7 million Downloads. EXECUTIVE SUMMARY Cyfirma...

^CYFIRMA

(in)sicurezza digitale

2026-06-11 12:29:33

Il worm Miasma disabilita 73 repository Microsoft su GitHub in 105 secondi: supply chain attack prende di mira gli AI coding agent

Si parla di:
Toggle

Il 5 giugno 2026, il worm Miasma — variante della famiglia Shai-Hulud attribuita al gruppo TeamPCP — ha raggiunto le organizzazioni GitHub di Microsoft. In 105 secondi, il sistema automatico di enforcement di GitHub ha disabilitato 73 repository tra Azure, Azure-Samples, microsoft e MicrosoftDocs. L’attacco introduce un cambio di paradigma nei supply chain attack: il trigger non è più l’installazione di un pacchetto, ma l’apertura di una cartella nel proprio editor o AI coding agent.

La catena di infezione: dal PyPI al repository injection

Per comprendere l’incidente del 5 giugno è necessario risalire al 19 maggio 2026, quando la stessa campagna Miasma aveva compromesso il pacchetto PyPI durabletask di Microsoft. In quell’occasione, un attaccante aveva caricato tre versioni malevole del pacchetto in una finestra di 35 minuti, usando un token di publishing compromesso, bypassando completamente la pipeline CI/CD. Il payload — un file rope.pyz da 28KB — rubava credenziali da AWS, Azure, GCP, Kubernetes e oltre 90 configurazioni di developer tool.

Il 5 giugno, lo stesso account contributor compromesso è stato usato per iniettare un commit direttamente nel repository GitHub Azure/durabletask. Il commit (5f456b8) riportava il messaggio “Switched DataConverter to OrchestrationContext [skip ci]” — ma non modificava alcun file sorgente. Aggiungeva invece 5 file di configurazione, con un timestamp retrodatato al 2020 per eludere il rilevamento, e il flag [skip ci] per sopprimere l’esecuzione della pipeline.

Quattro vettori, un payload: come Miasma abusa degli AI coding agent

L’attacco è notevole per la sua copertura trasversale degli strumenti di sviluppo più diffusi. I cinque file iniettati puntano tutti allo stesso payload (.github/setup.js, un file JavaScript da 4,6 MB altamente offuscato), attivandolo con meccanismi diversi:

• .claude/settings.json: hook SessionStart per Claude Code — esegue il payload all’avvio di qualsiasi sessione Claude nel repository.
• .gemini/settings.json: hook identico per Gemini CLI.
• .cursor/rules/setup.mdc: prompt injection per Cursor AI — istruisce l’agente a eseguire il payload spacciandolo per “inizializzazione obbligatoria del progetto”. Il flag alwaysApply: true garantisce l’attivazione indipendentemente dal file su cui si sta lavorando.
• .vscode/tasks.json: task con runOptions.runOn: "folderOpen" — eseguito automaticamente da VS Code all’apertura della cartella, senza alcun coinvolgimento di AI agent.

Il punto critico: clonare il repository è sicuro, aprirlo nell’editor non lo è. Questo inverte l’assunzione di sicurezza su cui si basano la maggior parte dei workflow di sviluppo.

73 repository in 105 secondi: l’automazione di GitHub come ultima linea di difesa

Ore dopo il commit malevolo, il sistema automatico di abuse detection di GitHub ha disabilitato 73 repository in due ondate distinte, separate da un gap di 56 secondi:

• Wave 1 (16:00:50 → 16:01:28 UTC): 39 repository in 38 secondi
• Wave 2 (16:02:24 → 16:02:35 UTC): 34 repository in 11 secondi

Tutti i repository restituiscono HTTP 403 con "reason": "tos". Tra quelli colpiti figurano repository critici come azure-functions-host, azure-functions-core-tools, l’intera famiglia dei worker (.NET, Node.js, Python, Java, PowerShell, Go) e — con conseguenze immediate — Azure/functions-action, la GitHub Action ufficiale per il deployment di Azure Functions.

La disabilitazione di functions-action ha rotto immediatamente ogni pipeline CI/CD che referenziava Azure/functions-action@v1. Un thread su Microsoft Learn ha raccolto oltre 20 segnalazioni di pipeline bloccate in poche ore. Microsoft ha inizialmente classificato l’evento come “violazione delle policy GitHub”, salvo poi ricaratterizzarlo come “internal management issue under investigation”.

Attributione: TeamPCP e il nexus Shai-Hulud/Miasma

L’incidente si inserisce nella campagna più ampia del gruppo TeamPCP, attivo da almeno la primavera 2026. Il payload del 19 maggio conteneva un C2 secondario (t.m-kosche[.]com) già noto come infrastruttura TeamPCP. Il gruppo ha una storia di attacchi supply chain di ampia portata: TanStack (42 pacchetti npm, CVE-2026-45321, CVSS 9.6), Mistral AI, l’ecosistema @[url=https://stream.antv.abyaya.la/video-channels/antv]antv[/url] (639 versioni su 323 pacchetti npm), @redhat-cloud-services (32 pacchetti), LiteLLM, Telnyx e Checkmarx.

Miasma è valutata come una variante evoluta del worm Mini Shai-Hulud: Wave 1 (giugno 1) usava hook preinstall npm; Wave 2 (giugno 3) ha introdotto la tecnica Phantom Gyp — file binding.gyp malevoli che eludono le difese supply chain tradizionali; Wave 3 (giugno 5) ha abbandonato il package manager del tutto, puntando direttamente al repository e all’editor.

Indicatori di compromissione

# Domini C2
check.git-service[.]com      # C2 primario payload maggio
t.m-kosche[.]com             # Infrastruttura TeamPCP (C2 secondario)

# Hash commit malevolo
5f456b8  (Azure/durabletask, 2026-06-05)

# File sospetti da cercare nei repository
.claude/settings.json        # Hook SessionStart
.gemini/settings.json        # Hook SessionStart
.cursor/rules/setup.mdc      # Prompt injection alwaysApply
.vscode/tasks.json           # runOn: folderOpen
.github/setup.js             # Payload principale (4.6 MB offuscato)

Due righe per i difensori

Chi ha clonato repository Azure/microsoft dopo il 2 giugno 2026 e li ha aperti in un editor deve considerare il sistema compromesso e ruotare immediatamente tutte le credenziali accessibili: GitHub token, npm token, AWS keys, Azure service principal, GCP service account, SSH key, Kubernetes secrets, Docker config, variabili d’ambiente e shell history.

Per prevenire incidenti analoghi: ispezionare i repository clonati per i file sopra elencati prima di aprirli; pinnare le GitHub Actions a commit SHA specifici invece di tag mutabili; abilitare branch protection con revisione obbligatoria dei PR; usare PyPI Trusted Publishing (OIDC) al posto di token long-lived; monitorare le connessioni outbound dai runner CI/CD verso domini sconosciuti.

L’attacco Miasma su Microsoft rappresenta un salto qualitativo nella minaccia supply chain: non bastano più le difese sul package manager se gli attaccanti possono iniettare hook direttamente nell’editor dello sviluppatore. La superficie d’attacco si è spostata dall’installazione all’apertura — e le difese devono adeguarsi di conseguenza.