(in)sicurezza digitale

2026-06-16 07:43:34

Operation Highland: Velvet Ant spia una rete air-gapped per 10 anni backdoorando PAM e OpenSSH

Si parla di:
Toggle

Per quasi un decennio, un gruppo di spionaggio informatico legato alla Cina ha operato indisturbato all’interno di una rete isolata di infrastrutture critiche, compromettendo il cuore stesso del meccanismo di autenticazione Linux. La scoperta, firmata dai ricercatori di Sygnia, racconta di una pazienza operativa rara e di una sofisticazione tecnica che ridefinisce il concetto di persistenza avanzata.

Velvet Ant: chi è e cosa ha fatto in precedenza

Velvet Ant è un cluster di attività di cyberspionaggio attribuito a un attore nation-state cinese, già documentato da Sygnia nel 2024 in una campagna che aveva preso di mira dispositivi F5 BIG-IP rimasti compromessi per tre anni senza essere rilevati. Nello stesso anno, Cisco aveva segnalato lo sfruttamento di uno zero-day nei propri switch NX-OS da parte dello stesso gruppo. La nuova ricerca, denominata Operation Highland, supera però per portata e durata tutto ciò che era stato osservato in precedenza: dieci anni di accesso continuativo a una rete air-gapped di infrastrutture critiche appartenente a una grande organizzazione.

La catena di attacco: dall’esterno alla rete isolata

L’intrusione ha avuto inizio nel 2016 con la compromissione di server esposti su internet. Su questi sistemi, Velvet Ant ha distribuito una versione modificata di GS-Netcat, uno strumento legittimo per creare tunnel cifrati, trasformato in una reverse shell persistente. Il file veniva mascherato come utility di sistema auditdb e collocato in /usr/sbin/, stabilendo la persistenza tramite un servizio systemd malevolo oppure modificando gli script di avvio SysVinit a seconda del sistema.

Per muoversi lateralmente senza generare traffico diretto verso internet, gli attaccanti hanno installato un proxy SOCKS5 scritto in Perl che mascherava il proprio processo come smbd -D, usando filename, porte e nomi di processo diversi su ogni host per ostacolare il rilevamento.

La parte più sofisticata riguarda però la costruzione del percorso di accesso verso la rete isolata. Velvet Ant ha modificato la configurazione di un server Nginx internet-facing per proxare richieste HTTP specificamente costruite verso un server backend compromesso. Questo backend aveva a sua volta Nginx configurato per inoltrare le richieste a un processo FastCGI (fcgiwrap) in ascolto su una porta separata. Il FastCGI wrapper agiva come bridge di esecuzione, lanciando un binario personalizzato chiamato uptime che stabiliva connessioni SSH verso sistemi nella rete isolata, usando parametri forniti tramite HTTP POST.

“Concatenando queste modifiche, Velvet Ant ha stabilito un percorso di esecuzione remota nell’ambiente segregato tramite semplici richieste HTTP, senza mai richiedere una connessione diretta alla rete di infrastrutture critiche.” — Sygnia

Il colpo di genio: backdoor nell’autenticazione Linux

Una volta ottenuto l’accesso alla rete isolata, Velvet Ant ha spostato il focus verso la persistenza a lungo termine e la raccolta di credenziali, attaccando direttamente il sistema di autenticazione Linux: i Pluggable Authentication Modules (PAM).

I ricercatori di Sygnia hanno identificato nove varianti distinte del modulo malevolo pam_unix.so, ciascuna compilata in un ambiente di build separato — un indicatore di un attore con risorse abbondanti e operativamente disciplinato. Alcune varianti funzionavano come backdoor pura, accettando una password hardcoded che consentiva l’accesso bypassando l’autenticazione normale. Altre raccoglievano e memorizzavano localmente le credenziali di tutti gli utenti in un file nascosto.

In parallelo, gli attaccanti hanno sostituito i componenti di OpenSSH — inclusi ssh, sshd e scp — con versioni trojanizzate capaci di:

• Catturare e registrare le password utilizzate nelle sessioni SSH
• Loggare tutti i comandi eseguiti dagli amministratori
• Nascondere le tracce dell’attività degli attaccanti
• Disabilitare SELinux quando avviati con privilegi root
• Permettere agli stessi attaccanti di disattivare il logging delle proprie sessioni tramite un flag speciale

Velvet Ant ha inoltre aggiunto le proprie chiavi pubbliche SSH negli authorized_keys dei server compromessi, garantendosi un accesso persistente senza password indipendente dai moduli PAM manipolati.

Dieci anni invisibili: perché il rilevamento era così difficile

La scelta di compromettere i componenti di autenticazione stessi, piuttosto che distribuire malware convenzionale, ha rappresentato il fattore chiave nella longevità dell’operazione. I tool di sicurezza cercano processi anomali e comunicazioni di rete sospette: un’autenticazione PAM modificata che accetta una password hardcoded sembra semplicemente un login legittimo. I log di sistema mostravano accessi normali. Non c’erano payload da rilevare, non c’erano connessioni C2 evidenti dall’interno della rete isolata.

L’uso di nomi di file, porte e nomi di processo differenti su ogni host rendeva impossibile correlare l’attività attraverso la rete senza una visione completa e coordinata dell’intero ambiente.

Il cleanup: più pericoloso della compromissione

Sygnia descrive la fase di remediation come particolarmente complessa. Velvet Ant aveva sostituito tanti componenti critici con versioni personalizzate che la loro rimozione scorretta avrebbe potuto bloccare l’accesso degli amministratori legittimi, causando interruzioni operative in sistemi di infrastruttura critica.

Il team di risposta ha dovuto costruire un laboratorio di test per validare il processo di sostituzione dei binari, profilare ogni host per identificare le versioni corrette dei componenti, testare le procedure di ripristino e preparare rollback prima di tentare qualsiasi intervento in produzione. Ogni step veniva validato verificando che l’autenticazione SSH continuasse a funzionare correttamente.

Indicatori di compromissione e due righe difensive

Sygnia raccomanda di trattare componenti come PAM, OpenSSH e Windows LSASS come asset di sicurezza critici da proteggere con:

• File Integrity Monitoring (FIM) sui binari di autenticazione e sui moduli PAM
• EDR con regole specifiche per modifiche a /lib/security/pam_unix.so, /usr/sbin/sshd, /usr/bin/ssh
• MFA obbligatoria per l’accesso privilegiato, anche in reti air-gapped
• Backup immutabili verificati periodicamente con procedure di ripristino testate offline
• Monitoring delle chiavi SSH nei file authorized_keys su tutti i server

# File e percorsi da monitorare con FIM
/lib/security/pam_unix.so
/lib/x86_64-linux-gnu/security/pam_unix.so
/usr/sbin/sshd
/usr/bin/ssh
/usr/bin/scp
/etc/ssh/sshd_config
/root/.ssh/authorized_keys
/home/*/.ssh/authorized_keys

# Processi sospetti identificati nell'operazione
smbd -D   # proxy SOCKS5 mascherato
uptime    # binario custom per SSH verso rete isolata
auditdb   # GS-Netcat reverse shell

# Pattern di accesso sospetto
# Login PAM con password non corrispondente agli hash in /etc/shadow
# Sessioni SSH con flag speciali non documentati
# Traffico HTTP verso Nginx con parametri POST insoliti verso backend interni

Operation Highland dimostra che la sicurezza delle reti air-gapped non può essere data per scontata. Quando un attore sufficientemente motivato riesce a ottenere l’accesso iniziale, la mancanza di connettività internet non è un ostacolo insuperabile: è semplicemente un problema da risolvere con creatività tecnica. E come questa operazione mostra, quella creatività può restare nascosta per un decennio.

Spcnet.it

2026-06-16 07:45:06

Attacco supply chain all’AUR di Arch Linux: 1.500 pacchetti compromessi con rootkit eBPF

Cosa è successo: l’attacco all’AUR in sintesi

Il team di sicurezza di Arch Linux ha disabilitato le nuove registrazioni all’Arch User Repository (AUR) a seguito di una compromissione su larga scala. Tra il 13 e il 15 giugno 2026 gli attaccanti hanno dirottato o creato ex novo oltre 1.500 pacchetti gestiti dalla community per distribuire payload malevoli: information stealer e rootkit basati su eBPF. I repository ufficiali di Arch (core, extra, multilib) non sono stati colpiti grazie ai processi di review più stringenti dei maintainer ufficiali.

L’attacco si è sviluppato in due ondate distinte, entrambe basate su dipendenze JavaScript malevole inserite nei PKGBUILD:

• Prima ondata: uso di un pacchetto denominato atomic-lockfile per eseguire binari ostili al momento del build
• Seconda ondata (più sofisticata): introduzione di un binario separato tramite il pacchetto js-digest, con tecniche di evasion più avanzate

Gli script malevoli erano progettati per scaricare e installare silenziosamente il malware sui sistemi degli utenti che avevano compilato i pacchetti compromessi dal sorgente.

Perché l’AUR è strutturalmente vulnerabile agli attacchi supply chain

L’AUR è un repository non ufficiale e non supportato di build script (PKGBUILD) contribuiti dalla community. Chiunque può creare un account e pubblicare un pacchetto; non esiste una review obbligatoria da parte del team Arch prima della pubblicazione. Questo modello “aperto” ha permesso all’ecosistema AUR di crescere fino a oltre 80.000 pacchetti, ma lo rende intrinsecamente più esposto rispetto ai repository ufficiali.

I vettori tipici di compromissione dell’AUR sono:

• Account hijacking: un attaccante prende controllo di un account maintainer inattivo (o con credenziali deboli) e pubblica commit malevoli su pacchetti legittimi e popolari
• Pacchetti typosquatting: creazione di nuovi pacchetti con nomi simili a quelli legittimi, sfruttando errori di battitura o la confusione tra nomi simili
• Dependency confusion: sostituzione di dipendenze interne con versioni malevole omonime pubblicate su registri pubblici

In questo caso l’attacco ha sfruttato principalmente l’account hijacking, con l’aggravante della catena di dipendenze JavaScript — un vettore sempre più usato in attacchi supply chain anche su ecosistemi npm e PyPI.

I payload: information stealer e rootkit eBPF

La scelta dei payload è tecnicament rilevante e vale la pena approfondirla.

Information Stealer

Gli information stealer raccolti in questa campagna erano progettati per estrarre credenziali, cookie di sessione browser, chiavi SSH, wallet di criptovalute e dati di configurazione da macchine Linux. Il targeting di sistemi Arch Linux (tipicamente macchine di sviluppatori, sysadmin e power user) massimizza il valore dei dati sottratti.

Rootkit eBPF

La componente più preoccupante è il rootkit basato su eBPF (Extended Berkeley Packet Filter). eBPF è una tecnologia del kernel Linux che consente l’esecuzione di programmi sandboxati direttamente nel kernel, originariamente pensata per networking e observability (usata da strumenti come Cilium, Falco, bpftrace). Abusata per scopi malevoli, permette di:

• Intercettare chiamate di sistema senza modificare file sul disco
• Nascondere processi, file e connessioni di rete agli strumenti di monitoring tradizionali
• Esfiltrare dati a livello di kernel, bypassando molti EDR
• Mantenere la persistenza in modo difficile da rilevare, dato che i programmi eBPF non appaiono nei normali listing dei processi

Un rootkit eBPF richiede privilegi elevati per essere caricato, ma una volta in esecuzione è significativamente più difficile da rilevare rispetto a un rootkit tradizionale basato su moduli kernel (LKM). Strumenti come bpftool permettono di enumerare i programmi eBPF caricati, ma un rootkit sofisticato può nascondere anche se stesso da questa enumerazione.

Come verificare se il proprio sistema è compromesso

Se si utilizza Arch Linux con pacchetti AUR installati nel periodo della compromissione, seguire questa procedura:

1. Verificare la presenza dei binari malevoli identificati

# Cercare i file associati alle due ondate dell'attacco
find / -name "atomic-lockfile" -o -name "js-digest" 2>/dev/null

# Cercare processi insoliti
ps aux | grep -E "(\.tmp|/tmp/\.|hidden)"

2. Enumerare i programmi eBPF caricati

# Listare tutti i programmi eBPF attivi
sudo bpftool prog list

# Listare le mappe eBPF
sudo bpftool map list

# Ispezionare un programma specifico (sostituire ID con quello trovato)
sudo bpftool prog dump xlated id <ID>

Programmi eBPF con nomi generici o vuoti, o di tipo kprobe/tracepoint non associati a tool di sistema noti, meritano approfondimento.

3. Controllare i pacchetti AUR installati recentemente

# Pacchetti installati nelle ultime 72 ore
grep -E "^\[ALPM\] installed" /var/log/pacman.log | tail -50

# Verificare l'integrità dei file installati
pacman -Qkk 2>&1 | grep -v "0 altered"

4. Seguire le indicazioni ufficiali del team Arch

Il team di sicurezza Arch ha pubblicato checklist ufficiali per gli utenti colpiti, disponibili sul portale di sicurezza Arch Linux. Le azioni di cleanup includono la rimozione dei pacchetti compromessi, la revoca delle chiavi SSH potenzialmente esfiltrate e il cambio delle credenziali esposte.

Best practice per chi usa l’AUR

Questo attacco è un promemoria di regole che esistono da anni ma vengono spesso ignorate per comodità:

• Leggere sempre i PKGBUILD prima di installare. È la prima difesa. Un PKGBUILD malevolo è spesso riconoscibile da download di binari da URL non ufficiali, pipe a shell, o dipendenze insolite.
• Usare helper AUR con revisione esplicita. Tool come paru mostrano il diff del PKGBUILD prima di procedere. Non ignorare questo step.
• Preferire pacchetti con molti voti e maintainer attivi. Non è una garanzia assoluta, ma riduce il rischio.
• Usare ambienti isolati per il build. Tool come aurutils con makechrootpkg compilano i pacchetti in un chroot pulito, limitando l’impatto di un PKGBUILD malevolo.
• Monitorare le dipendenze JavaScript nei PKGBUILD. Pacchetti che scaricano moduli npm o yarn durante il build meritano attenzione extra, soprattutto se le dipendenze non sono verificate tramite hash.
• Abilitare audit di sistema. auditd con regole appropriate può rilevare comportamenti anomali durante e dopo l’installazione di pacchetti.

Implicazioni più ampie per la sicurezza della supply chain Linux

L’attacco all’AUR si inserisce in un trend preoccupante di compromissioni della supply chain su piattaforme open source. Nell’ultimo anno abbiamo visto attacchi analoghi su npm, PyPI, RubyGems e GitHub Actions. La peculiarità dell’ecosistema Linux è che molti degli utenti AUR sono sviluppatori e sysadmin con accesso privilegiato a infrastrutture aziendali: la compromissione di una workstation di uno sviluppatore può trasformarsi rapidamente in un punto di ingresso laterale verso sistemi di produzione.

La risposta del team Arch — blocco delle registrazioni, revert dei commit malevoli, ban degli account — è stata rapida ma reattiva. Il dibattito nella community si concentra ora su misure preventive: firma obbligatoria dei PKGBUILD, review automatizzata tramite analisi statica, e requisiti più stringenti per l’acquisizione di pacchetti esistenti. Nessuna di queste misure è banale da implementare mantenendo la natura aperta dell’AUR, ma l’attacco ha reso evidente il costo del modello attuale.

---

Fonti: 4sysops · The Hacker News · The Register

Arch Linux suspends AUR registrations following massive supply chain attack – 4sysops

The Arch Linux security team has disabled new account registrations for the Arch User Repository (AUR) following a large-scale supply chain compromise. Attacker

^{IT News (4sysops)}

Spcnet.it

2026-06-16 07:45:27

DNS over HTTPS su Windows Server 2025: configurazione completa e considerazioni enterprise

Cos’è DNS over HTTPS e perché cambia le regole del gioco

Il DNS tradizionale risolve i nomi di dominio inviando query in chiaro su UDP o TCP sulla porta 53. Chiunque si trovi sul percorso di rete — un ISP, un operatore Wi-Fi aziendale o un attaccante con accesso al segmento — può leggere o manipolare quelle query. DNS over HTTPS (DoH) risolve questo problema incapsulando le query DNS all’interno di connessioni HTTPS cifrate con TLS: lo stesso meccanismo di crittografia utilizzato dalla normale navigazione web.

Con l’aggiornamento cumulativo di giugno 2026 (KB5094125) per Windows Server 2025, Microsoft ha reso disponibile DoH in modalità General Availability per il ruolo DNS Server on-premises. Non è più necessario affidarsi a resolver di terze parti: la cifratura DNS parte ora direttamente dalla propria infrastruttura interna.

DoH vs DNS over TLS: quale scegliere in ambienti enterprise

Esiste un protocollo simile, DNS over TLS (DoT), che cifra anch’esso il traffico DNS ma utilizza la porta dedicata 853. Questa scelta ha una conseguenza pratica rilevante: i sistemi di monitoraggio di rete possono identificare e filtrare il traffico DoT separatamente, mantenendo la visibilità sulle query DNS.

DoH, invece, transita sulla porta 443 e si fonde con il normale traffico HTTPS. Da un lato questo lo rende più difficile da bloccare; dall’altro riduce la visibilità degli strumenti di ispezione DNS aziendali. Prima di scegliere DoH in un ambiente enterprise, occorre valutare se la propria security operations si affida all’ispezione del traffico DNS per rilevare minacce (data exfiltration via DNS, C2 beaconing, ecc.). In quel caso, DoT potrebbe essere preferibile, oppure occorre affiancare soluzioni di monitoring che lavorino a livello applicativo.

Requisiti di sistema

Per abilitare DoH sul ruolo DNS Server di Windows Server 2025 sono necessari:

• Windows Server 2025 con l’aggiornamento cumulativo KB5094125 (9 giugno 2026) o successivo
• Un certificato TLS valido con Extended Key Usage “Server Authentication” e un Subject Alternative Name (SAN) che corrisponda al template URI DoH
• La chiave privata del certificato presente nel certificate store del computer locale, senza strong private key protection abilitata
• Il certificato emesso da una CA trusted da server e client (Microsoft Enterprise CA, DigiCert, Let’s Encrypt — tutte funzionano)
• Porta TCP 443 aperta in ingresso sul firewall del server
• Accesso amministrativo al server

Da notare: al momento non è disponibile alcuna interfaccia grafica nel DNS Manager per gestire DoH. Tutta la configurazione avviene tramite PowerShell.

Configurazione passo per passo

Step 1 — Importare il certificato TLS

Copiare il file .pfx del certificato sul server e importarlo nel certificate store del computer locale:

Import-PfxCertificate `
    -FilePath "C:\Certs\dns-server.pfx" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -Password (Read-Host -AsSecureString "Password PFX")

Step 2 — Associare il certificato alla porta 443

Generare un GUID univoco e associare il certificato alla porta tramite netsh:

$guid = New-Guid
$cert = Get-ChildItem -Path Cert:\LocalMachine\My |
        Where-Object { $_.Subject -match "dns.dominio.local" }

netsh http add sslcert ipport=0.0.0.0:443 `
    certhash=$($cert.Thumbprint) `
    appid="{$guid}"

Per vincolare il binding a un indirizzo IP specifico anziché a tutti gli indirizzi, sostituire 0.0.0.0 con l’indirizzo desiderato.

Step 3 — Aprire la porta 443 nel firewall di Windows

New-NetFirewallRule `
    -DisplayName "DNS over HTTPS" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow

Step 4 — Abilitare DoH e configurare il template URI

Sostituire dns.dominio.local con il hostname presente nel SAN del certificato:

Set-DnsServerEncryptionProtocol `
    -EnableDoh $true `
    -UriTemplate "https://dns.dominio.local:443/dns-query"

Restart-Service -Name DNS

Step 5 — Verificare la configurazione

Get-DnsServerEncryptionProtocol

Aprire il Visualizzatore eventi sotto Applications and Services Logs > DNS Server e verificare la presenza dell’evento ID 822, che conferma l’avvio del servizio DoH.

Configurare i client Windows per usare DoH

Windows supporta DoH lato client da Windows 11 (e da Windows Server 2022 nel ruolo di client DNS). Esistono due metodi principali per puntare i client al resolver DoH interno:

Interfaccia grafica (Windows 11)

Navigare in Impostazioni > Rete e Internet > Ethernet (o Wi-Fi) > Assegnazione server DNS, inserire l’indirizzo IP del server DNS e impostare la cifratura DNS su Solo cifrato (DNS over HTTPS).

Group Policy (Windows Server 2022 e successivi)

Applicare il criterio in Configurazione computer > Criteri > Modelli amministrativi > Rete > Client DNS > Configura risoluzione dei nomi DNS over HTTPS (DoH). Il criterio offre tre opzioni:

• Consenti DoH — usa DoH se il resolver lo supporta
• Proibisci DoH — impedisce l’uso di DoH
• Richiedi DoH — richiede sempre DoH

Attenzione: Microsoft sconsiglia di impostare “Richiedi DoH” su computer appartenenti a un dominio Active Directory se i server DNS non supportano ancora DoH come resolver. AD dipende pesantemente dal DNS, e forzare DoH su una rete senza resolver compatibile interrompe la risoluzione dei nomi e, di conseguenza, l’autenticazione e i GPO. Ora che Windows Server 2025 supporta il lato server, l’opzione “Richiedi DoH” diventa praticabile in ambienti completamente migrati.

Limitazioni attuali da tenere presenti

Prima di pianificare un deployment in produzione, è importante conoscere i limiti della GA attuale:

• Nessuna cifratura verso gli upstream resolver. DoH cifra solo il traffico tra i client e il DNS Server Windows. Le query che il DNS Server invia ai forwarder upstream o ai server autorevoli viaggiano ancora in chiaro sulla porta 53. Microsoft ha annunciato il supporto per query upstream cifrate in un aggiornamento futuro, ma senza timeline confermata.
• Nessuna interfaccia grafica. Il DNS Manager non include ancora le impostazioni DoH. Tutta la gestione richiede PowerShell.
• Punti ciechi nel monitoraggio. Il traffico DoH su porta 443 è cifrato e indistinguibile dall’HTTPS web. Gli strumenti di monitoring DNS a livello di rete perdono visibilità. Valutare l’impatto sulla security operations prima di abilitare DoH in modo capillare.
• DoH non sostituisce DNSSEC. DoH cifra il trasporto; DNSSEC verifica l’integrità delle risposte DNS con firme crittografiche. Le due tecnologie sono complementari e indipendenti: DoH senza DNSSEC protegge dalla sorveglianza ma non dalla manipolazione delle risposte da parte del server stesso.

Considerazioni per il deployment

Un approccio pragmatico per l’introduzione di DoH in un ambiente enterprise prevede di partire con la policy “Consenti DoH” — non forzata — su un gruppo pilota di macchine, verificare che i log di audit DNS continuino a funzionare (adattando gli strumenti di monitoraggio se necessario) e solo successivamente estendere il rollout. Per gli ambienti con requisiti di compliance legati all’ispezione del traffico DNS, è consigliabile documentare la strategia di visibilità alternativa prima di procedere con “Richiedi DoH”.

Il supporto nativo sul DNS Server on-premises è un passo significativo: elimina la dipendenza da resolver cloud di terze parti e permette di mantenere la cifratura DNS all’interno del perimetro aziendale, con pieno controllo sul certificato e sul logging.

---

Fonte: DNS over HTTPS (DoH) for Windows Server 2025 DNS Server is generally available — 4sysops

DNS over HTTPS (DoH) for Windows Server 2025 DNS Server is generally available – 4sysops

DNS over HTTPS (DoH) -- a protocol that encrypts DNS queries inside HTTPS connections -- is now generally available for the Windows Server DNS Server role. Star

^{IT Experts (4sysops)}

(in)sicurezza digitale

2026-06-14 06:24:09

Shadow fleet digitale: Russia e Iran usano 36 siti contraffatti per sfuggire alle sanzioni marittime

Un rapporto pubblicato oggi da Recorded Future’s Insikt Group smantella pezzo per pezzo una vasta rete di siti web contraffatti utilizzati dalle flotte ombra iraniane e russe per aggirare le sanzioni internazionali. Oltre 36 siti impersonano registri navali, amministrazioni marittime nazionali e società di classificazione inesistenti, formando un ecosistema digitale al servizio dell’evasione sanzionatoria.

Il contesto: flotte ombra e sanzioni internazionali

Da quando le sanzioni occidentali hanno colpito le esportazioni energetiche di Russia e Iran, entrambi i Paesi hanno sviluppato reti di navi “ombra” — imbarcazioni che operano cambiando frequentemente bandiera, proprietario apparente e documentazione per continuare a trasportare petrolio sul mercato globale. Il problema centrale è la verifica: port state control, compagnie assicurative e broker richiedono documenti ufficiali — certificati di classe, certificati per i marittimi, lettere P&I — e questi documenti ora vengono prodotti digitalmente da entità fittizie che mimano quelle reali.

Tre cluster, un ecosistema interconnesso

Insikt Group ha identificato tre cluster di infrastruttura online, designati Alpha, Bravo e Charlie, accomunati da sovrapposizioni tecniche, pattern di registrazione domini e ricorrenti errori OPSEC. L’analisi mostra connessioni esplicite a 17 navi, la maggioranza delle quali già sanzionate dall’OFAC (Office of Foreign Assets Control) del Dipartimento del Tesoro statunitense.

Cluster Alpha è quello più sofisticato dal punto di vista tecnico: include un generatore automatizzato di PDF che produce certificati fraudolenti per marittimi con QR code funzionali, apparentemente riconducibile all’azienda indiana di sviluppo web Oceaniek Technologies. I certificati vengono emessi “per conto” delle amministrazioni marittime di Benin, Comore e Nicaragua — paesi con scarsa capacità di supervisione e spesso sfruttati come bandiere di comodo.

Cluster Bravo è collegato a due cittadini siriani, uno dei quali ha precedenti di coinvolgimento in attività illecite, e comprende organizzazioni fittizie come la Med Lloyd Classification Society, Hellas Naval Bureau of Shipping e vari siti di formazione per marittimi. Cluster Charlie condivide caratteristiche tecniche e di design con Bravo ma rimane non attribuito, e utilizza uno schema di “validazione a strati” in cui le amministrazioni marittime false avallano altre entità false per costruire credibilità reciproca.

Tecniche di falsificazione: il generatore di certificati

Il meccanismo più significativo identificato nel Cluster Alpha è un’applicazione web che consente la generazione self-service di documenti marittimi fraudolenti. Il sistema accetta i dati del marittimo in input, genera un certificato PDF formalmente identico a quello ufficiale, associa al documento un QR code che punta a una pagina di verifica controllata dagli stessi attori — restituendo risultati “positivi” durante le ispezioni portuali — e mantiene un database queryabile di certificati fittizi per simulare consultazioni da parte delle autorità. Questa capacità trasforma il sistema di verifica documentale in uno strumento di validazione per i documenti fraudolenti stessi.

Pattern tecnici e indicatori di infrastruttura

# Domini identificati nei tre cluster
## Cluster Alpha
beninmaritime[.]org / beninmaritime[.]co / beninmaritime[.]net
epnicaragua[.]org
atlasregister[.]net
## Cluster Bravo
medlloyd[.]online
hellasnaval[.]net
nauticacentro[.]mx
isithin[.]com
## Cluster Charlie
pioneersmaritime[.]com
alliance-scs[.]org
sasmaa[.]club
zambmaritime[.]org
# IP di hosting condivisi
159[.]198[.]36[.]123
217[.]76[.]51[.]133
151[.]80[.]4[.]227

Collegamento a report precedenti e navi sanzionate

Il rapporto integra indagini precedenti: Bellingcat aveva documentato nel febbraio 2026 l’attività di Oceaniek Technologies, e Lloyd’s List aveva scoperto un cluster di registri navali falsi centrati attorno al dominio marinegov[.]net. Le 17 navi per cui Insikt Group ha trovato connessioni esplicite includono petroliere già sanzionate da OFAC, Unione Europea e altri Paesi. Questo elemento rafforza la tesi che le reti di siti fraudolenti non siano operative isolate ma componenti di un’infrastruttura di servizio — un sanctions-evasion-as-a-service — che vende documentazione falsa a più reti operative simultaneamente.

Due righe per compliance e difensori

Per le organizzazioni del settore marittimo, portuale e finanziario coinvolte in operazioni di due diligence, il rapporto segnala un cambio di paradigma: la verifica documentale tradizionale non è più sufficiente. Le raccomandazioni operative includono la verifica indipendente contattando direttamente le autorità nazionali (non tramite link nei documenti), l’integrazione di feed CTI nelle piattaforme di compliance per rilevare domini fraudolenti, l’analisi WHOIS dei domini presenti nei certificati e la segnalazione coordinata alle autorità dei Paesi la cui identità viene impersonata.

Fonte primaria: Insikt Group / Recorded Future, 11 giugno 2026.

Cyber-Enabled Maritime Sanctions Evasion

Discover how Iranian and Russian shadow fleets use a vast network of fake maritime websites and fraudulent documents to evade international sanctions

^{www.recordedfuture.com}

(in)sicurezza digitale

2026-06-12 14:00:46

ShinyHunters colpisce le università americane con uno zero-day Oracle PeopleSoft: l’operazione UNC6240 analizzata da Mandiant

Si parla di:
Toggle

Mandiant e Google Threat Intelligence Group (GTIG) hanno pubblicato oggi un rapporto dettagliato su una campagna attiva di compromissione ed estorsione attribuita a UNC6240, meglio noto come ShinyHunters. L’obiettivo: le istituzioni universitarie americane, colpite attraverso uno zero-day critico in Oracle PeopleSoft che ha consentito l’accesso non autenticato a centinaia di sistemi prima ancora che Oracle rilasciasse la patch.

Il vettore d’attacco: CVE-2026-35273, un RCE con CVSS 9.8

Al centro della campagna si trova CVE-2026-35273, una vulnerabilità di remote code execution (RCE) con punteggio CVSS di 9.8 nel componente Environment Management di Oracle PeopleSoft. Il punto di ingresso sfruttato è l’Environment Management Hub (PSEMHUB), un servizio amministrativo spesso esposto direttamente su Internet nelle configurazioni multi-server. L’attività — documentata tra il 27 maggio e il 9 giugno 2026 — ha preceduto l’advisory Oracle del 10 giugno 2026, classificando di fatto l’exploit come zero-day operativo per oltre due settimane.

GTIG ha identificato gli endpoint vulnerabili e avviato notifiche a oltre 100 organizzazioni globali, con una concentrazione geografica negli Stati Uniti. Particolarmente colpito il settore dell’istruzione superiore: il 68% delle organizzazioni notificate sono atenei e college.

Chi sono gli ShinyHunters: da BreachForums a campagne zero-day

ShinyHunters (tracciato da Mandiant come UNC6240) è un gruppo cybercriminale che si è fatto conoscere tra il 2020 e il 2022 per una serie di breach di alto profilo — AT&T, Ticketmaster, Santander, Advance Auto Parts — venduti poi su BreachForums. Il gruppo ha assunto il controllo di BreachForums dopo l’arresto degli amministratori precedenti, consolidando la propria posizione nell’ecosistema del cybercrime anglofono. La campagna attuale segna un’evoluzione tattica: da semplici acquirenti di accesso iniziale a gruppo capace di sviluppare o acquisire exploit zero-day per piattaforme enterprise.

Infrastruttura C2: MeshCentral travestito da Microsoft Azure

L’analisi delle directory aperte sui cinque host di staging (IP sequenziali 142.11.200.186–190) ha rivelato un’infrastruttura C2 basata su MeshCentral, un software open-source di remote management. Gli agenti Windows precompilati erano rinominati per mimare endpoint legittimi di Microsoft Azure:

• meshagent64-azure-ops.exe
• meshagent32-azure-ops.exe
• meshagent64-v2.exe

Tutti gli agenti erano hardcoded per connettersi al server C2 wss://azurenetfiles.net:443/agent.ashx. Il dominio azurenetfiles.net è stato scelto per imitare Microsoft Azure NetApp Files, una tecnica di masquerading volta a confondere i team di sicurezza durante l’analisi dei log di rete. I server di staging eseguivano Python SimpleHTTP sulla porta 8888, inavvertitamente esposti al pubblico — errore OPSEC che ha permesso a Mandiant e ai ricercatori indipendenti di recuperare l’intero corredo di artefatti.

Timeline operativa e reconnaissance

Il file .bash_history — identico su tutti e cinque i server di staging — ha fornito una timeline dettagliata delle operazioni. Il 27 maggio 2026 alle 22:14 UTC gli attaccanti hanno installato MeshCentral (v1.1.59); pochi minuti dopo, alle 22:25 UTC, hanno configurato il client acme-client per l’automazione dei certificati Let’s Encrypt per il dominio di masquerading. La reconnaissance sulle reti interne delle vittime includeva:

• Lettura del file psappsrv.cfg per estrarre hostname e indirizzi IP interni
• Analisi dei mount NFS attivi (mount | grep psoft)
• Lettura del file /etc/hosts per mappare la topologia interna
• Ispezione delle configurazioni WebLogic (config.xml)

Propagazione laterale e script fanout

Una volta ottenuto l’accesso al primo nodo, gli attaccanti hanno utilizzato MeshCentral per distribuire uno script Bash denominato [victim_abbreviation]_fanout.sh, scritto direttamente in /tmp tramite heredoc. Lo script automatizza il credential spraying SSH verso gli host interni, parsing la lista da /etc/hosts, e — una volta ottenuto l’accesso — copia un file di estorsione nelle directory WebLogic e Process Scheduler:

README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT

L’esfiltrazione dei dati è avvenuta tramite compressione con zstd seguita da una connessione SSH in uscita verso 176.120.22.24, IP che ospita il mirror pubblico del ShinyHunters Data Leak Site (DLS). Il 9 giugno 2026, alcune organizzazioni vittime sono apparse sul DLS confermando la compromissione avvenuta con successo.

Indicatori di compromissione (IoC)

# IP di staging C2
142.11.200.186
142.11.200.187
142.11.200.188
142.11.200.189
142.11.200.190

# DLS mirror
176.120.22.24

# Dominio C2
azurenetfiles.net

# Hash SHA-256 artefatti
.bash_history:              2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35
meshagent64-azure-ops.exe:  f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc
meshagent64-v2.exe:         d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f
meshagent32-azure-ops.exe:  c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f
meshagent (Linux):          68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309

# Porte
Python SimpleHTTP: porta 8888
WebSocket C2: wss://azurenetfiles.net:443/agent.ashx

Azioni di remediation prioritarie

Per i team di sicurezza che gestiscono ambienti Oracle PeopleSoft, Mandiant raccomanda azioni immediate:

• Disabilitare EMHub: in configurazioni multi-server, disabilitare il servizio Environment Management Hub; in configurazioni single-server, rimuovere completamente l’applicazione PSEMHUB.
• Blocco perimetrale: bloccare l’accesso esterno agli endpoint /PSEMHUB/* e /PSIGW/HttpListeningConnector a livello firewall — non affidarsi esclusivamente a regole WAF.
• Analisi log: verificare nei log WebLogic richieste POST anomale verso /PSEMHUB/hub da IP esterni.
• Audit filesystem: cercare file .jsp non previsti in PSEMHUB.war/ e directory inattese logs/, persistantstorage/, scratchpad/.
• Monitoraggio NetFlow: rilevare traffico SMB in uscita (porta 445) da host PeopleSoft verso destinazioni internet esterne (indicatore potenziale di cattura hash NetNTLM).

Fonte primaria: Mandiant / Google Cloud Blog, 11 giugno 2026.

ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit | Google Cloud Blog

An active compromise and extortion campaign attributed to ShinyHunters targeting Oracle PeopleSoft with a zero-day exploit.

^{Mandiant (Google Cloud Blog)}

Spcnet.it

2026-06-12 13:16:46

CVE-2026-44963: RCE critico su Veeam Backup & Replication — aggiornare subito a 12.3.2.4854

Il 9 giugno 2026 Veeam ha rilasciato una patch di emergenza per CVE-2026-44963, una vulnerabilità di esecuzione di codice remoto con CVSS v4 di 9.4 (Critical) che colpisce Veeam Backup & Replication 12.x. La falla consente a un qualsiasi utente autenticato nel dominio Active Directory di eseguire codice arbitrario sul backup server — anche senza privilegi specifici sull’applicazione Veeam stessa. In un ambiente enterprise, questo equivale alla potenziale compromissione dell’intera infrastruttura di disaster recovery.

Cosa permette di fare CVE-2026-44963

Si tratta di una falla di deserializzazione non sicura nel servizio Veeam Backup & Replication. Un utente di dominio può inviare richieste costruite ad hoc all’API interna del backup server e ottenere esecuzione di codice con i permessi del processo Veeam — tipicamente SYSTEM o un account di servizio ad alto privilegio.

Il vettore è di rete, la complessità bassa, non è richiesta interazione utente. L’unica limitazione: il backup server deve essere membro di un dominio Active Directory. I server Veeam in workgroup non sono affetti da questa CVE specifica.

Versioni affette e versione sicura

Versione	Stato
12.3.2.4465 e precedenti (tutta la linea 12.x)	⚠️ Vulnerabile
12.3.2.4854	✅ Patchata
13.x	✅ Non affetta (architettura diversa)

Perché i backup server sono target critici

Un backup server ha accesso privilegiato a tutti i sistemi che protegge: credenziali, snapshot, dati di configurazione. Un attaccante che lo compromette può:

• Esfiltrare dati sensibili dai backup di sistemi critici
• Cifrare o cancellare i backup, rendendo inutile la strategia di disaster recovery
• Usare le credenziali salvate per muoversi lateralmente nell’infrastruttura
• Distribuire ransomware sapendo che il ripristino sarà impossibile

Sina Kheirkhah di WatchTowr, che ha scoperto e segnalato la falla, sottolinea come compromettere il backup server sia l’equivalente di togliere la rete di sicurezza prima che qualcuno cada.

Verificare la versione installata

Da PowerShell sul backup server:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Veeam\Veeam Backup and Replication" |
    Select-Object -ExpandProperty PackageVersion

Oppure via registry:

reg query "HKLM\SOFTWARE\Veeam\Veeam Backup and Replication" /v PackageVersion

In alternativa, dalla Veeam Backup Console: Help → About.

Procedura di aggiornamento a 12.3.2.4854

L’update è disponibile sul portale download Veeam. Prima di procedere:

1. Verificare lo spazio disco: l’installer richiede almeno 3 GB liberi sul volume di sistema.
2. Eseguire un backup manuale dei sistemi più critici come precauzione.
3. Mettere in pausa i job schedulati per evitare conflitti durante l’aggiornamento.
4. Aggiornare i componenti remoti dopo l’update del server principale (proxy, repository, agent). Non ignorare questo passaggio.

# Verificare componenti da aggiornare dopo l'update del server
Add-PSSnapin VeeamPSSnapIn
$currentVer = (Get-VBRVersion).ProductVersion
Get-VBRServer | Where-Object { $_.ComponentsVersion -ne $currentVer }

Mitigazioni se non è possibile aggiornare subito

Se non è possibile applicare la patch immediatamente, queste misure riducono la superficie di attacco:

• Isolare il backup server dalla rete generale: limitare l’accesso alle porte di gestione Veeam (default TCP 9392, 9401) ai soli host autorizzati tramite firewall o ACL.
• Ridurre gli account di dominio con accesso al server Veeam: applicare il principio del minimo privilegio.
• Monitorare i log di autenticazione: cercare autenticazioni anomale verso il Veeam Backup Service in orari inusuali.
• MFA per gli account di gestione Veeam: se il provider di identità lo supporta, abilitare l’autenticazione a più fattori.

Il pattern storico delle vulnerabilità Veeam

Non è la prima volta che Veeam finisce sotto i riflettori per falle critiche. CVE-2023-27532 (CVSS 7.5), CVE-2024-40711 (CVSS 9.8) e ora CVE-2026-44963 mostrano che i backup server sono bersagli sempre più ricercati, specialmente dagli operatori ransomware. Il suggerimento è di trattare i server Veeam come sistemi Tier-0, al pari dei Domain Controller: monitoraggio dedicato, accesso privilegiato minimale, patch urgente e segmentazione di rete.

Conclusione

CVE-2026-44963 non ammette ritardi: qualsiasi utente di dominio può compromettere il backup server e da lì raggiungere tutto il resto. Verificare la versione installata, pianificare l’aggiornamento a 12.3.2.4854 nel più breve tempo possibile e applicare nel frattempo le mitigazioni di rete.

Fonte: The Hacker News — Veeam Backup & Replication RCE Flaw Lets Domain Users Run Remote Code | BleepingComputer — New Veeam vulnerability exposes backup servers to RCE attacks

Veeam Backup & Replication RCE Flaw Lets Domain Users Run Remote Code

Veeam fixes CVE-2026-44963 RCE in 12 builds, blocking authenticated domain users from attacking backup servers.

^{The Hacker News}

Spcnet.it

2026-06-12 13:14:29

IAKerb e LocalKDC su Windows: meno dipendenza da NTLM, più Kerberos

Perché NTLM è ancora vivo (e quanto è difficile eliminarlo)

In ambienti Active Directory, Kerberos è il protocollo di autenticazione preferito da Microsoft da oltre vent’anni. Eppure, NTLM continua a essere presente in quasi ogni infrastruttura Windows perché esistono tre scenari in cui Kerberos non funziona e il sistema ricade inevitabilmente su NTLM:

• Il client non ha visibilità di rete diretta su un Domain Controller (DC)
• L’autenticazione coinvolge un account locale invece di un account di dominio
• L’ambiente è un workgroup o una macchina standalone, senza infrastruttura di dominio

Sono esattamente questi tre gap che Microsoft sta affrontando con IAKerb e LocalKDC, due funzionalità oggi in public preview su Windows Insider (Canary Channel) e previste in disponibilità generale su Windows 11 24H2 e Windows Server 2025 nella seconda metà del 2026.

IAKerb: Kerberos anche senza visibilità sul Domain Controller

IAKerb (Initial and Pass-Through Authentication using Kerberos) è un meccanismo definito nella bozza IETF draft-ietf-kitten-iakerb-03. Si implementa come sotto-meccanismo GSS-API, inserendosi nel protocollo SPNEGO che Windows già utilizza per la negoziazione dell’autenticazione.

Nel flusso Kerberos standard, il client deve contattare direttamente il KDC (Key Distribution Center, il servizio che gira su ogni DC) sulla porta TCP/UDP 88 per ottenere un ticket prima di potersi autenticare su un servizio. Se nessun DC è raggiungibile, Kerberos fallisce e Windows scade su NTLM.

IAKerb risolve questo problema rendendo il server di destinazione un proxy trasparente per i messaggi Kerberos. Il client tunnel i messaggi Kerberos all’interno della connessione esistente verso il server applicativo (ad esempio, sulla porta TCP 445 per SMB), e il server li inoltra al DC per conto del client. Il server non vede mai la password o l’hash: si limita a fare da relay ai messaggi di protocollo.

Il risultato pratico è che l’autenticazione rimane su percorso Kerberos anche quando:

• Il client si trova in una subnet segmentata senza accesso diretto ai DC
• L’accesso avviene via VPN o accesso remoto con routing limitato
• L’architettura cloud restringe la connettività diretta ai controller di dominio

LocalKDC: Kerberos anche per gli account locali

LocalKDC affronta il secondo grande limite: gli account locali. Kerberos richiede un KDC per emettere i ticket, e gli account locali (quelli nel SAM della macchina) non hanno nessun KDC a cui rivolgersi. Di conseguenza, qualunque autenticazione remota che coinvolgesse un account locale era storicamente vincolata a NTLM.

LocalKDC è un KDC leggero integrato direttamente in Windows, che opera esclusivamente sugli account del SAM locale. Emette ticket Kerberos basati su AES per le identità locali, abilitando l’autenticazione Kerberos anche in ambienti workgroup, macchine standalone e qualsiasi scenario con credenziali locali.

Stato attuale e configurazione via registro

Le due funzionalità hanno default diversi nel preview corrente:

• IAKerb: abilitato per default
• LocalKDC: disabilitato per default

La configurazione avviene tramite valori di registro di tipo REG_DWORD:

• DisableIAKerb: impostare a 0 per abilitare, 1 per disabilitare
• DisableLocalKDC: impostare a 0 per abilitare, 1 per disabilitare

Group Policy e gestione tramite MDM (Intune incluso) saranno aggiunti quando le funzionalità usciranno dalla fase di preview.

Prima di testare: auditing NTLM

Prima di attivare IAKerb e LocalKDC in produzione, è fondamentale capire dove NTLM viene ancora usato nell’ambiente. Windows 11 24H2 e Windows Server 2025 includono log operativi NTLM migliorati, accessibili in Event Viewer sotto:

Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Gli Event ID rilevanti sono:

• 4020, 4021: eventi client (includono nome processo, IP di destinazione, codice motivo per cui Kerberos non è stato usato)
• 4022, 4023: eventi server (nome processo e IP client)
• 4030–4033: eventi sui domain controller (dettagli client e server)

I log client sono i più informativi perché riportano il motivo del fallback a NTLM, permettendo di identificare i workload che richiedono intervento prima di pensare a disabilitare NTLM.

L’abilitazione del logging si gestisce via Group Policy:

• Per client e server: Administrative Templates > System > NTLM > NTLM Enhanced Logging
• Per i domain controller: Administrative Templates > System > Netlogon > Log Enhanced Domain-wide NTLM Logs

Limiti attuali e roadmap Microsoft

IAKerb e LocalKDC non eliminano ogni dipendenza da NTLM. Rimangono scenari che continuano a richiedere NTLM:

• Applicazioni con NTLM hardcoded nel codice
• Infrastrutture che assumono NTLM come default nella loro logica di autenticazione
• Alcune interazioni tra account di dominio e account locali sulla stessa macchina

La roadmap Microsoft per la disabilitazione di NTLM si articola in tre fasi:

• Fase 1 (già in produzione): miglioramenti all’auditing NTLM
• Fase 2 (H2 2026): disponibilità generale di IAKerb e LocalKDC
• Fase 3 (~2027–2028): NTLM disabilitato per default nella prossima versione major di Windows Server

Cosa fare adesso

Per un amministratore di sistema che vuole prepararsi al cambiamento in anticipo, il percorso consigliato è: abilitare i log NTLM migliorati oggi (già disponibili su 24H2/Server 2025), analizzare gli event ID nei prossimi mesi per mappare i workload con dipendenza NTLM, e pianificare i test con IAKerb e LocalKDC su ambienti non produttivi non appena la disponibilità generale sarà confermata. Affrontare questa transizione gradualmente è molto più gestibile che trovarsi a fare remediation d’emergenza quando NTLM verrà disabilitato per default.

Fonte originale: Reducing NTLM fallback with IAKerb and LocalKDC in Windows – 4sysops.com

Reducing NTLM fallback with IAKerb and LocalKDC in Windows – 4sysops

Microsoft has introduced two new authentication features, IAKerb and LocalKDC, entering public preview in June 2026 for Windows Insiders in the Canary Channel.

^{IT Experts (4sysops)}

Spcnet.it

2026-06-12 13:14:52

Patch Tuesday Giugno 2026: record di 208 CVE, 6 zero-day e una falla kernel wormable con CVSS 9.8

Il Patch Tuesday di giugno 2026 ha stabilito un nuovo record assoluto: Microsoft ha rilasciato aggiornamenti di sicurezza per ben 208 CVE, superando il precedente record e portando con sé 6 zero-day, di cui uno attivamente sfruttato in attacchi reali. Per i sistemisti, questo ciclo di patch è tra i più critici dell’anno: ci sono falle wormable nel kernel, bypass multipli di BitLocker, RCE su Hyper-V, AKS e DHCP, e una vulnerabilità Exchange già sfruttata in produzione.

Il quadro generale

Delle 208 vulnerabilità corrette, 33 sono classificate Critical. La distribuzione per tipologia:

• 65 Elevation of Privilege
• 55 Remote Code Execution
• 30 Information Disclosure
• 27 Spoofing
• 19 Security Feature Bypass
• 7 Denial of Service

Il conteggio esclude le 360 CVE ereditate da Chromium/Edge e le falle in servizi cloud come Exchange Online e Microsoft Graph, già patchate in precedenza nel mese.

I sei zero-day

CVE-2026-42897 — Exchange Server Spoofing (attivamente sfruttata)

L’unica zero-day già in uso attivo. Un attaccante invia una email costruita ad hoc: se la vittima la apre in Outlook Web Access, viene eseguito JavaScript arbitrario nel browser. Microsoft ha distribuito mitigazioni tramite il servizio Exchange Emergency Mitigation (EEMS). Verificare che EEMS sia abilitato di default; la patch completa è in lavorazione. Azione immediata richiesta.

CVE-2026-45586 — Windows CTFMON GreenPlasma (EoP)

Divulgata da Nightmare Eclipse, permette di ottenere un shell SYSTEM sfruttando una link following errata nel Windows Collaborative Translation Framework. Prima di una serie di zero-day rilasciate dallo stesso ricercatore in protesta contro il bug bounty Microsoft.

CVE-2026-45585 — BitLocker YellowKey (Security Feature Bypass)

Con accesso fisico al dispositivo, un attaccante inserisce file costruiti su USB o partizione EFI e, avviando in WinRE tenendo CTRL, ottiene accesso illimitato al disco cifrato. Colpisce sistemi con BitLocker in modalità TPM-only. Mitigazione: abilitare TPM+PIN.

CVE-2026-50507 — BitLocker bitskrieg (Security Feature Bypass)

Secondo bypass BitLocker, divulgato da Jonas Lykkegaard. La patch potrebbe causare l’errore “A required file couldn’t be accessed because your BitLocker key wasn’t loaded correctly”. Il fix:

reagentc /disable
reagentc /enable

CVE-2020-17103 — Cloud Files Mini Filter Driver Mini-Plasma (EoP)

CVE originariamente del 2020, segnalata da James Forshaw (Google Project Zero). Sembrava già corretta nel dicembre 2020, ma Nightmare Eclipse ha dimostrato che la vulnerabilità era ancora sfruttabile. L’update di giugno 2026 la chiude definitivamente.

CVE-2026-49160 — HTTP/2 Bomb DoS su HTTP.sys

Abusa della compressione degli header HTTP/2 per forzare il server ad allocare quantità sproporzionate di memoria con pochissimi dati in ingresso. Microsoft ha introdotto la chiave di registro MaxHeadersCount per limitare il numero di header accettati (KB5102602):

; HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
; DWORD: MaxHeadersCount = 100

Le CVE Critical più rilevanti per l’infrastruttura

CVE-2026-45657 — Windows Kernel RCE (CVSS 9.8, wormable)

È la vulnerabilità che preoccupa di più. Una use-after-free nel kernel legata all’elaborazione del traffico TCP/IP permette a un attaccante non autenticato di eseguire codice da remoto, senza interazione utente. Il vettore CVSS (AV:N/AC:L/PR:N/UI:N) e la classificazione wormable significa che un exploit funzionante potrebbe autopropag arsi tra macchine sulla stessa rete. Sistemi colpiti: Windows 11 (23H2, 24H2, 25H2, 26H1) e Windows Server 2022/2025 incluso Server Core. I ricercatori stimano la finestra per un exploit pubblico in giorni, non settimane. Priorità assoluta.

CVE-2026-32193 — Azure Kubernetes Service Container Escape (Critical)

Path traversal in AKS che permette a un container configurato con hostNetwork: true di evadere il container e ottenere il controllo del worker node. Chi gestisce cluster AKS deve verificare aggiornamenti disponibili:

az aks upgrade --resource-group myRG --name myCluster --kubernetes-version latest

CVE-2026-44815 — DHCP Client Service RCE (Critical)

RCE nel client DHCP di Windows, sfruttabile da un attaccante che controlla un server DHCP malevolo in rete. Rischio elevato in ambienti con BYOD o reti ospiti non segregate.

CVE-2026-45641 / CVE-2026-47652 — Hyper-V RCE (Critical)

Due falle di esecuzione di codice in Hyper-V. Su hypervisor il patching è prioritario: una compromissione può portare all’escape delle VM e alla compromissione dell’host.

CVE-2026-45648 — Active Directory Domain Services RCE (Critical)

RCE nei Domain Controller. Qualunque falla RCE su DC va trattata con la massima urgenza: una compromissione equivale a quella dell’intero dominio.

CVE-2026-47291 — HTTP.sys RCE (Critical)

RCE nel driver HTTP.sys, separata dalla HTTP/2 Bomb. Colpisce tutti i sistemi che espongono servizi HTTP inclusi IIS e applicazioni che usano direttamente HTTP.sys.

Strategia di deployment

Con 208 CVE e sei zero-day, non c’è spazio per ritardi. Alcune linee guida pratiche:

1. Controllare ADV990001: verificare che il Servicing Stack Update (SSU) sia installato. È il prerequisito per l’installazione corretta di tutti gli altri aggiornamenti.
2. Exchange prima: CVE-2026-42897 è attivamente sfruttata. Applicare le mitigazioni EEMS immediatamente.
3. Domain Controller: CVE-2026-45648 su AD DS è Critical. Test in ambiente non-prod, poi deployment rapido su DC.
4. BitLocker — leggere le release notes: CVE-2026-50507 può richiedere il fix manuale con reagentc. Testare prima del rollout su larga scala.
5. Hotpatch su Azure VM: Microsoft ha reso generalmente disponibile l’hotpatching per Azure VM (Linux e Windows Server), che applica le patch kernel senza riavvio. Nei workload Azure, è la modalità preferita per ridurre i downtime.

Conclusione

Il Patch Tuesday di giugno 2026 non è un mese da rimandare. La CVE-2026-45657 (kernel wormable CVSS 9.8), la zero-day Exchange in produzione, i doppi bypass BitLocker e la falla AKS compongono un quadro che richiede azione rapida e pianificata. Scaricare gli update, verificare l’SSU, prioritizzare Exchange e DC, e monitorare per eventuali regressioni post-patch, specialmente per il caso BitLocker/reagentc.

Fonte: BleepingComputer — Microsoft June 2026 Patch Tuesday fixes 6 zero-days, 200 flaws | Zero Day Initiative — June 2026 Security Update Review

Zero Day Initiative — The June 2026 Security Update Review

I’ve made it through Pwn2Own Berlin, had a little vacation, and now I’m back for Patch Tuesday. Microsoft and Adobe didn’t disappoint. In fact, they have heralded my return with the largest Patch Tuesday release ever.

^{Dustin Childs (Zero Day Initiative)}

(in)sicurezza digitale

2026-06-11 18:31:38

RoguePlanet: il quinto zero-day di Nightmare Eclipse trasforma Microsoft Defender in un vettore di escalation a SYSTEM

Ore dopo che Microsoft ha distribuito il Patch Tuesday di giugno 2026 — correggendo tra l’altro due zero-day dello stesso ricercatore — Nightmare Eclipse ha rilasciato pubblicamente RoguePlanet, un nuovo exploit che sfrutta una race condition in Microsoft Defender per elevare i privilegi a SYSTEM su sistemi completamente patchati. Il gesto è l’ultimo atto di una guerra a distanza tra il ricercatore e Redmond su pratiche di divulgazione e bug bounty, e solleva interrogativi scomodi sulla gestione delle vulnerabilità da parte della più grande azienda di software al mondo.

La saga Nightmare Eclipse: cinque zero-day, una disputa irrisolta

RoguePlanet è il quinto exploit zero-day pubblicamente rilasciato da Nightmare Eclipse negli ultimi mesi, dopo BlueHammer, RedSun, GreenPlasma e YellowKey. I precedenti exploit hanno colpito Microsoft Defender, BitLocker e componenti core di Windows; GreenPlasma e YellowKey sono stati corretti proprio nel Patch Tuesday del 9 giugno 2026.

Il ricercatore sostiene che Microsoft abbia sistematicamente rimosso i repository GitHub e GitLab che ospitavano i PoC, costringendolo a creare una piattaforma self-hosted (projectnightcrawler.dev). Microsoft ha risposto nel maggio 2026 con un comunicato del MSRC in cui avvertiva che avrebbe collaborato con le autorità in caso di “attività dannose che causano reale danno ai clienti” — una formulazione che la comunità della sicurezza ha ampiamente interpretato come una velata minaccia legale verso il ricercatore. L’effetto è stato controproducente: la tensione si è intensificata, e RoguePlanet ne è la diretta conseguenza.

Meccanica dell’exploit: dalla RCE alla LPE via Defender

RoguePlanet nasce originariamente come vulnerabilità di Remote Code Execution. L’idea iniziale sfruttava il modo in cui Microsoft Defender gestisce file ospitati su share SMB remoti: un attaccante poteva indurre una vittima ad aprire un file .vhd(x) su un server SMB controllato, ottenendo che Defender sovrascrivesse i propri file — con conseguente RCE.

A metà maggio 2026, Microsoft ha effettuato un hardening silenzioso dell’API mpengine!SysIO*, bloccando gli attacchi basati su junction point. Il ricercatore ha dovuto riscrivere l’exploit da zero, riuscendo a preservare solo la componente di Local Privilege Escalation. Nella forma attuale:

• L’exploit sfrutta una race condition nella logica di processing interno di Defender.
• Un utente non privilegiato reindirizza un’operazione su file eseguita da Defender (che gira come SYSTEM) verso codice controllato dall’attaccante.
• Il risultato è l’apertura di un command prompt con privilegi SYSTEM — la shell più privilegiata su Windows.
• La percentuale di successo è variabile: il ricercatore riporta “100% su alcune macchine, meno su altre”, essendo una race condition dipendente dal timing.

ThreatLocker ha confermato la riproducibilità dell’exploit su Windows 11 con la patch KB5094126 installata. Il CEO Danny Jenkins ha dichiarato a BleepingComputer: “La nostra analisi iniziale conferma che l’exploit RoguePlanet è valido e funziona come descritto. Le organizzazioni che utilizzano application allowlisting possono prevenire l’esecuzione dell’exploit.”

Sistemi affetti e stato attuale

Al momento della pubblicazione di questo articolo, non esiste una patch ufficiale Microsoft per RoguePlanet. I sistemi vulnerabili includono:

• Windows 11 (build Official e Canary) con gli aggiornamenti di giugno 2026 installati
• Windows 10 con gli aggiornamenti di giugno 2026 installati

Non sono stati rilevati casi di sfruttamento attivo in the wild al momento della scrittura. Tuttavia, l’exploit è pubblicamente disponibile su un repository self-hosted, il che abbassa significativamente la barriera per attori motivati.

Il paradosso della divulgazione: quando il vendor diventa il problema

La vicenda Nightmare Eclipse tocca un nervo scoperto dell’ecosistema della sicurezza: cosa succede quando un vendor di dimensioni planetarie risponde ai ricercatori indipendenti con minacce legali anziché con correzioni tempestive e riconoscimento equo?

Il modello di coordinated disclosure — già fragile — mostra le sue crepe: il ricercatore ha seguito le procedure inizialmente, ma la risposta di Microsoft (rimozione dei repository, silenzio sul bug bounty, comunicato quasi legalistico) ha spinto verso la full disclosure non coordinata. Il risultato è una serie di zero-day pubblici su uno dei sistemi operativi più diffusi al mondo, senza patch disponibili.

Va notato che la comunità della sicurezza rimane divisa: alcuni vedono Nightmare Eclipse come un ricercatore che agisce nell’interesse pubblico esponendo pratiche scorrette; altri ritengono che rilasciare exploit senza patch metta in pericolo utenti comuni. La verità è che entrambe le posizioni hanno una base legittima — e che il vero problema risiede nel comportamento di Microsoft.

Indicatori e due righe per i difensori

In assenza di patch, le misure di mitigazione disponibili sono:

• Application allowlisting: come confermato da ThreatLocker, blocca l’esecuzione del payload. Soluzioni come Windows Defender Application Control (WDAC) o AppLocker possono essere efficaci.
• Principio del minimo privilegio: l’exploit richiede l’esecuzione di codice come utente locale. Ridurre la superficie d’attacco limitando i diritti degli utenti finali.
• Monitoraggio dei processi sospetti: alert su processi figlio spawned da MsMpEng.exe (il processo principale di Defender) con privilegi elevati.
• EDR e XDR: monitorare comportamenti anomali legati a race condition sulle operazioni di file di Defender.

# Processo da monitorare
MsMpEng.exe → cmd.exe / powershell.exe (child process con TOKEN SYSTEM)
# Percorsi sensibili coinvolti
C:\ProgramData\Microsoft\Windows Defender\*
mpengine!SysIO* API calls con reindirizzamento anomalo
# Fonti di intelligence
projectnightcrawler.dev (self-hosted repo Nightmare Eclipse)
CVE: non ancora assegnato al momento della pubblicazione

La storia di RoguePlanet non è semplicemente quella di un exploit: è il sintomo di un ecosistema della vulnerability disclosure sotto pressione, in cui le dinamiche di potere tra vendor e ricercatori indipendenti producono rischi reali per tutti gli utenti Windows. Seguiremo gli sviluppi.

(in)sicurezza digitale

2026-06-11 18:31:00

WhatsApp vs NSO Group: violata l’ingiunzione del tribunale, spearphishing contro gli utenti nonostante il divieto

WhatsApp ha presentato una richiesta di contempt order al tribunale federale contro NSO Group, accusando la società israeliana di spyware di aver continuato a colpire gli utenti della piattaforma nonostante un’ingiunzione permanente emessa in ottobre che le vietava esplicitamente di farlo. La vicenda riapre il dibattito sul mercato degli spyware commerciali e sull’efficacia degli strumenti legali contro chi li produce.

Il Contesto: sette anni di battaglia legale

La storia tra WhatsApp e NSO Group inizia nell’ottobre 2019, quando la piattaforma di Meta ha citato in giudizio la società israeliana per aver sfruttato una vulnerabilità del servizio per installare il suo spyware Pegasus su circa 1.400 dispositivi di attivisti per i diritti umani, giornalisti e dissidenti in tutto il mondo attraverso attacchi zero-click. Bastava che il bersaglio ricevesse una chiamata WhatsApp — anche senza risponderla — per compromettere il dispositivo.

Il procedimento giudiziario si è concluso con una vittoria storica per WhatsApp: nel maggio 2026 una giuria ha inizialmente assegnato 167 milioni di dollari di danni punitivi, successivamente ridotti a 4,4 milioni dal giudice federale che presiedeva il caso. A ottobre 2025, lo stesso giudice ha emesso un’ingiunzione permanente che vietava a NSO di utilizzare WhatsApp come vettore d’attacco.

NSO aveva risposto all’ingiunzione dichiarando che avrebbe potuto “mettere a rischio l’intera impresa NSO” e “costringere NSO a chiudere i battenti”, mentre il giudice respingeva le sue richieste di sospensione dell’ordine. La società ha presentato appello a novembre 2025, con un procedimento ancora in corso.

Le nuove violazioni: spearphishing in spregio al tribunale

Nonostante l’ingiunzione, WhatsApp ha rilevato nuova attività malevola attribuita a NSO Group dopo che utenti hanno segnalato comportamenti sospetti. Secondo il blog post pubblicato da Meta l’8 giugno 2026, gli attacchi avrebbero usato tecniche di social engineering per indurre gli utenti a cliccare su link malevoli verso siti web esterni fuori da WhatsApp, una metodologia simile alle campagne di 1-click phishing già in precedenza collegate a NSO.

La tecnica rappresenta un’evoluzione rispetto agli attacchi zero-click del 2019: non sfruttando più una vulnerabilità tecnica della piattaforma (impossibile dopo le patch e l’ingiunzione), NSO avrebbe adottato un approccio di spearphishing che richiede l’interazione dell’utente ma aggira il divieto tecnico di sfruttamento diretto dell’app. NSO avrebbe anche creato account e gruppi test su WhatsApp che la piattaforma ha rimosso.

WhatsApp ha condiviso pubblicamente gli indicatori di compromissione associati alle campagne e incoraggia gli utenti a verificare se siano stati bersaglio di metodi di social engineering collegati a NSO su più piattaforme, inclusi SMS ed email.

Le implicazioni: NSO sotto nuova proprietà, stessa operatività

Un elemento di contesto importante: lo scorso anno un gruppo di investitori americani ha acquisito NSO Group con l’ambizione dichiarata di rientrare nel mercato statunitense, da cui la società era stata di fatto esclusa dopo l’inserimento nella Entity List del Dipartimento del Commercio USA nel novembre 2021. L’acquisizione non sembra aver cambiato le pratiche operative della società.

Il mercato degli spyware commerciali continua a operare in una zona grigia normativa: i produttori si definiscono fornitori di strumenti legittimi per forze dell’ordine e intelligence, mentre le evidenze mostrano sistematicamente usi contro giornalisti, attivisti e dissidenti politici. Casi come quello di NSO Group dimostrano che anche quando una corte impone restrizioni operative esplicite, la compliance può essere ignorata.

La richiesta di contempt: cosa succede adesso

Con la richiesta di contempt of court, WhatsApp chiede al tribunale di sanzionare NSO per aver violato l’ingiunzione permanente di ottobre. Se il giudice dovesse riconoscere la violazione, NSO potrebbe essere soggetta a sanzioni finanziarie aggiuntive e a misure coercitive più severe, con potenziale impatto sull’appello ancora pendente.

Il caso stabilisce un precedente rilevante per l’intero settore dello spyware commerciale: per la prima volta un’azienda tecnologica è riuscita a ottenere non solo una vittoria risarcitoria ma un’ingiunzione permanente di portata operativa contro un vendor di sorveglianza. La risposta del tribunale alla presunta violazione di quell’ingiunzione determinerà se tali strumenti legali abbiano effettiva capacità deterrente.

Indicatori e raccomandazioni

WhatsApp ha pubblicato indicatori di minaccia collegati alle campagne di NSO. Chi ritiene di poter essere un bersaglio ad alto rischio — giornalisti, attivisti, operatori umanitari, funzionari governativi — dovrebbe:

• Verificare i propri dispositivi con strumenti come Mobile Verification Toolkit (MVT) di Amnesty International, che analizza artefatti forensi associati a Pegasus
• Trattare con massima sospetto qualsiasi link ricevuto su WhatsApp che rimandi a siti esterni, soprattutto da contatti non verificati o messaggi non attesi
• Controllare i propri account WhatsApp per rilevare accessi da dispositivi o sessioni non riconosciute
• Monitorare i threat indicators pubblicati da WhatsApp/Meta per verificare la presenza di domini o IP associati alle campagne negli access log dei propri sistemi

Il caso NSO-WhatsApp non è solo una vicenda legale tra due aziende: è uno dei fronti principali della battaglia globale per definire i limiti dell’industria dello spyware commerciale e la responsabilità legale dei suoi protagonisti.

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